Quantcast StorefrontBacktalk » Blog Archive » Gonzalez: The Al Capone Of Cyber Thieves?
advertisement
advertisement

Gonzalez: The Al Capone Of Cyber Thieves?

Written by Evan Schuman and Fred J. Aun
August 19th, 2009
Like this story? Share it
To share this story with people in your social network, please click on the network icons below.

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.)


advertisement

5 Comments | Read Gonzalez: The Al Capone Of Cyber Thieves?

  1. Craig Keefner Says:

    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.

  2. Walt Conway Says:

    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.

  3. Evan Schuman Says:

    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.

  4. A reader Says:

    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.

  5. Walt Conway Says:

    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.

Leave a Reply

Newsletter

Quickly catch-up on the latest in E-Commerce and Retail Tech with our free weekly newsletter, with urgent bulletins as news merits.
advertisement

Most Recent Comments

What’s The Rush For New PCI Call Center Requirements?

And I have not heard anyone mention the impact on companies who provide quality improvement services. Many merchants hire quality improvement companies to review their audio recordings to provide guidance on how to improve their sales staff’s effectiveness in customer service and sales retention. PCI Council needs to rethink this requirement until there is a widely available commercially viable solution. Read more...
Another ridiculous decision where regulators don't think critically enough about the unintended consequences of their decision. This will be a huge problem for the credit and collections industry. We have to keep all recorded calls for other reasons not related to cc information. We can't purge all of our calls and we don't have the technology to not record part of the conversation. Even if we did, I am not sure we could afford it. Read more...
This "clarification" is causing a lot of panic with large FS clients who now appear to be non-compliant after spending 7 figure sums on their compliance programs. The only alternative to call recording would now appear to be some sort of IVR/push button type interrupt to take card data away from the contact centre. The council is a position to force that sort of process and technology change and this may backfire on them and the vendors that lobbied hard for this clarification. Read more...
PCI council has made a one-sided decision; They should have done a much more in-depth research that could have provided more insight on what regards to the implications of such decision. Read more...

Will Old OS Cause PCI Violation? No, But Marketing Still Says So

This is an interesting issue, because there's more to it than what's apparent on the surface. PA-DSS requires supported and patched operating systems and other software components (e.g., databases, libraries, Java, etc.) per PA-DSS 7.1.b and 8.1, and the option for compensating controls simply isn't there. Merchants can make use of compensating controls for most PCI DSS requirements, but only when legitimate constraints exist and only in ways that meet the intent and rigor of the requirement and go above and beyond the other PCI DSS requirements. Read more...
Why would one automatically upgrade to a "new" OS -- some of the older versions of certain OS-es are more stable and more robust than the crap being peddled today. This is yet another clear example of PCI SSC being out of touch with reality. Rather than requiring a "current" OS, the requirement should be to demonstrate the OS in use is stable and robust, and is adequately hardened against threats. Read more...
There are compensating controls that encrypt the swipe at the driver level as it enter the PC, there are hardware encrypting card swipes so the cardholder data is already encrypted before it comes to the PC -- either of these, especially the second, would remove the OS entirely from a cardholder data risk profile. Read more...
In my opinion, the only thing the vendor did wrong was they didn’t know of that FAQ entry. Even if they did, it changes nothing about the need for merchants to update software that no longer receives updates. Read more...

MasterCard Blinks, Drops Dec. 31 Level 2 PCI Deadline

Reciprocity between MasterCard and Visa was always been a factor in Acquirer merchant level assignments. The brief removal of reciprocity generated a great deal of interest in being able to be classified at a lower level in MasterCard's world. Nevertheless the return of the reciprocity language in the December changes did not effectively create any new Level 2 merchants, but it DID dash the hopes of a lot of them.... :-( Read more...
Let's given them credit??? For being idiotic in the first place? Not on your life! Everyone has just had to scramble and include the costs of the previously announced M/C requirement in their 2010 budgets, and start negotiating with the QSAs for the additional services. All for naught! Read more...
"A bunch of Level 3 and Level 4 merchants just became Level 2s". Is this an accurate statement? MasterCard & Visa have historically included the caveat "or is a Level X in another brand" in their level setting criteria. MasterCard appeared to back way from this in the June pronouncement, and have simply returned to the status quo. Have Acquirers have been tracking and reporting merchants at separate levels by brand? Read more...
I stick by my comment (quoted in the column) about a bunch of L3 and L4 merchants becoming L2s and requiring an onsite. To me, what made MasterCard's original requirement for an onsite assessment for L2s palatable was that they took away their reciprocity provision. That is, they seemed to focus on larger merchants with over a million MasterCard trans/year. With reciprocity in place, a lot of smaller merchants are pulled into the onsite requirement. Rather than causing confusion, I think reciprocity will lead to additional work for processors and acquirers. Read more...

Retailers Sue POS Vendor, Questions Raised Where PCI Duties Stop

