-
everyone, I think, knows ATMs, used ATMs
-
and our security researchers there
-
have something very interesting to tell us about electronic bank robberies
-
and because them, please welcome our two security researchers with a very warm applause
-
tw: are we on?
-
okay, well
-
welcome to our little talk here
-
and thanks for the introduction
-
as the angel said, I guess everybody knows what an ATM is
-
it's basically used by people to dispense money from their accounts
-
either because they live in countries like this one
-
where you really don't use credit cards to pay
-
or because you don't wanna be tracked, right?
-
we're gonna tell a little war story here
-
and that's a case of ATM hacking
-
a real world incident that occured this year
-
and you wanna remember this number here
-
because that's how you enable the hacked system
-
in case it's infected
-
and I'm gonna hand over to my co-speaker here
-
to tell you about the first few things here
-
sb: yeah, okay, so let's just have a quick look
-
what do we have in a cash machine
-
so of course we have a safe
-
that's where we want to get in
-
there's the money, we want to spend
-
so of course we have a normal computer
-
it's like a desktop computer
-
mostly it's running a normal operating system
-
most likely it's Windows XP
-
and with just a few different manufacturers that build the teller machines
-
and, yes
-
we as user, we use a common user interface
-
it's just a screen - most likely it's a touchscreen
-
or we have then the EPP number pads
-
where we put the PIN number for our card
-
tw: one thing I would like to add to this slide
-
you see the picture on the right hand side
-
that's a photo we took yesterday when we arived here at Hamburg main station
-
and it's interesting, because this is the state hacked ATMs are usually in
-
befor the bad guys go there and cash out
-
I don't know - maybe this one is infected, too
-
sb: this is not the first ATM hacking, of course
-
the most famous one was from Barnaby at the Black Hat in 2010
-
you see in the screenshot here
-
this was the user interface of his malware
-
so from the functionality it's quite alike
-
but not as nice
-
tw: has anybody in the room looked at this Ploutus thing by any chance?
-
no...
-
sb: okay, so of course we have a lot of POS malware
-
from mobile terminals
-
to steal just sensitive information
-
like the credit card data or paymant data or something
-
and the most famous ones this year even was the Ploutus malware
-
probably you've heard about it - quite famous
-
we had a quick look at Ploutus, too
-
it was written in .NET
-
from the functionality it's similar or the same
-
but not as advanced
-
why are we standing here and talking about this case?
-
we had an incident
-
a bank, they discovered, they had a lot of
-
empty teller machines and they started to
-
work in investigation for themselves
-
just a little bit of forensics and it was just limited success
-
but yeah, they had to do something about it and they tapped up surveillance
-
and improved monitoring
-
and they started to discover that the infection was conducted via an USB stick
-
they get to mange to arrest the guy and to secure this USB stick
-
and on the USB stick we found actually that malware and started to examine that
-
tw: yeah so to re-address that, before we go on
-
what they did was: they figured "okay there's something going on with our ATMs"
-
and they improved their surveillance technology, if you will
-
and then saw that guy trying to cash out from one of the hacked machines
-
and then they went there, arrested the guy
-
and confiscated the USB thumb drive that he was carrying
-
and that's where we started our analysis
-
right
-
sb: they plugged in a USB stick
-
they broke a small part of the chassis
-
it's just PVC, so it's not hard to break that
-
and they plugged in a USB device and forced the ATM to reboot
-
so you can do that by cutting the power off
-
or putting down the LAN interface or plug it out
-
they forced the ATM to reboot and therefore to reboot from the USB device
-
and what we found on the USB device was just a simple image of a Hiren boot CD
-
everyone can just download that
-
and within that Hiren boot CD it's just a mini XP running
-
and you have a folder where you can just put customer executables
-
that will automatically be started when the XP is booted
-
within this customer section we just found our malware
-
it was a batch that was called hack.bat
-
just very nice
-
so actually we thought that this is probably a fake
-
because they just wanted us to examine the wrong file
-
to save some time
-
because it was just that obvious
-
you will have a look at bat script afterwards
-
so you can see what I mean
-
so yes, it's just a mini-XP
-
you have the hack.bat
-
and this will actually start the real malware
-
the so-called atm.exe
-
and yeah... what we found then besides the bootable device on the stick were some very interesting files
-
they were obviously copied from the infected ATM teller machines
-
we can tell that, because there were three different ones that we found there
-
and it was very interesting what kind of data were copied from the ATMs
-
we found data like system data
-
like for example the software hive key
-
a lot of files that have cache data, credit card data, payment data, someting like that
-
from each of the infected teller machines
-
and of course we have our atm.exe
-
that was really interesting
-
and we take a quick look at the hack.bat script
-
so you see, it's very user friendly
-
because they implemented a lot of very interesting switches
-
we see, right at the top, that he begins to copy the software hive key of the infected machines
-
and at first he's checking if the system is already hacked or if he has to do it
-
the switches you can see here
-
they are all implemented
-
the most used one is of course "-hack"
-
we see otherwise, that you have some functionality like clear log files
-
or get the log files
-
this is the part where he copies really interesting data from the teller machines
-
of course the question is: why does he do that?
-
we answer that later
-
it also has got a functionality on it that he can cover his tracks
-
you can clear all files of the malware and remove it also
-
a little bit more about the installer of the atm.exe
-
tw: yeah, thanks
-
I mean of course we were curious
-
now that we know how the system gets infected
-
insert the USB drive, force a reboot and then the batch script runs
-
we were curious: how does the actual cash out process work?
-
how do you get money out of the thing?
-
what we did was
-
we took this atm.exe file - the executable
-
and reverse engineered that to recover the funtionality
-
and the next couple of slides talk about what we found in this executable
-
first of all
-
the atm.exe is a UPX packed thing
-
UPX is one of the standard packers
-
you can easily unpack the original code again
-
and then we came across an interesting fact
-
so we unpacked it and loaded it up into our analysis tools
-
what you can see on the right hand side
-
it's a little bit blurred, but we hope you can still read it
-
is IDA Pro, that probably many of you are familiar with
-
one of the state-of-the-art disassemblers
-
so we loaded that file up into IDA Pro, took a look at the code
-
and then we discovered something interesting
-
we discovered that the original executable contains a resource
-
if you are a little bit familiar with the PE format
-
the executable file format on Windows systems
-
you might know that there are containers that you can use to store additional data
-
or attatch data to a binary
-
they are called resources
-
so this binary had a resource and there was some encrypted data in there
-
which turned out to be a DLL that contains the actual malicious functionality
-
and the interesting thing is that this resource is XOR-encrypted
-
now XOR is not a particularly strong encryption scheme
-
but never the less, if the key is long enough
-
like 4 bytes in this case
-
I mean you can still probably brute-force it
-
but well, you know
-
we figured that every executable that's deployed onto an ATM has the resource
-
encrypted with a key that is derived from the volume serial
-
which is an ID that is assigned to a hard drive when it's formatted
-
by the operating system
-
that means that every executable that's deployed onto an ATM is taylored specifically for this ATM
-
so it's not mass-malware that you can install on any ATM
-
each executable only runs one one very specific ATM
-
and that's interesting
-
I mean of course that raises the question: How do they get this ID in the first place?
-
How do they create this binary with the encrypted resource?
-
Where do they get the volume serials from?
-
and there are basically two options
-
I mean we don't have the answers to these questions
-
but there are only two options
-
one is: they go to the ATMs the first time, run their stuff
-
and extract the volume serial ID from the system
-
then go home, prepare the malware and then come back to infect the system
-
which seems kind of risky, because
-
if you get caught while doing this... well then
-
you'll lose something
-
the other option is...
-
we'll leave that to your imagination
-
so what we did
-
what you see here on the right hand side is some code that is executed after the XOR-decryption of the resource
-
and if you look closely enought you can see in the first basic block up there
-
it checks if the first byte of the decrypted data is an "M"
-
and then the next one checks if the next byte - the second byte - is a "Z"
-
which is part of the PE file header - MZ header
-
so we figured: okay, this is probably an executable
-
and that's how we recovered the original code
-
we assumed that this is an executable and then
-
you can call it a known plaintext attack or something like that
-
we reverted the XOR-encryption and recovered the DLL
-
and after this happened, of course
-
the dropper runs some checksumming code
-
to verify that the extracted and decrypted code is actually the DLL it wants to run
-
so after we recovered this malicious DLL
-
we took a closer look at that one
-
and it's dropped into this path up there under the system directory
-
and the value in the squared brackets over there is again derived from the volume ID
-
so if you come across one of these DLLs
-
you can take a look at the file name
-
and that's linked to the ATM it's supposed to run on
-
because of the naming scheme here
-
so that's how - and of course I mean you can see all of that in the code
-
that the second value there is hard-coded
-
that's how we figured: okay this sample was supposed to run on an ATM with this volueme ID
-
and then we came across something else
-
something that's as interesting
-
this DLL, or the malware in general writes a log file
-
and stores this on the USB drive that's used for the infection process
-
and that's pretty verbose
-
if you look at this
-
again we have to apologize that's it a little blurry
-
but there you can see
-
it's basically what is executed when the batch script runs, right?
-
there is a file name up there
-
if you can see that 978-blablabla DLL and some others
-
and suprisingly this log file contained information about three other infections that took place
-
so we switch to the next slide
-
with that information we can say
-
we have information that these guys infected at least four ATMs
-
the ones where we had that DLL for
-
and then these other three
-
that we recover from the log file
-
log file - again - is XOR-encrypted, but the key is hard-coded
-
so we could recover it from the code and then decrypt the log file and read it
-
this is an abbreviated version
-
the most interesting lines from the log
-
you can see that these ATMs run in fact Windows XP
-
yeah...
-
sb: what probably is quite intersting here is that we have information about three different teller machines
-
that were infected with this USB device
-
in clear text and we have it additionally in this somehow encrypted log file
-
so the question is: Why do we have that twice?
-
Why do we have this log file?
-
And why didn't they remove that files?
-
actually for every new infection they have to build up a new exe device
-
which is encrypted with the volume serial ID from this machine
-
and they would have enough time to clear that up
-
but they didn't do it
-
so furthermore the question broke: Why didn't they?
-
tw: okay, now in this part we wanna talk a little bit more about the actual payload
-
the malicious code that's executed on the compromised ATM
-
you know, the interesting bit
-
what you can see here is a list of some facts that we discovered
-
again this file contains some encrypted resources
-
this time they're encrypted with the static key that you see up there
-
so by looking at the code we obtained this key and could easily recover the resources
-
and they contained images like the one you see on the right hand side, up there
-
obviously stuff they wanted to display on the ATM screen, right?
-
we changed the coloring scheme and some other stuff here a little bit
-
because we don't wanna disclose the target here
-
yeah that's what they store in these resources
-
another thing that was in there, is this sdelete tool from Sysinternals
-
maybe some of you are familiar with that
-
a publicly available tool for secure file deletion
-
so you know, you override the file with specific byte patterns before you remove it
-
and they used that to remove forensic artefacts
-
forensic traces from the system
-
for example when they're uninstalling the malware
-
because you can also uninstall it from an ATM
-
but in case this fails for whatever reason, they have some backup code in the malware
-
some backup secure undelete code that does basically the same stuff
-
it overwrites the data first and then it deletes the file
-
so it's kinda interesting that it put a lot of effort into
-
covering up their, you know
-
hiding their traces on the system
-
and by the way
-
we will give you a demo in a few minutes
-
and show you the whole process
-
how you interact with an infected ATM
-
you will see the other screens as well
-
then of course for most malware it's important to become persistent on the infected system
-
because when it reboots for whatever reason, you want the malware to automatically load again
-
and these guys do that by writing the drop DLL into the AppInit DLLs value in the windows registry
-
for those of you, who are not familiar with the value
-
you can specify libraries in there that are loaded into every process that starts up
-
so by this you make sure that the malicious DLL is loaded into every proess that starts
-
within the current logon session at least
-
what you see down there is some decompiled source code
-
basically the main function of the malware
-
of the DLL
-
and what you can see there
-
there are several checks running in cash client one
-
cash client is the term for the software that controlles the ATM
-
that is running on the ATM
-
and controls the dispenser and so on
-
so it does this check and if this returns true, it starts some routine
-
and if some other checks succeed, then it calls some other functions and so on
-
basically what's happening here is that the DLL checks the name of the process it's running in
-
and then depending on this name it invokes certain functionality
-
and we believe that by doing this they implement support for different cash clients
-
this line down here, running in lsass.exe is also interesting
-
because the DLL is also obviously loaded into
-
what's lsass again? local system...
-
some windows process
-
is also loaded into that one of course
-
because of the AppInit thing
-
if it's running in this, it doesn't interact with the cash client ATM software at all
-
the DLL that's running in there is an event processor
-
for example, if you wanna uninstall the software
-
you basically create an uninstall event
-
and then the instance running in this process here
-
handles the event and removes the file and so on
-
and cleans up all traces
-
sb: what's also quite interesting here
-
you can see that later on, when we discover the malware itself
-
they have really somthing like a development cycle
-
it's really professional made up
-
because within the first infections we could find this malicious DLL within this AppInit hive key
-
there was an incident where the forensic team could discover it there
-
because it's quite obvious, you know
-
the AppInit DLL key is very famous for any malware
-
that should start at startup
-
and they improved it
-
so later on, they just added this malicious DLL to the DLLs which are started
-
just when the cash client is started
-
so it's also started from the startup, but it's not as loud
-
so you have to have to search quite deeper to find it
-
tw: Where are we? Are we on time? How are we doing?
-
How much time do we have left?
-
okay, plenty of time
-
great
-
so we know, how the malware becomes persistent
-
we know how it makes sure that it runs on the system
-
so it injects this DLL into all these processes
-
now of course we wanna know how to interact with it
-
because there must be a way of interacting with the malware
-
and what we found out by reverse engineering code is that the DLL that's running in the cash client
-
installs a hook for keyboard events
-
so whenever you press a key on the keyboard which in this case is the num pad
-
this is trapped by the malware and processed
-
and what they do is, they process only number keys
-
for obvious reasons
-
because that's the only kind of keys that you can enter
-
and if you enter the code that you've seen on the first slide
-
you activate a hidden menu that allows you to choose the several options
-
that you can use to control the ATM
-
but they have implemented an additional measure
-
because, you know, it's possible that somebody by accident enters the right 12 digits
-
and then suprise this thing pops up
-
and you can dispense all the money from the ATM
-
of course they don't want that to happen
-
so they have implemented a challenge-response scheme
-
so when you enter the 12 digit code, the first menu allowes you to say
-
present me with a challenge
-
and then the malware generates a random or like a secret code
-
where the scheme to generate it is secret
-
and you have to enter a response
-
that's not easy to crack
-
what they do in this case
-
because of the poor guy who goes to the ATM to cash out is not the brain behind the whole operation
-
they're likely to get arrested
-
so they probably don't want to transfer the knowledge
-
how to generate the response for the challenge to these people
-
can you tell the story about the phone calls?
-
sb: yeah, actually they had a surveillance video where they could monitor just one of their cash guys
-
which just currently had entered the secret 12 digits
-
and you can see on this video that he has already one part of this hack view
-
and after that he just took a cell phone
-
and called somebody and you can see that within that call
-
he types another number and right after that, he starts cashing out the teller machines
-
that's exactly that challenge-response check, he was talking about
-
so this proves that they don't want anything to chance
-
they wanna control which teller machine is cached out and exactly when and who does the cash out
-
so this may implicate that they don't trust their own people, do they?
-
tw: so, I mean we tried to bring you this video where the guy makes the phone call
-
but obviously the bank that was targeted here
-
they're a little concerned about their identity beeing disclosed
-
so unfortunately we couldn't get it
-
but, well, you have to trust us on that
-
that's how they probably do it
-
another thing is that these guys already anticipated that somebody would get a copy of the malware
-
and then probably start to reverse engineer it
-
and understand how it works
-
and of course the worst thing that can happen is
-
if somebody recovers the challenge-response functionality in that code
-
and then goes to all the hacked ATMs and, you know, jackpots them
-
insted of these guys
-
so they figured: okay, we need a means to protect that really important code
-
and that's not the only part, that's protected
-
there are several pieces that are, you know, critical
-
so to speak
-
so this challenge-response thing is one of them
-
and the other parts that are protected is everything that interacts wih the cash client
-
so by looking at the code you would never see a direct API call or DLL function call
-
into the cash clients libraries
-
all of this stuff is protected
-
and I'm gonna talk a little bit more about how they do that
-
it's a little bit hard to put that...
-
to find the right words for it
-
we have a picture of that in our mind, but...
-
we call that a state machine
-
so their obfuscation method is basically control flow obfuscation
-
when you look at some code statially, you can see this function is calling that function
-
and then this is calling that under this condition and so on
-
that's the control flow in the code
-
but if you don't wanna disclose that function A is calling function B
-
you have to put something in between
-
that obfuscates this relationship
-
they implemented a state-machine
-
that's what we call it
-
and this state machine consumes a buffer
-
a static buffer that's somewhere in the binary
-
and performs some computation on the bytes
-
and the result is the address of the function to call
-
at some point you say: state machine, here is a buffer
-
do your thing
-
and then the state machine starts computing the address to call
-
or that's only one scenario
-
the other scenario is that you wanna compute a certain value
-
for example, you enter the response for a particular challenge
-
and then the state machine with its functions computes some other value
-
that it compares to a challange or something
-
and this computation as well is protected by the state machine
-
and you can see a little snippet of that on the right hand side
-
again, if you can read it, you can see there's a lot of junk code in there
-
those of you who are familiar with polymorphism
-
polymorphic malware or other stuff like that
-
you will immediately see that some of the functions in there are total garbage
-
like for example, the SUB AL e1
-
and then, you know, some values are subtracted from a register first and then added again
-
so it's basically doing nothing
-
this junk code stuff is one method of obfuscation
-
and the other is, what's usally called "spaghetti code"
-
you know, it's jumping back and forth
-
and calling subroutines all over the place
-
and I think it's really hard or next to impossible to reverse engineer that
-
at least we spent several days
-
weeks even
-
and we couldn't really figure out how the state machine works
-
and that's really the purpose
-
but fortunately for us there was a solution for this
-
and that is what the little colored bar at the bottom of the slide shows you
-
again, this is something that IDA Pro generates for you, this disassembler tool
-
you can see the blue stuff at the front
-
that's the real code of the malware
-
all of that lives in the code section
-
and is at the beginning
-
and the green stuff here is library functions
-
here we have some data
-
and at the end there is some code again
-
and suprisingly this is the state machine
-
and it's pretty convenient for us that this is somewhere else in the memory layout
-
so what you can do is
-
you can put a memory break point a the section here
-
and by doing this trap every attempt to execute the state machine code
-
and then when you're in the state machine
-
you put a break point on the original, on the real code, up there
-
and you get the exit point of the state machine
-
by doing this you can basically treat the state machine as a black box
-
you don't care about the calculations at all
-
you can still reconstruct the relationship between the calling function and the callee
-
okay
-
unfortunately we couldn't use this break point method to understand how these value calculations are performed
-
but, well, you still can inspect memory and somehow understand a little bit of that somehow at least
-
okay now we wanna demo to you how this thing looks like
-
unfortunately we don't own an ATM that we can infect
-
but we have a virtual machine here that's running the malware
-
and we've patched the malware a little bit here
-
I think we didn't tell you
-
so what's happening is these screens when you enter the secret code
-
these screens that you saw on the slide
-
they're displayed on a second desktop
-
on Windows you can have as many desktops
-
like virtual desktops as you want
-
and then switch back and forth between these desktops
-
so what's happening is
-
these screens are displayed on a second desktop
-
and then execution switches over
-
the displays which is over to this desktop
-
so you leave the original ATM display and it's process alone
-
you just switch over to your secret menu desktop
-
and when you're done, you can switch back
-
that's a little difficult to debug
-
because when you do that, when you're running in a debugger and using break points and stuff
-
and the malware all of a sudden switches to a second desktop
-
you can't control the debugger anymore, because it's running on the first desktop
-
so we had to patch a few things to make it more convenient for us to demonstrate this
-
and that's what we're gonna do now
-
can you...?
-
so we have this little Windows XP VM
-
because we want to be accurate, right?
-
and I'm gonna start two processes here
-
one is: I have some little batch scripts
-
one is the one that simulates the malware running in the lsass process
-
and the other one simulates the malware running in the cash client
-
this one here
-
and let's just presume that this is showing the stardard ATM screen here
-
so "Enter your PIN" and stuff like that, okay
-
so what we're gonna do now is
-
we're gonna enter the 12 digit secret code that we saw on the first slide
-
you remember that, right?
-
and if you do that, you're presented with this menu here
-
do you wanna talk about those values? how that's calculated?
-
sb: yeah probably
-
so the only thing which is hard coded are the three lines at the bottom here
-
and all of the rest is just generated with the actual amounts they find on this ATM
-
so the ATMs, they have a lot of loo files which they create
-
and they're just saved on the hard drive
-
and within that files
-
every payment transaction is noted
-
what the malware does is
-
it requests the newest of that files
-
and just pulls the values into that screen
-
and so the attacker is presented with the actual value of the amount of money
-
and there he can just choose which one he wants to cash out
-
so just the 100 bills, or all of them
-
this is quite interesting
-
we took this screen from an ATM which was already attacked
-
there you can see that especially, or only the $100 cash cassette was cashed out
-
because, you know how long it takes if you're just cashing out 100 or 200 Dollars or Euros
-
and if you can imagine if you have a whole cassette full of money
-
that takes a lot of time
-
so this is why they most likely just cashed out this cassette with the most valuable input
-
tw: so what I can do now is
-
I can either press "0" and then I leave that again
-
and, you know, ATM shows its standard screen again
-
or I press "1"
-
I'm gonna do that now, just to show you what's happening
-
and now it's challenging me with this code here
-
and I have to enter the response
-
and yeah, I mean, it's a 6 digit number
-
the problem is
-
because we're not running on a real ATM, we cannot simulate this here
-
so I mean, I can enter a number here
-
but even if it would be the right one and it would accept this
-
we wouldn't be able to go any further, because some pieces are missing here
-
unfortunately... let me restart this
-
there we go again
-
usually what happens is
-
you press "1"
-
you get the challenge code
-
you call your HQ
-
you get the response code
-
you enter your response code
-
and then you have access to this second level menu, so to speak
-
that allows you to actually cash out
-
well, as I said, we cannot really do that here
-
so we have to simulate the fact that we're authenticated
-
we entered the right response code
-
for that we patched a little bit in this DLL
-
unfortunately we have to wait for three minutes now
-
because there is a timeout
-
they implemented a timeout as a measure to not leave this screen open
-
when, you know, something happens
-
the guy has to run off or something
-
because police is coming or something
-
and then you don't want to leave this on the scren
-
so they implemented a timer that fires after three minutes
-
and then after three minutes this window is closed
-
we patched this timer, that after three minutes the second layer menu is opened instead
-
we have to talk a little bit more, until that happens now
-
sb: probably about the version number
-
cause there you can see, they named their software
-
typical software style of course
-
with a four digit value number
-
so they have really a development cycle
-
for this malware
-
and they really are improving that with nearly every attack they are doing
-
they collect all facts they have, they improve antiforensics
-
and build in a little more functionality
-
you can really track these changes, they made
-
this developement improves
-
tw: another thing we can tell you meanwhile is that this challenge code is generated from two things
-
again, we don't know how it's generated, we don't know the algorithm
-
but we do know the input
-
and the two things that are the input to this algorithm
-
are an ID that's unique to the ATM
-
or the station, whatever you wanna call it
-
and a random value
-
so there's some randomness in there
-
by this you make sure that even if the same random value is chosen
-
the codes are different for two different ATMs
-
so the guy has to in fact call you and ask for the code
-
he cannot, you know, just by accident enter the right thing and take the money for himself
-
alright now would be a good time for the timer to fire
-
let's see
-
okay, I have another story
-
the dropper executable
-
when something goes wrong, they calculate an error message, an error code
-
oh, there we go
-
and this error code is derived from the value 1337
-
so apparently they think they are leet
-
which didn't really stop us from reverse engineering their software
-
this screen is like what we showed on the second slide
-
which basically says "this terminal is out of order, go to the next one"
-
and when you see this
-
I mean, two purposes:
-
one: others who want to dispense money from the ATM, if they see this, they would not touch it
-
and go to another one
-
but this also tells you that now you can enter another code
-
which turns out to be the same 12 digit sequence that we already know
-
to enter the second hidden menu
-
and there we go
-
this is now the real menu that you can use to control the ATM
-
again, you see the first four lines show you how much money for the different bills
-
or different notes is in there
-
but now you can actually, you know, cash out
-
you can dispense that money from the machine
-
so for example if I press "1", hopefully I can get the 300 R-Dollars
-
or if I press "4", I can get the 50s
-
so let me do that now and you can pay attention to the purple line at the bottom
-
so I press "4" now
-
and it said "wait" or "waiting" or something like that
-
and now it says "command has failed"
-
which is too bad because I wanted money, but my VM...
-
the emulation is not that good
-
sb: still didn't get to manage to really cash out some money from that machine here
-
tw: that would be nice
-
so I could now try to cash out 1, 2, 3, 4
-
and always I get this failure message
-
but this is where the malware actually interacts with the cash client
-
it loads, or resolves the libraries that belong to this cash client and then calls the API functions
-
to trigger the dispense functionality
-
but the other options at the bottom of the screen are also interesting
-
let me show you "7" and "8" first
-
and that's why I have this little window open here
-
I hope you can see that
-
so this is my network connection
-
the network devices that are installed
-
and as she said, every ATM has a persistentnetwork connection to the bank
-
so they can control what's going on and monitor and so on
-
so probably before you wanna cash out, you wanna disable the network entirely
-
and they can use "7" and "8" to do that
-
so let me press "7", you take a look at that window on the right hand side
-
you can see, the adapters are disabled now
-
and now I'm going to press "8" again
-
and now they're enabled again
-
that's convenient, right
-
so you can disable and enable the network adapters entirely
-
if you press "6" you're going back to this mode
-
and finally you can also format the system
-
I mean obviously because you wanna remove all the traces
-
so if I press "5", you see that little screen, that we already know
-
from the slide
-
they're somewhat cautious here
-
again, if you do that, you can either press "0"
-
then you get back to the previous menu
-
or you can press "9" and confirm that you actually wanna format the system
-
and doing that' now
-
and again it presents you with a challenge and you have to enter a 6 digit response code
-
the algorighm that's used to calculate this here is different from the previous one
-
and I mean we figured it out somewhat
-
but the funny thing is, that it doesn't actually format the system
-
it just uninstalles the malware
-
I don't know what the right answer to this is now
-
if you enter the wrong one, it keeps asking
-
and interestingly you cannot get out of this state anymore
-
so if you don't know the right answer, you're trapped in this
-
and after three minutes the "out of order" thing is displayed again
-
but if you enter the sectet code, you don't have access to the main menu again
-
you will always end up in this screen
-
so unless you enter the right code here, well, you locked yourself out
-
alright
-
we wanna conclude with some speculation about the people behind this maybe
-
we obviously don't really know who it is
-
but, you know, there are some interesting facts
-
and after that we'll open it up for questions and, you know, a little Q&A
-
sb: what we really can tell for sure
-
that they want to make serious money with that
-
they put a lot of effort in implementing and investigating
-
in coding actually
-
they build up quite a big team to do that and they have apparently different roles
-
that are strictly assigned
-
so every role has his part and is able to do his part
-
so it's quite separated
-
for sure they have to have profound knowledge about the ATMs
-
so most likely they really had one
-
to test all these features and to really check whether the coding is correct
-
whether they get any error messages
-
something like that
-
so either they probably robbed one and reverse engineered the original cash client
-
to derive the malware from it
-
or they most likely had someone in the inside
-
which was just to...
-
which had to develop the original cash client
-
and therefore really knows exactly how this works
-
how it's possible just to trigger a cash out
-
without entering a valid card, the PIN code
-
circumvent all the security measures that are implemented here
-
they have quite good development skills
-
so the code is quite sorted
-
you see the development cycles
-
they implement new features just like the AppInit DLL key stuff and so on
-
at least they are capable of protecting the code against people like him
-
they're just trying to reverse engineer malware
-
and they really try to cover their tracks for forensic investigations
-
so they made it really hard to get the pieces together
-
to just have a full image of how that finally works together
-
tw: alright
-
that was almost the last slide
-
you guys remember the 12 digits
-
from the first slide
-
so next time, before you dispense the money from an ATM, enter the 12 digits first
-
to make sure that it's not hacked
-
right, and if it is hacked
-
then you enter this here
-
because that uninstalls the malware
-
applause
-
well then we do a short Q&A, if it's okay for you
-
please, everybody that has a question
-
please line up on the microphones
-
signed with the numbers
-
and then we will do a short Q&A from approximately 8 to 10 minutes
-
alright, let's start with you
-
hi, I have two questions
-
the first question is whether they were gathering PIN codes and no strips
-
to be able to use them later on
-
and the second question is whether the ATM is connected to the Internet through the network connection
-
I didn't get all of that
-
can the others be a little quiet
-
so we have the chance to understand the questions
-
sorry, can you please repeat?
-
so my first question is whether the PIN codes and this magnetic strip
-
or any other information linked to the credit card number is gathered by this malware
-
and the second question is wether net network connection gives Internet access to the ATM
-
let me answer the first one, and for the second one, I'll refer to her
-
so this one could gather information like credit card stuff and so on
-
but it doesn't
-
not this one
-
I didn't get the second question
-
second question was: can you access the ATMs over the Internet? is there internet connection?
-
no, actually they do not have an Internet connection
-
but it is possible to build, so far
-
we did that in a test, where we tested an ATM
-
you can use this USB connection where they plugged in the bootable device
-
and just put an UTMS stick there and then you have an Internet connection
-
but by default there is none
-
but we did that, yeah
-
okay, then let's take number 1
-
thank you for your talk
-
I have two short questions
-
what was the time span between the infection and the cash out?
-
and did the attackers try to intercept card data?
-
so, the second question is the same as the previous one
-
they don't intercept any card data
-
they don't gather like credit card information and stuff like that
-
they only like jackpot - as Barnaby Jack called it - the ATMs
-
they only dispense money from the ATM
-
for the first question, what was the first question again?
-
what was the time span between the infection and the cash out?
-
how much time is between the infection and the actual cash out
-
we discovered that were only two to three days
-
so they could have any time between that, but they really try to make it short
-
and of course they waited for the right time, so right after the recharging
-
because thats the point of the most money
-
okay, then number 3 please
-
hi, thank you for your talk
-
question about banking security
-
this beeing Windows XP, I missed the part of code signing
-
and verified publishers and such
-
do banks employ these security measures or not?
-
they do have security measures
-
but they're only implemented when the XP is running
-
so they have whitelisting for applications
-
they have monitoring for the process
-
and they have an anti-virus
-
and of course something like that
-
but in essence everyone can dump their own software on it and run it
-
there is no whitelist for signatures or publishers, right?
-
there is a whitelist
-
actually there is, but that was the point why they did that
-
via bootable USB stick
-
because they wrote this DLL just within the system folder
-
and they have a whitelist for applications, but not for the DLLs
-
which these applications are using
-
I mean, it goes without saying that you can take measures to make the ATMs more secure
-
because this is kind of a trivial attack
-
and as you said, everybody could do that
-
and that's kind of the reason why we're giving this talk
-
it's no use in keeping vulnerabilites secret
-
they should be like talked about openly
-
and then people can go and fix their problems, right
-
thank you
-
do we have a question from IRC or the community out there?
-
yes there was one question coming from IRC
-
which was: how to get on the USB printer port to reverse that machine?
-
can you repeat the question please?
-
how to get on the USB port or printer port to reverse that machine?
-
this was just via cutting a hole into the chassis
-
so this is just a...
-
this is no metal, this is not a safe
-
so this is just a plastic
-
and there you can just cut a hole in it
-
and then you can actually access the USB port
-
I mean, they physically damaged the ATM to be able to access the USB port
-
and then they had to cut the network connection
-
and that triggered a reboot
-
so it's really a trivial attack
-
not that hard
-
okay number 4 please
-
yes
-
two part question
-
you would think that banking and money would be a high priority thing to secure
-
why are they using Windows XP?
-
and the second one is
-
applause
-
second one is
-
if there was a time-frame of I think it was three days between the two attacks
-
why don't they realize, there is hole cut into their ATM and just...
-
change it out?
-
applause
-
there is a...
-
that depends on the USB port that they used
-
there is one on the back, so you don't see it
-
and the other is just...
-
you can cut that very exact and then they just repaired it afterwards
-
they just fixed it
-
and for the first question
-
the problem in the main cases is that there are hundreds of thousands of teller machines
-
for each bank
-
and that's just the problem
-
they are of course starting to renew that
-
but when they are at the end doing that
-
Windows has already realeased two newer versions of operating systems
-
and that's one part of it
-
and the other thing, if we had Windows 7 here it wouldn't change a thing
-
I mean, that's probably a question for the banks that we can't really answer
-
but as long as they're convered by insurances
-
they don't really have to care
-
which is of course kind of short sighted
-
but maybe thats how it works
-
okay and now the last question from number 1
-
hi there, I was just curious about this particular ATM model
-
if we're framing this picture of this is let's say the state of security and ATM technology
-
or if it's just let's say an example for how to not build an ATM
-
I mean are these bad guys simply the first who found out
-
well it's basically that simple
-
or is it just let's say a really bad model, they have exploiting?
-
that all depends on the original cash client
-
so the teller machines are all the same, but every bank has an own cash client
-
it's an own software which is really doing the cashing out
-
and they're all different
-
and you have to develop the malware exactly for just one cash client
-
because it won't work on others
-
I mean, sorry
-
I mean also speaking about this physical security
-
I mean, having an easy accessible USB port
-
and booting USB images without any additional security measure
-
I mean, is this state of the art?
-
no, it's not
-
actually this has been fixed
-
because there is an whole disk encryption in place now
-
that just prevents this way of attack
-
but yeah, it's not at all teller machine currently implemented
-
so yes, it's kind of state of the art
-
yeah, great, thank you
-
okay then now
-
thank you to our security researchers
-
give them a great and warm applause, please
-
thanks for coming, thank you
-
subtitles created by c3subtitles.de