Date: Sun, 4 Nov 2007 15:45:54 +0100
From: "Radu State" <State@...ia.fr>
To: <full-disclosure@...ts.grok.org.uk>
Subject: breaking SIP for fun and toll fraud

SIP Digest Access Authentication RELAY-ATTACK for Toll-Fraud

 

     In this post, we would like to inform about a potential Authentication
vulnerability

     in SIP, where all SIP equipments using Digest Access Authentication
which can issue 

     re-INVITEs are vulnerable.

 

     The problem lies in an attack scenario, where a called device can be
triggered by a

     calling party to issue a re-INVITE. Such cases appear when either a
phone is put on

     hold. More general, this is possible whenever a target refresh within a
dialog takes

     place.

 

     The impact is that Toll-fraud, Call-ID spoofing, etc. are possible,
allowing a third

     entity to call on behalf of a victim. The victim is accountable in this
case for the

     call.

 

     To our knowledge, we don't know if neither the IETF nor anybody else
has addressed 

     this issue yet. 

 

     THIS IN NOT THE KNOWN ISSUE OF MAN IN THE MIDDLE. THE MAIN NOVELTY IS
THAT AN 

     ATTACKER CAN TRIGGER A re-INVITE FROM A CALLED PHONE AND REQUEST IT TO
AUTHENTICATE.

     In the known MITM the attacker has to wait until the victim initiates a
call and the

     attacker may issue the call to a destination choice, but to the one
initially chosen

     by the victim (RFC 3261 Section 22.4). 

 

Description of the attack:

 

Synopsis

 

     An attacker will issue a call to the victim, the victim answer and
later on put the

     attacker on hold. To address to be put on hold, an accomplice of the
attacker may

     initiate another call. Once the attacker receives the re-INVITE
specifying the 

     "On hold", he/she will request the victim to authenticate. This last
authentication 

     may be use by the attacker to impersonate the victim at its own proxy.
Detailed 

     explanation is below.

 

Notations

 

     P is the proxy located at URL:    proxy.org 

     X is the attacker located at URL: attacker.lan.org

     V is the victim located at URL:   victim.lan.org 

     V is also registered with P under the username victim@...xy.org

 

     Y is the accomplice of X (it can be in fact X), but we use another
notation for 

       clarity sake

 

Objective: 

 

     X wants to call a toll fraud number 1-900-XXXX  impersonating V

 

Process:

 

     Step 1) X calls's directly V. 

             "The route set MUST be set to the list of URIs in the
Record-Route header 

              field from the request...The remote target MUST be set to the
URI from

              the Contact header field of the request." RFC 3261 Section
12.1.1 UAS 

              behaviour

            

 

          X ---------- INVITE victim.lan.org -------------> V

               From : attacker@...acker.lan.org

               To: victim@...tim.lan.org 

               Contact: 1900-XXXX@...xy.org

               Record-Route: attacker.lan.org

 

     Step 2) The normal SIP processing

 

          X <--------------- 180 Ringing ------------------ V

          X <----------------- 200 OK --------------------- V

 

          X <--------------- Media Data ------------------> V

 

 

     Step 3) The accomplice Y steps in and invites victim V, and then the
victim decides

             to put X on hold

 

 

     Step 4) The victim, V, sends a re-INVITE to X (to put it on hold)

             "The UAC uses the remote target and route set to build the
Request-URI and 

              Route header field of the request." RFC 3261 12.2.1.1
Generating the

              Request (Requests within a Dialog)

 

          X <----------- INVITE 190XXXX@...xy.org -------- V

               From: victim@...tim.lan.org

               To : attacker@...acker.lan.org

 

     Step 5) X calls 1900-XXXX using the proxy P and the proxies asks X to
authenticate

             using a Digest Access Authentication with nonce
="Proxy-Nonce-T1" and

             realm ="proxy.org"

 

     Step 6) X request the victim to authenticate the re-INVITE from step 4
using the 

             same Digest Access Authentication received in step 5 

 

          X ------------401/407 Authenticate ------------> V

               Digest: realm ="proxy.org", nonce="Proxy-Nonce-T1"

 

     Step 7) In this step the victim will do the work for X (Relay Attack)

 

          X <----------- INVITE 190XXXX@...xy.org -------- V

               Digest: realm ="proxy.org", nonce="Proxy-Nonce-T1"

                       username= "victim",

                       uri="1900XXXX@...xy.org",

                       response="the victim computed response"

 

     Step 8) X may reply now to the Proxy with the valid Digest Access
Authentication

             computed by the victim. Note that the Digest itself it is a
perfectly 

             valid one.

 

 

POC code: 

 

     Available ONLY to legitimate VoIP device manufacturers.

 

Possible Mitigations: 

 

     Avoid re-INVITE

     Use strict outbound proxy with a complementary IDS to detect possible
anomalies

     ...

 

Further reading:

 

     More details (beyond simple ASCII drawings) can be found on 

          http://www.loria.fr/~abdelnur

 

Credits:

 

     Humberto Abdelnur, Ph.D student, the Madynes team at INRIA

     Radu State, Ph.D, the Madynes team at INRIA

     Olivier Festor, Ph.D the Madynes team at INRIA

 

This vulnerability was identified by the Madynes research team at INRIA
Lorraine, using 

the Madynes VoIP fuzzer KiF~KIPH

 

 


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.21/1109 - Release Date: 04/11/2007
11:05
 

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists