sip-fraud.txt

`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 [email protected]  
  
  
  
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 : [email protected]  
  
To: [email protected]   
  
Contact: [email protected]  
  
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 [email protected] -------- V  
  
From: [email protected]  
  
To : [email protected]  
  
  
  
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 [email protected] -------- V  
  
Digest: realm ="proxy.org", nonce="Proxy-Nonce-T1"  
  
username= "victim",  
  
uri="[email protected]",  
  
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  
  
`