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.