Gonzalez: The Al Capone Of Cyber Thieves?
Written by Evan Schuman and Fred J. AunAugust 19th, 2009
Albert Gonzalez, the Miami resident who was indicted last summer with stealing credit card data from TJX, BJ’s Wholesale Club, OfficeMax, Boston Market, Barnes & Noble, Sports Authority, Forever 21 and DSW can now add Heartland, Hannaford and 7-Eleven to the lengthy list of retailers that the federal government says he penetrated. In case you feel left out, there are two to three additional major retail chains that the feds have accused him of attacking, although those chains have yet to disclose that they were breached. (That’s likely to be divulged at trial and may never come to light if Gonzalez works out a plea bargain.)
And while he is accused—along with others—of having used POS networks as his own personal ATM machine, he’s also being accused of breaking into actual ATMs (and trying to use them as his own personal POS system?).
(Editor’s Note: There is a new story published that updates this one: J.C. Penney, Target Added To List Of Gonzalez Retail Victims. Gonzalez Agrees To Plead Guilty To Key Charges.)
The indictment—handed up Monday (Aug. 17) in Newark, NJ—offered a handful of new details about the breaches, but those disclosures brought more confusion. For example, 7-Eleven is a new name in the breach circle, and the indictment said that the $54 billion convenience store chain’s POS network files were directly—and successfully—attacked. In August 2007, “7-Eleven was the victim of a SQL injection attack that resulted in malware being placed on its network and the theft of an undetermined number of credit and debit card numbers and corresponding card data,” the indictment said.
But a statement that 7-Eleven issued on Tuesday (Aug. 18) tells a very different story. The 7-Eleven statement said that “affected transactions were limited to customers’ use of certain ATMs, owned and operated by a third party, located in 7-Eleven stores over a 12-day period from October 28, 2007, through November 8, 2007.”
That’s a very key difference, given that third-party ATM data—from machines that essentially leased space from various stores—would never be in the possession of 7-Eleven. Could it be that the stolen data was only used on such machines? Seems unlikely. When the TJX indictments against Gonzalez were handed up exactly a year ago (August 2008), one unidentified major retail chain victim also spoke of ATM assaults.
Another numerical mystery created by the indictment involves Heartland. Heartland has been adamant that it has no idea at all how many cards were impacted by the breach. Monday’s indictment gave the Heartland breach a very explicit number: 130 million. Said the indictment: “Beginning on or about December 26, 2007, Heartland was the victim of a SQL injection attack on its corporate computer network that resulted in malware being placed on its payment processing system and the theft of more than approximately 130 million credit and debit card numbers and corresponding card data.”
Heartland on Monday issued its own statement, which in journalistic circles would be called a non-statement statement as it didn’t actually say anything, except to congratulate the government for bringing the indictment. But Heartland Spokesperson Jason Maloni on Monday stood by the position that Heartland does not know the number of pieces of card data impacted. Asked how the government had figures that Heartland didn’t have, Maloni referred to the government’s number and said “We don’t see what this is based on.”
There’s plenty of wiggle room for Heartland here, as the comments certainly do not dispute the government’s figures.
The indictment lays out the rough means of attack that Gonzalez and three others used to access the retail databases. The others indicted on Monday with Gonzalez were identified solely as Hacker 1 and Hacker 2. (Wasn’t that taken from an updated Cat In The Hat book?) There is also a coconspirator referenced, identified only as P.T.
There’s an excellent chance that “PT” is actually Damon Patrick Toey, who plead guilty in December to working with Gonzalez on the TJX breach and strongly suggested to the sentencing judge that he was now working with the feds against Gonzalez. (Editor’s Note: Gonzalez’s attorney, Rene Palomino Jr., was quoted in a NYTimes story posted Wednesday (Aug. 19) confirming that PT was Patrick Toey and added that one of the unnamed Russian co-conspirators was Maksym Yastremski, who is currently serving a 30-year sentence in a Turkish prison. The Times story also quoted the attorney as saying that Gonzalez was about to plead guilty to federal cyber crime charges in New York and Massachusetts when New Jersey accelerated its indictment and, in effect, killed the plea negotiations.)
-Gene Hoffman
August 19th, 2009 at 10:21 am
The Tiger Woods of Cyber Crime. Amazing to me that after busting into Dave & Barry’s, he worked as informant for FBI on Shadowcrew thing and, after that gig, decided to go back to hacking into corp data.
August 19th, 2009 at 6:16 pm
A good post, and thanks for pointing out the potentially conflicting numbers between the indictments and press releases…very interesting to see how that works out.
I have spoken with some colleagues at 403 Labs (full disclosure: we are a QSA, PA QSA, and ASV firm) and we would take some exception to the comments of the retail security expert you quote. She begins by saying that the attack against Heartland Payment Systems came in the form of a back door and that such an attack obviated the efficacy of both firewalls and password rotation schemes. My colleagues and I would not dismiss too casually these controls. The intent of good network architecture and proper firewall policy is to limit access to the minimum necessary (e.g., default “deny all”) for business use. This is intended to include internal network segments (PCI DSS 1.2.1). Further, PCI specifies the need for both documentation and justification of open ports and services (PCI DSS 1.1.5-1.1.6). It’s not enough to use your firewall or firewalls to divide the company network from the Internet; PCI actively encourages segmentation between various internal zones and treating zones not directly involved in card data transactions as untrusted. Good network architecture and strict firewall rules that limit traffic don’t, by themselves, preclude the possibility of a back door being installed, but they certainly make it harder for the bad guy in question to do so and they limit the network-level access a back door has.
I would also challenge her point that password rotation “isn’t an effective defense, and shouldn’t be elevated to such by PCI or corporate ’security policies.’” Protecting access to user accounts, especially administrative or other critical accounts, is the core of password controls and very relevant to the attacks that led to many of the recent breaches. For example, the attacker needs first to install a back door onto the system in question. Often, these attacks require the attacker to compromise a privileged user account in order to install hostile software; strong passwords enforced by system-level controls defend against these attacks.
She argues that maintaining current anti-virus software is not an effective control because custom malware “will not be recognized as viral, especially if it performs no viral behaviors.” It’s not entirely clear what she means by viral behavior. Nonetheless, I’m not sure it’s wise to cease maintaining anti-virus software in the face of the numerous extant attacks that said software will detect, including keystroke capture malware used in compromising credit card data.
As for PCI’s security testing and security policies, PCI DSS 11.2 and 11.3 call for both automated vulnerability scans and penetration testing directed against both the external (e.g., Internet-facing) environment and the internal environment. The penetration tests are intended to simulate real attacks and skilled penetration testers are entirely capable of doing so. As such, a “PCI-test-detectable breach” is a pretty broad category that does include situations like these. It’s entirely possible that the penetration testing performed either wasn’t adequate or that the environment changed between the testing and the compromise, but to say that the PCI security testing requirements were inadequate sounds too broad. Also, remember that PCI DSS 12.1.2 specifically requires an annual risk assessment to identify and propose strategies to deal with threats and vulnerabilities. If you want to conclude, based on your risk assessment, that your organization needs end-to-end encryption, weekly penetration tests, and replacing card data with tokens, any competent assessor will agree with you wholeheartedly and help see to it that your information security practice lives up to this.
We may want to wait to learn more before making the statement “Heartland could have been (and probably was) breached while being 100 percent PCI 1.1 compliant on all their points.” Based on what I’ve noted above, we could conclude that this is not true. Organizations are obligated to comply with the PCI DSS, meaning they must meet all of the requirements all of the time. An assessor validates their compliance on (usually) an annual basis. It’s entirely possible that an organization could pull together to make things look good for the assessor and then let their controls lapse as soon as the report is finalized, but this misses the point entirely. PCI critics who regard the distinction between compliance and validation as a weakness ought to direct their criticism towards the organizations that claimed compliance but let their security controls lapse, rather than at the standard itself.
PCI DSS is not intended to be the maximum data security effort; it does not limit anyone from going above what the requirements dictate based on their own risk assessment. PCI doesn’t limit implementing additional controls like end-to-end encryption or additional security testing. On the contrary, it encourages this kind of activity.
August 20th, 2009 at 8:46 am
Editor’s Note: The retail exec quoted in the piece wanted to respond to Walt’s thoughts. Her comments:
I am not disagreeing with Walt on some of his points. He is certainly correct that PCI 6.5 does talk about protecting web-facing applications SQL injection and Heartland should have been looking for that exposure. If that’s the case, Hackers 11, PCI 1. The real question is if SQL injection was used as the original method of forcing entry, or only as the means for elevating privilege once the hackers were inside? The indictment text suggests the former, but one of the documents mentioned the xp_cmdshell exploit which suggests the latter, and that could have been outside the PCI review requirements.
I also agree that a properly firewalled and segmented network environment is an excellent defense, and is one of the best ways to limit exposure and maintain damage control. The problem there lies in the wriggle room around the word proper, and how that is interpreted by the company and the individual QSA. A processor is likely to run all their card handling systems in a single segment, but once that segment is breached at a processor the hackers have access to it all.
I did not say anti-virus software is ineffective against all attacks, only that it will always be ineffective against custom written malware. For software to behave like a virus it would have to spread itself, and there are some anti-virus products that detect that bad behavior. What is more effective than AV is a software execution policy that uses a whitelist instead of a blacklist, or a FIM product.
Regarding the argument against password rotation, I claim only that enforced rotation is an ineffective defense, not that policies enforcing strong passwords aren’t effective. Rotation is theoretically supposed to limit the damage, but hackers who gain system authority routinely install backdoors that render passwords ineffective, rotated or not. Password rotation primarily harms the users’ ability to remember them, forcing them to be written down.
Most security testing is thought of as walking a fence. The security team built the fence to keep the attackers out, so the natural test procedures focus on examining the fence. They look at the gate and make sure the lock is secured, they look at the walls and make sure there are no gaps, etc. They look for the vulnerabilities they expect to find. But hackers rarely come in over the fence. Instead they will find a new way to disguise themselves, or move the fenceposts, or send a purchase order for a new padlock for the gate, or trick the owners to bring their valuables outside the fence. As researchers learn these new tricks from successful hacks, they can and should be added to test suites, but it makes the hackers’ jobs easier to avoid detection when they know exactly what is being looked for.
I think Heartland was honestly trying to be PCI compliant – no company wants to leave themselves exposed. And PCI DSS does a great job of helping to keep the run of the mill hackers out of the environment. But as the article claims, Gonzales may be the Al Capone of cyber thieves. I don’t believe that 100% perfect PCI compliance would have stopped him.
August 20th, 2009 at 11:28 am
PCI DSS is a good set of practices for defense in depth, regardless of whether it is effective in every single case, or if it was applied perfectly.
I realize the discussion is about who did the stealing, and not what they stole, which is unfortunate. It misses the root cause of the problem, which is why the banks, retailers and processors are not using smart cards and cryptographic protocols to avoid all this handling of raw, valuable data in the first place. Get the valuables out of the retailers and processors hands, and the cyber-crooks will have nothing to steal.
Some people continually complain about the cost or the complexity or the inconvenience of securing the data properly. People like Gonzalez show why we must bite the bullet and do it anyway.
August 21st, 2009 at 12:54 pm
Let me make a point about PCI. I think we can all agree that compliance is not the same thing as security. In fact, I could make the case that PCI by its very nature assumes you *will* be breached and that your systems will be compromised. What PCI says is that when — notice I did not say “if” but “when” — your systems are breached, the cardholder data you are (foolishly?) storing won’t be compromised.
Just like compliance is not security, a breach doesn’t have to result in a data compromise.