Informático y "Segurata": Aprendiz de hax0r

Mostrando entradas con la etiqueta Aprendiz de hax0r. Mostrar todas las entradas

domingo, 10 de abril de 2011

Incidentes para recordar de los últimos dos meses

Llevamos una temporadita fina y elegante en cuanto a hacking e incidentes varios de seguridad informática. Como sé que me perderé si no lo escribo, aquí va esta entrada como una especie de lista de sucesos interesantes a recordar. Sin otro orden más que lo que voy encontrando:

El hacking al sitio web de la empresa HBGary (realmente, dos empresas) por el grupo Anonymous. Podemos ver una carta abierta de HBGary hablando un poco del tema.

El de la empresa RSA, por el que pudo llegar a obtenerse información sobre su producto de autenticación SecurID. Aquí hay una carta abierta de RSA sobre el tema. La forma de perpetrar el ataque fue un phishing a uno de los empleados de la compañía, que recibió un correo con un fichero excel malicioso adjunto, que explotaba una vulnerabilidad en Adobe Flash. Se explica de forma extendida aquí y aquí.

El de Comodo. El compromiso de una autoridad de registro permitió la generación de certificados digitales falsos de unos cuantos sitios importantes. A destacar, el mecanismo elegido para mitigar el riesgo: en algunos casos se emite una actualización vía OCSP, pero en otros se emite una actualización de software directamente, como es el caso de Microsoft. SecurityByDefault cuenta el incidente muy bien, y nos enseña, además, que si el navegador no puede comprobar si el certificado está revocado o no, no da ninguna alerta al usuario. ElLadoDelMal nos enseña que se conoce la técnica para hacer un man-in-the-middle que evite esta comprobación OCSP.

El de Mysql, cuyo sitio web fue vulnerado... con una inyección SQL. Mediante el mismo método, además de Mysql.com, les han dado caña a muchos otros últimamente, incluyendo a Comodo y HBGary, como nos explican en el blog de WhitehatSecurity.

El de PHP.net. El compromiso de uno de sus servidores pudo haber permitido al atacante obtener credenciales para acceder al repositorio del propio código fuente, aunque parece que no ha tenido consecuencias graves.

El de los foros de Telecinco, se puede ver el defacement hecho aquí.

La no-presencia de keyloggers en los portátiles de Samsung. Primero se dijo que había, luego se descubrió que era un falso positivo.

La fuga de direcciones de correo de la empresa de marketing online Epsilon. Se teme que podría dar pie a toda una oleada de ataques de phising contra las entidades que trabajen con esta empresa y cuyas direcciones hayan sido reveladas.

Ahí es nada.

Actualización 12/04/2011: ayer le tocó a Barracuda.
Actualización 27/05/2011: y durante el último mes, muy duramente a Sony.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS, seguirlo en Twitter, o

lunes, 4 de abril de 2011

Para aprender más: SecSE y No cON Name

En muchos blogs dedicados a seguridad informática se publican habitualmente listados con conferencias variadas, tanto cerca de casa como en los más lejanos lugares del mundo (o casi). Yo suelo escribir poco sobre eso, y para compensar un poco hoy hablamos de dos conferencias que me llaman la atención.

Lejos de casa, tenemos una conferencia nueva que acaba de cerrar el registro para candidatos a presentar (el call for papers, en argot). Es SecSE, una conferencia dedicada a la seguridad en el desarrollo que celebra su quinta edición en Viena, y que tendrá temas tan interesantes como la forma de abordar las tareas propias de seguridad en un proyecto de desarrollo de software cuando hay metodologías ágiles de por medio, seguridad en el diseño, codificación e implantación de software, técnicas de verificación y pruebas, seguridad y usabilidad, o análisis de riesgos, entre muchos otros temas. Se celebra entre el 22 y el 26 de Agosto.

Cerca de casa, una de las tres o cuatro principales conferencias que no hay que perderse es No cON Name. Con el objetivo de estimular la industria española de la seguridad informática a través del intercambio y actualización del conocimiento entre los profesionales y expertos, y aumentar la concienciación sobre la importancia de la seguridad de los medios tecnológicos en ciudadanos, organizaciones y empresas, se celebra este año en el CosmoCaixa de Barcelona el 16 y 17 de Septiembre.

