A tool to poison a targeted issuer of SIP INVITE requests with 301
(i.e. Moved Permanently) redirection responses. The tool is named
redirectpoison. It was tested on a Linux Red Hat Fedora Core 4 platform
(Pentium IV, 2.5 GHz), but it is expected this tool will successfully
build and execute on a variety of Linux distributions.

    Copyright (c)  2006  Mark D. Collier/Mark O'Brien
    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".
 
Authors:  Mark D. Collier/Mark O'Brien   10/16/2006  v1.1
	  Mark D. Collier/Mark O'Brien   09/14/2006  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.

The following open-source libraries of special note were used to build
redirectpoison:

1) libnet v1.1.2.1 (tool requires at least this version)
2) libpcap v0.9.4 (tool will probably work with some earlier versions)
3) hack_library [utility routines - Str2IP( ) GetNextGuid( )]
   see www.hackingexposedvoip.com

    Note: The Makefile for redirectpoison presumes
          that hack_library.o and hack_library.h reside in
          a folder at ../hack_library relative to the Makefile
          within the redirectpoison directory.

Install and build the libraries in accordance with their respective
instructions. Then change to the redirectpoison directory and type: make
Warnings might presented as a function of the compiler vintage.

---------------

[root@localhost redirectpoison_v1.1]# ./redirectpoison
 
Error: 4 command line parameters are mandatory
 
redirectpoison - Version 1.1
                 October 16, 2006
 Usage:
 Mandatory -
        interface (e.g. eth0)
        target source IPv4 addr
        target source port
        "contact information" (i.e. the poison)
            A string enclosed by dbl quotes. Contact information
            is used as-is (i.e. no validity parsing is performed)
            Examples: "<sip:fooledya@bogus.com>"
                      "hacker <sips:hackedyou@188.55.128.10>"
                      "<sip:6000@10.1.101.60>"
                      "voicemail <sip:4500@192.168.20.5;transport=udp>"
                      "<sip:4500@192.168.20.5:\"secret\">"
                      "<sip:100.77.50.52;line=xtrfgy>"
                      Note: the last example did not include a
                            'user' part in the URI. The tool
                            detects if a SIP request received from
                            the targeted host already exhibits
                            poisoning by comparing the user part
                            from the poison with the user part in:
                              1) the Request-URI
                              2) the To-URI
                            If the user part of either URI equals
                            the user part from the poison, then the
                            tool remains quiet in that instance.
                            Presumably, the target is issuing a new
                            SIP request to a redirected party and
                            the tool user wishes that transaction
                            to proceed without additional
                            interference. If you don't specify a
                            user part in the contact poison, then
                            pre-poisoning detection logix is
                            disabled and the tool reacts to every
                            INVITE request it detects from the
                            target source IP:port.
 Optional -
        -h help - print this usage
        -v verbose output mode
[root@localhost redirectpoison_v1.1]#

---------------

If you execute the tool by specifying poison without a URI 'user' part,
you receive the following output:

---------------

[root@localhost redirectpoison_v1.1]# ./redirectpoison eth2 10.1.101.1 5060 "<sip:100.77.50.52;line=xtrfgy>"
 
redirectpoison - Version 1.1
                 October 16, 2006
 
target IPv4 addr:port = 10.1.101.1:5060
 
redirect response contact info: <sip:100.77.50.52;line=xtrfgy>
 
Warning: The contact poison specified is expected to contain
         a SIP URI. Although the user part of a URI is
         optional, it is needed by this tool to determine
         if a target SIP request has already been poisoned.
         The tool does not transmit a poisoned SIP redirect
         response for a SIP request already carrying poison.
         No URI 'user part' has been found in the poison.
         The pre-poisoning assessment logix is disabled!
 
 __REDIRECTPOISON_LIBNET_PROTOCOL_LAYER = 3
 
Will inject spoofed audio at IP layer

 
Process priority was = 0
 
Process Priority set to: -20 (i.e. highest priority)

---------------
 
However, if you specify a poison with a 'user' part in the uri, then you'll
receive this output:

---------------

[root@localhost redirectpoison_v1.1]# ./redirectpoison eth2 10.1.101.1 5060 "voicemail <sip:4500@192.168.20.5;transport=udp>"
 
redirectpoison - Version 1.1
                 October 16, 2006
 
target IPv4 addr:port = 10.1.101.1:5060
 
redirect response contact info: voicemail <sip:4500@192.168.20.5;transport=udp>
 
pre-poisoning assessment logix is dependent upon finding
this URI 'user' part in the Request-URI or To-URI of target
SIP requests:  4500
 
 __REDIRECTPOISON_LIBNET_PROTOCOL_LAYER = 3
 
Will inject spoofed audio at IP layer
 
 
Process priority was = 0
 
Process Priority set to: -20 (i.e. highest priority)
 
---------------

The tool runs until a fatal error occurs or it is signaled to halt
(i.e. <ctrl>c). When the tool terminates, it'll print a few metrics.
An example follows:

---------------

exiting...
 
Number of packets sniffed from target = 53
 
Number of INVITE requests sniffed from target = 4
 
Number of poisoned redirect replies transmitted to target = 2
 
[root@localhost redirectpoison_v1.1]#

---------------
 
