SIP version detection script

It's always nice to make a first impression as the "Teletubby that forgets the attachment" ... Well here it is :)

Patrik Karlsson
http://www.cqure.net

Matt Selsky

2009-11-23 05:17:35 UTC

Post by Patrik Karlsson
I just finished my first nmap script with some great help from Ron Bowes.
Like the e-mail subject states it does version detection for the SIP protocol.
I've done some basic testing and it looks as if it does what it't intended to.
PORT STATE SERVICE VERSION
5060/udp open|filtered sip Asterisk PBX
PORT STATE SERVICE VERSION
5060/udp open|filtered sip 3CXPhoneSystem 8.0.9844.0
Bug reports or comments and suggestions on things that could be done better/differently are most welcome.

Any reason not to run this script on 5060/tcp as well?

--
Matt

Patrik Karlsson

2009-11-23 11:49:34 UTC

Any reason not to run this script on 5060/tcp as well?
--
Matt

It probably should, and maybe even 5061/tcp (SIP over TLS)?! However, as I started fixing the script I noticed I got some strange answers back, like the version being written twice. I then ran tcpdump and found that Nmap is already probing 5060/tcp. Greping for a pattern in this packet revealed:

[***@localhost ~]# grep -r "***@nm" /usr/share/nmap/
/usr/share/nmap/nmap-service-probes:Probe TCP SIPOptions q|OPTIONS sip:nm SIP/2.0\r\nVia: SIP/2.0/TCP nm;branch=foo\r\nFrom: <sip:***@nm>;tag=root\r\nTo: <sip:***@nm2>\r\nCall-ID: 50000\r\nCSeq: 42 OPTIONS\r\nMax-Forwards: 70\r\nContent-Length: 0\r\nContact: <sip:***@nm>\r\nAccept: application/sdp\r\n\r\n|

So, you tell me, should I be running the script against these TCP ports as well? Why doesn't the nmap-service-probes contain the same SIP probes for UDP?

// Patrik

Matt Selsky

2009-11-24 13:58:31 UTC

Any reason not to run this script on 5060/tcp as well?
--
Matt

So, you tell me, should I be running the script against these TCP ports as well? Why doesn't the nmap-service-probes contain the same SIP probes for UDP?

Because when I originally wrote the SIP OPTIONS probe, I only had access to a tcp SIP server (5060/udp was firewalled)? :-)

Since you have access to a 5060/udp SIP server, can you try adding a udp version of the same/similar probe to nmap-service-probes?

--
Matt

Patrik Karlsson

2009-11-24 15:09:12 UTC

Any reason not to run this script on 5060/tcp as well?
--
Matt

So, you tell me, should I be running the script against these TCP ports as well? Why doesn't the nmap-service-probes contain the same SIP probes for UDP?

Because when I originally wrote the SIP OPTIONS probe, I only had access to a tcp SIP server (5060/udp was firewalled)? :-)
Since you have access to a 5060/udp SIP server, can you try adding a udp version of the same/similar probe to nmap-service-probes?
--
Matt

I ran the exact same probe by simply changing the TCP to UDP in nmap-service-probes. I have attached the responses I received. Both contain version information but were not matched. I guess there's more to it than just switching the protocol in the probe?

SIP/2.0 476 Unresolvable destination (476/TM)
Via: SIP/2.0/TCP nm;branch=foo;received=192.168.56.4
From: <sip:***@nm>;tag=root
To: <sip:***@nm2>;tag=fa997f81440371de71ab448ebdb9af56-fe3b
Call-ID: 50000
CSeq: 42 OPTIONS
Server: OpenSER (1.3.2-tls (x86_64/linux))
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/TCP nm;branch=foo;received=127.0.0.1
From: <sip:***@nm>;tag=root
To: <sip:***@nm2>;tag=as70b83097
Call-ID: 50000
CSeq: 42 OPTIONS
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:127.0.0.1>
Accept: application/sdp
Content-Length: 0

