End to End Encryption is NOT the PCI Silver Bullet!
Evan Schuman of StorefrontBacktalk has a pretty shocking article today. Apparently, the Heartland malware hid in the unallocated file space.
Right on the heels of my last blog post too. Nuts.
Our forensic examiners at VeriSign look for this type of malware during every investigation because it is not a new trick. It surprises me that it was almost missed. Even still, I stand by my original premise which is that the standard (properly implemented) would prevent this. In order to get the malware on there, a software flaw or credential had to be exploited. Both of those vulnerabilities are addressed by PCI-DSS.
What is more troubling is the same noise that came out after the Hannaford breach last year. Bill Homa, their CIO at the time, first said that PCI was not hard enough (seriously?!? If it was harder, do you think there would be more adoption?), and that end to end encryption would have saved the day. On the surface, I disagree.
At this time, banks cannot process encrypted credit card data (PIN Debit may be the only exception). At some point during the many processes that occur in order for money to actually change hands as a result of a credit card transaction, the data must be decrypted. I'm not saying there are not opportunities to increase the security of payment data, or even take large areas of your network out of scope, but just saying that end-to-end encryption is the solution is irresponsible.
Let's take this example that is fictitious, but not so much so that I have not seen this in the field somewhere. Merchant A encrypts everything from the POS Controller to the back office processing. That leaves the POS Terminal to POS Controller link vulnerable, as well as the machine that does the processing to send transactions to the bank. You could not solely rely on encryption to protect you here, you would need to make sure the rest of the standard is properly enforced on those key machines.
Another example, where the POS Terminal to Controller link is encrypted, but nothing past that. It leaves the controller open to attack, especially if it has access to the internet (don't laugh... I have seen that on many occasions).
I understand minimizing the exposure of unencrypted card data, but even with malware combing through memory, that is not something that we should rely on (or that a developer should argue when you are conducting a PCI Assessment).
We should continue to pursue end-to-end encryption solutions because it will make life for Merchants a TON easier, and will boost the overall security inside the payment process. Remember though, if you take away one vulnerability, the bad guys will find another. I predict you will see an increase in the threats against the devices themselves. More skimming devices, and more fake ATMs/PEDs are coming. That's a management and training problem to fix (NOT a technology problem).
I stand by my original point. The standard, properly implemented, could have prevented a breach like this.
Comments
"hid in the unallocated file space." How exactly does this work? I can't find any tech writeups. I don't see how the code could execute from there unless there was a slim parent exe within the filesystem that runs, then obtains/imports the bulk of its code from the sectors. Also, does "unallocated", mean free space as opposed to sectors outside of the partition(s)?
Posted by: Lucas Z. | January 30, 2009 9:45 AM
Excellent question Lucas! I asked one of our heavily certified VeriSign Forensic Examiners to answer that question for us. Here is what he said!
When a file is deleted on an NTFS partition, a flag in the $MFT (Master File Table) is set indicating it is not in use, and the allocated clusters are marked with 0s in the $Bitmap (Tracks the allocation status of all clusters in a partition), which means they are unallocated. In addition, the index buffer entry for the logical folder is deleted. Because the $MFT record is otherwise untouched, an accurate record of cluster is usually intact, thus making recovery more available. At this point, from the Windows Explorer view, the file is no longer visible to the end user. So, from the malware point, it could be possible to recover the deleted malcode - perhaps from a trojaned service or from memory a program reads the MFT, finds the file pointer, recovers the code and then runs the code that then deletes itself again. Introduce packers, then the code can be further obscured from normal analysis. Figure, if the malcode was only in memory, and the forensic team did not do any type of live analysis, then they would have missed it.
Slack space is the unused space in a disk cluster. The DOS and Windows file systems use fixed-size clusters. Even if the actual data being stored requires less storage than the cluster size, an entire cluster is reserved for the file. The unused space is called the slack space. Unallocated Space is available disk space that is not allocated to any volume or file. Fragments of deleted files are often scattered across unallocated space on the disk.
Posted by: Branden Williams | February 2, 2009 12:03 PM
Thanks for the technical write-up. That's pretty darn ingenious! I'd have to imagine that no matter how they're hiding the bulk of their code, there has to be a rogue startup process to kickstart it on boot that could be found via analysis of a HijackThis report or by checking the modification dates of services and drivers for unknowns. I mean, something has to be present from Windows viewpoint at start for it to survive a reboot, yeah? Evaluate that via hex editor and IDA Pro to see where it goes from there. Or maybe these things create the startup process only on shutdown, delete the startup process once it gets going at boot, repeat? Tricky punks…
In the end, is it thought that this is the kind of dastardly thing that was running on HPS system(s) as opposed to it being a normal malware that got deleted?
Posted by: Lucas Z. | February 3, 2009 5:41 PM