VoIP Cisco System, Security Analysis
# Authors: Ferraris Andrea, Priori Gaetano, Forte Raffaele
# Vendor Homepage: http://www.cisco.com
# Version: Cisco CM Administrator v10.5.2.10000-5
I. INTRODUCTION
Nowadays, the use of VoIP technology is spreading in every business. Voice Over IP allows to carry voice calls over the company network and enables to connect offices across the without any additional cost.
In this article we present a security analysis of Cisco VoIP system; specifically, about how to intercept phone calls, obtain administrative credentials, access the phones and retrieve full VoIP network topology. Our research includes Cisco CM Administrator (version 10.5.2.10000-5) and Cisco UC Phones.
II. DESCRIPTION
Standards for securing VoIP are available in the Secure Real-time Transport Protocol (SRTP) and the ZRTP protocol for analog telephony adapters as well as for some softphones. IPsec is available to secure point-to-point VoIP at the transport level by using opportunistic encryption.
From a security point of view, since VoIP uses IP network, the tools and methodologies commonly known and used in security analysis can be applied. In our analysis we are going to encounter SIP as VoIP implementation.
The following sections are divided as follows:
- Section III – we will present how to setup the attacker PC. In this phase we are able to obtain VLAN identification and perform a passive network sniffing.
- Section IV – we will describe how it can be possible to intercept local calls.
- Section V – we will present an information leakage vulnerability that allows to obtain administrator credentials and network topology. We also develop a script to exploit that vulnerability.
- Section VI – conclusion and future projects.
III. NETWORK ANALYSIS AND SETUP
For the whole testing phase we used BackBox Linux connected through Ethernet cable to the enterprise LAN.
First, we started with a network passive sniffing but we does not find any clues or VoIP packages. In the most companies, the VoIP network is separated by “normal” traffic using different VLAN (Virtual LAN) according to IEEE 802.1q standard. Peraphs, if we switch VLAN, we can sniff VoIP traffic.
In order to “change” VLAN and be albe to sniff traffic, it is necessary to load a kernel module using command
$ sudo modprobe 8021q
After loading this new module, we perform another passive sniffing. This time, we are able to see more traffic than before; in particular we obtain CDP packets.
Cisco Discovery Protocol is a proprietary data link layer developped by Cisco and it is used by Cisco equipments to share various informations. Cisco devices send, in multicast 01:00:0C:CC:CC:CC, a CDP packet with various information include OS type, service protocol, VTP type and VLAN source. Usually a CDP packet is sent every 60 seconds, but it can take longer.
In our case the VLAN for VoIP traffic is 50. This information allows to save time but if there is not this packet, a security researcher can brute force every VLAN because there are only 65535 possible VLAN tag. A particular tool usefull in this kind of analysis is Voip Hopper.
Using vconfig we are able to create a pseudo-interface to communicate in VLAN 50, as we can see below
$ sudo vconfing add eth0 50
Now, we can sniff traffic on that pseudo-interface: this capture presents a lot of ARP request but MAC address is Cisco, so we are probably inside the VoIP network. In order to avoid malfunction in the network, we attack only our office phone; for this reason, we need to identify the IP address of the target phone. Obviously, a real attacker does not perform this step but he can try different MAC address.
To obtain the IP address of our phone, we first check the MAC address printed near the serial number behind the phone, then we unplug the cable. After few minutes, we re-plug the telephone and try to intercept DHCP request/response from our MAC address. DHCP response give us the IP address and another fundamental information: the IP address of the gateway .
The phone first try to connect to network using IPv6 protocol. After, it try to obtain IPv4 using DHCP. If there is not a IPv6 network present in the organization, an attacker could spoof router and respond to the request.
If the organization does not use IPv6, the phone should be configured without using IPv6 (default configuration) and only IPv4.
In summary, now we known:
- VLAN tag of VoIP network
- IP address of target phone
- IP address of SIP server (gateway)
- The network use DHCP
Thanks to DHCP we now can try to obtain a valid address in order to contact the SIP server done with the command listed below.
$ sudo dhclient eth0.50
If everything go well now we have an IP address an we can try to attack the SIP server. A complete scan with Nmap showed many ports open, including the TCP 6970 and 69.
IV. ATTACKING VOIP NETWORK
Now, we have access to the network and we can communicate with SIP server and phone. The next step is to sniff traffic between phone and server.
To achieve this Man-in-the-Middle we used an ARP posioning attack this kind of technique uses in “malicious” way the ARP protocol. Address Resolution Protocol is a protocol that allow to obtain MAC address from an IP address.
ARP poisoning attack sends to the victim an ARP packet (called “gratuitous ARP”) where it says that the MAC address of the gateway is the attacker address. This way, all the traffic directed to the gateway is sent to our machine but we need one step more: we want to eavesdrop the gateway response too. To achieve this, we send another ARP packet to gateway where it says that the MAC address of the phone is attacker address. Now, every packets exchange from phone to gateway pass though our machine.
We use Ettercap to perform ARP poisoning but other tools are available too (or scripting with Scapy). Now we can sniff the local traffic.
Using Ettercap from terminal:
$ ettercap -TqM -i eth0.50 arp:remote /phone// /gateway//
Now, we want to see the traffic exchanged when a call is performed. To obtain this data we use our “poisoned” phone to call another telephone. As we can see below the call follow this step:
- The phone send a 101 Request Invite to the gateway. This packet contains the information about the source phone and destination phone.
- The server send back a status information 100 Trying to inform the caller phone that the communication needs to be esatblished.
- The server send another status information 180 Ringing to inform the caller phone that the other phone is “Ringing”. This way the caller phone can beep until hang up.
- When the callee hang up, the server send back to the caller phone 200 OK packet.
- The traffic exchanged between the two phones is “invisible” ergo the RTP traffic does not reach our machine.
It seems the “real call” does not pass through gateway but it’s likely that the real “data voice” is exchanged direct through the two phone. In order to evaesedrop the RTP packet we perform another ARP poisoning between the caller and callee telephone. Again, we use Ettercap to poison the callee ARP cache and repeat the same step before.
Now we have capture RTP packet. The real communication, indeed, is performed by the two telephone directly without the gateway redirects the data between the two phones.
The RTP data is not encrypted, and all the data is routed using the poisoned ARP table, making ARP poisoning still a valid attack. By saving the capture file (in our test we use Wireshark to intercept traffic) we are able to retrieve the voice data try to decode it. Wireshark helps us to identify the codec used in the commmunication. To decode this data we need to export RTP payload and, using the right codec, transform into an audible format. It’s important to notice that the data are raw, so we need to create a right file in order to open with normal player.After decoding the traffic we are able to listen all the call .
The point of this attack is not to demonstrate new Cisco vulnerability but is to illustrate how the same technique and tools used in network assestment can be used against non-traditional platform. In this case, our attack vector is use ARP poisoning, an ancient technique that demonstrate once again its power. Moreover, default configuration of the system does not activate any type of encryption: this way, a real attacker (or disappointed employee) can easily evaesdrop all phone call made and, maybe, he use this data to ransom someone.
This attack has a critical impact and the “exploitable level” is easy/medium: everyone with a bit of penetration testing skills can listen all phone calls.
V. GATEWAY HTTP ATTACK
Our research is continued in the “registration” phase. In this step we want to intercept and see how a phone make initial registration against SIP server.
Again, we use ARP poisoning to intercept all the traffic between phone and SIP server, but, now, we have a new problem: ARP poisoning attack works only when the system is already running.
We can follow various way in order to avoid this problem:
- Send continuous ARP packet until the phone it is able to read one.
- Trying to concourre against the real server in ARP response
- Send an ARP packet as soon as the phone can read it but before it ask the MAC address in order to capture all the traffic.
We choose the last way. As we have already seen, the Cisco phone first try to use IPv6 address and only after that try DHCP. With a simple Python script we are able to sniff the network and as soon as we intercept a IPv6 packet, we can start our poisoning attack.
This way, we are able to evaesdrop all the registration phase from phone and gateway.
First of all the phones try to obtain various configuration file using TFTP: Trivial File Transfer Protocol allow light client to obtain file, like FTP, but using UDP (port 69). The phone asks to server a particular file named SEPC80084XXXXXX.cnf.xml.sgn. We put XXXXXX for anonymity purpose because the real file name is the mac address of the phone. This files seems to have a standard name: SEP+PHONE_MAC_ADDRESS.cnf.xml.sgn.
With this information we can asks to TFTP server file with that file name trying different MAC. Obviously, brute forcing 6 bytes is not easy but the first three is fixed (OUI Cisco) so we only need to try the other three. After that, we perform a little search for this vulnerability and we found an old vulnerability on Exploit DB where a gateway is enumerated on its TFTP port to find configuration files for each phone.
This files contains various configuration information about the phone as we can see in figure include the IP address and the name on the phone.
We want to see what the phone do if the TFTP server does not responde: we repeat the same attack as before but, this time, we trunk every TFTP packet. We expect this attack cause DoS on the phone because it can not obtain its configuration file.
Contrarly as we expected, after few packets the phone tries to obtain these files using HTTP protocol directly to port 6970. This way, also if the well known vulnerability before is fixed, an attacker can obtain the same information using a different service. Moreover, the communication is in plain text (HTTP) and can be easily read by the attacker.
Now we can enumerate all phone connected to the network. On GitHub we can see the python script we use in order to retrieve all configuration files.
During analysis of this file, we found that are present a XML tag named <sshUserId> and <sshPassword>. This fields are empty in the majority of files but we are able to find few files where this fields contains valid credentials.
Another interesting reference is to the file SPDefault.cnf.xml where other useful information is stored. Here we can find where the Unified CM is present. Using the credentials previously collected we can access the administration panel, where we can control phone calls, remote conferences and all activies concerning VoIP traffic. We can delete and create user account and change Call ID too.
We don’t know if this credentials is the same because the system administrator is “lazy” (often people are lazy) or because that password must be the same in order to work and we don’t know why that fields are empty in some files too. For now, we can only say that credentials are used to access in remote to the telephone.
Again, the point to this attack is to highlight how tools and methodologies used in “normal” pen test can be used against non-traditional platform. In this particular case we are able to obtain access to main panel of the Unified CM so the risk of this attack is very high and the technique used are pretty simple.
VI. CONCLUSION
Even if the previous vulnerability is de facto patched in TFTP the vulnerability is still present, even in a worse configuration, in HTTP.
Cisco declined the first vulnerability disclosure as a misconfiguration, but leaking admin credentials by default should still be considered as a serious threat to an organization security.
In order to prevent this kind of information leakege you should encrypt all the communications between the Cisco Unified Communications Manager and the phones and add remote authentication on the gateway as explained in the Cisco Security Center.
After this error are fixed, we will continue our research against VoIP network because we think that in the future this technology replace the old telephony technology. The security and privacy is a “must have” and our goal is to find this security flaws before bad guys. Keep calm and Hack the Planet!