//Patrik

Matt Selsky

2009-11-25 16:51:47 UTC

Post by Patrik Karlsson
So, you tell me, should I be running the script against these TCP ports as well? Why doesn't the nmap-service-probes contain the same SIP probes for UDP?

Is there any way to say that all "match" lines for "Probe TCP SIPOptions" are also valid for "Probe UDP SIPOptions" without having to copy and paste?

--
Matt

David Fifield

2009-11-26 01:47:42 UTC

Post by Patrik Karlsson
So, you tell me, should I be running the script against these TCP ports as well? Why doesn't the nmap-service-probes contain the same SIP probes for UDP?

Is there any way to say that all "match" lines for "Probe TCP SIPOptions" are also valid for "Probe UDP SIPOptions" without having to copy and paste?

I tried doing it with a fallback, but fallbacks are protocol-specific so
a UDP probe can't refer to a TCP probe. Copying the tested match lines
sounds okay.

David Fifield

Tom Sellers

2009-11-24 02:24:54 UTC

Post by Patrik Karlsson
Hi all,
I just finished my first nmap script with some great help from Ron Bowes.
Like the e-mail subject states it does version detection for the SIP protocol.
I've done some basic testing and it looks as if it does what it't intended to.
PORT STATE SERVICE VERSION
5060/udp open|filtered sip Asterisk PBX
PORT STATE SERVICE VERSION
5060/udp open|filtered sip 3CXPhoneSystem 8.0.9844.0
Bug reports or comments and suggestions on things that could be done better/differently are most welcome.

Patrik,

I have not had a chance to look at your code, but looking at your output
I would suggest setting the port state to open when you successfully identify the
service.

Something like this should work:

nmap.set_port_port(host, port, "open")

Tom

Patrik Karlsson

2009-11-24 08:01:36 UTC

Post by Tom Sellers

Post by Patrik Karlsson
Hi all,
I just finished my first nmap script with some great help from Ron Bowes. Like the e-mail subject states it does version detection for the SIP protocol.
I've done some basic testing and it looks as if it does what it't intended to.
PORT STATE SERVICE VERSION
5060/udp open|filtered sip Asterisk PBX
PORT STATE SERVICE VERSION
5060/udp open|filtered sip 3CXPhoneSystem 8.0.9844.0
Bug reports or comments and suggestions on things that could be done better/differently are most welcome.

Patrik,
I have not had a chance to look at your code, but looking at your output
I would suggest setting the port state to open when you successfully identify the
service.
nmap.set_port_port(host, port, "open")
Tom

Thanks Tom!

I have an updated script that does that and works against 5060/tcp and 5061/tcp (SIP TLS).
However, as I posted earlier I realized that there is a static probe in nmap-service-probes that already works against 5060/tcp. So I'm guessing that same probe could be sent to 5060/udp as well and make my script redundant?

Patrik

Fyodor

2009-11-24 22:58:39 UTC

Post by Patrik Karlsson
I have an updated script that does that and works against 5060/tcp
and 5061/tcp (SIP TLS). However, as I posted earlier I realized
that there is a static probe in nmap-service-probes that already
works against 5060/tcp. So I'm guessing that same probe could be
sent to 5060/udp as well and make my script redundant?

Hi Patrik. Thanks for sending your SIP script, and you make a good
point here about the existing static probe.

In general, it is best to handle version detection using that
subsystem (e.g. nmap-service-probes) rather than NSE.
Nmap-service-probes is less powerful and flexible, but more efficient
to execute and maintain. But it can only handle 1 static probe and a
regex-parseable response. I see that your script uses a more dynamic
probe containing the source IP address, etc.

Maybe you can experiment with 5060/udp and see if you can get the same
version information with just a version detection probe and match
line(s) in nmap-service-probes? Like we do for TCP. That would be
the ideal case. If that cannot be done, your new SIP script is a
great fallback option.

