Amazon Responds About SIP Attacks From EC2

On April 18th Amazon finally responded publicly with respect to the SIP attacks recently suffered from hosts within their EC2 service. Their response comes in the form of an informational security bulletin posted to their AWS Security Center.

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.

They are correct in that there was nothing special about the attack itself. That is, nothing unique that required the use of EC2. However, the very scalability of EC2 that is heralded as magnificent for business also makes it an ideal platform from which to launch large scale attacks of any kind.

I remain disappointed at their claim of action when contrast against Fred’s actual experience. They were unacceptably slow to respond, and remarkably opaque about the matter.

Further, their direct contact with Fred was solely by way of their PR department. That just about perfectly frames up their understanding of the issue; a public relations matter.

Security is more than a public relations issue!

If I were subject to such an attack, and met with this kind of response from the company hosting the attack I would immediately report it to the FBI Cyber Crimes Unit.

Perhaps such attention might help compel the host to move more swiftly in addressing the matter. Perhaps it might even get elevated beyond the public relations department.

  • I found their response insulting and a couple of sentences really set me off:

    “However, when abuse is detected, we are able to act swiftly to isolate the abusive behavior.”

    Would they consider it swift if I took more than a week to isolate a server in my network that was attacking their phone system?

    “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.”

    I can sum my reaction to this in three letters. W T F. Really amazon? Really? We’re going to engage with significant SIP providers. Non-significant SIP providers will continue to be ignored and receive slow responses.

    My boycott continues.

  • Aaron

    Amazon haven’t been in touch with the provider I know that reported the issue weeks ago. Amazon should be able to respond to these sort of incidents within hours. I know of 3 independent sources that reported the SIP attack to Amazon and yet it still took them over a week to act. I can see EC2 becoming infested with crackers unless Amazon pull their socks up in a hurry!

  • Interesting, just had such a brute fore attack from within amazon coming from 79.125.87.153 (ec2-79-125-87-153.eu-west-1.compute.amazonaws.com) should I even bother to report to amazon? or would it be better just find the IP range and just block it for ever.

    • As I have said elsewhere, you should report it to Amazon. However, if they fail to act in a reasonable space of time you should report it to the FBI Cyber-Crimes Unit.

  • @Cristian,

    I’d recommend both. 🙂

    I still have not had a response from my complaint (other than the PR response).

  • I did report it about 30 min after writing my comment (to amazon, not FBI). no answer so far. 3 Servers where affected. I banned the complete amazon IP ranges mentioned here: http://lists.digium.com/pipermail/asterisk-users/2010-April/247123.html

    I also limited the new connections to port 5060 to 3 per 60sec.
    Using shorewall:
    Limit:info:VOIP,3,60 net $FW udp 5060

    Or with pure iptables like described here: http://pbxinaflash.com/forum/showthread.php?t=5018

    I hope this will settle things a bit. Unfortunately fail2ban didn’t help since the attacks are to fast for fail2ban to react.
    A further problem is that asterisk reacts different depending if a users exists or not.
    Oh well, IT life would be boring without hackers wouldn’t it ? 🙂

  • Have you had any cpu increase or jitter with that method?

    I posted a perl script that uses iptables in a separate chain on Team Forrest:

    http://www.teamforrest.com/blog/171/asterisk-no-matching-peer-found-block/

    Of course, it will only run at the speed of cron, which may be to slow for you if fail2ban wasn’t good enough. That being said, with it dropping all traffic, generally it work well. I make sure my peers aren’t extensions or regular dictionary words, and it’s been decent. The normal attack is 2 – 5 minutes, and the script has been catching them. I like using a separate chain just to track it (I block other violations in diff chains).

    Fred

  • didn’t have any problems so far, but I must admit it’s not really a high load server. It’s a small XEN virtual server with only 512MB RAM. But enough for what I need.
    But I didn’t see any log entries which triggered the firewall rule, except the ones where I tested it. So it seems to work without influencing SIP traffic at all.

    I did report the incident to amazon and there where some funny lines in their answer.

    “We have completed an initial investigation of the issue and learned that the IP address you reported did indeed belong an Amazon EC2 instance.”

    oh really?

    “We’ve already contacted the Amazon EC2 customer who controlled the instance in question and informed them that they are required to terminate their unauthorized interaction with your network, failing which we will terminate their instance.”

    so basically they have sent that user a warning message and that was it.

    Two days later I received a new message which just tells me that incident was closed.

    I’m curious how they would react if we all started brute forcing amazon services.