Reunirá, igual que ha hecho en anteriores ediciones (para algo es la conferencia española en seguridad con más solera), a los mejores expertos del panorama español e internacional para hablar de muchos temas de seguridad informática, por ejemplo: phising y malware, gestión de identidades, prevención de fugas de información, herramientas/estudios/técnicas para BCP y SGSI, seguridad en el desarrollo de software, técnicas de ingeniería inversa, seguridad en dispositivos médicos, móviles, SCADA...

La lista de temas a proponer no es cerrada, y si tienes una idea buena podría tener cabida en la conferencia.. Aquí se pueden descargar las presentaciones de la edición anterior, para ir haciéndonos una idea. El plazo de presentación de propuestas para incluir un proyecto en el No cON Name 2011 ya está abierto y terminará el 31 de Mayo. Podemos encontrar más información aquí. La inscripción para los asistentes se abrirá el 15 de Mayo (o sea, en nada, así que date prisa si quieres ir).

Para estar al día: twitter de No cON Name.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS, seguirlo en Twitter, o

domingo, 20 de marzo de 2011

Mezclando nmap con metasploit

Coincidiendo con la idea, indicada en Bruteforceando con metasploit y en bruteforceando, de que es mejor tener pocas herramientas que hagan muchas cosas, que no un catálogo enorme y heterogéneo de soluciones que vengan de las fuentes más diversas, leo en Nmap? In my Metasploit? It's more likely than you'd think! que Metasploit puede usar el motor NSE de Nmap dentro de sus propios módulos, y aprovechar la sinergia entre ambos proyectos para conseguir algo mejor.

Aún cuando ya usaba los resultados del análisis de puertos hecho por nmap como mapa (es un decir) para el lanzamiento de exploits, ahora dispondrá de funciones específicas para invocar a un script nse dentro de un módulo de metasploit. El módulo de Metasploit se encargará de cuantas tareas sean necesarias para construir los argumentos con los que invocar al script, y de procesar después los resultados del mismo.

De momento, si descargamos el código fuente de su repositorio svn (tengo la revisión r12033), podemos ver un ejemplo de código hecho en ./msf3/modules/auxiliary/scanner/oracle/oracle_login.rb, que utiliza el script nse de ataques por diccionario contra bases de datos Oracle realizado por Patrik
Karlsson. Para ello se sirve del módulo Msf::Auxiliary::Nmap. Con unas pocas funciones del módulo tenemos la invocación al script nse hecha, en líneas generales viene a ser así:

limpiar el almacén de parámetros pasados a nmap, mediante la función nmap_reset_args
pasar sus parámetros al script nse, mediante la función nmap_append_arg
lanzar nmap: función nmap_run
procesar la salida xml de nmap: función nmap_hosts. Como argumento, esta función debe recibir un puntero a una función nuestra, que se encargará de procesar cada máquina detectada por nmap (en el ejemplo, es la función process_host).

Analizando únicamente el ejemplo, parece una forma sencilla de reutilizar el trabajo hecho en nmap en nuestra solución de explotación favorita, pero quizás no la más eficiente: si queremos usar dos o más módulos de metasploit que llamen a nmap, tendremos que lanzar dos escaneos, (con lo que pueden llegar a tardar). En cualquier caso, es muy de agradecer que esté ahí.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS, seguirlo en Twitter, o

martes, 8 de marzo de 2011

Bruteforceando con Metasploit

Hace unos días escribía una pequeña entrada sobre los scripts de Nmap para hacer ataques por diccionario. Si bien es cierto que están muy muy bien, hay una pequeña carencia básica: nos falta SSH entre la lista de servicios incluidos para atacar por diccionario. Si no podemos con Nmap, podemos tirar de otra solución esencial en la caja de herramientas de un pentester: Metasploit.

La versión 3.4, presentada en Mayo 2010, ya tenía un conjunto estable de scripts para esta tarea, incluyendo SSH. Usarlo es sencillo, con unos pocos comandos en msfconsole es suficiente:

Ver la lista de scripts para atacar la autenticación de servicios. Podemos ver el script ssh_login entre la lista de los módulos auxiliares: search login
Lo seleccionamos: use auxiliary/scanner/ssh/ssh_login
Indicamos la máquina a atacar: set RHOSTS [IP]

