26 Oct
2011
26 Oct
'11
11:22 a.m.
Hello!
Today at SIPit 29 we successfully tested the kamailio auth_identity module that implements
RFC 4474.
We could successfully add SIP identity headers and verify incoming headers from one other
implementation.
Now, the module is not built for scalability and redundance. A lot of stuff is cached in
RAM, like certificates - which could lead to an DOS attack vector. It doesn't make it
simple either when you have multiple servers for one domain. Maybe a memcached backend
could help.
We will also try to look for other attack vectors, like sending bad HTTPS URL's.
Regardless, this was the first time I got SIP identity working and the others are
struggling with their code to get their end working :-)
Kamailio rocks.
/O
26 Oct
26 Oct
11:32 a.m.
Well Done, Olle :)
/alfred
On 26/10/11 17:22, Olle E. Johansson wrote:
Hello!
Today at SIPit 29 we successfully tested the kamailio auth_identity module that
implements RFC 4474.
We could successfully add SIP identity headers and verify incoming headers from one other
implementation.
Now, the module is not built for scalability and redundance. A lot of stuff is cached in
RAM, like certificates - which could lead to an DOS attack vector. It doesn't make it
simple either when you have multiple servers for one domain. Maybe a memcached backend
could help.
We will also try to look for other attack vectors, like sending bad HTTPS URL's.
Regardless, this was the first time I got SIP identity working and the others are
struggling with their code to get their end working :-)
Kamailio rocks.
/O
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
27 Oct
27 Oct
4:28 a.m.
2011/10/26 Olle E. Johansson <oej(a)edvina.net>et>:
Today at SIPit 29 we successfully tested the kamailio
auth_identity module that implements RFC 4474.
We could successfully add SIP identity headers and verify incoming headers from one other
implementation.
That's really good.
Now, the module is not built for scalability and
redundance. A lot of stuff is cached in RAM, like certificates - which could lead to an
DOS attack vector. It doesn't make it simple either when you have multiple servers for
one domain. Maybe a memcached backend could help.
We will also try to look for other attack vectors, like sending bad HTTPS URL's.
IMHO this is the main problem. I suspect nobody is using this module
in production (I mean with high traffic), as making Kamailio to block
is really easy for an attacker:
- Create a domain attacker-domain.info
- Make any subdomain *.attacker-domain.info point to 1.2.3.4.
- Send thousands of INVITE request to kamailio containing a random
Identity-Info header as follows:
Identity-Info: <http://RANDOM.atatcker-domain.info:RANDOM_PORT/aRANDOM.cer>
- The kamailio process receiving such INVITE would try to open a TCP
connection with the given random domain and random port. 1.2.3.4 does
not exist so TCP timeout will always occur.
- Let's assume that this TCP timeout is set to 1 seg. If Kamailio uses
10 workers and receives 10 hacked INVITE's per second, kamailio gets
totally blocked. Dead.
So this mechanism (or its implementations in Kamailio) is not safe
since it depends on the URL written by a possible attacker.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4824
days inactive
4825
days old
2 comments
3 participants
participants (3)
-
Alfred E. Heggestad -
Iñaki Baz Castillo -
Olle E. Johansson