 Hi everyone, this is turning my phone into a streaming device and both solutions We'd like to introduce ourselves briefly. I'm Emiliano Renueva. I'm a security engineer and security researcher at UTN I am from Córdoba, Argentina. And this is Damborgonio A security researcher. They are our Twitter tags if you want to follow us We are trying to protect data and people through a new type of risk management democratizing cyber insurance, having companies from bankruptcy after cyber attacks through advanced risk analysis This is the agenda. Well We'll talk about why we chose these devices, these solutions which are the security concerns that we found and How we hack them by taking different paths such as network traffic analysis application analysis, Bluetooth, hardware and so on Go ahead So what are digital wallets and what's the impulse and how everything is connected? Well digital wallets are a way for you to have your money stored in your phone Basically, you can receive money. You can transfer money or you can do operations with your money The problem comes when you have a business you want to receive payments from anyone For example, you're sending things and you are trying to to get payments from a guy that doesn't have the same wallet or May have a Craig debit card So this advice is basically what they do is they allow you to interact with the credit card information and to receive the data that you need to make a payment and They're connected through Bluetooth. These solutions are widely available in Argentina So that's why we try to to analyze them and as you can see they are pretty common There are a lot of devices that are there We have very different digital wallets and all these devices have different providers So you can see in the bottom that there is a lot of providers because my boss striped this breed and amongst ours so You need to keep in mind that you have the the manufacturer and the digital wallet implementator And the one thing that you need to keep in mind as well is that the attacker right now might be the digital wallet owner So you have this you have this business and you're trying to receive payments When you are receiving a payment you need to protect the client data from the guy that's paying and using this great card to give you money so Right now the attack surface. It's a little bit bigger and we would choose these devices to to assess them Is the in the first case is that they are sending very critical information over Bluetooth, which is critical information so We might you might know that Bluetooth photo zero to very vulnerable You can do a shy hug attacks and you can do a lot of stuff with Bluetooth So our first question was how secure is this? It's really secure You can really see the critical information from the air or not. This is that difficult on the other hand we saw that differently from the the components or the Impulse that have a specific system embedded in it when you're trying to use your mobile application with those devices You can control the data flow. You can control the payment process And this is very it's a big problem because right now you can try Amongst other things to make a replay attack. You can try a different payments You can show the client one amount of money and then charge it for a bigger amount or something like that So we try to figure out how vulnerable is that the the critical owner the Digital one owner can manipulate the payment flow and the third thing is that we have a really wide attack surface You can hack that the entry you can hack the hardware You can have the firmware you can have the Bluetooth you can do a shy hack You can have manipulation of the application you can reverse an SDK that Third parties provided to you to integrate with your digital wallet. You can manipulate network traffic There's a lot of things you need to implement security measures on each one of those steps So the attack surface is really big. So as you can see, this is a simple graphic All those are attack points, right? So you can try to get the critical information for example in each one of those points So the other thing that you need to understand is what are the features that these those devices provides? These devices Allow you to read EMB, which is the chip from the credit card You can read the max train formation with is the black stripe in the back of your credit card for your credit card you can read NFC and Receive NFC payments and those devices allow a firmware update over the air They receive over the air key updates because I was play later how the case system management works and They have Bluetooth low energy and EDR, which is the 3.0 and they support pretty much every payment standard and you need to keep in mind that to understand what we've done is that These devices encrypt critical information to be sent to the back end and the way this is done is by a key management system Protocol which is called the UKBT. Basically what this device they have is a specific key you have as a Wallet provided you have a master key and for each one of the devices that go into the market You will generate a specific key Which is called the e-pec and this key will be embedded in the firmware and then for each Transaction that we'll try to do you'll try to generate a new key a session key to Encrypt this information and when this information gets to the back end Cypher with a triple desk The back-end system will try to generate the same key based on the device itself and the transaction that it's occurring So there is no interchange of a key, but this is a cypher Cypher channel between the device and the back end so after that the bus the transaction when It's it's get done and the other thing that you didn't understand is that click information provides a lot of stuff amongst them You can read a mag stripe. You can the mag stripe is a Stun is it's a fixed data. You can clone it. It's not something that you can change You have a mv data NFC data, which is a specific protocol that allows you to make payments But they have another additional Cypher link over it Won't get into details, but you need to know that there's a different protocols and stuff that you can get from a critical So moving on to network traffic Well, we're starting analyzing one of the cases one of the application vendors that interacts with this device and Well, we intercepted the traffic We actually realized that we can read and modify any data traveling on the request and the responses We use Frida objection meeting proxy burps with and well any proxy And we can control the whole payment flow And we capture we can capture the encrypted information that comes from this device and we can try Different use cases such as reducing data reconstructing information well We had to break the SSL pinning. So we use Frida scripts and running with objection and a proxy and Here we have the first a use case which is data reconstruction We have seen that this particular application was managing information We have obtained information from the back end that wasn't used at the front end. So we have seen that That is the encrypted information the credit card number and the CVV and expiration, etc But the back end returns the same information and not encrypted So there you see the first a numbers of the credit card number and the DNI and the last four numbers and expiration date so Well, that data was in venues at front end. So we should try to reconstruct the complete credit card number So how many attempts should I do? nearly nine thousand right But To get these four numbers that we are missing We should do only 999 attempts because The Crackle number follows a specific structure that can be validated with that script for example, right? so We should do brute force and then we get these four missing numbers and then we have The whole picture to make payments malicious payments So even though the Crackle data was traveling Cypher when the response for each one of the payments came through You can get this data to reconstruct any Crackle information Well, this is a next a use case which consists of reusing data Do you keep it? It states that The key the transaction key should be used once and then should be discarded So what if we resend a request that has the encrypted information with this key traveling in the request? What if we resend the request after a valid payment it should fade following the standard but Here we have the the process We initiate the transaction The customer makes a payment on the device We capture by analyzing the traffic we capture their request the transaction Goes well is accepted, but then when the customer leaves the store We started with triggers another payment with our cards But then we replace their request with the credit card information that is encrypted, but we have saved it previously We make another payment so you should keep in mind that there is a gray area between the responsibilities of the Device provider and the Craig and the digital wallet owner So these things comes to get in the gray area that No one wants to take a possibility about about the things that you should do and you should not do with the Great data and here we are positions as merchants. We are the attacker merchants So here's demo of their reply attack So we have two phones with two different applications and we are trying to make a payment from on the first digital wallet capture the data and then we open a second Digital wallet with a second device and we will try to dummy credit card payment and then we replace this great Good day dummy data with the previous one and we'll you will see that we have a successful transaction. So right now Everything's connected to me to proxy I already done a transaction So the the payment went through so sorry. This is a first payment Already connected. I'm getting the traffic from me to proxy I just received the encrypted credit card information from the first payment Again, don't bother about getting this data. It's all fixed. So you won't be able to use this data, but once the Right here. I'm using a simple identification number that you need in Argentina to make a payment and You will see that the transaction it's approved So the client left the store goes to home pretty happy. He paid 55 pesos and I'll turn off the Wi-Fi and leave everything on the side And they use a different Account in an old phone I'm getting the information to give you information that shouldn't be used to to recent for our payment and saving this data just in a text file That's cypher data. You can see the key SN which is a transaction key Which allows you to generate on the back end the new key to surface data and right on turn the phone Wi-Fi to make another payment that's a dummy card This it's already expired and I use it to make an initial payment so right now into 70s traffic and I will replace in this data. So turn on the device Make another payment for a bigger amount that's about a dollar and Right now you'll see the trigger the device But I will capture the information on traffic on our traffic. I will replace the information with the previous one and I resume the the traffic and you'll see that right now needed to again input on a data This is not validity. So I just can input whatever you want and you'll see that the intersection went through. So There are more things Wait a minute. So you can see that right here. I we have the Sorry, I was trying to show you Man, it was the second transaction and the wallet from the customer with a With a valid payment. Yeah, you can see right here We have the two payments from the same client and the second payment was never never actually executed. What's I need was charged so Going back to the presentation. Okay. Well, let's move on to application analysis We have seen network traffic and now We are going to hook the methods from the SCI is the key SDK sorry and We have the SDK and the device interacting with the application So we try to manipulate the objects the instance is related to the encrypted car information coming from this So we are abusing to UK PT implemented here Remember that We have this case in which we cannot reuse the key because this was fixed This was reported and fixed. We shouldn't use again the same request, but Encrypted car information shouldn't be used again too. So we are the ones interacting with the SDK and the device So we can manipulate and get as many keys and as many encrypted car information as we want This was theoretical We thought about it last year we tested this year and it worked so How it works We initiate a transaction The customer is going to pay Taps the car and this device we capture that current encrypted car information, right? And we try to make the payment fail So in the second attempt from the customer we are sending to you in the previous car information and In this second tab this second attempt from the client We are capturing also that information and we are saving it on memory and then when the customer leaves We are we're going to pay again with this second tab that we capture and The transaction will be accepted. This is a little script that we developed to run with objection We hooked the method the serializer that triggers the request that completes the operation the payment and We enumerate all the instances related to the objects the credit car information that comes from here and Well, we can save on an awry or send to a server and In the first attempt we are sending the umit data in order to make the payment fail and Well that method returns these umit data at first instance And then we are sending the previous car information that we are saving in each tab and well, we are sending the information to a server if we want and And well in order to understand this process We have two requests the first one that initiates the payment and the second one that completes that operation With an operation ID that is got from the first request Now in the demo we are showing you the request and responses, but I Wanted to make it clear that we are not manipulating the traffic We are only manipulating the instances at runtime. We are manipulating and hooking the methods of the SDK so Let's start with the demo Well, we are starting the application the customer is going to pay We are pairing the device. This is the first step. We are capturing the information But we are sending to umit data in order to make the payment fail Well, we are completing the DNI for legal reasons And Then we are triggering the the first request starting the payment with valid data but the second one is Jumit data because we want to make the payment fail, right? so then There's an error and we say the customer. Hey, let's try it again We have captured this valid information from the credit card and in this second time We are capturing also the credit card information, but we are sending the previous one from the first step that we have captured so completing again legal data and Then we are sending Well starting the payment again because this is a valid transaction We get an operation ID which is needed to complete the transaction later with this second request and Then we are sending the previous card information that we have saved And this wasn't used well We have triggered Now the malicious payment the customer leaves the store really really happy Then we trigger another payment As an attacker as a merchant attacker We start the operation We get the operation ID from the first request and then we are sending these previous card information From the customer which is encrypted. I don't need to know Where what is the what the credit card number is or the CVV so? We completed a payment so Here we have a valid transaction and the customer will see a second payment, but Just to clarify We try to manipulate the price, but this was validated at backend So and the the price was the first one that the customer paid previously so that was the demo and the second one And well just to in order that you understand how the script is This is a script running with objection We are capturing the first step But we tampered the method the serializer and we send the duma data We are saving car information. We are linking it to a server and This is the second top when the customer tries again But we are sending the previous one right the first one Well, this is the attacker top and we are sending The second top from the customer. It's a little a little strange But we are sending previous data and the payment goes what? So let's move on to Bluetooth so blue two analysis We don't open the all the devices They are mainly for and all of them share the pretty much the same Bluetooth chip which is the I chip YC 10 21 This if you go to a dog sheet, you'll see that these devices supports Bluetooth 3.0 and 5.0 And you might know that Bluetooth low energy is quite vulnerable. You can do shy hacker dogs. You can do a lot of stuff So we hope that we don't load Test application that some of these providers Allow you to use to interact with the device and to see if the device is working properly or not so We had this application to make it work with Bluetooth Low energy and we use below jack which is a tool that we love a lot Using three microbeats connected to a USB hub We were able to sniff all the the advertisement packets and we started to we were able to sniff critical information from a payment and You can see in the left there is the the application itself testing application It will show you the same the same information siphon information that we sent to the back end and Will be deciphered at the end and you can see in the right the Wireshark analysis and you can see the same information is being shown on both sides. So we are we we are effective We are sniffing the same information that the pain sent to the back end So the the Bluetooth is not adding any adding any siphon over the traffic, but We will try to do the same attack against all the digital wallets We weren't able to it to do it because mostly because all of them use a Bluetooth EDR which is the 3.0 and it's based on the peri-mechanism mechanism So to see what it's the data that is sending over Bluetooth EDR We were able to get the HCI the bug lock from Android and now doing we run a lot of Analysis over this traffic and we found out that the same data is traveling over the the HCI But since a Bluetooth EDR is adding another layer of a siphon ring You cannot get this information from just sniffing Bluetooth 3.0 and if you will were able to do it, you will need a really expensive tool which we will have But doing just a little bit of research over these devices You'll see that the first time you try to pair this device to your phone You will be shown with a numeric combination. The combination is basically Paying method when you show the same 6-digit number on the device and on the On the phone and you need to click accept on those devices I don't know if you see what's the problem. You have you don't have any screen in those devices You have no way to see or to know what are you paying to? So we tried to do an money-and-mere attack Basically what we created is just a very simple script where you where you use a single Bluetooth adapter and Basically doing a Bluetooth analysis over the traffic We found out that all the traffic information was sent over Bluetooth with an SPP protocol Which is basically serial over a Bluetooth. It's just transmit and send data. That's it You need just one channel. So we emulated the channel and we created a simple script Which is trying to listen based on a regex just to see if there is a device that is turned on other thing that you need to keep in mind is that For each other section you need to turn on the device because it turns off itself after three maybe five minutes So for interaction you need to turn it on and it accepts connection from pretty much anyone because again You don't have any way to pay it correctly with any other with any device. So All the script what it does is trying to start listening in the air It just connects as fast as you can to the device and then it starts emulating the same device and provides the same SPP protocol So that's it the setup. It's pretty simple. You have on one side the device turn on Raspberry Pi with Python and then the mobile application will try to connect automatically to the device that we are emulating so This demo This is one digital wallet You can see right here. That's the the remote tech top for the Raspberry Pi. We try we start the demanding me attack You can see that it's already Saw the device it's connected to the self and right now. It's emulating the same device so I just Enter to the mobile application At the digital wallet, I go to try to make a payment and Right now those devices are paid, but you will see that Everything works pretty good Right now you can see all the great the drafting information between the application the Raspberry Pi and the the impulse device For now try to make a payment and you can see all the information right from the air on the Miami attack so The pain mechanism doesn't allow you to know what are you actually paying to the devices, you know Where we're spending to and the mobile application doesn't know so what we can we do with this? With the money in the attack we can do basically a quick max type we can try to do a max type stealing Since the device is connected from from a one you can try to do another year update or or Impact update which is the key that itself or you can try to do do capital by past Which is pretty much the same as you in a shown but on Bluetooth level you try to force a bad payment You try it again You saw it save the data from the two the two manipulations and you send just one and the other It's already valid to make a second payment, but I wanted to show you a little big a little thing of This is the second try that we've done with money in the middle attack. This is another digital wallet and we try just a small payment and Now you you might be able to see something quite interesting Again the the color and the guys that's running this talk doesn't know that there's a guy in the middle so Right here. You can see that everything is working properly. I used an NFC payment and Everything is working currently But it's just really different. I've tried the max type and Again, this cake this data from the max type this car this are expires on the water But this information should be cypher. There's no way this information is traveling in plain text Right, so for another payment And you can see right there This is the plain text Max type information from the air. So basically you can go to any site You can go to any store in Argentina that you're using this Solution sit there and start receiving credit information. You can go with this data and emulate a card with max poof Pretty much. So moving forward Analysis we are not cover hackers this climber We're trying to be but these are the four devices that are right now available in Argentina We talk them apart and we saw that they share the same principles amongst all of them You have the small ones which don't so doesn't support NFC and the bigger one that supports NFC basically So what are the valuable points? I mean, what can I get as a? Low-level hardware hacker from this well the first thing that I think is really interesting to have is the credit information That is traveling on the devices DMC or in the tokens are also very data to make a payment So if I get the state of this information, I could go make payments The firmware might be really interesting to find bugs and hack other devices The AP key which allow will allow me to Disappear my own data and they may make another payment or maybe the UART logs will allow me to see a few logs That might be leaking important information, but you can see right here. This is really basic This is the connectors and things that you might find in these devices You have a blue to connector a big connector. We connect to the chip a controller Mike stripe, which is pretty much a tape head connected to an upper fire and in the back, but you can see in the upper fire and the MV front end and of course the Bluetooth I know you say all right But in the bigger devices you might find again Bluetooth a microcontroller We found out that this a flash memory. We suspect this. This is where the firmware is stored We have as well a tape head a body controller and an EFC front end of course to interact with NFC So this is something this every basic diagram on what are the the main components that all these devices we have so we went to for the long-hugging fruit and After running a few analysis stuff that we found out that the device was still working all open So they have any of the tampering measures And that's a must when you have a great car or career or whatever payment system You need to have on the tampering measures to avoid anyone to just hook in the data bus install the steaming formation Why because you have clear text traffic between each one of the country your component You have the controller which provide which provide you with a little bit of Cryptography but in the meanwhile mean between the data is trailing from the the peripheral and the controller You have clear text traffic. So we went for the long-hugging fruit and we tried to Get the max train formation from a simple swipe, which is pretty much like a common schema. That's pretty much what it is so That's the that's the amplifier. It's connected to the tape head and we connected an oscilloscope to the tape head and you can see in the right in the left that you have a waveform which is the encoding for the great car information from the from the mic stripe and You can see that the shape is very specific So this is what we saw on the oscilloscope pretty much the same shape. This data is on clear text traffic. So We got a data we tried to create a schema a schema We're trying to get this data and just mean it over the air whatever you can disclaimer This is our kill. Of course, don't don't get angry. There's a long way to do this. I'll show you but We used Blue peel which is an Arduino with a specific chip set that allowed me to have really high rates of Analog reads over the the data that is been sent between the tape head and the controller And we were sending all this data on raw data over the Bluetooth Which is again our kill and we were seeing this data with a Raspberry Pi connected to a bomber cat which is a vice that amongst other things allow you to emulate critical information So we create a little script for both these things Raspberry Pi with the code data will create will create the specific Max but the data that need to be sent to the bomber cat over serial in the bomber cat with emulate this data. So Here's demo Here's the test application. Here's the open device is working right now as it is. Here's the the hardware input implant and that's the receiver and that's another Car a critical receiver basically to see that the same information that we are sent are the same one that we are emulating so right now I'll try to make a swipe and You'll see that all this information right now has been sent over Bluetooth This is all the the data points and right now you can see that right the bottom That's the track two of the decoded data and this data is being sent To the bomber cat that is in the bottom You cannot say right now and right now emulating the data and you can see that pretty much is the same Not pretty much. It's the same data. This track two that we were able to send over the air again This is our kill this way is your way to do this But this is what work for us and this just to show you That the device is still working by itself right now You can see that the hardware input again because we are not hardware hackers. It's creating a lot of noises So when I try to make a payment Of course, it will fail. But if I disconnected the hardware him blood, you'll see that everything will work I Just to connect it the device and you can see that you're receiving the same and give data What is the device is supposed to do when it's open? It should wipe out all the keys and you shouldn't be able to decipher any data. So this is a big deal because You don't know if you're paying even though the network traffic or the blue for traffic might not be tampered You don't know if there is anything embedded in the device So this is what the scheming plant looks like it's quite big huge The receiver you can see on the left and you can see the transmitter on the right. It's pretty big But we find out that there's another way to do it We used a very simple for three three RF transmitter connected directly to the the energy input of the the same device and we were say able to Make a few swipes and transmit the same data over To a receiver and you can see that's quite small the thing that we weren't able to decode this data Correctly because there's a lot of noises and these devices are not that Not that good at just meeting Nice information over there So the last thing that the last night is working on one of those digital world companies. We saw that You shouldn't you should keep in mind that this is a trust chain between the device and the back end because Since the same keys being generated on both ends All the data is trusted between each one of the points. So In most of digital wallets you have this Fraud prevention systems when you are trying to make a same payment over and over and if it fails three Maybe four times your credit card might be blocked So we were saying that that we were heard we heard about a lot of Clients complaining about payments that they never had done and we were seeing that there was a lot of tryout payments for a bigger amount of money and all fails and Pretty much every payment was the same the data from the payment that the credit card was the same But they were changing the CVV number, which is a cure number embedded inside the the max train formation so we tried to replicate this problem to see what the fuck is what is going on and we found out that We created a max booth We didn't have the the bumper cut back then and we tried the same to do the same execution just trying to change the CVV number and We find out that the application behave really differently even though the credit card was blocked The credit the application behave differently if the CV was correct or if it is not so if the CV was not correct The application showed you something and if it was correct it showed you a different thing so The attacker once he get to the right CVV number He waited for the client to unlock his card and then he will go up there and make another payment So this is a problem mostly related to the trust chain between the devices and the gray area between their responsibilities of the Device provider and the great on the digital wallet the vendor So conclusion well final thoughts Companies should use encrypted end-to-end solutions that implements anti tampering with anti tampering measures and It's important to read manual to know how to implement also the Tu Kpt standards in it in this case and reuse data should be denied for no reasons and It could be good if an expiration or a TTL could be added to To this encrypted card information in order that no one can reuse it later So you have seen that we can save the information and using another opportunity and another way to associate and with a signature or I don't know something that Associated the accounts with the device and device ID or the impulse information Okay, one thing We think that one of the most critical things is that you can manipulate data So as Celia said, we thought we think that you should Digital sign everything that you're saying to the back end to make sure that the client is not manipulating the data That's really difficult to do. Sometimes you might find in Android that you can do pretty much whatever you want with your application On the other hand You should have any auto bounds pairing method because again, these devices If they didn't tend to be chipped and you don't want to add the screen you need to provide another way To avoid mining in the attacks. So all about paying might work with those devices because you can pair them with NFC for example So that might work and there is no no way for me as an attacker to make a money-in-the-meal attack us as itself Or you can add a device screen to devices to just to be sure that you're paying to the right device We think that this problem is quite quite dumb. I mean, it's really easy to to fix it But it might be related to the the implementation and the design of the solution by itself So these are the repositories the money-in-the-meals called pretty out The post they are harrowing plant again We are not having hackers. So sorry if you see things that you might not like and the current check card instructions to the repository for the Frida and objection scripts and we would like to thanks a few friends of ours I don't know Marino Marino called a hugger space in Joaquin Marila for help us and give us our recommendation and tips to Auto this sort of things. So thank you. We're open to questions