Tag Archives: malicious software

Malware Inside the Credit Card Machine

image

(Update, July 2009: A BusinessWeek article puts the company’s side; maybe I was a little too harsh on them in this post.)

This gives you an idea of how bad malware is getting, and how much we’re underestimating it: a U.S.. company that processes credit card transactions has just revealed that malware inside its computers may have stolen the details of more than 100 million credit card transactions. That would make it the biggest breach in history.

Heartland Payment Systems, one of the fifth largest U.S. processors in terms of volume, began receiving reports of fraudulent activity late last year. But it took until last week to find the source of the breach: “A piece of malicious software planted on the company’s payment processing network that recorded payment card data as it was being sent for processing to Heartland by thousands of the company’s retail clients,” according to Brian Krebs of The Washington Post.

Revealed were credit/debit card numbers, expiry dates and names of customers to some, or all, of more than a quarter of million retail outlets. Bad guys could make fake cards based on this data, but they probably couldn’t use it to buy stuff online, the company said. (At least one observer has characterized this as garbage, opining that a lot of eCommerce merchants turn off their Address Verification System because of errors, and fears of losing the customer.)

That it took so long is pretty extraordinary in itself—these are, after all, the company’s own computers. We’re not talking about investigators having to track down malware on one of its customers computers, or somewhere in between. But that’s not all that’s remarkable: It looks like the certification that these kinds of operations rely on, the Payment Card Industry Data Security Standard, or PCI DSS, was issued last April  (here’s the proof. Certificates are valid for a year). This suggests according to Digital Transaction News, that the bad guys have found a way around the industry standard level of protection.

Also remarkable is this: The company chose to release the news on Inauguration Day, a fact that has rightly prompted accusation the company is burying the news. The company has played down the seriousness of the breach, saying that not enough information was revealed about individual cards for identity theft to be an issue, while at the same time suggesting that it’s part of a wider “cyber fraud operation.” I’m not sure it can have it both ways.

The company but has set up a website for concerned individuals at 2008breach.com. (Note the cute use of last year to make it seem like something of historical interest only—or maybe 2009breach.com was already taken? That doesn’t seem to have stopped worried customers trying to log on; as of writing the website, and those of the company, are down—possibly because of visitor traffic.)

Apart from the insubstantial response of HPS itself, it’s worth pointing out that this kind of attack is not new. CardSystems, another processor was breached in 2005—apparently via malware which grabbed data it was storing (rather than processing.)

I was kinda skeptical back then of the way it was handled—the company itself delayed release of the information for a month. More digging suggested that the information had been available far longer. It was perhaps understandably coy, given these things never end prettily: Within a few months what was left of CardSystems was acquired by Pay By Touch, also known as Solidus Networks, just in time for it be slapped down by the FTC. Pay By Touch itself closed down last year and its website is no longer active.

What this new breach seems to tell us is that the bad guys are—and probably always have been—smarter than the good guys. Data within a payment processor like HPS does not need to be encrypted—indeed, the company argues it can’t be encrypted, because it needs to be processed—so while CardSystems was clearly in breach of the rules by storing data, HPS is arguing that it’s not.

But all this tells us is that the security measures in place to protect our data are not enough. God knows how that malware got into their computers. And why it was so hard to trace once it—or something–was known to be there. But the lesson from this miserably handled episode has to be that security and oversight need to be tightened, while transparency towards customers—the individuals who have to pick up the pieces, by scanning their monthly statements for months to come for possible fraud—has to be seriously improved.

The bigger issue, of course, is to finally wake up to the fact that malware is no longer some obscure corner of security matters, but something that affects all of us.

Image: Screenshot of the inaccessible 2008breach.com website.

When Chatbots Go Bad

Richard Wallace of the A.L.I.C.E. AI Foundation, Inc. and creator of the Alice chatbot says his creation (sorry, can’t find a permalink) may have been lured to the dark side:

I have received a multitude of emails recently from subscribers to MSN Instant Messenger services, from people who have chatted with a clone of ALICE on their system who have suspected that this clone is downloading spyware onto their machines. The threat of malicious bots releasing viral software has appeared before, but this is the most serious incident so far. Like many clones of ALICE, this one appears to contain the basic AIML content containing my email address and references to the A. I. Foundation, which of course has nothing to with malicious software. But it directs people to complain to me.

New Scientist quotes Richard as saying that “this is insidious because compared to other bots, she does the best job of convincing people that she is a real person.” I’m not quite clear as to how this happens, but it would appear that anyone chatting with these Rogue Alices would be infected with spyware via MSN chat.

If so, is this the start of something? As chatbots get better, can we expect them to spread through every online social tool, infecting us with their sleaze and reducing our trust levels to zero.