my lab partner & i have found that if we sniff an ACK message during call setup and extract the call tag and id, then we can arbitrarily hang up the call from our java attack generator. i thought about adding some logic to ser.cfg to process BYEs. is there an easy way to authenticate the BYE? i have something like the following in ser.cfg, but it seems to have no effect
if (method=="BYE") { if (!check_from()) { ...etc }; };
thanks, scott DSi
Ticknor.Scott@ic.gc.ca writes:
my lab partner & i have found that if we sniff an ACK message during call setup and extract the call tag and id, then we can arbitrarily hang up the call from our java attack generator. i thought about adding some logic to ser.cfg to process BYEs. is there an easy way to authenticate the BYE?
there is no way to authenticate bye if it is initiated by the party that is not local to the proxy.
-- juha
You can disable UDP - that prevents from faked messages, but causes lots of interoperability problems.
klaus
Ticknor.Scott@ic.gc.ca wrote:
my lab partner & i have found that if we sniff an ACK message during call setup and extract the call tag and id, then we can arbitrarily hang up the call from our java attack generator. i thought about adding some logic to ser.cfg to process BYEs. is there an easy way to authenticate the BYE? i have something like the following in ser.cfg, but it seems to have no effect
if (method=="BYE") { if (!check_from()) { ...etc }; };
thanks, scott DSi
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Mar 30, 2004 at 10:55, Klaus Darilion klaus.mailinglists@pernau.at wrote:
You can disable UDP - that prevents from faked messages, but causes lots of interoperability problems.
Disabling UDP won't prevent faked messages. You don't have to inject the faked message into the same tcp connection (which would be difficult). You can open another tcp connection and send the faked BYE on it. There is nothing that would prevent this (and there are/were some UAs that opened a different tcp connection for each request).
Andrei
Ooops, sorry! I've mistaken something.
klaus
Andrei Pelinescu-Onciul wrote:
On Mar 30, 2004 at 10:55, Klaus Darilion klaus.mailinglists@pernau.at wrote:
You can disable UDP - that prevents from faked messages, but causes lots of interoperability problems.
Disabling UDP won't prevent faked messages. You don't have to inject the faked message into the same tcp connection (which would be difficult). You can open another tcp connection and send the faked BYE on it. There is nothing that would prevent this (and there are/were some UAs that opened a different tcp connection for each request).
Andrei
Andrei Pelinescu-Onciul wrote:
On Mar 30, 2004 at 10:55, Klaus Darilion klaus.mailinglists@pernau.at wrote:
You can disable UDP - that prevents from faked messages, but causes lots of interoperability problems.
Disabling UDP won't prevent faked messages. You don't have to inject the faked message into the same tcp connection (which would be difficult). You can open another tcp connection and send the faked BYE on it. There is nothing that would prevent this (and there are/were some UAs that opened a different tcp connection for each request).
Actually the problem is not only with BYE. If you can sniff SIP flow between two UAs (it is necessary to extract proper sequence number, call-id and tags), then you can inject false replies into any transaction in progress. For example by sending such final negative reply to an INVITE you can abort the call in the very beginning, by sending 302 you can divert caller to another person without him even noticing, etc. And while theoretically you can authenticate BYEs if UA/proxy support that, there is no way to authenticate replies at all.
Therefore, the only way to secure SIP signaling from eavesdropper is to use some form of TLS security, that is to encrypt all SIP flow between UA and proxy, so that there is no way to extract information necessary for constructing fake requests and replies without breaking underlying encryption algorithm.
-Maxim
-
Andrei Pelinescu-Onciul -
Juha Heinanen -
Klaus Darilion -
Maxim Sobolev -
Ticknor.Scott＠ic.gc.ca