Tuesday, April 3, 2012

Update on the Global Payments Visa - MasterCard Breach

Image representing Global Payments as depicted...
Image via CrunchBase

Update on the Visa - MasterCard - Global Payments Network Breach

Tuesday, April 03, 2012

Pierluigi Paganini

9a824a3f55b26adad5431f6715dbec2e
(Translated from the original Italian)
Yesterday morning, as planned, Global Payments Inc. - the Atlanta-based credit and debit card processor that recently announced a breach that exposed 1.5 million card accounts - held a conference call to discuss the breach and its impact.
Again, Krebs on Security Blog is the more accredited source on the incident in my opinion, as they had announced the breach first.
During the conference call, Paul Garcia, Chairman and CEO of Global Payments, focused the discussion on the response by the company to the incident. Garcia remarked that the company itself had reported the breach voluntarily.
Garcia didn't date the incident to January, like several rumors sustain, instead declaring that Global Payments has discovered it in early March and promptly informed the authorities.
He said:
“There’s a lot of rumor and innuendo out there which is not helpful to anyone, and most of it incredibly inaccurate. In terms of other timelines, I just cannot be specific further about that.”
The information provided is in contrast with that proposed by Krebs which announced that Visa and MasterCard were warned by the payment processor that an exposure occurred between Jan 21, 2012 and Feb. 25, 2012.
Garcia also added:
“This does not involve our merchants, our sales partners, or their relationships with their customers. Neither merchant systems, or point of sale devices, were involved in any way. This was self-discovered and self-reported.”
First, we must observe the scaling of the figures for the number of cards compromised initially was hypothesized that the exposed card were about 10 million, but the number dropped to 1.5 million today.
Unfortunately, Garcia hasn't provided more information regarding the incident, for this reason many experts have started to search for useful information on the Internet that could be related to the breach and to its timing.
Two useful observations were made by Krebs:
"For the past two years, GlobalPaymentsInc.com has been hosted at MaximumASP, a hosting provider in Louisville, KY. On Feb. 20, 2012, the company moved its Web site to Amazon’s EC2 cloud hosting service. MaximumASP declined to answer questions about possible reasons for the switch, citing customer confidentiality policies."
"The New York Times in a story published Saturday cited unnamed sources saying that this was the second time in a year that Global Payments had experienced a breach. I have heard likewise from an anonymous hacker who claims the company was breached just after the new year in 2011. The hacker said the company’s network was under full criminal control from that time until March 26, 2012. “The data and quantities that was gathered [was] much more than they writed [sic]. They finished End2End encryption, but E2E not a full solution; it only defend [sic] from outside threats.” He went on to claim that hackers had been capturing data from the company’s network for the past 13 months — collecting the data monthly — gathering data on a total of 24 million unique transactions before they were shut out."
"When asked if he had evidence that would back up his claims, the hacker produced a Microsoft Word document with Global Payments’s logo entitled “Disaster Recovery Plan TDS US: Loss of the Atlanta Data Center.” The document appears to have been created on May 6, 2010 by Raj Thiruvengadam, who according to LinkedIn.com was an Atlanta-based Oracle database administrator for Global Payments from May 2006 through August 2011."
"I asked Global Payments if they could verify the authenticity of the document, but have not yet heard back from them. I will not publish it, as it contains apparently sensitive information about the organization’s internal databases. A screen shot of the title page is below."
The above information gives the impression that something had happened a couple of years ago, an event that had prompted both the migration of systems and above all that had necessitated the implementation of a recovery procedure.
The info, though consistent, requires further study, but it is worth pointing out that other companies in the past which were victims of such incidents had discovered their systems were vulnerable long after the real date of the breach.
Crucial is being able to date the real involvement of the company and its management to determine if communications had been omitted in the past, an event that would have provided a case of failure in proper handling of the initial breach providing an advantage to the attackers.
These are all hypotheses that have as their intent to emphasize the importance of two factors:
  • implementation of procedures for the technical response to the events
  • media management of the event itself and its communication to business partners
The two aspects are strongly correlated and demonstrate that sometimes while managing the incident in a technically impeccable way, the omission of information about third parties can cause extensive damage and trigger dangerous mechanisms that can lead to disastrous consequences.
In the meantime, Visa temporary removed Global Payments from its list of "compliant service providers", leaving the door open to the company for reinstatement once the processor can be aligned again with "Visa's standards."
Looking the problem from the perspective of the customers, I can only suggest to them to wait to be contact by their banks, but in the meantime to monitor transactions on their accounts. The risks of counterfeit credit cards and illicit transactions is high.
Let's remember that Global Payments in a statement admitted:
"The investigation to date has revealed that Track 2 card data may have been stolen, but that cardholder names, addresses and social security numbers were not obtained by the criminals."
Visa referred ABC News to the Global Payments' announcement that Track 2 data was stolen.  While track 2 is used by the bank for the operation, "Track 1" data generally refers to the information reported on the front of a bank card, so if this information is stolen along with that contained in "Track 2", it is possible to clone a card.
Finally, I leave you with a thought: The fact that the company did not immediately discover the number of cards exposed leaves me thinking that it did not identify with any certainty the exposed portion of the system and the agent that made possible the exploitation of the vulnerability .
I think there are more questions still about the event than answers, so I hope in the next few days we will be able to faithfully reconstruct the events.
References:
Cross-posted from Security Affairs

Disqus for ePayment News