July 11, 2010
Posted by on
The lastest week there has been a tremendous SIP scanning from IPs all over the world latest week. The scannings are coming from a lot of IPs but the same signature, so it is probably only one person/firm behind this.
The scanning is this:
OPTIONS sip:100@X.X.X.X SIP/2.0
Via: SIP/2.0/UDP 192.168.1.9:5060;branch=
From: “sipsscuser”<sip:firstname.lastname@example.org>; tag=01669016334862887007103185718785156498385702949
CSeq: 1 OPTIONS
The lay-out of the OPTIONS messages is the same as in SIPVicious
scannings, so the author has taken this python code and just changed the User-Agent.
And this is just the beginning….
April 14, 2010
Posted by on
There have never been so many SIP scannings in so short time for all my VoIP honeypots.They have tried all types, INVITES, REGISTER, SUBSCRIBES and OPTIONS. A short list of some of the attackes latest 48 hours. Normally just doing a couple hundred extensions and passwords, some of these IPs trying up to 10 000 different extensions/passwords.
IP addresses [User-agent] Provider
220.127.116.11 [First SIPVicious, then SIPPER for PhonerLite]
18.104.22.168 [SIPVicious] Amazone EC2
So keep your systems ready for the flood to come! This is just the start.
February 4, 2010
Posted by on
RIPE said a long time ago that IPv4 is running out of addresses. Now they are also allocating the 1.x.x.x network for production traffic. But this is a bit problematic, since people have been using IP addresses like 22.214.171.124 and 126.96.36.199 as examples in scripts, tools and manuals. People who don’t know any better, they try contact these. When they routes to these networks where alive, a LOT of traffic started coming in.
What made it interesting for Sandro in EnableSecurity was that most traffic was UDP (60 %) and almost 90 % to IP addresss 188.8.131.52. This is a text from RIPEs article about it:
We found that almost 60% of the UDP packets are sent towards the IP address 184.108.40.206 on port 15206 which makes up the largest amount of packets seen by our RRC. Most of these packets start their data section with 0x80, continue with seemingly random data and are padded to 172 bytes with an (again seemingly random) 2 byte value.
This can actually be RTP traffic (VoIP audio traffic) generated from hosts that are vulnerable to SIP INVITE attacks, as Sandro points out in his comment and on his blog.
This is also alarming! This scanning with default RTP audio to IP 220.127.116.11 and port 15206 seems to be doing REALLY well on the Internet. There are a lot of VoIP unsecure platforms accepting and responding to ANY SIP INVITE they get. The software doing it is NOT SIPVicious, but another. It normally uses port 3058 to send the SIP INVITES from. If anybody knows something about this software, please contact me.
I have had a slide in my VoIP presentations about this scenario. If you do a SIP INVITE sweep, you should NOT have a valid IP address for the audio. Every successful INVITE would then generate at least 20 seconds of 0,1Mbit per second stream (g711 audio) to your IP address. Your SIP INVITE sweep with your IP as receiver for RTP traffic will not take long before it backfires on you and you get a DDoS on yourself (well earned though IMHO).
So what is next?
I would love to have a honeypot or get access to the traffic going to port 18.104.22.168. All hosts that would send RTP traffic to this address, should be contacted and asked to secure their servers!
Status now from RIPE:
Since the traffic patterns seemed to be stable we decided to withdraw the announcement of 22.214.171.124/24 and 126.96.36.199/24 on 2 February 2010.
January 21, 2010
Posted by on
The Exploit Database reports that FreePBX version 2.5 and 2.6 is vulnerable to Cross-Site Scripting (XSS).
An affected user may unintentionally execute scripts or actions written by
an attacker. In addition, an attacker may obtain authorization cookies
that would allow him to gain unauthorized access to the application.
This is just the beginning of vulnerabilities in different VoIP applications. Up until now, there has not been the need of vulnerabilities to exploit VoIP services. Too many IP PBXes has been configured insecure, and easy to abuse.
The next wave will see more exploits beeing used towards IP PBXes. They are often based on same protocols and applications as any other server….
January 13, 2010
Posted by on
Finally, an open-source solution to filter away those SIPVicious and other SIP attacks. SecSIP is Stateful SIP Protection Systemwhich analyses the SIP signalling on the fly and decides wether to forward it or not. It can throttle number of SIP messages (useful since one of mye VoIP honeypots was hit with 16 000 INVITES within 8 minutes..).
Great work and I’m looking forward to test it out live!
January 11, 2010
Posted by on
If you have an IP PBX on a public IP, and you are not quite sure if it is secure enough, you should get to it now!
Scannings on port 5060 has exploded the lastest days. Previously it was a couple hits in the week, now it’s up to a 100 a day. This means that if your VoIP setup is not 100% secure, others will find it and abuse it!And you will get the telephony bill!
Get to it, secure your VoIP communication platform right now!
Check the following:
- All users has strong passwords
- Access Lists are updated and preferably both ways (both incoming and outgoing traffic on the server)
- No unused services are enabled
- Latest patches are on the server OS
- Latest patches are on the application
- Latest SECURE firmware on the hardware endpoints (phones etc.)
- Other services on the plattform like Web servers, TFTP, FTP, SSH are locked down or VERY strong passwords
- Encrypt the traffic from the user and into the server (to make eavesdropping harder)
- Make the PCs accessing your platform secure. Any keycatchers or sniffers installed here?
- Forgotten someting? Please comment
December 28, 2009
Posted by on
Been picking up more and more hits in the VoIP honeypots lately. What puzzles me, is that several of those originate from different IPs but same port number. IANA assigned port 3058 to the following:
videobeans 3058/tcp videobeans
videobeans 3058/udp videobeans
IPs that has hit one or more of our honeypots the latest days:
From port 3058
Notice the two consecutive IPs, 188.8.131.52 and .53.
But why port 3058… the reason is probably simple, but for now I’m guessing on the same software running on PCs with a public IP.
November 9, 2009
Posted by on
SIP is now mostly run over UDP. This is scalable but unsecure. Microsoft uses only TCP and encrypted TLS. But TLS has its own flaws as shown by this webpage.
There are three general attacks against HTTPS discussed here, each with slightly different characteristics, all of which yield the same result: the attacker is able to execute an HTTP transaction of his choice, authenticated by a legitimate user (the victim of the MITM attack). Some attacks result in the attacker-supplied request generating a response document which is then presented to the client without any certificate warning or other indication to the user. Other techniques allow the attacker to forward or re-purpose client certificate authentication credentials.
They use HTTPS, but it could most likely also be done in SIP as well. When everybody is using SIP TLS, there will still be security issues….
More info in here.
September 4, 2009
Posted by on
The RFC draft-ietf-speermint-voipthreats-01 was release in July and summarizes several of the threats towards VoIP.
SIP Request Spoofing
Most SIP request spoofing require first a SIP message eavesdropping
but some of the them could be also performed by guessing or
exploiting broken implementations. Threats in this category are:
session teardown - the attacker uses CANCEL/BYE messages in order
to tear down an existing call at SIP layer, it is needed that the
attacker replicates the proper SIP header for the hijacking to be
successful (To, From, Call-ID, CSeq);
Billing fraud - the attacker alters an INVITE request to bill a
call to a victim UE and avoid paying for the phone call.
user ID spoofing - SSPs are responsible for asserting the
legitimacy of user ID; if an SSP fails to achieve the level of
identity assertion that the federation it belongs expects, it may
create an entry point for attackers to conduct user ID spoofing
Unwanted requests - the attacker sends requests to interfere with
regular operation, i.e. sends a REGISTER request to hijack calls.
The SPEERMINT architecture as defined in [refs.speermintarch] does
not require registrations between the signaling functions (SF) of
the connected SSPs. Superfluous requests like REGISTERs should be
There is also a part of how to spoof messages:
SIP Reply Spoofing
Threats in this category are:
Forged 200 Response - the attacker sends a forged CANCEL request
to terminate a call in progress tricking the terminating UE to
believe that the originating UE actually sent it, and successfully
hijacks a call sending a forged 200 OK message to the originating
UE communicating the address of the rogue UE under the attacker's
Forged 302 Response - the attacker sends a forged "302 Moved
Temporarily" reply instead of a 200 OK, this enables the attack to
hijack the call and to redirect it to any destination UE of his
Forged 404 Response - the attacker sends a forged "404 Not Found"
reply instead of a 200 OK, this enables the attack to disrupt the
The RFC has a good overview how to protect yourself against these security issues in the end and elaborates on each of them what to do.
Here is a smaller part of it:
4.13. Encyrption and Integrity Protection of Signalling Messages
Encryption of signalling messages can be achieved with TLS or IPSec.
Similar to strong identity assertion, a PKI infrastructure is assumed
to be in place for TLS (or IPSec) deployment so that SSPs can obtain
and trust the keys necessary to decrypt messages and verify
signatures sent by other SSPs.
4.14. Encyrption and Integrity Protection of Media Stream
The Secure Real-time Transport Protocol (SRTP) [RFC3711] adds
security features to plain RTP by mainly providing encryption using
AES to prevent eavesdropping. It also uses HMAC-SHA1 and index
keeping to enable message authentication/integrity and replay
protection required to prevent media hijack attacks. Secure RTCP
(SRTCP) provides the same security-related features to RTCP as SRTP
does for RTP. SRTCP is described in [RFC3711] as optional. In order
to prevent media session teardown, it is recommended to turn this
A MUST read and “are we covered” for all VoIP Service Providers! Good luck!
March 26, 2009
Posted by on
If I know the IP address of your SIP User-Agent and your extension, I can get your password. Not true? Here is how Sandro and I did it! Sandro Gauci also has a tool (voippack for Canvas) which automates the whole process, you can watch the video here!
The fault is that a User-Agent actually answers on an authorization request, even though there is no reason for it. We first send an INVITE, the user-agent rings and the user picks up the phone. When the user hangs-up, we reply the BYE message with an authorization request, which the User-Agent normally answers with a SIP Digest (with the encrypted password). We brute force this digest.
The master plan:
- Check up on the Internet which ISPs are delivering VoIP. Check RIPE for their IP ranges. Scan them for SIP devices.
- Get the extensions they are using (or their ranges of usernames (e.g phone numbers, then do brute force on these ranges on each IP)
- Send an INVITE to the correct extension and the phone will ring. When the user hangs-up, we have the password.
We make the phone send a PROXY AUTHENTICATION when the SIP UserAgent sends the BYE message. We answer with “407 Proxy authorization required” and then the SIP UserAgent actually answers this with the password in a MD5 hash.
- The SIP stack is not connected to the IP Stack. Why is the SIP User Agent answering on SIP messages from other IPS than the SIP Registrar it is connected to? There should be automatically a rule saying “all SIP messages from other servers than what I’ve registered to = drop them!”
- Why does the User Agent blindly answer a challenge on the BYE message. Just send it a “407” and the SIP UA answers with the password…
Units tested (and we managed to get the password)
The units that will be tested further:
- Thompson ST2030
How to protect yourself (for users)
- Make sure your VoIP provider has credit limits! You don’t want to get a huge phone bill!
- Report any unusual phone calls or strange behavior!
How to protect yourself (for VoIP providers)
- Protect your SIP user-agents! This is hard with the Fritz units
which is normally used as a router
- Have very long SIP passwords and use all characters that is possible! (#¤%” and others)
- Change the SIP password regularly
- Run VoIP honeypots to detect scans in your area
How serious do you think this is? Write your comments now!