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 () 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
Static Code Analysis
Vulnerability Scanning Tools
Web Application Security
Software Testing Tools
Source Code Security Analyzer
Software Code Security
Source Code Analysis
Veracode Security Threat Guides
Cross Site Scripting
Cross Site Request Forgery
Mobile Code Security
Written by: Chris Wysopal