Cheers,
-F

Patrik Karlsson

2009-11-24 23:13:35 UTC

Post by Fyodor

Hi Patrik. Thanks for sending your SIP script, and you make a good
point here about the existing static probe.
In general, it is best to handle version detection using that
subsystem (e.g. nmap-service-probes) rather than NSE.
Nmap-service-probes is less powerful and flexible, but more efficient
to execute and maintain. But it can only handle 1 static probe and a
regex-parseable response. I see that your script uses a more dynamic
probe containing the source IP address, etc.
Maybe you can experiment with 5060/udp and see if you can get the same
version information with just a version detection probe and match
line(s) in nmap-service-probes? Like we do for TCP. That would be
the ideal case. If that cannot be done, your new SIP script is a
great fallback option.
Cheers,
-F

Hi Fyodor,

Thanks for the explanation. It turned out that there's no need for that dynamic stuff to be in there in order to trigger a response, at least not for the equipment I tested it against using the static probe already in nmap. I did a quick test against UDP using the static probe and got answers back that seemed equivalent to those recieved over TCP. For some reason they failed to match any of the existing lines though?

//Patrik

Matt Selsky

2009-11-25 08:01:24 UTC

Post by Patrik Karlsson
Thanks for the explanation. It turned out that there's no need for that dynamic stuff to be in there in order to trigger a response, at least not for the equipment I tested it against using the static probe already in nmap. I did a quick test against UDP using the static probe and got answers back that seemed equivalent to those recieved over TCP. For some reason they failed to match any of the existing lines though?

Patrik,

Do you have any examples of the output you did get?

I added a UDP probe was able to detect the SIP Express Router and SIP Router software running on sip.iptel.org:

# nmap -sT -sV -sU -p 5060 sip.iptel.org

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-25 02:50 EST
Interesting ports on sip.iptel.org (213.192.59.75):
PORT STATE SERVICE VERSION
5060/tcp open sip-proxy SIP Router 2.99.99-pre3 (i386/linux)
5060/udp open sip-proxy SIP Router 2.99.99-pre3 (i386/linux)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.82 seconds

# nmap -sT -sV -sU -p 5060 sip.iptel.org

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-25 02:51 EST
Interesting ports on sip.iptel.org (213.192.59.75):
PORT STATE SERVICE VERSION
5060/tcp open sip-proxy SIP Express Router 2.1.0-dev23-make (i386/linux)
5060/udp open sip-proxy SIP Router 2.99.99-pre3 (i386/linux)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.39 seconds

Let me know what you get against your server.

--
Matt

Patrik Karlsson

2009-11-25 09:51:30 UTC

Post by Tom Sellers

Patrik,
Do you have any examples of the output you did get?
# nmap -sT -sV -sU -p 5060 sip.iptel.org
Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-25 02:50 EST
PORT STATE SERVICE VERSION
5060/tcp open sip-proxy SIP Router 2.99.99-pre3 (i386/linux)
5060/udp open sip-proxy SIP Router 2.99.99-pre3 (i386/linux)
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.82 seconds
# nmap -sT -sV -sU -p 5060 sip.iptel.org
Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-25 02:51 EST
PORT STATE SERVICE VERSION
5060/tcp open sip-proxy SIP Express Router 2.1.0-dev23-make (i386/linux)
5060/udp open sip-proxy SIP Router 2.99.99-pre3 (i386/linux)
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.39 seconds
Let me know what you get against your server.
--
Matt
<sip.patch>

Hi Matt,

I applied your patch and it worked correctly against my Asterisk boxes. I added a match for them in the submitted patch. They didn't match any of the softmatch rules as Asterisk returns it's server information in the User-Agent header, rather than the Server header. However, the patch did not work against my OpenSer SIP proxy. I'm running: OpenSER SIP Server 1.3.2-tls (x86_64/linux)

