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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2011/10/26 Olle E. Johansson oej@edvina.net:
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.
-
Alfred E. Heggestad -
Iñaki Baz Castillo -
Olle E. Johansson