WEBVTT 00:03.130 --> 00:05.570 Good morning, everyone. 00:06.070 --> 00:08.190 My name is Timur Yunusov. 00:08.190 --> 00:19.170 I'm head of offensive security research team in Cyber R&D Lab and one of the organizers of Payment Village. 00:19.810 --> 00:25.510 And today my presentation will be about payment bug bounty. 00:25.510 --> 00:33.510 And because of a lot of struggles, I decided to name it Fearing Loss in Payment Bug Bounty. 00:36.770 --> 00:45.730 So at the beginning, we're going to talk a little bit about setting up the payment lab, also about what to do and what not to do. 00:45.730 --> 00:51.370 At the end, we'll reflect a little bit on what to expect, what you should not expect, how to behave. 00:51.990 --> 00:56.210 And middle part, the main section is about vulnerabilities themselves. 00:56.210 --> 01:05.270 So mostly we'll be talking about bugs which actually had given money to me or my friends or my colleagues in the past. 01:05.270 --> 01:17.750 But also we'll talk just briefly about beginning stuff, very beginning, how to start with payments, what is interesting, what you can look at. 01:17.750 --> 01:21.450 And these are actually things which already can give you money. 01:22.410 --> 01:26.050 Although they are at the very beginning level. 01:27.390 --> 01:34.130 So why we do this, why we actually do Payment Village? 01:34.690 --> 01:43.070 We think that this is quite niche part of information security, not only in terms of bug bounty. 01:43.070 --> 01:49.730 As you can imagine, there are not many bug bounty programs which support payment vulnerabilities. 01:49.730 --> 02:00.030 But in general, it's quite niche and there are not too many experts in payment security, although there are many experts in APSEC or any other fields. 02:00.090 --> 02:06.350 And this is mostly due to the fact that this is like quite high entry barriers there. 02:06.370 --> 02:13.250 And they were historically there in place, a lot of proprietary information, etc. 02:13.310 --> 02:17.430 Not willingness to share the information within the community. 02:17.430 --> 02:20.910 And this is what we try to break here. 02:20.910 --> 02:32.950 And to be honest, bug bounty maybe is a good idea to do so because there are plenty of bugs there in cards. 02:32.950 --> 02:46.910 Over the last few years, we found like dozens of them and like dozens of groups of vulnerabilities and they could be applied for almost every bank we looked at. 02:46.910 --> 02:48.850 So bugs are everywhere. 02:49.370 --> 02:58.570 And I really support you guys to go and start digging there, finding vulnerabilities, repeating vulnerabilities that we found or other people found in the past. 02:58.570 --> 03:05.450 And we can actually change the surface of payment security at the end. 03:07.310 --> 03:12.490 Just for the beginning, yeah, don't expect just a traditional approach. 03:12.490 --> 03:24.670 So if you can imagine a normal person who does bug bounty, all they need is just a browser and verb, for example, and that's all. 03:24.810 --> 03:30.650 However, that is how your lab will be looking potentially. 03:30.650 --> 03:40.170 So a lot of cards, a lot of point-of-sales readers, different devices to read and write data for cards, to do man-in-the-middle. 03:40.170 --> 03:53.430 So you still can work a lot within mobile applications or web applications, but this talk will be about different approaches. 03:53.850 --> 03:58.970 So let's talk about what you need to get. 03:58.970 --> 04:03.250 Yeah, cards, most important part, obviously, for me at least. 04:03.250 --> 04:24.710 Mobile applications, point-of-sales, NFC readers and writers, as well as ENV chip readers and writers, and devices which allow you to do man-in-the-middle, so essentially read and write simultaneously and be able to replace some bits of information between reading and writing process. 04:24.710 --> 04:29.350 So let's go a little bit deeper into details. 04:30.210 --> 04:41.090 So cards, payment cards, you will need a payment card such as Visa or MasterCard or if it will be any other brand, go for it. 04:41.090 --> 04:44.830 It's very interesting to look at non-standard cards. 04:44.830 --> 04:54.970 So if you live in Asian region, you can get access to UnionPay, American Express or any other brands which are not Visa or MasterCard. 04:55.250 --> 05:03.330 These cards support a few payment mechanisms, payment schemes, shall we say. 05:03.330 --> 05:15.550 The first is MagStripe, one of the oldest one, and Lian, I believe, already has published a lot of materials about MagStripe, how it works, how to proceed with that, etc. 05:16.470 --> 05:32.790 CardNotPresent, this is essentially number on the front part of your card and security code on the back of your card, which allow you to do payments online, on the websites, and as I said, it's called CardNotPresent. 05:33.790 --> 06:02.350 Next, EMV or CHIP is a modern, relatively modern type of payment, however, it's been proved as not the most secure type of payment and there are plenty of vulnerabilities disclosed in the past by people like Steven Murdoch or Ross Anderson about different core issues for CHIP cards and CHIP transactions. 06:02.350 --> 06:19.650 And NFC, so NFC is a sort of modern way of EMV, just same EMV in a different wrapping of contactless proximity access. 06:21.050 --> 06:35.150 Next, as I said, you probably will need a mobile phone, such as rooted Android with NFC features or jailbroken iOS, which also should support Apple Pay. 06:35.430 --> 06:54.250 And this will be helpful for looking at different processes within banks or financial organizations, such as registration, different online banking services, with traditional payments, some registration process like QRC checks, know your customer. 06:55.030 --> 07:11.630 Android historically had their own mobile wallet implementation, which is called HCE, Host Card Emulator, and this allows other applications to create their own mobile wallets, so not just Google Pay. 07:11.630 --> 07:20.090 And all of these implementations can have their own vulnerabilities, which is quite interesting. 07:20.410 --> 07:38.230 Where iOS has only secure element and iOS can work only with Apple Pay, however, it's still possible to find some vulnerabilities, not only in Apple Pay itself, but in the process of issuing 07:41.610 --> 07:45.210 a mobile wallet from the mobile application. 07:46.630 --> 07:59.810 Next, you will need point of sales, like nowadays if you live in the US or Europe, it's super easy to open any like Square, PayPal. 07:59.810 --> 08:17.690 And two years ago, we discussed with Leanne how to open mobile point of sale account, how to get point of sale and start digging around different vulnerabilities there or use it for finding vulnerabilities in cards. 08:18.990 --> 08:24.410 Keep in mind, they are not the most robust piece of hardware. 08:24.410 --> 08:31.910 They are quite easy to break just due to their cost and, you know, their size. 08:32.690 --> 08:49.690 At the same time, they also, for many payment providers, it will be super easy to be suspended due to some fraud suspension or some other dodgy activities, which you actually gonna do with your own cards, I hope. 08:49.690 --> 09:06.190 At the same time, it's still reasonably easy to reopen your account to use a competitor or even the same company and try to reapply for another account, even though the previous one was suspended. 09:07.290 --> 09:22.250 Next, you will need NFC reader and writer and there are also a few options like the cheapest one and not the best one is ACR122 presented on the top. 09:22.730 --> 09:37.970 My reference is to use PN532 and there are also a few vendors which support PN532, so you can get Adafruit, which is most expensive, you can get one which is a little bit cheaper. 09:39.470 --> 09:41.370 Next is to use Proxmark. 09:41.370 --> 10:02.970 Proxmark, historically, is well aware of NFC payments and support protocol 14443 and you can get information about NFC data using Proxmark. 10:03.330 --> 10:19.190 My favorite choice is to use Android app, custom Android app, which you can just start cloning project on a GitHub like a video sender and adjust it for your needs. 10:19.190 --> 10:39.470 There are also projects which you don't even need to adjust, like Raw APDU or Card Reader Pro and they allow you to show, to read information from the card, like basically out of the box you go to Google Play Market, download it and that's it. 10:40.910 --> 11:18.310 EMV, so EMV reader is like the cheapest and most popular solution is SCR3310 and there are also plenty of projects which work with smart card readers, like PEMV deals, mostly work with PeaceCard module from Python, so it's also reasonably easy to start with reading data which stored on EMV chip of the card. 11:18.310 --> 11:33.790 And EMV chip is just standard ISO 7816, which support Java ecosystem, so basically all the applications on the chip and NFC, they are essentially Java applications. 11:33.790 --> 11:57.490 And there are Java frameworks and Java environments like Java Card OS, which support, which really has a few projects allow you to go and start writing your first payment application to, you know, to find vulnerabilities to replicate normal behavior of the card to understand what actually is going on. 11:58.890 --> 12:21.250 Going to the most interesting part, yeah, man-in-the-middle, so essentially we need situation where one card is sending information to the point-of-sale terminal and we need first of all to read all this information and be able to modify this information, 12:21.250 --> 12:33.270 you know, to do buffer overflow on the reader or to tamper data and to change cardholder verification methods, for example. 12:33.270 --> 12:49.130 And the first thing that we were working with was two PM532 readers working in different modes, SPI and UART, and they both can be connected to Raspberry Pi. 12:49.130 --> 13:00.910 And Python script on Raspberry Pi will be able to send information from one reader to another and to modify information on the fly, which is very convenient. 13:00.910 --> 13:18.590 And my colleague Alexey is going to present this project, which we worked with, thanks for him, for many, many years, so I hope we will update links very soon. 13:21.650 --> 13:34.550 However, for some reason PM532 don't work very good with all of cards and all of readers, and that's why I had to work with two mobile phones which support NFC. 13:34.550 --> 13:47.350 So the problem is that you have point-of-sale and a card, and point-of-sale works perfectly with other cards, and one dedicated card works perfectly with other point-of-sales. 13:47.350 --> 14:02.150 However, if you take dedicated point-of-sale and dedicated card and use this setup of PM532, they just don't see each other, and I don't know what to do with that, and none of us actually know so far. 14:02.330 --> 14:15.170 And we struggled with this problem for a while, and that's why at some point I decided to move on and to work with mobile phones. 14:15.170 --> 14:29.330 So one mobile phone acts as a reader, one mobile phone acts as a writer, and you probably met these projects in the past, just at the beginning of NFC era on mobile phones. 14:30.330 --> 14:49.090 And you basically send information over Wi-Fi, it's a little bit slow, but you still will be able to get transactions done, maybe with a little bit of help and a little bit of tweaks, however, it's still possible. 14:50.050 --> 15:09.390 As I said, there are a few open-source projects available on the GitHub, both for reading and writing this data, and you can modify all essential information on the fly, on the mobile app, or using some other man-in-the-middle devices over the Wi-Fi. 15:11.390 --> 15:34.030 EMV man-in-the-middle is like... there are a few projects, but the most reliable for me, project that works not perfectly, still have lumps and bumps and some issues with some cars, but still one of the best solutions I've ever met was made by Omar Choudhary, 15:34.030 --> 15:39.370 what, around 2010-2011, so it's like almost 10 years ago. 15:40.690 --> 16:07.850 And this project is publicly available, schemes, everything to do the same project is available on his website or on the university, Cambridge University website, and you can't buy it online, you need to manufacture your own, however, that's the device we use. 16:07.850 --> 16:32.710 So, basically, CART is entered in a reader, and then there is a C code, which allows you to send information and to do all necessary changes, acting as an active man-in-the-middle, and there is a CART emulator, as you can see on top, which is inserted into the CART reader. 16:33.950 --> 17:02.690 Well, as you can imagine, you can't go with this to McDonald's, you can't use this device in public space, unless you are really like a spy with exceptional skills of hiding and pretending to be a different person, so that's why it's... 17:02.690 --> 17:06.790 You need to do this at home with your own readers, with your own CART, yeah. 17:08.150 --> 17:15.010 So, what to do and what not to do, based on my own experience. 17:16.930 --> 17:20.130 First of all, don't do this for money, guys. 17:20.470 --> 17:27.150 There are much quicker and easier ways to earn money within Backbounce. 17:28.830 --> 17:49.030 Next, try to stay within the law, don't try to use stolen identities, don't try to create fake identities or synthetic identities, yeah, use only your own IDs, driving license, etc, etc. 17:49.030 --> 18:09.950 You can use, I don't know, your friend or your colleague to open another second account with their agreement from their side, yeah, but, yeah, stick up to legal rules. 18:09.950 --> 18:31.590 I've met many times, like, someone else's social security numbers lurking on the dark web, someone else's accounts on the websites, yeah, but this is really the easiest way to go to jail, so don't use these things, yeah, not a good idea. 18:31.590 --> 18:57.490 And also use only your own money and, as I said, only your own accounts, yeah, if you will send money on a card and then try to simulate stealing money from other point of sale, account or in any other way, this seems legit, at least for me, yeah, so you are not violating any laws, 18:57.490 --> 19:01.270 you don't try to steal money from someone else, so this is fine. 19:01.590 --> 19:09.030 However, if you will try to use someone else's money or accounts, this can end up very badly. 19:11.630 --> 19:32.150 Like, five or six years ago, there were no banks which offer bad bounty or responsible disclosure programs, and one of the first one was N26, where nowadays you can find plenty of them. 19:32.150 --> 19:42.790 Some of them are hidden, some of them are available on very limited resources, yeah, you need to dig around a little bit, so here are a few examples, not all of them, yeah. 19:44.170 --> 20:05.070 You can meet and find bad bounty programs on very, very big banks, like American Express, Bank of America, Capital One, and they all have plenty of resources, mobile cards, mobile applications, web applications, custom host card simulators, as I said, 20:05.070 --> 20:12.050 payment cards were top one for me over the last year, yeah, I was trying to find vulnerabilities. 20:12.790 --> 20:29.610 Not just in cards, but obviously over the time I had to expand a little bit my scope, because some things are just not so straightforward, you start looking around cards, then you use mobile phone, and then you suddenly see something and you can't stop digging there, 20:29.610 --> 20:35.150 so, but mostly point of my interest was a card. 20:36.830 --> 20:58.870 Then there are plenty of cryptocurrency startups, currency exchange markets, which also have the same set, like Coinbase, Crypto.com, they have their own cards, they have plenty of mobile applications, they have plenty of web applications, so it's really, 20:58.870 --> 21:02.450 really wide scope and they all have public bug bounty programs. 21:05.150 --> 21:34.070 Point of sales developers and service providers, like Square, Ingenica, they also have their own bug bounty programs, and, for example, Square have also payment cards, they have reasonably secure mobile applications and web applications, so I dare you go and try and break their... 21:35.450 --> 21:39.410 Devices, or software, or hardware, yeah. 21:41.650 --> 21:51.310 Things I haven't looked at, but I clearly know that they have bug bounty programs, like Simple Bank, Wells Fargo, etc, etc. 21:51.310 --> 22:09.930 I wasn't able to do so just because I don't live in the US and I don't have a social security number, but if you guys are located in the US, this is basically the easiest way, yeah, you look at vulnerabilities that I will present in a minute and go and check in these banks, 22:09.930 --> 22:17.130 because none of bug bounty participants probably have ever checked this yet. 22:18.850 --> 22:27.590 So, I'm gonna talk, as I said, mostly about bugs that have given money to me or my friends in the past. 22:27.590 --> 22:49.850 However, we also have this big area of bugs which are really easy to start with, easy to replicate, and they are available on our website, paymentvillage.org.slashlabs, so there are plenty of videos, little bit of materials, and we are here on the DEF CON, 22:49.850 --> 23:02.130 so you can write to us, ask questions, and we're gonna publish some feedback forms on our website, so people will be able to ask questions in the future as well. 23:02.170 --> 23:17.090 And we also are planning to publish more and more materials on our Payment Security Wiki to share more details about vulnerabilities in cards and in payments. 23:17.970 --> 23:19.770 So, let's start. 23:19.770 --> 23:28.630 We're gonna start with the easiest one, things which are mostly can be covered via web or mobile applications, sometimes they involve cards. 23:28.630 --> 23:31.250 First thing is current surrounding. 23:31.270 --> 23:45.910 One of my favorite thing, my colleague Arkady, my ex-colleague Arkady, will be sharing more information about this vulnerability on Sunday, I believe, on online banking security presentation. 23:45.910 --> 24:09.110 But briefly, for example, you have point of sale which accept payments in dollars, and you are paying for one dollar, making payment for one dollar from British card, which is essentially will be 0.77 British pounds. 24:09.110 --> 24:28.770 Then you wait three days, and after that make a refund for 0.02 dollars, which will be essentially rounded to 0.02 pounds, and your account, you will receive 0.02 pounds on your card back in three days time after that. 24:28.770 --> 24:51.870 So, as you can see, it is profit of 0.0047 dollars, yeah, because of rounding issues, and because that's how it works, all financial organization works with two digits after point. 24:53.590 --> 24:55.290 Have we reached already? 24:55.290 --> 24:56.930 Quite not yet. 24:57.490 --> 25:18.330 So, in order to show severity of vulnerabilities, you will need to repeat this at least a few hundred times, yeah, so most of banks asked me to repeat this at least 100 times, one bank I repeated this 500 times, which basically is worth like 2 dollars. 25:20.230 --> 25:39.890 Best case scenario, obviously, will be to repeat this 10,000 times, so 10,000 times will bring us 0.0047 dollars profit, maybe you don't even need 5 pounds to them, and that's the moment when you will meet different issues like bypassing one-time password, 25:39.890 --> 25:48.310 bypassing different anti-fraud measures, and basically you are not going to do this manually. 25:48.330 --> 25:56.630 Yeah, 500 transactions or 10,000 transactions, it's impossible to do this manually, so you need some sort of automation. 25:58.890 --> 26:21.810 A little bit about variations of this attack, so traditionally and originally it was related to currency exchange within online banking or mobile banking systems, and obviously this does not work everywhere, yeah, because many banks do this functionality in a right way. 26:21.810 --> 26:42.830 However, last year we found that all card payments, all payments that involve cards are prone to this vulnerability, such as online acquiring, offline acquiring, PayPal, Square, so for example you have PayPal account and you charge for 1 dollar from British cards and then do a refund, 26:42.830 --> 26:50.110 so all of them, all of cards that we checked, they are all prone to this vulnerability. 26:50.110 --> 27:08.490 So what I'm going to do is on each group of vulnerability I share amount of money that each submission has given me and the complexity out of 5, so 2 out of 5 rounding is reasonably easy to replicate. 27:08.490 --> 27:30.430 Yeah, many banks sadly share and say that, oh, this is not our problem, this is a problem of Visa or Mastercard, or this is a problem of the acquirer, or something like that, so there were, I think, 3 or 4 accepted submissions about currency rounding, 27:30.430 --> 27:32.930 but still better than nothing. 27:32.930 --> 27:54.710 Another variation is to use card-to-card, so if you send, for example, 2 cents to British account or to British card, you will receive 0.02 pounds almost always, yeah, so this is like 100%. 27:54.710 --> 28:02.630 The question is where you will be able to send this amount of money and how to find these vulnerabilities and how to prove this to the bank. 28:02.630 --> 28:24.770 And one of the interesting things that I found in the past is, for example, many banks can't handle refund transactions normally, so you, for example, try to do a refund in any currency, like in the lowest currency, rubles, Philippine pesos, anything like that, 28:24.770 --> 28:45.150 on your account, which is like pound accounts or dollar accounts, yeah, and even after rounding, if it's much smaller than 0.01, bank looks at the refund transaction and they need to do something with that, or like, they can't just ignore this or skip this, 28:45.150 --> 29:17.130 although some banks actually do this, and they have to give you the minimal amount of money and that's why your account will have 0.01 pounds on it after this transaction, so it's much more profitable than just a regular currency rounding, so the exchange rate can be like 10 times bigger than the market currency exchange rate. 29:19.830 --> 29:39.790 Next is a cashback, so sadly, cashback vulnerabilities, I reported to a few banks, but all of them didn't have an official bug bounty program, so all I've got is just 10Q, we're gonna fix this vulnerability, 10Q, so I earned 210Q, which is $0. 29:40.770 --> 30:20.650 Also quite easy to replicate transaction vulnerability to out of 5, so a lot of cards and banks have their cashback programs, and for example, if you're gonna pay $1, you'll get 1% cashback, which is 1 cent, yeah, but here is where wrong mechanics or wrong math or issues lie within, 30:20.650 --> 30:30.290 yeah, so if you're gonna do payment for 1 cent, you still can get a cashback of 1 cent, minimal amount of cashback. 30:30.290 --> 30:48.630 Next, if you can do payment in 0.01 any currency, like peso or rubles, you still can get 0.01 dollar cashback, which is even much higher than amount you spent, which is really good. 30:50.770 --> 31:12.010 Next is, you do payment for $1, get your 1 cent cashback, and then you do $1 refund, return money back, and cashback does not disappear anywhere, so you earned money out of nothing, yeah, normal banks, they just recall these things and take your cashback back, 31:12.010 --> 31:14.710 but not all of them. 31:15.660 --> 31:42.370 And next thing is that, imagine you go to the hotel, check in, pay $500 at the beginning, and you get your $5 cashback here, yeah, and then once you check out and you haven't eaten anything from your bar, room bar, or you didn't pay for anything extra, 31:42.370 --> 32:08.110 you actually, $400 will be returned, yeah, and clearance, as it's called, will go only for $100, but cashback will remain the same, so mass here is also wrong, and as you can see, there are plenty of ways to benefit on the cashback, so it's very important to keep an eye on different offerings, 32:08.110 --> 32:29.490 different products, new plans, because many banks, they start without cashback, and then they like, oh, let's implement cashback in our plans, yeah, sometimes that's why I buy more expensive plans, not like the cheapest one, because cheapest normally doesn't cost you anything, 32:29.490 --> 32:48.010 but if you, for example, are willing to pay 10 pounds a month, your plan will be different, and this plan may include cashback, and you can check this cashback, find vulnerability, submit it, and then switch back to the cheapest plan. 32:50.490 --> 33:10.270 Next, distributed guessing attack, or pin master attack, so this vulnerability is still pending for a few tickets on HackerOne for me, so it still hasn't brought any money for me, but I look forward to finish this process, because it's been like around half a year. 33:10.270 --> 33:23.330 For this submission, also reasonably easy, 2 out of 5, and we are going to publish a lot of materials and resources on our wiki about distributed guessing attack, pin master attack. 33:24.070 --> 33:53.570 The idea is in separate brute-forcing of card number, expiry date, and CVV, and the most high-profile case was in Tesco Bank 2017, where hackers have stolen 1.5 million pounds, and for this purpose, for distributed guessing, hackers, or you, can use different resources, 33:53.570 --> 34:13.810 like registration process, password resetting process, which involve, oh, and now you need to enter your card details, yeah, but they may not ask about all details, they may ask about only card number and expiry date, not CVV, and this is a way for you to separately guess brute-force card number and CVV, 34:14.110 --> 34:18.770 and then separately card number and expiry date, and then separately CVV. 34:18.770 --> 34:28.470 Other features like card-to-card within banks or outside of banks really help to find valid card numbers and valid expiry date. 34:28.810 --> 34:37.190 Refunds normally don't request for CVV, they only request for card number and expiry date. 34:37.190 --> 35:04.310 So, a few cases that I found in the past, yeah, one of my favorite, and I still look forward for getting money out of this, is one bank which allowed adding other cards for paying for credits or for any other things, and this process actually allowed to bypass security checks and enter random CVV, 35:04.310 --> 35:20.190 and within very specific circumstances card would have been added, and you obviously can start making payments with this card without knowing CVV, which is just amazing. 35:20.190 --> 35:30.850 I really want to share more details, write an article about that, so I hope this problem will be resolved soon, and I will be able to share this information. 35:31.410 --> 35:44.990 I also like payments on the airplane, because, as you can imagine, first of all, they won't require 3D secure, because you are in the air. 35:47.150 --> 36:09.610 And they almost always allow you to brute force CVV, expiry date, and you don't need to pay too much, you choose plan, like paying $5 for internet, yeah, so it's not like a massive problem to check this process and get a payment, check the brute force and things. 36:10.490 --> 36:33.830 For example, British Airways have CVV field in their onboard payment system, but they don't actually check CVV, so they send information to the issuing bank, saying this is the payment, these are requisites, expiry date, plan, that's it, give me money. 36:33.830 --> 36:56.790 And that's normal process, and bank says, okay, here is money, yeah, and that allows you to brute force basically expiry date and card number separately from CVV, you don't need to know right CVV, you brute force card details, and then you can brute force CVV separately. 36:58.310 --> 37:21.530 Race Condition, also very, very old attack, one of my favorite, and I'm really glad that more and more submissions I see on HackerOne community about Race Condition and other vulnerabilities, logical vulnerabilities, brought me decent amount of money up to $2000, 37:21.530 --> 37:25.770 reasonably easy to replicate, 3 out of 5. 37:25.770 --> 37:48.310 I won't go very deep into details of this vulnerability, it's what you do, you basically Google Race Condition Vulnerability HackerOne, you can read few submissions, publicly available disclosures, and to understand what this is all about and how to get it done, 37:48.310 --> 37:53.590 yeah, I'm gonna talk about how to apply Race Condition to payments. 37:53.590 --> 38:12.650 So, first thing I always check is can you use one-time password within Race Condition many times, yeah, can you actually do many transactions with one-time password or different operations with one-time password within very small period of time, like milliseconds. 38:12.650 --> 38:36.110 Race Condition also allows you to bypass daily limits, so if you have, for example, daily limit of payments of $100 and you do two payments for $100 or $99 within the same very small period of time, you basically can do transactions and twice your daily limits. 38:36.950 --> 39:03.030 Next is transaction replace, like cryptogram replace or transaction ID replace, so the idea of transactions is that it should be used only once, it should be unique and identify the original intention of the payee and if you'll be able to replicate transaction many times within small amount of period of time or over the day, 39:03.030 --> 39:04.450 that's not good. 39:06.170 --> 39:35.550 Scenario which I looked and I was looking for a long time in the wild but sadly haven't found yet is obviously making money out of nothing when you basically send money from one account to another account using Race Condition and at some point you end up having more money on one account than you should have at the end. 39:38.630 --> 39:40.070 Been okay. 39:40.450 --> 39:43.310 This is the vulnerability I started with. 39:43.870 --> 39:48.930 I wanted to check as many banks and as many cards as possible. 39:49.610 --> 40:03.430 Sadly, one of the most complex one, 5 out of 5 and this is mostly due to the fact that you need special equipment, as I said, man-in-the-middle device and you can't buy it. 40:03.430 --> 40:17.710 You still can use things like SimTrace or other projects but for me they don't work and I really struggle to launch them, to do actual man-in-the-middle, to change data, not only to log this data. 40:17.710 --> 40:38.650 But if you'll be able to get a man-in-the-middle device or to create your own, this is gonna be very beneficial to check against this attack and we have a special wiki website, wiki page for this attack. 40:38.650 --> 40:55.350 It's quite old, was many times discussed by people from University of Cambridge, Ross Anderson, Stephen Murdoch, like starting 2005, I believe. 40:57.450 --> 41:02.570 You can read a lot about the materials, there are plenty of materials, but just briefly, yeah. 41:02.570 --> 41:19.150 So every card has their own cardholder verification rules, which says how I want to verify a cardholder and traditional methods are signature, offline pin or online pin. 41:19.510 --> 41:28.490 And during man-in-the-middle attack we replace the first rule for offline pin, if it's not the offline pin. 41:28.490 --> 41:41.330 And what happens is that you enter random pin code on a terminal, this pin code will be sent to the card, because it's offline pin checking, not online. 41:41.450 --> 41:55.050 And card sees that this is a wrong pin and get back to you with an answer 63C2, which is translated as wrong pin, two attempts left. 41:55.870 --> 42:09.170 And what we do with man-in-the-middle attack is we replace this answer for 900, which is translated as pin was okay, everything's fine, let's move on. 42:09.770 --> 42:15.170 The terminal then will request the payment cryptogram and card will provide this payment cryptogram. 42:15.170 --> 42:28.550 And this is normal intended behavior, so due to very complex... there is no simple answer why this is intended behavior. 42:28.550 --> 42:42.350 But I really ask you guys go and look and read all the materials which are available on our website or will be available soon in order to understand how this works and why this is the case. 42:42.350 --> 43:02.550 But what should be done is that after that, when all the information, cryptogram and all the payment transaction details will be sent to the issuing bank to get a final confirmation, bank should actually support this issue and they have all instruments for this, 43:02.550 --> 43:15.870 but most of them don't and they fail to see that this transaction is not good and to decline it and most of them they accept this transaction. 43:15.870 --> 43:30.970 The thing is that I found one or two maybe banks who actually correctly checked this attack and correctly made decisions. 43:30.970 --> 43:47.110 Most of banks, they allow this attack, so just go and check and if you'll be able to submit this vulnerability, I will be so happy and 2020 will not be lost for me. 43:47.810 --> 43:57.210 Cryptogram replay also reasonably decent money income has brought to me. 43:57.590 --> 44:03.450 Some of them are complex 5 out of 5, some of them are not, depends on the circumstances. 44:03.450 --> 44:24.310 Most of the cases you just need to... so this attack also explained on a few of our documents, white papers, not only ours, guys from payment industry as well on our website you can find all links. 44:25.010 --> 44:47.990 So payment cryptogram is essentially a cryptographic signature of some fields which card requests like date, amount, currency and also requests a few fields which help against exactly replaying. 44:47.990 --> 45:01.010 So it asks for the UN, unique number from the terminal and card provides transaction counter by itself to protect against replaying already pre-recorded transaction. 45:01.010 --> 45:14.850 And basically as long as we know all fields, date, amount, currency, we can pre-record the cryptogram, calculate the cryptographic signature and use it in the future. 45:14.850 --> 45:21.170 And to protect against this, that has been ATC implemented. 45:21.170 --> 45:30.250 So each new transaction should have higher ATC, sequential ATC, like 1, 2, 3, 4, 5. 45:30.250 --> 45:43.830 And if ATC is out of order, like you have transaction on the bank with ATC 5 and then next you get with ATC 1, that is suspicious, that might be a sign of fraud. 45:43.830 --> 45:52.050 And initially banks were saying, Visa or MasterCard were saying to banks that you need to suspend these transactions. 45:52.050 --> 46:02.610 However, some of these transactions were legit and they were coming out of order because of offline transaction process. 46:02.610 --> 46:08.530 So some of transactions were made on flight, on board, some were on a tube, I don't know, offline. 46:08.530 --> 46:17.830 And then they went online much later, much later the next transaction was made by the genuine customer. 46:17.830 --> 46:46.540 And these false positives, massive amount of false positives brought the industry to the level where Visa, MasterCard, most of the banks said, alright guys, ATC out of order is not strict evidence of fraud. 46:46.540 --> 46:51.340 It might be just an out of order transaction, offline transaction. 46:51.340 --> 46:58.420 So you can't cancel transactions due just to this fact, you need to consider other things. 46:58.420 --> 47:12.750 And most of the banks just switched off these checks and now you can use the same ATC or ATC out of order, pre-recorded cryptogram, calculated cryptogram and then send it many, many times. 47:13.630 --> 47:26.370 This is not good, this is not right, but this is essentially how payment industry works nowadays and we also submitted a few vulnerabilities there for many banks. 47:26.370 --> 47:38.950 Some of them are willing to change this, some of them are not willing to change this process and rely on other risk mitigation procedures, but God bless them. 47:40.750 --> 47:56.790 Another type of cryptogram replay I discussed in 2017 and to be honest it's much easier than 5 out of 5 here, is related to Apple Pay in-store or on-app payments. 47:56.790 --> 48:14.010 So basically the same idea, payment cryptogram which generates by your Apple phone when you use your fingerprint is a signature of all essential fields like date, amount, currency and special nonce. 48:14.010 --> 48:58.250 So it generates some random unique information and you can use the same cryptogram many times and that is because Apple does not check this information, they imply that this information goes transparently between them and the issuing bank and they just provide the ecosystem and they don't look at customers' and cardholders' data and they have maybe one line saying that cryptogram should be unique and should not be used more than one time, 48:58.250 --> 49:24.030 but they don't have very explicit explanation for merchants and for service providers and therefore service providers say we do what Apple says us to do and merchants say we do what Apple says us to do and that's why after my presentation in 2017, now 2020 and most of web resources that we checked, 49:24.030 --> 49:27.750 that I checked 3 years ago, they're still vulnerable to this attack. 49:28.950 --> 49:48.090 The only one difference which is really good sign is that since that Mastercard decided to look at this information at their network because as you can imagine all payments with Mastercard cards, they go through their network and they can spot this information, 49:48.090 --> 49:54.910 they can spot the replay pre-recorded transaction and they cancel them. 49:54.910 --> 50:05.150 So the only one difference is that now this attack can be done only with cards which are not essentially Mastercard card. 50:07.270 --> 50:13.270 Remote code execution on the terminals, on point of sales, yeah, like Square. 50:13.270 --> 50:24.890 Square has their own bug bounty program as I said and they have their own point of sales, fancy big one and smaller, not as fancy but still very robust indeed. 50:25.910 --> 50:42.390 And they have, my colleague got two and a half grand for submission about vulnerability, not even in their terminals but in terminals that Square has used in the past. 50:45.570 --> 51:07.110 The only one problem is that you need to know hardware very well, hardware security, be a reasonably decent engineer but my ex-colleague Alexey is going to share tomorrow I believe a presentation about point of sales security, how to spot vulnerabilities, 51:07.110 --> 51:09.470 how to start digging around that. 51:09.470 --> 51:19.190 So go and look and maybe you'll be able to find your own remote code execution in some point of sales and earn some money. 51:20.910 --> 51:46.410 As I said, we published special, as we call them, labs, yeah, where there are a few lessons how to start with payments, how to understand what is recorded on MaxTry, what is recorded on NFC, EMV and how to actually find your own first payment vulnerability. 51:46.410 --> 52:01.430 So go on our website, look there and if you'll have any questions you can ask them on Discord or later get in touch with us via emails or any feedback forms we gonna publish on our website. 52:02.650 --> 52:08.070 So a little bit of reflection on today's presentation, yeah. 52:10.770 --> 52:28.110 If you will look at how mature a bank or any other financial institution is, you can see, like, okay, on top you have banks can have official bug bounty program, which is like best case scenario for you. 52:28.110 --> 52:33.930 They may have private bug bounty programs, which you still need to get access to. 52:34.640 --> 52:52.100 Then next, banks may have emails like security ad or a special responsible disclosure page, so you Google responsible disclosure bank X or site X and try to reach them via their resources. 52:52.730 --> 53:02.590 Banks may also have staff on LinkedIn, security staff, and this is the opportunity I've taken many times in the past, it's very helpful. 53:04.230 --> 53:20.170 However, don't ever try to use support of the bank, customer support on Twitter or in the app, because as you can imagine, they are not dedicated for security and I'm gonna show you why. 53:20.170 --> 53:26.350 So what happens if you write to the support in the app or on Twitter? 53:26.350 --> 53:40.070 Most of the cases, you will get something like, yeah, regarding the issues you have spotted, you can send us information at and then some public email like contact or feedback at or something like that. 53:40.070 --> 53:55.330 However, sometimes if it's small startup, you actually can reach their security team, yeah, so they will be sending you emails like security app, which is good, yeah. 53:57.730 --> 54:06.850 In-app feedback, in-app chat assistance, yeah, most of the times they have no clue what are you talking about. 54:07.870 --> 54:22.090 And like I was sending to one of the banks information like, oh, I found this issue in your cart, I need some assistance, blah, blah, blah, and they were like, did you try to delete your app, turn it on and off back? 54:22.090 --> 54:30.630 And I was like, this is related to cart guys, this has no connection to the application whatsoever. 54:30.630 --> 54:39.210 And that's kind of normal behavior you should expect if you will try to reach in-app feedback teams. 54:39.210 --> 54:48.550 However, I was very surprised once when staff has started writing me things like cheap IRQC, failure. 54:48.550 --> 55:04.010 I was like, wow, this is a very deep knowledge and this is probably not the type of terminology you share with your customers just because a normal customer will not understand a word in your sentence. 55:04.010 --> 55:21.210 But this might happen, although I'm telling you Twitter or in-app support is one of the worst way to reach the bank with about your security issues. 55:21.270 --> 55:32.350 So if you can't find official or private background to program or security app doesn't exist and you don't see security stuff on LinkedIn, this is a really bad sign. 55:33.130 --> 55:41.130 That means that bank or fintech startup whatsoever, they are not interested in security. 55:41.130 --> 55:52.470 They probably have their own problems of absolutely different level and you won't get anything out of that, just to let you know. 55:54.470 --> 55:57.670 LinkedIn was very helpful for me. 55:57.670 --> 56:11.450 So you do look for something like security, name of the organization and try to reach persons and try to reach people and inform them about vulnerabilities. 56:11.450 --> 56:18.110 Quite tricky because you can find different groups of people there. 56:18.110 --> 56:30.090 You can find like a very low ground person like security analyst, SOC team analyst, someone like work in the fields. 56:30.930 --> 56:38.930 And they won't be able to leverage your vulnerability within the team most of the times. 56:38.930 --> 56:45.570 You can find people like CEO, CISO or CTO within banks. 56:45.570 --> 56:55.710 And they won't handle your issue because they just probably don't have time, don't have intentions, are not willing to do anything. 56:55.710 --> 57:06.810 Unless they are an actual owners of the startup, which can be a little bit different, although they might not even have free time as well. 57:06.810 --> 57:16.710 So the best idea here will be some sort of middleman, like product owner, like security lead or something like that. 57:16.710 --> 57:19.830 And this is the best choice for you. 57:19.830 --> 57:28.810 They will be able to understand the severity of issue, they will be able to leverage this issue along the chain within the bank. 57:31.290 --> 57:34.170 So problems with HackerOne. 57:34.170 --> 58:02.850 Yeah, even if the company has a HackerOne or Bacrowd security program, you can meet a lot of times responses such as this issue is not relevant, this isn't the cybersecurity risk, or these problems should be handled through law enforcement and financial departments, 58:02.850 --> 58:03.350 etc. 58:03.350 --> 58:20.070 So just because most of the banks work via HackerOne using HackerOne staff as a first line, they don't use their own security staff, security engineers to handle requests. 58:20.070 --> 58:35.210 And most of the time HackerOne staff won't understand what you're talking about, like, they will be just rubbish for them, they might say out of scope, because of this is a physical security issue or something like that, etc, etc. 58:35.210 --> 58:39.450 So expect this behavior very often. 58:39.510 --> 58:50.930 And what I normally do, I come back to this point, try to reach security staff on LinkedIn saying, hey, guys, I sent the information to you. 58:50.930 --> 58:58.530 But HackerOne staff has declined, noticed this as informative, closed the ticket. 58:58.530 --> 58:59.810 So can you look, please? 58:59.810 --> 59:03.670 And if you will think that this is not relevant, all right. 59:03.670 --> 59:07.250 But if you think this is important, you can reopen this ticket. 59:07.250 --> 59:21.810 Or you can do the same within bug bounty, within HackerOne, for example, yeah, you can find some other issue, open another ticket and wait until actual bank staff will reach you. 59:21.810 --> 59:28.150 And after that saying, damn, hey, guys, I also have this ticket, which was closed. 59:28.150 --> 59:31.970 And I believe that this is important for you. 59:34.990 --> 59:37.310 Like last few thoughts. 59:37.690 --> 59:39.990 And that will be it for today. 59:41.690 --> 59:45.350 You need to be very clear and transparent about issues. 59:45.350 --> 59:54.670 As I said, it's very important to say that this is related to physical card, this is related to point of sale, some of them will say, oh, this is out of scope because of that. 59:54.670 --> 01:00:04.510 But some programs, I remember, like Backrowd, first response was from them, oh, this is out of scope because this is a physical security issue. 01:00:04.510 --> 01:00:24.650 But like half an hour later, they were like, all right, guys, we have decided that probably maybe we will try to reach bank and bank will decide their own because they understood that they are not at the position of fully understanding the severity of the vulnerability because they normally handle it. 01:00:24.670 --> 01:00:29.370 They normally handle things like web or pen test issues, yeah. 01:00:30.430 --> 01:00:49.770 You need to be very persistent, very creative, don't expect too much unless you will be very persuasive and will try to deliver your ideas to HackerOne staff or to the bank staff. 01:00:49.770 --> 01:00:55.690 And that's why you also need to be ready to wait, wait long, long time. 01:00:55.690 --> 01:00:58.150 And that's why I don't do this for money, guys. 01:00:58.270 --> 01:01:06.650 If I would have to live on my bug bounty income, I would just kill myself. 01:01:06.650 --> 01:01:08.070 This is just horrendous. 01:01:08.070 --> 01:01:15.390 I have tickets which are open for half a year and I don't expect them to be resolved anytime soon. 01:01:16.390 --> 01:01:18.910 But they are just driving me, yeah. 01:01:18.910 --> 01:01:22.770 And I'm really glad that I do these things. 01:01:23.750 --> 01:01:25.210 Don't violate the law. 01:01:25.210 --> 01:01:27.270 As I said, it's very important. 01:01:27.410 --> 01:01:35.810 You clearly should understand and see the line where you can go and where you can't go. 01:01:35.810 --> 01:01:45.570 And it's better to reach security staff first saying, oh, this is a potential problem and I want to look deeper and this, this and that. 01:01:45.570 --> 01:01:47.010 What do you think about that? 01:01:47.010 --> 01:02:00.290 Because as you can or may remember, even within just a regular web bug bounty, these things may cause a lot of issues within the security staff. 01:02:01.290 --> 01:02:03.010 Forget about the scope. 01:02:03.010 --> 01:02:05.310 Try to think outside of the box. 01:02:05.310 --> 01:02:13.670 Payment bug bounty is not about XSS, remote code execution or any other traditional web approaches. 01:02:13.670 --> 01:02:16.570 It is about something absolutely different. 01:02:16.570 --> 01:02:33.750 So I really hope that this presentation in our village will bring more awareness to the community, will bring more people to the payment security and will change the industry essentially.