[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