Ahora tenemos que dar la lista de usuarios y contraseñas a utilizar para la prueba. Tenemos muchas posibilidades, que podemos listar con el comando show options, por ejemplo dar un listado de nombres de usuario y contraseñas en un fichero, con el formato [USUARIO espacio PASSWORD] en cada línea. Una prueba sencilla es elegir un nombre de usuario y un fichero con un listado de passwords posibles.

Indicamos el nombre de usuarios que queremos atacar: set USERNAME [NOMBRE]
Indicamos el fichero de passwords a utilizar: set PASS_FILE [RUTA_FICHERO]
Si no queremos ser molestados con cada intento de autenticación fallido, indicamos que no los imprima en la consola: set VERBOSE false . Al menos para probar, deberíamos ver qué está haciendo el script... por lo que yo no lo pondría.
¡Atacamos!: run

Cuando tengamos éxito, veremos un mensaje de confirmación con la palabra "success" en la consola ;) .

Para ver las sesiones que tenemos activas: sessions -l
Para entrar en una: sessions -i [NUM_SESION]

¡Éxito!

Fácil, ¿no?.

Existen muchísimas herramientas para algo tan sencillo como un ataque por fuerza bruta o diccionario contra un servicio en red. Algunos ejemplos son la veterana y recientemente reactivada Hydra, la increíble Medusa, ncrack (otra solución de la suite nmap para el tema de la fuerza bruta), Nix, o las que tienes en kits de pentesting como Inguma. Pero no nos hace falta complicarnos la vida buscando, las utilidades más esenciales son suficientes ;) . Otro tema, por cierto, es de dónde sacar diccionarios para probar, podemos hacerlo por ejemplo de los recursos que nos ofrece DragonJar. ¿Qué usas tú?.

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS, seguirlo en Twitter, o

lunes, 7 de marzo de 2011

La MASA

Un post de apunte rápido (Twitter no vale para todo): Microsoft presentó recientemente una nueva aplicación de seguridad interesante: el Microsoft Attack Surface Analyzer, o MASA. Esta es una solución que sirve para tomar una "foto" de nuestro sistema antes de instalar un software, otra después de instalarlo, y comparar el resultado para ver cuáles han sido las modificaciones realizadas y qué puertas podrían dejar abiertas en nuestro sistema.

Genial para desarrolladores que quieran ver que agujeros podría abrir su software, para los profesionales informáticos que pueden ver qué hará una nueva actualización y evaluar sus riesgos, o incluso para el equipo de respuesta de un incidente de seguridad.

Visto en WindowsTecnico, en Darknet, y en Microsoft Security Development Lifecycle. Descarga para Windows 7 y Windows Server 2008 R2.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS, seguirlo en Twitter, o

sábado, 26 de febrero de 2011

bruteforceando

"Bruteforceando" es una bonita palabra que he escuchado muchas veces, para hablar de ataques por fuerza bruta, es decir, el método que consiste en probar todas las combinaciones posibles de aquello que queramos crackear, para ver con qué combinación acertamos. Lo usaremos normalmente para obtener el usuario y password con el que entrar a un sistema. Pues de esto va esta entrada: de una herramienta de toda la vida que ahora tiene esta posibilidad, Nmap.

En la versión 5.50, anunciada hace un mes más o menos, se incluye una buena cantidad de scripts para hacer este tipo de ataques contra sistemas y protocolos variados (ssh, http, oracle, ms-sql, mysql, svn, vnc, apple filing protocol y muchos otros). NOTA: Siendo estrictos, realmente lo que hacen son ataques por diccionario, y no un ataque por fuerza bruta, pero bueno, la categoría establecida para este tipo de scripts se llama "brute"...

Se puede obtener el listado completo de scripts que implementan esta funcionalidad con el comando nmap --script-help "*-brute" :

Listado de scripts de la categoría "brute"

Y podemos ver que efectivamente funcionan (prueba de ataque por diccionario contra un servidor telnet en mi red):

Un ataque sencillo parece que funciona

Para hacer esto dispone de dos bibliotecas sencillas (brute y unpwdb), que nos permiten hacernos nuestros propios scripts para bruteforcear sin tener ni idea de programación en Lua (el lenguaje con que están implementados los scripts de nmap). La documentación de ambas bibliotecas explican de forma sencilla cómo hacer un script que las utilice. Y si no se entiende, pues basta con echar un vistazo a cualquier script que las utilice, por ejemplo http-brute o http-form-brute. Por no necesitar, ni tenemos que buscar un diccionario de passwords, ya que dispone de un diccionario con los 5000 usuarios y passwords más utilizados, actualizado recientemente por cortesía (es un decir) de Gawker.com.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS, o seguirlo en Twitter

