Posts Tagged ‘hijacking’

A few weeks ago, Kyle Rozendo asked a question on the IT Security StackExchange about Cracking a PCI terminal using a trojan based on the card. It caught my attention, so I started digging a little deeper into this matter.

There are some difficulties involved in hacking an ATM:

• Often proprietary software
• Often custom OS or modified embedded Windows

This means a high level of understanding is necessary, as well as access to ATMs to test on. All of the attacks I’ve dug up had some level of inside information before they were constructed.

2009: Diebold gets targeted by Skimer-A Trojan

One of the first serious hacks I came by was a Trojan found in ATMs in eastern Europe around 2009. As reported by Sophos, the attack was aimed at Diebold Opteva ATMs.

The Trojan was named Skimer-A. It’s main goals were:

• Steal information (card numbers and PINs)
• Allow remote access
• Drop more malware

The hack required physical access to the machine. The perpetrators used social engineering, to persuade stores to allow them physical access to the machine after hours, so they could install the virus. After an analysis of the malware, Diebold concluded the attackers also had to have inside information about the systems. A lot of the functions used to extract information were part of the ATMs operation software, but were never documented. They also knew administrative passwords and unlocked the custom Windows CE version Diebold used as well as misconfiguring its firewall. (This was concluded from the security update by Diebold.)

2010: ATM Jackpotting by Barnaby Jack

In 2010, McAfee security expert, Barnaby Jack presented his “ATM Jackpotting” at Blackhat. He was able, after careful analysis with physical access to a few teller machines, to write a tool that could remotely exploit an ATM and patch it so you can call a custom menu with an access code or remotely start emptying the ATM’s money cassettes (hence Jackpotting).

The attack is aimed at standalone and hole-in-the-wall ATMs. The ATMs often run:

• ARM/XSCALE processor
• Windows CE
• TCP/IP, Dial Up or CDMA wireless
• Support for SSL
• 3DES encrypted pin pad

In his research he used 3 different ATMs (he ordered these and got them delivered at home). He started his research by looking at the internal workings and, although there were some security measures in place, once a he had physical access many possibilities started to appear. He started by looking for a way to modify the boot sequence, because the ATM boots into its proprietary software. This means he has to patch the system so he can get access to a shell. He accomplished this by using a JTAG debugger.

Using the JTAG module, he was able to send a break when starting the difference services. After this he could launch a proper shell.

This work was all necessary to reverse engineer the software and develop the actual attacks:

• Walk up attack by “upgrading” the firmware with a flashcard (this required physical access, and a key to open the machine and access the motherboard – such keys are standard, and easy to find on the Internet).
• Remote configuration attack, firmware can be upgraded remotely

The latter is the most interesting attack, but there are some security defenses in place that make a bruteforce attack impossible. However Barnaby Jack was able to find a vulnerability in the authentication mechanism which allowed him to log in to the machine. He wrote a tool to do these attacks, named “Dillinger”. Now the problem he faced was how to find the ATMs on the internet.

Whilst ATMs support TCP/IP, about 95% of all ATMs still connect to the internet using Dial Up. This means War Dialing using a VOIP tool like WarVox, makes it possible to go and find ATMs on the net. Most of the ATMs use a proprietary protocol, so once you identify this protocol you know an ATM is listening on the other side and you can go and try to exploit it. Once you have access to the ATM you can spawn a shell and install a rootkit. You will still need to identify where the ATM is physically located so you can go and collect the money. This is done by reading the configuration file (often the address is present on the receipts).

The rootkit to keep access to the teller is called “Scrooge”. It hides itself on the machine. One difficulty is that the kit needs to be modified for almost every version of ATM software that’s running because of different peripherals and non-standard ways to communicate. After installing the kit you can walk up to the ATM and enter a keys equence on the keypad, this brings up a custom menu that allows you to jackpot the ATM (completely empty it) or give you a specific amount of cash. This can also be done remotely.

Barnaby suggests following countermeasures:

• Better physical locks
• Executable signing at the kernel level
• Implement Trusted Environment
• Put them on a seperate, firewalled network
• Disable the Remote Management System if you aren’t using it
• More and better code auditing

You can find the complete presentation on Vimeo.

2012: MWR InfoSecurity reveals chip and PIN vulnerability

Chip and PIN is a system where one can insert his banking or credit card into a small machine and make an electronic payment. In the U.K. there is a government backed initiative to make these as widespread as possible. MWR InfoSecurity, a Basingstoke (U.K.) based security company, revealed a way to attack these terminals with a custom PIN card. The attacks demonstrated at Blackhat 2012:

• Producing a fake receipt, making a cashier think the payment was successful
• Infect PIN entry devices to collect card data and harvest these with another rogue card
• Network and interface attack

