Hacker Economics 2: The Conspiracy of Apathy

April: The iFrame Problem
In early April, the Spring Edition 76service server in Hong Kong was taken down. Filters added the new Gozi variant to their lists of detected malware. On the run again, 76 and Exoric would fold up their tent and modify Gozi to be undetectable again while they found a new place to set up shop. And when they did, the steps would start again, the two sides entwined in an endless, uneasy foxtrot.

Jackson continued to help where he could but much of this was out of his hands. He had since immersed himself in another facet of 76service—its distribution mechanism.

No matter how inspired the idea of a subscription to infected machines was, or how cleverly engineered the bot that infected those machines was, 76’s and Exoric’s success with 76service, surprisingly, relied on something they didn’t develop themselves, but rather contracted out: distribution, for which they used iFrames, a browser feature that allows Web sites to deliver content from a remote Web site within a frame on a page. Think of stock quotes origination from one site streamed into a small box on another site. (For more about iFrames, see Death by iFrame.) 76 and Exoric used iFrames to infect computers – but in April they had contracted this part of the work out to another service, iFramebiz.com.

Jackson found a partial list of sites hosting the iFrames used exclusively for Gozi. Jackson sampled 5,848 pages, only a portion of the infected pages on his partial list (meaning 76 and Exoric probably paid tens of thousands of dollars for iFrame infections). Some of the iFramed sites on his list were offline. Some had been cleaned up. But 2,079 of them, more than a third of the sample, still had the code online, ready to deliver new, undetectable versions of Gozi as soon as they were ready. A month later, when Jackson took attendance again, 98 percent of the 2,079 were still hosting the iFrame.

Even if Gozi was gone for good, the iFramers would be happy to resell access to these iFrames to the next malware developer.

Transferred Risk
As much as the HangUp Team has relied on distributed pain for its success, financial institutions have relied on transferred risk to keep the Internet crime problem from becoming a consumer cause and damaging their businesses. So far, it has been cheaper to follow regulations enough to pass audits and then pay for the fraud rather than implement more serious security. “If you look at the volume of loss versus revenue, it’s not horribly bad yet,” says Chris Hoff, with a nod to the criminal hacker’s strategy of distributed pain. “The banks say, ‘Regulations say I need to do these seven things, so I do them and let’s hope the technology to defend against this catches up.’”

“John” the security executive at the bank, one of the only security professionals from financial services who agreed to speak for this story, says “If you audited a financial institution, you wouldn’t find many out of compliance. From a legal perspective, banks can spin that around and say there’s nothing else we could do.”

The banks know how much data Lance James at Secure Science is monitoring; some of them are his clients. The researcher with expertise on the HangUp Team calls consumers’ ability to transfer funds online “the dumbest thing I’ve ever seen. You can’t walk into the branch of a bank with a mask on and no ID and make a transfer. So why is it okay online?”

And yet banks push online banking to customers with one hand while the other hand pushes problems like Gozi away, into acceptable loss budgets and insurance—transferred risk.

As long as consumers don’t raise a fuss, and thus far they haven’t in any meaningful way, the banks have little to fear from their strategies.

But perhaps the only reason consumers don’t raise a fuss is because the banks have both overstated the safety and security of online banking and downplayed negative events around it, like the existence of Gozi and 76service.

So did the banks create a false sense of security or did consumers drive them to not address it through their apathy? The banks themselves might argue that they are acting responsibly. It’s hard to tell since most decline to talk about the problem. Bill Nelson is president of the Financial Services Information Sharing and Analysis Center, or FS-ISAC, a group for bank security executives where they can safely share intelligence and other information. Membership in the FS-ISAC has increased from 68 in 2004 to 2,200 this year. “That’s not a lack of interest,” says Nelson.

Nelson was the closest person to bank security executives who would speak on the record. He bristled at the notion that banks are carelessly pushing services they can’t secure. “It’s being misinterpreted that banks don’t care about security. They spend millions of dollars on this. These are good, quality people,” Nelson says.

If anything, say Nelson and others, blaming banks is precisely backwards. If you want to point fingers look at their customers, who’ve created the demand for the product in the first place. “It’s kind of ridiculous to think you wouldn’t, as a bank, use the Internet as a transport,” notes Hoff. “If you’re not offering some form of online banking, you’re going to wither away and go out of business.”

Eric Johnson, an economist at Dartmouth who recently published a study on malware on peer-to-peer networks says, “Customers are the banks’ worst enemies here. Customers are exposing lots of material that creates an environment for identity theft.”

Indeed, many malware problems are intimately connected to insecure PCs and finicky consumers who, even if they say otherwise, value convenience over security. As one CISO at a bank put it—anonymously, of course, “Users are pretty dumb.”

Next: Hacker Economics 3: MPACK and the Next Wave of Malware recounts the demise of 76service and the emergence of more powerful form-grabbing technology.