1 00:00:00,590 --> 00:00:05,760 Hi, I'm Trey Cowan, I'm here with Brenda So, and we're security researchers here at Red Balloon Security. 2 00:00:06,000 --> 00:00:15,340 For the past year and a half, we've been working on this ATM, partially as a CTF target, but later as a research project. 3 00:00:16,040 --> 00:00:23,180 So this was something that kind of evolved out of the CTF work that we've done. 4 00:00:23,440 --> 00:00:39,560 So our agenda today, first we're going to talk about this ATM, what's involved in here, what's involved in a normal ATM, then we're going to talk about setting up our own payment processor, what we had to do to get that to work, and then our two vulnerabilities that we discovered. 5 00:00:39,560 --> 00:00:51,720 So the first in the remote management system on this device, and the second in its implementation of the extensions for financial services component, which we'll get more into later. 6 00:00:53,340 --> 00:00:58,960 So one of the things to note here is that, you know, there's been a lot of talk of ATMs in the past. 7 00:00:58,960 --> 00:01:09,880 One of the more famous ones was Barnaby Jack's talk ten years ago, where he demonstrated a bunch of cool things, jackpotting ATMs, installing rootkits. 8 00:01:11,340 --> 00:01:16,780 And you know, we kind of wanted to see how things improved in over a decade. 9 00:01:18,120 --> 00:01:21,560 And yeah, that's one of the ways we got here. 10 00:01:22,560 --> 00:01:30,460 The initial spark was, we were at a conference and accidentally unplugged an ATM as we were setting up our own table. 11 00:01:31,120 --> 00:01:33,940 And notice something funny on the screen when we turned it back on. 12 00:01:34,600 --> 00:01:37,200 This is the startup screen on the ATM. 13 00:01:37,560 --> 00:01:43,500 And you'll see here that this is running Microsoft Windows CE 6.0, which is quite an old version. 14 00:01:44,380 --> 00:01:47,560 And you know, at Red Balloon, we've worked with embedded devices quite a bit. 15 00:01:47,560 --> 00:01:51,160 And so there are people here who know quite a bit about Windows CE. 16 00:01:51,160 --> 00:01:54,300 So we thought it would be an interesting target to start tearing into. 17 00:01:56,420 --> 00:01:59,720 Now you'll see these ATMs all around the city. 18 00:02:00,060 --> 00:02:02,020 Our city is Manhattan. 19 00:02:03,240 --> 00:02:07,700 In things like bodegas, gas stations, street corners, anywhere. 20 00:02:08,160 --> 00:02:09,920 They're a fairly common ATM. 21 00:02:10,780 --> 00:02:14,260 And you know, we thought we may as well get this one. 22 00:02:14,260 --> 00:02:15,540 So we did. 23 00:02:15,540 --> 00:02:17,760 We got our own ATM shipped to our office. 24 00:02:18,480 --> 00:02:22,780 In fact, we're up to, I believe it's five ATMs now. 25 00:02:23,320 --> 00:02:27,680 Three of this larger ATM, this is the Halo 2. 26 00:02:27,680 --> 00:02:34,940 And then two of a smaller ATM that is actually able to go on a flight with some modifications. 27 00:02:35,100 --> 00:02:37,480 So it's easier to take around to conferences. 28 00:02:38,800 --> 00:02:44,240 So one of the things we want to do on our CTF was teach people about, you know, card technologies. 29 00:02:44,240 --> 00:02:49,460 We got people to interface with the EMV chip, magnetic stripes on the card. 30 00:02:50,580 --> 00:03:00,140 And just any way that you can think of to interface with this device in ways that you wouldn't normally be able to interface with something. 31 00:03:00,140 --> 00:03:05,800 So that was cool to be able to, you know, create a ecosystem around that. 32 00:03:06,100 --> 00:03:09,680 So we actually had this at the IoT Village last year. 33 00:03:10,080 --> 00:03:12,400 This is the leaderboard, the final leaderboard. 34 00:03:13,540 --> 00:03:15,180 And those are real cash payouts. 35 00:03:15,180 --> 00:03:17,240 So we paid everyone in $2 bills. 36 00:03:17,520 --> 00:03:19,680 It was quite a fun experience. 37 00:03:21,200 --> 00:03:26,500 So this is the smaller ATM that we took around, the MX4000W. 38 00:03:28,460 --> 00:03:32,540 So it's almost able to be taken on a flight, but not quite. 39 00:03:32,540 --> 00:03:36,080 You have to take out the cash dispenser in order to get it to be underweight. 40 00:03:37,820 --> 00:03:40,860 This is the case we took it in. 41 00:03:41,320 --> 00:03:45,900 There's actually a number of times we've taken it on flights for quite a bit of money. 42 00:03:46,680 --> 00:03:48,800 And also across international borders. 43 00:03:48,800 --> 00:03:56,300 So we took it to Canada one time, which was quite a struggle to get through border security. 44 00:03:57,060 --> 00:04:00,240 And it ended up not being the thing they gave us the hardest time about. 45 00:04:00,240 --> 00:04:04,940 They were more concerned about the T-shirts we were importing into the country to give away. 46 00:04:04,940 --> 00:04:08,440 So we registered as importers. 47 00:04:09,140 --> 00:04:14,500 So there was a lot of people that I want to thank for the work in the CTF that we did. 48 00:04:15,160 --> 00:04:21,740 Alex, Alex, our CEO Ong, Brian, Jatin, James, Rafi, and Tim. 49 00:04:22,780 --> 00:04:26,720 This was a lot of people helping, a big group effort. 50 00:04:26,720 --> 00:04:28,580 So thank you guys for that. 51 00:04:31,170 --> 00:04:36,230 One thing you need to be able to understand about the ATM industry is there's generally two market segments. 52 00:04:36,230 --> 00:04:38,930 The first being retail and the second one financial. 53 00:04:38,930 --> 00:04:51,430 Retail is generally more focused on cost and being appealing to people who just want an ATM on their property to be able to give to their customers, let them get cash out of it. 54 00:04:52,430 --> 00:04:56,050 Just any time you need cash to appear out of thin air. 55 00:04:56,350 --> 00:04:58,150 The second one is financial. 56 00:04:58,150 --> 00:05:03,770 That one's generally more focused on being more secure and more up to date. 57 00:05:03,770 --> 00:05:10,170 Those are much larger ATMs often, and you generally won't find those except in a bank. 58 00:05:10,470 --> 00:05:18,550 Most of these ATMs run Windows, and there's a number of manufacturers, but this is one of the most common ones that we found. 59 00:05:19,870 --> 00:05:21,550 So how does an ATM work? 60 00:05:21,550 --> 00:05:25,210 You insert your card, some magic happens, and then cash comes out. 61 00:05:26,170 --> 00:05:28,310 Well, there's a lot of moving components here. 62 00:05:28,870 --> 00:05:35,890 Firstly, it's a vault with some holes in it, notably the Ethernet cable coming out the back, though not all ATMs have that. 63 00:05:36,850 --> 00:05:38,890 Some actually use a cellular connection. 64 00:05:40,010 --> 00:05:41,630 So this is our ATM. 65 00:05:42,190 --> 00:05:46,410 There's two components to it, two compartments. 66 00:05:46,650 --> 00:05:54,090 The top section, which is a little bit lower security in terms of the lock, and the bottom section, which actually contains the cash. 67 00:05:55,270 --> 00:06:07,810 The top section, you'll see, has the receipt printer, card reader, pin pad, and also the main CPU and any network connections in it. 68 00:06:07,810 --> 00:06:14,250 The bottom component has the cash dispenser, which works with the cassettes. 69 00:06:14,250 --> 00:06:21,010 So the cassettes will actually hold all of the cash, and the cash dispenser obviously dispenses that. 70 00:06:21,010 --> 00:06:23,710 So there's two separate sections there. 71 00:06:24,610 --> 00:06:35,110 And in fact, the key for the top section, as Barnaby Jack mentioned 10 years ago, all the keys for the tops of the ATMs are the same. 72 00:06:35,110 --> 00:06:49,170 So you can't trivially get to the bottom of the ATM where the vault is, because there's different keys there, and then there's also an electronic lock, which has a numeric code. 73 00:06:49,170 --> 00:06:55,470 However, the top section only has a key that's commonly available. 74 00:06:55,470 --> 00:07:08,310 So when we originally got the ATM, one of the problems we had was our intern actually locked the key inside of the ATM, which is possible to do, because this thing automatically latches when it's closed. 75 00:07:08,310 --> 00:07:23,250 So we went and actually 3D printed a key that we used in the top of the ATM, because all the keys are the same, and we were able to open it, retrieve the real key, and continue on our way. 76 00:07:25,070 --> 00:07:27,550 Again, most of these devices run Windows. 77 00:07:27,550 --> 00:07:34,470 This one specifically runs Windows CE 6, which is quite old in terms of operating systems. 78 00:07:35,410 --> 00:07:39,030 This was released before Barnaby Jack's talk. 79 00:07:39,030 --> 00:07:46,650 There's a lot of modern protections missing from it that you would expect in a device that literally holds thousands of dollars. 80 00:07:49,490 --> 00:07:55,110 So when we opened up the ATM, we were greeted with this main circuit board. 81 00:07:55,570 --> 00:08:04,110 It has an HDMI, USB, Ethernet, and interestingly, a dial-up connection, so you can hook this up to a phone line and set things up that way. 82 00:08:04,550 --> 00:08:07,750 And then connections to the cash dispenser and receipt printer. 83 00:08:08,710 --> 00:08:16,030 So immediately looking at it, there's HDMI and USB, so can we just hook up a monitor and keyboard and get something going with it? 84 00:08:16,390 --> 00:08:20,230 Well, unfortunately, there's no Explorer shell that pops up with this. 85 00:08:20,650 --> 00:08:25,110 It's all in this kiosk mode application, winatm.exe. 86 00:08:25,410 --> 00:08:31,170 So our initial attempts to interface with it through a keyboard actually completely failed. 87 00:08:31,510 --> 00:08:33,530 The keyboard didn't work at all. 88 00:08:33,870 --> 00:08:36,050 Even caps lock didn't work. 89 00:08:36,050 --> 00:08:51,650 And the reason that that would happen is there's actually no driver for the keyboard built into this operating system image, which is actually very smart, because there's no situation really where you'd need a keyboard on this device. 90 00:08:51,810 --> 00:08:54,510 The pinpad is not treated as a keyboard. 91 00:08:54,510 --> 00:09:02,810 It's all about reducing the attack surface area there, so you can't just hook up a USB rubber ducky and run some bad scripts. 92 00:09:04,130 --> 00:09:13,390 So I'm going to hand it off to Brenda now to talk about, since we couldn't interface with it through a keyboard, what we actually did to work with this device initially. 93 00:09:16,240 --> 00:09:17,020 All right. 94 00:09:17,020 --> 00:09:24,100 So on the main port, we found these very suspicious pads, and on the back, around the same location, there are these resistor pads. 95 00:09:24,100 --> 00:09:27,280 So we suspect that this might be JTAG. 96 00:09:27,380 --> 00:09:28,760 And it turns out it is. 97 00:09:28,760 --> 00:09:31,300 It is a standard 10-pin ARM connector. 98 00:09:31,300 --> 00:09:35,140 We do need to solder some pull-up, pull-down resistors on the back. 99 00:09:35,140 --> 00:09:44,400 But after we do that, we're able to connect it with JTAGulator, identify it as JTAG, and use a JTAG debugger afterwards to interface with the ATM. 100 00:09:44,920 --> 00:09:46,260 So that's good. 101 00:09:46,380 --> 00:09:50,980 The next step is to dump the flash in order to get the firmware from the ATM. 102 00:09:50,980 --> 00:09:53,920 Now, on the ATM, the firmware is stored on the NAND flash. 103 00:09:53,920 --> 00:09:58,560 As you can see inside the little red box, it's 48 pins and a service mount. 104 00:09:58,560 --> 00:10:01,300 So it's pretty painful to rip out from the board. 105 00:10:01,300 --> 00:10:08,880 But we did desolder it at one point, and we used the SuperPro, which is a flash reader-writer, to read and write to the flash. 106 00:10:09,000 --> 00:10:12,200 We did it a couple of times, but eventually the board died. 107 00:10:12,300 --> 00:10:19,620 The board just can't handle that many times of soldering and desoldering, and we did rip out some pin pads, and we cannot recover it afterwards. 108 00:10:20,260 --> 00:10:22,020 So at that point, we're kind of panicking, right? 109 00:10:22,020 --> 00:10:23,860 Do we need to buy a new ATM? 110 00:10:24,040 --> 00:10:32,720 No, not really, because we found out that we can just go online and buy the main board at $400 a pop at atmpartmark.com. 111 00:10:32,720 --> 00:10:39,600 So we bought a few main boards, and they did work, but we don't want them to break again. 112 00:10:39,700 --> 00:10:42,900 So this time, second try, let's be more resourceful. 113 00:10:42,900 --> 00:10:46,660 We think maybe there is someone who did some reverse engineering and put them online. 114 00:10:46,660 --> 00:10:51,660 Maybe the firmware is already online packaged nicely, but it could also be behind some paywall. 115 00:10:51,660 --> 00:10:52,700 We don't know. 116 00:10:52,820 --> 00:10:57,420 But with enough Googling, we found out that the firmware is actually publicly available. 117 00:10:57,500 --> 00:11:01,020 Now, Trey mentioned the two versions of ATM that we got. 118 00:11:01,020 --> 00:11:04,460 It turns out that they both share the same firmware update. 119 00:11:04,460 --> 00:11:08,800 So we only need to download it once, and we start looking at it. 120 00:11:08,800 --> 00:11:11,260 So in the firmware update, there are three main files. 121 00:11:11,260 --> 00:11:21,680 The bootloader, nk.bin, which is where the kernel and other kernel libraries are stored, and most importantly, a master.zip file, where all the application binaries are. 122 00:11:21,680 --> 00:11:32,180 This is where the ATM executable is, it's where the libraries that the executable uses are, and it's where all the audio files, the JPEG that is used by the ATM are. 123 00:11:33,080 --> 00:11:35,060 And we look at the application binary. 124 00:11:35,060 --> 00:11:41,060 The exported entry in the application binary still has their names on it. 125 00:11:41,060 --> 00:11:46,120 So from a reverse engineer's perspective, it gets pretty easy to figure out what each function does. 126 00:11:46,120 --> 00:11:53,440 So for instance, if you want to figure out the dispense money functionality, you just find a function that is called dispense. 127 00:11:53,440 --> 00:12:00,320 Or if you want to figure out how the receipt printer works, you find another function called printReceipt. 128 00:12:00,380 --> 00:12:02,720 So that's a win for us, right? 129 00:12:02,720 --> 00:12:07,420 So with this firmware update, we tried our first firmware modification attempt. 130 00:12:07,420 --> 00:12:13,780 We didn't do anything fancy, we just tried to change the please wait while loading screen to please wait while pwning. 131 00:12:13,780 --> 00:12:18,120 However, when we changed that one character, we got stuck on the boot up screen. 132 00:12:18,580 --> 00:12:20,120 Now why does that happen? 133 00:12:20,120 --> 00:12:26,580 That's because in this firmware update, the manufacturer enabled Microsoft code signing. 134 00:12:26,600 --> 00:12:31,200 It is used to ensure that the software has not been corrupted by third parties. 135 00:12:31,200 --> 00:12:37,800 And in our case, our application binary is assigned with a certificate that is named MX5300CE. 136 00:12:38,260 --> 00:12:45,040 Now, at that point, we don't really know where the certificate is, and we don't really know how the verification process works. 137 00:12:45,040 --> 00:12:50,240 So in order to figure out the digital signature, we have two ways to do it. 138 00:12:51,500 --> 00:13:04,280 Either we take the time, reverse engineer the code signing algorithm, create our own certificate, resign everything, or we just find where the certificate verification function is and return true. 139 00:13:04,780 --> 00:13:10,260 So in order to do that, we need to take a deeper dive into how the kernel files and the kernel is structured. 140 00:13:10,900 --> 00:13:15,980 As mentioned before, there is this file called nk.bin where the kernel is. 141 00:13:15,980 --> 00:13:24,480 So that file is packaged in something called a bin.fs format, and within a bin.fs format, there are these records. 142 00:13:25,100 --> 00:13:29,560 In one of the records, that's where the kernel and the libraries are. 143 00:13:31,020 --> 00:13:36,980 We took out the record, and we started trying to figure out how that binary works. 144 00:13:37,020 --> 00:13:40,020 In that binary, there is the Windows CE header. 145 00:13:40,020 --> 00:13:40,940 It's pretty standard. 146 00:13:40,940 --> 00:13:51,060 You have your magic byte, you have your start address, and more importantly, there's a pointer to the ROM HDR structure inside a binary. 147 00:13:51,060 --> 00:13:54,320 This structure has some very interesting information. 148 00:13:54,780 --> 00:14:02,040 It has the physical start address, it has the physical end address, number of files, but more importantly, it also points us to the module entries. 149 00:14:02,620 --> 00:14:10,660 With that table of contents, with the ROM HDR structure, we figure out where nk.exe, which is the kernel, is. 150 00:14:10,660 --> 00:14:17,240 We figure out where the library is inside the binary, and we're able to parse out the kernel and the libraries. 151 00:14:17,240 --> 00:14:21,620 We use a tool called eimgfs to extract the files. 152 00:14:21,620 --> 00:14:33,180 And we figure out that although the application binaries are signed, since in this version of Windows CE, the kernel is used to verify the application binary, the kernel itself is not signed. 153 00:14:33,320 --> 00:14:38,920 We found a file called filesys.dll, which checks for certificate verification. 154 00:14:39,280 --> 00:14:44,200 Now, this is part of the control flow graph of the certificate verification function. 155 00:14:44,200 --> 00:14:48,320 We figured that out because there's a string, literally, that says, search verify. 156 00:14:48,640 --> 00:14:56,840 And as we're analyzing the control flow graph, we realize that every successful operation would return a number 4 to the caller. 157 00:14:57,620 --> 00:14:58,820 So, here's what we do. 158 00:14:58,820 --> 00:15:07,180 Instead of returning an error code on other paths, we just modify to always move the number 4 to r0, which is the return register in ARM. 159 00:15:08,060 --> 00:15:14,560 And after we patch filesys.dll, we package the whole thing, we successfully bypass signature verification. 160 00:15:14,980 --> 00:15:20,340 And from then on, we're able to modify our firmware and add our own custom code to the ATM. 161 00:15:21,080 --> 00:15:25,780 So, here's a video of the ATM having custom code on it. 162 00:15:25,780 --> 00:15:34,800 As you can see, we press a button and we printed out a small receipt, like a portrait of the ATM, so we think it's kind of cheeky. 163 00:15:34,800 --> 00:15:36,140 So, that's why we did it. 164 00:15:36,380 --> 00:15:37,480 So, that's good, right? 165 00:15:37,480 --> 00:15:43,800 We got firmware modification working, but now it really has to work as an ATM. 166 00:15:43,960 --> 00:15:47,200 And throughout this process, we found some very interesting stuff, right? 167 00:15:47,200 --> 00:15:50,460 So, firstly, this is a very old device. 168 00:15:50,460 --> 00:15:51,740 It's a pretty slow device. 169 00:15:51,740 --> 00:15:53,900 And each update takes around 20 minutes. 170 00:15:53,900 --> 00:15:58,840 We have to sit there and babysit the ATM as it's updating and manually punching the settings. 171 00:15:58,980 --> 00:16:01,620 We also found a lot of peculiar commands. 172 00:16:01,620 --> 00:16:10,060 So, for instance, within 5 seconds of the loading screen, if you hit clear, left, right, clear, clear, cancel, you can clear the settings on the NVRAM. 173 00:16:10,340 --> 00:16:19,440 Or if you hit enter, clear, cancel, 1, 2, 3, it would bring you to a password prompt, which brings you to the operator screen where you can change the settings on the ATM. 174 00:16:20,560 --> 00:16:22,740 So, we figured out the firmware update process. 175 00:16:22,920 --> 00:16:23,880 We're pretty good now, right? 176 00:16:23,880 --> 00:16:25,120 We have JTAG. 177 00:16:25,120 --> 00:16:28,420 We have the firmware itself with some debugging symbols. 178 00:16:28,560 --> 00:16:31,980 We have an understanding of how the firmware update process works. 179 00:16:31,980 --> 00:16:35,280 We are able to modify, add, and remove executables. 180 00:16:35,760 --> 00:16:37,060 One last hurdle. 181 00:16:37,060 --> 00:16:39,760 It keeps on getting stuck on the whole screen. 182 00:16:39,760 --> 00:16:42,080 Like, we got stuck on this screen for a while trying to connect something. 183 00:16:42,080 --> 00:16:44,140 What is it trying to connect to exactly? 184 00:16:44,820 --> 00:16:52,640 So, we did some digging, and it turns out that the ATM is actually trying to connect to a service called the payment processor. 185 00:16:52,960 --> 00:16:55,620 Now, there are these big card networks that issue a card to you. 186 00:16:55,620 --> 00:16:59,460 So, for instance, it could be your MasterCard or Amex or Visa. 187 00:16:59,460 --> 00:17:08,820 And when you put in your debit card into the ATM and try to draw money out, there is a middleman called the payment processor that would help the ATM connect to these card networks. 188 00:17:08,880 --> 00:17:15,180 So, there are different kinds of protocol for communication between the ATM and the payment processor. 189 00:17:15,180 --> 00:17:18,360 But the one that we looked at is called the Triton Protocol. 190 00:17:19,300 --> 00:17:23,280 Now, the Triton Protocol is a request-response communication protocol. 191 00:17:23,280 --> 00:17:30,480 There are four different types of communication pairs, but the most common ones are the configuration pair and the transaction pair. 192 00:17:30,540 --> 00:17:32,920 We did find the documentation online. 193 00:17:32,980 --> 00:17:38,660 However, it is a preliminary specification, and it is very out of date, so some of the information is wrong. 194 00:17:38,660 --> 00:17:42,880 And we needed to use Wireshark to figure out the correct request-response format. 195 00:17:43,300 --> 00:17:44,380 So, this is how it works, right? 196 00:17:44,380 --> 00:17:48,880 When you first boot up the ATM, it tries to connect to this payment processor. 197 00:17:48,880 --> 00:17:59,980 And the payment processor, once it receives a request, it sends back a response having some important information in it, such as the surcharge amount that it is going to take on the ATM. 198 00:18:00,540 --> 00:18:07,720 And for subsequent transactions, it would send a balance inquiry or withdrawal transaction code. 199 00:18:07,720 --> 00:18:15,140 So, the ATM would send a packet to the payment processor, having the card number, encrypted PIN, withdrawal balance if you are withdrawing money. 200 00:18:15,140 --> 00:18:26,460 The payment processor takes that packet, talks to the network, talks to different card networks, and returns whether you can successfully withdraw money or not with a success-slash-error code. 201 00:18:26,840 --> 00:18:29,680 So, you might think, this information is pretty important, right? 202 00:18:29,680 --> 00:18:31,720 So, is that information encrypted? 203 00:18:31,720 --> 00:18:33,560 And the answer is yes. 204 00:18:33,560 --> 00:18:36,140 It is encrypted with SSL or TLS. 205 00:18:36,140 --> 00:18:44,260 However, this is an option, which means that operators can actually opt out not to use encryption for Triton traffic. 206 00:18:44,260 --> 00:18:47,500 However, the PIN numbers do have an extra layer of protection. 207 00:18:47,760 --> 00:18:51,280 And most use triple DES for encryption. 208 00:18:51,900 --> 00:18:53,220 It is pretty standard triple DES. 209 00:18:53,220 --> 00:18:55,900 It uses two keys, K1 and K2. 210 00:18:55,900 --> 00:18:59,760 So, the PIN would be enclosed in its own padding. 211 00:18:59,760 --> 00:19:04,700 The ATM encrypts it, sends it to the server, so the server would decipher it. 212 00:19:06,240 --> 00:19:08,380 So, triple DES is a block cipher. 213 00:19:08,380 --> 00:19:10,120 It is a shared key protocol. 214 00:19:10,160 --> 00:19:12,260 And the setup is actually pretty interesting, right? 215 00:19:12,260 --> 00:19:18,980 So, when a technician comes to your store or restaurant to set up the ATM, it would punch in two keys. 216 00:19:18,980 --> 00:19:22,140 And these two keys are XORed together to form a master key. 217 00:19:22,320 --> 00:19:27,520 Now, the server also has knowledge of this key, but it is not the final keys used to encrypt the PIN. 218 00:19:27,920 --> 00:19:29,300 So, this is how it happens. 219 00:19:29,300 --> 00:19:35,560 Once the technician punches in the key, both the ATM and the payment processor would have a copy of the master key. 220 00:19:36,320 --> 00:19:39,940 The ATM would tell the payment processor, hey, I'm using triple DES. 221 00:19:40,780 --> 00:19:51,500 The payment processor would acknowledge it and encrypt two other keys, which is the final K1 and K2, with the master key, and send the encrypted pair of keys back to the ATM. 222 00:19:51,780 --> 00:20:00,180 The ATM decrypts K1 and K2 with the master key, and those two keys would be used to encrypt your PIN number. 223 00:20:00,460 --> 00:20:14,720 So, when someone enters their PIN on the ATM, the PIN is encrypted with K1 and K2, and that encrypted PIN gets sent over, and the payment processor would decrypt it with K1 and K2. 224 00:20:15,500 --> 00:20:28,940 So, after we understand the Trident Protocol, how the PIN encryption scheme works, we wrote a server, a Trident Protocol server, put it on a Raspberry Pi, and connect it to the ATM, and the ATM is finally functional. 225 00:20:38,970 --> 00:20:46,710 So, one of the first things you want to do on a device like this that's hooked up to a network is to see what surface area it exposes in terms of open ports. 226 00:20:48,150 --> 00:20:49,870 So, that's what we did. 227 00:20:49,870 --> 00:20:53,030 We actually found eight open ports on this device initially. 228 00:20:53,230 --> 00:21:03,870 The first two are the Windows CE web server, the default web server that's built into all Windows CE images, if that option's enabled, running on this device. 229 00:21:03,910 --> 00:21:10,510 When you actually pull it up, it's just the default web page that gets returned. 230 00:21:10,510 --> 00:21:17,970 So, likely this was something that just wasn't removed from the image as it was being built. 231 00:21:19,630 --> 00:21:24,690 Interesting aside is that you'll find a lot of Windows CE devices on the Internet. 232 00:21:26,690 --> 00:21:44,930 There's a couple of queries you can run to look that up, but especially something as old as Windows CE 6.0 on the public Internet would be a concern, ATMs, I haven't seen many, if any, ATMs on the public Internet. 233 00:21:45,450 --> 00:21:47,150 Mostly other devices. 234 00:21:48,690 --> 00:22:01,870 So, this second port, or I guess third port that we found here, the 5555, was a bit puzzling at first, but we realized it was the remote management system default listening port. 235 00:22:01,870 --> 00:22:11,030 So, that's something that you use to update the ATM, to administrate it, to check balances, that sort of deal. 236 00:22:11,530 --> 00:22:13,270 So, that's what that port was. 237 00:22:13,710 --> 00:22:15,950 And then we had these last five ports here. 238 00:22:15,950 --> 00:22:20,930 So, these were ones that we didn't quite know, ones that we weren't able to figure out easily. 239 00:22:22,110 --> 00:22:35,770 So, we tried connecting to them, but for quite a while we just weren't able to get any results from it, or send any data and have it be acknowledged. 240 00:22:36,710 --> 00:22:44,670 So, we'll come back to that in a bit, but first I'm going to hand it off to Brenda to talk a little bit more about RMS and what remote management system does. 241 00:22:46,810 --> 00:22:49,010 All right, so what is RMS? 242 00:22:49,010 --> 00:22:54,550 So, RMS stands for Remote Monitoring System Service, Remote Management System Service. 243 00:22:54,650 --> 00:23:00,390 However you want to call it, it is a service that lets customers control the collection of ATM remotely. 244 00:23:00,530 --> 00:23:09,310 So, the customer can use this service to update the firmware on a bunch of ATMs, check the amount of money left, download the transaction history from the ATM. 245 00:23:09,790 --> 00:23:14,630 Now, this is an optional service, meaning that users can enable or disable it. 246 00:23:14,630 --> 00:23:20,630 The default port for RMS is 5555, which corresponds to Trey's port scan. 247 00:23:21,990 --> 00:23:28,510 So, in RMS it uses the ATM's ID and the custom password for verification. 248 00:23:29,530 --> 00:23:34,690 So, when we were reverse engineering it, we realized there was close to no documentation on RMS. 249 00:23:34,730 --> 00:23:42,930 So, at the end we needed to use a combination of Wireshark, Ghidra, and AIDA to figure out a communication protocol, and the process took around two weeks. 250 00:23:42,930 --> 00:23:45,930 But we eventually got it, right? 251 00:23:45,930 --> 00:23:51,810 So, the RMS packet is pretty standard, you know, you have a start by a terminal, but there's like an LLC at the end. 252 00:23:51,810 --> 00:24:01,270 The more interesting part is like the encoded data, where that part is actually obfuscated with an extra table hard-coded in the binary. 253 00:24:02,490 --> 00:24:05,970 And this is actually not the first time someone looked into RMS. 254 00:24:05,970 --> 00:24:12,190 In fact, in Barnaby Jack's talk in 2010, he jackpotted an ATM via a vulnerability in RMS. 255 00:24:12,190 --> 00:24:18,670 And since then, and we looked at his report, it turns out that the RMS packet structure is still the same. 256 00:24:18,710 --> 00:24:21,210 Obfuscation techniques didn't really change. 257 00:24:21,650 --> 00:24:29,590 And in his talk, he found out that a malformed packet can lead to authentication bypass and eventual firmware modification. 258 00:24:30,150 --> 00:24:33,430 So, the service should be secure now, right? 259 00:24:33,730 --> 00:24:35,290 Well, let's put it to the test. 260 00:24:35,290 --> 00:24:42,070 We want to use a fuzzer to fuzz it, but we don't want to set up memory or emulate some Windows CE functions. 261 00:24:42,070 --> 00:24:45,250 So, we used BooFuzz, which is a network fuzzer. 262 00:24:45,290 --> 00:24:55,070 It takes a lot of heavy work out of it, so we only needed to define the protocol in code, and BooFuzz would take it, test different inputs, and do the rest. 263 00:24:55,590 --> 00:24:58,250 So, we did get around five to six crashes. 264 00:24:58,290 --> 00:25:09,390 And when we're analyzing the crashes, we see that every time when we send a really large packet, so any packet more than 10 kilobytes, the device would crash and reboot. 265 00:25:09,390 --> 00:25:15,190 Interestingly, this happens regardless of whatever password or ID you send to the device. 266 00:25:15,590 --> 00:25:24,770 And with JTAG, we figured out that a crash happened in this function called RMSProcessTCP in the library that controls the RMS communication. 267 00:25:25,530 --> 00:25:29,770 So, let's take a deeper dive into this function and how it works. 268 00:25:29,930 --> 00:25:44,090 So, at first, the function accepts any incoming connections via TCP, receives the packet, decrypts it with the XOR table, verifies the ID and the password, parses the command, closes the connection. 269 00:25:44,350 --> 00:25:50,850 And the problem happened at this stage, where it received the RMS packet and decrypts it with the XOR table. 270 00:25:51,450 --> 00:25:54,250 So, what exactly went wrong? 271 00:25:54,290 --> 00:25:57,690 Well, it turns out it's basically a buffer overflow. 272 00:25:57,690 --> 00:26:05,150 In the function that received the RMS packet, it copies the TCP packet over to a global buffer without any bounce check. 273 00:26:05,550 --> 00:26:11,730 And what it did is that this eventually overrides a function point it has called when the application exits. 274 00:26:11,950 --> 00:26:16,290 And this copy happens before any kind of terminal ID or password verification. 275 00:26:16,710 --> 00:26:28,670 So, the consequence is, as long as you understand the packet structure, as long as your packet structure is sound, the buffer overflow could happen, and you can write shellcode in your packet to lead to arbitrary code execution. 276 00:26:29,930 --> 00:26:32,010 Now, what can the attacker do? 277 00:26:32,010 --> 00:26:40,470 We were investigating it, and we realized that most DLLs are paged out as the application exits, except for the functions that control the NVRAM. 278 00:26:40,610 --> 00:26:47,530 And in this device, in this ATM, NVRAM is pretty important because it basically controls anything on the admin screen. 279 00:26:47,530 --> 00:26:50,250 It stores all the settings on the ATM. 280 00:26:52,210 --> 00:27:02,450 So, for instance, an attacker can point the ATM to the malicious server because within the NVRAM, it stores the IP of the payment processor. 281 00:27:02,450 --> 00:27:04,970 You can change the denomination of the ATM. 282 00:27:04,970 --> 00:27:13,370 So, for instance, if your ATM is supposed to have $20 bills, you can change the denomination to $1 bills in order to extract more money from the ATM. 283 00:27:13,670 --> 00:27:18,970 And let's go to a demo of the RMS vulnerability. 284 00:27:20,030 --> 00:27:22,510 All right, so we have our ATM here. 285 00:27:22,510 --> 00:27:26,570 It has RMS running on the background. 286 00:27:26,650 --> 00:27:31,890 So, now Trey is going to send a packet over to the ATM. 287 00:27:31,950 --> 00:27:35,610 And as you see here, it says remote monitoring system is in progress. 288 00:27:35,650 --> 00:27:39,870 Trey sends a malformed packet over, but it still looks fine here, right? 289 00:27:40,050 --> 00:27:44,510 So, now let's say I'm the operator, and I need to perform a firmware update. 290 00:27:44,510 --> 00:27:52,750 So, I will do and declare cancel 1, 2, 3 in order to go into a password prompt. 291 00:27:52,850 --> 00:27:56,050 And then I put the operator password in. 292 00:27:56,270 --> 00:27:58,750 That brings me to an administration screen. 293 00:27:58,750 --> 00:28:00,610 You can change a bunch of stuff here. 294 00:28:00,610 --> 00:28:08,010 But right now, since I'm doing a firmware update, I'll go into system setup, system control, software update. 295 00:28:08,010 --> 00:28:10,510 Yes, I want to do a software update. 296 00:28:10,630 --> 00:28:13,830 So, this is where the shellcode gets executed, right? 297 00:28:13,830 --> 00:28:24,130 Because as the application exists cleanly, the function pointer that we overwrote would be called, and that would execute our shellcode. 298 00:28:25,590 --> 00:28:30,670 In this specific demo, we set the shellcode so that it would point... 299 00:28:30,670 --> 00:28:42,830 instead of pointing to the Raspberry Pi with the Triton protocol running, it would point back to Trey's laptop, which has the Triton server running. 300 00:28:43,970 --> 00:28:44,490 Right . 301 00:28:44,630 --> 00:28:51,770 So, as you see here, it just updated successfully, and we needed to wait a few seconds to reboot. 302 00:28:52,030 --> 00:28:54,430 Once again, this device is pretty slow. 303 00:28:54,430 --> 00:29:03,090 As you can see here, it's going to take a while for it to go past the boot screen and go back into normal operation again. 304 00:29:03,090 --> 00:29:10,490 So, one interesting thing to note is that as we're writing the shellcode, we need to figure out where the functions are. 305 00:29:10,630 --> 00:29:21,910 And as Trey said, since this is a pretty old device, it's a pretty old version of Windows CE, a lot of the modern protections against... a lot of modern protections and binaries are implemented. 306 00:29:21,910 --> 00:29:27,670 So, for instance, we don't see any ASR implemented in the binary through JTAG. 307 00:29:27,670 --> 00:29:46,330 So, what we're able to do is that once we use JTAG to figure out where all the libraries are in one boot process, the next time we rebooted those libraries, the executables would be loaded back into the same location, which makes the process of writing shellcode easier. 308 00:29:47,070 --> 00:29:57,210 And as I mentioned before, the shellcode would point the ATM to Trey's computer, and how it does is modify some settings on the NVRAM. 309 00:29:57,210 --> 00:30:00,630 The NVRAM controls all the settings, right? 310 00:30:00,630 --> 00:30:02,950 It controls whether SSL is turned on or off. 311 00:30:02,950 --> 00:30:07,390 It controls where the ATM is pointing to. 312 00:30:07,490 --> 00:30:11,490 And it's also a pretty simple function to reverse engineer. 313 00:30:11,490 --> 00:30:18,350 It takes two numbers, and each pair of numbers would point to, for instance, whether SSL is turned on or not. 314 00:30:18,350 --> 00:30:26,010 It would point to the IP string of the payment processor host. 315 00:30:26,810 --> 00:30:30,650 So, as you see here, now it's initializing. 316 00:30:30,970 --> 00:30:31,990 It takes a while. 317 00:30:31,990 --> 00:30:35,690 It's loading, and it's trying to interface with the peripherals. 318 00:30:36,470 --> 00:30:39,510 It prints out a receipt whenever it reboots, right? 319 00:30:39,510 --> 00:30:47,890 So, it's just saying, oh, test printing, okay, and it prints out a version of the printer within the ATM. 320 00:30:51,230 --> 00:30:53,530 It takes a while to initialize. 321 00:30:53,530 --> 00:31:08,510 But after initializing, you would see that instead of pointing to the payment processor on the Raspberry Pi, it would point to the Triton server that Trey is running on his computer. 322 00:31:09,170 --> 00:31:10,610 It makes a lot of noises, right? 323 00:31:10,790 --> 00:31:12,170 It's trying to print something. 324 00:31:12,170 --> 00:31:14,950 It's trying to make sure the cache dispenser works. 325 00:31:15,650 --> 00:31:18,210 All right, now it's trying to connect to the host. 326 00:31:18,210 --> 00:31:26,270 And as you can see on Trey's computer, our malicious payment processor is working. 327 00:31:26,270 --> 00:31:27,690 It's interfacing with the ATM. 328 00:31:28,130 --> 00:31:30,290 So, I have a card here. 329 00:31:30,490 --> 00:31:33,430 It's one of the cards that we printed in-house at Red Balloon. 330 00:31:33,590 --> 00:31:35,250 So, it has track 2. 331 00:31:35,250 --> 00:31:41,270 So, it has tracks here, and track 2 is where the interesting information is stored, is where your card number is stored, in fact. 332 00:31:41,490 --> 00:31:44,850 So, let's say I'm a customer, and I wanted to check my balance. 333 00:31:47,750 --> 00:31:50,150 It takes a while. 334 00:31:50,650 --> 00:31:52,650 I hit English. 335 00:31:53,110 --> 00:31:54,490 It asks me to enter a PIN, right? 336 00:31:54,490 --> 00:31:55,910 It can be anything. 337 00:31:56,950 --> 00:31:57,910 Enter. 338 00:31:58,510 --> 00:32:02,050 And let's say I want to inquire my balance on the ATM. 339 00:32:03,710 --> 00:32:06,530 Let's say I want to check my checking. 340 00:32:06,530 --> 00:32:08,330 No receipt, thank you. 341 00:32:08,550 --> 00:32:14,630 And it is connecting to the host, although it says an ineligible account on Trey's computer. 342 00:32:14,630 --> 00:32:20,610 So , you can actually see the expiration date of the card and the card number itself. 343 00:32:22,710 --> 00:32:23,610 All right. 344 00:32:23,830 --> 00:32:24,930 Back to you, Trey. 345 00:32:33,160 --> 00:32:33,680 Cool. 346 00:32:33,680 --> 00:32:35,280 So, we just saw the RMS demo. 347 00:32:35,660 --> 00:32:49,540 And now I want to talk a little bit more about interacting with this device and what we had to do to actually get things to work on it, since we didn't have a keyboard or any HRD device to really interface with it. 348 00:32:49,540 --> 00:32:53,400 So, we kind of had to actually take a look at this. 349 00:32:53,400 --> 00:32:56,440 So , there's an ActiveSync, probably, port on here. 350 00:32:56,440 --> 00:32:58,280 But we couldn't quite get that working. 351 00:32:59,040 --> 00:33:06,180 ActiveSync is the way you would work with Windows CE devices to interface with them on a desktop computer. 352 00:33:06,400 --> 00:33:11,800 But we couldn't get that working, so we actually compiled our own tool. 353 00:33:12,440 --> 00:33:13,500 This is Windows CE. 354 00:33:13,500 --> 00:33:14,860 It's a standard platform. 355 00:33:14,860 --> 00:33:20,480 How difficult should it be to be able to just compile something to work on it? 356 00:33:21,580 --> 00:33:24,080 Well, the caveat here is that it's Windows CE 6.0. 357 00:33:24,080 --> 00:33:27,540 So, this was released in 2006, initially. 358 00:33:28,140 --> 00:33:33,620 So, we actually had to go all the way back to Visual Studio 2008 to get this really going. 359 00:33:34,900 --> 00:33:39,800 It's quite an old IDE, but we knew it worked well under Windows XP. 360 00:33:39,800 --> 00:33:50,740 So, what we were able to do with this IDE was actually build some C-sharp applications, get them to run on the .NET Framework, which is actually on this device. 361 00:33:50,740 --> 00:33:53,160 It has a .NET Compact Framework on here. 362 00:33:54,560 --> 00:34:07,020 However, it's fairly old, so a lot of examples for C-sharp code, if you're not incredibly familiar with it initially, you can't just copy-paste off of Stack Overflow to get things working on here. 363 00:34:08,220 --> 00:34:10,260 A lot of useful features are missing. 364 00:34:10,480 --> 00:34:14,600 But, in the end, we did get an application working on here. 365 00:34:14,820 --> 00:34:23,680 So, we really wanted an application for our CTF to be able to have a web server that people could connect to, to interface with the ATM. 366 00:34:25,080 --> 00:34:26,440 So, this was the start of that. 367 00:34:26,440 --> 00:34:29,120 We actually popped a dialog box here. 368 00:34:31,340 --> 00:34:39,820 And, you know, we could have used the built-in web server on this device that you saw in the port scan earlier. 369 00:34:39,820 --> 00:34:46,780 However, there wasn't any DLL or any capabilities for any sort of dynamic content or scripting. 370 00:34:46,900 --> 00:34:49,700 So, that would have been a bit difficult to actually get up and running. 371 00:34:49,700 --> 00:34:59,500 So, instead, we created our own web server, which was difficult in its own right, because HTTP primitives aren't in the .NET version we're using. 372 00:34:59,500 --> 00:35:04,140 So, we had to build things on top of just straight TCP sockets. 373 00:35:04,140 --> 00:35:11,540 But , with some good examples, we fast-forwarded a bit and had a web server working, which is what you see here. 374 00:35:11,980 --> 00:35:15,580 So, this is our test setup. 375 00:35:15,580 --> 00:35:24,760 This is a device emulator running the .NET code and displaying our CTF web page there. 376 00:35:26,940 --> 00:35:30,800 So, for launching on Startup, there's a number of ways we could have gone about this. 377 00:35:30,800 --> 00:35:41,280 But, again, we didn't quite have any way to interface with the ATM at this point, since we are trying to compile our own tool. 378 00:35:41,660 --> 00:36:02,280 So, in order to be able to launch that tool, to be able to probe how the device works, we actually used the debugger every single time we wanted to run it, and hijacked the startup process, the call and create process, and pointed that towards our custom server. 379 00:36:02,920 --> 00:36:09,640 So, we could reverse the startup procedure and do the proper way through registry edits, which can be a bit difficult on Windows CE. 380 00:36:09,640 --> 00:36:36,340 But, what we ended up doing was actually just taking the executable that was on here, that would normally be launched, called winatm.exe, renamed it to something else, and then named our own executable winatm.exe, and then launched the original process that would normally be launched as a child process of our server. 381 00:36:37,720 --> 00:36:45,560 So, we've got this C-sharp code running, it's all good, but what would it take to get some native code running? 382 00:36:45,560 --> 00:36:47,480 So , let's actually dig into it here. 383 00:36:49,940 --> 00:37:00,800 What we ended up needing to do was use Visual Studio 2005, going even further back, and install a number of different packages to actually get this to work. 384 00:37:02,040 --> 00:37:20,300 It was quite a pain, but in the end it was actually quite worth it, because in one of the most amazing Microsoft things I've ever seen, you can click through a wizard and, from scratch, build an OS image, which is a pretty amazing concept. 385 00:37:20,300 --> 00:37:28,320 You're clicking little checkboxes to enable or disable different features, and change how things are built into it. 386 00:37:28,800 --> 00:37:38,360 So, from that we were able to actually see different DLLs that would normally be on the ATM, like the keyboard driver and things like that. 387 00:37:39,600 --> 00:37:44,860 But by this point, we had already gotten our web server up and running. 388 00:37:45,440 --> 00:38:02,570 We've got it launching every boot, and so we built all these commands to be able to interface with the device, check out what processes we're running, how to remove registry keys, how to remove files, any sort of thing we'd need to really dig in and research it, 389 00:38:02,880 --> 00:38:05,520 and have fun diversion while we did it. 390 00:38:05,520 --> 00:38:12,560 So, this was actually... we found a build of Doom for this device, and we actually got it up and working here. 391 00:38:12,560 --> 00:38:19,260 This was an Easter egg in some of our earlier CTF challenges to be able to find this. 392 00:38:21,400 --> 00:38:30,160 But it ended up... I'm not sure if it was eating up all the memory, but the system would just randomly reboot partway through after Doom had been launched. 393 00:38:30,160 --> 00:38:37,960 So, we had to remove that for further CTF challenges, but it was fun to get it up and running while we had it. 394 00:38:37,960 --> 00:38:43,680 And despite being a fairly slower and older ARM core, we were able to run this. 395 00:38:46,000 --> 00:38:56,760 So, one of the things we did next was take a look at the registry, see how things were configured, and look for any clues of things that might be interesting on this device. 396 00:38:57,360 --> 00:39:12,100 So, one of the things that we initially found that was kind of familiar were some of these keys, and you might take a look at them and recognize those numbers from some of the ports that were open earlier. 397 00:39:13,280 --> 00:39:30,840 And even more interesting, if you take a look at the key name, it's a little concerning, because you start to think, maybe this cache dispenser is somehow related to this open port on 8004. 398 00:39:31,140 --> 00:39:32,920 So, what is this? 399 00:39:32,920 --> 00:39:34,520 What are we taking a look at here? 400 00:39:34,520 --> 00:39:35,780 Well, here's a hint. 401 00:39:36,160 --> 00:39:38,520 XFS is what this is. 402 00:39:39,060 --> 00:39:42,640 Not the file system, the money one. 403 00:39:42,740 --> 00:40:05,400 And XFS is this standard platform for financial devices that exposes this sort of middleware, where you can have a Windows application send a command that gets passed through these layers of abstraction, and go to the service provider, the service provider being the thing that actually is able to interface directly with the devices. 404 00:40:05,800 --> 00:40:16,860 So, this allows you to build things in sort of Lego's fashion, so you can swap out different components of your system, theoretically. 405 00:40:17,440 --> 00:40:24,400 You know, swap out different cache dispensers, swap out different card readers, and there are all these standard different devices that you can put on here. 406 00:40:25,460 --> 00:40:35,620 So, you'll see the cache dispenser, you'll see the ID card unit, which is reading your card, pin pad, things of that nature are all in here. 407 00:40:37,060 --> 00:40:38,560 So, what is XFS? 408 00:40:38,560 --> 00:40:39,860 Where does this come from? 409 00:40:40,040 --> 00:40:47,040 It started out as a Microsoft thing, where they wanted to create the standard platform for Windows for financial devices. 410 00:40:47,680 --> 00:40:59,120 They seem to have really succeeded, because this is, you know, kind of one of the industry standards for how you would set up an ATM or any other financial device. 411 00:41:00,020 --> 00:41:16,260 And so, Microsoft handed it off to SIN, the European Committee for Standardization, who is actually the maintainers of the standard now, and you can go on their website and find all of these documents detailing how devices are hooked up in XFS. 412 00:41:17,140 --> 00:41:25,520 So, for example, this is the cache dispenser device description document here. 413 00:41:25,660 --> 00:41:28,360 So, this is great for people building these devices. 414 00:41:28,360 --> 00:41:59,980 It creates a fairly open ecosystem that allows manufacturers to be able to swap out different things and have that, which also causes an issue in terms that it's a fairly homogenous platform that allows people with very little understanding of ATMs to actually be able to create some fairly portable malware to be able to use on these different devices. 415 00:42:00,200 --> 00:42:07,420 That takes advantage of the XFS interface, and we've seen a number of different pieces of malware that use this. 416 00:42:08,620 --> 00:42:12,880 So, going back to the ports, again, this is something XFS-related. 417 00:42:13,300 --> 00:42:20,940 So, we see those numbers there, and what I did was go through and map out. 418 00:42:21,640 --> 00:42:33,940 You can see that after logical services, there's auxiliaries, card reader, cache dispenser, and then there's also the device class, which is what XFS would call that device. 419 00:42:33,940 --> 00:42:38,500 IDC and CDM for the cache dispenser. 420 00:42:38,700 --> 00:42:47,980 And created this mapping showing which registry key corresponds to which device class, which corresponds to which port. 421 00:42:48,860 --> 00:42:57,940 So, you can see here again that this is, you know, the device classes are the standard XFS designations for these types of devices. 422 00:42:58,820 --> 00:43:01,200 So, what does this tell us? 423 00:43:02,200 --> 00:43:03,520 There's open ports. 424 00:43:03,740 --> 00:43:05,720 They're related to XFS somehow. 425 00:43:06,900 --> 00:43:09,900 Can we make it dump out some money? 426 00:43:11,060 --> 00:43:16,240 Well, the problem again is, you know, we can connect to these ports, but we can't get anything out of them. 427 00:43:16,240 --> 00:43:19,260 We don't see any traffic, and we don't know what to send into them. 428 00:43:19,760 --> 00:43:20,920 So, let's sniff it. 429 00:43:20,920 --> 00:43:39,760 You know, let's see if there's anything on these ports, even on the local network interface on here, that's listening and sending messages to see if we can take that and use it to build our own messages or replay them. 430 00:43:39,760 --> 00:43:52,460 The problem here being that this is a Windows CE device, and you can't just download Wireshark for Windows CE because, as this very helpfully points out, there is no Wireshark for Windows CE. 431 00:43:53,980 --> 00:44:08,320 So, Windows CE does have packet capture capabilities, but it's not built into this ATM image, and I didn't really want to take the time to try and figure out how to port it to this ATM image. 432 00:44:08,320 --> 00:44:11,660 So, the easiest way to do this ended up being JTAG. 433 00:44:12,460 --> 00:44:31,780 And the way, the plan of attack here was to intercept the socket create calls, get the handles for them, and then map those handles to the different services, intercept socket sending receive calls, and look at the buffers, and save all that traffic, and then acquire some cutlets. 434 00:44:31,780 --> 00:44:50,360 So, what we did was went through, found where these registry strings were being read, and from that we were able to figure out which socket creation call corresponded to which different device class. 435 00:44:50,900 --> 00:45:09,080 And here you'll see that this is where we're hooking the send and receive functions in Winsock to be able to look at the buffer and take the data that is either being sent or the data that has been received, save that to a file, and take a look at it. 436 00:45:09,080 --> 00:45:15,380 So, this is all in Ladderbock, this is a JTAG debugger that we use, and it's great for scripting like this. 437 00:45:16,620 --> 00:45:19,980 So, as you can see here, we have a number of packets that came in. 438 00:45:19,980 --> 00:45:21,920 Some of these are send, some of these are received. 439 00:45:21,920 --> 00:45:27,640 So, it's just a bunch of binary blobs, and there's not very much that we can easily recognize in there. 440 00:45:27,940 --> 00:45:34,780 There is the US dollars string in the packet in the lower right, but it's nothing immediately obvious. 441 00:45:34,780 --> 00:45:39,240 So, first thing we tried was, can we just replay one of these packets? 442 00:45:39,660 --> 00:45:50,140 Because we know, we were doing actions on the ATM as we were capturing these packets, so we can roughly correlate what might have been sent to the cache dispenser to cause it to dispense cache. 443 00:45:51,080 --> 00:45:59,080 So, yes, we can just replay and send out some cache from the cache dispenser. 444 00:45:59,080 --> 00:46:05,860 It was actually fairly straightforward to be able to do that, and then you can see we dumped out some cache here. 445 00:46:07,040 --> 00:46:14,100 It was no need to learn how all the structure works, no need to learn how to work with these fields. 446 00:46:14,100 --> 00:46:22,360 You can literally just take this packet that you've seen, replay it to dispense cache, and that was fairly straightforward. 447 00:46:23,660 --> 00:46:33,500 So, that worked in the case where we just wanted to dispense the same amount of cache, but what if we wanted to dispense as much cache as possible over and over? 448 00:46:33,940 --> 00:46:50,080 Well, after looking at this dump for a while, we were able to figure out some patterns and see the structures in there, especially after looking at the XFS documentation, and we created some scripts that allowed us to parse these packets and then see what was in there. 449 00:46:50,080 --> 00:46:59,880 So, for example, here we have a packet where it's the result of reading card that's been put in the ATM. 450 00:46:59,880 --> 00:47:06,180 So you can see the card number there is 555555555555555555555555. 451 00:47:06,180 --> 00:47:07,980 That's the track 2 data. 452 00:47:10,560 --> 00:47:18,020 And we have these fields here that might not be immediately obvious, this command code, notably. 453 00:47:18,220 --> 00:47:28,360 So if you look in the XFS documentation, you can see that there is this concept of a device class, or service class, and then a service offset. 454 00:47:28,360 --> 00:47:35,660 So the service class being 2, that's multiplied with 100 to get the service offsets, which is 200. 455 00:47:36,720 --> 00:47:42,420 And then all of the commands are some offset from that base number. 456 00:47:42,420 --> 00:47:54,080 So 207 is this specific command for idcard read raw data, which corresponds to what we saw here, which is 207, which is hex cf. 457 00:47:54,320 --> 00:47:57,640 You can see the result of that read raw data there. 458 00:47:59,060 --> 00:48:11,000 So we modified this to work with the structure for the cache dispenser packet and, you know, pumped up the amount of cache that we're dispensing. 459 00:48:11,340 --> 00:48:21,140 And yeah, we were able to run that and we can actually run any XFS command on this device if we send it to the appropriate port. 460 00:48:21,140 --> 00:48:31,440 So kind of in retrospect here, you know, pro tip, if you're using TCP sockets for IPC, don't listen on 0.0.0.0. 461 00:48:31,540 --> 00:48:38,140 And if you're creating a networked device, at least do a port scan before you ship it. 462 00:48:39,340 --> 00:48:46,680 So we want to run through the XFS demo here and show you this machine spitting out some cache. 463 00:48:48,840 --> 00:48:49,420 Cool. 464 00:48:49,420 --> 00:48:50,820 So we have the ATM here. 465 00:48:50,820 --> 00:48:53,520 And I'm going to run the script we wrote for XFS. 466 00:48:53,520 --> 00:48:59,040 And you should see that the command is being injected directly into the XFS middleware. 467 00:48:59,040 --> 00:49:02,180 So none of this will actually show that cache is being dispensed. 468 00:49:02,740 --> 00:49:05,880 So if I run the command, 469 00:49:12,660 --> 00:49:14,680 it's going to dump out some cache. 470 00:49:15,540 --> 00:49:17,620 So this is just going to continually happen. 471 00:49:17,620 --> 00:49:20,620 It's going to keep dumping out $2 bills over and over again. 472 00:49:21,140 --> 00:49:26,640 And yeah, this is the result of a computer just being on the same network. 473 00:49:26,640 --> 00:49:34,900 You know, you can grab the Ethernet cable behind it and send a single packet to the ATM and it will dump out a load of cache. 474 00:49:43,030 --> 00:49:43,470 All right. 475 00:49:43,470 --> 00:49:45,250 Thank you for coming to our talk. 476 00:49:45,250 --> 00:49:48,490 And be sure to join us in our Q&A afterwards.