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

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


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

About Chris Wysopal

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.

Comments (1)

Marsh Ray | November 11, 2009 12:54 pm

"but figured out how to turn the stored encrypted PIN code back into the plain text PIN [...] There are many different PIN storage algorithms out there and the older ones have weaknesses. [...] backwards compatibility with older encryption format"

Sounds like the possible encryption algorithms were probably reasonably well documented.

A four-decimal-digit PIN only has 10,000 possibilities. That's a trivial space to brute force.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

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