Good morning, everyone. My name is Timur Yunusov. I'm head of offensive security research team in Cyber R&D Lab
and one of the organizers of Payment Village.
And today my presentation will be about payment bug bounty.
And because of a lot of struggles, I decided to name it
Fearing Loss in Payment Bug Bounty.
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. At the end, we'll reflect a little bit on what to expect,
what you should not expect, how to behave.
And middle part, the main section is about vulnerabilities themselves.
So mostly we'll be talking about bugs which actually had given money to me or my friends or my colleagues in the past.
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. And these are actually things which already can give you money.
Although they are at the very beginning level.
So why we do this, why we actually do Payment Village?
We think that this is quite niche part of information security, not only in terms of bug bounty.
As you can imagine, there are not many bug bounty programs which support payment vulnerabilities.
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.
And this is mostly due to the fact that this is like quite high entry barriers there.
And they were historically there in place, a lot of proprietary information, etc.
Not willingness to share the information within the community.
And this is what we try to break here.
And to be honest, bug bounty maybe is a good idea to do so because there are plenty of bugs there in cards.
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.
So bugs are everywhere.
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.
And we can actually change the surface of payment security at the end.
Just for the beginning, yeah, don't expect just a traditional approach.
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.
However, that is how your lab will be looking potentially.
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.
So you still can work a lot within mobile applications or web applications, but this talk will be about different approaches.
So let's talk about what you need to get.
Yeah, cards, most important part, obviously, for me at least.
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.
So let's go a little bit deeper into details.
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.
It's very interesting to look at non-standard cards.
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.
These cards support a few payment mechanisms, payment schemes, shall we say.
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.
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.
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.
And NFC, so NFC is a sort of modern way of EMV, just same EMV in a different wrapping of contactless proximity access.
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.
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.
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.
And all of these implementations can have their own vulnerabilities, which is quite interesting.
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 a mobile wallet from the mobile application.
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.
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.
Keep in mind, they are not the most robust piece of hardware.
They are quite easy to break just due to their cost and, you know, their size.
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.
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.
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.
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.
Next is to use Proxmark. Proxmark, historically, is well aware of NFC payments and support protocol 14443
and you can get information about NFC data using Proxmark.
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.
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.
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.
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.
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.
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,
you know, to do buffer overflow on the reader or to tamper data and to change cardholder verification methods, for example.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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, what, around 2010-2011, so it's like almost 10 years ago.
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.
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.
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...
You need to do this at home with your own readers, with your own CART, yeah.
So, what to do and what not to do, based on my own experience.
First of all, don't do this for money, guys.
There are much quicker and easier ways to earn money within Backbounce.
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.
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.
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.
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, you don't try to steal money from someone else, so this is fine.
However, if you will try to use someone else's money or accounts, this can end up very badly.
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.
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.
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, payment cards were top one for me over the last year, yeah, I was trying to find vulnerabilities.
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, so, but mostly point of my interest was a card.
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, really wide scope and they all have public bug bounty programs.
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...
Devices, or software, or hardware, yeah.
Things I haven't looked at, but I clearly know that they have bug bounty programs, like Simple Bank, Wells Fargo, etc, etc.
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, because none of bug bounty participants probably have ever checked this yet.
So, I'm gonna talk, as I said, mostly about bugs that have given money to me or my friends in the past.
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, 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.
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.
So, let's start. We're gonna start with the easiest one, things which are mostly can be covered via web or mobile applications, sometimes they involve cards.
First thing is current surrounding. 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.
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.
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.
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.
Have we reached already? Quite not yet. 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.
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, bypassing different anti-fraud measures, and basically you are not going to do this manually.
Yeah, 500 transactions or 10,000 transactions, it's impossible to do this manually, so you need some sort of automation.
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.
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, so all of them, all of cards that we checked, they are all prone to this vulnerability.
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.
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, but still better than nothing.
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%.
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.
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, 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, 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.
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.
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, yeah, so if you're gonna do payment for 1 cent, you still can get a cashback of 1 cent, minimal amount of cashback.
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.
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, but not all of them.
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,
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, 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, 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.
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.
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.
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, 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,
and then separately card number and expiry date, and then separately CVV.
Other features like card-to-card within banks or outside of banks really help to find valid card numbers and valid expiry date.
Refunds normally don't request for CVV, they only request for card number and expiry date.
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, 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.
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.
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.
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.
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.
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.
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, reasonably easy to replicate, 3 out of 5.
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, yeah, I'm gonna talk about how to apply Race Condition to payments.
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.
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.
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, that's not good.
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.
Been okay. This is the vulnerability I started with. I wanted to check as many banks and as many cards as possible. 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.
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.
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.
It's quite old, was many times discussed by people from University of Cambridge, Ross Anderson, Stephen Murdoch, like starting 2005, I believe.
You can read a lot about the materials, there are plenty of materials, but just briefly, yeah.
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.
And during man-in-the-middle attack we replace the first rule for offline pin, if it's not the offline pin.
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.
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.
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.
The terminal then will request the payment cryptogram and card will provide this payment cryptogram.
And this is normal intended behavior, so due to very complex... there is no simple answer why this is intended behavior.
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.
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, 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.
The thing is that I found one or two maybe banks who actually correctly checked this attack and correctly made decisions.
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.
Cryptogram replay also reasonably decent money income has brought to me. Some of them are complex 5 out of 5, some of them are not, depends on the circumstances.
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.
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.
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.
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.
And to protect against this, that has been ATC implemented. So each new transaction should have higher ATC, sequential ATC, like 1, 2, 3, 4, 5.
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.
And initially banks were saying, Visa or MasterCard were saying to banks that you need to suspend these transactions.
However, some of these transactions were legit and they were coming out of order because of offline transaction process.
So some of transactions were made on flight, on board, some were on a tube, I don't know, offline. And then they went online much later, much later the next transaction was made by the genuine customer.
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.
It might be just an out of order transaction, offline transaction. So you can't cancel transactions due just to this fact, you need to consider other things.
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.
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.
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.
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.
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.
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,
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, that I checked 3 years ago, they're still vulnerable to this attack.
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, they can spot the replay pre-recorded transaction and they cancel them.
So the only one difference is that now this attack can be done only with cards which are not essentially Mastercard card.
Remote code execution on the terminals, on point of sales, yeah, like Square. 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.
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.
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, how to start digging around that.
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.
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.
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.
So a little bit of reflection on today's presentation, yeah.
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.
They may have private bug bounty programs, which you still need to get access to.
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.
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.
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.
So what happens if you write to the support in the app or on Twitter?
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.
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.
In-app feedback, in-app chat assistance, yeah, most of the times they have no clue what are you talking about.
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?
And I was like, this is related to cart guys, this has no connection to the application whatsoever.
And that's kind of normal behavior you should expect if you will try to reach in-app feedback teams.
However, I was very surprised once when staff has started writing me things like cheap IRQC, failure.
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.
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.
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.
That means that bank or fintech startup whatsoever, they are not interested in security.
They probably have their own problems of absolutely different level and you won't get anything out of that, just to let you know.
LinkedIn was very helpful for me.
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.
Quite tricky because you can find different groups of people there.
You can find like a very low ground person like security analyst, SOC team analyst, someone like work in the fields.
And they won't be able to leverage your vulnerability within the team most of the times.
You can find people like CEO, CISO or CTO within banks.
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.
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.
So the best idea here will be some sort of middleman, like product owner, like security lead or something like that.
And this is the best choice for you. They will be able to understand the severity of issue, they will be able to leverage this issue along the chain within the bank.
So problems with HackerOne. 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, etc.
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.
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.
So expect this behavior very often. 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.
But HackerOne staff has declined, noticed this as informative, closed the ticket. So can you look, please? And if you will think that this is not relevant, all right. But if you think this is important, you can reopen this ticket.
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. And after that saying, damn, hey, guys, I also have this ticket, which was closed. And I believe that this is important for you.
Like last few thoughts. And that will be it for today. You need to be very clear and transparent about issues. 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.
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. 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.
They normally handle things like web or pen test issues, yeah. 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.
And that's why you also need to be ready to wait, wait long, long time. And that's why I don't do this for money, guys. If I would have to live on my bug bounty income, I would just kill myself. This is just horrendous. I have tickets which are open for half a year and I don't expect them to be resolved anytime soon.
But they are just driving me, yeah. And I'm really glad that I do these things.
Don't violate the law. As I said, it's very important. You clearly should understand and see the line where you can go and where you can't go.
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. What do you think about that? 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.
Forget about the scope. Try to think outside of the box. Payment bug bounty is not about XSS, remote code execution or any other traditional web approaches. It is about something absolutely different.
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.