29 Mar
2004
29 Mar
'04
11:17 p.m.
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
30 Mar
30 Mar
7:58 a.m.
Ticknor.Scott(a)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
10:55 a.m.
You can disable UDP - that prevents from faked messages, but causes lots
of interoperability problems.
klaus
Ticknor.Scott(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:02 p.m.
On Mar 30, 2004 at 10:55, Klaus Darilion <klaus.mailinglists(a)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
12:57 p.m.
Ooops, sorry! I've mistaken something.
klaus
Andrei Pelinescu-Onciul wrote:
On Mar 30, 2004 at 10:55, Klaus Darilion
<klaus.mailinglists(a)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
1:28 p.m.
Andrei Pelinescu-Onciul wrote:
On Mar 30, 2004 at 10:55, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
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
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).
7340
days inactive
7341
days old
5 comments
5 participants
participants (5)
-
Andrei Pelinescu-Onciul -
Juha Heinanen -
Klaus Darilion -
Maxim Sobolev -
Ticknor.Scott＠ic.gc.ca