domingo, 14 de noviembre de 2010

la especificación de las cookies

A cuento del post de hace un mes y algo sobre las cookies y sus tamaños, os dejo un post rapidito para mencionar un artículo muy bueno sobre las debilidades en la especificación de las cookies HTTP, en el blog de lcamtuf.

Nos cuenta sobre los orígenes de las cookies, de sus flags más conocidos, y una serie de problemillas de seguridad muy interesantes que surgen debido a la forma en que se especificó su uso. Para no perdérselo.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS o seguirlo en Twitter...

martes, 14 de septiembre de 2010

cookies y sus tamaños

Hoy que me han dejado algo de tiempo para leer y ponerme al día, he estado leyendo entre otras cosas, este magnífico paper de la presentación de Robert Hansen y Josh Sokol en Blackhat, sobre cómo HTTPS no es bastante para garantizar la confidencialidad de la información de un sitio web. En el paper, y después en este post, se menciona un detalle que llama la atención: es posible hacer una denegación de servicio, no a un sitio web entero, sino a una porción del mismo nada más.

¿Cómo?. Inyectando una cookie demasiado grande en el navegador del usuario. En el caso de que un sitio web reciba una cookie demasiado grande... ¿qué puede pasar?. Algunas opciones posibles para que se dé este DoS son:

el valor de la cookie malformada, una vez recibido por el servidor de web, es almacenada en una o más variables en el aplicativo web correspondiente. Podría darse el caso de que esta variable tenga un límite de tamaño, y por tanto que fuera posible realizar un overflow. Y por tanto, ser posible una denegación de servicio. Esta posibilidad depende, por supuesto, de cómo se haga la gestión de memoria a nivel de sistema y en el entorno de ejecución correspondiente. Aquí va un ejemplo (extraído de la guía Owasp Testing) , en que se usa esta posibilidad sobre un aplicativo web CGI (o sea, tecnológicamente más viejo que la tos)
en tecnologías más modernas, podría ocurrir que la cookie de marras, al tener un valor malformado, no fuera tratada adecuadamente por la lógica del programa y se disparara una excepción no controlada (el resto os lo podéis imaginar)
el servidor de web recibe una petición HTTP más grande de lo que puede tratar, y la rechaza

El tercer punto es el más curioso: ¿cuál es el tamaño máximo de una petición HTTP?. Se configura en cada servidor de web. IIS 6.0 tiene un valor predeterminado de 16 KB, de acuerdo a este artículo de la web de Symantec. Para aplicaciones ASP.NET, parece que es 4MB (es el valor por defecto del parámetro httpruntimesection.maxrequestlength). Apache Tomcat 5.5 tiene un valor por defecto de 4 KB, 8 KB en Tomcat 6.0, según su documentación (véase parámetro maxHttpHeaderSize). Y es diferente para otros servidores (me gustaría tener una lista más completa, pero no tengo más tiempo para hacerla, por desgracia).

La idea, entonces, es inyectar una cookie en el navegador del usuario (con un xss, por ejemplo), lo suficientemente grande como para que se rechace la petición HTTP, asignándole como ruta una parte determinada del sitio web atacado (/logout.aspx, por ejemplo). ¿Cuál es el tamaño máximo que puede tener una cookie, en un navegador web?. ¿Cuántas cookies puedo tener por dominio?. El RFC 2965 dice que un navegador debería ("should") permitir al menos 20 cookies por dominio, con un tamaño máximo garantizado para cada una de 4 KB al menos. Internet Explorer parece que cumple de sobra, de acuerdo a este post de IEBlog de 2007.

Con lo cual, pues parece que este tipo de DoS es perfectamente posible, aunque cantará muchísimo en los logs del servidor de web, proxies, IDS, etc. No he contado nada que no se supiera ya, pero espero que la información de este post sirva: yo mismo no me sabía los detalles de los tamaños, etc, y me ha costado lo mío buscarlos. Cualquier aportación (particularmente si hay erratas), es bienvenida. Slds!