SIP Attacks From Amazon EC2 Going Unaddressed
mjgraves writes "Over the past week a number of IP-PBX systems have been suffering SIP attacks from hosts in the Amazon EC2 cloud. At least a dozen known attacks have been reported to Amazon, which has been surprisingly quiet about the matter. The issue has been well documented by one of the attack victims on his blog. The matter was also discussed on the April 16th issue of the VoIP Users Conference (podcast available at the link; EC2 segment begins around 3:30). Amazon appears to have gone silent on the matter even as the attacks are ongoing. This is completely irresponsible behavior from a such a hosting company, which should be acting to take down the attacker in their midst."
RTFA.
Haida Manga
The complainant in the article actually e-mailed and called Amazon several times, and got several less-than-satisfactory responses. Evidently Amazon's solution is "mediation" - you're supposed to talk to the hackers and work something out! They have zero interest in actually shutting them down.
DATABASE WOW WOW
I've been reporting an IM spammer for several weeks now an IM spammer hosting sites with a place called Flying Croc. I've even complained to their upstream provider, but to no avail from either. Both of these have AUPs specifically prohibiting spamming from or spam being used to advertise sites on their network, but it seems the AUPs are only really intended to let the host disconnect someone they don't like, not actually to prevent their customers from launching an attack or spamming campaign. Or at least, the webcam sites being spammed for still trace right back to the same networks as they did.
Maybe there needs to be some mandatory service level from companies above a certain size (a response from a human within X days, etc.). Service seems to be getting worse and worse across the board. And maybe a requirement that if said company says something, it damn well better back it up when called upon to.
To fight the war on terror, stop being afraid.
You would think it would be pretty easily for Amazon to find and shut down the attackers... why haven't they done so already?
Perhaps because the UDP source addresses are spoofed, and the goal of the attack is to trick AWS into shutting down legitimate paying customers' businesses?
Since this involved illegal computer access from an information provider (don't think Amazon's been classified as a telecom provider. yet.), why not involve the consumer fraud devision of the Washington State Attorney General. If a bunch of AG people and sheriffs descend on Amazon's offices with search warrants for "Any and all computers, disks, hardware, etc.", I think Amazon will take notice pretty quickly.
There's an awful lot of spam and other abuse coming out of EC2. I'm not surprised to hear that it's being used as a source of SIP attacks as well. Amazon is quite irresponsible about handling abuse. As long as it isn't harming their systems, they wait until someone reports abuse, and then they terminate only the EC2 instance from which the attack originated. They make zero effort to thwart future attacks or prevent more abuse.
Amazon is gaining a reputation as a house of ill repute, and they deserve it.
Tired of FB/Google censorship? Visit UNCENSORED!
SIP = Session Initiation Protocol, it's the protocol that sets up and tears down the session on a VOIP call. After the initial setup, VoIP uses RTP, or Real-time Transmission Protocol to transfer the call data packets, while SIP manages the connection itself (adding callers, changing addresses, adding video, etc).
SIP is application layer protocol that sits on top of a transport protocol like TCP or UDP, which sits on top of the IP network layer. If not encrypted (it often isn't), it is vulnerable to everything TCP is, including DOS attacks, man in the middle attacks, packet sniffing, and various hardware related attacks like buffer overflows and such. Even encrypted it is still vulnerable to the hardware related attacks and DOS attacks.
What you can do with these attacks is the same as what you'd do with TCP attacks: eavesdropping, call re-routing, disconnecting calls, SIP agent impersonation to place new calls, etc.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
An IP-PBX system is a PBX system on an IP network. ;)
A PBX is a call center through which all phone calls for a specific area are routed - like a building or a telco's service area. It stands for Private Branch Exchange.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
They have zero interest in actually shutting them down.
Maybe if you flood-ping the offending IP from your attacked PBX their automated IDS will blackhole your IP.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I don't think so. One way to stop the attacks is to use pf/iptables to forward the offending REGISTERs to a bot that simply sends back a bogus "200 OK" response. As soon as the attacker thinks he's found an opening, the attack stops.
This is basically like an ISP arguing they are not responsible for spam sent by their downstream customers they provide internet connectivity to.
The IP addresses belong to the ISP, so they are ultimately responsible for handling any report of abuse in terms of network traffic from those IPs.
If the ISP does nothing, the IPs will eventually get blacklisted, and most blacklists will make the blacklist entry larger and larger until the ISP responds... e.g. start with blacklisting just that IP, then if it continues, blacklist the entire /24, then if it continues, blacklist that entire RIR registered IP block.
As last step... blacklist the entire AS number.
Amazon EC2 is in the same situation here. If they don't respond to serious abuse complaints like this, transit providers are going to start blackholing EC2 IPs at their border.
Eventually, this could make EC2 useless....
Bezos is a smart businessman, and as such most of his properties are separate corporations that are friends of Amazon, but maintain the ability to go bankrupt if they go wrong without bankrupting Amazon.com. Such a warrant might get the attention of EC2... but there's no way it'd stretch all the way to Amazon.com unless there was some proof of a shared resource being involved.
At least one attack came from Amazon. I reported it, and Amazon has confirmed that it was their customer. The packets weren't spoofed, no attempt was made to hide their origin.
Finally! A year of moderation! Ready for 2019?