A major SIP attack launched from Amazon's EC2 cloud raises questions about cloud security.
The Amazon Elastic Compute Cloud (EC2) service is a poster child of the cloud revolution. Making massively scalable resources available without significant capital investment is a revolutionary concept that's ideal for bursty businesses such as Intuit's TurboTax. Telephony related firms such as Twilio and Ribbit rely on Amazon's services to instantly expand as their customers and projects require.
EC2 is a web infrastructure service that provides instant application-ready infrastructure that charges by usage instead of capacity. According to the EC2 website, "Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change."
The elasticity and scalability associated with EC2 were unheard of just a few years ago, and are still astounding. But what happens when those resources are used for evil instead of good?
Last week, a major SIP attack was launched from the EC2 cloud. It was a brute force attack that searched for open SIP ports in order to unrelentingly pound on phone systems searching for valid credentials.
Brute force attacks such as these are not uncommon--and sometimes are actually intended or act as a denial of service attack (DoS). But this is the era of the cloud, and "massively scalable" applies to attacks as well. One blogger reported the attack was on track to consume 6-10 GBs of traffic in one day on his WAN.
What Happened
Amazon Web Services (AWS) offers what's known as Infrastructure as a Service (IaaS) and is just one form of cloud computing. Though AWS is rather small in Amazon's portfolio, it is experiencing rapid growth and could conceivably overtake its e-commerce business in the future. Amazon's IaaS offering includes highly scalable virtual servers, storage, and networking services available on-demand without a contract and charged with a pay-as-you-use model. It allows organizations (and individuals) to develop core applications and capabilities without having to build, fund, and manage the capital equipment and physical aspects of a data center. Numerous success stories exist. Consider Netflix, which is experiencing a major shift in business model from physical DVD rental to real-time video streaming. Neflix selected Amazon's EC2 service for infrastructure rather than build-out a data center.
Last week, a number of telecom administrators noticed a major attack on their systems. Administrators started discussing over Twitter and VoIP groups a development that was to become a three-day attack. The widespread assault was coming from Amazon EC2 at an amazing rate.
SIP attacks are not new, but it is clear that cloud technology brings a new level of capability, capacity, and anonymity to the security problem. All it takes to unlock Internet services capable of mass destruction is a credit card.
It appears the intent of the attack was only to scan for valid SIP credentials. A valid SIP registration can be sold, used for toll-fraud, used to masquerade as the victim, or as a means to bypass surveillance such as wiretapping.
There was no indication the attack specifically targeted particular users or phone systems--rather it likely hit Internet sites scanning for UDP access on port 5060. Asterisk systems log such attempts visibly, and the Asterisk community of users reached out to each other. In particular, administrators Fred Posner and Stuart Sheldon independently blogged their observations and reported the matter to Amazon. Posner blogged: "The [brute force attack] complaints mentioned this weekend show an excessive amount of traffic; with some providers claiming 6GB of traffic dedicated to such attacks. Since we ourselves received an attack from an Amazon hosted server, we also reported and complained to the Amazon NOC/Abuse depts."
Amazon had little to say about the incident, and certainly took what some feel was an unreasonable amount of time to stop it. Amazon did not return calls regarding this story--nor was particularly communicative to those that filed abuse alerts.
Update: On April 18--after this article was written but before it was posted--Amazon Web Services posted an acknowledgement of the attack on its website:
There have been some recent discussions about SIP brute force attacks originating from Amazon EC2. We can confirm that several users reported SIP brute force attacks originating from a small number of Amazon EC2 instances about a week ago. It appears these attacks were designed to exploit security vulnerabilities in the SIP protocol. There is nothing specific about this attack that requires Amazon EC2. It was a brute force attack that could be launched from any computer on any network.
The behavior of these instances clearly violated our terms of usage. We responded to the abuse reports according to our normal abuse reporting procedures and shut down the abusive account when we were able to confirm the abusive behavior. We take all claims of misuse of our services very seriously and investigate each one. When we find misuse, we take action quickly and shut it down. Our terms of usage are clear and we continually monitor and work to make sure the services aren’t used for illegal activity. It’s important to note that we take the privacy of our customers very seriously, and don’t inspect the contents of instances. This is part of the reason that legitimate customers of all types are comfortable running production applications on Amazon EC2. However, when abuse is detected, we are able to act swiftly to isolate the abusive behavior.
We are looking closely at this event to determine how we can respond better in the future. First, we have made modifications to our abuse detection protocols so we can more quickly and identify SIP based abuse in the future. We are also engaging significant SIP providers to open up communication channels so we can quickly respond to any significant SIP abuse that is not detected in the future. Finally, we are working on making modifications to our abuse reporting mechanisms to better assure we respond promptly in situations like these.
If you suspected misuse of Amazon EC2, please email [email protected]
It is not known if the attacks stemmed from a compromised customer of Amazon's services or if the attackers actually directly purchased Amazon services in order to launch the attack. Both Posner and Sheldon notified Amazon by sending detailed information including logs and IP addresses to Amazon's published abuse EC2 address. Posner received an email response 48 hours later asking him to resubmit the information via an Abuse Report Form (Amazon does not accept attachments). Posner attempted to resubmit the information but said the form's submit link was broken.
There have been some recent discussions about SIP brute force attacks originating from Amazon EC2. We can confirm that several users reported SIP brute force attacks originating from a small number of Amazon EC2 instances about a week ago. It appears these attacks were designed to exploit security vulnerabilities in the SIP protocol. There is nothing specific about this attack that requires Amazon EC2. It was a brute force attack that could be launched from any computer on any network.
The behavior of these instances clearly violated our terms of usage. We responded to the abuse reports according to our normal abuse reporting procedures and shut down the abusive account when we were able to confirm the abusive behavior. We take all claims of misuse of our services very seriously and investigate each one. When we find misuse, we take action quickly and shut it down. Our terms of usage are clear and we continually monitor and work to make sure the services aren’t used for illegal activity. It’s important to note that we take the privacy of our customers very seriously, and don’t inspect the contents of instances. This is part of the reason that legitimate customers of all types are comfortable running production applications on Amazon EC2. However, when abuse is detected, we are able to act swiftly to isolate the abusive behavior.
We are looking closely at this event to determine how we can respond better in the future. First, we have made modifications to our abuse detection protocols so we can more quickly and identify SIP based abuse in the future. We are also engaging significant SIP providers to open up communication channels so we can quickly respond to any significant SIP abuse that is not detected in the future. Finally, we are working on making modifications to our abuse reporting mechanisms to better assure we respond promptly in situations like these.
If you suspected misuse of Amazon EC2, please email [email protected]
The behavior of these instances clearly violated our terms of usage. We responded to the abuse reports according to our normal abuse reporting procedures and shut down the abusive account when we were able to confirm the abusive behavior. We take all claims of misuse of our services very seriously and investigate each one. When we find misuse, we take action quickly and shut it down. Our terms of usage are clear and we continually monitor and work to make sure the services aren’t used for illegal activity. It’s important to note that we take the privacy of our customers very seriously, and don’t inspect the contents of instances. This is part of the reason that legitimate customers of all types are comfortable running production applications on Amazon EC2. However, when abuse is detected, we are able to act swiftly to isolate the abusive behavior.
We are looking closely at this event to determine how we can respond better in the future. First, we have made modifications to our abuse detection protocols so we can more quickly and identify SIP based abuse in the future. We are also engaging significant SIP providers to open up communication channels so we can quickly respond to any significant SIP abuse that is not detected in the future. Finally, we are working on making modifications to our abuse reporting mechanisms to better assure we respond promptly in situations like these.
If you suspected misuse of Amazon EC2, please email [email protected]
Posner's bot response from Amazon said:
Thank you for contacting Amazon Web Services. We take reports of unauthorized network activity from our environment very seriously. It is specifically forbidden in our terms of use. Because Amazon EC2 Public IP addresses may change ownership frequently, without additional information we will be unable to identify the correct owner of the IP address for the period of time in question.
Posner ridicules Amazon's inability to track address usage, and he questions Amazon's commitment to controlling forbidden activities, since the attacks lasted three days. In a subsequent communication received by Posner, Amazon explained, "Our normal process is to connect the two involved parties to give them an opportunity to talk in case the abuse is not malicious, but is simply heavy traffic from a legitimate customer."
Sheldon acted on this and went through Amazon's brokerage service that allows anonymous direct communication between parties. He did not expect or receive a response as the attacks continued. Sheldon took more aggressive protective action. "After this last attack, we have adopted a policy of dropping EC2 network connections to certain services at the network edge. If they are unwilling to properly control their network, we will control what their network can see on ours."
Sheldon added, "If a customer on our network violates policy, they are subject to being blocked and shutdown. This is the way it is with almost every network out there. Amazon's position was to do nothing. They allowed the attack to continue against innocent operators for days. These operators may have suffered loss of business due to saturation of carrier, and I have yet to see so much as an apology from Amazon."
Conclusion
Cloud services bring unprecedented instant computing and network capacity that is changing the way organizations evaluate and plan IT budgets and projects. But there is a dark side to this powerful force.
Sheldon said "Attacks of all kinds have been originating from EC2 since they started. You can look back through Google and see complaints from people being hammered by SSH brute force attacks, as well as SPAM originating from EC2 systems. The truth is, EC2 is a perfect service to base attacks from. Systems are transient, and you don't need much more then a credit card and an internet connection to use the service."
For whatever reason, Amazon is saying nothing on this one, which is only feeding the fire of discontent. In addition to administrators completely blocking EC2, some claimed to have cancelled unrelated EC2 accounts. One blogger chimed in saying he will buy merchandise elsewhere as well.
Amazon has been a major part of both the Internet and cloud revolutions, but evidently needs to brush-up on security. There is a possibility that Amazon worked feverishly to contain the damage and protect a compromised customer--that would be a nice thought. But the evidence of a prolonged attack, no public communication or response to submitted alerts, and the confession it doesn't log how customers use public IP addresses all suggest a very immature stance on security.
Dave Michels is a regular contributor and blogs exclusively about telecom at www.pindropsoup.com.