This tool does NOT presume it is running as Man-In-The-Middle
(MITM), however, it does presume that SIP signaling can be received
by the specified Ethernet interface in promiscuous mode (e.g. the
host running the tool is connected to a hub through which target
SIP signaling messages are flowing). A 3xx series SIP response is
a "final response". The desire is for the tool to detect an INVITE
request from the specified target host IPv4 addr:port and reply
with a 301 (i.e. Permanently Moved) response (i.e. if the INVITE
message doesn't already appear to have been poisoned by this tool)
before the host receives any final or provisional replies to its
INVITE request. To aid in accomplishing this desire, the tool raises
its execution priority to the maximum (i.e. the numerically most
negative setting: -20). This is one reason, among others, why the
tool must execute as root. You may notice other applications running
concurrently on the host executing this tool responding more slowly
than they otherwise would.

This version of the tool is not entirely comprehensive. Several
shortcuts are taken, particularly with regard to SIP message
parsing. Some caveats to keep in mind:

o The tool does not handle key instances of abbreviated header
  names. "key" is defined as those header names of particular
  interest to the tool (e.g. To, From, Contact, ..etc).

o The tool presumes that the colon immediately follows header
  names without intervening whitespace.

o The tool does not handle headers spanning multiple lines.

o Characters in the user part of URIs are permitted to be expressed
  using hex notation. RFC 3261 states that a uri user part with any
  character expressed using hex notation is equal to that same
  character expressed without hex notation. This tool does not
  recognize such an equality.

o Escaped charaters are not necessarily processed in accordance
  with RFC 3261. 

o --- Otherwise, the tool presumes INVITE messages are properly
  formatted in accordance with RFC 3261.

o The tool supports unfragmented packets using UDP transport.

o The tool supports standard IPv4 network headers without 
  options.

o The tool does NOT presently support 802.1q (i.e. layer 2
  VLAN/priority tagging) within the 802.3 IEEE Ethernet
  header.

An analysis of the table found in RFC 3261, Section 20, page 158 was
performed. This analysis yielded the message headers that must appear
in a redirect response, what headers need to be copied as-is from the 
INVITE message into the redirect response, what headers must be 
modified from the INVITE message as they are copied into the redirect
response, what headers must not appear in a redirect response, and
what headers are optional in a redirect response. As such:

   Exclude the following headers that must or should or may appear
   in the INVITE request from the 301 response:

   Accept
   Accept-Encoding
   Accept-Language
   Alert-Info
   Allow
   Authentication-Info
   Authorization
   Max-Forwards
   Priority
   Proxy-Authorization
   Proxy-Require
   In-Reply-To
   Record-Route
   Route
   Subject
   Supported
   WWW-Authenticate

   Must copy the following headers from the request to the 
   response:

   Call-ID
   CSeq
   From
   To (and add a tag to the end if no tag is present)
   Via

   The following headers are optional or should appear in certain
   requests and may appear in responses. We're going to exclude
   these headers from being copied into the response. However,
   we're going to include a content length header of zero (i.e. 
   "Content-Length: 0" in the redirect response. 

   Call-Info
   Content-Disposition
   Content-Encoding
   Content-Language
   Content-Length
   Content-Type
   Date
   Mime-Version
   Organization
   Reply-To
   Require                    
   User-Agent

   The following headers may originate in a response. We do not
   include them in our response.

   Server
   Warning

   The purpose of this tool is to spoof Contact headers in a redirect
   response, so we'll any discard Contact headers found in the 
   request and supply our own.

   Contact

Any SDP message found in the target INVITE request is discarded.  

If you don't know the targeting parameters of the host to be 
poisoned with redirect responses a priori (i.e. IPv4 address,
UDP source port), use Ethereal/Wireshark or some appropriate
sniffer to determine the SIP UAC of interest.

In a poison string such as the following:

"voicemail <sip:4500@192.168.20.5;transport=udp>"

the entire content (i.e. minus the dbl quotes) is referred by 
RFC 3261 as a name-addr. The characters appearing before the
uri are collectively defined as the display-name field
(i.e. "voicemail" in this case). Many VoIP phones with displays
react to receiving a redirect reply with that contact information
by outputting something like the following to their display:

Forwarding to
  voicemail

If the display-name field is not included in the poison
contact information, those phones typically extract the
'user' part from the uri and display something like the
following:

Forwarding to
  4500

This version of the tool does not attribute any special significance
to re-INVITE requests. For example, it is common for the Asterisk
IP PBX to behave as a SIP B2BUA during at least the beginning and
end of a call. When the Asterisk IP PBX receives an INVITE request
from a caller, it will first set itself up as the called endpoint
to the calling device (i.e. it "answers" the call) and as the calling
endpoint to the called device. Bi-directional audio is bridged through
the Asterisk IP PBX. Codec translation occurs as needed. If the
Asterisk channels in-use and the device endpoint capabilities support
it, Asterisk then removes itself from the audio path. It does this
by re-INVITE'ing the endpoints to transmit audio directly to each
other. If the redirectpoison tool is in a position to detect these
re-INVITEs, it will very likely repoison (i.e. redirect) one of
those re-INVITEs. Don't be surprised if the call gets torn down in
this scenario.    

A compilation directive determines whether the object code of the tool is
produced with Ethernet layer spoofing or whether IP layer spoofing is
sufficient. Testing to-date has demonstrated that Ethernet layer spoofing
is NOT required. The tool executes faster when it is not required to spoof
at the Ethernet layer. Ethernet layer spoofing is not recommended.

Mark O'Brien (10/19/2006)