Are you attending Black Hat next week in Las Vegas (July 29-Aug 2)? Or the Defcon show that follows? If so, would you be willing to provide a report (either audio or written) for us to include in a future Blue Box podcast (or potentially post on the VOIPSA blog)? Neither Jonathan nor I (nor Martyn) are going to be attending Black Hat or Defcon but there do look to be a number of quite interesting talks involving VoIP security. If you would be willing to send in a report from Black Hat or Defcon just briefly talking about what is discussed at the sessions there, please do drop us an email as we’d love to have such contributions.
FYI, if you want to try audio, contributions could be either: 1) recorded using something like Audacity and then sent by email; or 2) simply called into our comment line (+1-206-350-2583 or sip:email@example.com).
Over on the Blue Box site, I just posted about two VoIP security presentations that are now available with the audio synchronized with slides courtesy of a new “slidecasting” interface created by SlideShare.net. The two presentations are:
- the 15-minute “story” I did of “SysAdmin Steve” and the troubles he face (audio was first available as Blue Box SE#15)
- the 90-minute workshop that Jonathan, Shawn and I did covering VoIP security threats, tools, best practices and more (audio was first available as Blue Box SE#16)
I’m intrigued by the slidecasting interface because to me it allows people who could not attend to experience the presentation in a manner close to what attendees saw. Anyway, any feedback you all have would be welcome.
Last week the folks at Digium released 4 security advisories on their www.asterisk.org/security web site. They are:
There are fixes for all the issues (basically, to upgrade to the current release of the Asterisk stream you are using) and if you are using Asterisk (or a derivative of Asterisk) we would encourage you to read these advisories and take the recommended actions.
On a side note, it’s definitely been great to see the changes Digium has brought to reporting security issues with Asterisk. First was the security portal at www.asterisk.org/security and then starting in April were these well done security advisory documents. Kudos to Kevin Fleming and the rest of the developer team there. (Thanks also to Kevin for starting to post these advisories to the VOIPSEC mailing list.)
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.
Blue Box Special Edition #18 is now available for download. This episode features Martyn Davies interviewing first Rod Hodgman from Covergence and then Jeff Carr from Borderware about the role of the Session Border Controller (SBC). In each interview, he discusses the company, their products, the role of SBCs and poses the question “Do SBCs break SIP?” Each of the interviewees also discussed a user of their products and provides other information about their company. More information and pictures are available in the episode show notes.
Technorati tags: voip
, voip security
, blue box
, martyn davies
, jeff carr
, rod hodgman
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
We were contacted today by Takehiro Takahashi, a graduate research student at the Georgia Institute of Technology, who has an intriguing new research project they called “Voice over VoIP”. From their main web page:
Vo2IP is a proof of concept attack which demonstrates a new type of VoIP threats, the VoIP covert channel. With Vo2IP, you can establish a hidden conversation by embedding further compressed voice data into regular PCM-based voice traffic (i.e. G.711 codec). Therefore anyone who is wire-tapping your conversation will decode something completely different from the actual conversation – granted that he is not aware of the use of Vo2IP.
As I understand it, they basically take a G.729 audio stream and tuck that into a spare 8Kbps that can be found in a G.711 audio stream. An eavesdropping attacker would hear only the overall G.711 audio while the Vo2IP clients on either end encoded/decoded the covert stream (more details here and here). In any event, Takehiro and his fellow researchers would be very interested in any feedback folks have on the project. Source and binary code for Windows is available. Please email Takehiro with any feedback.
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.