Note that you can run the script in debug mode to lookup IP addresses based on city origination.  Hope this script helps you and let us know how it goes.

• iPhone Facetime client doesn’t use SIP REGISTER for authentication
• Uses STUN for NAT Traversal and resolving the remote callee and called party’s IP address of each iPhone
• After the remote party’s IP address has been resolved, SIP INVITE and MESSAGE packets are exchanged directly between iPhone devices
• Cleartext SIP and RTP
• RTP video appears to use the H.264 video codec, and audio appears to use the AAC-LD codec (the same audio codec used in Cisco TelePresence).
• FaceTime uses XMPP to authenticate each iPhone to an Apple Jabber server, using TLS and mutual certificate authentication.

Josh and I were discussing this the other day because he was trying to use the ‘VideoSnarf’ tool in order to re-construct the H.264 encoded media packets.  The codec does appear to be H.264, but with some slightly modified reserved fields.  Right now this isn’t working, but we hope to have an updated version of VideoSnarf working together with Facetime traffic in the near future.

This is so interesting because it is the first SIP client on a widely deployed consumer Smartphone device developed and supported by a vendor such as Apple.  I think it signals that we are going to see more of these applications – these are exciting times.  It will be interesting to see how other vendors follow up soon with 2-camera video clients on Smartphones using VoIP protocols, taking the lead from Apple.  I am sure many others will be taking a closer look at Facetime, and the attack surface area here for potential exposures are very interesting, as well as the potential security measures that can be applied in order to protect Facetime traffic.

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.

Last week, the folks at SIPfoundry released the 4.0 version of their SIP server, sipXecs.  I don’t hear a lot of talk about sipXecs so let me say a few things about it here:

* it’s a great SIP software proxy/registrar package, with an active development and support community

* It’s free.

* It has a distributed component software design, which optimizes HA configurations for clustering

* It has a very intuitive web console GUI, and it has a bootable CD with all software pre-loaded on it

* Great documentation wiki.  For example, I had set up a working SIP trunk configuration in under five minutes.

This is not to take away from other high quality open source  SIP server software projects like opensips, but I’ve been using and testing the previous version of sipXecs for a while now, and love this software.  I’ve just started testing this exciting new 4.0 release.  The most noticeable feature of this release is full sip trunking and remote worker support (far-end and near-end NAT traversal, and HA media anchoring).  What this means is that you have a full solution for running your own SBC and SIP Proxy.  The sipxbridge component of sipXecs is the SBC software component.   With sipXecs and sipxbridge, you can set up a proof of concept service provider network in your home, set up an enterprise lab for interop testing and comparison to commercial SBC vendors, use the software for a security testing demo toolkit, or just use the solution to register your remote phones into your network, and place outbound calls.  Great job and thanks to SIPfoundry for this work.

A new version of the VoIP Hopper security assessment tool was released earlier this week, with Nortel VLAN Discovery support.  VoIP Hopper is a free security assessment tool that supports VLAN Hopping – in essence, it mimicks the behavior of an IP phone for the Voice VLAN Discovery protocol or mechanism.  Then it rapidly automates a VLAN Hop, tagging the DHCP request and all subsequent Voice traffic with the discovered Voice VLAN ID.  Since most new VoIP deployments use the segmentation of discrete Voice VLANs for increasing QoS requirements, an attacker must sometimes first gain access into the Voice VLAN as a prerequisite vector, before running other VoIP exploits.  VoIP Hopper enables a regular PC to become a member of the IP Phone VLAN.  The tool is simple yet powerful, and has been used in many security assessments in the past.  The new features of VoIP Hopper:

* Nortel Voice VLAN Discovery and VLAN Hop

* A new CDP Spoof mode for more rapid and automated VLAN Hop in a CDP network

* An integrated DHCP client 

From the VoIP Hopper website, the next features planned for VoIP Hopper are LLDP-MED support and trunk port testing.

Finally, I recently used the SIPVicious tool in a remote VoIP security assessment, and it’s a very useful tool that any VoIP security professional should have.  When you look at the business risk of toll fraud / service theft, this tool can be pretty valuable in enumerating vulnerabilities that can be a risk to your business in the form of remote attackers trying to gain unauthorized access to your VoIP network and placing unauthorized calls.  As VoIP proliferates, we’ll see more usage of tools like this to conduct reconnaissance of open SIP services, valid users, and the brute forcing of subscriber/user passwords.  On the proactive protection side, it’s also good to see folks contributing open source proof of concepts for mitigating this risk.  Here is a “Simple Asterisk Based Toll Fraud Prevention Script”.  If you use an active response firewall/IDS/IPS solution, you could actually detect the attempts to toll fraud/service theft attacks based on a signature, and have your VoIP IPS and/or firewall block the source IP address of the would-be attacker.  It’s called a “Voice Toll-Fraud Intrusion Prevention System”  (VTIPS) .  Good to see open source software progress in this direction.