$words[rand()]

Sjur Usken and San­dro Gauci have dis­cov­ered a major flaw in the SIP imple­men­ta­tions on a wide range of IP phones. The short expla­na­tion is that the phones do not ver­ify where a proxy authen­ti­ca­tion request is com­ing from and hap­pily return the SIP authen­ti­ca­tion infor­ma­tion. It is hashed and salted, but the salt is cho­sen by the attacker, so a set of rain­bow tables would make crack­ing it triv­ial. For full details, check out Sjur’s blog post (which spread fairly rapidly around the VoIP world) and his lat­est post show­ing the trace as he attacked a Cisco 7940 I set up for this purpose.

Until the phone ven­dors release fixed firmware (if they do) the only way to defend your­self from this is to not have phones exposed on pub­lic IP addresses. If they have to be for some rea­son (we all know SIP and NAT really don’t get along, and proper SIP aware NAT devices cost a fair bit) set fire­wall rules that pre­vent the phones from speak­ing SIP to any IPs that aren’t part of your VoIP sys­tem. Alter­na­tively, in the event that every sin­gle phone on your sys­tem is sta­t­i­cally addressed, the reverse could be done at the reg­is­trar side. It wouldn’t stop the attack­ers from find­ing the pass­word, but it would pre­vent them from using it in any way.

The impli­ca­tions of an attacker gain­ing the SIP authen­ti­ca­tion infor­ma­tion are of course severe, once they have that they can imi­tate the attacked phone and make calls to any num­ber of regions poten­tially cost­ing thou­sands of dol­lars in the course of a sin­gle night.