A SIP scanner is a tool that scans a VOIP/Video network from the Internet side with the intent of “breaking in” and using the network to place voice/video calls. Today, toll avoidance and toll fraud appear to be the primary motivation (rather than SPIT) – however, one thing is clear: the number of SIP scanner attacks is on the increase. Whilst the attacks that have reached my network appear mostly to be targetted against badly configured Asterix IP telephony solutions (left with default settings), Cisco/Tandberg VCS Expressway video solutions could be every bit as vulnerable unless correctly configured. These attacks should be of special concern if you have any PSTN/ISDN gateways, SIP ATAs or SIP trunks in use in your deployment. A typical attack appears to be to attempt to place a VOIP call through your gateway to get a free call (toll avoidance). A refinement of this attack used by organised crime is, instead, to attempt to place a calls to a premium rate international telephone number using your gateway – so you, the victim, get saddled with a huge telephone bill. And, of course, because the calls cross national boundaries this makes it all the harder to try and recoup your losses through legal means – few organisations have the wherewithal to mount an international lawsuit. Anatomy of a SIP scan attack: There seem to be a few different common attacks out there, as far as I have been able to tell. Each attack differs somewhat from the other, but there appears to be a number of commonalities which suggest that the same attack tool (or set of attack tools) may be being used by the different attackers. What should be done? There is always going to be a balance between the ability to freely communicate over the Internet using open standards – and the risk that those fraudsters and spammers who would abuse this pose to others. The only safe system is a closed system – but, honestly, how useful would any telephony system be if you had to pre-arrange some sort of bilateral trust relationship/federation with any domain you wanted to call or be called by? Not very useful; not very scalable – and an administrative nightmare. And what happens if one of your trusted partners’ networks gets compromised and used as a jump-off point for attacking your network? So, even this extreme approach isn’t very safe. The right thing to do (in my opinion) is to learn to live with the risk – and to take reasonable steps to protect your network from the fraudsters and spammers. Vigilance General good practice is to remain vigilant to what is happening on your network. In particular, check what calls are being attempted so you can spot any suspicious activity and adjust configuration (if need be) to protect against it. One way of doing this is to regularly review call logs and search logs from your VCS. When I reviewed my VCS logs the other week I was shocked to see hundreds of rogue call attempts (thankfully deflected by the VCS’s default configuration):
(note: IP addresses of my Expressway has been changed to 220.127.116.11 for reasons of privacy) I believe that the attackers have found my system by a simple IP address scan – looking for a system with SIP port 5060 “open”. Other possibilities include that they found the SRV records for my domain – but given that I have yet to receive an attack which includes my domain name, I’m reasonably confident that it’s the former. Attacks that my systems have received (so far) have tended to fall into one of the following categories:
- Exploration: a SIP “OPTIONS” request usually claiming to be from firstname.lastname@example.org dialing 100@my-ip-address. Presumably, a positive response to this will alert the attacker that they’ve found a certain popular telephony platform with a default dialplan present (and so perhaps being administered by a novice). This suggests a ripe target for attack.
- Direct attack a): a SIP “INVITE” request purporting to be from asterisk@<some ip address> to <somenumber>@my-ip-address
- Direct attack b): a SIP “INVITE” request purporting to be from unknown@<some ip address> to <somenumber>@my-ip-address
- Direct attack c): a SIP “INVITE” request purporting to be from 101@<some ip address> to <somenumber>@my-ip-address
- Direct attack d): a SIP “INVITE” request purporting to be from 100@<some ip address> to <somenumber>@my-ip-address – often a huge number of different variants of “somenumber” are used in an attempt to thwart any security-through-obscurity that local dial-plan conventions might be providing.
So, although there are some obvious patterns here, it’s going to be a never ending arms race to defend against these attackers. As soon as awareness is raised of each common attack, and defences against the common attacks are put in place, new attacks will be developed by the attackers. My observation of these attacks prompted me to decide to tighten up the default VCS configuration to provide extra layers of protection (even though, by luck, the attacks I received were harmlessly deflected by the default VCS configuration). I will discuss an iterative approach to tightening up VCS Expressway security in a future post. If you’re now panicking, and can’t wait until then, I suggest you investigate some of the VCS configuration advice to be found on the Cisco website and on messageboards.
Update: for up-to-date resources (2015) please take a look at purplescarab.com and sign up for the free newsletter!