@dinozaizovi: Finding vulnerabilities without exploiting them is like putting on a dress when you have nowhere to go.

This clever analogy spurred a discussion about the importance of proving exploitability as a prerequisite to fixing bugs. While I agree that nothing is more convincing than a working exploit, there will always be a greater volume of bugs discovered than there are vulnerability researchers to write exploits. Don’t get me wrong — as a former penetration tester, I agree that it is fun to write exploits, it just shouldn’t be a gating factor. Putting the burden of proof on the researcher to develop an exploit is not scalable, nor does it help create a development culture that improves software security over the long term.

A related topic, and one that hits closer to home for me, is how software developers deal with the results of static analysis. Static analysis is often misunderstood, particularly by people who have only dealt with dynamic analysis (fuzzing, web scanning, etc.) or penetration testing in the past. Because static analysis detects flaws without actually executing the target application, there’s an increased likelihood of finding “noise” (insignificant flaws) or false positives. On the other hand, static analysis provides broader coverage, often detecting flaws in complex code paths that a web scan or human tester would be unlikely to find. So there’s your trade-off.

Here’s a conversation I have all too frequently, paraphrased:

Now imagine that conversation stretching out to 30 minutes or more. They could’ve fixed a half-dozen flaws already. And it’s not limited to SQL injection. For example, consider cross-site scripting (XSS):

Buffer overflows:

By now you get the picture. Many developers want proof, to the extent that they’ll sacrifice efficiency to get it. If we are to improve software over the long haul, developers must learn to recognize situations where it takes less time to patch a bug than to argue about its exploitability. On a more positive note, from someone who talks to static analysis customers on a daily basis, the tide is starting to turn in the right direction. But it is still an uphill battle.

Veracode Security Solutions

Veracode Security Threat Guides

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.

Update:

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