Apparently the exploits involved were present in normal computers more than a decade ago, making you wonder why this problem was ignored or went undetected. Especially when Cambridge University researchers warned banks of the lack of security in these type of machines as early as 2010. Issues included unencrypted and unauthenticated communication between terminal and remote administration server, which makes a man in the middle attack dead easy. At the moment of writing there hasn’t appeared any white paper (I’m aware of or had access to). The devices affected were produced by VeriFone.

Conclusion

If we look at the attacks over time, it becomes clear that they can be deployed faster and faster. The hacks still require a high level of knowledge and understanding of these systems, but because there are some really basic security issues like bad code reviewing, unencrypted/unauthenticated communication and bad physical security, the attacks are seemingly easy to deploy. It’s up to the producers of these machines to start securing them. Companies still rely too much on security through obscurity and do not expect an attack because a hacker would need insider information. Previous articles suggest that it’s not extremely hard to get that information.

Sources:

• Geoff White,Channel 4,Credit card readers can be hacked for details, 29 July 2012
• Anonymous, Infosecurity, Russians hack Diebold ATM software, 19 March 2009
• Anonymous, Sophos, Troj/Skimer-A, 17 March 2009
• Pat Carroll, Finextra, Protecting Pin Pad Payment, 18 July 2012
• Vanja Svajcer, Naked Security, Credit card skimming malware targeting ATMs, 17 March 2009
• Graham Cluley, Naked Security, Is there malware lurking in your ATM?, 17 March 2009
• Graham Cluley , Naked Security, More details on the Diebold ATM Trojan horse case, 18 March 2009
• Warwick Ashford, Computer Weekly, BlackHat 2012: UK firm MWR InfoSecurity reveals chip and PIN vulnerability, 26 July 2012

Since the birth of the internet, there has been censorship. People have always been looking for ways to anonymously access the internet, either by proxy or VPN, however these still (can) log traffic origin and destination.

Since a few years there have been a few projects to anonymize traffic. One of the more famous ones is Tor (The Onion Router).

How Tor works

Tor uses servers and clients. When you request a webpage from your client, Tor will make an encrypted request to a randomly selected relay server called an Onion router. This Onion router knows who you are. Next thing the router does is ask another Onion router to relay the message. This second Onion router only knows the first Onion router. The second asks a third, the third asks the fourth, etc. No single router knows the complete route, however the client does.

The client can access a database which holds all the relays and if he wants, he can select his own route or a random route is selected. He then gets all the public keys for the route and encrypts his message in reverse order, starting with the public key of the last node, than the one to last node, etc. So the encryption is layered (just like the layers of an onion). However there is also a message for every node that contains the next hop. Now at the exit router the message is decrypted completely and the request for the webpage is made. For the webserver that serves the question, the client’s IP is the IP of the exit node.

The weakest link

So traffic is encrypted multiple times and relayed through different servers. This ensures anonymity. However… everyone can set up a Tor exit node … and everyone that has an exit node, can monitor the traffic.

The weakness in this technology is one we find in other technologies as well, the so called “user”.

A lot of people are concerned about their anonymity and figure they are safe when using Tor. They forget that when using a physical line or an encrypted Wifi AP, The chances of getting a Man in the Middle Attack (MMA) is small.

Now because we can easily host an exit node, we can sniff traffic from people who think they are anonymous, a lot of people in fact. At 20 Mbit (the max speed we allowed Tor to use), we got about 200 different Facebook sessions a day.

Facebook

Users forget about certain things, like facebook over https. I’ve heard people say “I’ve enabled https on my facebook account, so when I log in, I’m safe.” Well that’s good for them but they forget that often, if you do not explicitly state https for the facebook login page, your password and username is sent PLAIN TEXT over the internet. Facebook doesn’t know you want a secure line before you are logged in.Obviously this goes up for a lot of different sites other than Facebook.

The whole point of Tor is to be anonymous, but users get facebook accounts with often their full name and address on it, and then log in insecurelly.

One could write a script (and we made a proof of concept), that looks for usernames and passwords or hijacks sessions and automatically goes to a facebook like page “I am using Tor to be anonymous”.

I am not saying Tor is unsafe, all we wanted to proof is that people need to think twice before thinking they are anonymous and safe on the internet. There will always be people that want to do malicious stuff. We could have hijacked about 20 accounts in half an hour and revealed people who use Tor or get into their emailboxes. (like Dan Egerstad also prooved in 2007).

Youtube Video

The comments in the clip are in Dutch, but basically we set up a tor node and used tshark to capture traffic. We specified we were interested in http traffic coming/going from Facebook. We then took the session cookie and injected it into our browser which then automatically logs us into Facebook as that user.

Conclusion

Tor is a good anonymity provider, but like all tools, you need to use it in the correct way.