Penetration Testing mailing list archives
RE: ATM Security
From: Omar Herrera <oherrera () prodigy net mx>
Date: Sun, 15 May 2005 13:08:48 -0500
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
Current thread:
- ATM Security Dexlab Dexlab (May 15)
- RE: ATM Security Omar Herrera (May 15)
- Re: ATM Security news (May 23)