The big news circulating through the Internet right now related to Skype is that someone may have reverse-engineered part of Skype’s encryption. Two posts of note:
The comments on the TechCrunch article are particularly worth reading as a number of security-related folks have jumped into the debate – and the author of the reverse-engineered code has jumped in as well (or someone claiming to be him, anyway).
People have been trying to reverse-engineer Skype’s proprietary encryption algorithm’s for years… and there have been various presentations at conferences and much data out there. In this case now, a developer named Sean O’Neil has made code available that apparently will decrypt one layer of Skype’s encryption.
Now, the code does NOT give you access to actual Skype messages. O’Neil writes in the TechCrunch comments:
Decryption of the RC4 layer gives nothing other than the ability to check CRC-32 of the packets, mere detection of random-looking encrypted packets as Skype. Maybe some firewalls will be able to block it at last.
I interpret that to mean that this code could help differentiate Skype traffic from other network traffic. The value there is really only, as the author says, that tools could be able to block Skype traffic because it could be more easily identified.
O’Neil goes on to say he has reverse-engineered more of Skype’s protocols and will be laying it all out at the Chaos Communication Conference in Berlin in December. We’ll have to see what gets said then…
I am also seeing the term used to describe enterprise-directed DoS, where an attacker typically floods a contact center with calls. I have recently worked with both enterprises, service providers, and hosted IVR companies that have seen these attacks. The current motive seems to be traffic pumping/revenue generation, not DoS per se, but the side impact is that operation at the target sites is degraded or seriously disrupted, depending on call volume and trunk capacity. Interestingly, the targets I have talked to are primarily using TDM trunks, while the attackers (according to the service providers I have talked to) are using VoIP. I have a post on my blog with more information:
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.
The big news circulating through the Internet right now related to Skype is that someone may have reverse-engineered part of Skype’s encryption. Two posts of note:
