 So it was a long time coming, I want to give a big thanks to my mate Alex, fluent from Europe to help me road trip these ATMs to Vegas. We literally are through two ATMs in the back of an Escalade and Gundot from the Bay Area of Vegas thinking, if we get pulled over for this mate, I'm going to have a hell of a way of trying to explain no way out of it, but... We got here... Okay, right up there. So here are like two ATMs in the back of an Escalade and about 6,000 notes of novelty currency. That'd be what, I know for you boys out there. But so the attraction to target ATMs is fairly obvious, you know, they're full of cash. But for myself, it's kind of part of a bigger picture and a bigger plan. And that's to explore systems that, when compromised, have direct and immediate consequences. So whether they be ATMs, medical devices, smart meters, you know, the computer system in your vehicle, particularly because they're not often designed with a secure methodology from the get-go. And as a result of that research, we can use that knowledge to design, bear and safer products in the future. So the goal of the talk is to spark discussion on ways to remediate and fix the vulnerabilities I'm going to be demonstrating. The goal isn't to give a cookbook recipe on how to hack ATMs. The process of finding vulnerabilities, I think, is always more interesting, you know, the journey not the destination. Although the destination is pretty damn cool on this one too. And I hope to change the way people look at devices that from the outside are seemingly impenetrable. So current attacks, probably all aware of the skimmer, which is certainly a fan favorite. Say a small overlay that slides over the card slot of pin pads, manufactured to blend seamlessly with the ATM itself, designed to capture both the track data and pin numbers. And the technology on some of these is no joke too, you know, it will send you the data over GPS and some even have like temporary protection so when they're found out or wipe itself up. Interesting. Physical theft and ram raids, you've probably seen those various YouTube videos where a couple of good old boys hurl through the front window of a place, attach a chain to the ATM and the other end to the pickup truck and just gun it out of there. Not really the most subtle of attacks, of course, but it's kind of a ninja status to compare to some of the other ones. And card trapping and card snooping, it's where someone inserts a small shim, it's commonly known as the Lebanese loop. Traps your card and it's designed such a way that when your card's read, the card won't be returned and it's often combined with shoulder surfing to get your pin, but sometimes they'll get your pin in ways which may not be quite as friendly. Safe cutting in frontal attacks, basically going in ATM with a pair of pliers and a blow torch, and explosives which is surprisingly popular, which I find a little bit odd. Attack is literally tying a bunch of explosives to an ATM and blowing the crap out of it. Now you'll think that would be somewhat counterproductive to what you're trying to accomplish there and it's big in Australia, so go figure. And data breaches, hacking the bank processor, harvesting the card data and pins, I suppose the best example of that would have been the hack of the RBS World Pay back end. And certainly safest, most technically sophisticated attacks I've seen, and I think about nine million was stolen during that attack. And of course other, or miscellaneous. So we have the default passcode attack from a couple years back, that's where if the operator password was left unchanged on the ATM, you could reprogram the ATM and think there was a lower denomination than it really was. So you probably don't think it was full of $5 notes when it's really giving you $20. And I'll be adding more to the other category, practical attacks, which I think I'll blow that little wee John Connor's attack right out of the water. So I picked standalone ATMs. There's a few reasons. One, they're pretty easy to get a hold of. Like anything on the internet, you can jump online and just add to cart, basically. But getting the ATMs delivered to your house on the other hand is interesting. So I remember when one of the ATM delivery guys came in and he wheeled the ATM into my place, and he just like, why on earth do you need an ATM in your house for? And I was feeling a bit cheeky that day, so I just looked at him and was like, oh, I just don't like the transaction fees, mate. And also they're everywhere, right? Every bar, convenience store, market, whatever it may be. And they're often in secluded areas hidden out by the restroom, tucked away in corners. But I'm gonna discuss attack methods for both standalone and hole in the wall ATMs. I'll go with walkup style attacks, but then shift focus to the far more important vector in my opinion, and that's the remote attack. And what an attacker can leverage with a successful remote compromise. And when I mean remote, I mean remote default, because that's the only way to roll, really. So just to show how popular these ATMs are, this is literally one block just down the road from my place, decided I'd just go on a bit of a pub crawl and see what I could find as far as vulnerable ATMs go. Literally, yeah, this is half a mile. My favorite is this dude actually who owns a Mexican restaurant, he's a good sport, notice about a Teppateo resting on top of the ATM there. He doesn't exactly look chuffed to be in this picture. So the standard specs of a new model retail style ATM, typically Windows CE running an ARM processor. New model support both TCP IP and dial up by default. Wireless being CDMA, not 802.11, so no drive by ATM hacks unfortunately. Thought it would be cool to drive by a store and have it spit out its cash. No such luck. SSL support and the triple desk encrypted PIMPADs. Basically the PIMPAD itself performs all the encryption on the device, has anti tampering mechanisms and I'll talk more about that in a piece a little bit later too. Is that better? Okay, so here's the ATM internals, receipt printer, over to the right you can see the card reader and there's a serial interface that leads down into the safe which is actually wired into the dispenser. And there's also various motherboard inputs, multiple USB, SD cards, network and some debugging ports. Now there's usually a cover that protects the circuit board and I've only removed it just to show the internals. I guarantee that these ATMs are completely stock, completely unmodified, totally untouched. Now, funnily enough of all the possible ways that an ATM talk could get disrupted, it was actually my cat who almost took it down for me. Had like a USB keyboard plugged in and he was running around chasing a moth or something and tripped over the USB cord, pulled it out and pulled out the processor plug-in at the same time but luckily it was easily soldered back in for, anyway, bad kitty. So in my opinion a presentation shouldn't really be a full-blown technical tutorial. So I'm gonna be following up later with a white paper that goes into more technical details but rather than digging deep into the ins and outs of Windows CE internals, I sum up the security hurdles I faced with this quote. We were concerned about protection but not about security. We weren't trying to design an airtight system like Windows NT. And this was from Thomas Fenwick, the guy who actually created the Windows CE kernel. And I got that from a book that was called Inside Windows CE which was essentially just a bunch of interviews with the core developers. So obviously things have changed a little bit since that book was written but to be honest there were not a lot of roadblocks. So before we can even think about giving the guy from Terminator to a run for his money and actually start devising attacks. First step is to be able to interface with the ATM itself, gain access to the file system and then with access to the file system we can then pull the executables off to be able to do some reverse engineering. Now unfortunately when the ATM boots, they're boots directly to a proprietary application so there's no explorer shell. So we need a shell to make things easy and originally I thought I could just, naively I thought I could just plug in a keyboard and just alt tab but that wasn't to be the case of course. So to get a shell we'll need explorer to somehow execute air boot time. The CE application boot sequence is pretty straightforward. Kernel NKXE runs file sys.exe, it initializes the registry in the file system and then executes the applications listed in the HKLM in the registry key. So the trick is to patch the application we want executed into this boot list. So we want to get explorer EC into the boot list and there's two approaches. The first approach is you actually have a copy of the CE ROM image, the registry file can then be extracted, modified, recompiled into the image but this requires a way of course to rewrite the flash, whether it be over serial, ethernet, JTAG or what have you. Now the other approach is to patch and explorer while you're debugging which of course requires debugging capability, JTAG and so on. So I decided to go with JTAG because it's a fairly straightforward way to accomplish our goals. JTAG is essentially a hardware debugging interface which will give you unrestricted debugging access to the processor core. Now the hardware for this stuff used to be pretty pricey but these days with OpenOCD and some of the open source developments here the hardware for less than a hundred bucks now. So with JTAG access we can remotely debug with GDB, debug the kernel, bootloader, so on. JTAG's been talked about to DEF so I'm not gonna dwell on it too much. So this is the hardware the bugger just connected to the motherboard. Now it probably seems obvious but the use of hardware the buggers and things of that nature have absolutely nothing to do with the ATM attacks that I'll be demonstrating. Simply used to initially gain access to the file system so we can reverse engineer to find vulnerabilities. Now speaking of JTAG I learned a valuable lesson when I was actually missing around one of the ATMs. I had the JTAG hooked up, screwing around, accidentally wiped out a massive chunk of the firmware which unfortunately overwrote some of the core ATM files. Now at the time I was unable to get the software for the ATM to fix it so I had to core a licensed ATM technician. And three of them came over to my house and again, you know, why do you have ATMs in your house? I said, oh, you know, I haven't moved into the convenience store yet or whatever. And anyway, so yeah, that's what happens, you know, I've never seen something completely annihilated stuff like that. And I was like, oh, I was just trying to change the splash screen, you know, I put in this little card and, you know, just crapped out and he's like, oh yep, yep, yep, they'll do that, they'll do that, you know. So the dude pops open the ATM and he's going on and I'm like firmware, what on earth is that, mate? You know, I'm just acting completely stupid. Teachers me a lot about hacking ATMs, I got his business card, we kept in touch, but I think possibly after this presentation that relationship may be severed. But so yeah, the lesson was always back up your firmware. So now that we can debug, we need a way to inject. Now with the debugger connected, we set a break point on create process, offset found by dumping the memory from the ATM and just doing a byte compare with an offline version of Corti LL. Now when working with the ARM process, the parameters on pass or function, the pass via registers before they utilize the stack. So R0 being the first parameter, it's going to have the executable that we want to execute. Now we simply replace the string of the ATM executable, reads from the registry, overwrite with explorer.exe. Now explorer.exe has to exist in the image for this to actually work. If not, you need to put a copy of explore on a removable disk and pass a full name to create process. But then you get a shell. So as simple as that really. Now when I was first playing with these ATMs, I was actually quite excited to have a shell on it. Had my ATMs playing movies and what not. But probably not really surprisingly, ATMs are pretty crap for playing movies. Filly slow flame rate and a six inch screen so they won't be replacing the home theater. Okay, so with explorer, we can plug in a USB drive and keyboards and copy off the files for reverse engineering. Modify the registries or explorers always gonna boot. Remote debugging with JTAG, of course, is not the ideal, with GDB is not the ideal way to debug a Windows machine. So the next step is to actually set up a more user friendly debugging environment. So as a way to debug Windows C applications, we're having Active Sync and that's a bug with Visual Studio over ethernet. You simply build an empty project, overwrite the local executable with the executable from the device you want to debug, with the TCP settings correct, it'll copy file from the device, and then you have application debugging Visual Studio. So now we finally have everything in place to be able to reverse engineer the software to locate the vulnerabilities, but also to test any software we create for the ATM. So finally we can get to planning an attack. Now of course there's a limited attack surface obviously. We have the card reader, but assuming we have an overflow or some other string based attack via the card tracks, is extremely limited amount of characters and a very restricted character set. I'm not gonna say it's not possible, but I'll say it'll be unlikely to be practical or all that reliable. The keypad's possibly a long shot, but you never know, maybe master passwords left in by developers, backdoors, what have you. And then the network, so any open ports, answering phone line, any options for any possible remote attacks. And of course the various inputs on the motherboard itself, but of course this requires access to the motherboard itself. Now of course progress is never really made without a few failures along the way, and my attempt to come up with a terminator to SCAC, I made this device. It's basically a electromagnet wired up to an amp which is connected to a media player. A web files created to simulate the data on a Magstripe. Electromagnets plugged into the card slot, you play the web and the ATM thinks it's just read a magnetic stripe. Technically it works fine, but it didn't help me for shit for finding vulnerabilities. Okay, so the walk up attack. The goal of course is to execute code on the ATM. Now the cash dispenser is housed at the very least by a safe. Even if that's if you take the cheapest option, if you spend more you can get some fairly heavy duty vault style protections. But the motherboard on the other hand is protected by, one key fits all lock. And this is standard practice as you can see. And like everything else on the internet, they're easily available to add to cart. And you can get keys for pretty much every major vendor. So one key safe will open all the models from that same manufacturer, the cabinet. Now, funny enough, the default keys used to be available last year, but they've somehow vanished. I'm sure of a little creativity they can still be acquired. So now with your master key, you have access to the USB slots and whatever other inputs. So you can pop open the motherboard compartment and insert a USB key within a couple of seconds. It's a lot faster installing a skimmer, of course. Now, even though the attack time here is short, of course, it's still the possibility for detection. That's the great thing about these retail and the standalone type ATMs. You know, they're in bars, they're out by the restrooms, out of sight, off by the sewing machine or something. But then there's also kind of the psychological aspect of ATMs, you know, it's considered kind of rude to look over the shoulder of someone that's using the ATM. Unless you're, of course, a criminal and if he was looking over my shoulder, well, he would learn a trick or two, I suppose. Now, all ATMs need ways to upgrade the firmware. And this is most often leveraged via the removable drives. So the ATM application will check the drive for a valid upgrade, a valid firmware is found. It will load it up, install and upgrade the device. And of course we can install whatever code we want to. Now, of course, the firmware is typically a proprietary format. Executables encapsulate in the firmware, there are checksums and encryption, but these algorithms are easily figured out by reverse engineering the code on the ATM side. So once you can create your own firmware package, it has the correct format, but you can then upgrades, but of course with a few modifications. Now, the remote attack, which is obviously the most important vector. So most, if not all ATMs are running some sort of Windows-based OS, support some form of remote monitoring and remote configuration. So this allows you to log into your ATM remotely, review or change your settings, get stats, change splash screens and so on. But another useful feature is the ability to remotely upgrade the software. Now this is sometimes a feature, but it's always something you can leverage if you have a vulnerability, right? Now obviously authentication is required to be able to do anything remotely. And this particular model, you require both a serial number and a password. And they're both made up of combination numbers and letters, five second delays forced after each connection attempt. So brute forces basically are the question. So we require a vulnerability within the authentication process itself. And it just so happens. So introducing Dillinger. Dillinger is my remote ATM attack or administration tool, whatever way you want to look at it. So we've talked about loading code locally on an ATM machine with the master key and the flash drive, the correctly formed firmware, your AC set. But the obvious drawback here is that you need to interact with the machine in some way. So of course the ultimate win is to be able to execute code or load software remotely. And that's where Dillinger comes in. Named after the bank robber, of course. So Dillinger takes advantage of a fairly serious vulnerability in the ATM remote management capability. And interestingly, although most operators don't actually use this capability, remote monitoring is enabled by default on all of this manufacturer's ATM, so charging. Now, typically to log into the machine remotely, require both knowledge of the serial number and of the password. Now, due to a pretty awesome vulnerability, I'm able to bypass all authentication on the device and the remote attack is 100% reliable. Now, Dillinger supports both TCP IP and it also supports dial up, because I heard through a fairly knowledgeable source that approximately 95% of these standalone type ATMs are using a dial up connection. So of course, back in the day, trying to find an ATM over the phone line would be a long process of nights and nights of war dialing. But thanks to tools like HDMor's Warbox, you can map out modems on exchange in a matter of hours and then just write a custom tool to find ATMs and you're away. So Dillinger allows you to manage the unlimited amount of ATMs through its interface. So you could add a group, say a city under this city, you can add each individual ATM that you found and either its IP address or its phone number. Now, the heart of the tool, of course, is the authentication bypass, which is the stepping stone to doing anything useful, really. So one feature in Dillinger is to be able to test the bypass in a way which confirms the vulnerability, but doesn't actually modify the remote system or leave any trace. So the obvious problem of finding a remote ATM is that you have no idea of the location. So I've added a feature which can pull the ATM settings, which includes all the master passwords and the receipt data, because you know each time you use an ATM, you look at the bottom of the receipt as the location of where it is or at least the name of the business, right? Upload a rootkit, and so that's not a bad feature. Bypasses authentication initiates the software upload, which lets me replace the firmware, so awesome. So in general, someone's going to need to be at the ATM if you want to get a payout, right? So I've had another feature so it would be possible to carry out an attack without ever visiting the ATM. When someone inserts a card, that track data is captured and I can retrieve that track data remotely. And finally, the remote jackpot, which I suppose speaks for itself, really. Now, introducing Scrooge. Scrooge is the rootkit I've developed specifically for ATMs, implements a typical rootkit technologies, hides itself by various C system calls, hooks, hides itself from the process list, hides itself in the file system, looking for schools filtering the results and so on. Now there's a hidden pop-up menu which can be activated with both a special key sequence on the ATM or inserting a card that has some custom track data on it. It'll run on any ARM or X scale based ATM until with a few tweaks. Originally it was designed for both Intel and ARM but it turns out that CE on X86 is actually pretty rare and basically non-existent in the ATM world. So the code for interfacing with the ATMs has to be customized with different ATMs as they all use different peripherals and fairly non-stated protocols for communicating. So I just use a standard set windows hook for capturing the side buttons on the ATM and although the API is actually undocumented and Windows CE still exists and it works as expected. So a combination of keys will trigger the menu. It's varied enough not to launch by accident but if maybe some kid's screwing around with it he might get a big payout but who knows. The card reader is hooked via an inline detour style patch so essentially where you patch in a branch instruction to a piece of code you'd like to intercept. Branch jumps your code, your code executes and then returns the original function. Now with the hook in place there's a check on the rebuff anytime a card has entered and if the second track matches gimme the loot it will bring up the menu as well. So the menu functions are fairly standard for what you'd expect. You can dispense from each cassette, print out stats which includes remaining bill counts and of course exit. So to add my own functionality I've added a few inline patches where basically if you patch in a few assembler stubs of the functions you wanna hook that stub calls functions in external TLL and executes any overwritten instructions and continues as normal. So this could be done dynamically but the fact that these specific ATM vulnerabilities allow me to replace the entire firmware and all the different executables I can make these patches permanent which is far more reliable. And it's also a lot easier on ARM as every instruction is 32 bits long. So I place hooks at the card reader, the pin pad and the parser that handles the remote configuration commands. So with those hooks we can add some fairly handy features, save the track data, capture the pin pad and a few custom remote commands. Get the track data remotely sure, remote jackpot might as well. So I've blitzed through these because there's a fair few demos I need to get through. So I may as well put my money where my mouth is now I suppose I guess there's a pun there somewhere. Actually let's start with the remote stuff first. Okay so we can start by adding a group. Hold on let me get this sort of thing sorted. So we'll make the group DEF CON we can now add an ATM. My ATM location I guess would be on stage at DEF CON. And so even though I support both modem TCP IP I just have this wired over crossover cable just for the ease of demonstration really. Okay so of course I can test the bypass which is important. This will allow me to ensure that the authentication bypass actually exists but won't modify anything on the system. So I'm gonna attempt connection, connected, testing ATM authentication bypass success. Now if you just wanna quickly flick over to the ATM now and get that on screen is that possible? So all that's shown on the ATM is that RMS process is just is RMS process basically. That's all that's seen. Okay now let's go back to the computer now please. Now of course the best is to be able to upload the root kit which will leverage that same authentication bypass to get there and I'm just gonna reiterate that this is default on every single one of these ATMs. So upload the final version of Scrooge. Connects sends the authentication bypass success initializes a software upload and now Scrooge is actually uploading to the ATM. That port is just default, say again? No I mean that's the port that they specify in the manual which interestingly enough can't be changed either. Okay if we could flip back to the ATM now. So basically once a root kit's been uploaded the ATM should reboot. Just says RMS process. So it realizes someone's managing the ATM they just don't realize that it's not legitimate I suppose. There we go so the root kit got uploaded the ATM's rebooting so now as it boots up it should have my root kit surreptitiously running in the background. Just let me know when that boots back up. Oh tried to cover the vendor's name but what can you do? Can I take one of those mics over there? Okay so as I said there's, we need to get actually on the ATM here. As I said there's two ways to pop up this remote menu. One is by the Gimmi diluted card and the other is by a special key sequence. So let's try it. Okay so it pops up my hidden menu there. Will let me dispense 50 notes from A, B, C or D which are the four cassettes on the ATM. I pronounced statistics like I told earlier. So let's just try to dump 50 bills from the first cassette. So these actually are doublers invites to the freak show party by the way. So yeah you can pop up the menu by the card but also by entering the special key sequence. And there we go. Okay can we go back to the computer again? So you've found this ATM but you of course you have no idea where it is. So that's where we can retrieve the ATM settings. Again uses the authentication bypass. Okay it's received the settings save into disk. So at the top here you can see the master passwords for my ATM, Barnaby's ATM. I actually don't live at one, two, three Kiwi streets by the way. But yeah so it has the your location, the master passwords as well as the phone numbers and also the IP address. Now so far all of these attacks have actually required someone to be at the ATM. And I require a volunteer from the audience now. Is Brandon actually here? I think he has a specific card created for this. By the way it was just any volunteers would have had all their credit card details displayed on the screen. So you have to be careful before you raise your hand. Yes that's actually another interesting point. They build the cameras. You can have the cameras built into these machines but via this remote management you can actually turn off the cameras or retrieve the images or even replace the images. Did you get your card back? Okay so I assume Brandon knows how to use an ATM so he's just entered his card. Okay we'll stay on the computer for one sec. So now I should be able to remotely pull the track data so this should have captured anyone's card that's been entered in there. Now you can see I had captured the gimme the loot card which was my original one to pop up the menu. Brandon's card, Dr. Raid of the Buster Cardi. I've never seen a credit card that says leet, leet, leet, leet, leet, leet, leet, leet, leet, leet before. Fair play. Okay if we go back to the ATM again please. Now of course you can't, you have to add the remote jackpot or just be rude not to really so let's try that one. It's connecting, sending the, we have a winner. And go down to the dispenser. What's that? Yeah. So I'll talk about that briefly at the end if I have time. But yes. Okay so, oh actually I almost forgot about the other ATM I'm sorry. So you remember that the attack on the other ATM, actually let me just make sure I have the correct firmware on it one sec. Okay so as you remember the attack on the other ATM is to simply pop open the compartment with your master key and insert the USB that has the correct firmware. I'm not very good at this, it takes me a while but should hopefully be in within three seconds. So that's the attack essentially carried out on that one and if we could zoom in on that one. Actually that's probably about perfect there. Takes a while to boot ARM processors, ARM9 is not the fastest. Now you're gonna have to forgive me because this was tailored originally for Black Hat so they might be a bit of, oh you'll see. It was also tailored for Vegas as well which you'll also see. Okay so, so that's just the, the Black Hat logo with the floats around the screen and it's just doing this as the ATMs actually initializing. So right now this is actually my firmware running on the device. Takes a little while to boot up. These aren't the fastest machines in the world unfortunately. Any quick questions while this is happening? What's up? I would say a year here on and off, you know. It's more of a hobby, sort of a nighttime job. And I think it has a better effect if I just open that first cabinet. Yeah it'll keep doing that. I'm just gonna disconnect the sound because it's kind of bugging me a bit. Yeah if you just go back to the computer again. So counter measures. So the obvious physical counter measure of course is to prevent the walk up attack is to offer upgrade options on the physical locks. That's where you have a unique key for each of the locks. Of course you want to take this into your own hands. You could just, you know, drill a hole and put a padlock on or something. If a trusted environment is set up which allows only signed executables to be run, this would have prevented the original attack and although it wouldn't have prevented the attack vector of the remote, it would have added another barrier for uploading these rogue executables. Now unfortunately in Windows CE5, implementing the trusted environment isn't as straightforward as it should be. Code has to be introduced into the build and I think the option to implement a secure environment should be made a lot easier. But what can you do now to prevent the remote attack? Disable RMS. High chances are you're not using that functionality. Disable it and that can be done from the operator menu. And finally it's time to give these devices a proper rehall. There hasn't been a secure development methodology in from the get go. So you need to play catch up at this stage. Have the code audited, penetration tests, implement these best practices from here on out. There's been a noticeable surge in the community I've seen to research these proprietary devices like ATMs. And the simple fact is these companies who manufacture these devices, they're not Microsoft, they haven't had 10 plus years and continued attacks against their software which is for secure development, development where they are today. So I think it's important, we dig in, research these devices, find vulnerabilities, find solutions and ultimately ensure a more secure future. Thank you.