Following up on a story we’ve literally been covering for years, SC Magazine reported last week that VoIP fraudster Edwin Pena was to be arrive back in the USA last Friday, October 16. The FBI news release indicates that Pena is to be arraigned today, October 23rd, in New Jersey.
Apparently there’s a new piece of malware floating around that targets audio processors like Skype:
The Trojan has the ability to record audio from the computer — including any Skype calls in progress — and store the files locally in an encrypted MP3 file, where they can later be transmitted to the attacker.
The Trojan, which Symantec calls Trojan.Peskyspy, can be downloaded to a computer by tricking the user with an email scam or other social engineering tactic, Symantec says. Once a machine has been compromised, the threat can exploit an application that handles audio processing within a computer and save the call data as an MP3 file.
Can Asterisk really be used to “unmask”blocked Caller-ID and show the private number?
Well, yes… but it really has less to do with Asterisk then it does with not respecting the signaling sent to you by a SIP trunking provider. It’s conceivable that any IP-PBX could be configured to allow you to do this… and points to a larger issue with trust boundaries between SIP Service Providers (a.k.a. Internet Telephony Service Providers or ITSPs) and their customers.
THE “HACK”
Let’s take a step back first and explain… over the weekend FierceVoIP ran a piece about VoIP security talks at the “Last Hope” conference that referenced a demonstration by Kevin Mitnick of how you could use Asterisk to show Caller ID information for someone calling even if the caller’s ID is set to “private”. Someone (”phant0msignal”) recorded a video of the demonstration (and yes, if you listen, the audio cuts in and out) and posted the video to YouTube and the code to his blog. This might have gone somewhat unnoticed except that it got picked up by Engadget, which naturally garnered a good bit of attention. Here’s the video:
THE EXPLANATION
So was this really a big “hack” that exposed private information?
Not really… although it may be a clever use of scripting within Asterisk.
Here’s the thing:
Asterisk received this information as a natural part of SIP communication because the SIP Service Provider TRUSTED Asterisk to “do the right thing” and NOT display the information.
Which, normally, would be the case. Asterisk would respect the SIP privacy headers and not display the Caller ID. However, in this case Asterisk was modified to NOT respect the privacy headers and display the information that was requested to be private.
To understand this, we need to look at one of the ways that “Caller ID” is usually handled within the world of SIP communication. RFC 3325 defines a SIP header called “P-Asserted-Identity” that is inserted typically by the first SIP proxy that is interacting with the SIP endpoint. The result, within a trusted administrative domain, is the inclusion of one or more headers that look like:
The P-Asserted-Identity header, often referred to as P-A-I for short, includes this identity information that can be used by the proxy for the recipient of the call to display “Caller ID” on the recipient’s SIP endpoint (phone, softphone, etc.).
Now, when a call is to be private, there is an additional SIP header included. RFC 3323 defines the “Privacy” SIP header and section 9.3 of RFC 3325 adds an “id” value to the Privacy header. So the resulting SIP headers look like:
P-Asserted-Identity: "Dan York" <sip:dyork@example.com>
P-Asserted-Identity: tel:+14155551212
Privacy: id
Per RFC 3325 Section 7, this Privacy header indicates to the SIP proxy that the P-A-I information MUST be stripped off before the SIP headers are sent to an “untrusted” entity. From the RFC:
Parties who wish to request the removal of P-Asserted-Identity header
fields before they are transmitted to an element that is not trusted
may add the “id” privacy token defined in this document to the
Privacy header field. The Privacy header field is defined in [6].
If this token is present, proxies MUST remove all the P-Asserted-
Identity header fields before forwarding messages to elements that
are not trusted.
So the “hack” in this case was that Asterisk’s SIP handling was modified to NOT respect the Privacy header and instead pass along the P-A-I information to, in this case, the endpoint.
THE LARGER PROBLEM
The larger problem/issue is really this:
Why did the SIP Service Provider send the P-A-I information down to Asterisk box in the first place?
The answer, of course, is simply this:
The SIP Service Provider assumed that it could trust the SIP server with which it was communicating.
The Service Provider extended its “trust boundary” out to encompass the SIP network of its customers. As far as the Service Provider was concerned, the customer was just another SIP network and should be trusted. The Service Provider did not apparently care whether the customer was another carrier – or just someone running Asterisk on a home system. They were simply glad to provide connectivity to the customer.
The problem is:
The trust boundary of the PSTN was then extended out to the customer system.
and there was an implicit assumption that PSTN privacy requests would be respected.
NO EASY ANSWERS
One obvious reaction is “So the Service Provider shouldn’t send that information to the customer’s SIP server!” Perhaps. Perhaps the Service Provider should not trust any of its customers with that information. (And I Am Not A Lawyer so I don’t know if in this case there are actual legal issues here.)
But I’m not sure it’s that simple.
You see, there’s a bit of a “Wild West” going on right now in the world of SIP trunking. Basically, anyone and their brother, mother, father, sister (and…) can get into the world of providing SIP trunks simply by setting up a SIP server (which could be done with Asterisk) and buying some upstream SIP connectivity from a larger SIP Service Provider… ta da… “ZZZZZ VoIP Services” is born. Simple. Easy.
If you are a larger SIP Service Provider, you will sell to smaller Service Providers and naturally extend your “trust boundary” to them. They will sell to others… and so on… and so on… until some final system is connected to some endpoints.
SIP clouds connected to SIP clouds connected to more SIP clouds.
Where do you appropriately define the “trust boundary”? Is it perhaps the “top tier” SIP Service Providers? Is it “the carriers who run the PSTN”? Should it have been stripped off at a gateway coming in from the PSTN?
We’re building this massive “interconnect” of SIP clouds… and this is just one of the many issues that it is not entirely clear that we have a consensus on. Sure, RFC 3325 defines what should happen on a technical level… but what about on a policy level? Who gets to be part of the “trusted” community? (FYI, I would strongly recommend reading RFC 3325 for a better understanding of the issue.)
In the meantime, it’s fairly safe to assume that if you are “blocking” your Caller ID, there is no actual guarantee that it won’t be seen by the recipient. In the vast majority of cases, sure, that privacy will be respected. But there’s no guarantee.
Welcome to new world of VoIP…
P.S. And yes, if you were reading this and thinking “Gee, so can’t the ‘Caller-ID’ be easily spoofed just by modifying the SIP headers?” you are absolutely right. That’s why there’s a good amount of work going on right now in the IETF around the whole area of “strong identity”… but that’s a topic for another blog post some time…
Some researchers over at Johns Hopkins University have discovered that due to the way Variable Bitrate Compression does it’s thing, even if the audio stream is encrypted it is still possible to determine entire words and phrases based on the lengths of the packets with a high degree of accuracy.
According to the article referenced above it appears that the proof of concept tool is fairly limited, but given a little time and additional effort it’s capabilities could be greatly expanded, potentially to the point of transcribing entire conversations.
On April 1st VuNet reported that hackers had taken down the International Space Station’s email capabilities.
So, this was a good April Fool’s joke, right?
Three astronauts onboard the Space Station reported last night that email was no longer working.
Hackers are thought to have planted a Trojan in the computer systems at Houston and used the infection to ride the satellite uplink to the Space Station.
What is especially troubling is the email system’s reliance upon older Microsoft operating systems that are no longer supported by Microsoft.
“I am sorry but there is nothing we can do. It is past its deadline, said Professor Brian Offin, Microsoft’s head of obsolete operating systems.
Again, a good April Fool’s joke, right?
However, this false article brings to light the fact that as newer technologies replace legacy systems, we must bear in mind that the new technology changes will, over time, themselves become legacy systems and subject to the same outdated, unsupported and insecurities that plagued the very legacy systems they replaced.
So what’s this have to do with VoIP and the International Space Station? Well, details are thin, but way back in 2000 VoIP Group Inc. was awarded a contract to provide a VoIP replacement for the ISS to “bring about significant cost reductions as it supplements and then replaces an existing legacy system.”
Initially deployed at NASA’s Marshall Space Flight Center in Huntsville, Alabama, and later at other International Space Station operations centers, the solution will consist of VoIP Group’s gateways connected to the Internet and to Raytheon voice switches and CUseeMe conference servers to support voice conferencing. The system is designed to link together researchers, NASA operations personnel, and potentially ISS crew, to support collaboration during Space Station experiment planning and operations. Because users can access the system using a standard Internet browser on an inexpensive multimedia PC, they can be located at NASA centers, universities, and companies throughout the world, and still connect in real-time, 24 x 7.
I hope that the sharp folks at NASA and VoIPgroup are taking the proactive steps to avoid security problems with critical communications with the ISS.
Some time back we reported here about the Pena/Moore case, where a duo stole VoIP services and then sold them on to third parties, who thought they were buying a legitimate service. Pena went on the run, and I believe is still missing. The techie of the duo, Robert Moore is now off to prison. Information Week have an interview with him here.
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.
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.
Remember 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.)
As we’d discussed in our previous coverage of the case, there were really two different types of systems that were attacked:
Voice gateways of VoIP service providers
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.
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/
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.
