Editor’s note: Imported from my old personal blog @ TC with minor edits to improve readability where necessary.
In Deep Darknet Inspection - Part 1 we tried to unravel as much as we could out of a pair of TCP SYN packets. The result was a picture of what appeared to be a Conficker-infected host. By looking at IP and TCP header detail as well as packet timing intervals we were able to put forth a pretty reasonable profile as to the origin of those packets. Now, in part two, we consider a new pattern of packets from that darknet session - UDP packets arriving on destination port 5060, a well-known port assigned to the session initiation protocol (SIP). We’ll hone in on 17 such packets received at a single destination IPv4 address over the course of 36 hours. All of these were SIP OPTIONS request messages with very similar content. The SIP payload of two such messages, with the original destination IP address in the “OPTIONS sip” field obfuscated to 192.0.2.1, are shown below:
SIP payload 1:
OPTIONS sip:100@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-1047900479;rport
Content-Length: 0
From: "sipvicious"<sip:100@1.1.1.1> tag=34353131313634613133633401353835363538393133
Accept: application/sdp
User-Agent: friendly-scanner
To: "sipvicious"<sip:100@1.1.1.1>
Contact: sip:100@127.0.0.1:5060
CSeq: 1 OPTIONS
Call-ID: 965192181434457134540520
Max-Forwards: 70
SIP payload 2:
OPTIONS sip:100@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.9:5060;branch=z9hG4bK-17038962;rport
Content-Length: 0
From: "sipsscuser"<sip:100@192.168.1.9> tag=77194458456158489721772408023096992174807017852
Accept: application/sdp
User-Agent: sundayddr
To: "sipscc"<sip:100@192.168.1.9>
Contact: sip:100@192.168.1.9:5060
CSeq: 1 OPTIONS
Call-ID: 124296019799750175018545983
Max-Forwards: 70
The SANS ISC 5060 port report and Team Cymru’s Top 10 UDP ports graph both show greater than average activity for UDP port 5060. A veritable source of public information on emerging scanning trends can be found by watching the Internet Storm Center Diary hosted by SANS. In July, the Handler on Duty posted an entry entitled Targeting VoIP: Increase in SIP Connection on UDP port 5060 and you could subsequently find more information about the nature of these scans, which would undoubtedly lead you to the SIPVicious toolkit.
SIPVicious is widely used for SIP scanning today. Earlier this year the South West Anarchy Team (SWATeam) published swat0013.txt, a text describing how to use SIPVicious to locate open VoIP PBX systems that can be later tested for open extensions as a means to make free phone calls. Old school phreaks meet the new school phreaks.
The SIP content shown above might not seem too interesting, especially
when an automated tool like SIPVicious is being used, but it might suit
the pedantic to know more. In this case it helps to have some
familiarity with the SIPVicious code and in particular the svmap.py
script. Some of the SIPVicious generated fields are based on local host
system properties. These values include a local source address and
source port number in the Via and Contact fields. SIPVicious, as of
this writing, attempts to discover a local address, using a
gethostbyname(gethostname()) call, for the Via and Contact fields. It
also uses a hard coded 1.1.1.1 IP address in other places.
If the system calls used to determine the local IP address fail, 127.0.0.1 is used instead. This is noteworthy because we’ve seen other SIP scans from multiple sources that always use an IP address of 192.168.1.9 in all fields except the OPTIONS field. In addition, unique identifiers in the From, User-Agent and To fields have been altered from their original SIPVicious counterparts. See the SIP payload 2 in the listing above for an example. It is unlikely those scanning hosts all happen to be behind a NAT using the same 192.168.1.9 address so we can infer that there is some modified version of svmap.py in the wild. This is a reasonable assumption since other parts of the SIP payload in those scans correspond perfectly to those fields generated by the SIPVicious code. It would be highly improbable for someone to come up with the same patterns independently.
The source ports shown above are also 5060, which, after examining the SIPVicious code, suggests that there are no locally running SIP listeners on the local sending system’s UDP port 5060. However, we sometimes see other source ports used in these scans, usually some marginal value greater than 5060. This suggests a couple of scenarios. One, the source host already has a SIP listener in use on port 5060, maybe it is the same end host where both the scanning and subsequent follow up call attempts are being run from. Two, by considering the distance the source port value is from 5060, we can infer the approximate number of concurrent SIPVicious processes running on the end host at the time we received our scan packet. SIPVicious will increment, by one, the source port value until it finds an available local socket.
Believe it or not, there is more to the SIP scans if we consider the IP identification fields, not shown above. We talked about the IP id field in deep darknet inspection part one and implied that it often acts as a simple 16-bit packet counter. Of course, many systems do different things with different protocol fields, including the IP id field, as we are about to discover.
Out of the 17 SIP scans from this darknet session, all had a unique source IP address, but seven had an IP id field value of zero. Assuming all 17 packets were generated by independent origin hosts and any IP id value is roughly equally probable, the chance of that occurring naturally are astronomical. It turns out that Linux always sets the IP id field value to zero for UDP messages when the don’t fragment bit in the IP header is also set, which is typically the case here. CVE-2002-0510 has been assigned to this behavior, but it was not considered an issue worth changing the IP stack implementation for. What about those 10 scans that did not have an IP id field value of zero? It is likely many of those systems are not Linux. Since SIPVicious is written in Python, a likely platform in those cases are a BSD-based system. It is also possible that source hosts responsible for those 10 scans were behind some sort of middle box, such as a NAT, that rewrote the IP id field to a seemingly random value. DNS PTR queries, passive DNS data, OS fingerprinting techniques, examining the IP TTL field, checking if the DF bit is set and other tricks might help characterize each of those further, but we’ll leave those ideas as an exercise for the reader to ponder.
Here again, with a deeper look into darknet packets we were able to uncover not only the nature of the packets seen at a darknet, but we were also able to better profile systems sourcing the traffic. In this case we were lucky to have access to the source code used to generate these packets. Not surprisingly, we won’t always be so fortunate as we will soon see in part three.