Skip to main content
November 11, 2009

We Need To Learn More About the RBS Worldpay ATM Attack

The size and scope of the RBS Worldpay ATM heist are unprecedented. The perpetrators stole $9M in a matter of hours from 2100 ATMs worldwide. An indictment was handed down on Nov 10, 2009. I am always on the lookout for indictments and trials related to computer crime because this is often the only time the details of the attacker's techniques and victim's vulnerabilities are released publically. For instance it wasn't until an indictment was issued in the Heartland Payment Systems breach that we found out how the attackers breached the perimiter. In that case it was a SQL Injection flaw on an internet facing web application. What can we learn from the RBS Worldpay indictment?

The indictment states that the attackers were able to generate ATM cards and obtain the correct PIN codes to make a withdrawal. PIN codes, like most sensitive secrets, are stored in encrypted form. The indictment states that the attackers were able to reverse engineer the PIN codes. I take this to mean they didn't sniff them on the network but figured out how to turn the stored encrypted PIN code back into the plain text PIN. If this is the case there is a huge vulnerability in the way banks are storing PINs. There are many different PIN storage algorithms out there and the older ones have weaknesses. As an example, here is a paper on attacking the algoritm used by IBM 3624s which many ATMs are based on. Like password hash storage in Windows, backwards compatibility with older encryption formats can be a grave weakness. I am hoping that the FBI or Secret Service has shared the details of this attack with all US banks.

We know to get to the encrypted PINs the attackers had to breach the perimeter of RBS Worldpay. The indictment states the attackers used a vulnerability in the RBS Worldpay computer network. This is about as vague as it gets. Was it a misconfigured firewall, a web application vulnerability, an unpatched server, or something else? This would be nice to know from an industry viewpoint because if RBS WorldPay isn't dedicating enough resources to protect from a particular threat then other organizations likely aren't also.

Finally some nice details. The indictment shows the SQL commands that were executed to manipulate the bank's database to change limits on certain ATM cards and delete transaction data. It is not clear how the attackers are accessing the SQL server, whether it is a command-line on the server itself, another machine, or perhaps through SQL Injection. It is clear that it is game over once an attacker can modify your database tables.

I hope more details come to light so the industry can be educated from this attack and it isn't simply a data breach datapoint.


Several people have asked me about PIN cracking. The papers talk about PIN cracking as an "insider attack". The truth of the matter is once you breach the perimeter and are in the soft gooey center, for all intents and purposes, you are an insider.

There are a few papers on the topic.

The Unbearable Lightness of PIN Cracking delivered at Financial Cryptography and Data Security 2007 describes a few techniques.

Here is an excerpt of the approaches:

It is well known that when several PIN block formats are available the security of the whole system degrades to the security of the weakest PIN block format. The attacks demonstrate that reformatting capability between different PIN block formats allows an attacker to abuse weaknesses of both formats.Therefore enabling reformatting is more dangerous than using the weakest format. We have also shown that the ISO-1 format is extremely weak and thus should be immediately removed from the list of allowed interchange transaction formats.

Another interesting insight from the attacks described is that the offset and the PVV values may reveal as much information as the PIN itself. One possible remedy is treating the offset and the PVV as secret values. The changes require worldwide modifications in ATMs, HSMs and other components implementing the PIN processing API.

In addition to all implementation of this API, systems applying the EMV standard ([7]) and using online (rather than off-line) PIN verification are also vulnerable to the attacks.

Another Paper:Formal Analysis of PIN Block Attacks

Abstract PIN blocks are 64-bit strings that encode a PIN ready for encryption and secure transmission in banking networks. These networks employ tamper proof hardware security modules (HSMs) to perform sensitive cryptographic operations, such as checking the correctness of a PIN typed by a customer. The use of these HSMs is controlled by an API designed to enforce security. PIN block attacks are unanticipated sequences of API commands which allow an attacker to determine the value of a PIN in an encrypted PIN block. This paper describes a framework for formal analysis of such attacks. Our analysis is probabilistic, and is automated using constraint logic programming and probabilistic model checking.

Veracode Security Solutions
Veracode Security Threat Guides

Chris Wysopal, co-founder and CTO of Veracode, is recognized as an expert and a well-known speaker in the information security field. He has given keynotes at computer security events and has testified on Capitol Hill on the subjects of government computer security and how vulnerabilities are discovered in software. His opinions on Internet security are highly sought after and most major print and media outlets have featured stories on Mr. Wysopal and his work. At Veracode, Mr. Wysopal is responsible for the security analysis capabilities of Veracode technology.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.