[00:00.590 --> 00:04.580]  Hi, I'm Trey Cowan, I'm here with Brenda So, and we're security researchers here at Red
[00:04.580 --> 00:05.760]  Balloon Security.
[00:06.000 --> 00:13.300]  For the past year and a half, we've been working on this ATM, partially as a CTF target, but
[00:13.300 --> 00:15.340]  later as a research project.
[00:16.040 --> 00:23.180]  So this was something that kind of evolved out of the CTF work that we've done.
[00:23.440 --> 00:28.760]  So our agenda today, first we're going to talk about this ATM, what's involved in here,
[00:28.760 --> 00:33.860]  what's involved in a normal ATM, then we're going to talk about setting up our own payment
[00:33.860 --> 00:38.860]  processor, what we had to do to get that to work, and then our two vulnerabilities that
[00:38.860 --> 00:39.560]  we discovered.
[00:39.560 --> 00:44.660]  So the first in the remote management system on this device, and the second in its implementation
[00:44.660 --> 00:51.720]  of the extensions for financial services component, which we'll get more into later.
[00:53.340 --> 00:57.840]  So one of the things to note here is that, you know, there's been a lot of talk of ATMs
[00:57.840 --> 00:58.960]  in the past.
[00:58.960 --> 01:05.180]  One of the more famous ones was Barnaby Jack's talk ten years ago, where he demonstrated
[01:05.800 --> 01:09.880]  a bunch of cool things, jackpotting ATMs, installing rootkits.
[01:11.340 --> 01:16.780]  And you know, we kind of wanted to see how things improved in over a decade.
[01:18.120 --> 01:21.560]  And yeah, that's one of the ways we got here.
[01:22.560 --> 01:29.100]  The initial spark was, we were at a conference and accidentally unplugged an ATM as we were
[01:29.100 --> 01:30.460]  setting up our own table.
[01:31.120 --> 01:33.940]  And notice something funny on the screen when we turned it back on.
[01:34.600 --> 01:37.200]  This is the startup screen on the ATM.
[01:37.560 --> 01:43.500]  And you'll see here that this is running Microsoft Windows CE 6.0, which is quite an old version.
[01:44.380 --> 01:47.560]  And you know, at Red Balloon, we've worked with embedded devices quite a bit.
[01:47.560 --> 01:51.160]  And so there are people here who know quite a bit about Windows CE.
[01:51.160 --> 01:54.300]  So we thought it would be an interesting target to start tearing into.
[01:56.420 --> 01:59.720]  Now you'll see these ATMs all around the city.
[02:00.060 --> 02:02.020]  Our city is Manhattan.
[02:03.240 --> 02:07.700]  In things like bodegas, gas stations, street corners, anywhere.
[02:08.160 --> 02:09.920]  They're a fairly common ATM.
[02:10.780 --> 02:14.260]  And you know, we thought we may as well get this one.
[02:14.260 --> 02:15.540]  So we did.
[02:15.540 --> 02:17.760]  We got our own ATM shipped to our office.
[02:18.480 --> 02:22.780]  In fact, we're up to, I believe it's five ATMs now.
[02:23.320 --> 02:27.680]  Three of this larger ATM, this is the Halo 2.
[02:27.680 --> 02:34.940]  And then two of a smaller ATM that is actually able to go on a flight with some modifications.
[02:35.100 --> 02:37.480]  So it's easier to take around to conferences.
[02:38.800 --> 02:44.240]  So one of the things we want to do on our CTF was teach people about, you know, card technologies.
[02:44.240 --> 02:49.460]  We got people to interface with the EMV chip, magnetic stripes on the card.
[02:50.580 --> 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.
[03:00.140 --> 03:05.800]  So that was cool to be able to, you know, create a ecosystem around that.
[03:06.100 --> 03:09.680]  So we actually had this at the IoT Village last year.
[03:10.080 --> 03:12.400]  This is the leaderboard, the final leaderboard.
[03:13.540 --> 03:15.180]  And those are real cash payouts.
[03:15.180 --> 03:17.240]  So we paid everyone in $2 bills.
[03:17.520 --> 03:19.680]  It was quite a fun experience.
[03:21.200 --> 03:26.500]  So this is the smaller ATM that we took around, the MX4000W.
[03:28.460 --> 03:32.540]  So it's almost able to be taken on a flight, but not quite.
[03:32.540 --> 03:36.080]  You have to take out the cash dispenser in order to get it to be underweight.
[03:37.820 --> 03:40.860]  This is the case we took it in.
[03:41.320 --> 03:45.900]  There's actually a number of times we've taken it on flights for quite a bit of money.
[03:46.680 --> 03:48.800]  And also across international borders.
[03:48.800 --> 03:56.300]  So we took it to Canada one time, which was quite a struggle to get through border security.
[03:57.060 --> 04:00.240]  And it ended up not being the thing they gave us the hardest time about.
[04:00.240 --> 04:04.940]  They were more concerned about the T-shirts we were importing into the country to give away.
[04:04.940 --> 04:08.440]  So we registered as importers.
[04:09.140 --> 04:14.500]  So there was a lot of people that I want to thank for the work in the CTF that we did.
[04:15.160 --> 04:21.740]  Alex, Alex, our CEO Ong, Brian, Jatin, James, Rafi, and Tim.
[04:22.780 --> 04:26.720]  This was a lot of people helping, a big group effort.
[04:26.720 --> 04:28.580]  So thank you guys for that.
[04:31.170 --> 04:36.230]  One thing you need to be able to understand about the ATM industry is there's generally two market segments.
[04:36.230 --> 04:38.930]  The first being retail and the second one financial.
[04:38.930 --> 04:46.110]  Retail is generally more focused on cost and being appealing to people who just want an ATM on their property
[04:46.110 --> 04:51.430]  to be able to give to their customers, let them get cash out of it.
[04:52.430 --> 04:56.050]  Just any time you need cash to appear out of thin air.
[04:56.350 --> 04:58.150]  The second one is financial.
[04:58.150 --> 05:03.770]  That one's generally more focused on being more secure and more up to date.
[05:03.770 --> 05:10.170]  Those are much larger ATMs often, and you generally won't find those except in a bank.
[05:10.470 --> 05:15.890]  Most of these ATMs run Windows, and there's a number of manufacturers,
[05:15.890 --> 05:18.550]  but this is one of the most common ones that we found.
[05:19.870 --> 05:21.550]  So how does an ATM work?
[05:21.550 --> 05:25.210]  You insert your card, some magic happens, and then cash comes out.
[05:26.170 --> 05:28.310]  Well, there's a lot of moving components here.
[05:28.870 --> 05:34.070]  Firstly, it's a vault with some holes in it, notably the Ethernet cable coming out the back,
[05:34.070 --> 05:35.890]  though not all ATMs have that.
[05:36.850 --> 05:38.890]  Some actually use a cellular connection.
[05:40.010 --> 05:41.630]  So this is our ATM.
[05:42.190 --> 05:46.410]  There's two components to it, two compartments.
[05:46.650 --> 05:51.330]  The top section, which is a little bit lower security in terms of the lock,
[05:51.330 --> 05:54.090]  and the bottom section, which actually contains the cash.
[05:55.270 --> 06:02.170]  The top section, you'll see, has the receipt printer, card reader, pin pad,
[06:02.170 --> 06:07.810]  and also the main CPU and any network connections in it.
[06:07.810 --> 06:14.250]  The bottom component has the cash dispenser, which works with the cassettes.
[06:14.250 --> 06:21.010]  So the cassettes will actually hold all of the cash, and the cash dispenser obviously dispenses that.
[06:21.010 --> 06:23.710]  So there's two separate sections there.
[06:24.610 --> 06:31.470]  And in fact, the key for the top section, as Barnaby Jack mentioned 10 years ago,
[06:32.350 --> 06:35.110]  all the keys for the tops of the ATMs are the same.
[06:35.110 --> 06:40.990]  So you can't trivially get to the bottom of the ATM where the vault is,
[06:40.990 --> 06:49.170]  because there's different keys there, and then there's also an electronic lock, which has a numeric code.
[06:49.170 --> 06:55.470]  However, the top section only has a key that's commonly available.
[06:55.470 --> 07:03.870]  So when we originally got the ATM, one of the problems we had was our intern actually locked the key inside of the ATM,
[07:03.870 --> 07:08.310]  which is possible to do, because this thing automatically latches when it's closed.
[07:08.310 --> 07:15.390]  So we went and actually 3D printed a key that we used in the top of the ATM,
[07:15.950 --> 07:23.250]  because all the keys are the same, and we were able to open it, retrieve the real key, and continue on our way.
[07:25.070 --> 07:27.550]  Again, most of these devices run Windows.
[07:27.550 --> 07:34.470]  This one specifically runs Windows CE 6, which is quite old in terms of operating systems.
[07:35.410 --> 07:39.030]  This was released before Barnaby Jack's talk.
[07:39.030 --> 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.
[07:49.490 --> 07:55.110]  So when we opened up the ATM, we were greeted with this main circuit board.
[07:55.570 --> 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.
[08:04.550 --> 08:07.750]  And then connections to the cash dispenser and receipt printer.
[08:08.710 --> 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?
[08:16.390 --> 08:20.230]  Well, unfortunately, there's no Explorer shell that pops up with this.
[08:20.650 --> 08:25.110]  It's all in this kiosk mode application, winatm.exe.
[08:25.410 --> 08:31.170]  So our initial attempts to interface with it through a keyboard actually completely failed.
[08:31.510 --> 08:33.530]  The keyboard didn't work at all.
[08:33.870 --> 08:36.050]  Even caps lock didn't work.
[08:36.050 --> 08:43.690]  And the reason that that would happen is there's actually no driver for the keyboard built into this operating system image,
[08:43.690 --> 08:51.650]  which is actually very smart, because there's no situation really where you'd need a keyboard on this device.
[08:51.810 --> 08:58.770]  The pinpad is not treated as a keyboard. It's all about reducing the attack surface area there,
[08:58.770 --> 09:02.810]  so you can't just hook up a USB rubber ducky and run some bad scripts.
[09:04.130 --> 09:09.890]  So I'm going to hand it off to Brenda now to talk about, since we couldn't interface with it through a keyboard,
[09:09.890 --> 09:13.390]  what we actually did to work with this device initially.
[09:16.240 --> 09:20.880]  All right. So on the main port, we found these very suspicious pads,
[09:20.880 --> 09:24.100]  and on the back, around the same location, there are these resistor pads.
[09:24.100 --> 09:27.280]  So we suspect that this might be JTAG.
[09:27.380 --> 09:31.300]  And it turns out it is. It is a standard 10-pin ARM connector.
[09:31.300 --> 09:35.140]  We do need to solder some pull-up, pull-down resistors on the back.
[09:35.140 --> 09:39.720]  But after we do that, we're able to connect it with JTAGulator, identify it as JTAG,
[09:39.720 --> 09:44.400]  and use a JTAG debugger afterwards to interface with the ATM.
[09:44.920 --> 09:50.980]  So that's good. The next step is to dump the flash in order to get the firmware from the ATM.
[09:50.980 --> 09:53.920]  Now, on the ATM, the firmware is stored on the NAND flash.
[09:53.920 --> 09:58.560]  As you can see inside the little red box, it's 48 pins and a service mount.
[09:58.560 --> 10:01.300]  So it's pretty painful to rip out from the board.
[10:01.300 --> 10:05.000]  But we did desolder it at one point, and we used the SuperPro,
[10:05.000 --> 10:08.880]  which is a flash reader-writer, to read and write to the flash.
[10:09.000 --> 10:12.200]  We did it a couple of times, but eventually the board died.
[10:12.300 --> 10:15.400]  The board just can't handle that many times of soldering and desoldering,
[10:15.400 --> 10:19.620]  and we did rip out some pin pads, and we cannot recover it afterwards.
[10:20.260 --> 10:22.020]  So at that point, we're kind of panicking, right?
[10:22.020 --> 10:23.860]  Do we need to buy a new ATM?
[10:24.040 --> 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.
[10:32.720 --> 10:39.600]  So we bought a few main boards, and they did work, but we don't want them to break again.
[10:39.700 --> 10:42.900]  So this time, second try, let's be more resourceful.
[10:42.900 --> 10:46.660]  We think maybe there is someone who did some reverse engineering and put them online.
[10:46.660 --> 10:51.660]  Maybe the firmware is already online packaged nicely, but it could also be behind some paywall.
[10:51.660 --> 10:52.700]  We don't know.
[10:52.820 --> 10:57.420]  But with enough Googling, we found out that the firmware is actually publicly available.
[10:57.500 --> 11:01.020]  Now, Trey mentioned the two versions of ATM that we got.
[11:01.020 --> 11:04.460]  It turns out that they both share the same firmware update.
[11:04.460 --> 11:08.800]  So we only need to download it once, and we start looking at it.
[11:08.800 --> 11:11.260]  So in the firmware update, there are three main files.
[11:11.260 --> 11:16.360]  The bootloader, nk.bin, which is where the kernel and other kernel libraries are stored,
[11:16.360 --> 11:21.680]  and most importantly, a master.zip file, where all the application binaries are.
[11:21.680 --> 11:27.060]  This is where the ATM executable is, it's where the libraries that the executable uses are,
[11:27.060 --> 11:32.180]  and it's where all the audio files, the JPEG that is used by the ATM are.
[11:33.080 --> 11:35.060]  And we look at the application binary.
[11:35.060 --> 11:41.060]  The exported entry in the application binary still has their names on it.
[11:41.060 --> 11:46.120]  So from a reverse engineer's perspective, it gets pretty easy to figure out what each function does.
[11:46.120 --> 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.
[11:53.440 --> 12:00.320]  Or if you want to figure out how the receipt printer works, you find another function called printReceipt.
[12:00.380 --> 12:02.720]  So that's a win for us, right?
[12:02.720 --> 12:07.420]  So with this firmware update, we tried our first firmware modification attempt.
[12:07.420 --> 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.
[12:13.780 --> 12:18.120]  However, when we changed that one character, we got stuck on the boot up screen.
[12:18.580 --> 12:20.120]  Now why does that happen?
[12:20.120 --> 12:26.580]  That's because in this firmware update, the manufacturer enabled Microsoft code signing.
[12:26.600 --> 12:31.200]  It is used to ensure that the software has not been corrupted by third parties.
[12:31.200 --> 12:37.800]  And in our case, our application binary is assigned with a certificate that is named MX5300CE.
[12:38.260 --> 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.
[12:45.040 --> 12:50.240]  So in order to figure out the digital signature, we have two ways to do it.
[12:51.500 --> 12:58.840]  Either we take the time, reverse engineer the code signing algorithm, create our own certificate, resign everything,
[12:58.840 --> 13:04.280]  or we just find where the certificate verification function is and return true.
[13:04.780 --> 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.
[13:10.900 --> 13:15.980]  As mentioned before, there is this file called nk.bin where the kernel is.
[13:15.980 --> 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.
[13:25.100 --> 13:29.560]  In one of the records, that's where the kernel and the libraries are.
[13:31.020 --> 13:36.980]  We took out the record, and we started trying to figure out how that binary works.
[13:37.020 --> 13:40.940]  In that binary, there is the Windows CE header. It's pretty standard.
[13:40.940 --> 13:45.500]  You have your magic byte, you have your start address, and more importantly,
[13:46.920 --> 13:51.060]  there's a pointer to the ROM HDR structure inside a binary.
[13:51.060 --> 13:54.320]  This structure has some very interesting information.
[13:54.780 --> 13:58.480]  It has the physical start address, it has the physical end address, number of files,
[13:58.480 --> 14:02.040]  but more importantly, it also points us to the module entries.
[14:02.620 --> 14:10.660]  With that table of contents, with the ROM HDR structure, we figure out where nk.exe, which is the kernel, is.
[14:10.660 --> 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.
[14:17.240 --> 14:21.620]  We use a tool called eimgfs to extract the files.
[14:21.620 --> 14:25.760]  And we figure out that although the application binaries are signed,
[14:25.760 --> 14:30.520]  since in this version of Windows CE, the kernel is used to verify the application binary,
[14:30.520 --> 14:33.180]  the kernel itself is not signed.
[14:33.320 --> 14:38.920]  We found a file called filesys.dll, which checks for certificate verification.
[14:39.280 --> 14:44.200]  Now, this is part of the control flow graph of the certificate verification function.
[14:44.200 --> 14:48.320]  We figured that out because there's a string, literally, that says, search verify.
[14:48.640 --> 14:54.120]  And as we're analyzing the control flow graph, we realize that every successful operation
[14:54.120 --> 14:56.840]  would return a number 4 to the caller.
[14:57.620 --> 15:01.660]  So, here's what we do. Instead of returning an error code on other paths,
[15:01.660 --> 15:07.180]  we just modify to always move the number 4 to r0, which is the return register in ARM.
[15:08.060 --> 15:11.640]  And after we patch filesys.dll, we package the whole thing,
[15:11.640 --> 15:14.560]  we successfully bypass signature verification.
[15:14.980 --> 15:20.340]  And from then on, we're able to modify our firmware and add our own custom code to the ATM.
[15:21.080 --> 15:25.780]  So, here's a video of the ATM having custom code on it.
[15:25.780 --> 15:31.140]  As you can see, we press a button and we printed out a small receipt,
[15:31.140 --> 15:34.800]  like a portrait of the ATM, so we think it's kind of cheeky.
[15:34.800 --> 15:37.480]  So, that's why we did it. So, that's good, right?
[15:37.480 --> 15:43.800]  We got firmware modification working, but now it really has to work as an ATM.
[15:43.960 --> 15:47.200]  And throughout this process, we found some very interesting stuff, right?
[15:47.200 --> 15:51.740]  So, firstly, this is a very old device. It's a pretty slow device.
[15:51.740 --> 15:53.900]  And each update takes around 20 minutes.
[15:53.900 --> 15:58.840]  We have to sit there and babysit the ATM as it's updating and manually punching the settings.
[15:58.980 --> 16:01.620]  We also found a lot of peculiar commands.
[16:01.620 --> 16:04.420]  So, for instance, within 5 seconds of the loading screen,
[16:04.420 --> 16:10.060]  if you hit clear, left, right, clear, clear, cancel, you can clear the settings on the NVRAM.
[16:10.340 --> 16:14.980]  Or if you hit enter, clear, cancel, 1, 2, 3, it would bring you to a password prompt,
[16:14.980 --> 16:19.440]  which brings you to the operator screen where you can change the settings on the ATM.
[16:20.560 --> 16:23.880]  So, we figured out the firmware update process. We're pretty good now, right?
[16:23.880 --> 16:28.420]  We have JTAG. We have the firmware itself with some debugging symbols.
[16:28.560 --> 16:31.980]  We have an understanding of how the firmware update process works.
[16:31.980 --> 16:35.280]  We are able to modify, add, and remove executables.
[16:35.760 --> 16:39.760]  One last hurdle. It keeps on getting stuck on the whole screen.
[16:39.760 --> 16:42.080]  Like, we got stuck on this screen for a while trying to connect something.
[16:42.080 --> 16:44.140]  What is it trying to connect to exactly?
[16:44.820 --> 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.
[16:52.960 --> 16:55.620]  Now, there are these big card networks that issue a card to you.
[16:55.620 --> 16:59.460]  So, for instance, it could be your MasterCard or Amex or Visa.
[16:59.460 --> 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.
[17:08.880 --> 17:15.180]  So, there are different kinds of protocol for communication between the ATM and the payment processor.
[17:15.180 --> 17:18.360]  But the one that we looked at is called the Triton Protocol.
[17:19.300 --> 17:23.280]  Now, the Triton Protocol is a request-response communication protocol.
[17:23.280 --> 17:30.480]  There are four different types of communication pairs, but the most common ones are the configuration pair and the transaction pair.
[17:30.540 --> 17:32.920]  We did find the documentation online.
[17:32.980 --> 17:38.660]  However, it is a preliminary specification, and it is very out of date, so some of the information is wrong.
[17:38.660 --> 17:42.880]  And we needed to use Wireshark to figure out the correct request-response format.
[17:43.300 --> 17:44.380]  So, this is how it works, right?
[17:44.380 --> 17:48.880]  When you first boot up the ATM, it tries to connect to this payment processor.
[17:48.880 --> 17:56.440]  And the payment processor, once it receives a request, it sends back a response having some important information in it,
[17:56.440 --> 17:59.980]  such as the surcharge amount that it is going to take on the ATM.
[18:00.540 --> 18:07.720]  And for subsequent transactions, it would send a balance inquiry or withdrawal transaction code.
[18:07.720 --> 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.
[18:15.140 --> 18:19.540]  The payment processor takes that packet, talks to the network, talks to different card networks,
[18:19.540 --> 18:26.460]  and returns whether you can successfully withdraw money or not with a success-slash-error code.
[18:26.840 --> 18:29.680]  So, you might think, this information is pretty important, right?
[18:29.680 --> 18:33.560]  So, is that information encrypted? And the answer is yes.
[18:33.560 --> 18:36.140]  It is encrypted with SSL or TLS.
[18:36.140 --> 18:44.260]  However, this is an option, which means that operators can actually opt out not to use encryption for Triton traffic.
[18:44.260 --> 18:47.500]  However, the PIN numbers do have an extra layer of protection.
[18:47.760 --> 18:51.280]  And most use triple DES for encryption.
[18:51.900 --> 18:55.900]  It is pretty standard triple DES. It uses two keys, K1 and K2.
[18:55.900 --> 18:59.760]  So, the PIN would be enclosed in its own padding.
[18:59.760 --> 19:04.700]  The ATM encrypts it, sends it to the server, so the server would decipher it.
[19:06.240 --> 19:10.120]  So, triple DES is a block cipher. It is a shared key protocol.
[19:10.160 --> 19:12.260]  And the setup is actually pretty interesting, right?
[19:12.260 --> 19:18.980]  So, when a technician comes to your store or restaurant to set up the ATM, it would punch in two keys.
[19:18.980 --> 19:22.140]  And these two keys are XORed together to form a master key.
[19:22.320 --> 19:27.520]  Now, the server also has knowledge of this key, but it is not the final keys used to encrypt the PIN.
[19:27.920 --> 19:29.300]  So, this is how it happens.
[19:29.300 --> 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.
[19:36.320 --> 19:39.940]  The ATM would tell the payment processor, hey, I'm using triple DES.
[19:40.780 --> 19:48.060]  The payment processor would acknowledge it and encrypt two other keys, which is the final K1 and K2, with the master key,
[19:48.060 --> 19:51.500]  and send the encrypted pair of keys back to the ATM.
[19:51.780 --> 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.
[20:00.460 --> 20:07.580]  So, when someone enters their PIN on the ATM, the PIN is encrypted with K1 and K2,
[20:07.580 --> 20:14.720]  and that encrypted PIN gets sent over, and the payment processor would decrypt it with K1 and K2.
[20:15.500 --> 20:20.320]  So, after we understand the Trident Protocol, how the PIN encryption scheme works,
[20:20.320 --> 20:28.940]  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.
[20:38.970 --> 20:42.510]  So, one of the first things you want to do on a device like this that's hooked up to a network
[20:42.510 --> 20:46.710]  is to see what surface area it exposes in terms of open ports.
[20:48.150 --> 20:53.030]  So, that's what we did. We actually found eight open ports on this device initially.
[20:53.230 --> 21:00.290]  The first two are the Windows CE web server, the default web server that's built into all Windows CE images,
[21:00.290 --> 21:03.870]  if that option's enabled, running on this device.
[21:03.910 --> 21:10.510]  When you actually pull it up, it's just the default web page that gets returned.
[21:10.510 --> 21:17.970]  So, likely this was something that just wasn't removed from the image as it was being built.
[21:19.630 --> 21:24.690]  Interesting aside is that you'll find a lot of Windows CE devices on the Internet.
[21:26.690 --> 21:29.910]  There's a couple of queries you can run to look that up,
[21:29.910 --> 21:37.610]  but especially something as old as Windows CE 6.0 on the public Internet would be a concern,
[21:37.610 --> 21:44.930]  ATMs, I haven't seen many, if any, ATMs on the public Internet.
[21:45.450 --> 21:47.150]  Mostly other devices.
[21:48.690 --> 21:55.370]  So, this second port, or I guess third port that we found here, the 5555, was a bit puzzling at first,
[21:55.370 --> 22:01.870]  but we realized it was the remote management system default listening port.
[22:01.870 --> 22:11.030]  So, that's something that you use to update the ATM, to administrate it, to check balances, that sort of deal.
[22:11.530 --> 22:13.270]  So, that's what that port was.
[22:13.710 --> 22:15.950]  And then we had these last five ports here.
[22:15.950 --> 22:20.930]  So, these were ones that we didn't quite know, ones that we weren't able to figure out easily.
[22:22.110 --> 22:31.470]  So, we tried connecting to them, but for quite a while we just weren't able to get any results from it,
[22:31.470 --> 22:35.770]  or send any data and have it be acknowledged.
[22:36.710 --> 22:41.870]  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
[22:41.870 --> 22:44.670]  and what remote management system does.
[22:46.810 --> 22:49.010]  All right, so what is RMS?
[22:49.010 --> 22:54.550]  So, RMS stands for Remote Monitoring System Service, Remote Management System Service.
[22:54.650 --> 23:00.390]  However you want to call it, it is a service that lets customers control the collection of ATM remotely.
[23:00.530 --> 23:06.690]  So, the customer can use this service to update the firmware on a bunch of ATMs, check the amount of money left,
[23:06.690 --> 23:09.310]  download the transaction history from the ATM.
[23:09.790 --> 23:14.630]  Now, this is an optional service, meaning that users can enable or disable it.
[23:14.630 --> 23:20.630]  The default port for RMS is 5555, which corresponds to Trey's port scan.
[23:21.990 --> 23:28.510]  So, in RMS it uses the ATM's ID and the custom password for verification.
[23:29.530 --> 23:34.690]  So, when we were reverse engineering it, we realized there was close to no documentation on RMS.
[23:34.730 --> 23:40.430]  So, at the end we needed to use a combination of Wireshark, Ghidra, and AIDA to figure out a communication protocol,
[23:40.430 --> 23:42.930]  and the process took around two weeks.
[23:42.930 --> 23:45.930]  But we eventually got it, right?
[23:45.930 --> 23:50.010]  So, the RMS packet is pretty standard, you know, you have a start by a terminal,
[23:50.010 --> 23:51.810]  but there's like an LLC at the end.
[23:51.810 --> 23:54.950]  The more interesting part is like the encoded data,
[23:54.950 --> 24:01.270]  where that part is actually obfuscated with an extra table hard-coded in the binary.
[24:02.490 --> 24:05.970]  And this is actually not the first time someone looked into RMS.
[24:05.970 --> 24:12.190]  In fact, in Barnaby Jack's talk in 2010, he jackpotted an ATM via a vulnerability in RMS.
[24:12.190 --> 24:18.670]  And since then, and we looked at his report, it turns out that the RMS packet structure is still the same.
[24:18.710 --> 24:21.210]  Obfuscation techniques didn't really change.
[24:21.650 --> 24:29.590]  And in his talk, he found out that a malformed packet can lead to authentication bypass and eventual firmware modification.
[24:30.150 --> 24:33.430]  So, the service should be secure now, right?
[24:33.730 --> 24:35.290]  Well, let's put it to the test.
[24:35.290 --> 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.
[24:42.070 --> 24:45.250]  So, we used BooFuzz, which is a network fuzzer.
[24:45.290 --> 24:50.690]  It takes a lot of heavy work out of it, so we only needed to define the protocol in code,
[24:50.690 --> 24:55.070]  and BooFuzz would take it, test different inputs, and do the rest.
[24:55.590 --> 24:58.250]  So, we did get around five to six crashes.
[24:58.290 --> 25:04.730]  And when we're analyzing the crashes, we see that every time when we send a really large packet,
[25:04.730 --> 25:09.390]  so any packet more than 10 kilobytes, the device would crash and reboot.
[25:09.390 --> 25:15.190]  Interestingly, this happens regardless of whatever password or ID you send to the device.
[25:15.590 --> 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.
[25:25.530 --> 25:29.770]  So, let's take a deeper dive into this function and how it works.
[25:29.930 --> 25:34.550]  So, at first, the function accepts any incoming connections via TCP,
[25:34.550 --> 25:40.930]  receives the packet, decrypts it with the XOR table, verifies the ID and the password,
[25:40.930 --> 25:44.090]  parses the command, closes the connection.
[25:44.350 --> 25:50.850]  And the problem happened at this stage, where it received the RMS packet and decrypts it with the XOR table.
[25:51.450 --> 25:54.250]  So, what exactly went wrong?
[25:54.290 --> 25:57.690]  Well, it turns out it's basically a buffer overflow.
[25:57.690 --> 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.
[26:05.550 --> 26:11.730]  And what it did is that this eventually overrides a function point it has called when the application exits.
[26:11.950 --> 26:16.290]  And this copy happens before any kind of terminal ID or password verification.
[26:16.710 --> 26:22.490]  So, the consequence is, as long as you understand the packet structure, as long as your packet structure is sound,
[26:22.490 --> 26:28.670]  the buffer overflow could happen, and you can write shellcode in your packet to lead to arbitrary code execution.
[26:29.930 --> 26:32.010]  Now, what can the attacker do?
[26:32.010 --> 26:36.970]  We were investigating it, and we realized that most DLLs are paged out as the application exits,
[26:36.970 --> 26:40.470]  except for the functions that control the NVRAM.
[26:40.610 --> 26:47.530]  And in this device, in this ATM, NVRAM is pretty important because it basically controls anything on the admin screen.
[26:47.530 --> 26:50.250]  It stores all the settings on the ATM.
[26:52.210 --> 26:56.690]  So, for instance, an attacker can point the ATM to the malicious server
[26:56.690 --> 27:02.450]  because within the NVRAM, it stores the IP of the payment processor.
[27:02.450 --> 27:04.970]  You can change the denomination of the ATM.
[27:04.970 --> 27:08.070]  So, for instance, if your ATM is supposed to have $20 bills,
[27:08.070 --> 27:13.370]  you can change the denomination to $1 bills in order to extract more money from the ATM.
[27:13.670 --> 27:18.970]  And let's go to a demo of the RMS vulnerability.
[27:20.030 --> 27:22.510]  All right, so we have our ATM here.
[27:22.510 --> 27:26.570]  It has RMS running on the background.
[27:26.650 --> 27:31.890]  So, now Trey is going to send a packet over to the ATM.
[27:31.950 --> 27:35.610]  And as you see here, it says remote monitoring system is in progress.
[27:35.650 --> 27:39.870]  Trey sends a malformed packet over, but it still looks fine here, right?
[27:40.050 --> 27:44.510]  So, now let's say I'm the operator, and I need to perform a firmware update.
[27:44.510 --> 27:52.750]  So, I will do and declare cancel 1, 2, 3 in order to go into a password prompt.
[27:52.850 --> 27:56.050]  And then I put the operator password in.
[27:56.270 --> 27:58.750]  That brings me to an administration screen.
[27:58.750 --> 28:00.610]  You can change a bunch of stuff here.
[28:00.610 --> 28:08.010]  But right now, since I'm doing a firmware update, I'll go into system setup, system control, software update.
[28:08.010 --> 28:10.510]  Yes, I want to do a software update.
[28:10.630 --> 28:13.830]  So, this is where the shellcode gets executed, right?
[28:13.830 --> 28:21.690]  Because as the application exists cleanly, the function pointer that we overwrote would be called,
[28:21.690 --> 28:24.130]  and that would execute our shellcode.
[28:25.590 --> 28:30.670]  In this specific demo, we set the shellcode so that it would point...
[28:30.670 --> 28:35.850]  instead of pointing to the Raspberry Pi with the Triton protocol running,
[28:35.850 --> 28:42.830]  it would point back to Trey's laptop, which has the Triton server running.
[28:43.970 --> 28:44.490]  Right.
[28:44.630 --> 28:51.770]  So, as you see here, it just updated successfully, and we needed to wait a few seconds to reboot.
[28:52.030 --> 28:54.430]  Once again, this device is pretty slow.
[28:54.430 --> 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.
[29:03.090 --> 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.
[29:10.630 --> 29:15.130]  And as Trey said, since this is a pretty old device, it's a pretty old version of Windows CE,
[29:15.210 --> 29:21.910]  a lot of the modern protections against... a lot of modern protections and binaries are implemented.
[29:21.910 --> 29:27.670]  So, for instance, we don't see any ASR implemented in the binary through JTAG.
[29:27.670 --> 29:33.370]  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,
[29:33.370 --> 29:40.670]  the next time we rebooted those libraries, the executables would be loaded back into the same location,
[29:40.670 --> 29:46.330]  which makes the process of writing shellcode easier.
[29:47.070 --> 29:53.730]  And as I mentioned before, the shellcode would point the ATM to Trey's computer,
[29:53.730 --> 29:57.210]  and how it does is modify some settings on the NVRAM.
[29:57.210 --> 30:00.630]  The NVRAM controls all the settings, right?
[30:00.630 --> 30:07.390]  It controls whether SSL is turned on or off. It controls where the ATM is pointing to.
[30:07.490 --> 30:11.490]  And it's also a pretty simple function to reverse engineer.
[30:11.490 --> 30:18.350]  It takes two numbers, and each pair of numbers would point to, for instance, whether SSL is turned on or not.
[30:18.350 --> 30:26.010]  It would point to the IP string of the payment processor host.
[30:26.810 --> 30:31.990]  So, as you see here, now it's initializing. It takes a while.
[30:31.990 --> 30:35.690]  It's loading, and it's trying to interface with the peripherals.
[30:36.470 --> 30:39.510]  It prints out a receipt whenever it reboots, right?
[30:39.510 --> 30:47.890]  So, it's just saying, oh, test printing, okay, and it prints out a version of the printer within the ATM.
[30:51.230 --> 30:53.530]  It takes a while to initialize.
[30:53.530 --> 31:03.290]  But after initializing, you would see that instead of pointing to the payment processor on the Raspberry Pi,
[31:03.290 --> 31:08.510]  it would point to the Triton server that Trey is running on his computer.
[31:09.170 --> 31:10.610]  It makes a lot of noises, right?
[31:10.790 --> 31:14.950]  It's trying to print something. It's trying to make sure the cache dispenser works.
[31:15.650 --> 31:18.210]  All right, now it's trying to connect to the host.
[31:18.210 --> 31:26.270]  And as you can see on Trey's computer, our malicious payment processor is working.
[31:26.270 --> 31:27.690]  It's interfacing with the ATM.
[31:28.130 --> 31:30.290]  So, I have a card here.
[31:30.490 --> 31:33.430]  It's one of the cards that we printed in-house at Red Balloon.
[31:33.590 --> 31:35.250]  So, it has track 2.
[31:35.250 --> 31:39.150]  So, it has tracks here, and track 2 is where the interesting information is stored,
[31:39.150 --> 31:41.270]  is where your card number is stored, in fact.
[31:41.490 --> 31:44.850]  So, let's say I'm a customer, and I wanted to check my balance.
[31:47.750 --> 31:50.150]  It takes a while.
[31:50.650 --> 31:52.650]  I hit English.
[31:53.110 --> 31:55.910]  It asks me to enter a PIN, right? It can be anything.
[31:56.950 --> 31:57.910]  Enter.
[31:58.510 --> 32:02.050]  And let's say I want to inquire my balance on the ATM.
[32:03.710 --> 32:06.530]  Let's say I want to check my checking.
[32:06.530 --> 32:08.330]  No receipt, thank you.
[32:08.550 --> 32:14.630]  And it is connecting to the host, although it says an ineligible account on Trey's computer.
[32:14.630 --> 32:20.610]  So, you can actually see the expiration date of the card and the card number itself.
[32:22.710 --> 32:24.930]  All right. Back to you, Trey.
[32:33.160 --> 32:35.280]  Cool. So, we just saw the RMS demo.
[32:35.660 --> 32:39.700]  And now I want to talk a little bit more about interacting with this device
[32:40.260 --> 32:43.620]  and what we had to do to actually get things to work on it,
[32:43.620 --> 32:49.540]  since we didn't have a keyboard or any HRD device to really interface with it.
[32:49.540 --> 32:53.400]  So, we kind of had to actually take a look at this.
[32:53.400 --> 32:56.440]  So, there's an ActiveSync, probably, port on here.
[32:56.440 --> 32:58.280]  But we couldn't quite get that working.
[32:59.040 --> 33:02.020]  ActiveSync is the way you would work with Windows CE devices
[33:02.020 --> 33:06.180]  to interface with them on a desktop computer.
[33:06.400 --> 33:11.800]  But we couldn't get that working, so we actually compiled our own tool.
[33:12.440 --> 33:14.860]  This is Windows CE. It's a standard platform.
[33:14.860 --> 33:20.480]  How difficult should it be to be able to just compile something to work on it?
[33:21.580 --> 33:24.080]  Well, the caveat here is that it's Windows CE 6.0.
[33:24.080 --> 33:27.540]  So, this was released in 2006, initially.
[33:28.140 --> 33:33.620]  So, we actually had to go all the way back to Visual Studio 2008 to get this really going.
[33:34.900 --> 33:39.800]  It's quite an old IDE, but we knew it worked well under Windows XP.
[33:39.800 --> 33:46.260]  So, what we were able to do with this IDE was actually build some C-sharp applications,
[33:46.260 --> 33:50.740]  get them to run on the .NET Framework, which is actually on this device.
[33:50.740 --> 33:53.160]  It has a .NET Compact Framework on here.
[33:54.560 --> 34:00.440]  However, it's fairly old, so a lot of examples for C-sharp code,
[34:00.440 --> 34:02.860]  if you're not incredibly familiar with it initially,
[34:03.320 --> 34:07.020]  you can't just copy-paste off of Stack Overflow to get things working on here.
[34:08.220 --> 34:10.260]  A lot of useful features are missing.
[34:10.480 --> 34:14.600]  But, in the end, we did get an application working on here.
[34:14.820 --> 34:19.940]  So, we really wanted an application for our CTF to be able to have a web server
[34:20.580 --> 34:23.680]  that people could connect to, to interface with the ATM.
[34:25.080 --> 34:26.440]  So, this was the start of that.
[34:26.440 --> 34:29.120]  We actually popped a dialog box here.
[34:31.340 --> 34:37.800]  And, you know, we could have used the built-in web server on this device
[34:37.800 --> 34:39.820]  that you saw in the port scan earlier.
[34:39.820 --> 34:46.780]  However, there wasn't any DLL or any capabilities for any sort of dynamic content or scripting.
[34:46.900 --> 34:49.700]  So, that would have been a bit difficult to actually get up and running.
[34:49.700 --> 34:54.960]  So, instead, we created our own web server, which was difficult in its own right,
[34:54.960 --> 34:59.500]  because HTTP primitives aren't in the .NET version we're using.
[34:59.500 --> 35:04.140]  So, we had to build things on top of just straight TCP sockets.
[35:04.140 --> 35:09.940]  But, with some good examples, we fast-forwarded a bit and had a web server working,
[35:09.940 --> 35:11.540]  which is what you see here.
[35:11.980 --> 35:15.580]  So, this is our test setup.
[35:15.580 --> 35:18.840]  This is a device emulator running the .NET code
[35:20.300 --> 35:24.760]  and displaying our CTF web page there.
[35:26.940 --> 35:30.800]  So, for launching on Startup, there's a number of ways we could have gone about this.
[35:30.800 --> 35:37.340]  But, again, we didn't quite have any way to interface with the ATM at this point,
[35:37.340 --> 35:41.280]  since we are trying to compile our own tool.
[35:41.660 --> 35:47.840]  So, in order to be able to launch that tool, to be able to probe how the device works,
[35:48.860 --> 35:52.400]  we actually used the debugger every single time we wanted to run it,
[35:52.400 --> 35:55.860]  and hijacked the startup process, the call and create process,
[35:55.860 --> 36:02.280]  and pointed that towards our custom server.
[36:02.920 --> 36:07.180]  So, we could reverse the startup procedure and do the proper way through registry edits,
[36:07.180 --> 36:09.640]  which can be a bit difficult on Windows CE.
[36:09.640 --> 36:16.180]  But, what we ended up doing was actually just taking the executable that was on here,
[36:16.180 --> 36:19.940]  that would normally be launched, called winatm.exe,
[36:19.940 --> 36:26.000]  renamed it to something else, and then named our own executable winatm.exe,
[36:26.000 --> 36:36.340]  and then launched the original process that would normally be launched as a child process of our server.
[36:37.720 --> 36:41.940]  So, we've got this C-sharp code running, it's all good,
[36:41.940 --> 36:45.560]  but what would it take to get some native code running?
[36:45.560 --> 36:47.480]  So, let's actually dig into it here.
[36:49.940 --> 36:55.400]  What we ended up needing to do was use Visual Studio 2005, going even further back,
[36:55.400 --> 37:00.800]  and install a number of different packages to actually get this to work.
[37:02.040 --> 37:05.660]  It was quite a pain, but in the end it was actually quite worth it,
[37:05.660 --> 37:12.040]  because in one of the most amazing Microsoft things I've ever seen,
[37:12.040 --> 37:16.800]  you can click through a wizard and, from scratch, build an OS image,
[37:16.800 --> 37:20.300]  which is a pretty amazing concept.
[37:20.300 --> 37:25.280]  You're clicking little checkboxes to enable or disable different features,
[37:25.280 --> 37:28.320]  and change how things are built into it.
[37:28.800 --> 37:35.840]  So, from that we were able to actually see different DLLs that would normally be on the ATM,
[37:35.840 --> 37:38.360]  like the keyboard driver and things like that.
[37:39.600 --> 37:44.860]  But by this point, we had already gotten our web server up and running.
[37:45.440 --> 37:49.180]  We've got it launching every boot, and so we built all these commands
[37:49.180 --> 37:55.300]  to be able to interface with the device, check out what processes we're running,
[37:55.300 --> 37:58.900]  how to remove registry keys, how to remove files,
[37:58.900 --> 38:02.570]  any sort of thing we'd need to really dig in and research it,
[38:02.880 --> 38:05.520]  and have fun diversion while we did it.
[38:05.520 --> 38:09.980]  So, this was actually... we found a build of Doom for this device,
[38:09.980 --> 38:12.560]  and we actually got it up and working here.
[38:12.560 --> 38:19.260]  This was an Easter egg in some of our earlier CTF challenges to be able to find this.
[38:21.400 --> 38:24.420]  But it ended up... I'm not sure if it was eating up all the memory,
[38:24.420 --> 38:30.160]  but the system would just randomly reboot partway through after Doom had been launched.
[38:30.160 --> 38:34.180]  So, we had to remove that for further CTF challenges,
[38:34.180 --> 38:37.960]  but it was fun to get it up and running while we had it.
[38:37.960 --> 38:43.680]  And despite being a fairly slower and older ARM core, we were able to run this.
[38:46.000 --> 38:49.120]  So, one of the things we did next was take a look at the registry,
[38:49.120 --> 38:54.300]  see how things were configured, and look for any clues of things
[38:54.300 --> 38:56.760]  that might be interesting on this device.
[38:57.360 --> 39:03.780]  So, one of the things that we initially found that was kind of familiar
[39:04.460 --> 39:06.900]  were some of these keys, and you might take a look at them
[39:06.900 --> 39:12.100]  and recognize those numbers from some of the ports that were open earlier.
[39:13.280 --> 39:20.240]  And even more interesting, if you take a look at the key name,
[39:20.940 --> 39:24.760]  it's a little concerning, because you start to think,
[39:24.760 --> 39:30.840]  maybe this cache dispenser is somehow related to this open port on 8004.
[39:31.140 --> 39:34.520]  So, what is this? What are we taking a look at here?
[39:34.520 --> 39:38.520]  Well, here's a hint. XFS is what this is.
[39:39.060 --> 39:42.640]  Not the file system, the money one.
[39:42.740 --> 39:46.380]  And XFS is this standard platform for financial devices
[39:48.360 --> 39:53.220]  that exposes this sort of middleware, where you can have a Windows application
[39:53.220 --> 39:57.720]  send a command that gets passed through these layers of abstraction,
[39:57.720 --> 40:01.520]  and go to the service provider, the service provider being the thing
[40:01.520 --> 40:05.400]  that actually is able to interface directly with the devices.
[40:05.800 --> 40:09.980]  So, this allows you to build things in sort of Lego's fashion,
[40:09.980 --> 40:16.860]  so you can swap out different components of your system, theoretically.
[40:17.440 --> 40:20.180]  You know, swap out different cache dispensers, swap out different card readers,
[40:20.180 --> 40:24.400]  and there are all these standard different devices that you can put on here.
[40:25.460 --> 40:28.860]  So, you'll see the cache dispenser, you'll see the ID card unit,
[40:28.860 --> 40:35.620]  which is reading your card, pin pad, things of that nature are all in here.
[40:37.060 --> 40:39.860]  So, what is XFS? Where does this come from?
[40:40.040 --> 40:44.780]  It started out as a Microsoft thing, where they wanted to create the standard platform
[40:44.780 --> 40:47.040]  for Windows for financial devices.
[40:47.680 --> 40:51.020]  They seem to have really succeeded, because this is, you know,
[40:51.020 --> 40:56.980]  kind of one of the industry standards for how you would set up an ATM
[40:56.980 --> 40:59.120]  or any other financial device.
[41:00.020 --> 41:06.120]  And so, Microsoft handed it off to SIN, the European Committee for Standardization,
[41:06.120 --> 41:08.440]  who is actually the maintainers of the standard now,
[41:08.440 --> 41:11.940]  and you can go on their website and find all of these documents
[41:11.940 --> 41:16.260]  detailing how devices are hooked up in XFS.
[41:17.140 --> 41:25.520]  So, for example, this is the cache dispenser device description document here.
[41:25.660 --> 41:28.360]  So, this is great for people building these devices.
[41:28.360 --> 41:36.260]  It creates a fairly open ecosystem that allows manufacturers to be able to
[41:36.920 --> 41:40.240]  swap out different things and have that,
[41:40.240 --> 41:45.460]  which also causes an issue in terms that it's a fairly homogenous platform
[41:45.760 --> 41:52.360]  that allows people with very little understanding of ATMs
[41:52.360 --> 41:57.180]  to actually be able to create some fairly portable malware
[41:57.180 --> 41:59.980]  to be able to use on these different devices.
[42:00.200 --> 42:02.520]  That takes advantage of the XFS interface,
[42:02.520 --> 42:07.420]  and we've seen a number of different pieces of malware that use this.
[42:08.620 --> 42:12.880]  So, going back to the ports, again, this is something XFS-related.
[42:13.300 --> 42:20.940]  So, we see those numbers there, and what I did was go through and map out.
[42:21.640 --> 42:27.380]  You can see that after logical services, there's auxiliaries, card reader, cache dispenser,
[42:27.380 --> 42:33.940]  and then there's also the device class, which is what XFS would call that device.
[42:33.940 --> 42:38.500]  IDC and CDM for the cache dispenser.
[42:38.700 --> 42:45.200]  And created this mapping showing which registry key corresponds to which device class,
[42:45.200 --> 42:47.980]  which corresponds to which port.
[42:48.860 --> 42:52.020]  So, you can see here again that this is, you know,
[42:52.020 --> 42:57.940]  the device classes are the standard XFS designations for these types of devices.
[42:58.820 --> 43:01.200]  So, what does this tell us?
[43:02.200 --> 43:05.720]  There's open ports. They're related to XFS somehow.
[43:06.900 --> 43:09.900]  Can we make it dump out some money?
[43:11.060 --> 43:13.880]  Well, the problem again is, you know, we can connect to these ports,
[43:13.880 --> 43:16.240]  but we can't get anything out of them.
[43:16.240 --> 43:19.260]  We don't see any traffic, and we don't know what to send into them.
[43:19.760 --> 43:20.920]  So, let's sniff it.
[43:20.920 --> 43:25.600]  You know, let's see if there's anything on these ports,
[43:25.600 --> 43:28.920]  even on the local network interface on here,
[43:29.600 --> 43:36.000]  that's listening and sending messages to see if we can take that
[43:36.000 --> 43:39.760]  and use it to build our own messages or replay them.
[43:39.760 --> 43:42.820]  The problem here being that this is a Windows CE device,
[43:43.580 --> 43:48.820]  and you can't just download Wireshark for Windows CE because,
[43:48.820 --> 43:52.460]  as this very helpfully points out, there is no Wireshark for Windows CE.
[43:53.980 --> 43:58.540]  So, Windows CE does have packet capture capabilities,
[43:58.540 --> 44:00.760]  but it's not built into this ATM image,
[44:00.760 --> 44:08.320]  and I didn't really want to take the time to try and figure out how to port it to this ATM image.
[44:08.320 --> 44:11.660]  So, the easiest way to do this ended up being JTAG.
[44:12.460 --> 44:17.320]  And the way, the plan of attack here was to intercept the socket create calls,
[44:17.320 --> 44:24.240]  get the handles for them, and then map those handles to the different services,
[44:24.240 --> 44:27.520]  intercept socket sending receive calls, and look at the buffers,
[44:27.520 --> 44:31.780]  and save all that traffic, and then acquire some cutlets.
[44:31.780 --> 44:39.200]  So, what we did was went through, found where these registry strings were being read,
[44:39.200 --> 44:50.360]  and from that we were able to figure out which socket creation call corresponded to which different device class.
[44:50.900 --> 44:56.040]  And here you'll see that this is where we're hooking the send and receive functions in Winsock
[44:56.680 --> 45:04.640]  to be able to look at the buffer and take the data that is either being sent or the data that has been received,
[45:04.640 --> 45:09.080]  save that to a file, and take a look at it.
[45:09.080 --> 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.
[45:16.620 --> 45:19.980]  So, as you can see here, we have a number of packets that came in.
[45:19.980 --> 45:21.920]  Some of these are send, some of these are received.
[45:21.920 --> 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.
[45:27.940 --> 45:34.780]  There is the US dollars string in the packet in the lower right, but it's nothing immediately obvious.
[45:34.780 --> 45:39.240]  So, first thing we tried was, can we just replay one of these packets?
[45:39.660 --> 45:44.240]  Because we know, we were doing actions on the ATM as we were capturing these packets,
[45:44.240 --> 45:50.140]  so we can roughly correlate what might have been sent to the cache dispenser to cause it to dispense cache.
[45:51.080 --> 45:59.080]  So, yes, we can just replay and send out some cache from the cache dispenser.
[45:59.080 --> 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.
[46:07.040 --> 46:14.100]  It was no need to learn how all the structure works, no need to learn how to work with these fields.
[46:14.100 --> 46:22.360]  You can literally just take this packet that you've seen, replay it to dispense cache, and that was fairly straightforward.
[46:23.660 --> 46:28.380]  So, that worked in the case where we just wanted to dispense the same amount of cache,
[46:28.380 --> 46:33.500]  but what if we wanted to dispense as much cache as possible over and over?
[46:33.940 --> 46:40.300]  Well, after looking at this dump for a while, we were able to figure out some patterns and see the structures in there,
[46:40.980 --> 46:50.080]  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.
[46:50.080 --> 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.
[46:59.880 --> 47:06.180]  So you can see the card number there is 555555555555555555555555.
[47:06.180 --> 47:07.980]  That's the track 2 data.
[47:10.560 --> 47:18.020]  And we have these fields here that might not be immediately obvious, this command code, notably.
[47:18.220 --> 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.
[47:28.360 --> 47:35.660]  So the service class being 2, that's multiplied with 100 to get the service offsets, which is 200.
[47:36.720 --> 47:42.420]  And then all of the commands are some offset from that base number.
[47:42.420 --> 47:50.500]  So 207 is this specific command for idcard read raw data, which corresponds to what we saw here,
[47:50.500 --> 47:57.640]  which is 207, which is hex cf. You can see the result of that read raw data there.
[47:59.060 --> 48:04.240]  So we modified this to work with the structure for the cache dispenser packet
[48:06.180 --> 48:14.260]  and, you know, pumped up the amount of cache that we're dispensing. And yeah, we were able to run
[48:14.260 --> 48:21.140]  that and we can actually run any XFS command on this device if we send it to the appropriate port.
[48:21.140 --> 48:29.040]  So kind of in retrospect here, you know, pro tip, if you're using TCP sockets for IPC,
[48:29.040 --> 48:37.060]  don't listen on 0.0.0.0. And if you're creating a networked device, at least do a port scan before
[48:37.060 --> 48:45.840]  you ship it. So we want to run through the XFS demo here and show you this machine spitting out
[48:45.840 --> 48:53.520]  some cache. Cool. So we have the ATM here. And I'm going to run the script we wrote for XFS.
[48:53.520 --> 48:59.040]  And you should see that the command is being injected directly into the XFS middleware.
[48:59.040 --> 49:05.880]  So none of this will actually show that cache is being dispensed. So if I run the command,
[49:12.660 --> 49:17.740]  it's going to dump out some cache. So this is just going to continually happen. It's
[49:17.740 --> 49:23.800]  going to keep dumping out $2 bills over and over again. And yeah, this is the result of
[49:24.720 --> 49:28.740]  a computer just being on the same network. You know, you can grab the Ethernet cable behind it
[49:29.680 --> 49:34.900]  and send a single packet to the ATM and it will dump out a load of cache.
[49:43.030 --> 49:48.490]  All right. Thank you for coming to our talk. And be sure to join us in our Q&A afterwards.