Attack

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

Community member D.W. nominated this week’s question: What cryptographic flaw was exploited by Flame to get its code signed by Microsoft?

Hendrik Brummerman provided an in depth answer which was subsequently confirmed by updates from Microsoft:

Certificate Purpose

There are multiple purposes a certificate may be used for. For example it may be used as a proof of identity of a person or webserver. It may be used for code sining or to sign other certificates.

In this case a certificate that was intended to sign license information was able to sign code.

It might be as simple as Microsoft not checking the purpose-flag of customer certificates they signed:

Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing.

MD5 collision attack

The reference to an old algorithm might indicate a collision attack on the signing process: There was a talk at CCC 2008 called MD5 considered harmful today – Creating a rogue CA Certificate

• Website
• Slides
• Video

In that talk the researches explained how to generate two certificates with the same hash. The generated a harmless looking certification request and submitted it to a CA. The CA signed it and generated the valid certificate for https-servers. But this certificate had the same hash as another generated certificate which had the purpose CA-certificate. So the CA signature of the harmless certificate was valid for the dangerous one as well. The researches exploited a weakness in MD5 to generate collisions. In order for the attack to work, they had to predict the information the CA would write into the certificate.

The combination of a collision attack and a misuse of the certificate purpose were both theoretical possibilities before this attack, but  the researchers of the original md5 collision attack published that the attackers used a new variant of the known md5 chosen prefix attack.

Mark Hillick listed a few useful links, around the wider problems the antivirus industry has – being a very reactionary industry its effectiveness is reduced – and a related presentation by Moxie Marlinspike on authentication.

D.W. also provided some useful links for further reading, from Microsoft’s own Technet, and from arstechnica.

Makerofthings7‘s answer focused on reducing the surface area of public trust – in this instance, it wouldn’t have prevented the attack, as the cert was signed by Microsoft, but it would improve security in general.

Silvercore linked to an excellent blog post on the incident – well worth a read.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

This week’s Question of the Week was asked by Purge back in February.  His concern has been echoed in various publications – the worry that scanning one of the common QR codes you see in magazine adverts and on billboards could cause something malicious to happen as most QR scanners on smartphones take you straight to the URL encoded in the QR image. This isn’t a malicious QR (unless you count linking to a particular genre of music malicious) but how would you know?

logicalscope pointed out that a QR code was simply an encoding, so anything you could put in a URL could be encoded in a QR code. This could include XSS, SQL Injection or any other URL based attack.

handyjohn linked to a brief paper over on http://dl.packetstormsecurity.net/papers/attack/attaging.pdf outlining how QR codes could be used to direct victims to an attack website. An attacker could simply print QR code stickers and place them over existing ones on popular advertising hoardings to fool people into going to a site either with malicious code, or that is a spoof of the expected website which can ask for credentials from the victim.

roryalsop focused on the mitigation, which can be very straightforward: rather than send the browser directly to the website, just display the URL that is encoded in the QR image. This way the user can make a decision whether it is a malicious website or not (within the usual bounds for Internet users.) Admittedly logicalscope’s final point, that the QR decoder application could have a vulnerability is also true, but by adding in a user validation step we can at least improve security.

How about storing this one in your phone as a Security Stack Exchange business card – assuming people trust you enough to scan it.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

This weeks question of the week was asked by user claws back in February 2011 and while a lot has happened since then, it is still a very valid question.

The top scoring answer, “What makes you think they don’t get caught”, by atdre, while more of a challenge to the original question, has proven to be quite appropriate, as over the last year various alleged members of Anonymous have been caught. Some through informants, others through intelligence work, however the remainder of the answers focus on the technical and structural reasons why Anonymous continues to be a major force on the Internet.

