Temanme! Soy un CEH

Hace un rato termine de rendir el examen CEH "Certified Ethical Hacker" de EC-Council, y después de casi 4hs y 150 preguntas aprobé!

Así que ya saben, soy un Hacker Ético, y encima Certificado... :P

Libro "Hacking Etico"

El amigo Carlos Tori finalmente publicó su libro "Hacking Etico", y ya lo pueden reservar desde: www.hackingetico.com

Como se puede apreciar por el Temario, este libro es un excelente recurso de información para introducirse en las técnicas de intrusión, y conocer las acciones necesarias para asegurar la información.

También les recomiendo descargar la "muestra gratis" del libro en donde se detalla como crackear passwords utilizando Rainbow Tables.

Felicitaciones para Carlos!

Metasploit Hackeado

El ataque se realizo mediante un ARP Poisoning dentro de la misma VLAN en la que se encontraba el servidor de Metasploit. ¿ Cuantos ISP's toman precauciones contra un ataque tan viejo como este ?

NOT A CISSP

El viernes pasado en la Drunked Security Professionals, la meeting semanal que FedeK se encarga de organizar para reunir a los amigos que fueron a la ekoparty, Nico Waisman trajo de regalo para los presentes unos prendedores con el mensaje "NOT A CISSP":

Como no tenía nada que hacer, me puse a reflexionar sobre el significado que tiene este prendedor. En mi opinión, estamos hablando de algo mucho más profundo que el simple mensaje "No Tengo la Certificación CISSP", sino que también nos habla del valor que tienen hoy en día las certificaciones de seguridad.

CISSP es sin dudas una de las certificaciones más respetadas dentro de la seguridad. No solo hay que rendir un examen, sino que para poder rendirlo te tiene que recomendar otro CISSP, hay que poseer varios años de comprobada antigüedad como profesional, y en algunos casos hasta pueden llegar a hacerte una auditoria para comprobar tus antecedentes.

Pero poseer una certificación como CISSP, ¿ es realmente un aval del conocimiento práctico que puede tener un profesional en la vida real ?

¿ Porqué algunos avisos de trabajo para el área de seguridad de Google tienen la leyenda casi desafiante: "CISSP not required. Relevant experience must be hands-on." ?

En el caso particular de CISSP, pienso que esta más orientada a managers que técnicos, y si bien creo CISSP avala una excelente base de conocimientos de seguridad en un profesional, definitivamente esto no significa experiencia práctica en la vida real.

Escucho sus comentarios...

Evadiendo Snort con Paquetes Fragmentados

Hace unos días, iDefense publico un advisory sobre una vulnerabilidad en el preprocesador Frag3 de Snort que permitiría evadir la detección de un ataque con paquetes fragmentados.

Definitivamente esta vulnerabilidad no tuvo el mismo impacto mediático que la catástrofe criptográfica de Debian, pero que todas las redes protegidas por Snort, hayan sido susceptibles a ataques de los que nadie se ha enterado, no es para nada poca cosa.

Parte del advisory de iDefense decía lo siguiente:

"Due to a design error vulnerability, Snort does not properly reassemble fragmented IP packets. ... In order to exploit this vulnerability, an attacker would have to fragment IP packets destined for a targeted host, ensuring that the TTL difference is greater than the configured maximum. By default, the maximum difference is 5."

¿ Cuál es el problema ?

Básicamente, el problema se debía a la opción "ttl_limit" de frag3, que por default tiene un valor de 5. Esto significa que si llegaba un fragmento con una TTL de 40, y luego otro con una TTL de 46, debido a la vulnerabilidad encontrada estos fragmentos no serían controlados por la política de Snort.

Al parecer esto se debió a un error de concepto introducido en Snort 2.6 y 2.8, y que ha sido corregido por Sourcefire en el nuevo release 2.8.1. iDefense también propone un workaround a este problema, que consiste en llevar el "ttl_limit" a su valor máximo de 255.

¿ Qué es frag3 y porque controla la TTL ?

frag3 es un preprocesador de Snort. Un preprocesador sirve para detectar ataques que no pueden ser detectados mediante una comparación de firmas, o para normalizar datos que luego si puedan ser detectados por comparación de firmas. En particular, el preprocesador frag3 se encarga de reensamblar paquetes fragmentados para poder comparar el payload con firmas de ataques.

Una de las técnicas mas usadas para evadir un IDS es la fragmentación de paquetes, por lo que frag3 no solo reensambla los paquetes, sino que también verifica que no se este intentando realizar una evasión mediante paquetes fragmentados, y aquí es en donde entra en juego el control de la TTL.

frag3 posee 2 opciones para controlar la TTL, una es "min_ttl" y la otra es "ttl_limit", en la cual se descubrió la reciente vulnerabilidad. Veamoslas un poco más:

- min_ttl: Indica el valor mínimo de TTL que debe tener un paquete para ser aceptado. Esto es útil para detectar ataques de evasión en los que entre nuestro IDS y el target hay un router. La idea de estos ataques es enviar un paquete fragmentado con una TTL muy chica que al pasar por el router expire.

Por ejemplo, mandamos 3 paquetes fragmentados a un target, el primero y el tercero poseen un payload de ataque y una TTL alta, mientras que el segundo paquete posee un payload con datos basura y una TTL muy chica. Cuando Snort reensamble los 3 paquetes, se mezclará el payload de ataque con los datos basura, y ninguna comparación de firmas detectará el ataque. Como el segundo paquete tiene una TTL muy chica, va a expirar cuando pase por el router, y solamente llegarán al target el primer y el tercer paquete, que efectivamente tenían el payload de ataque.

- ttl_limit: Como ya dijimos, esta opción controla la diferencia máxima del valor de la TTL que puede haber entre paquetes fragmentados con el mismo ID de fragmentación. Según se ha publicado, esto es un error de diseño que ya se venía arrastrando de versiones anteriores de Snort con frag2, y que en el futuro será descontinuado.

Al parecer, esta opción fue agregada porque herramientas como Fragroute, para realizar ataques de evasión con paquetes fragmentados, configuraban los campos de los paquetes con valores al azar que raramente se veían en tráfico normal. Por ejemplo, una diferencia de TTL de hasta 5 saltos podría llegar a ser normal ya que es posible que un paquete haya tomado una ruta mas larga, pero según entiende Snort más de 5 saltos ya es algo más raro.

Bueno, saludos a todos los administradores de Snort que seguramente deben tener mucho trabajo, primero corrigiendo esta vulnerabilidad, y después averiguando si en algún momento los han hackeado sin enterarse ;-)

Más info:
- iDefense Advisory
- Diff for /preprocessors/spp_frag3.c
- Snort: Frag3
- Eluding Network Intrusion Detection
- SecurityFocus: Evading NIDS, revisited