[VOIPSEC] CallManager and OpeSer toll fraud and authentication forward attack

[satyam]

" The tested implementations do not allow to check if the provided URI in
the Digest authentication header is the same as the REQUEST-URI of  the
message, which  allows an attacker to call any other extension. This is not
a simple replay attack."

This is an RFC 3261 requirement

Section 22.4 The Digest Authentication Scheme

"      6.  RFC 2617 [17] requires that a server check that the URI in the
          request line and the URI included in the Authorization header
          field point to the same resource.  In a SIP context, these two
          URIs may refer to different users, due to forwarding at some
          proxy.  Therefore, in SIP, a server MAY check that the
          Request-URI in the Authorization header field value
          corresponds to a user for whom the server is willing to accept
          forwarded or direct requests, but it is not necessarily a
          failure if the two fields are not equivalent.
"

For a call server this may be the right approach. A device with security
policies can enforce stricter constraints, which is aware of presence or
absence of intermediate proxies and call forwarding behavior and can have
policies around this. 

Although, not using a new nonce or a nonce-count is a poor practice

Thanks,
Satyam


-----Original Message-----
From: voipsec-bounces at voipsa.org [mailto:voipsec-bounces at voipsa.org] On
Behalf Of Radu State
Sent: Friday, October 12, 2007 11:54 AM
To: voipsec at voipsa.org
Subject: [VOIPSEC] CallManager and OpeSer toll fraud and authentication
forward attack

MADYNES Security Advisory : SIP toll fraud and authentication forward attack

Date of Discovery 5  May, 2007

Vendor1 (Cisco) was informed on 22 May 2007

Vendor 2 (OpenSer, voice-systems) was informed in 4 th October 2007

ID: KIPH11 

Affected products

 

CallManager:

System version: 5.1.1.3000-5 

Administration version: 1.1.0.0-1

 

OpenSer

 

SVN version until the 4 th October 2007

Version 1.2.2

 

 

Summary 

 

 

The tested systems do not associate a Digest authentication to a dialog
which allows any user who can sniff the traffic to make its own calls on
behalf of the the sniffed device. 


Synopsis

The tested implementations do not allow to check if the provided URI in
the Digest authentication header is the same as the REQUEST-URI of  the
message, which  allows an attacker to call any other extension. This is not
a simple replay attack.

They do not allowed to generate one-time nonces.   These issues will allow a
malicious user able to sniff a Digest  authentication from a regular user,
to call (by spoofing data) any  extension on behalf of the user; as long as
the nonce does not expire.

The first vendor   (Cisco) was informed  in May 2007 and acknowledged the
vulnerability. The second vendor (OpenSe, voice-systems r) was informed in
October 2007 and fixed the vulnerabity on the same day.

 This vulnerability was identified by the Madynes research team at INRIA
Lorraine, using the Madynes VoIP fuzzer KIPH. This is one of the first
vulnerabilities published where advanced state tracking is required.

Background 

*	SIP is the IETF standardized (RFCs 2543 and 3261) protocol for VoIP
signalization. SIP is an ASCII based INVITE message is used to initiate and
maintain a communication session. 



Impact :


A malicious user perform toll fraud and call ID spoofing.


Resolution



OpenSer fixed the issue on the 4 th October.  

 

The devel branch was enhanced to export a variable $adu which refer to this
field. It is easy now to check in config file whether it is equal or not
with r-uri:

 

if($adu != $ru)

{

# digest uri and request uri are different 

}

 


Credits

*	Humberto J. Abdelnur (Ph.D Student) 
*	Radu State (Ph.D) 
*	Olivier Festor (Ph.D) 


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

 

POC: PoC code is available on request

 

 

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org