Building The Net

Amazon Brute Force SIP Attacks – Dave Michels Interviews Me.

Shortly After my “SIP Brute Force Attack Originating From Amazon EC2 Hosts” post, Dave Michels interviewed me for an article Dark Side of the Cloud. This is that interview:

Dave:   What do you believe the intent was of the attacks? Free long distance?

Stu: Certainly free long distance would be one reason… But there are many other reasons to hijack a SIP account. I’m sure that organized crime would pay for a block of active SIP logins. They could use them to circumvent surveillance, or possibly use them for fraudulent boiler room calls about extended warranties and such.

Remember, most folks still believe that the Telephone System is secure… They tend to believe someone who is calling them.

Dave: Do you know of any systems that were compromised by the attacks?

Stu: That were actually compromised? No, I have no direct knowledge of that, but most of that info won’t be available for months. Let’s face it, we (SIP providers) have only heard about the attacks that were caught. If you look at the overall picture, we are probably only seeing about 2%-5% of the total attacks reported at this time. From reviewing the logs on our systems, I could see how this attack could easily compromised accounts.

This incident is far from over as far as fallout goes…

Dave: Do you think the attacks were targeted at Asterisk systems or any SIP system?

Stu: Any SIP system would have been a target for the attack. Ironically, most of the reports came from Asterisk operators, because Asterisk actually gives you access to logs you can make sense out of. From my experience, most commercial solutions do not provide the same kind of info that Asterisk does to the operator. So, a proprietary SIP proxy or PBX could have been diagnosed as being “hosed” for some unknown reason, and reset several times until the attacker got what he was looking for, or went away.

Dave: How do you think the attacks found target systems?

Stu: Simple port scanning. Find UDP/5060 and you probably have found a SIP proxy / PBX.

Dave: My guess is the attacks came from a system on EC2 that was compromised and quickly scaled up into an attack machine. That seems more plausible than someone running an instance on Amazon to conduct attacks.

That would mean that Amazon had two problems – a compromised customer and an attack coming from their premises. thoughts?

Stu: From what folks were reporting, this was more then just one attack machine… My guess would be that the perpetrator:

• Compromised several servers on the EC2 cloud via an ssh brute force attack.
• Compromised one or more corporate EC2 accounts at the control panel level, and spun up a bunch of bot servers.
• Created a corporate account using a stolen identity.
• Just gave Amazon their name and CC and figured they’d plead that they got hacked.

Whatever the method of infiltration, this instance shows that there are giant holes in the way Amazon manages their EC2 server rentals.

Dave: Amazon was very slow to respond or communicate – and the attacks ran for several days – but do you believe Amazon was slow to react in trying to stop the attacks? In other words, do you think Amazon could have stopped these much faster if they were truly serious about this or could it have taken several days to find it isolate it and stop it?

Stu: Calling Amazon’s response to this slow, is like calling Bill Gates financially comfortable… A huge understatement…

As a network operator, I have an abuse address that is published in my whois record for the IP address space I control. When I receive an email to that address, it is my responsibility as a network operator, to investigate, and if found to be factual, stop any abusive traffic from leaving my network. I then should contact the people that complained and make sure that I have resolved the problem to their satisfaction.

Now, we are of course, attempting to contact the customer that is responsible for the hardware that the IP address is on, but our primary goal, is to isolate the inappropriate traffic to only our network.

What I received from Amazon was an email with a link to a form I could fill out that went to the account of the system that was using the IP address, and a statement from them that they could not do anything about the attack, as they did not control the server… This notice did not come in until 24hrs after I reported the attack.

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.

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. This should have been Amazon’s position…

Dave:  This seems like an unprecedented attack in terms of size and speed – but that may be the new reality with cloud infrastructure. How should this incident change (if at all) operating practices?

Stu: Attacks of all kinds have been originating from EC2 since they started to offer the service. 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 a internet connection to use their service.

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 our network.

Dave: You state you contacted the customer… did Amazon provide you contact information?

Stu: Amazon pointed us to a form that we could send a message on their EC2 system to the Amazon client. We received no actual information regarding the Amazon EC2 account.

My closing statement: The SIP protocol is just as vulnerable to attack and compromise as any protocol that uses authentication. Sadly, many VoIP operators use simple passwords to make it easier to configure SIP devices. This will be their undoing… If you have SIP open to the world, then make sure you protect it with strong passwords.

Thank you Dave, for these great questions!

— Stu