Attacking encrypted VOIP (SIP) protocols
In this post I will be explaining the approach in attacking the encrypted voice over IP (VOIP) protocol, more specifically, SIP (Session Initiation Protocol). When we are talking about the SIP encryption, it will most likely assume some kind of SSL/TLS wrapping (SIP over TLS).
An example below shows the solution design that allows interception, decryption and manipulation of SIP messages.
The central component consists of mitm_relay.py and BURP. It is not required that both BURP and mitm_relay run on the same machine, but my setup did run both of them on the same virtual instance.
The communication chain looked like this:
Client -> mitm_relay->BURP->SIP Server->Client 2
The mitm_relay.py is a python script available at https://github.com/jrmdev/mitm_relay
Before we fire up the mitm_relay, we need to configure couple of things- its certificate (self signed in my case, and private key). Once this is in place, we can run it:
Few details about the mitm_relay setup:
-l 0.0.0.0 -listen to all available interfaces
-p 127.0.0.1:8080 -BURP is running on localhost, port 8080
-r tcp:5061:192.168.0.101:5016 -forward all traffic received on localport 5061 to SIP server
-c mitm.pem -self-signed certificate
-k privatemitm.key -private key
mitm_relay will forward SIP packets to BURP in which we can see it decrypted. BURP is a popular web proxy which does not speak SIP, which is why we needed mitm_relay.py to assist. BURP can be found on https://portswigger.net/burp. mitm_relay will encapsulate the SIP traffic with "/CLIENT_REQUEST" and "/SERVER_RESPONSE" additions to POST request so that BURP knows how to handle these.
So, either in BURP or in a wireshark pcap captured on the same machine, we can analyse the traffic capture and identify relevant SIP digest authentication attributes. Not only that, we can actually observe the full application level dialog that is by its structure very similar to HTTP protocol.
What we want here is to use, if possible, sipdump and sipcrack utilities from Kali to dump and crack the SIP passwords captured in the pcap. But, there is an issue here. While sipdump/sipcrack work well in streamlined fashion against the SIP sessions captured in plain text, it is not the case when we have encrypted session capture.
The issue is that sipdump is unable to interpret the captured pcap because it's encrypted. Sure enough, we can import the private key into the wireshark and have everything decrypted, but this capability is not supported by sipdump.
There are two options here we can follow for password cracking:
a) we can manually reconstruct the file that sipcrack will recognise
b) we can develop new application to streamline the password cracking
Let us explore bot of them, starting with a).
So, we need to reconstruct the fileformat that sipcrack is able to interpret (sip.dump in the below screenshot). I manually crafted the sip.dump file format by extracting the SIP authentication attributes (username, realm, password, nonce, method and URI) which are all captured in the pcap. (Of course, you will not see the password, but you will see the SIP digest MD5 hash response which is a function of password). Once this format was presented to sipcrack, it recognised it properly.
On the receiver's side the call is successfully established.
b) option , as mentioned above, is to develop our own application capable of parsing the mitm_relay.py output (which is a text-based files) and cracking the password. For that purpose the new application was developed - https://github.com/adenosine-phosphatase/sipcrack2
It is now time to discuss some context around this attack. Even though it is technically possible, it is by no means easy to execute this attack in a real-life scenario. Let us look into one major obstacle that the attacker would be facing if she wanted to compromise the caller.
In the figure below we see a configuration options for a legitimate SIP client (in my case it's Jitsi, but these fields are more-less present in all decent SIP clients).
Note that "proxy" setting is filled in with a legitimate SIP proxy server that would usually be supplied by your Telco/VOIP service provider. So , the first thing that comes to mind is how to redirect the traffic through the attacker's proxy?
We surely have no control over the Telco proxy.
One way to do it is ARP-poison the cache of the switch that maintains ARP-IP mappings for a telco SIP proxy. This is not easy to do- you 'd need to have access to that switch, which you , most likely, will not. The risk is more elevated in the environment of the Telco itself - if you are the employee of the respective telco/service provider, the access to SIP proxy switch would probably be easier, but still not trivial. You need to find out the device IP, a way how to inject ARP packets into it etc. Also, once inside the telco, it is more likely that the SIP would be decrypted at this stage.
The first reason being that the traffic, once inside telco is considered "trusted". The second reason is that many providers will aim to process decrypted traffic to increase the traffic processing performance (no encryption, no CPU/crypto calculation overload, therefore, higher throughput).
An example below shows the solution design that allows interception, decryption and manipulation of SIP messages.
The communication chain looked like this:
Client -> mitm_relay->BURP->SIP Server->Client 2
The mitm_relay.py is a python script available at https://github.com/jrmdev/mitm_relay
Before we fire up the mitm_relay, we need to configure couple of things- its certificate (self signed in my case, and private key). Once this is in place, we can run it:
-l 0.0.0.0 -listen to all available interfaces
-p 127.0.0.1:8080 -BURP is running on localhost, port 8080
-r tcp:5061:192.168.0.101:5016 -forward all traffic received on localport 5061 to SIP server
-c mitm.pem -self-signed certificate
-k privatemitm.key -private key
mitm_relay will forward SIP packets to BURP in which we can see it decrypted. BURP is a popular web proxy which does not speak SIP, which is why we needed mitm_relay.py to assist. BURP can be found on https://portswigger.net/burp. mitm_relay will encapsulate the SIP traffic with "/CLIENT_REQUEST" and "/SERVER_RESPONSE" additions to POST request so that BURP knows how to handle these.
The issue is that sipdump is unable to interpret the captured pcap because it's encrypted. Sure enough, we can import the private key into the wireshark and have everything decrypted, but this capability is not supported by sipdump.
a) we can manually reconstruct the file that sipcrack will recognise
b) we can develop new application to streamline the password cracking
Let us explore bot of them, starting with a).
So, we need to reconstruct the fileformat that sipcrack is able to interpret (sip.dump in the below screenshot). I manually crafted the sip.dump file format by extracting the SIP authentication attributes (username, realm, password, nonce, method and URI) which are all captured in the pcap. (Of course, you will not see the password, but you will see the SIP digest MD5 hash response which is a function of password). Once this format was presented to sipcrack, it recognised it properly.
It is now time to discuss some context around this attack. Even though it is technically possible, it is by no means easy to execute this attack in a real-life scenario. Let us look into one major obstacle that the attacker would be facing if she wanted to compromise the caller.
In the figure below we see a configuration options for a legitimate SIP client (in my case it's Jitsi, but these fields are more-less present in all decent SIP clients).
We surely have no control over the Telco proxy.
One way to do it is ARP-poison the cache of the switch that maintains ARP-IP mappings for a telco SIP proxy. This is not easy to do- you 'd need to have access to that switch, which you , most likely, will not. The risk is more elevated in the environment of the Telco itself - if you are the employee of the respective telco/service provider, the access to SIP proxy switch would probably be easier, but still not trivial. You need to find out the device IP, a way how to inject ARP packets into it etc. Also, once inside the telco, it is more likely that the SIP would be decrypted at this stage.
The first reason being that the traffic, once inside telco is considered "trusted". The second reason is that many providers will aim to process decrypted traffic to increase the traffic processing performance (no encryption, no CPU/crypto calculation overload, therefore, higher throughput).
Nice Blog.
ReplyDeleteI am trying to intercept IBM i series traffic which is using telnet over TLS 1.2. I am following the same steps but still seeing the encrypted traffic in Burp.
Ładnie to wygląda.
ReplyDelete