I would add a couple more questions: "did the breach involve the use of the default passwords?" (The story doesn't say.) And "were the default passwords used by Computer World to remotely administer the store systems?" "where is the PCI auditor in all this?" Did the restaurant group think they didn't need an audit because Radiant was (mis)representing Aloha as PCI compliant? How is a retailer or even a PCI auditor to know otherwise? A PCI auditor is not necessarily a qualified computer forensic investigator capable of finding the card data on the hard drives. They can only base a decision on information given to them by others. Read more...
There are so many holes in the process it will be difficult to pin blame on just one constituent. It is ridiculous that the technology exists to better secure these transactions (PIN, EMV, etc) yet banks won't use them. Only the banks or government can force this change, and retailers will suffer until then. Read more...
A major issue in this case will be if the restaurants had any support agreements in place with Computer World and if so what those agreements say. In my experience many single unit/small operators choose to skip the support agreements in favor of a "pay as you go" arrangement. In this scenario I can't imagine how the POS VAR can be held responsible for a system they don't own nor exclusively manage. Read more...
There is a big difference in having the POS installation guide say "make sure you set this password because the security of your CHD depends on this" vs. a POS application not storing the CHD in the first place. Traditionally only the merchant was liable for breaches and PCI related fees (fines). Maybe dragging some of the vendors into the liability mud fight will open the eyes of some of these vendors. Read more...

Should Credit Card Transactions Be Free? There May Be A Way

Here in the Netherlands, where the population is notoriously penny-pinching, credit card acceptance is amazingly low. It's both a result of the consumer not wanting to pay interest on everyday purchases as well as merchants not giving up a slice of the action. It is both legal and common to pass the processing fee onto the customer as a surcharge. Now things are moving to leave the credit cards behind: mobile phone payments are becoming more and more common here, and the transaction fees are minimal. Parking and entertainment (movie/concert tickets, nightclubs) have been amongst the first, and it's rapidly gaining momentum because the market has been hungry for the convenience at a price it is willing to pay. Read more...
"Free" is an illusion. Don't charge one person but charge double to someone else. I am very skeptical on anyone who says that advertising will create valid cashflow. Just look at the advertising struggles in a TiVo world. And if you sell your customers data, just be warned that the one group that might have issue with that are you customers (which to me is very important to cashflow. Read more...
Another factor not mentioned here is the impending costs that the processors and issuers are going to incur when someone decides on an end-to-end encryption method, and it then becomes government mandated. I can guarantee that this is a when question and not an if question. The back-end networks are pretty antiquated right now, and it's going to cost billions to replace everything. The cost of tech may be going down, but the cost of replacing millions of servers and hardware, and creating new, proprietary, software is still really expensive. Read more...
Accepting credit cards are not "risk-free" for merchants, contrary to Jim's comments above. Chargebacks are an expense - both in terms of actual transaction reversals and costs associated with managing the process. Chargeback rules and expenses can be everything from a thorny issue to an onerous expense for some merchants, especially for convenience stores that allow customers to pay for gasoline at the pump, or other retailers that allow in-store self-checkout options. Read more...
I've wondered for years why the price of transactions has been so high. Phone companies long ago started offering unlimited calling for flat rates because they understood that in many cases it cost more to report on the transactions (calls) than it did to fulfill them. Read more...
If a home-owner defaults on the mortgage, who is taking the risk? The bank making the loan to the consumer or the person selling the house? It is obviously the bank that takes this risk and is rewarded for that risk through interest rate charges. In my mind, we have mixed together two distinct and unrelated transactions. Read more...
The one big factor not mentioned in this article is who will take over the risk ? Taking credit cards is risk free to merchants and the issuing Banks take the risk if a customer defaults on the payments ! If you had a "interchange free" payment system will the merchants assume the risk ? Also, if there isn't enough profit for the issuing banks they will stop issuing credit cards which will in turn kill our economy. Read more...

The Dangerous Out-Of-Scope PCI Charade

If tokens are ever deemed in-scope, then where does the line stop? I ask this because it would mean that all timestamps, sequential number, random numbers or any other piece of information that may or may not be used to generate a token is within scope -- all data a POS uses and stores, not just payment data. Read more...
Having the ability to do both Tokenization and End to End Encryption (not mere point to point) can have tremendous scope and risk reduction benefits and agility to adapt to change in this fast moving compliance landscape. Being able to have both on tap from a single platform is a solid approach to avoiding the pitfalls. Read more...
But the consumer walks into a particular retail chain, gives their payment card to someone wearing that chain's uniform and the card is swiped. If, six months later, there's a breach and that card was misused, it's the retailer who will in the spotlight. They're the deep pocket and, therefore, the target. If the consumer is angry and wants to cut off business, it will hit the retailer. Therefore, if the retailer is going to end up being blamed no matter what, they have to stay involved. Read more...
True, that someone may be storing a token-to-PAN cross reference. But that would be the bank, not the retailer. If the bank is not sure they can keep their data secure, then there are bigger problems to be addressed than bringing tokens into scope. Read more...
Good general point, Steve, but for the record, not all tokenization is done the same way. Many tokens are associated with lookup lists that allow for them to re-matched to the card data if it's needed, such as for a chargeback. A token doesn't have to be decryptable (is that a word?) for there to be a way to access the original data. Read more...
The out-of-scope argument is very valid but in reference to tokens, the premise of temporarily out-of-scope or abruptly deemed in-scope is flawed. Conway was quoted “anything that could be made unreadable can, in various ways, be made readable again,” this statement is true when talking about encryption technologies (all encryption technologies) but not so with true tokens. True tokens are in no way related to the original data other than as a reference key. Read more...