Oops. To make a long story short, the “voipsa.org” domain was set to auto-renew on a credit card that was cancelled between renewals – and email notifications went to an incorrect address. It’s all better now. Life is good…
Sorry about that – and thanks to the multiple people who pinged us about it!
I don’t travel nearly as as much as I used to, yet when I do I always keep a sharp eye out for the technical glitches in devices around me in travel environments. What can I say? It provides me endless amusement.
While Linux boxes crashing in airlines’ on-board entertainment systems are nothing new, and several photos exist on the Internet depicting these crashes, I’m seeing something different these days…
On my way back from ph-neutral security conference in Berlin, I took a Continental 757 back to the US and observed the passenger entertainment system headrest in the row in front of me was frozen on the the movie selection GUI. The passenger in that seat asked the flight attendant to fix the problem and the headrest PC was rebooted from somewhere up front.
So, the funny (and a bit scary perhaps) bit is the screenshot I took of the reboot process. You can see the very high resolution photo here: http://tinyurl.com/linuxonplane
Observations from the linux crash on a plane photo:
1. 172.17.X.X private IP address range
2. FTP server IP address and transfer of system log tarball to the FTP server…user is “xxxxx” — imagine what the password might be…
Some reasonable concerns:
1. Tilting up the headrest PC and peeking behind it I saw CAT-5 cable. With a small tool or hands, and big cajones, an attacker *could possibly* unplug that cable and attach it to a laptop and hop onto the entertainment network. In addition, with some imagination and the right tools, an attacker could feasibly take over some or all aspects of the headrest PCs, including perhaps the sniffing of credit cards used by patrons, or even adding some specialized content…
2. This aircraft did not have on-board wireless Internet access, but I suspect that some airlines offering this service could have network crossover connectivity to different subnets, or perhaps only relying on VLANs for separation.
In the end, we can only hope that of the several networks likely running on a modern passenger jet, that true air-gapping is taking place and these systems are in no way connected to critical on-board networks. Time will tell if this is indeed the case. In the meantime, keep an eye out for those Linux boxes crashing on planes!
As some readers may already know, Syngress has now published a book I wrote, “Seven Deadliest Unified Communications Attacks” that dives into the threats to communications systems and the strategies to protect your systems. It is part of a series of “Seven Deadliest <topic> Attacks” books that have come out over the past couple of months. (And yes, there are seven books in the series.)
As I explained in this video, my intent was not so much to write a book about “VoIP security” but rather to take a look at a slightly larger level at the overall systems that we are connecting together under the name of “unified communications”. When we have voice, video, instant messaging, presence… coming from multiple different systems and then distributed over the global IP network… how do you secure it all?
The book was really my attempt to put in print form many of the themes we have written about on this site, talked about on the Blue Box Podcast and discussed in the VOIPSEC mailing list.
I do want to thank a couple of people in the VOIPSA circles… as I noted in the Acknowledgements, Dustin D. Trammell was an outstanding technical editor – and Andy Zmolek provided some excellent comments and thoughts. Longtime friend and VOIPSA blog contributor Martyn Davies had some helpful feedback, too, as did Scott Beer over at Ingate Systems.
Anyway, the book is out there… and I’ve put up a companion web site at www.7ducattacks.com where I’ll be listing additional resources, errata, updates, etc. There is also a Facebook page for the book. Feedback is definitely welcome (and yeah, I wouldn’t be opposed if you bought a copy or two 😉 ). I’m doing some interviews and podcasts about the book… if you are interested in interviewing me for your site or show, please contact me.
My hope with the book is that in some small way it can help encourage and spread the discussions we all have been having here… and in the end help our communications systems be a bit more secure. Thanks to all of you who have been reading posts here, commenting on them, participating in VOIPSEC and asking great questions.
P.S. If you are available tomorrow, Friday, May 20th, at 1pm US Eastern time, I’ll be interviewed live on the VoIP Users Conference call. Anyone is welcome to join in, listen, and ask questions.
The security weaknesses of VLANs have been known for years. Recent case studies have highlighted the potential risk of using Voice VLANs together with VoIP in an infrastructure absent of properly configured security controls. While visiting Europe just recently, I was reminded of this issue for a couple of reasons.
The British Crown Jewels
Firstly, I saw the magnificent British Crown Jewels in display. They are quite impressive. They are arguably the most valuable items in the world possessed by a sovereign state, and obviously need to be properly protected. It really got me thinking about the origin of the term “Crown Jewels” and how the industry has used this term to refer to protection of a company’s most valuable and precious IT assets and data. We talk about protecting against the theft of these “Crown Jewels” – a company’s IP, trade secrets, or other mission critical data. How to protect and defend the “Crown Jewels”?
Theft of the Crown Jewels!
Hotel VoIP Deployments
After seeing the Cullinan I diamond and other precious jewels, I stayed in a hotel in Stockholm that had IP Phones deployed in guest rooms, which had me thinking again about how attackers could access a company’s IT “Jewels” from a physically unsecured area. A quick and passive view of the IP Phone network configuration showed that this network was most likely vulnerable to the aforementioned VLAN Hop vulnerability. I’ve been seeing an increasing amount of Hotel VoIP deployments in the last year exactly like this.
Both of these items reminded me of how easy it is for a would-be attacker, sitting in the comfort and privacy of their hotel room, to steal a company’s most valuable trade secrets and data through VoIP, in the right scenario and when the environment is not properly protected. We’ve seen this before in production environments, in authorized security assessments. I wanted to reach out to the community and share this with you, and see what others are seeing as well. I’ve roughly seen 1 in 3 hotels in the past year have VoIP deployed in the guest rooms. I am curious as to whether others are seeing a similar trend. What other UC business applications are you seeing deployed in physically remote areas, and how are they being used?
Trunking VoIP to Physically Isolated Areas
When VoIP networks are propagated through trunk ports to physically isolated remote locations that are still under the administrative domain of the same organization, the risk increases that a VLAN Hop into the Voice VLAN can result in unauthorized access to corporate network resources. Resources that were not intended by the system designers. I’m making generalizations because every network is different. But the most common configuration I am seeing takes place because the IP Phones normally need a range of TCP/UCP ports open into the call servers, and the call servers are centrally hosted on the corporate data network. Sometimes the firewall doesn’t properly implement the policy of least privilege for only permitting operational IP Phone traffic and denying all other traffic. The best example of a physically remote location that comes to mind is a Hotel room, but I’m sure there are other good examples. Hotel VoIP deployments with wired ethernet offer benefits to the user such as guest VLAN Internet access from the PC port of the IP Phone. But if you think about it, it offers the perfect backdoor attack vector into the internal network. Privacy and seclusion. An attacker can spend as much time as they please, evading detection and slowly discovering the network. Each time I see this, it makes me wonder the extent to which this vulnerability is getting exploited in real life, but not being publicly disclosed. We’ve seen how well publicized CHD / data breaches of the PCI DSS have taken place over wireless networks – I wonder if and how long it will take before this happens over a VoIP infrastructure deployed to a physically remote location which is trunked, unprotected into the internal network where mission critical servers are hosted.
Some would say that this is a network infrastructure “firewall” mis-configuration issue and not a VoIP issue. They are right. But you could also argue that this issue opens up only when you deploy VoIP with QoS and VoIP is so tightly integrated with the network and QoS. The VLAN Hop also enables UC attacks against not only the IP Phones, but the call server as well. For VoIP to be operational, those TCP/UDP ports between the IP phones and call server must always be permitted, even through a properly configured firewall.
Death of the Voice VLAN
Some have talked about the death of the Voice VLAN and others have questioned the relevance of Voice VLANs to UC Security. In my opinion, VLANs were never intended for security. They were designed for one thing: Broadcast Domain isolation, resulting in improved performance and host management. Then the “Voice VLAN” came about – a special access port feature for VoIP that enables the easy application of QoS and IP Phone provisioning. Brilliant, if you really think about it. Voice VLANs were also never intended for security features. However, some started seeing it this way because, by default, a PC wasn’t a member of the Voice VLAN, and Voice would have the highest priority on the network in the event of a malware outbreak on the “data” access VLAN, and so forth. This is still QoS – not security. A network with properly configured QoS at layer 2 or 3 doesn’t distinguish a virus outbreak from an extremely chatty file transfer application. In either case, VoIP will take the highest precedence through the network. Then we started hearing “VLAN is not a security measure” and now we are coming back full circle.
Voice VLANs are never going to die off due to their perceived security limitations. In fact, they are brilliant . They make it easier to deploy VoIP and other new and promising UC applications, like IP Video. Applications like IP video that are heavily reliant on QoS. This helps us all. The best thing we can do is recognize their security limitations and that they were never intended for security to begin with. Which brings me to my final point.
Why?
Many of you reading this are already well aware of this. But that doesn’t necessarily signify that others who deploy or own VoIP do as well. Just the other day, I had a conversation with a Network Engineer who had deployed VoIP for a major US sports stadium. This person believed that the IP Phones configured in the luxury suites were protected against VLAN Hop just because they had deployed MAC Address filtering on the switch ports. We all know that Voice VLAN Hop and MAC Address spoofing can be automated via myriad tools. But still, that doesn’t mean everyone else does.
I’m writing you today to ask for your help as VoIP Security professional in spreading awareness about this issue. I am open to hearing what you are seeing (specifically vendors and configurations in remote areas, and how the application is being used) or any other friendly comments or suggestions. This is an area of research and interest. Please email jostrom {at} viperlab {dot} net.
Earlier this week, several news outlets including Wired.com reported on a new Telephony Denial-of-Service attack that’s becoming more widespread. In this attack scenario, hundreds or thousands of PSTN calls are launched to the victim’s phone in order to prevent financial institution notifications from arriving while the attacker drains accounts. It’s less clear that attackers can do anything about email or SMS alerts, but based on sheer volumes alone one has to assume the attackers are using VoIP technology to originate the calls. Certainly there are many implications to consider, particularly if TDoS attacks become more common within the PSTN going forward.
I recently interviewed XMPP co-chair Joe Hildebrand for UCfederate.info regarding XMPP Domain Name Assertions (DNA) used to enable certain instant messaging federation use cases where an XMPP server might host multiple domains. Without DNA, it’s effectively impossible to use TLS for these multiple-domain scenarios, but that’s not the main point of this post. During the course of our conversation, we touched on the general problem of how you leverage PKI and digital certificates to establish trust between two domains for a given application protocol (itself a well-understood concept in theory) and the practical challenges that still remain on a protocol-by-protocol basis for ensuring integrity when binding a certificate to a domain for a given protocol.
Take SIP-TLS for example. We’ve run into more than a few implementations that check for a valid certificate but do absolutely no validation of the domain itself, such that if I send a message purporting to be from xyz.com after presenting a valid certificate from abc.com, not even so much as an error message is logged. Moreover, SIP doesn’t actually specify how such validation should take place, leading to vendor-proprietary implementations that utilize different certificate subject mechanisms and complicate SIP federation.
I noticed a few comments on my prior post claim that UC federation is effectively a solved problem. That’s only true if you narrow the meaning of UC federation to an absurdly small subset of the communications and collaboration space. Yes, XMPP federation for simple domain pairs for instant messaging is well defined with many interoperable vendor implementations today. Frankly, XMPP federation is the best story we’ve got for federation in the UC space, as the story degrades quickly from there. The next-best stories are effectively vendor-specific with Microsoft OCS Federation and Cisco’s Intercompany Media Engine (currently the only product using ViPR – (Verification involving PSTN Reachability – an IETF draft standard proposed by Cisco). There’s a lot of work left to do before all communications and collaboration services are federateable between enterprises, and it turns out that these certificate binding problems are one of the big gaps. To date, XMPP is the closest to solving them and the IETF is considering adopting general standards for protocol certificate binding based on related work – see: draft-saintandre-tls-server-id-check-02 for example]
There’s more to come on this topic in the near future, but for now I just want to leave you with this: it doesn’t matter how secure an established TLS connection is for a given protocol if you can’t bind application-layer domain claims with the certificate used for TLS session establishment. It’s a common fallacy that TLS “makes you secure” all by itself – that’s akin to saying that seat belts and airbags will prevent you from crashing. Federation can only succeed when all associated protocols have well-understood certificate and domain bindings that are properly validated by vendor products used by the federation participants. Anyone who tells you that’s a solved problem today for UC is delusional.
Want to learn about how voice biometrics are being used today in real deployments? Want to learn what advances have been made in the technology? Want to find out how people are using it for voice authentication, identification and more?
If so, consider attending the Voice Biometrics Conference taking place next week, May 4th and 5th, in the New York City area. It’s got a packed agenda and a great list of speakers who really represent the leading edge of what people are doing with voice biometrics. (And yes, I’m one of the speakers and yes, my employer Voxeo is one of the sponsors of the event.)
The organizers of the event, Opus Research, have also really tried to focus the event on showing real-world examples of biometrics deployments. Here is a message that organizer Dan Miller sent out yesterday:
The conference agenda is now packed with use cases across many applications, verticals and government functions. Here’s the list from today’s e-mail:
T-Mobile – Deutsche Telekom’s T-Mobile is developing fast authentication to focus on building a better customer experience.
Bell Canada – The largest customer-facing deployment of voice verification with more than two million customers enrolled.
Bank Leumi (Israel) – Will present how it successfully deployed multiple applications for voice-based user authentication for customers and employees.
I DRIVE SAFELY – Hear how the company implemented a voice-based solution for enrolling students in its online drivers’ education program.
Atos Origin – IT services provider Atos Origin incorporates voice authentication into its “Help Desk” and holds promise for multiple applications inside enterprises around the world.
Centrelink – Australian social services agency who deployed a speaker verification system to authenticate access to welfare services.
Federal Government of Mexico – Learn how the federal government of Mexico has implemented a speaker identification program for use in law enforcement.
If you’re looking for a way to network with the people who have lessons to share regarding strategic, tactical, technical, organizational or even social issues that arise as they specify solutions, analyze vendors, define their projects and carry out their plans, attending Voice Biometrics 2010 will be rewarding.
If you can get to the New York area, do check out the event… registration information can be found on the event page. And if you are attending… I’ll see you there!
If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.
On NPR’s ‘Fresh Air’ this week, Richard Clarke made some great points, in particular with the logic bomb scenarios of sneaking in code and untrustworthy hardware. While this is old news, it’s still a very real threat — recall that Chisco devices were discovered on US government networks and disclosed back in 2008.
With Richard Clarke’s story in mind, I think it’s worth re-visiting the “Chisco” problem. This article below is from three years ago, yet this same Chisco eBay seller mentioned, “Sincere Networking” is still up and running (ya gotta love that name, no?). Bear in mind this is just one of many Chisco eBay stores — that is, there are plenty of others moving all types of Chisco gear on eBay, including routers, firewalls, switches. We are way beyond WAN NIC interfaces folks.
Why can’t these get shut down?
Network World: “eBay ‘Chisco’ stores are selling fake Cisco products originating in China”
This counterfeit gear has already landed on plenty of networks, and it’s likely to continue. Just like the FBI’s conclusion on slide 10, I agree that a huge risk in this area stems from small ‘mom n’ pop’ subcontractor outfits that choose to purchase this gear on the cheap from eBay, and then charge-back their own clients for the list price on CCO. Of course, that dirty network engineer in your organization could do a swap-out with Chisco gear during your next change management window — and in these economic times perhaps merely to re-sell the valuable real card rather than backdoor the organization’s network.
That said, recent security conference presentations, such as CanSecWest’s “Can you still trust your network card” should be at the forefront of the discussion when this Chisco topic comes up.
I know this is a dirty subject. It’s so dirty that very few folks even want to discuss it. It’s a nightmare. But like it or not, it’s going to be up to you to make sure that your gear is legitimate, especially if you’re on a US government network as according to the FBI’s presentation on slide 40, “Cisco’s Brand Protection does NOT coordinate with Cisco’s Government Sales”
Here’s a few links to hopefully get you started on the right path.
Comments with additional resources are most welcome.
Well, it only took about five years and three sessions of Congress to finally pass this thing in both the House and the Senate. The Senate passed their version of the bill (S. 30) on February 23rd and the House passed their version of the bill (H.R. 1258) on April 14th. All that remains now is for any differences in the two bills to be reconciled and sent to the President for a signature.
Awhile back I blogged on VOIPSA about medical devices using VoIP. This is a follow-up to that post, and is a bit more tangible in that these devices are showing up on the auction sites.
I typically check eBay weekly for medical devices showing up, with an eye for anything with a network interface.
Bluetooth-enabled devices abound, but the (mis-perception) that an attacker must be physically close decreases popular interest from a security testing perspective. In contrast, it’s a box “on the wire” that enables an attacker in say, Palau, to to reach out and provide what I’d call a “negative home medical monitoring experience.”
So what’s on eBay?
Here’s a ViTel (now owned by Bosch) device and blood pressure monitor on eBay that’s a few years old, but has the ability “…to communicate via standard telephone line, broadband, or cellular and does not interfere with existing telephone service.”
ViTel Net Turtle 400 & A&D UA-767PC Blood Pres. Monitor
eBay Link: http://tinyurl.com/yytwgma
Suggested for discussion:
1. Should vendors of these devices be concerned about their sale on site like eBay? Why or why not?
2. Are there any available business services that monitor the after-market sale of these devices?
3. Would/should vendors care about re-acquiring these devices?
4. How interesting / valuable would it be to conduct a security analysis on this device, report the findings to CERT, and publish at DefCon or BlackHat?
5. Does a diagram like the one below concern anyone?
