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

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í:

1. limpiar el almacén de parámetros pasados a nmap, mediante la función nmap_reset_args
   
2. pasar sus parámetros al script nse, mediante la función nmap_append_arg
3. lanzar nmap: función nmap_run
4. 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

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

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

Dos utilidades básicas

---

Siempre tenemos muchas noticias sobre herramientas de seguridad de mil clases y tipos, y es imposible (además de poco innovador) hacer un post cada vez que sale una, salvo que sea novedosa o particularmente relevante. Hoy toca un pequeño post por darse el segundo caso, pues ha habido novedades en dos imprescindibles: Nmap y SQLMap. Ambas forman parte de la caja de herramientas imprescindibles de todo aquél que se dedique a tests de intrusión.

Nmap, por excelencia una de las herramientas imprescindibles para el análisis de red y servicios, ha incluido numerosas mejoras (aunque como nos dicen en SecurityByDefault, de muchas cosas ya disfrutábamos desde versiones anteriores), entre las que se incluyen: motor mejorado, libro sobre la herramienta (parte de él está gratis en Internet, si lo quieres entero hay que comprarlo), la herramienta Ncat para hacer las funciones de la ya antigua netcat, y NDiff para poder comparar dos escaneos y ver las diferencias (útil para administradores de sistemas y departamentos de seguridad, que han de hacer una vigilancia continuada). Además, y aunque no sean exclusivas de esta versión, hay dos mejoras que me gustan mucho: el interfaz gráfico mejorado Zenmap, y los scripts NSE, que incluyen muchísimas utilidades.

SQLMap es imprescindible en la realización de test de intrusión sobre aplicaciones web, para explotar vulnerabilidades de inyección SQL, razón por la que la suite w3af la utiliza. Hace unos días se publicó la versión 0.7 (publicitada vía mensajes a diversas listas de correo, entre otros medios), y por lo que veo en el Changelog, los últimos cambios son para dar estabilidad a la herramienta, e incluir numerosas mejoras que permiten aprovechar mejor la integración con metasploit, entre otras cosas. Su autor, B.Damele, es un crack en esto del hacking web y en particular de la inyección SQL, como muestra, se puede ver su material sobre el tema.

¡Que aprovechen!

---

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

MISSP en PYMES

---

¿Qué es un MISSP y por qué puede ser útil? Un Managed Internet Security Service Provider es un proveedor de servicios de internet (ISP), que complementa su oferta al cliente con servicios de seguridad gestionada, como firewalls en red, vpn, detección de spam, o detección de intrusiones.

La idea básica es proteger el acceso a Internet, tanto en tráfico entrante como saliente, desde la propia red del operador en vez de en las instalaciones del cliente. Típicamente será un servicio operado desde un Security Operation Center propiedad del ISP, que deberá contar con soluciones tecnológicas adecuadas y personal especializado.

No es un concepto nuevo, ni mucho menos. Pero tampoco lo conoce todo el mundo ;) . En el FAQ de Sans nos hacen una descripción de qué son, y comentan algunos factores a tener en cuenta antes de decidir si contratar, o no, servicios de estas características. Básicamente:

• si se dispone de la capacidad de generar firmas propias para los sistemas de detección de intrusiones, o si por el contrario, se depende del fabricante del IDS
• ¿se dispone de una variedad de soluciones, que permitan operar sobre entornos tecnológicos variados, o se utiliza una solución global para todo?
• ¿qué medidas de seguridad física se emplean en el SOC?
• ¿qué medidas se han aplicado con respecto a la tolerancia a fallos? ¿Cuál es el proceso de notificación de fallos? ¿Se revisa periódicamente el funcionamiento de los equipos? ¿Existe un sistema de centralización de logs, que permita revisar los mismos en caso de que un equipo se vea comprometido?
• ¿se confía el servicio a personal propio o subcontratado? ¿Se investiga a las personas que componen el equipo, antes de contratarlas? ¿Se realizan acuerdos de confidencialidad en todos los casos?
  
• ¿qué importancia da el proveedor a las certificaciones en seguridad? ¿El equipo que se ocupa del servicio recibe formación contínua, que le permita seguir al día?

A mí personalmente me parece interesante saber cómo el servicio se va a adaptar a las propias necesidades de mi organización, por ejemplo, si me va a proporcionar algún tipo de consola en la que se pueda parametrizar determinados aspectos del servicio, y si se pueden definir políticas y utilizar el servicio proporcionado para vigilar su cumplimiento de forma externa a la organización. También es interesante saber si el servicio proporciona informes en un formato personalizado o por el contrario es genérico, cuál es el detalle de las explicaciones que se proporcionan, si se incluyen servicios de consultoría que ayuden a comprender bien las características del problema que se haya reportado, la probabilidad de que ocurra y el impacto que podría tener, o si mantienen contacto con equipos CERT oficiales.

Otras cuestiones interesantes no tienen que ver tanto con el propio servicio en sí, como con la manera en que el cliente utilizará este servicio. Es el propio usuario el que tiene un conocimiento exhaustivo de su propia organización, y podrá distinguir amenazas reales de las que no lo son. Su gestión de riesgos es el motor del resto de las tareas a realizar en materia de seguridad, no se debe olvidar esto nunca. Una pequeña o mediana empresa podría pensar que contratando un servicio de seguridad gestionado como este resuelve todas sus necesidades de seguridad. Sin embargo, lo que hace es externalizar los medios técnicos necesarios, pero sigue teniendo necesidades organizativas a las que prestar atención.

