[ml] [VoIPSA] Ready or not… here come the IRC-controlled SIP/VoIP attack

quando sono in ufficio e rientro dal pranzo leggo per qualche minuto i 
subject che piu attirano la mia attenzione fra i vari feed a cui sono 
sottoscritto. ho trovato questao una interessante lettura da dopopranzo 
di venerdi pomeriggio. dal blog di VoIPSA.

http://voipsa.org/blog/2007/05/07/ready-or-not-here-come-the-irc-controlled-sipvoip-attack-bots/

*/A story/*: ZZZ Telemarketing (not a real name) is locked in a heated 
fight with their bitter rival, YYY Telemarketing (also not a real name), 
to win a very large lead generation contract with Customer X. Customer X 
has decided to run a test pitting the two companies against each other 
for a week to see who can generate the most leads. The ZZZ CEO has said 
to his staff that it is “do or die” for the company. If they fail to win 
the contract, they will have to shut down - they need to do “whatever it 
takes” to win over YYY. A ZZZ staffer discovers that part of why YYY has 
consistently underbid them is because they are using SIP trunks to 
reduce their PSTN connection costs. But the staffer also discovers that 
YYY is using very cheap voice service providers who run over the public 
Internet with no security.

Discreet inquiries are made in the dark corners of the Internet. A large 
sum of money is exchanged through third-parties. The test begins on 
Monday and both firms are off in their own buildings rapidly calling. 
But at a designated time on Tuesday, a bot-herder somewhere out on the 
Internet connects to an IRC chat room and enters a line of text. Moments 
after the Enter key is pressed, “bots” on tens of thousands of zombie 
PCs wake up and start slamming the SIP servers at YYY and its providers 
with enormous numbers of bogus SIP messages, each of which require 
processing. Effectively all outbound (and inbound) PSTN connections 
grind to a halt. YYY IT staff try desperately to stop the attack but 
don’t have any real knowledge of how to defend against these attacks. 
Because the attacks paralyzed YYY’s SIP server but left their Internet 
connection still usable, their ISP won’t help and says it is a problem 
for their telephony providers. Those providers, of course, are 
preoccupied trying to fight off the the attack themselves. Meanwhile, 
hidden out on the net, the bot-herder watches the attempts and simply 
brings more botnets online as some nodes are successfully shut down or 
blocked.

Late on Wednesday at a designated time, the bot-herder enters the IRC 
room again and enters another command. All bots immediately cease their 
attacks. YYY can now make calls, but in their desperate attempts to 
restore connectivity the YYY IT staff has made such a mess of their 
network that it takes them until extremely late in the evening to return 
full service. Thursday morning YYY is back in full operation, but it’s 
too late to overtake ZZZ’s head start. ZZZ wins the test and the 
contract. (And YYY’s lawyers desperately search for some way to pin this 
on ZZZ.)

Is this just a piece of creative fiction? (or a nightmare?)

Today, probably yes… but last week the first steps toward bringing about 
the reality appeared in the VOIPSEC mailing list 
<http://www.voipsa.org/VOIPSEC> when a group of academic researchers 
announced the availability of a “VoIP bot” 
<http://voipsa.org/pipermail/voipsec_voipsa.org/2007-May/002323.html> 
for testing automated attacks against VoIP systems that use the SIP 
protocol. While the researchers indicated they were making it available 
to aid in the efforts to develop effective tools to /prevent/ attacks, 
the cold, hard reality is that the same tool and code can be used for 
/attacks/ by those out operating botnets 
<http://en.wikipedia.org/wiki/Botnet> for malicious purposes. Deploy it 
on hundreds (or thousands) of zombie computers 
<http://en.wikipedia.org/wiki/Zombie_computer> and an attacker 
potentially has a great way to execute a distributed denial of service 
(DDOS) against a company with, for example, a SIP trunk across the 
public Internet. Thereby potentially shutting down that company’s access 
to the PSTN. No inbound or outbound phone calls for the duration of the 
attack.

Welcome to the era of VoIP botnets.

With all the VoIP security tools 
<http://www.voipsa.org/Resources/tools.php>out there, we knew it was 
only a matter of time before this occurred, but now the proverbial genie 
has been let out of the bottle. (or is it “bot-tle”?)

*REALITY CHECK #1 *- /Now, before anyone cues the song “It’s the End of 
the World as We Know It”/ and starts to rip out their VoIP deployment, 
let’s be clear that this bot only affects systems using the /SIP 
protocol/. Given that the vast majority of /corporate/enterprise/ VoIP 
deployments today occur with /proprietary protocols/ (and this is true 
of all the main VoIP vendors), this news has little immediate impact on 
that segment of the market. However, most all enterprise vendors are now 
supporting SIP phones and/or SIP trunks - and so this definitely will be 
a concern in the future. In the PSTN line replacement market, though, 
there certainly are a good number of service providers offering SIP 
connections/trunks. If they are doing that across the public Internet 
(versus their own network where they can better control traffic) then 
this is definitely something of concern to them.

*REALITY CHECK #2* - Let’s also be clear that there is no massive botnet 
out there right now out there waiting to kill all your SIP trunks or SIP 
sets (that we know of). What was released was a “proof-of-concept” that 
showed in a very basic way what could be done. The real threat is that 
attackers could modify the code, improve/tweak it, and start to deploy 
it out there in larger botnets. If we don’t look at ways to address the 
issues raised here, it /will/, though, become a more serious issue.

With those statements out of the way, let’s look at what this 
proof-of-concept bot does. First, as shown on the README page 
<http://www.loria.fr/%7Enassar/readme.html>, you connect to an IRC 
server and create a chat room/channel. You then install the software 
onto a PC and run it (it’s a Java JAR file), providing the name of the 
IRC server and channel to which you are connected. You then simply start 
executing SIP attack commands. If you start up several instances of the 
bot connecting to the same IRC channel, you can issue commands that are 
implemented by all your bots.

Simple. Easy. (Scared yet?)

So what does it do? Well, here are the commands:

   * *spit* - sends an audio file to a specified SIP address
   * *dos* - sends successive SIP invites to a SIP address for a
     specified period of time
   * *scan* - takes a list of possible user names and sends a SIP
     INVITE for each one (trying to determine what SIP usernames are used)
   * *crack* - if you know SIP user names (potentially from ’scan’) you
     can try to crack the password
   * *register* - if you know a SIP username and password, the bot will
     send a SIP REGISTER packet

A limited command set today, but the researchers indicate they will be 
refining it - and the source code is now out there for anyone to obtain 
and modify. And for something like a DOS (or DDOS) this could be 
effective. I only installed one bot on my test network, but I did see 
that it did generate a large number of packets against a SIP server I 
have running here. You could see the power of multiplying that.

So with the genie out of the bottle, what do we as VoIP security 
professionals do about it?

I’ll offer several suggestions (and certainly welcome more as comments 
to the post):

  1. *Play with this proof-of-concept bot* - In order to defend against
     something, we need to understand it. Grab this one now and start
     understanding how it works…. before larger botnets targeting VoIP
     do actually get out there.
  2. *Understand what SIP security options you have* - If you are using
     SIP in your VoIP infrastructure (either for phones or for
     trunking) understand what options you have for securing the SIP
     signaling. Can you encrypt the SIP signaling? Can you only accept
     connections from specific endpoints? Talk to you vendors and
     service providers. With either of those options you would greatly
     reduce (if not eliminate) the impact of a botnet attack.
  3. *Ask your SIP service provider if they support secure SIP
     connections (and if not, when they will)* - As we have ranted here
     and on the Blue Box podcast
     <http://www.blueboxpodcast.com/2006/10/blue_box_42_the.html>,
     service providers offering SIP connections over the public
     Internet without securing those connections are, in my opinion,
     playing a dangerous game and are most likely the first to be
     affected by something like this.
  4. *Test, test and re-test your SIP systems, phones and other
     endpoints* - The VoIP security tools
     <http://www.voipsa.org/Resources/tools.php>are out there to test
     your implementation. What are you waiting for? Test anything with
     a SIP connection (obviously your /own/ devices or with the
     permission of the owner). Report any issues to the vendors (and if
     the vendor doesn’t respond, contact us here at VOIPSA and we’ll
     see if we can put you in touch with someone).
  5. *Participate in IETF efforts to better secure SIP *- As I wrote
     last week
     <http://voipsa.org/blog/2007/05/03/sipit-20-shows-the-very-clear-need-for-sip-security-interoperability/>,
     there are definitely areas of SIP security that need to be
     improved within the IETF <http://www.ietf.org/>. We need to get
     better support all around for TLS-encrypted SIP (aka “SIPS”). We
     need to solve the SRTP key exchange problem. We need to make get
     NAT traversal mechanisms like ICE fully standardized. We need
     vendors and service providers to implement existing RFCs… and we
     need to reach closure on other issues. Join the SIP, SIPPING and
     RTPSEC mailing lists. Comment on existing Internet-Drafts or
     contribute new ones.
  6. *Understand “botnets” and what network defenses you can use* -
     Botnets are not new. There is a great amount of info out there
     already (some pointers here
     <http://en.wikipedia.org/wiki/Botnet#External_links>, here
     <http://http://www.shadowserver.org/wiki/pmwiki.php?n=Information.Botnets>,
     here <http://www.eweek.com/article2/0,1895,2029720,00.asp>and here
     <http://en.wikipedia.org/wiki/Zombie_computer>). Talk to others in
     the field and see what defenses you can use within your existing
     network infrastructure.
  7. *Ensure you aren’t a /source/ of zombie computers* - It goes
     without saying that just in general you should already be
     employing mechanisms to ensure that spyware/malware
     <http://en.wikipedia.org/wiki/Malware>isn’t being installed on
     your computers. Anti-virus is part of that, as are things like
     ensuring that all computers are up-to-date on patches.
  8. *Don’t panic* - As I said at the beginning, we are not aware of
     any massive botnets out there targeting SIP (at least today… check
     back tomorrow). This is just yet one more thing to add to our list
     of many other things to be considered as we look at how to secure
     VoIP.

Going back to my story at the top, YYY might not have had the problems 
if their SIP server were set to reject all packets that did not 
originate from their service providers… or if they had required 
encryption with mutual authentication so that spoofed IP addresses 
couldn’t affect things… or if…

The reality is that there are solutions out there today that will go far 
in blunting the effect of these type of attacks. We just need to be sure 
that we are /using/ and /improving/ those solutions… if we don’t… well… 
then we /will/ be cueing up that song!

Other comments or suggestions?