sip-fraud.txt
Posted on 05 November 2007
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@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@attacker.lan.org To: victim@victim.lan.org Contact: 1900-XXXX@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@proxy.org -------- V From: victim@victim.lan.org To : attacker@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@proxy.org -------- V Digest: realm ="proxy.org", nonce="Proxy-Nonce-T1" username= "victim", uri="1900XXXX@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
