Whats brewing on the SIPVicious front

Been quite for a while, but that does not mean that I've been resting. Instead I've been looking into fingerprinting SIP devices and not relying on the User-agent header to identify the a SIP network element's name.

This means that SIPVicious tools will soon be able to guess the name of the device. What's important is that the tools will be able to maintain do this without sacrificing speed and efficiency. Expect more news on this.

Other than that, I'm looking at how to integrate the dns stuff with svmap - things like the SRV records and ENUM.

And.. last but not least.. I've been working on an article for Hakin9 magazine which explains a lot of behind the scenes when it comes to how SIPVicious tool suite works.

introduction to svmap

Svmap is a network scanner for SIP. Similar to nmap - it will scan for devices on ports specified by passing the right command line options. Once svmap finds a device that supports SIP, it will extract information from the response and identify the type of device. Anyone running this tool will typically end up with a list of IP addresses of SIP devices and the names for those devices.

A penetration tester or security auditor will probably find this tool particularly useful especially during reconnaissance. With the IP address, device name and possibly version at hand, he or she can then target security weaknesses specific to that device. A security administrator or security analyst can also make use of svmap to list different active SIP user-agents on the network. Based on this information, the security administrator then has the ability to identify rogue and vulnerable devices which can cause a security concern.

Svmap is able to scan for SIP devices much faster than generic UDP port scanners. Typical port scanners such as nmap, scan UDP ports by sending a packet to each port and expecting an ICMP packet which indicates that the port is closed. If no ICMP error is received within a reasonable time, the port scanner assumes that the port is either open or else filtered. While this method has worked for years, it can never be considered efficient or neat, (at least) because of two reasons:

• The majority of UDP ports are closed - therefore having to wait for each ICMP error to confirm that the port is closed is not a good idea
• Nowadays a lot of devices are behind firewalls or NAT and will never reply with an ICMP error

Svmap works by sending a UDP packet containing a SIP request to a range of specified IP addresses, and listing those that send back a valid SIP response. Since UDP is a connectionless protocol, this method can be relatively fast. For example, during testing we were able to identify around 200 SIP devices on one particular network, out of a scan of IP addresses in less than 3 minutes. On the other hand when we scanned the same network with nmap version 4.20 (default options for sU scan on port 5060), it took longer than 20 minutes at which point we stopped the scan.

For examples on how to use svmap check out the wiki.
Download the whole SIPVicious tool suite from the project page.

SIPVicious version 0.2.1 released

Go get it from the usual place.

This is mostly a bug fix release but we still managed to squeeze in some minor features:

• Session state is now saved

• svmap supports sending INVITE to particular extensions

If you're on a system with subversion installed, you can simply run "svn update" to receive the latest version. Check out the Changelog to see what changed.

SIPVicious 0.2.1 public beta

Just wanted to let you know that v0.2.1 is public beta (meaning that it will be released soon). Go for it (and submit a bug report if you get any bad feelings) ;-)

Changelog:
v0.2.1 (maintenance)
General:

• Feature: updated the report function to include more information about the system. Python version and operating system is now included in the bug report. option now supports optional feedback.
• Feature: Store information about the state of a session. Sessions can be complete or incomplete, so that you can resume incomplete sessions but not complete ones.
• Bug fix: Added a check to make sure that the python version is supported. Anything less than version 2.4 is not supported
• Bug fix: IP in the SIP msg was being set to localhost when not explicitly set. This is not correct behavior and was fixed. As a result of this behavior some devices, such as Grandstream BT100 were not being detected. Thanks to robert&someone from bulgaria for reporting this
• Bug fix: fixed a bug in the database which was reported anonymously via the --reportback / -R option.Thanks whoever reported that. Bug concerns the dbm which does not support certain methods supported other database modules referenced by anydbm. Reproduced on FreeBSD. Thanks to Anthony Williams for help identifying this
• Bug fix: Ranges of extensions in svwar could not take long numeric extensions (xrange does not support long / large numbers). Thanks to Joern for reporting this
• Bug fix: svwar was truncating extension names containing certain characters. Fixed.
• Bug fix: when binding to a specific interface, the IP within the SIP message could be incorrect (when there are multiple interfaces). This has been fixed.
• Cosmetic: Certain PBXs reply with "603 Declined" when svwar finds that the extension does not exist. This creates extra noise. It is now being suppressed.

That's all folks!