SteveS, Purge, mrnap, tylerl and others  mention the usual way attackers hide on the Internet – using machines in other countries, generally owned by unwitting individuals who have not protected them sufficiently (This includes botnets – but there are also willing botnets, provided by followers of Anonymous – who allow their machines to be used for attacks) and by routing through networks such as TOR (The Onion Router) so that even if law enforcement try to trace the connection back they will fail either because there are too many connections to track, or because some of the connections will pass through countries where the Internet Service Providers are not able or willing to assist with the trace.

I think Eli hit the nail on the head, however with “because anonymous can be anyone, literally” – as while there are certainly a core group of skilled and motivated individuals, there are many thousands of individuals who will contribute to an attack, and these individuals may be different from one month to the next as the nature of Anonymous allows people to join and take part as and when they want to, if a particular cause is of interest to them.

The Lulzsec spinoff from Anonymous appeared to be a deliberately short lived group who wanted to do something less political, and more for “the lulz” – focusing on large corporates and security organisations to highlight weaknesses in controls, and nealmcb provided links in comments to articles on this group in particular. In terms of detection, the same comments apply here as to the wider Anonymous group.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com. 

Slightly later than officially planned, question of the week number 17, a weekly feature on security stack exchange is a rather unusual but very interesting choice. We’ve featured it by community votes – and because it’s an interesting study of “how to think about security”.

So, without further ado, Security.SE member Incognito asked: What would one need to do in order to hijack a satellite?.

I did warn you! Well, never fear, it turns out our members know exactly how to do it! So without further ado:

Overview

In terms of radio communications security, most satellite communications systems are repeaters, accepting communication from the highest strength incoming signal at will. Most satellites then contain a command module to order the satellite to perform certain actions as necessary. Due to the highly custom nature of individual satellites, the commands that are accepted and the security for them is highly variable, so there’s a lot of potential for exploitation. As one of our answerers puts it:

When it comes to satellites, the word general does not apply.

Legal Concerns

As a result of the wide variety of frequencies and power requirements in use, chances are, attempting to send commands to a satellite are likely to violate local radio laws – as such, we do not recommend it (although we find the study of security very interesting, all the same).

Finding and talking to a satellite

Clearly, if you’re going to communicate with a satellite, you need equipment with sufficient power and range. You’ll need to be aware of the carrier frequency, the maximum satellite range, the data rate and satellite transmitter power. The location and altitude of satellites also matters – some are geostationary and as such are always in range, while others orbit and may only be in range for a specific period of time. Directional antennas with tracking motors will help an awful lot if the satellite changes position at all. Our answers provide even more detailed radio advice and links, so if you’re interested in your radio, do have a read!

Taking control of a satellite

There are several means by which you can take control of a satellite:

1. Direct comms: If you have identified your target satellite, the most obvious method would be to communicate directly with it, sending it the commands you desire. Depending on the satellite you target your options will vary. You’ll need to be aware of the protocol and options available to you.
2. MITM: One option for hijacking a satellite is to identify its command and control – the ground station – and intercept its communications. If you can afford to rent a small plane and can fly it over the site, possibly allowing you an advantage.

Doing it legally

It may be possible to purchase satellite time, depending on who you ask – and as such it may be possible to legitimately control a satellite, even if only for a brief period!

The expensive way

Many of the answers given focused on the radio communication protocols – however, Security.SE member and former moderator Graham Lee highlighted the physical security of satellites as a major concern – the only problem being the cost of getting into space. If you can, being able to nudge the satellite is enough to deny service by altering the antenna direction – you may be able to exploit it in other ways, whilst you’re up there. Of course, you don’t need to go up there yourself necessarily – a rocket will do the job adequately well and apparently doesn’t even need explosives!

Summary

Satellite security is an interesting area with many concerns that has perhaps been overlooked in our focus on the security of online stores and the like. Thankfully, people are looking at the security of communications systems that rely on satellites!

This QotW writeup relied on answers from Jeff Ferland, this.josh and Graham Lee primarily. Thanks to all our answerers on this particular question for providing their insights!

Can you improve on these answers? Feel free to visit the question and provide additional detail!