As a technology enthusiast first, and an information security professional second, I admire the internal complexity, external simplicity, and sheer power offered by Amazon's cloud computing services. Academics have forever fantasized about instant-on-pay-per-use-grid-computing. Amazon has been able to turn this into reality. The advent of utility computing indicates progress: it is 2009 - most of us shouldn't have to dwell on organizing computing infrastructure - rather, most of us should be able to take computing for granted so we can create great things with it.
I'd like to discuss how the EC2 service, as it stands currently, can and is being abused by criminals. I'm not the first person to bring up this problem, yet it is an important issue that is worthy of further discussion because it exposes an extraordinarily powerful infrastructure into the hands of cyber-criminals.
For the purpose of this conversation, I want to take upon how the criminals in the phishing underground are likely to benefit from Amazon's EC2 because it ties back to what I feel is the root issue (the credit card system). I'd also like to invite you to read an interview with Billy Rios and me, titled Spies in the Phishing Underground, to gain some further background on the characteristics of the average phisher, common tools used, and how the criminals are able to communicate and trade knowledge.
In order to setup a phishing site, the first task a criminal has to complete is to compromise and gain access (or obtain by way of bartering) to a server on the Internet. The next thing the phisher is likely to do is to un-archive a ready-made phishing-kit (HTML, JavaScript, and images representing the target organization's logo, in addition to a server side script that is responsible for collecting the POST variables and emailing them to a static email address owned by the phisher) in the web-root of the web server running on the compromised host. And there you have it, a fully working phishing site.
A typical phishing site is found out by the targeted organization via customer complaints or by the aid of community driving anti-phishing efforts (example: Phishtank). Once this happens, the ISP who owns the IP address of the compromised host is identified and contacted. All of this happens within a matter of hours. In other words, the time-to-live of phishing sites is less than a day, if even a few hours. This promotes a whack-a-mole approach to the problem: criminals setup phishing sites as fast as they can, while organizations that are targeted must locate them and attempt to shut them down by contacting the ISPs.
The goal of the targeted institutions is to play the whack-a-mole game faster: find the phishing sites as fast as possible and shut them down before their customer data is stolen.
On the other hand, the goal of the phisher is to play the whack-a-mole game harder: quickly spawn new instances of phishing websites and lure potential victims to submitting their information. Because the time-to-live of phishing sites is only a matter of hours, it is in the best interest of the criminals to continue to seek out faster methods of spawning new instances of phishing sites. This is why Amazon EC2 is a ripe platform for the phishers. If you are a phisher, this is the process you can follow to abuse the EC2 platform:
- Sign up for an Amazon account and EC2 service using a single stolen credit card.
- Configure an EC2 virtual instance (AMI) to host a phishing site.
- Spawn n instances of the AMI. Phishing sites are now active (if the default number of instances a new customer is allowed to create is low, the phisher will have to create m Amazon accounts in step 1. to get n X m instances if that is the goal).
- Collect thousands of additional credit card numbers in a matter of hours.
- Amazon is likely to be notified of the phishing sites and will terminate the account and all associated AMIs. No problem. Just select one credit card out of the hundreds or thousands you have likely to have captured in step 4 and go back to to Step 1.
Do you see the problem at hand? EC2 is an extraordinarily powerful infrastructure available to anyone with a stolen credit card. Even if someone is able to use the EC2 platform for a few hours with a stolen credit card, he or she will be able to initiate a vicious cycle that may become impossible to halt.
I feel that the root cause of this situation is that credit institutions, based on weighing lost revenue to the amount of fraud committed, have decided to accept the fraud because the cost of instituting a more secure mechanism (biometric or 2-factor, for example) is higher than the cost of the fraud. Profitable institutions have the right to make a business decision such as this, but the problem in this scenario is that the cost of the fraud due to credit card transactions, which are insecure by design (the credit-card system is based on a static number that never changes), is also borne by merchants such as Amazon and also the organizations that run business using the Amazon cloud, yet this cost is not figured into the original business decision.
I think this is a disappointing situation. From a business perspective, I sympathize with Amazon - here is a company that wants to offer bleeding-edge innovation to the masses, yet they are unable to find an alternative to the credit-card system without having to compromise and make it difficult for the legitimate people to also use the service. Even so, I am glad that Amazon continues to offer their platform to the masses. Innovation should be allowed to drive forward. Always.
It isn't within the scope of this write-up to consider technical tactics Amazon could use to lower the impact and probability of the problem (but feel free to comment if you want to discuss). However, I do wish that Amazon did a better job of setting up a clear channel of communication so information security researchers and administrators are easily able to reach them. I have been asked for advice by some organizations who have noted denial of service attacks launched their way, originating from the Amazon cloud space, and I'm told it often seems next to impossible to reach anyone at Amazon who knows or cares enough to look into the matter.
In closing, you may be interested in my earlier write-up on this topic which is a little dated but may still be of some value: Amazon's Elastic Compute Cloud [EC2]: Initial Thoughts on Security Implications.