Así será necesario que se defina un plan de acción en caso de que se detecte un riesgo real, y esto es algo que sólo el personal interno de una organización puede realizar. Sólo los usuarios pueden priorizar adecuadamente sus riesgos, decidir cuál el plazo fijado para la resolución del problema detectado, o establecer cuáles son las medidas de mitigación y supervisión adecuadas a su entorno y a los medios de que dispongan. Y son ellos los que deben definir sus propios planes de contingencia y de continuidad de negocio. Por eso, por ejemplo, en Inteco existe un plan de impulso a la certificación e implantación de un SGSI en la PYME (hay que decir que una empresa que decida implantarlo, obtiene una subvención del Plan Avanza que cubre un elevado tanto por ciento de los costes de implantación).

Slds!

---

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

Notas sobre problema en el TCP

---

La noticia ya es sabida, la anoto para recordar en el futuro... Después de haberse encontrado problemas con el DNS y con el protocolo BGP, y haberse puesto de moda el pre-aviso de vulnerabilidades con objeto de obtener algo de publicidad gratis mientras el descubridor da tiempo a los fabricantes a poner las medidas adecuadas en sus productos, ahora podríamos tener problemas con el mismo funcionamiento de TCP.

En este caso, fue una empresa llamada Outpost24 la que ha anunciado vulnerabilidades que implican la manipulación de la tabla de estados TCP (que registra en qué estado se encuentra una conexión TCP). De momento, no se han dado detalles acerca de cuál es el problema, parece tener que ver son las llamadas SYN cookies, un mecanismo que evita tener que mantener un registro del estado de una conexión, hasta que se termina el proceso de establecer la misma (el llamado TCP three-way handshake). Este mecanismo se utiliza para defenderse de los ataques SYN flood (es decir, evita que si un malote se dedica a lanzar únicamente paquetes de inicio de la conexión TCP, se desborde la tabla de estados TCP).

Se sabe que hay una herramienta llamada "socktress" que explotaría las posibilidades del problema, si bien no está disponible para descarga. Supuestamente, iban a darse más datos en las conferencias T2 de Helsinky, pero realmente no se ha ampliado información.

No creo que esto sea ninguna falsa alarma, porque las personas que han descubierto el asunto son auténticos TCP-ninjas, crearon por ejemplo el escáner Unicornscan. Espero a leer qué nos cuentan ;)

Algunos enlaces:
blog de uno de los autores
Algo de Fyodor
Entrada en Securityfocus
Algo de Hispasec

---

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

Nmap en BlackHat

---

Las últimas novedades de Nmap (versión 4.68 ahora mismo) fueron presentadas en las conferencias BlackHat. Daniel Miessler nos hace un pequeño resumen en su blog, y la ppt se puede descargar por ejemplo en insecure.org. Principalmente:

--reason: la razón por lo que te dice que un puerto está abierto o cerrado.
--top-port: escanear sólo los puertos más utilizados.

Hay que destacar además el nuevo motor para identificar el sistema operativo de la máquina escaneada, el lenguaje de scripting que incorporó en las últimas versiones, y además, la nueva interfaz gráfica, que puede generar un mapa de la red escaneada similar al que hace Cheops (nos indica dmiessler).

Nota final: en septiembre se espera el lanzamiento del libro "Nmap Network Scanning", que promete ser algo a tener en la estantería. Explicará no sólo las opciones de Nmap, sino como aplicarlas adecuadamente en la realización de tests de intrusión, realización de inventarios de red, detectar accesos wireless y proxies abiertos, etc.

Monitorización DNS

---

Sobre la vulnerabilidad de envenenamiento de DNS caché (la de Kaminsky), se ha comentado mucho en qué consiste, cuánto ha sido explotada, etc. Pero se dice muy poco de un aspecto fundamental, acerca de las medidas a aplicar, que es cómo se monitoriza que el comportamiento de un DNS es el correcto, es decir, que no ha sido (o está siendo) atacado explotando este problema. Tampoco se está diciendo (ahora) nada sobre otro tema relacionado, que es cómo utilizar un servidor DNS para detectar malware y analizar su comportamiento.

Buscando información sobre el tema, encontré dos papers sobre cómo utilizar los datos de estadísticas y el propio tráfico del DNS para detectar redes de botnets, y en general, monitorizar el comportamiento del servicio. Son estos:

1. Antoine Schonewille, Dirk-Jan van Helmond: "The Domain Name Service as an IDS" (este aparece también en Sergio Hernando)
2. Bojan Zdrnja, Nevil Browlee and Duane Wessels: "DNS anomalies"

Son una lectura muy buena :) , y por unos días, lo único que voy a poner: ¡es tiempo para un merecido descanso veraniego!. En septiembre volveré con nuevos temas para este blog.

Slds!

Redes para pobres

---

Si uno necesita preparar una red de pruebas, y no hay una red física que sirva de maqueta (algo en lo que sólo una empresa con mucho dinero gastaría), tenemos que invocar a San VMware para que nos salve la vida.

En RaDaJo nos presentan una red de pruebas basada en máquinas virtuales WMware, que han llamado NETinVM. Todas las máquinas de la red utilizan User-Mode-Linux. Ideal para crearnos entornos de simulación, probar herramientas, o crear una demo de una aplicación cliente-servidor.

Tiene buena pinta, así que un poquito de publicidad no le vendrá mal :)