Telecom Junkies podcast: Interview with a VoIP Hacker (Robert Moore of the Pena/Moore voip fraud case)

imageRemember the Pena/Moore voip fraud case back in June 2006? Would you like to know how the attacks were done?  And how you can protect your network?

First, for those who don’t recall, this was a case where Edwin Pena was alleged to have set himself up as a voice service provider and then, with the assistance of a developer named Robert Moore, routed his customer’s calls across the networks of other VoIP service providers.  Pena is alleged to have stolen at least 10 million minutes from other voice service providers and made in excess of $1 million dollars. Pena subsequently fled the country (and remains even today a fugitive).  We wrote about it here and also covered it in Blue Box podcasts #31 and #33 and I was a guest on a Telecom Junkies podcast back in July 2006 discussing the case.

In any event, one year later Robert Moore has been convicted for his part in the scheme and on July 24th was sentenced to a two-year term in prison, 3 years probation and a $150+K fine.  

Before he reports to prison in about 6 weeks, though, Moore got in contact with Jason Huffman from The Voice Report to ask if Jason was interested in an interview.  Given my prior involvement with the Telecom Junkies podcast, Jason contacted me to see if I would also be interested in coming onto the show.  Both he and I were concerned about interviewing someone recently convicted (i.e. not wanting to glorify the crime or criminal), but I shared Jason’s view that if we could obtain information about how the attacks were done we could potentially help people protect their systems against these type of attacks.  (Jonathan was also invited and provided great feedback but was unable to attend due to scheduling issues.)

The result is a new Telecom Junkies podcast: “Interview with a VoIP Hacker” which is available for download.

As we’d discussed in our previous coverage of the case, there were really two different types of systems that were attacked:

  1. Voice gateways of VoIP service providers
  2. Servers/routers of other businesses that were compromised to hide the source of traffic going to the voice gateways

In the interview, Robert Moore confirms that all the voice gateway attacks were H.323 (no SIP was involved) and they weren’t terribly sophisticated because the VoIP service providers didn’t have all that much security in place.

Moore also indicates that all the other boxes (#2) were compromised primarily by easy means such as weak and easily guessable passwords – or even worse, unchanged default passwords.  In some cases, there were boxes on the Internet with exposed SNMP ports that then let the attackers learn all about the box so that they could then research potential vulnerabilities.  This part really had nothing whatsoever to do with VoIP but instead with really just basic IT security practices which were (and undoubtedly still are) very obviously not being followed by many folks out there. 

In any event, the interview is now available for listening.  Meanwhile, Moore is soon heading off to prison and Pena is still somewhere out there…

P.S. If anyone listening can identify the name of the second switch vendor that Moore indicates he went after, neither Jason nor I could identify it despite my request for the name to be repeated.

UPDATE: Thank you to all who responded. The other switch was a Quintum Tenor – http://www.quintum.com/

Anyone attending Black Hat or Defcon interested in providing reports into the Blue Box podcast?

imageAre 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:bluebox@voipuser.org).

Technorati tags: , ,

BlueBox podcasts of ETel "Black Bag Security Review" presentations now available with audio synced to slides

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.

Four Asterisk security vulnerabilities released

image 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.)

IPTComm 2007, Day Two

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.

IPTComm 2007, Day One

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.

It’s What the Computer Has Become

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 – Session Border Controllers (SBCs) Special – Interviews with Covergence and Borderware about the role of the SBC

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.

Now I’ve CAPTCHA’d Your Attention

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: , ,

"Voice over VoIP" project aims to show use of "covert channels" to tunnel voice inside of voice

image 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.