Skype is certainly taking some punishment recently. Today the news broke that someone has let loose a worm that uses the Skype API to send a chat message to your Skype contacts. The chat message includes a link which (if the user clicks on it) will download the w32/Ramex.A virus, which in turn infects their PC, and will visit their Skype friends. Obviously, this is a big concern for anyone with a user base as large as Skype’s, since even a small percentage of users that click on the link can cause wide distribution.
More: Skype Blog
Just to show that VoIP security is not all about SIP, researchers Himanshu Dwivedi and Zane Lackey from iSEC Partners have produced some interesting material on vulnerabilities in IAX, which they just presented at the recent Black Hat conference. IAX (pronounced eeks) as you may know, is a proprietary protocol often used to connect together Asterisk servers for the purposes of call routing. Implementors say that it is simpler than SIP, and also tunnels through firewalls better than SIP, thanks to a ‘VPN like’ approach that tunnels signalling and media together down the same pipe.
iSEC came up with a number of novel attacks including exploiting authentication problems with the use of MD5 hashes; man-in-the-middle and DoS. They have a very nice paper here that describes their attacks in detail, and they have also made available some code (in Python) that you can use for your own experimentation.
Not stopping at IAX, they also had a go at the granddaddy of VoIP protocols, H.323, and have published a couple of attack tools there too. It’s enough to keep you busy all Summer long.
More: Black Hat USA 2007 abstracts
Day two opens with a keynote from Jonathan Rosenberg, one of Henning Schulzrinne’s early collaborators on SIP. Rosenberg went on from Columbia University to Dynamicsoft, later Cisco Systems where he is now a Fellow. Rosenberg is still active in IETF work related to SIP, and was principal author of NAT traversal techniques, STUN and ICE.
Rosenberg touched on many topics in his presentation on the challenges for IP telephony, but of course one of the challenges he talked about was SPIT or voice SPAM. He said that one basic decision point is whether you know the caller or not. As long as we have strong identity on VoIP networks, it’s possible to keep a white list of permitted callers. Then the problem becomes how to enroll people on to that list in the first place.
Safely letting in people that you don’t know opens the field to a whole range of different techniques. Some that he mentioned include: consent and reputation systems; CAPTCHAs; computational puzzles and payments at risk. Some of these he outlined as more promising than others, but the point is that this problem is not solved yet, and in fact is an ongoing discussion in the IETF and elsewhere.
Day one of IPTComm brings a whole raft of VoIP Security topics: Saverio Niccolini of NEC Philips spoke about a holistic approach to VoIP intrusion detection and prevention, including the use of a “honeypot” to draw attacks away from the true telephony service to a dummy that can help in analsysis of attacks. Jens Fiedler of Fraunhofer Fokus spoke about VoIP Defender, a prototype system that allows the dynamic analysis of SIP traffic, with realtime generation of filter rules, then applied back to the signalling traffic. Ali Fessi (Univ. of Tuebingen) spoke about CoSIP, and attempt to marry traditional SIP servers with a P2P SIP approach, with the aim of improving resilience to system failures or DoS attack. Humberto Abdelnur (INRIA) described Kiph, a stateful SIP fuzzer. Rather then the approach taken by the PROTOS toolset, KIF is SIP-specific, and understands not just the grammar, but also to some extent the context and behaviour of SIP, in order to better test for vulnerabilities in SIP-based products. Finally Ge Zhang (Fraunhofer FOKUS) spoke about DoS attacks to VoIP, based on attacks to the DNS server, which of course the SIP Proxy depends upon for its function. He also described some limited defences against this threat.
Interestingly, Henning Schulzrinne told us in his opening remarks that our host, Columbia University NY, recently experienced its own SPIT (Internet Telephony SPAM) attack, with someone accessing the Proxy, and “war dialling” a lot of IP phone extensions. There have been few real-life examples of this so far, but you can see that large IP communities, like universities, are likely to attract such attacks.
Reading recently about Snom releasing a new phone with IPSec VPN capabilities started me thinking about the incredible processing power that embedded devices have these days. It wasn’t so many years ago that IP phones couldn’t offer encryption due to the high CPU demands, but as each passing month goes by, the clock rates go up, new CPUs come out, while the prices go down. Nokia advertised their new N95 smartphone recently, proclaiming that this is “what the computer has become”, and this is actually true. The navigation computer on the Apollo moon missions had to be loaded and reloaded several times during the trip, as it only had an 8k memory to store navigation programs in. Famously, their computer crashed several times on the first moon landing, due to data overload from the radar telemetry. Those guys would have been happy to have a modern PDA on board, with thousands of times more power than their humble machine.
Since these phones have more power, we expect the devices to do much, much more, and the devices can suffer from feature-itis, where all kinds of bells and whistles are added, not because they are needed, but because we can do it, and cheaply. So far from getting a device that is “just a phone”, we get all kinds of extraneous features, many of which have security implications, and in fact vulnerabilities. Ask the average cellphone user, and you will probably find that they only know about 5% of the functions available to them, and they probably didn’t even read the (usually thin) handbook that came with it. This is also true for VoIP phones, which normally come packed with other non-VoIP services like TFTP, FTP, LAN capture, embedded web server, network time service, and so on. A lot of these features can be exploited when passwords are left at factory default, which they commonly are.
If we are going to make all the phones into fully-functional computers, then from a security point of view we need to make sure that each device is properly audited, and hardened, and patch-managed. Many enterprises are not yet ready for what the computer has become.
Back to telephony SPAM or SPIT again. Hannes Tschofenig noted on his blog the publication of an RFC draft on the use of CAPTCHAs in SIP.
For the uninitiated, CAPTCHA means “Completely Automated Public Turing Test to Tell Computers and Humans Apart”, or in other words an automated test of your humanity. In the context SPAM over Internet Telephony, the aim is to tell genuine human callers from ‘bots’ or software that aims to make our phones ring and play unwanted marketing messages at us.
Some of the choices are laid out there, for example a system (corporate PBX for example) could challenge an incoming call, by playing a sound, then asking you to describe the sound. Or in the case of a video call, show you a picture and ask you to describe it in words before connecting the call. A moment’s examination would allow a human to conclude “teapot”, where a computer looking at a cartoon or photo teapot would need to expend a lot of CPU to reach the same result.
Ok, you may say that computers are so smart now that they can recognize pictures, or do automatic speech recognition (speech to text) remarkably well. This is true, to a degree, but the fact is that clever CAPTHCAs will demand heavy processing on the attacker’s side, and this works against what they are trying to do. After all, they want to implement systems that can make thousands of calls per hour at low cost. If we increase the cost of the calls by adding a quarter of a second of CPU to each call, then we give the telephony spammers a capacity problem, and force them to spend much more on server machines. By making SPAM an economic problem once again, we can raise the barriers to entry.
The draft text can be found here, and Hannes’s blog is here.
Technorati Tags: SPIT, SPAM, CAPTCHA
At Spring VON Europe, Ari Takanen said something very interesting about security of legacy interfaces in the panel session on The Real Risks of VoIP Security. In the discussion of established phone networks versus VoIP or next generation networks, he pointed out that “some interfaces are not designed to be open”, and therefore these can be particularly vulnerable to attack if for some reason that interface does get revealed. Ari gave the example of MGCP, the protocol that allows control of media gateways used in the PSTN.
MGCP is a functional interface that allows an application, or controller, to remotely instruct a media gateway how to handle a call, for example play a tone or voice prompt, perhaps wait for DTMF input. MGCP is designed for a tight relationship between controller and media gateway, but in its very design it is assumed that both components are secure inside a carrier’s network, and so security of the interface is a secondary concern. This means that should an ‘evil’ application get access to the MGCP interface, it can perform DoS attacks and other mayhem, and disrupt the operation of essential services, for example IVRs and prepay services.
As we transition from legacy PSTN (SS7) networks to NGN, there are going to be some shocks along the way. PSTN networks are closed today, with all the signalling hidden behind borders that potential hackers have no access too. However, as tools like SIGTRAN make telcos more-and-more embrace the TCP/IP world, all sorts of interfaces that should be concealed will from time-to-time offer new opportunities for hackers to try. We don’t have to switch the whole system over to SIP before enhanced security for telephony should be on the agenda.
One aspect of VoIP security that keeps coming to my attention in recent weeks is that of location privacy, or in other words, does the call recipient (or others â€˜listening on the lineâ€™) know where you are?
At a VON Europe panel this week, Cullen Jennings, Distinguished Engineer at Cisco, was talking about peer-to-peer (P2P) SIP, and how the P2P approach definitely helps with location privacy. He gave the example of emergency procedures in the USA, which require the countryâ€™s President and Vice President to be in different physical locations from each other yet still be able to communicate. At the same time, they must prevent eavesdropping enemies from locating the Vice President physically.
I said that â€˜P2P helpsâ€™, but perhaps I should say â€˜can helpâ€™, with the right systems in place. In the UK last week, Sky News ran a story about how criminals might use encrypted VoIP to run circles around the police, due to the difficulty of tapping and listening to the calls. I hope to be able to write in more detail in the next few weeks why this is basically untrue, but the information I have received is that the VoIP providers “can be very helpful” to the police in these cases. Even if a VoIP stream cannot be decrypted, it is often possible to obtain a list of times, durations, and IP addresses that can easily provide both location and evidence. Also, if a VoIP call breaks out onto the PSTN, a service offered by many or most VoIP telcos, then once again you have a location (albeit the call destination rather than the source), and you have the opportunity to monitor the call.
No-one likes to think that all their calls are being tracked, or that their location is known at all times, but of course in democratic countries we assume that there are enough checks and balances to ensure that this information is available to few and will not be abused. At the same time, criminals and terrorists should not assume that new technologies like VoIP and IM give them a cloak of anonymity, because this is definitely not the case.
Today at Spring VON Europe in Stockholm, one of the panel sessions covered the issue of the proliferation of codecs, both for video and voice.Â Industy veteran Henry Sinnreich of Adobe rasied an interesting topic for the panel regarding compromised or evil codecs.Â An evil codec could provide a stream of audio designed in such a way to crash or destabilize an endpoint, with the aim of putting the endpoint in a mode where the conversation could then be monitored.Â Some researchers have already shown that such attacks are in principle possible.
So the question is what to do about this, and how to test systems to prevent this kind of attack?Â There were no real answers were forthcoming today, butÂ I shall certainly revisit the topic in my panel session tomorrow, Â The Real Risks of VoIP Security, and see if my experts fare better.
From my own point of view, I think it could be a nightmare to have to scan every RTP stream in real time for ‘evil’ signatures, much like in email scanners.Â The CPU required to do this for all audio could be disabling.Â If the codec software can be ‘hardened’ and made robust enough to withstand such an attack, this would seem a better solution.
The papers are in and theÂ conference agenda is now published.
There’s plenty of meat here for those interested in VoIP Security, with Â talks on intrustion detection and prevention, SIPÂ security architecture, SIP fuzzing and DoS prevention.Â Jeff Pulver will deliver the keynote, and many of the speakers are the same people that create such interesting discussion trails on the Voipsec list anchored on this site.
If you’re in New York Â July 19th/20th, it’s going to be a great session.Â Registration is open here.