John PescatoreCloud computing continues to proceed on its merry way through the Gartner hype cycle. As part of its trip towards the trough of disillusionment, clever hacks are coming out on how to make the cloud do bad things. Brett O’Connor has posted some simple directions on how to set up Bit Torrent services on Amazon’s EC2 cloud services, and a commenter showed how it could be done on Amazon’s S3 service. This means users can access BitTorrent’s tremendous network of malware-infested files by going to Amazon services, making it harder to block from the enterprise perspective.
Now this isn’t truly a hack – he is paying for Amazon services and just happens to be running an application (BitTorrent) that carries a lot of content that is either pirated or malicious. Amazon does include a terms of service warning:
Certain services are prohibited, and you may not operate a site or service that:
- Constitutes, promotes, facilitates, or permits gambling.
- Includes, promotes or facilitates child pornography or other illegal activities, including without limitation any activities that might be libelous or defamatory or otherwise malicious or harmful to any person or entity, or discriminatory based on race, sex, religion, nationality, disability, sexual orientation, or age.
- Engages in deceptive practices such as posing as another service for the purposes of:
- Phishing.
- Pharming.
- Distributes, shares, or facilitates the distribution of unauthorized data, malware, viruses, Trojan horses, spyware, worms, or other malicious or harmful code (collectively, “Harmful Components”).
- Violates, misappropriates, or infringes the rights of any third party.
- Constitutes or facilitates the illegal export of any controlled or otherwise restricted items, including without limitation, software, algorithms, or other data that is subject to export laws.
But will Amazon (and other cloud providers) police their services to detect and block these prohibited uses? BitTorrent clearly violates several of these conditions.
Well, ISPs don’t do very much to block these kinds of services – should cloud providers act differently than ISPs? I think they should – they shouldn’t have the kind of common carrier protection that telecomms and ISP firms have had. However, I’m sure cloud providers will argue they are more like public storage rental facilities – they can’t be liable for what is stored and done inside the “space” they rent out on a monthly basis.
We went through this same issue back in the mid-1990′s when spam first became an issue and the telecomms players managed to use the common carrier angle to not have any responsibility for the nastiness of the bits they were carrying back and forth. ISPs were getting paid to carry those bits and were loathe to take steps to reduce their own revenues. It would be nice to think that in this era of social networks and Web 2.0 and the cloud that things will be different, but I doubt it – cloud-based services will likely be a cheap means of producing all kinds of large scale nastiness.
Of course, botnets have proven that the bad guys have already figured out how to assemble their own “cyber crime as a service” cloud and really don’t need to pay Amazon or anyone else.
Category: Uncategorized Tags:
6 responses so far ↓
1 John Pescatore: Will the Cloud Produce Acid Rain? January 26, 2009 at 7:24 pm
[...] Read more… Share: [...]
2 Ilya Rabinovich January 27, 2009 at 5:04 am
Hi John!
BitTorrent? Wrong! Rainbow tables on Amazon EC2- that’s really kicking staff.
3 John Pescatore January 27, 2009 at 6:06 am
Yes, great point. We have talked about how cheapening compute cycles will make brute force attacks more affordable for bad guys, whether through P2P things like Deep Crack or via cloud computing.
Now, moving to longer salt values, like in bcrypt, make rainbow table attacks much more computationally expensive. Moore’s law has meant that authentication technologies don’t need to focus on reducing their computational cost – servers have plenty of power for dealing with user logins that use less efficient approaches that make it more costly for the attackers.
4 Ilya Rabinovich January 27, 2009 at 8:42 am
Unfortunately, MS SMB RC4-based authorization algo has no salt at all. That’s the point! You have to use 128-char passwords or block SMB access with firewall/router (or whitelisting IP’s) in order to protect your IPC$ sessions.
5 Lydia Leong February 5, 2009 at 9:09 pm
I actually disagree with you sharply on the spam issue, in terms of historical ISP behavior. (I was there, as it were, having started the abuse department at Digex, and dealt with various ISP industry anti-spam efforts through the mid to late 90s.)
In the mid-90s era of the business ISP industry, ISPs didn’t require customers to sign an acceptable use policy. Contractually, you could only terminate a customer for doing something illegal, and spamming was not actually illegal. As spam volumes picked up, ISPs went through the process of consulting lawyers, writing enforceable AUPs, and including a contractual requirement to comply with the AUP. It wasn’t so much that those ISPs wanted to service spammers, as they’d ended up signing a bad apple, and had to go through a defensible process to terminate a contract.
Making things worse was the fact that those spammers would go through all kinds of shenanigans to hide their identity. And you didn’t actually want them as a customer, since there was a good chance that they wouldn’t pay their bill. And when you terminated them, it was you, the ISP, who was stuck holding (and paying for) the contract for the local loop, so the entire mess would cost you a bundle. But they knew, and you knew, that if they managed to fool you into selling them service, it would take you probably 90 days to terminate them, during which they could happily spam away while you seethed.
There were certainly exceptions — ISPs who were desperate for revenue, any revenue, and were willing to tell everyone else to sod off. But by and large, the industry self-policed fairly decently, with upstream providers enforcing AUPs on their downstream. (You’d always have problems with downstream web hosters who weren’t terminating spammers quickly enough, for instance.)
Most hosters are pretty aggressive about terminating illegal activity when it’s brought to their notice. I’m hearing from the cloud providers that it’s difficult for genuinely elastic services, though. It’s basically the same problem that you had with dial-up accounts back in the ’90s. Someone would buy a dial-up account with a credit card (often a stolen card), then use the account to send spam until terminated (which usually didn’t take long, but was enough time to make it worthwhile). Same thing here — buy some virtual servers with a credit card, send spam (or conduct some other illegal activity) until terminated, rinse and repeat with a different card.
Amazon and many other cloud providers are generic compute providers, so they can pretty much be used to do anything illegal that you could do on any other server.
6 John Pescatore February 6, 2009 at 5:45 am
My experience doesn’t match up with yours. In about 1996 or 1997, I ran a panel at the old National Information Systems Security Conference in Baltimore and had the CISOs of some of the largest (at the time) ISPs and they all basically said they knew who the spammers were but the corporate lawyers *and* the product managers would not let them be shut down.
Even since then, the ISP industry has *by no means* policed itself decently. They have certainly responded to complaints from large customers but that is about it. Now, lots of spam is really just unsolicited commercial email – the ISPs don’t need to deal with that. But so much spam and phishing is patently malicious and using spoofed IP addresses and with some investment could have been dealt with.
Yes – the bad guys use clever tactics, good guys can be clever, too, if they choose to attack the problem. Once high-bandwidth consumption attacks (like worms) started impacting ISPs bottom lines, we saw them start to try to take action -but mainly by lobbying Microsoft to add features like the Malicious Software Removal tool to remove common worms from infected PCs that were impacting consumer ISP capacity – rather than doing something themselves to block attacks. They were in a low margin business and none of them wanted to make the capital investment to reduce (not eliminate) the problem their customers were having.
I had many conversations with people at carriers about “book to bill” hurdles that kept them from being able to buy the security technology needed – they could only do so when customers began to ask them for a paying service. DDoS prevention is a great example – ISPs did very little about it but once large banks began to ask about paying for filtering, they all ran out and bought Arbor Peak Flow and Cisco Guard.
Ditto hosters – they are only aggressive when someone complains. Yes, the large ones are a bit better, but not all that much. When those credit card accounts were active it was revenue – if no one complained to a hoster, the hoster did nothing. If the spammer or malware spreader shut down before the hosters even knew what was going on, then the hosters were not paying attention – they weren’t making the investment to know that their services were being used for illegal activities. Pretty straightforward IDS would tell them in minutes.
As you describe, cloud providers are pretty much following that same arc – depend on terms of service clauses for legal cover, but don’t invest in means of reducing how easy it is for your customers to violate ToS unless it impacts your capacity.
Leave a Comment