Redirection Attacks

In SIP, a proxy or UA can respond to an INVITE request with a 301 Moved Permanently or 302 Moved Temporarily response. The initiating UA should use the value in the Contact header line to locate the moved user . The 302 response will also include an expires header line that communicates how long the redirection should last. If an attacker is able to monitor for (or is an MITM) the INVITE request, he can respond with a redirection response, effectively denying service to the called party and possibly tricking the caller into communicating with a rogue UA.

To demonstrate this attack, we developed the redirectpoison tool. This monitors for an INVITE request and responds with a 301 Moved Permanently response. The usage information for this tool is as follows :

 redirectpoison: ./redirectpoison EthernetInterface TargetSourceIP TargetSourcePort "Contact Information" h -v Usage Example: ./redirectpoison eth0 10.1.101.30 5060 "<sip:6000@10.1.101.60>" Mandatory parameters: EthernetInterface  The Ethernet interface to write to. TargetSourceIP  The IPV4 address of the target UA to redirect calls away from. TargetSourcePort  The port of the target UA to redirect calls away from. "Contact Information" If this option is not specified, the tool feeds back the URI in the To header of each INVITE request as the Contact information in the redirect response. This parameter allows you to specify the URI to which the INVITE is redirected. Be sure to enclose the URL in quotes. Some example URIs are:  -c "<sip:fooledya@bogus.com>"  -c "hacker <sips:hackedyou@188.55.128.10>"  -c "<sip:6000@10.1.101.60>"  -c "<sip:4500@192.168.20.5;transport=udp>" Optional Parameters: -h  Help  Prints this usage information. -v  Verbose  Enables verbose output. 

The redirectpoison tool does not need to be run as a man-in-the-middle (MITM). However, it does require that SIP signaling be received by the specified Ethernet interface in promiscuous mode (for example, the host running the tool must be connected to a hub through which target SIP signaling messages are flowing ). Chapters 5 and 6 discuss several ways to accomplish this level of eavesdropping. The tool monitors SIP signaling messages for an INVITE destined for the target host and replies with a 301 Moved Permanently response. This response must be sent and received before any other provisional or final responses are received (in other words, the attack needs to win the race condition). To aid in accomplishing this, the tool raises its execution priority to the maximum (the numerically most negative setting: 20). You must run this tool as root to allow this priority to be set.

As part of research for this tool, an analysis of RFC 3261 was performed. This analysis yielded the message headers that must appear in a redirect response, which headers need to be copied as-is from the INVITE message into the redirect response, which headers must be modified from the INVITE message as they are copied into the redirect response, which headers must not appear in a redirect response, and which headers are optional in a redirect response. As such, for the attack to be successful:

  • Exclude the following headers that must or should or might 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

  • 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

Other headers are optional, so they are not included. The purpose of this tool is to spoof Contact headers in a redirect response, so any Contact headers are discarded and replaced . Any SDP message found in the target INVITE request is discarded.

When run, the redirectpoison tool runs until terminated by the user. The proxies we tested , including Asterisk and SER, didn't check if the Contact returned for a 301 response was the same as what was provided in the To: header of the INVITE request.

Attack Redirection Attacks to a Nonexistent IP Phone

Popularity:

6

Simplicity:

8

Impact:

8

Risk Rating:

7

You can use the redirectpoison tool to redirect calls to a nonexistent SIP phone, resulting in a DoS condition for both the caller and called parties. An example redirectpoison command-line invocation is shown here:

 ./redirectpoison eth0 10.1.101.40 5060 "<bogus@10.1.101.2>" 

Attack Redirection Attacks to a Random SIP Phone

Popularity:

6

Simplicity:

8

Impact:

8

Risk Rating:

7

You can also use the redirectpoison tool to redirect calls to a random or unexpecting user, resulting in a DoS condition to the called party and confusing the caller and the new called party. The new party will receive a call from a user who is not expecting them to answer. An example redirectpoison command-line invocation is shown here:

 ./redirectpoison eth0 10.1.101.40 5060 "<3500@10.1.101.2>" 

Attack Redirection Attacks to a Rogue SIP Phone

Popularity:

6

Simplicity:

8

Impact:

9

Risk Rating:

8

You can also use the redirectpoison tool to redirect calls to a rogue SIP phone, which could be used to imitate the intended called party. The rogue could trick the caller into leaving a voicemail or possibly involve a human who tricks the caller into disclosing important information. An example redirectpoison command-line invocation is shown here:

 ./redirectpoison eth0 10.1.101.40 5060 "<hacker@10.1.101.2>" 

Impact and Probability of Occurrence

Redirection attacks are similar in impact to registration hijacking attacks in that they both subvert inbound calls to a specific SIP phone. Redirection attacks are arguably less disruptive, however, because they affect inbound calls to a SIP phone from a single other SIP phone (at least using the tool we provided). All of the attacks possible with registration hijacking are possible; it is just that redirection attacks affect calls coming from a single SIP phone. See the "Attacks" sections under "Registration Hijacking" for some examples.

For these attacks to take place, the attacker needs access to the part of your internal network where a SIP phone sends signaling and can be tricked into redirecting INVITE requests to the new target. This attack is also possible from a public network if you use SIP trunks for access to your voice service provider.

Countermeasurs Countermeasures

You can employ several countermeasures to address redirection attacks. These countermeasures are similar to those described in the "Countermeasures" section for erasing registrations.



Hacking Exposed VoIP. Voice Over IP Security Secrets & Solutions
Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions
ISBN: 0072263644
EAN: 2147483647
Year: 2004
Pages: 158

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net