From: Omar Herrera (oherrera@prodigy.net.mx)
Date: Sun May 15 2005 - 14:08:48 EDT
You can do them from the network or on-site. You most probably want to test
them from the network. Installations vary from country to country and from
bank to bank. You will rely a lot on physical security to assure
data/processing integrity on the ATM itself. Here are a few suggestions:
Physical, on site assessment:
* Verify physical integrity of the box
* The slot for cards should not show signs of tampering
(You can find histories of false card slot attached to
ATMs to steal card information, or the card itself)
* Network/phone and power cables should be properly secured
(i.e. not visible and out of reach). I saw once an ATM inside a
Bank
exposing the UTP cable, following it you would find an unscrewed
panel with several other UTP cables going into the bank... one
wonders if banks are really safe places :-)
* verify that there are no open doors and panels in the ATM box
Logical, on site assessment:
* Try to brute-force an error on the system (common black box
approach to test input validation/timing applies). You might need
to use a valid card and get some bucks from your account actually,
to be ably to fully test the application.
Some ATMs run over O.S. like Windows, I've seen some of these exit to the
desktop, it seems difficult to navigate with only a numeric keypad and some
selection buttons, but if you are lucky... (Note that I was NOT pentesting
when I found these. I've just run into 3 of these boxes which happened to
have some fault in the application, while I was going to get some cash, they
were in that state before I even got there... So I'm not sure if the
application simply crashed or if someone was actually tampering with it
before.)
Logical, network assessment:
You will first need to get access to a network from where these devices
and/or their communications are visible, some are network based but I know
that some devices use modems and PSTN. Once you are able to see the device:
* Do network level assessment (portscan, banner id, the device, then
do app. level testing, like any other application).
* Verify that communications between the device and bank servers are
encrypted (or at least isolated somehow). If you see patterns that
repeat after using the ATM several times, then the communication
might be just encoded but not encrypted.
* Do network assessments on servers that interact with ATM's
(compromising an ATM is bad, but compromising servers that
store/process data from several ATM's is far worse. Therefore
these should be checked).
* Verify integrity controls. Try replaying a captured session or
injecting spoofed data
As usual, check your contract's scope and liability statements. Be aware
that ATMs and servers dealing with them have hardware/software belonging to
different parties (Banks, ATM maker, etc.) , so make sure that you are able
to perform each test without affecting a third party.
Preferably, be sure that personnel from your client are physically present
with you, during your tests. ATM systems are delicate and some countries
have specific regulations for dealing with hacking financial systems, so you
might want to be more careful with this than with regular PenTest
engagements.
Some references that might be useful:
http://www.cse.ohio-state.edu/~jain/cis788-97/atm_security/
http://www.rennes.enst-bretagne.fr/~rolin/Anglais/ATMsecurite.html
http://wired-vig.wired.com/news/technology/0,1282,8823,00.html
http://www.theregister.co.uk/2004/07/21/atm_keypad_security/
I hope this will be useful.
Cheers,
Omar Herrera
> -----Original Message-----
> From: Dexlab Dexlab [mailto:samurai.jack111@gmail.com]
> Sent: Sunday, May 15, 2005 6:28 AM
> To: pen-test@securityfocus.com
> Subject: ATM Security
>
> Hi all,
>
> Does anyone here has an idea about ways of doing Automatic teller
> machine (ATM) assessments...?
>
> Thanks
> jack...Samurai Jack
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:21 EDT