[VOIPSEC] Breaking SIP for fun and toll fraud

Klaus Darilion klaus.mailinglists at pernau.at
Wed Nov 7 04:33:49 EST 2007


Hi Radu!

1. How can X call directly Y bypassing P?
2. Yes, there is potential for fraud. This shows that actually a proxy 
never should trust any user data (e.g. Contact).

regards
klaus

Radu State schrieb:
> 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 at proxy.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 at attacker.lan.org
> 
>                To: victim at victim.lan.org 
> 
>                Contact: 1900-XXXX at proxy.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 at proxy.org -------- V
> 
>                From: victim at victim.lan.org
> 
>                To : attacker at attacker.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 at proxy.org -------- V
> 
>                Digest: realm ="proxy.org", nonce="Proxy-Nonce-T1"
> 
>                        username= "victim",
> 
>                        uri="1900XXXX at proxy.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
>  
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org




More information about the Voipsec mailing list