[VOIPSEC] Breaking SIP for fun and toll fraud

[Andre Fucs de Miranda]

Iñaki,

For what I understand,
the attack is possible because the victim UAC is receiving the SIP request
directly from the Attacker, without passing through the proxy. This step
induces the victim UAC to sned the invite back from where it came from, an
rogue "UAS".

Note:
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 MUS 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

Great work
indeed. Sounds like people writing the RFC didn't finish their home work and
forgot about source routing attacks? :-)

Cheers



----
Mensagem Original ----
From: Iñaki Baz Castillo
To: voipsec at voipsa.org
Sent: Dom, Novembro 4, 2007 9:50 pm

Subject: Re: [VOIPSEC] Breaking SIP for fun and toll fraud

> I've just now subscribed to this list so cannot reply the original mail and
> conserve the thread, I'm sorry.
> About the security issue, what about this solution?:
>
>>  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 >    Digest: realm ="proxy.org",
nonce="Proxy-Nonce-T1"

>>      username= "victim",

>>      uri="1900XXXX at proxy.org",

>>      response="the victim computed response"

>

> Proxy.org is the proxy responsible for victim, so victim should
authenticate

> just to its proxy but no to other UAS. Why should the victim
authenticate to

> other UAS different of its proxy?

> In this case, proxy.org could remove credentials in any message
passing

> through it with any destination, so the attacker wouldn't get a valid
> digets.

> For example, OpenSer could do it by adding
"consume_credentials()" before

> relaying the message.

>

> In case of escenarios where the above solution is not valid there
is still

> other solution in the proxy side: test the "Contact" URI
and reject messages

> with forbidden URI's in Contact (as proxy URI).

> Regards.

>

>

> --

> Iñaki Baz Castillo

> _______________________________________________

> Voipsec mailing list

> Voipsec at voipsa.org

> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

>