Sunday (sundayddr) SIP scanning worm. When printers turn bad..

It's time for another quick analysis of a prevalent SIP scanner that has been active for the last 4-5 months. It is particularly interesting because it is spreading like a worm, seems to use multiple scanning techniques (ssh and SIP) and acts like a botnet.

This scanner likely responsible for the uptick in port 5060 (SIP) scanning noted on this SANS Internet Storm Center diary entry. We noticed this scanner first hit our honeypots on July 8, at the same time SANS posted the note about significant increase in UDP port 5060 (SIP) scanning.

First of all, here is a redacted version of the contents of a typical scan:

Source: 124.89.88.18:5060
Datetime: 2010-07-09 hh.mm.ss
Message:
OPTIONS sip:100@honeypot_IP_removed SIP/2.0
Via: SIP/2.0/UDP 192.168.1.9:5060;branch=zqwehwebK-0523432245;rport
Content-Length: 0
From: "sipsscuser"<sip:[email protected]>; tag=removed
Accept: application/sdp
User-Agent: sundayddr
To: "sipssc"<sip:[email protected]>
Contact: sip:[email protected]:5060
CSeq: 1 OPTIONS
Call-ID: removed...
Max-Forwards: 70

Note the order and layout of the SIP headers is very similar to that of the sipvicious tool, which I described in an earlier blog entry. This suggests that a modified version of sipvicious is being used. It is trivial to modify sipvicious in this way, just by changing the python script.
- "sundayddr" replaces the usual "friendly-scanner" in the User-Agent header
- "sipsscuser" replaces the usual "sipvicious" in the From header
- The source extension is now set to [email protected], changed from [email protected] in original sipvicious tool.

Up till today (this analysis and graphics were done in early in August) we now detected these scans coming from hundreds more IP addresses. This indicates we are dealing with a botnet, not the opportunistic scans from single IP's that we more often see. Of course it is technically possible that UDP spoofing could be the cause of these multiple IP's, but it is reasonable to rule this out in this case, as it would not make any sense to spoof the UDP messages because the attacker would not get a response to the SIP scan.


Note there are a lot of scans coming from IP addresses in China. I feel it is important to point out here that this is *not* attribution of anyone in China necessarily, rather it just means that seemingly a lot of these Chinese IP addresses may be compromised and are taking part in this scanning activity.
The geographic heatmap of IP's that have been conducting scanning against out honeypots, also shows a large amount of activity from Chinese IP space. We have results from 4 honeypots located in vastly separate countries, including Australia. There is nothing special about the IP's of the honeypots, thus the extent of scanning on the wider internet is likely be vastly more than the 4 honeypots have recorded.


Note the prevalence of Unix-like machines. Apparently there are even a couple of compromised Printers that are scanning. Makes me wonder when we will see our first Internet enabled fridge, coffee machine, or garden watering system attacking our sensors (yes its entirely likely...).


Note that the vast majority are running ssh on port 22. Also note the filtered ports, and port 4444 (Metasploit?). There are a lot of explanations for ports being open,filtered and closed, including port forward/NAT, load balancing, however it is interesting to note the number of ssh servers involved in the sample set.

Although we haven't located the kit responsible for this, here is a theory put forward by a security colleague, and which is fairly strongly supported by our results: The scanning network most likely consists of Unix-like systems that offer ssh login, and that have weak passwords that can easily be brute forced, and the sequence of events may be as follows.

  1. Server 1 scans a range of IP's and looks for ssh servers
  2. It finds that Server 2 is running ssh, and attempts to brute force logins. It succeeds and thus compromises Server 2
  3. While logged in to Server 2 via ssh , Server 1 runs a simple shell script on Server 2.
  4. The shell script pulls down a "kit" from some location onto Server 2. The kit contains the modified sipvicious scanner, and an ssh brute force scanner from a remote site. It most likely uses common tools that are pre-installed on many ssh servers, for example 'wget'. This kit is that unpacked and run on Server 2.
  5. When run, the script causes Server 2 to scan a set of networks for SIP servers, some of which include our SIP honeypots.
  6. Server 2 then scans a set of networks for ssh servers, finds and compromises Server 3, and the whole cycle repeats in an automated, worm-like fashion.

This scanner is still very active today. An IP from China scanned one of our Australian honeypots as I was writing this, on 27 October 2010.

Using a self propogating/botnet-like infrastructure is just another evolution of malicious SIP scanning, and it is evident that more and more development is being put into systems that can automate the discovery of vulnerable SIP servers, for subsequent nefarious use.