When looking at the tcpdump I noticed something that I previously missed. The server is actually answering with a response that should match. However, it's sending it's response back to the client using 5060/udp as destination. I didn't have this problem with my SIP version script and was able to narrow it down to the rport attribute of the Via header. I have modified your probe so it sends this as well and it works as expected against my boxes now.

Here's how the Asterisk info looks, incase you need to improve my match:

SF-Port5060-UDP:V=5.00%I=7%D=11/25%Time=4B0CF293%P=i686-redhat-linux-gnu%r
SF:(SIPOptions,16A,"SIP/2\.0\x20200\x20OK\r\nVia:\x20SIP/2\.0/UDP\x20nm;br
SF:anch=foo;received=192\.168\.56\.4\r\nFrom:\x20<sip:***@nm>;tag=root\r\nT
SF:o:\x20<sip:***@nm2>;tag=as3f61201f\r\nCall-ID:\x2050000\r\nCSeq:\x2042\
SF:x20OPTIONS\r\nUser-Agent:\x20Asterisk\x20PBX\r\nAllow:\x20INVITE,\x20AC
SF:K,\x20CANCEL,\x20OPTIONS,\x20BYE,\x20REFER,\x20SUBSCRIBE,\x20NOTIFY,\x2
SF:0INFO\r\nSupported:\x20replaces\r\nContact:\x20<sip:192\.168\.56\.4>\r\
SF:nAccept:\x20application/sdp\r\nContent-Length:\x200\r\n\r\n");

--
Patrik

Matt Selsky

2009-11-25 16:41:34 UTC

Post by Patrik Karlsson
I applied your patch and it worked correctly against my Asterisk boxes. I added a match for them in the submitted patch. They didn't match any of the softmatch rules as Asterisk returns it's server information in the User-Agent header, rather than the Server header. However, the patch did not work against my OpenSer SIP proxy. I'm running: OpenSER SIP Server 1.3.2-tls (x86_64/linux)
When looking at the tcpdump I noticed something that I previously missed. The server is actually answering with a response that should match. However, it's sending it's response back to the client using 5060/udp as destination. I didn't have this problem with my SIP version script and was able to narrow it down to the rport attribute of the Via header. I have modified your probe so it sends this as well and it works as expected against my boxes now.
SF-Port5060-UDP:V=5.00%I=7%D=11/25%Time=4B0CF293%P=i686-redhat-linux-gnu%r
SF:(SIPOptions,16A,"SIP/2\.0\x20200\x20OK\r\nVia:\x20SIP/2\.0/UDP\x20nm;br
SF:x20OPTIONS\r\nUser-Agent:\x20Asterisk\x20PBX\r\nAllow:\x20INVITE,\x20AC
SF:K,\x20CANCEL,\x20OPTIONS,\x20BYE,\x20REFER,\x20SUBSCRIBE,\x20NOTIFY,\x2
SF:0INFO\r\nSupported:\x20replaces\r\nContact:\x20<sip:192\.168\.56\.4>\r\
SF:nAccept:\x20application/sdp\r\nContent-Length:\x200\r\n\r\n");

Good work on the "rport" option.

I updated the Asterisk match line to look for \r\n since I still want to catch the case where Asterisk returns a version number too. I added some of the TCP match lines that I could test like OpenSER, SER, OpenSIPS, and SIP Router. Can you try this updated version of my patch?

--
Matt

Patrik Karlsson

2009-11-25 16:48:41 UTC

Good work on the "rport" option.
I updated the Asterisk match line to look for \r\n since I still want to catch the case where Asterisk returns a version number too. I added some of the TCP match lines that I could test like OpenSER, SER, OpenSIPS, and SIP Router. Can you try this updated version of my patch?
--
Matt
<sip-v2.patch>

Looking good!

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-25 17:47 CET

Interesting ports on sip.testpbx.lo (192.168.56.4):
PORT STATE SERVICE VERSION
5060/udp open sip-proxy Asterisk PBX

Interesting ports on 192.168.56.3:
PORT STATE SERVICE VERSION
5060/udp open sip-proxy OpenSER SIP Server 1.3.2-tls (x86_64/linux)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 2 IP addresses (2 hosts up) scanned in 7.92 seconds

//Patrik

David Fifield

2009-11-26 01:54:09 UTC

Good work on the "rport" option.
I updated the Asterisk match line to look for \r\n since I still
want to catch the case where Asterisk returns a version number too.
I added some of the TCP match lines that I could test like OpenSER,
SER, OpenSIPS, and SIP Router. Can you try this updated version of
my patch?

Looking good!
Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-25 17:47 CET
PORT STATE SERVICE VERSION
5060/udp open sip-proxy Asterisk PBX
PORT STATE SERVICE VERSION
5060/udp open sip-proxy OpenSER SIP Server 1.3.2-tls (x86_64/linux)
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 2 IP addresses (2 hosts up) scanned in 7.92 seconds

This patch is looking great and I have committed it in r16209. I have
one question--is it worth adding "sslports 5061" to the TCP SIPOptions
probe? Does someone have that set up so they can test it?

David Fifield

Patrik Karlsson

2009-11-26 15:46:45 UTC

Post by David Fifield

Good work on the "rport" option.
I updated the Asterisk match line to look for \r\n since I still
want to catch the case where Asterisk returns a version number too.
I added some of the TCP match lines that I could test like OpenSER,
SER, OpenSIPS, and SIP Router. Can you try this updated version of
my patch?

I tested adding the sslports 5061 to the probe. It got me the same results but in a third of the time it took without it.

//
Patrik

Matt Selsky

2009-12-01 06:50:11 UTC

Post by David Fifield
This patch is looking great and I have committed it in r16209. I have
one question--is it worth adding "sslports 5061" to the TCP SIPOptions
probe? Does someone have that set up so they can test it?

I tested adding the sslports 5061 to the probe. It got me the same results but in a third of the time it took without it.

And the patch:

diff --git a/nmap-service-probes b/nmap-service-probes
index 808f263..883a901 100644
--- a/nmap-service-probes
+++ b/nmap-service-probes
@@ -6884,6 +6884,7 @@ match ldap m|^0.\x02.*TLS confidentiality required|s i/TLS required/
Probe TCP SIPOptions q|OPTIONS sip:nm SIP/2.0\r\nVia: SIP/2.0/TCP nm;branch=foo\r\nFrom: <sip:***@nm>;tag=root\r\nTo: <sip:***@nm2
rarity 5
ports 406,5060
+sslports 5061
fallback GetRequest
# Some VoIP phones take longer to respond
totalwaitms 7500

--
Matt

David Fifield

2009-12-13 04:07:38 UTC

I tested adding the sslports 5061 to the probe. It got me the same results but in a third of the time it took without it.

diff --git a/nmap-service-probes b/nmap-service-probes
index 808f263..883a901 100644
--- a/nmap-service-probes
+++ b/nmap-service-probes
@@ -6884,6 +6884,7 @@ match ldap m|^0.\x02.*TLS confidentiality required|s i/TLS required/
rarity 5
ports 406,5060
+sslports 5061
fallback GetRequest
# Some VoIP phones take longer to respond
totalwaitms 7500

Thanks, committed.

David Fifield

Matt Selsky

2009-11-25 16:49:21 UTC

Post by Patrik Karlsson
I have an updated script that does that and works against 5060/tcp and 5061/tcp (SIP TLS).
However, as I posted earlier I realized that there is a static probe in nmap-service-probes that already works against 5060/tcp. So I'm guessing that same probe could be sent to 5060/udp as well and make my script redundant?

Do the new entries in nmap-service-probes work against your 5061 SIP TLS server?

Patrik Karlsson

2009-11-25 17:16:26 UTC