On 12/20/08 12:03, Iñaki Baz Castillo wrote:
El Jueves, 18 de Diciembre de 2008, Iñaki Baz Castillo
escribió:
I'm thinking in the following flow in which
the caller/attacker would
get an unlimited call (but a limited CDR duration):
--------------------------------------------------------------------------
attacker Kamailio (Acc) gateway
INVITE (CSeq 12) ------>
<-------- 407 Proxy Auth
INVITE (CSeq 13) ------>
INVITE (CSeq 13) ------>
<------------------- 200 Ok
<------------------- 200 Ok
<< Acc START >>
ACK (CSeq 13) ----------->
ACK (CSeq 13) ----------->
<******************* RTP ************************>
# Fraudulent BYE !!!
BYE (CSeq 10) ----------->
<< Acc STOP >>
BYE (CSeq 10) ----------->
<-- 500 Req Out of Order
<-- 500 Req Out of Order
--------------------------------------------------------------------------
There is a solution for this (not perfect):
- The proxy stops the accounting when receives a BYE from the gateway,
regardless of the BYE reply from the client. This prevents from BYE
negatively answered by clients.
- The proxy stops the accounting when receives a BYE from the client and the
200 OK from the gateway. This prevents from the above case in which the
client sends an out-of-date CSeq in the BYE.
But this is not enough, note the following case:
- The user is in a call with the gateway.
- The user sends a BYE with "Route: proxy" and RURI pointing to *himself*.
- The BYE arrives to the proxy which forwards it back to the user again.
- The user (attacker in fact) replies a 200 OK but doesn't terminate the RTP
session with the gateway.
- The proxy receives the 200 OK (BYE) from a user, so terminates the
accounting.
- The gateway knows exactly *nothing* about it, the call continues (but from
now it's free).
Annoying?
This is part of well know Route-based attacks. I did a demo for a German
newspaper like 4-5 years ago with a modified KPhone.
Fortunately for you, kamailio gives you a lot of tools to enhance the
security as you need. You can check the stack of Via headers, source ip,
etc... against the destionation address.
Similar attacks can happen with poisoned DNS, where is hard to check the
IP address.
I believe in this cases an important aspect is to be sure you can
identify the attacker. It is hard to prevent all people can think of,
but when detecting one case, being able to get the guilty is very
important. Also, at that time, you can add the logic to prevent further
exposure to same attack.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com