1 00:00:01,300 --> 00:00:08,560 Hi everyone. This is turning my phone into a skimming device and post solutions. We'd like to 2 00:00:08,560 --> 00:00:14,100 introduce ourselves briefly. I'm Eliana Barrio Nuevo. I'm a security engineer and security 3 00:00:14,100 --> 00:00:21,000 researcher at UTN. I am from Cordoba, Argentina, and this is Dan Borgogno. Hi, I'm a security 4 00:00:21,000 --> 00:00:28,900 engineer. I'm a security researcher. There are Twitter tags if you want to follow us. 5 00:00:28,900 --> 00:00:35,600 Uh, we are trying to protect data and people through a new type of risk, uh, risk management. 6 00:00:35,860 --> 00:00:39,800 Then we're pricing, uh, saving insurance, saving companies from bankruptcy after a cyber 7 00:00:39,800 --> 00:00:48,000 attacks through advanced, uh, risk analysis. Uh, this is the agenda. Well, we'll talk about why 8 00:00:48,000 --> 00:00:54,760 we chose these devices, these solutions. Which are the security concerns that we found. And 9 00:00:54,760 --> 00:00:58,880 how we hacked them by taking different paths, such as network trafficking, and, uh, 10 00:00:58,880 --> 00:01:06,320 traffic analysis, application analysis, Bluetooth, hardware, and so on. Go ahead. So, 11 00:01:07,020 --> 00:01:12,260 what are, uh, digital wallets, and what, what's MPOS and how everything is connected? Well, 12 00:01:12,400 --> 00:01:17,580 digital wallets are a way for you to have your money stored in your, in your phone basically. You 13 00:01:17,580 --> 00:01:22,800 can receive money, you can transfer money, or you can do operations with your money. Uh, the 14 00:01:22,800 --> 00:01:27,460 problem comes when you have a business, you want to receive payments from anyone. For example, 15 00:01:28,880 --> 00:01:34,160 you are trying to, to get payments from a guy that doesn't have the same wallet, or may have a 16 00:01:34,160 --> 00:01:38,520 credit debit card. So, these devices basically what they do is they allow you to interact with 17 00:01:38,520 --> 00:01:43,340 credit card information and to receive the data that you need to make a payment. And they're 18 00:01:43,340 --> 00:01:47,900 connected through Bluetooth. These solutions are widely available in Argentina, so that's why we 19 00:01:47,900 --> 00:01:52,840 try to, to analyze them. And as you can see, they are pretty common. There are a lot of, of 20 00:01:52,840 --> 00:01:59,900 devices that are out there. Uh, we have very different, uh, digital wallets, and all these 21 00:01:59,900 --> 00:02:04,500 devices have, uh, different providers. So, you can see in the bottom that there is a lot of 22 00:02:04,500 --> 00:02:11,380 providers, VBOS, MagicBOS, Stripe, Dspread, and amongst others. So, um, you need to keep in 23 00:02:11,380 --> 00:02:18,100 mind that you have the, the, the manufacturer and the digital wallet implementator. And the one 24 00:02:18,100 --> 00:02:22,820 thing that you need to keep in mind as well is that the attacker right now might be the, the 25 00:02:22,840 --> 00:02:27,420 digital wallet owner. So, you have this evi- you have this business and you're trying to 26 00:02:27,420 --> 00:02:33,540 receive payments. When you are receiving a payment, you need to protect the client data from 27 00:02:33,540 --> 00:02:38,980 the guy that's paying and using his credit card to, to give you money. So, right now the 28 00:02:38,980 --> 00:02:43,960 attack surface, uh, it's a little bit bigger. And we would use these devices to, to assess 29 00:02:43,960 --> 00:02:48,880 them. Is the, in the first case is that they are sending very critical information over 30 00:02:48,880 --> 00:02:52,820 Bluetooth, which is credit card information. So, uh, we might, uh, uh, we might, uh, uh, uh, uh, uh, 31 00:02:52,820 --> 00:02:57,080 you, you might know that Bluetooth, uh, 4.0, it's very vulnerable. You can do a shy 32 00:02:57,080 --> 00:03:02,500 hacker attacks and you can do a lot of stuff with Bluetooth. So, our first question was, uh, how 33 00:03:02,500 --> 00:03:07,580 secure is this? It's really secure. You can really see the critical information from the air or 34 00:03:07,580 --> 00:03:15,820 not. Is that difficult? On the other hand, uh, we saw that, uh, differently from the, the 35 00:03:15,820 --> 00:03:22,700 components or the, the inputs that have a, a specific system embedded in it. When you're 36 00:03:22,820 --> 00:03:27,760 trying to use your mobile application with those devices, you can control the, the, the data 37 00:03:27,760 --> 00:03:32,540 flow. You can control the payment process. And this is really, uh, it's a big problem because right 38 00:03:32,540 --> 00:03:37,440 now you can try, amongst other things, to make a reply attack. You can try a different 39 00:03:37,440 --> 00:03:42,620 payment. You can show the client, uh, one amount of money and then charge it for a bigger amount 40 00:03:42,620 --> 00:03:48,440 or something like that. So, we tried to figure out how vulnerable is that the, the, the 41 00:03:48,440 --> 00:03:52,400 critical owner, the, the digital warning owner can manipulate the, the payment flow. 42 00:03:52,820 --> 00:03:58,560 And the thir- third thing is that we have a really wide attack surface. You can hack data 43 00:03:58,560 --> 00:04:02,640 entry. You can hack the hardware. You can hack the firmware. You can hack the Bluetooth. You 44 00:04:02,640 --> 00:04:07,660 can do shy hack over Bluetooth. You can have manipulation of the application. You can reverse 45 00:04:07,660 --> 00:04:13,940 an SDK that, uh, a third party is provided to you to integrate with your digital wallet. You 46 00:04:13,940 --> 00:04:18,000 can manipulate network traffic. There's a lot of things and you need to implement security 47 00:04:18,000 --> 00:04:22,100 measures on each one of those steps. So, the attack surface is really big. So, 48 00:04:22,820 --> 00:04:27,820 as you can see, this is a simple graphic. Uh, all those are attack points, right? So, you can 49 00:04:27,820 --> 00:04:34,480 try to get the critical information, for example, in each one of those points. So, the other 50 00:04:34,480 --> 00:04:38,740 thing that you need to understand is what are the features that these, those devices provides. 51 00:04:39,300 --> 00:04:45,660 Um, these devices, uh, allow you to read EMV, which is the, the chip from the credit card. You 52 00:04:45,660 --> 00:04:51,140 can read the MAC string information which is the black stripe in the back of your credit card. You 53 00:04:51,140 --> 00:04:52,800 can read NFC and you can read the, uh, the, the, uh, the, uh, the, uh, the, uh, the, uh, the, uh, 54 00:04:52,820 --> 00:04:58,020 I mean, receive NFC, NFC payments. And those devices allow, uh, firmware updates over the 55 00:04:58,020 --> 00:05:03,200 air. They receive, over the air, uh, key updates because this will be played later how the 56 00:05:03,200 --> 00:05:09,160 case system marshals works. And they have Bluetooth, uh, low energy, and EDR which is the 57 00:05:09,160 --> 00:05:14,940 $3 guru. And they support pretty much every, uh, payment standard. And you need to keep in 58 00:05:14,940 --> 00:05:20,240 mind that to understand, uh, what we've done, uh, a, is that this devices encrypt some 59 00:05:20,240 --> 00:05:22,800 critical information to be sent to the backend and they are not just passiveidiot that uh, 60 00:05:22,800 --> 00:05:29,020 the way this is done is by a key management system um a protocol which is called the UKPT. 61 00:05:29,260 --> 00:05:36,260 Basically what this device eh have is a specific key you have as a um um a wallet 62 00:05:36,260 --> 00:05:40,720 provider you have a master key and for each one of the devices that are going to the market you 63 00:05:40,720 --> 00:05:46,500 will generate a specific key which is called the EPEC and this key will be embedded in the 64 00:05:46,500 --> 00:05:52,180 firmware and then in for each transaction that we'll try to do you'll try to generate a new 65 00:05:52,180 --> 00:05:57,500 key a session key to encrypt this information and when this information gets to the backend 66 00:05:58,080 --> 00:06:04,060 cypher with a triple desk the backend system will try to generate the same key based on the 67 00:06:04,060 --> 00:06:09,280 device itself and the transaction that is occurring. So there is no interchange of the key 68 00:06:09,280 --> 00:06:15,100 but this is a cypher uh cypher channel between the device and the backend. So after that the 69 00:06:15,100 --> 00:06:20,220 best the transaction went eh it's it's get done. Another thing that I didn't understand is 70 00:06:20,220 --> 00:06:22,160 that the information provides uh the uh the uh the uh the uh the uh the uh the uh the uh the 71 00:06:22,180 --> 00:06:28,520 notice of all of those stuff amongst them you can read max stripe you can DMAX yep is uh... 72 00:06:28,520 --> 00:06:33,580 aistarit eh it's it's a fixed data you can clone it it's not something that you can change. 73 00:06:33,820 --> 00:06:40,040 Um you have AMB data which is uh specific protocols that allows you to make payments but 74 00:06:40,040 --> 00:06:45,560 they have another additional cypher link over it. I will lift you up into a tapes but you need to 75 00:06:45,560 --> 00:06:48,460 know that that is a different products and study to get a precalóst także you get form a 76 00:06:48,460 --> 00:06:52,160 credit card. So moving on to network traffic. One most important vaccination feature in connect 77 00:06:52,180 --> 00:06:54,540 we started analyzing one of the cases, 78 00:06:54,600 --> 00:06:56,000 one of the application vendors 79 00:06:56,760 --> 00:06:58,500 that interacts with this device. 80 00:06:58,920 --> 00:07:02,280 And well, we intercepted the traffic. 81 00:07:02,560 --> 00:07:05,640 We actually realized that we can read and modify 82 00:07:06,220 --> 00:07:08,840 any data traveling on the requests and the responses. 83 00:07:09,400 --> 00:07:12,720 We use Frida, Objection, Meet and Proxy, 84 00:07:12,920 --> 00:07:14,980 Burp Suite, and well, any proxy. 85 00:07:15,720 --> 00:07:18,320 And we can control the whole payment flow. 86 00:07:18,320 --> 00:07:22,880 And we can capture the encrypted information 87 00:07:22,880 --> 00:07:24,400 that comes from this device. 88 00:07:24,800 --> 00:07:28,100 And we can try different use cases, 89 00:07:28,800 --> 00:07:32,180 such as reusing data, reconstructing information. 90 00:07:32,860 --> 00:07:36,720 Well, we had to break the SSL pinning, 91 00:07:36,780 --> 00:07:41,660 so we use Frida scripts running with Objection and a proxy. 92 00:07:43,220 --> 00:07:45,980 And here we have the first use case, 93 00:07:46,160 --> 00:07:47,780 which is data reconstruction. 94 00:07:48,320 --> 00:07:51,200 We have seen that this particular application 95 00:07:51,920 --> 00:07:53,600 was managing information. 96 00:07:54,440 --> 00:07:57,580 We have obtained information from the backend 97 00:07:57,820 --> 00:08:00,560 that wasn't used at the front end. 98 00:08:00,660 --> 00:08:02,300 So we have seen that. 99 00:08:03,220 --> 00:08:05,060 That is the encrypted information, 100 00:08:05,520 --> 00:08:09,680 the credit card number and the CVV and expiration, et cetera. 101 00:08:09,860 --> 00:08:12,400 But the backend returns the same information 102 00:08:13,120 --> 00:08:14,380 and non-encrypted. 103 00:08:14,940 --> 00:08:17,920 So there you see the first, 104 00:08:17,920 --> 00:08:21,780 a numbers of the credit card number and the DNI 105 00:08:21,780 --> 00:08:25,660 and the last four numbers and expiration date. 106 00:08:25,780 --> 00:08:30,960 So, well, that data wasn't being used at front end. 107 00:08:31,120 --> 00:08:33,420 So we should try to reconstruct 108 00:08:33,880 --> 00:08:36,600 the complete credit card number. 109 00:08:37,740 --> 00:08:40,020 So how many attempts should I do? 110 00:08:40,640 --> 00:08:42,560 Nearly 9,000, right? 111 00:08:43,520 --> 00:08:47,900 But to get these four numbers that we are meeting, 112 00:08:47,920 --> 00:08:52,180 we should do only 999 attempts 113 00:08:53,180 --> 00:08:56,760 because the credit card number follows a specific structure 114 00:08:57,360 --> 00:09:00,920 that can be validated with that script, for example, right? 115 00:09:01,580 --> 00:09:04,460 So we should do brute force 116 00:09:04,460 --> 00:09:08,100 and then we get these four missing numbers. 117 00:09:08,240 --> 00:09:12,240 And then we have the whole picture to make payments, 118 00:09:12,900 --> 00:09:14,940 malicious payments, so. 119 00:09:15,160 --> 00:09:17,860 So even though the critical data was strong, 120 00:09:17,860 --> 00:09:20,760 only in cipher, when the response for each one 121 00:09:20,760 --> 00:09:22,200 of the payments came through, 122 00:09:22,360 --> 00:09:25,160 you can get this data to reconstruct any critical information. 123 00:09:27,200 --> 00:09:30,220 Well, this is the next obvious case, 124 00:09:30,460 --> 00:09:32,400 which consists of reusing data. 125 00:09:33,540 --> 00:09:36,640 TUKPT states that the key, 126 00:09:36,820 --> 00:09:39,020 the transaction key should be used once 127 00:09:39,020 --> 00:09:40,920 and then should be discarded. 128 00:09:41,280 --> 00:09:47,620 So what if we resend a request that has the encrypted information 129 00:09:47,860 --> 00:09:49,980 with this key traveling in the request? 130 00:09:50,280 --> 00:09:52,840 What if we resend the request after a valid payment? 131 00:09:53,260 --> 00:09:56,220 It should fail following the standard, 132 00:09:56,320 --> 00:09:59,500 but here we have the process. 133 00:10:00,100 --> 00:10:01,920 We initiate the transaction. 134 00:10:03,660 --> 00:10:06,260 The customer makes a payment on the device. 135 00:10:06,700 --> 00:10:10,020 We capture, by analyzing the traffic, 136 00:10:10,140 --> 00:10:11,200 we capture the request. 137 00:10:11,820 --> 00:10:15,480 The transaction goes well, is accepted, 138 00:10:15,780 --> 00:10:17,600 but then when the customer leaves, 139 00:10:17,600 --> 00:10:20,300 the store, we started with triggers, 140 00:10:20,440 --> 00:10:22,200 another payment with our cards, 141 00:10:22,320 --> 00:10:25,520 but then we replace the request with the credit card 142 00:10:25,520 --> 00:10:26,640 information that is encrypted, 143 00:10:26,840 --> 00:10:28,280 but we have saved it previously. 144 00:10:29,340 --> 00:10:31,380 And then we make another payment. 145 00:10:31,940 --> 00:10:34,480 So you should keep in mind that there's a gray area 146 00:10:34,480 --> 00:10:37,640 between the responsibilities of the device provider 147 00:10:37,640 --> 00:10:40,480 and the digital wallet owner. 148 00:10:40,760 --> 00:10:44,680 So these things comes to get in the gray area 149 00:10:44,680 --> 00:10:47,560 that no one wants to take the possibility of, 150 00:10:47,560 --> 00:10:49,360 well, about the things that you should do, 151 00:10:49,380 --> 00:10:52,120 and you should not do with the data. 152 00:10:52,640 --> 00:10:55,860 And here we are positioned as merchants. 153 00:10:56,240 --> 00:10:57,980 We are the attacker merchants. 154 00:11:00,200 --> 00:11:02,600 So here's demo of the replay attack. 155 00:11:08,720 --> 00:11:11,680 So we have two phones with two different applications, 156 00:11:11,980 --> 00:11:13,820 and we are trying to make a payment 157 00:11:13,820 --> 00:11:17,420 from on the first digital wallet, capture the data, 158 00:11:17,560 --> 00:11:20,440 and then we open a second digital wallet 159 00:11:20,440 --> 00:11:21,400 with a second device, 160 00:11:21,620 --> 00:11:25,440 and we'll try to dummy credit card payment, 161 00:11:26,000 --> 00:11:28,860 and then we'll replace this credit card damage data 162 00:11:28,860 --> 00:11:29,840 with the previous one, 163 00:11:29,960 --> 00:11:32,660 and you will see that we have a successful transaction. 164 00:11:32,880 --> 00:11:36,220 So right now, everything's connected to midterm proxy. 165 00:11:37,580 --> 00:11:39,340 I already done a transaction. 166 00:11:41,360 --> 00:11:43,200 So the payment went through. 167 00:11:52,540 --> 00:11:55,860 So sorry, this is a pierce payment, already connected. 168 00:11:56,080 --> 00:11:58,160 I'm getting the traffic from midterm proxy. 169 00:11:59,280 --> 00:12:01,960 I just received the encrypted credit card information 170 00:12:02,760 --> 00:12:04,160 from the first payment. 171 00:12:12,080 --> 00:12:14,640 Again, don't bother about getting this data. 172 00:12:14,940 --> 00:12:17,540 It's all fixed, so you won't be able to use it. 173 00:12:17,540 --> 00:12:24,400 But once the, right here, I'm using a simple identification 174 00:12:24,400 --> 00:12:26,860 number that you need in Argentina to make a payment, 175 00:12:29,200 --> 00:12:31,720 and you will see that the transaction, it's approved. 176 00:12:32,020 --> 00:12:35,360 So the client left the store, goes to her home, pretty happy. 177 00:12:35,440 --> 00:12:42,560 He paid $0.55, and I'll turn off the Wi-Fi 178 00:12:42,560 --> 00:12:47,120 and leave everything on the side, and I'll use a different, 179 00:12:49,180 --> 00:12:51,600 different account in another phone. 180 00:12:53,680 --> 00:12:55,220 I'm getting the information, the green information 181 00:12:55,220 --> 00:13:00,420 that shouldn't be used to resend for another payment. 182 00:13:00,740 --> 00:13:04,060 And saving this data, just in a text file. 183 00:13:06,080 --> 00:13:07,100 That's cipher data. 184 00:13:07,340 --> 00:13:10,060 You can see the key SN, which is a transaction key, 185 00:13:10,180 --> 00:13:13,220 which allows you to generate on the back end the new key 186 00:13:13,720 --> 00:13:14,420 to save this data. 187 00:13:14,920 --> 00:13:17,240 And right now I'm turning the phone, Wi-Fi, 188 00:13:17,540 --> 00:13:18,220 to make another payment. 189 00:13:18,360 --> 00:13:19,340 That's a dummy card. 190 00:13:19,500 --> 00:13:20,540 This salary expired. 191 00:13:20,980 --> 00:13:23,860 And I use it to make an initial payment. 192 00:13:25,640 --> 00:13:27,320 So right now, I'm just saving the traffic, 193 00:13:32,580 --> 00:13:34,400 and I will replace this data. 194 00:13:34,580 --> 00:13:36,060 So turn on the device. 195 00:13:37,180 --> 00:13:39,120 Make another payment for a bigger amount. 196 00:13:42,320 --> 00:13:43,580 That's about a dollar. 197 00:13:48,100 --> 00:13:54,600 And right now you'll see that I'll trigger the device, but I will capture the information on network traffic, 198 00:13:54,800 --> 00:13:56,940 I will replace the information with the previous one, 199 00:13:58,500 --> 00:14:04,260 and I resume the traffic, and you'll see that right now I need to again input another data. 200 00:14:04,780 --> 00:14:09,920 This is not valid, so I just can input whatever you want, and you'll see that the intersection went through. 201 00:14:18,820 --> 00:14:24,100 There are more things, wait a minute. So you can see that right here, we have 202 00:14:27,240 --> 00:14:30,560 the, sorry I was trying to show you, oh man. 203 00:14:30,820 --> 00:14:36,160 It was the second transaction and the wallet from the customer with a 204 00:14:36,920 --> 00:14:37,640 with a 205 00:14:38,220 --> 00:14:38,960 valid payment. 206 00:14:39,460 --> 00:14:45,040 Yeah, you can see right here, we have the two payments from the same client, and the second payment was never 207 00:14:45,040 --> 00:14:46,920 actually executed, and it was 208 00:14:47,540 --> 00:14:48,680 charged. So, 209 00:14:49,700 --> 00:14:57,980 going back to the presentation. Okay, well, let's move on to application analysis. We have seen network traffic, and now 210 00:14:58,720 --> 00:15:02,540 we are going to hook the methods from the SDK, 211 00:15:02,860 --> 00:15:06,100 SDK, sorry, and 212 00:15:06,100 --> 00:15:10,080 we have the SDK and the device interacting with the application. 213 00:15:10,680 --> 00:15:16,740 So, we try to manipulate the objects, the instances related to the encrypted card information 214 00:15:16,740 --> 00:15:18,000 coming from this. 215 00:15:19,540 --> 00:15:24,280 So, we are abusing TUKPT implemented here, and 216 00:15:25,080 --> 00:15:26,000 remember that 217 00:15:26,880 --> 00:15:31,960 we have this case in which we cannot reuse the key because this was fixed, 218 00:15:32,080 --> 00:15:38,600 this was reported and fixed, we shouldn't use again the same request, but 219 00:15:39,620 --> 00:15:46,640 encrypted card information shouldn't be used again, too. So, we are the ones interacting with 220 00:15:46,740 --> 00:15:54,340 the SDK and the device, so we can manipulate and get as many keys and as many encrypted card information as we want. 221 00:15:54,820 --> 00:15:55,940 This was theoretical. 222 00:15:57,820 --> 00:16:03,640 We thought about it last year, we tested this year, and it worked. So, 223 00:16:05,000 --> 00:16:06,120 how it works? 224 00:16:07,260 --> 00:16:08,820 We initiate a transaction, 225 00:16:09,800 --> 00:16:12,060 the customer is going to pay, 226 00:16:12,240 --> 00:16:15,620 taps the card on this device, we capture 227 00:16:15,620 --> 00:16:23,920 that encrypted card information, and we try to make the payment fail. 228 00:16:25,740 --> 00:16:32,680 So, in the second attempt from the customer, we are sending to you the previous card information, 229 00:16:33,940 --> 00:16:37,340 and in this second attempt from the client, 230 00:16:37,580 --> 00:16:45,280 we are capturing also that information and we are saving it on memory. And then when the customer leaves, we are 231 00:16:45,620 --> 00:16:50,340 going to pay again with this second tap that we captured, and 232 00:16:51,020 --> 00:16:57,640 the transaction will be accepted. This is a little script that we developed to run with Objection. 233 00:16:58,040 --> 00:17:05,580 We hooked the method, the serializer that triggers the request that completes the operation, the payment, and 234 00:17:06,580 --> 00:17:11,060 we enumerate all the instances related to the objects, 235 00:17:11,360 --> 00:17:15,600 the credit card information that comes from here, and 236 00:17:15,620 --> 00:17:20,120 well, we can save on an array, or send to a server. 237 00:17:22,340 --> 00:17:27,000 And in the first attempt, we are sending GMI data in order to make the payment fail. 238 00:17:27,920 --> 00:17:32,620 And, well, that method returns this GMI data at first instance, 239 00:17:32,900 --> 00:17:36,940 and then we are sending the previous card information that we are saving in each tap. 240 00:17:37,720 --> 00:17:41,180 And, well, we are sending the information to a server if we want. 241 00:17:43,640 --> 00:17:44,160 And, 242 00:17:44,160 --> 00:17:44,760 well, 243 00:17:44,760 --> 00:17:50,200 in order to understand this process, we have two requests. The first one that initiates the payment, 244 00:17:50,420 --> 00:17:56,880 and the second one that completes that operation with an operation ID that is got from the first request. 245 00:17:57,620 --> 00:18:02,320 Now in the demo, we are showing you the request and responses, but 246 00:18:02,980 --> 00:18:07,340 I wanted to make it clear that we are not manipulating the traffic. 247 00:18:07,660 --> 00:18:14,360 We are only manipulating the instances at runtime. We are manipulating and hooking the methods of the SDK. So, 248 00:18:15,680 --> 00:18:17,860 let's start the demo. 249 00:18:22,020 --> 00:18:27,000 Well, we are starting the application. The customer is going to pay. 250 00:18:29,620 --> 00:18:35,200 We are pairing the device. This is the first step. We are capturing the information, 251 00:18:35,540 --> 00:18:39,820 but we are sending GMI data in order to make the payment fail. 252 00:18:42,060 --> 00:18:44,600 Well, we are completing the DNI, 253 00:18:44,760 --> 00:18:45,480 for legal reasons. 254 00:18:47,260 --> 00:18:53,100 And then we are triggering the first request, starting the payment with valid data. 255 00:18:53,600 --> 00:18:55,160 But the second one 256 00:18:56,040 --> 00:19:00,020 is GMI data because we want to make the payment fail, right? 257 00:19:01,240 --> 00:19:01,840 So, 258 00:19:02,740 --> 00:19:03,340 then 259 00:19:05,220 --> 00:19:09,540 there's an error and we say to the customer, hey, let's try it again. 260 00:19:11,320 --> 00:19:14,740 We have captured this valid information from the customer. 261 00:19:14,760 --> 00:19:19,060 We are sending the credit card. And in this second time, we are capturing also the credit card information, 262 00:19:19,380 --> 00:19:24,120 but we are sending the previous one from the first step that we have captured. 263 00:19:25,720 --> 00:19:26,980 So, completing again. 264 00:19:28,480 --> 00:19:29,200 Legal data. 265 00:19:30,680 --> 00:19:32,020 And then we are sending, 266 00:19:33,040 --> 00:19:36,100 well, starting the payment again, because this is a valid transaction. 267 00:19:36,340 --> 00:19:41,040 We get an operation ID, which is needed to complete the transaction later with this second request. 268 00:19:43,120 --> 00:19:44,740 And then we are sending the payment. 269 00:19:44,740 --> 00:19:47,140 And then we are sending the previous card information that we have saved. 270 00:19:48,740 --> 00:19:50,660 And this wasn't used. 271 00:19:54,980 --> 00:19:56,920 Well, we have triggered 272 00:19:58,940 --> 00:20:03,840 now the malicious payment. The customer leaves the store, really, really happy. 273 00:20:04,440 --> 00:20:06,820 Then we trigger another payment 274 00:20:09,040 --> 00:20:11,520 as an attacker, as a merchant attacker. 275 00:20:14,820 --> 00:20:16,320 We start the operation. 276 00:20:20,160 --> 00:20:23,000 We get the operation ID from the first request. 277 00:20:25,300 --> 00:20:30,720 And then we are sending this previous card information from the customer, which is encrypted. 278 00:20:30,880 --> 00:20:31,840 I don't need to know 279 00:20:32,440 --> 00:20:34,100 where, what is the, 280 00:20:34,700 --> 00:20:39,300 what the credit card number is, or the CVV. So, we completed a payment. 281 00:20:40,660 --> 00:20:41,180 So, 282 00:20:42,540 --> 00:20:44,300 here we have a valid transaction. 283 00:20:44,300 --> 00:20:47,560 And the customer will see a second payment. 284 00:20:47,700 --> 00:20:47,920 But, 285 00:20:49,020 --> 00:20:49,960 just to clarify, 286 00:20:50,840 --> 00:20:55,300 we tried to manipulate the price, but this was validated at backend. 287 00:20:55,840 --> 00:20:56,440 So, 288 00:20:56,660 --> 00:21:00,760 and the, the price was the first one that the customer paid previously. 289 00:21:01,100 --> 00:21:02,560 So, that was the demo. 290 00:21:02,800 --> 00:21:04,600 And the second one. 291 00:21:10,320 --> 00:21:13,660 And well, just to, in order that you understand, 292 00:21:14,300 --> 00:21:15,520 how the script is, 293 00:21:25,320 --> 00:21:27,720 this is a script running with objection. 294 00:21:30,740 --> 00:21:32,700 We are capturing the first step, 295 00:21:33,680 --> 00:21:37,040 but we tamper the method, the serializer, 296 00:21:37,610 --> 00:21:38,820 and we send the GMI data. 297 00:21:42,660 --> 00:21:43,200 Yeah. 298 00:21:45,560 --> 00:21:47,640 We are saving card information. 299 00:21:47,840 --> 00:21:49,300 We are linking it to a server. 300 00:21:50,160 --> 00:21:53,100 And this is the second tab when the customer tries again. 301 00:21:53,600 --> 00:21:56,960 But we are sending the previous one, right? 302 00:21:57,040 --> 00:21:57,580 The first one. 303 00:22:00,280 --> 00:22:00,800 Well, 304 00:22:03,080 --> 00:22:05,500 this is the attacker tab, and we are sending 305 00:22:06,660 --> 00:22:08,740 the second tab from the customer. 306 00:22:08,900 --> 00:22:13,640 It's a little, a little strange, but we are sending previous data. 307 00:22:13,640 --> 00:22:15,820 And the payment goes well. 308 00:22:17,500 --> 00:22:19,160 So, let's move on to Bluetooth. 309 00:22:19,680 --> 00:22:20,920 So, Bluetooth analysis. 310 00:22:21,940 --> 00:22:23,740 We don't open the, all the devices. 311 00:22:24,060 --> 00:22:24,980 There are mainly four. 312 00:22:25,400 --> 00:22:29,040 And all of them share pretty much the same Bluetooth chip, 313 00:22:29,140 --> 00:22:32,620 which is the iChip YC1021. 314 00:22:33,180 --> 00:22:34,780 This, if you go to the data sheet, 315 00:22:34,880 --> 00:22:38,160 you'll see that this device supports Bluetooth 3.0 and 5.0. 316 00:22:38,740 --> 00:22:41,840 And you might know that Bluetooth low energy is quite vulnerable. 317 00:22:42,040 --> 00:22:43,060 You can do shy hacker attacks. 318 00:22:43,220 --> 00:22:43,620 You can do laser attacks. 319 00:22:43,620 --> 00:22:43,920 You can do a lot of stuff. 320 00:22:46,040 --> 00:22:50,000 So, we have, we have a test application 321 00:22:50,000 --> 00:22:53,560 that some of these providers allow you to use. 322 00:22:53,860 --> 00:22:55,480 To interact with the device and to see 323 00:22:55,480 --> 00:22:57,020 if the device is working properly or not. 324 00:22:58,900 --> 00:23:03,140 So, we had this application to make it work with Bluetooth low energy. 325 00:23:03,360 --> 00:23:07,180 And we used VideoJack, which is a tool that we love a lot. 326 00:23:07,420 --> 00:23:10,740 Using three micro bits connected to a USB hub, 327 00:23:10,740 --> 00:23:15,460 we were able to sniff all the advertisement packets. 328 00:23:15,760 --> 00:23:20,660 And we tried to, we were able to sniff critical information from a payment. 329 00:23:21,520 --> 00:23:23,260 And you can see in the left, 330 00:23:23,380 --> 00:23:25,440 there is the application itself, 331 00:23:25,700 --> 00:23:26,280 testing application. 332 00:23:26,520 --> 00:23:28,520 It will show you the same information, 333 00:23:28,820 --> 00:23:30,800 cipher information that we sent to the backend. 334 00:23:31,180 --> 00:23:33,560 And will be deciphered at the end. 335 00:23:33,640 --> 00:23:34,680 And you can see in the right, 336 00:23:34,700 --> 00:23:36,420 the Wireshark analysis. 337 00:23:36,840 --> 00:23:38,260 And you can see the same information 338 00:23:38,260 --> 00:23:39,960 is being shown on both sides. 339 00:23:40,740 --> 00:23:41,780 So, we are, we are, 340 00:23:42,740 --> 00:23:45,760 we are sniffing the same information 341 00:23:45,760 --> 00:23:48,040 that is being sent to the backend. 342 00:23:48,140 --> 00:23:50,520 So, the Bluetooth is not adding any, 343 00:23:50,580 --> 00:23:53,540 adding any ciphering over the traffic. 344 00:23:53,660 --> 00:23:53,840 But, 345 00:23:54,480 --> 00:23:56,700 we will try to do the same attack 346 00:23:56,700 --> 00:23:58,380 against all the digital wallets. 347 00:23:58,440 --> 00:23:59,540 We weren't able to do it, 348 00:23:59,540 --> 00:24:00,420 to do it because, 349 00:24:00,560 --> 00:24:03,160 mostly because all of them use a Bluetooth EDR, 350 00:24:03,360 --> 00:24:04,300 which is the 3.0. 351 00:24:04,500 --> 00:24:06,060 And it's based on the pairing mechanism. 352 00:24:07,220 --> 00:24:10,720 So, to see what is the data that is sending now, 353 00:24:10,740 --> 00:24:11,520 over Bluetooth EDR, 354 00:24:11,680 --> 00:24:14,920 we were able to get the HCI debug log 355 00:24:14,920 --> 00:24:15,640 from Android. 356 00:24:15,840 --> 00:24:18,800 And doing, we ran a lot of analysis 357 00:24:18,800 --> 00:24:19,780 over this traffic. 358 00:24:20,060 --> 00:24:21,540 And we found out that the same data 359 00:24:21,540 --> 00:24:23,900 is traveling over the HCI. 360 00:24:24,460 --> 00:24:26,700 But, since Bluetooth EDR 361 00:24:26,700 --> 00:24:28,480 is adding another layer 362 00:24:28,480 --> 00:24:29,620 of ciphering, 363 00:24:29,680 --> 00:24:31,440 you cannot get this information from 364 00:24:31,440 --> 00:24:34,320 just sniffing Bluetooth 3.0. 365 00:24:34,560 --> 00:24:35,920 And if you will, 366 00:24:36,040 --> 00:24:37,360 were able to do it, 367 00:24:37,380 --> 00:24:38,920 you'll need a really expensive tool, 368 00:24:41,060 --> 00:24:43,180 but doing just a little bit of research 369 00:24:43,180 --> 00:24:44,040 over these devices, 370 00:24:44,320 --> 00:24:46,640 you'll see that the first time you try to 371 00:24:46,640 --> 00:24:48,360 pair this device to your phone, 372 00:24:48,880 --> 00:24:50,500 you will be shown with 373 00:24:50,500 --> 00:24:51,320 a numeric comparison. 374 00:24:51,760 --> 00:24:54,580 Numeric comparison is basically a pairing method 375 00:24:54,580 --> 00:24:56,720 where you show the same 6 digit number 376 00:24:56,720 --> 00:24:57,960 on the device, 377 00:24:58,120 --> 00:25:00,320 on the phone, 378 00:25:00,600 --> 00:25:02,380 and you need to click accept 379 00:25:02,380 --> 00:25:03,120 on those devices. 380 00:25:03,440 --> 00:25:05,020 I don't know if you see what's the problem. 381 00:25:05,360 --> 00:25:07,600 You don't have any screen in those devices. 382 00:25:07,860 --> 00:25:10,380 You have no way to see or to know 383 00:25:10,740 --> 00:25:12,060 what are you pairing to. 384 00:25:12,540 --> 00:25:14,560 So, we tried to do 385 00:25:14,560 --> 00:25:15,520 a man-in-a-mill attack. 386 00:25:16,320 --> 00:25:18,340 Basically, what we created 387 00:25:18,340 --> 00:25:20,760 is just a very simple script 388 00:25:20,760 --> 00:25:22,180 where you use 389 00:25:22,180 --> 00:25:23,500 a single Bluetooth adapter 390 00:25:23,500 --> 00:25:25,980 and basically doing a Bluetooth analysis 391 00:25:25,980 --> 00:25:27,660 over the traffic, we found out that 392 00:25:27,660 --> 00:25:29,900 all the traffic information was sent 393 00:25:29,900 --> 00:25:32,120 over Bluetooth with an SPP protocol, 394 00:25:32,380 --> 00:25:34,000 which is basically serial over Bluetooth. 395 00:25:34,280 --> 00:25:36,820 It's just transmit and send data. 396 00:25:36,980 --> 00:25:37,360 That's it. 397 00:25:37,500 --> 00:25:39,080 You need just one channel. 398 00:25:41,080 --> 00:25:42,740 And we created 399 00:25:42,740 --> 00:25:44,760 a simple script which is trying to listen 400 00:25:44,760 --> 00:25:46,300 based on a regex 401 00:25:46,300 --> 00:25:48,640 to see if there is a device 402 00:25:48,640 --> 00:25:49,580 that is turned on. 403 00:25:49,740 --> 00:25:51,760 Other thing that you need to keep in mind is that 404 00:25:51,760 --> 00:25:54,380 for each transaction, you need to turn on the device 405 00:25:54,380 --> 00:25:56,460 because it turns off itself 406 00:25:56,460 --> 00:25:58,480 after 3, maybe 5 minutes. 407 00:25:58,780 --> 00:26:00,980 So for each transaction, you need to turn it on 408 00:26:00,980 --> 00:26:02,500 and it accepts connection from 409 00:26:02,500 --> 00:26:04,140 pretty much anyone because again, 410 00:26:04,260 --> 00:26:06,780 you don't have any way to pair it correctly 411 00:26:06,780 --> 00:26:08,280 with any other device. 412 00:26:09,000 --> 00:26:09,220 So, 413 00:26:10,740 --> 00:26:12,000 the script, what it does is trying to 414 00:26:12,000 --> 00:26:13,480 start listening in the air, 415 00:26:13,620 --> 00:26:15,200 it just connects as fast as it can to the device 416 00:26:15,200 --> 00:26:17,160 and then it starts emulating the same device 417 00:26:17,160 --> 00:26:19,020 and provides the same SPP protocol. 418 00:26:19,440 --> 00:26:21,920 So, that's the setup. It's pretty simple. 419 00:26:22,100 --> 00:26:24,600 You have on one side the device turned on, 420 00:26:24,700 --> 00:26:26,300 a Raspberry Pi with Python 421 00:26:26,300 --> 00:26:28,480 and then the mobile application 422 00:26:28,480 --> 00:26:29,920 will try to connect automatically 423 00:26:30,380 --> 00:26:31,920 to the device that we are emulating. 424 00:26:32,560 --> 00:26:33,000 So, 425 00:26:41,360 --> 00:26:42,160 this is demo. 426 00:26:43,180 --> 00:26:44,920 This is one digital wallet. 427 00:26:45,660 --> 00:26:46,880 You can see right here 428 00:26:46,880 --> 00:26:48,960 that that's the remote desktop 429 00:26:48,960 --> 00:26:50,260 for the Raspberry Pi. 430 00:26:50,520 --> 00:26:52,340 We start the 431 00:26:52,340 --> 00:26:53,400 money in me attack. 432 00:26:54,080 --> 00:26:55,600 You can see that it's already 433 00:26:56,880 --> 00:26:57,880 saw the device. 434 00:26:58,120 --> 00:27:00,180 It's connected to itself and right now it's emulating 435 00:27:00,180 --> 00:27:00,800 the same device. 436 00:27:01,460 --> 00:27:03,120 So, I just 437 00:27:05,060 --> 00:27:06,560 enter to the mobile application 438 00:27:07,680 --> 00:27:09,000 at the digital wallet. 439 00:27:09,200 --> 00:27:10,560 I go to try to make 440 00:27:10,740 --> 00:27:10,960 payment 441 00:27:12,580 --> 00:27:14,540 and right now those devices 442 00:27:14,540 --> 00:27:15,660 are paid, but 443 00:27:18,920 --> 00:27:19,720 you'll see that 444 00:27:21,260 --> 00:27:22,140 everything works 445 00:27:22,600 --> 00:27:24,560 pretty good. Right now you can see 446 00:27:24,560 --> 00:27:26,160 all the traffic information 447 00:27:26,680 --> 00:27:28,880 between the application, the Raspberry Pi 448 00:27:28,880 --> 00:27:29,560 and the 449 00:27:30,780 --> 00:27:31,440 MPOS device. 450 00:27:32,380 --> 00:27:34,520 Right now I'll try to make a payment and you can see 451 00:27:34,520 --> 00:27:36,660 all the information right from 452 00:27:36,660 --> 00:27:37,640 the air on the money in me attack. 453 00:27:39,640 --> 00:27:40,080 So, 454 00:27:41,520 --> 00:27:42,920 the payment mechanism 455 00:27:42,920 --> 00:27:44,280 doesn't allow you to know 456 00:27:44,280 --> 00:27:46,040 what are you actually paying to. 457 00:27:46,280 --> 00:27:48,440 The device doesn't know where it's paying to 458 00:27:48,440 --> 00:27:50,000 and the mobile application doesn't know. 459 00:27:50,260 --> 00:27:52,280 So, what can we do with this? 460 00:27:54,360 --> 00:27:56,600 With the money in me attack, we can do 461 00:27:56,600 --> 00:27:57,020 basically 462 00:27:57,020 --> 00:28:00,520 we can try to do a 463 00:28:00,520 --> 00:28:01,300 max stripe stealing. 464 00:28:03,620 --> 00:28:04,580 Since the device 465 00:28:04,580 --> 00:28:06,280 is connected from the main one, 466 00:28:06,380 --> 00:28:08,240 you can try to do an over the air update 467 00:28:08,240 --> 00:28:10,520 or an EPEC update 468 00:28:10,740 --> 00:28:11,660 which is the key that itself. 469 00:28:12,140 --> 00:28:13,720 Or you can try to do a 470 00:28:13,720 --> 00:28:16,400 pass which is pretty much the same as Juliana shown 471 00:28:16,400 --> 00:28:18,160 but on Bluetooth level. 472 00:28:18,360 --> 00:28:20,440 You try to force a bad payment, 473 00:28:20,640 --> 00:28:22,380 you try it again, you save 474 00:28:22,380 --> 00:28:23,860 the data from the two 475 00:28:24,840 --> 00:28:26,420 manipulations and you send just one 476 00:28:26,420 --> 00:28:28,380 and the other it's already 477 00:28:28,380 --> 00:28:29,920 valid to make a second payment. 478 00:28:30,460 --> 00:28:31,960 But I wanted to show you 479 00:28:31,960 --> 00:28:34,020 a little big 480 00:28:34,020 --> 00:28:35,400 a little thing of 481 00:28:41,760 --> 00:28:43,060 this is the second 482 00:28:43,060 --> 00:28:44,520 try that we've done 483 00:28:44,520 --> 00:28:45,820 with money in the meal attack. 484 00:28:45,960 --> 00:28:47,380 This is another digital wallet 485 00:28:48,180 --> 00:28:50,780 and we charge just a small payment 486 00:28:52,400 --> 00:28:54,640 and I know you might be able to 487 00:28:54,640 --> 00:28:55,760 see something quite interesting. 488 00:28:59,340 --> 00:28:59,780 Again, 489 00:29:00,840 --> 00:29:01,940 the car owner 490 00:29:01,940 --> 00:29:04,340 and the guys that run the store 491 00:29:04,340 --> 00:29:05,900 doesn't know that this is a money in the meal. 492 00:29:08,700 --> 00:29:10,280 So, right here you can see that 493 00:29:10,740 --> 00:29:11,280 everything is working properly. 494 00:29:11,520 --> 00:29:13,000 I used an NFC payment 495 00:29:14,400 --> 00:29:15,960 and everything is working correctly. 496 00:29:17,020 --> 00:29:18,180 But it's just really different. 497 00:29:18,300 --> 00:29:19,000 I'll try the max type. 498 00:29:19,540 --> 00:29:22,140 And again, this data from the max type 499 00:29:22,140 --> 00:29:23,940 this card is already expired on the wallet 500 00:29:23,940 --> 00:29:26,400 but this information should be ciphered. 501 00:29:26,440 --> 00:29:28,200 There's no way this information is traveling 502 00:29:28,740 --> 00:29:29,420 in plain text. 503 00:29:30,260 --> 00:29:30,700 Right? 504 00:29:41,100 --> 00:29:42,220 So, here's another payment 505 00:29:43,140 --> 00:29:44,360 and you can see right there 506 00:29:45,160 --> 00:29:46,960 this is the plain text 507 00:29:47,780 --> 00:29:48,860 max type information 508 00:29:49,380 --> 00:29:50,120 from the app. 509 00:29:50,240 --> 00:29:52,120 So, basically you can go to any site 510 00:29:58,220 --> 00:29:59,860 you can go to any store 511 00:29:59,860 --> 00:30:02,620 using this solution 512 00:30:02,620 --> 00:30:04,860 sit there and start receiving 513 00:30:04,860 --> 00:30:05,660 critical information. 514 00:30:05,860 --> 00:30:07,180 You can go with this data 515 00:30:07,180 --> 00:30:08,980 and emulate a card with MaxPoof. 516 00:30:10,740 --> 00:30:11,480 So, uh, 517 00:30:11,720 --> 00:30:12,880 moving forward 518 00:30:14,660 --> 00:30:15,180 um 519 00:30:16,460 --> 00:30:17,380 hardware analysis. 520 00:30:17,660 --> 00:30:19,380 We are not hardware hackers, disclaimer. 521 00:30:19,820 --> 00:30:22,380 We're trying to be, but these are the four devices 522 00:30:22,380 --> 00:30:24,500 that are right now available in Argentina. 523 00:30:25,120 --> 00:30:25,960 We talked about 524 00:30:25,960 --> 00:30:27,800 and we saw that 525 00:30:27,800 --> 00:30:30,540 they share the same principles amongst all of them. 526 00:30:30,700 --> 00:30:32,000 You have the smaller ones 527 00:30:32,000 --> 00:30:34,160 which doesn't support NFC 528 00:30:34,160 --> 00:30:36,540 and the bigger one that supports NFC, basically. 529 00:30:37,520 --> 00:30:38,340 So, uh 530 00:30:38,340 --> 00:30:40,600 what are the valuable points? I mean, what kind of 531 00:30:40,740 --> 00:30:41,220 do I get as a 532 00:30:42,220 --> 00:30:44,360 low-level hardware hacker from this? 533 00:30:44,580 --> 00:30:46,580 Well, the first thing that I think is 534 00:30:46,580 --> 00:30:48,540 really interesting to have is the critical information 535 00:30:48,540 --> 00:30:50,080 that is traveling on the devices. 536 00:30:50,520 --> 00:30:52,140 Uh, DMC or 537 00:30:52,140 --> 00:30:53,600 EMB tokens are also 538 00:30:53,600 --> 00:30:56,520 data to make a payment. So, if I get 539 00:30:56,520 --> 00:30:58,580 this information, I could go 540 00:30:58,580 --> 00:30:59,860 make payments. Uh, 541 00:31:00,080 --> 00:31:02,400 the firmware might be really interesting to find 542 00:31:02,400 --> 00:31:03,900 bugs and hack other devices. 543 00:31:04,440 --> 00:31:06,080 The APK, which will 544 00:31:06,080 --> 00:31:08,640 allow me to decipher my own 545 00:31:08,640 --> 00:31:09,580 data and then make 546 00:31:10,740 --> 00:31:12,720 other payments. Or maybe the UART logs 547 00:31:12,720 --> 00:31:14,540 will allow me to see a few 548 00:31:14,540 --> 00:31:16,680 logs that might be 549 00:31:16,680 --> 00:31:18,380 leaking important information. 550 00:31:18,800 --> 00:31:20,500 But, you can see right here 551 00:31:20,500 --> 00:31:21,840 this is really basic. 552 00:31:22,440 --> 00:31:24,620 This is the connectors and things that you might 553 00:31:24,620 --> 00:31:26,560 find in these devices. You have 554 00:31:26,560 --> 00:31:28,520 a Bluetooth connector, an EMB connector, we connect 555 00:31:28,520 --> 00:31:29,760 to the chip, a controller, 556 00:31:30,020 --> 00:31:32,500 a mic stripe, which is pretty much a tape head 557 00:31:32,500 --> 00:31:33,940 connected to an amplifier, 558 00:31:34,780 --> 00:31:36,580 and in the back, well, you can see 559 00:31:36,580 --> 00:31:38,440 the amplifier and the EMB front end 560 00:31:38,440 --> 00:31:40,160 and, of course, the Bluetooth 561 00:31:40,740 --> 00:31:41,760 uh, I don't know if you can see it already. 562 00:31:42,740 --> 00:31:44,460 Uh, but in the bigger devices 563 00:31:44,460 --> 00:31:46,420 you might find, again, Bluetooth, 564 00:31:46,660 --> 00:31:48,700 a microcontroller. Uh, we found out 565 00:31:48,700 --> 00:31:50,440 that this is a flash memory. Uh, we 566 00:31:50,440 --> 00:31:52,760 suspect this, this is where the firmware is stored. 567 00:31:53,140 --> 00:31:54,580 Uh, we have as well 568 00:31:54,580 --> 00:31:56,580 a tape head, a battery controller, and 569 00:31:56,580 --> 00:31:58,640 an EFC front end, of course, to interact 570 00:31:58,640 --> 00:32:00,740 with NFC. So, this is 571 00:32:00,740 --> 00:32:02,540 something, this is a very basic diagram 572 00:32:02,540 --> 00:32:04,680 on what are the main components 573 00:32:04,680 --> 00:32:06,640 that all these devices will have. 574 00:32:06,820 --> 00:32:07,220 So, 575 00:32:08,380 --> 00:32:10,260 we went to, for the long-hanging fruit 576 00:32:10,740 --> 00:32:12,680 and after running 577 00:32:12,680 --> 00:32:14,540 a few analysis stuff, we found 578 00:32:14,540 --> 00:32:16,320 that the device was still working 579 00:32:16,320 --> 00:32:18,720 all open. So, do you have any 580 00:32:18,720 --> 00:32:20,600 anti-tampering measures? And that's a 581 00:32:20,600 --> 00:32:22,640 must. When you have a credit card 582 00:32:22,640 --> 00:32:24,300 or credit card reader or whatever 583 00:32:24,300 --> 00:32:26,740 payment system, you need to have anti-tampering 584 00:32:26,740 --> 00:32:28,560 measures to avoid anyone 585 00:32:28,560 --> 00:32:30,140 to just hook in 586 00:32:30,140 --> 00:32:32,460 the data bus and start stealing information. 587 00:32:32,740 --> 00:32:34,240 Why? Because you have 588 00:32:34,240 --> 00:32:36,700 clear text traffic between each 589 00:32:36,700 --> 00:32:38,480 one of your components. You have the 590 00:32:38,480 --> 00:32:40,620 controller which provides you 591 00:32:40,740 --> 00:32:42,800 with a little bit of cryptography, 592 00:32:43,020 --> 00:32:44,560 but in the meanwhile, 593 00:32:44,660 --> 00:32:46,200 between the data struggling 594 00:32:46,500 --> 00:32:48,740 from the peripheral and the controller 595 00:32:48,740 --> 00:32:50,200 you have clear text traffic. So, 596 00:32:50,320 --> 00:32:52,200 we went for the long-hanging fruit 597 00:32:52,720 --> 00:32:54,340 and we tried to 598 00:32:54,340 --> 00:32:56,540 to get the maximum 599 00:32:56,540 --> 00:32:58,660 information from a simple swipe, which 600 00:32:58,660 --> 00:33:00,380 is pretty much like a common 601 00:33:00,380 --> 00:33:02,180 schema. That's pretty much what it is. 602 00:33:02,700 --> 00:33:04,640 So, um, that's the 603 00:33:04,640 --> 00:33:06,220 that's the amplifier. 604 00:33:06,580 --> 00:33:08,620 It's connected to the tape head and 605 00:33:08,620 --> 00:33:10,380 we connected an oscilloscope to the tape head 606 00:33:10,740 --> 00:33:12,480 and you can see in the left that 607 00:33:12,480 --> 00:33:14,640 you have a waveform, which 608 00:33:14,640 --> 00:33:16,440 is the encoding for the credit card 609 00:33:16,440 --> 00:33:18,220 information from the mic stripe. 610 00:33:19,260 --> 00:33:20,720 And you can see that 611 00:33:20,720 --> 00:33:22,120 the shape is very specific. 612 00:33:22,400 --> 00:33:24,460 So this is what we saw on the oscilloscope. 613 00:33:24,700 --> 00:33:26,000 Pretty much the same shape. 614 00:33:26,280 --> 00:33:28,600 This data is on clear text traffic. 615 00:33:28,920 --> 00:33:30,720 So, we got the 616 00:33:30,720 --> 00:33:32,580 data. We tried to create a 617 00:33:32,580 --> 00:33:34,760 schemer. A schemer will try to get 618 00:33:34,760 --> 00:33:36,480 this data and transmit it over the air 619 00:33:36,480 --> 00:33:38,620 wherever you can. Disclaimer, 620 00:33:38,740 --> 00:33:40,340 this is overkill, of course. 621 00:33:40,740 --> 00:33:42,160 Don't get angry. 622 00:33:42,360 --> 00:33:44,500 There's another way to do this. I'll show you, but 623 00:33:45,400 --> 00:33:46,380 we used 624 00:33:46,960 --> 00:33:48,240 BluePill, which is an Arduino 625 00:33:48,240 --> 00:33:50,440 with a specific chipset that 626 00:33:50,440 --> 00:33:52,420 allowed me to have really high rates 627 00:33:52,420 --> 00:33:54,480 of analog reads over 628 00:33:54,480 --> 00:33:56,720 the data that is being sent 629 00:33:56,720 --> 00:33:58,560 between the tape head and the 630 00:33:58,560 --> 00:34:00,660 controller. And we were sending all 631 00:34:00,660 --> 00:34:02,380 this data on raw data 632 00:34:02,380 --> 00:34:04,440 over the Bluetooth, which is again 633 00:34:04,440 --> 00:34:06,640 overkill. And we were receiving this data 634 00:34:06,640 --> 00:34:08,840 with a Raspberry Pi 635 00:34:08,840 --> 00:34:10,720 connected to a bomber gun. 636 00:34:10,740 --> 00:34:12,700 We just advised that, amongst other 637 00:34:12,700 --> 00:34:14,740 things, allow you to emulate critical information. 638 00:34:15,120 --> 00:34:16,400 So we created a little script 639 00:34:16,400 --> 00:34:17,900 for both these things. 640 00:34:18,420 --> 00:34:20,060 Raspberry Pi will decode the data. 641 00:34:20,220 --> 00:34:22,260 We'll create the specific 642 00:34:22,260 --> 00:34:24,740 data that needs to 643 00:34:24,740 --> 00:34:26,500 be sent to the bomber gun over serial and the 644 00:34:26,500 --> 00:34:28,200 bomber gun will emulate this data. 645 00:34:28,400 --> 00:34:30,520 So, here's the demo. 646 00:34:38,440 --> 00:34:39,600 Here's the test application. 647 00:34:40,740 --> 00:34:42,660 Open device is working right now as it is. 648 00:34:43,120 --> 00:34:43,740 Here's the 649 00:34:44,940 --> 00:34:46,400 hardware input implant 650 00:34:46,400 --> 00:34:47,680 and that's the receiver. 651 00:34:48,120 --> 00:34:49,220 And that's another 652 00:34:49,220 --> 00:34:52,560 critical receiver. Basically to see 653 00:34:52,560 --> 00:34:54,300 that the same information that we have sent 654 00:34:54,300 --> 00:34:56,180 are the same ones that we are emulating. 655 00:34:56,680 --> 00:34:58,680 So right now I'll try to make 656 00:34:58,680 --> 00:34:59,200 a swipe. 657 00:35:00,540 --> 00:35:02,620 And you'll see that all this 658 00:35:02,620 --> 00:35:04,760 information right now has been sent over Bluetooth. 659 00:35:05,620 --> 00:35:06,600 This is all 660 00:35:06,600 --> 00:35:08,040 the data points. 661 00:35:08,300 --> 00:35:09,860 And right now you can see that 662 00:35:10,740 --> 00:35:12,160 right at the bottom, that's the track 2 663 00:35:12,160 --> 00:35:13,280 of the decoded data. 664 00:35:13,780 --> 00:35:15,280 And this data is being sent 665 00:35:16,320 --> 00:35:18,080 to the bomber gun that is in the bottom. 666 00:35:18,200 --> 00:35:19,280 You can not see it right now. 667 00:35:19,500 --> 00:35:21,620 And right now I'm emulating the data and you can see that 668 00:35:21,620 --> 00:35:24,260 pretty much the same. Not pretty much. 669 00:35:24,300 --> 00:35:25,740 The same data, the track 2 670 00:35:25,740 --> 00:35:28,200 that we were able to send over the air. 671 00:35:28,580 --> 00:35:30,140 Again, this is overkill. 672 00:35:30,520 --> 00:35:32,460 This is an easy way to do this. 673 00:35:32,640 --> 00:35:34,340 But this is what worked for us. 674 00:35:34,760 --> 00:35:36,460 And this is just to show you 675 00:35:38,500 --> 00:35:40,520 that the device is still working by 676 00:35:40,740 --> 00:35:42,160 itself. Right now you can see that 677 00:35:42,160 --> 00:35:44,720 the hardware input, again, because we are not 678 00:35:44,720 --> 00:35:46,700 hardware hackers, is creating a lot of noises. 679 00:35:47,800 --> 00:35:48,660 So when I 680 00:35:48,660 --> 00:35:50,100 try to make a payment 681 00:35:50,760 --> 00:35:52,620 of coffee, it will fail. 682 00:35:52,740 --> 00:35:54,700 But if I disconnect the hardware input 683 00:35:54,700 --> 00:35:55,880 you'll see that 684 00:35:55,880 --> 00:35:57,180 everything will work. 685 00:36:00,800 --> 00:36:02,780 I just deconnected the device 686 00:36:02,780 --> 00:36:04,620 and you can see that you're receiving the same 687 00:36:04,620 --> 00:36:06,820 encrypted data. What this device is supposed 688 00:36:06,820 --> 00:36:08,620 to do when it's open, it should wipe 689 00:36:08,620 --> 00:36:10,720 out all the keys and you should be able to 690 00:36:10,740 --> 00:36:11,500 decipher any data. 691 00:36:11,760 --> 00:36:13,760 So this is a big deal because 692 00:36:14,780 --> 00:36:16,040 you don't know if you're paying 693 00:36:16,040 --> 00:36:18,220 even though the network traffic or the Bluetooth 694 00:36:18,220 --> 00:36:20,000 traffic might not be tampered, 695 00:36:20,380 --> 00:36:22,380 you don't know if there is anything embedded 696 00:36:22,380 --> 00:36:22,880 in the device. 697 00:36:25,160 --> 00:36:26,520 So this is what the 698 00:36:26,520 --> 00:36:28,400 schema implant looks like. It's 699 00:36:28,400 --> 00:36:30,280 quite big. It's huge. 700 00:36:31,160 --> 00:36:32,760 The receiver you can see on the left 701 00:36:32,760 --> 00:36:34,340 and you can see the transmitter on the right. 702 00:36:34,600 --> 00:36:36,580 It's pretty big. But we 703 00:36:36,580 --> 00:36:38,100 found out that there's another way to do it. 704 00:36:38,140 --> 00:36:40,380 We used a very simple 433 705 00:36:40,740 --> 00:36:42,040 RF transmitter 706 00:36:42,540 --> 00:36:43,880 connected directly to the 707 00:36:44,640 --> 00:36:46,320 energy input of 708 00:36:46,320 --> 00:36:48,240 the same device and we were 709 00:36:48,240 --> 00:36:50,220 able to make a few 710 00:36:50,620 --> 00:36:52,080 swipes and transmit the same data 711 00:36:52,600 --> 00:36:54,520 to our receiver and 712 00:36:54,520 --> 00:36:56,500 you can see that's quite small. The thing that 713 00:36:56,500 --> 00:36:58,580 we weren't able to decode this data 714 00:36:58,580 --> 00:37:00,560 correctly because there's a lot of noises 715 00:37:00,560 --> 00:37:02,040 and these devices are not 716 00:37:02,040 --> 00:37:04,700 that good at transmitting 717 00:37:07,880 --> 00:37:09,500 nice information over there. 718 00:37:10,740 --> 00:37:12,520 So the last thing that 719 00:37:12,520 --> 00:37:14,520 the last analysis working on 720 00:37:14,520 --> 00:37:16,500 one of those digital wallet companies 721 00:37:16,500 --> 00:37:17,300 we saw that 722 00:37:17,900 --> 00:37:20,340 you should keep in mind that it's a 723 00:37:20,340 --> 00:37:22,260 trust chain between the device 724 00:37:22,260 --> 00:37:24,500 and the backend because since the 725 00:37:24,500 --> 00:37:26,440 same key is being generated on both 726 00:37:26,440 --> 00:37:28,640 ends, all the data is 727 00:37:28,640 --> 00:37:30,600 trusted between each one of the points. 728 00:37:30,700 --> 00:37:30,840 So 729 00:37:32,140 --> 00:37:34,220 in most of digital wallets you have 730 00:37:34,220 --> 00:37:36,440 these fraud prevention 731 00:37:36,440 --> 00:37:38,600 systems where you're trying to make the same 732 00:37:38,600 --> 00:37:40,640 payment over and over and if you 733 00:37:40,740 --> 00:37:42,300 fail three, maybe four times 734 00:37:42,300 --> 00:37:44,120 your critical might be blocked. 735 00:37:44,540 --> 00:37:45,840 So we were seeing that 736 00:37:45,840 --> 00:37:48,560 we heard about 737 00:37:48,560 --> 00:37:50,700 a lot of clients complain about 738 00:37:50,700 --> 00:37:52,680 payments that they never had done 739 00:37:52,680 --> 00:37:54,320 and we were seeing that 740 00:37:54,320 --> 00:37:56,040 there was a lot of 741 00:37:56,640 --> 00:37:58,660 tryout payments for a bigger amount of 742 00:37:58,660 --> 00:38:00,820 money and all failed. 743 00:38:01,120 --> 00:38:02,680 And pretty much 744 00:38:02,680 --> 00:38:04,700 every payment was the same. The data from 745 00:38:04,700 --> 00:38:06,180 the payment, the critical was the same but 746 00:38:06,720 --> 00:38:08,740 they were changing the CVV number which is 747 00:38:08,740 --> 00:38:10,680 a secure number embedded inside the 748 00:38:10,740 --> 00:38:11,620 MAC information. 749 00:38:12,140 --> 00:38:14,440 So we tried to replicate this 750 00:38:14,440 --> 00:38:16,740 to see what the fuck is going on 751 00:38:16,740 --> 00:38:18,700 and we found out that 752 00:38:18,700 --> 00:38:20,400 we created 753 00:38:20,400 --> 00:38:22,060 a MAC spoof. We didn't have the 754 00:38:22,060 --> 00:38:24,640 back then and we tried 755 00:38:24,640 --> 00:38:26,540 to do the same execution. Just 756 00:38:26,540 --> 00:38:28,680 trying to change the CVV number 757 00:38:28,680 --> 00:38:30,880 and we found out that 758 00:38:30,880 --> 00:38:32,580 the application behaved really 759 00:38:32,580 --> 00:38:34,400 differently even though the credit card 760 00:38:34,400 --> 00:38:36,040 was blocked. The 761 00:38:36,040 --> 00:38:38,220 application behaved differently 762 00:38:38,560 --> 00:38:40,720 if the CVV was correct or if it 763 00:38:40,740 --> 00:38:42,860 is not. So if the CVV 764 00:38:42,860 --> 00:38:43,520 was not correct 765 00:38:43,520 --> 00:38:46,560 the application showed you something and if 766 00:38:46,560 --> 00:38:48,540 it was correct it showed you a different thing. 767 00:38:48,760 --> 00:38:50,240 So the 768 00:38:50,740 --> 00:38:52,760 attacker once he get to the right 769 00:38:52,760 --> 00:38:54,140 CVV number he waited 770 00:38:54,480 --> 00:38:56,600 for the client to unlock his card and 771 00:38:56,600 --> 00:38:58,580 then he would go up there and make another 772 00:38:58,580 --> 00:39:00,540 payment. So this is a 773 00:39:00,540 --> 00:39:02,620 problem mostly related to 774 00:39:02,620 --> 00:39:04,740 the trust chain between the devices 775 00:39:04,740 --> 00:39:06,320 and the gray area between 776 00:39:06,320 --> 00:39:08,580 the responsibilities of the 777 00:39:08,580 --> 00:39:10,640 device provider and the credit 778 00:39:10,740 --> 00:39:11,820 and the digital wallet 779 00:39:12,740 --> 00:39:13,480 vendor. 780 00:39:14,560 --> 00:39:16,440 Well, final 781 00:39:16,440 --> 00:39:16,880 thoughts. 782 00:39:19,140 --> 00:39:20,580 Companies should 783 00:39:20,580 --> 00:39:22,740 use encrypted end-to-end 784 00:39:22,740 --> 00:39:24,240 solutions that implements 785 00:39:24,320 --> 00:39:25,120 anti-tampering 786 00:39:25,120 --> 00:39:28,540 measures and 787 00:39:28,540 --> 00:39:30,520 it's important to read 788 00:39:30,520 --> 00:39:32,500 manual to know how to implement 789 00:39:32,500 --> 00:39:33,540 also the 790 00:39:34,540 --> 00:39:36,460 TUKPT standards 791 00:39:36,460 --> 00:39:38,540 in this case. 792 00:39:38,900 --> 00:39:39,860 And 793 00:39:40,740 --> 00:39:42,620 use data should be denied for 794 00:39:42,620 --> 00:39:43,740 no reasons. 795 00:39:44,380 --> 00:39:46,360 And it could be good 796 00:39:46,360 --> 00:39:48,580 if an expiration or 797 00:39:48,580 --> 00:39:50,520 TTL could be added 798 00:39:50,520 --> 00:39:52,420 to this encrypted 799 00:39:52,420 --> 00:39:54,660 card information in order that no one 800 00:39:54,660 --> 00:39:56,360 can reuse it later. 801 00:39:57,160 --> 00:39:58,740 So you have seen 802 00:39:58,740 --> 00:40:00,000 that we can save information 803 00:40:00,000 --> 00:40:01,820 using another opportunity. 804 00:40:02,920 --> 00:40:04,560 Another way to 805 00:40:04,560 --> 00:40:06,700 associate with a signature 806 00:40:06,700 --> 00:40:07,320 or 807 00:40:07,320 --> 00:40:10,160 I don't know, something that 808 00:40:10,740 --> 00:40:12,440 the accounts with the device 809 00:40:12,440 --> 00:40:14,140 and device ID or 810 00:40:14,140 --> 00:40:15,440 the imposed information 811 00:40:16,960 --> 00:40:18,460 and additional things 812 00:40:18,460 --> 00:40:19,360 that you can add. 813 00:40:19,680 --> 00:40:22,220 One thing, we 814 00:40:22,560 --> 00:40:24,420 think that one of the most critical 815 00:40:24,420 --> 00:40:26,280 things is that you can manipulate data. 816 00:40:26,560 --> 00:40:28,260 So as Elena said, we 817 00:40:28,260 --> 00:40:29,620 think that you should 818 00:40:30,480 --> 00:40:32,340 digital sign everything that you're 819 00:40:32,340 --> 00:40:34,240 sending to the back end to make sure that 820 00:40:34,240 --> 00:40:36,140 the client is not manipulating the data. 821 00:40:36,360 --> 00:40:38,520 That's really difficult to do. Sometimes you might 822 00:40:38,520 --> 00:40:40,540 find in Android that you can do pretty much 823 00:40:40,740 --> 00:40:41,740 whatever you want with your application. 824 00:40:43,240 --> 00:40:44,340 On the other hand, 825 00:40:44,400 --> 00:40:46,100 you should have any 826 00:40:46,100 --> 00:40:47,840 auto bounce pairing method. 827 00:40:48,260 --> 00:40:49,620 Because again, these devices 828 00:40:50,460 --> 00:40:52,420 if they intend to be chipped 829 00:40:52,420 --> 00:40:54,400 and you don't want to add a screen, you need to 830 00:40:54,400 --> 00:40:56,460 provide another way to avoid 831 00:40:56,460 --> 00:40:58,780 money in the media attacks. So auto bounce pairing 832 00:40:58,780 --> 00:41:00,740 might work with those devices 833 00:41:00,740 --> 00:41:01,860 because you can pair them 834 00:41:02,540 --> 00:41:03,700 with NFC for example. 835 00:41:04,620 --> 00:41:05,860 So that might work. 836 00:41:05,980 --> 00:41:08,340 And there is no way for me as an attacker 837 00:41:08,340 --> 00:41:09,900 to make a money in the media attack. 838 00:41:10,920 --> 00:41:11,800 As itself. 839 00:41:12,800 --> 00:41:14,140 Or you can add a 840 00:41:14,620 --> 00:41:16,540 screen to the devices just to 841 00:41:16,540 --> 00:41:18,620 be sure that you're paying to the right device. 842 00:41:19,060 --> 00:41:20,020 We think that 843 00:41:20,740 --> 00:41:21,800 this problem is quite 844 00:41:22,560 --> 00:41:24,320 dumb. I mean, it's really easy to 845 00:41:24,320 --> 00:41:25,540 fix it, but 846 00:41:25,540 --> 00:41:28,220 it might be related to the implementation 847 00:41:28,560 --> 00:41:30,580 and the design of the solution by itself. 848 00:41:31,540 --> 00:41:32,500 So these are the 849 00:41:32,500 --> 00:41:34,640 repositories. The money in the media is called 850 00:41:34,640 --> 00:41:35,120 Pretiado. 851 00:41:36,700 --> 00:41:38,000 They post the 852 00:41:38,000 --> 00:41:40,540 hardware implant. Again, we are not 853 00:41:40,740 --> 00:41:42,300 hackers, so sorry if you see 854 00:41:42,300 --> 00:41:43,620 things that you might not like. 855 00:41:43,880 --> 00:41:46,200 And the card injection is the 856 00:41:46,200 --> 00:41:47,340 repository for the 857 00:41:47,940 --> 00:41:48,460 scripts. 858 00:41:49,660 --> 00:41:52,280 And we would like to thank a few friends of ours. 859 00:41:52,540 --> 00:41:54,160 Adriano Perroneo, Marino Marino, 860 00:41:54,280 --> 00:41:55,840 and Joaquin Marilla 861 00:41:55,840 --> 00:41:57,820 for helping us and giving us recommendations 862 00:41:57,820 --> 00:42:00,780 and tips to sort of things. 863 00:42:00,960 --> 00:42:02,480 So thank you. We're open 864 00:42:02,480 --> 00:42:02,920 to questions. 865 00:42:14,180 --> 00:42:15,980 Thank you.