jueves, 30 de octubre de 2008

CheatsSheet: Análisis de Malware

Aquí tenemos otra Cheats Sheet sobre Análisis de Malware desarrollada por Lenny Zeltser, certificado GIAC GSE e Instructor de SANS.

La información resumida en este material forma parte del curso SEC610: Reverse-Engineering Malware, impartida por él mismo:



El documento puede ser descargado desde la propia web del autor (versión inglés) tanto en WORD como en PDF, así como de www.pentester.es (versión en castellano), igualmente tanto en WORD como en PDF.

miércoles, 22 de octubre de 2008

TCPDUMP & WIRESHARK

Cualquiera que se dedique a esto de la seguridad sabe el uso intensivo que se hace de estas dos herramientas: TcpDump y WireShark.

Para el que no lo sepa, estas dos herramientas son sniffers de red, en modo texto el primero y con interface gráfico el segundo (aunque también tiene una versión en modo texto llamada TShark, muy buena). ¿Para que necesitamos en seguridad hacer sniffing de red?, pues basicamente para análizar tráfico, o bien cuando hacemos una auditoría de seguridad de un producto que transfiere datos a través de la red y queremos valorar la seguridad de estas comunicaciones, o bien en el día a día de la detección de intrusiones, cuando el NIDS detecta un posible ataque siempre es muy útil disponer de una captura completa del paquete de red y si es posible de la conexión entera, con el fin de análizarlo y descubrir si se ha tratado de un falso positivo o de un ataque real.

El caso es que ambas herramientas tienen su propio lenguaje para limitar que tipo de tráfico queremos analizar, algo muy útil si queremos centrarnos en un tráfico concreto, pero que muchas veces nos pueden surgir dudas (sobretodo con Wireshark) de como sería la opción para capturar una serie concreta de paquetes. Por ello, os remitimos una Cheats Sheet publicada en la web PacketLife en la que tenemos una referencia rápida de estas dos grandes herramientas:



Podeis pinchar en las propias imágenes para descargar el PDF, os recomiendo tenerlo a mano, yo pienso hacerlo.

También cabe destacar que la web PacketLife dispone de una sección de Cheats Sheets muy buena, puede que os interese a más de uno pasaros y descargaros alguna.

Un gran trabajo el del autor de PacketLife.

viernes, 17 de octubre de 2008

Romper WPA/WPA2 con GPU's ? Falacias!

Se ha publicado recientemente, que la empresa ItWire, ha desarrollado una nueva tecnología que permite utilizar la GPU de la tarjeta gráfica para incrementar 100 veces la capacidad de cálculo de la CPU, permitiendo romper el cifrado de WPA/WPA2. Permitidme una sarcástica carcajada para lo que es un phising comercial en toda regla y veamos porque:


Dado que la longitud mínima de una PSK de WPA o WPA2 es de 8 caracteres y el alfabeto manejado es de [A-Za-z0-9Sym32] tenemos (29+29+20+32)^8 =21.435.888.100.000.000 posibles palabras del lenguaje. Dado que los procesadores actuales mas potentes (utilizando el algoritmo de aircrack) pueden a lo sumo barrer 400 palabras por segundo (y soy muy benevolo) . Multiplicado por la capacidad de procesamiento de la gran NVIDIA nos da 400.000 palabras del lenguaje por segundo. Hechando calculos...


Se tardaría 1699,318881596 años es barrer todas la posibles cadenas, eso suponiendo que has acertado don el ESSID (ya que la cadena de cifrado depende de él) y que la PSK es de SOLO DE 8 CARACTERES! como bien sabes la longitud de la cadena en WPA puede ser mayor de 60 caracteres.


Así que este producto esta bien, sí , pero esta muy muy lejos de lo que anuncian, y es mas un phising comercial que otra cosa. He visto varios de estos como gente que vende colecciones de DVD's con tablas precomputadas que te aseeguran que rompen todos las claves WPA, falacias. El verdadero problema de seguridad de WPA son los usuarios y solo será vulnerable cuando rompan el cifrado(RC4/AES).

Por si os gusta el tema de aparatillos hardware que permiten incrementar la potencia de calculo, picocomputing contruye mediante ASICs y FPGAs dipositivos que pueden llegar a barrer 1000 palabras por segundo.

lunes, 13 de octubre de 2008

¿Estoy enfermo doctor?

Tal y como escribe Lorna Hutcheson en su post en el ISC de SANS, muchas veces el problema a la hora de comenzar un proceso de Incident Handling es que los afectados ni siquiera se dan cuenta de que han sufrido un incidente de seguridad.

Según el SANS Institute, el proceso de Incident Handling tiene unas etapas definidas, de las cuales las dos primeras (Preparación y Detección) son de especial importancia en el día día de las empresas, ya que en caso de no cumplirse dificulta mucho el análisis forense posterior, y por lo tanto aumenta las posibilidades de que el mismo incidente o similar pueda volver a ocurrir.

Por ello, y partiendo de la base que no se ha realizado una fase de preparación muy adecuada (IDS, capturas de tráfico de red, logs almacenados remotamente en las máquinas, etc), este artículo de SANS nos da 10 indicadores/síntomas de que podemos estar sufriendo una intrusión. Evidentemente esto no es la panacea, pero si no hemos realizado una fase de preparación pueden resultar útiles para saber cuando debemos acudir a un especialista en seguridad.

Este es el decálogo, mis comentarios van en cursiva:
  1. Tu servidor de logging no registra nada o no has recibido alertas en las últimas 12 horas <- Generalmente hay actividad, si no recibes nada no quiere decir que tus sistemas se han vuelto más perfectos por si solos o que los atacantes han reconocido tu superioridad y han dejado de atacarte, probablemente ya los tienes en casa y simplemente están impidiendo que te lleguen las alertas
  2. Los discos de tu servidores FTP o de tus usuarios de repente se han llenado o quizá los logs han crecido a un tamaño no habitual
  3. Los productos de la competencia se parecen a los tuyos, con pequeños cambios <- o están ofreciendo servicios similares a los tuyos por precios ligeramente inferiores a tus mismos clientes, cuando el precio de tus servicios no es algo público
  4. Tus compradores empiezan a recibir Spam en la cuenta que solo usaban para tus servicios <- cuidado con las contraseñas de clientes, la mayoría de personas utilizan las mismas contraseñas para clientes/proveedores que para la propia empresa, así que si sufres una intrusión puede que gran parte de tus clientes se puedan ver afectados
  5. Los usuarios reportan cosas como ventanas cerrandose por si mismo, página de inicio del navegador cambiada, etc -> En general, cualquier comportamiento anómalo puede ser señal de una intrusión o virus
  6. Alguien necesita ayuda para conectarse a la Wifi de la compañía y la compañía no tiene ninguna Wifi <- casi todas las empresas tienen hoy en día Wifi, pero es una técnica habitual abrir un Rogue AP para intentar hacer un MitM a los usuarios
  7. Te das cuenta de que el software da errores o se cuelga de repente (software de pagos, navegadores, etc) <- en ocasiones es lo normal, pero si empieza a dar errores de forma más seguida hay que confirmar si se trata de algún parche reciente del fabricante que ha producido inestabilidad (esto es bastante habitual) o si puede haber otras razones (binario cambiado, librerías cambiadas, etc)
  8. Te notifican los usuarios que su contraseña no funciona <- una cantidad de usuarios bloqueados o que se han olvidado la contraseña es normal, pero si este número aumenta mucho puede que nos estemos viendo afectados por un ataque de fuerza bruta que está bloqueando a los usuarios de los que intentan obtener contraseña. Quizá en el momento que nos damos cuenta ya ha obtenido una clave y está dentro de nuestros sistemas
  9. Los sistemas funcionan de forma inusualmente lenta <- medirlo con medios objetivos, recordad que para los usuarios los sistemas SIEMPRE funcionan de manera inusualmente lenta. Si por contra el administrador verifica la lentitud es conveniente verificar el sistema y las comunicaciones, y si aún así no encontramos el motivo no es conveniente dejarlo pasar, quizá no veamos el proceso que provoca la carga porque está oculto mediante algún tipo de rootkit o similar
  10. Los visitantes a tu web corporativa notifican que son redirigidos a otra o que simplemente no tiene el mismo aspecto de siempre <- esta es evidente, demasiado evidente, un defacement de la web puede ser un objetivo en si mismo, en cuyo caso no tienen que haber llegado al resto de sistemas o puede ser una medida de distracción para centrar los esfuerzos de los técnicos y que no nos demos cuenta de que otras actividades anómalas están teniendo lugar en nuestra red

Evidentemente lo mejor es montar detectores de intrusos basados en red y en host, análisis (automático si es posible) de logs y generación de alertas en caso de producirse anomalías, etc, pero al menos con este decálogo de SANS tenéis la opción de salir airosos de un incidente y, quizá para la próxima vez, implantar medidas de Preparación y Detección para que si vuelve a ocurrir seamos capaces de detectarlo tempranamente y de disponer de la máxima cantidad de información posible

Finalizo el post con una gran frase que me dijo un profesor cuando estudiaba en la universidad: "Todo administrador de sistemas sufre alguna vez alguna intrusión en su vida, no importa lo experto que sea, pero sabe enfrentarse a ella y hacer una correcta gestión del incidente. El administrador que os diga que NUNCA ha sufrido una intrusión en sus sistemas es que sencillamente nunca se dio cuenta de ello".

Una gran frase, sin duda, y un buen decálogo, gracias SANS.

viernes, 3 de octubre de 2008

Resucita el Ping de la Muerte

Todos recordamos aún el ataque DoS que fue conocido hace años como el Ping de la Muerte, que consistía en aprovechar un error en practicamente todas las implementaciones de las pilas TCP/IP de todos los fabricantes de sistemas operativos y electrónica de red (Unix/Linux, Windows, impresoras, routers, firewalls) para mandar un ICMP de tamaño superior al máximo permitido por el protocolo, pero fragmentado, de tal manera que al ser reensamblado superaba el tamaño máximo permitido y producía una denegación de servicio en la máquina que realizaba el "desfragmentado".

Pues bien, esta vulnerabilidad que fue corregida por los fabricantes a lo largo de 1997 parece que ha vuelto a resucitar, no porque se haya encontrado una vulnerabilidad idéntica, sino por el descubrimiento de una técnica similar que recuerda mucho a este ataque debido a lo difundido que está el fallo y a no necesitar requisitos grandes de ancho de banda ni disponer de un botnet ni nada parecido para realizar el ataque.

La vulnerabilidad fue descubierta por los desarrolladores del conocido escaneador de puertos Unicornscan que, según sus propias palabras, mientras realizaban unas pruebas con la herramienta se dieron cuenta que en determinadas circustancias el sistema escaneado respondía a algunos paquetes continuamente hasta que el sistemas dejaba de funcionar y era necesario realizar un reinicio para que recuperara su correcto funcionamiento.

Por lo que se ha podido saber de la vulnerabilidad entre los datos publicados y un "intercambio de posts" entre Fyodor (desarrollador de nmap) y Robert Lee (uno de los descubridores de la vulnerabilidad) parace ser que se trataría de una especie de "SYN de la Muerte", debido a que parece tener algo que ver con la manera en que almacena las conexiones activas una pila TCP/IP cuando recibe un SYN. Además, por una frase que leo en alguno de estos artículos, la herramienta sockstress desarrollada como prueba de concepto (aunque no ha sido publicada) permitiría entre sus parámetros definir IP de origen y de destino, lo que me lleva a pensar si estos parámetros estarán destinados a realizar Spoofing de IP (con lo cual ya sabemos que el DoS está basado únicamente en el paquete SYN) o si por el contrario el ataque es del tipo Echo-Chargen y consiste en hacer que el sistema se reenvie paquetes hasta que se colapse por si mismo.

En cualquier caso, los fabricantes ya están trabajando para lanzar los parches de seguridad adecuados, que serán publicados el día 17 de Octubre, justo antes de que los descubridores de la vulnerabilidad den los detalles técnicos en la T2 Security Conference de Finlandia.

Estemos todos atentos a la publicación de los parches y apliquemelos cuanto antes, antes de que empiecen a aparecer herramientas DoS "on the wild", recordad que esta vez no hace falta disponer de una botnet, un atacante solo necesita lanzar unas pocas conexiones para detener el servicio de nuestras máquinas.

miércoles, 1 de octubre de 2008

Vulnerabilidad Dan Kaminsky (I)

Como es de suponer muchos de vosotros habréis leído por infinidad de sitios sobre la vulnerabilidad de DNS que ha provocado un revuelo considerable.

En esta entrada voy a "intentar" explicarla con un poco detalle para quien tenga curiosidad de cómo se producido y por qué.
Los requisitos para no perderse demasiado es saber cual es básicamente el funcionamiento del protocolo DNS. Para esto aconsejo los siguientes enlaces que lo explican y dan una visión general:

Wikipedia
Video tutorial

Una vez ya tenemos claro el mecanismo del protocolo DNS de manera genera y para que sirve, empezaremos en esta primera entrada explicando aquellas partes del protocolo implicadas en la vulnerabilidad para que después sea más fácil comprenderla:

Descripción del protocolo DNS

Lo primero que debemos saber y refrescar es cual es la estructura de un mensaje del protocolo rfc1035: Lo primero de todo es saber que un mensaje DNS se estructura 5 secciones:


  1. Header
  2. Question
  3. Answer
  4. Authority
  5. Additional

A continuación se explicarán brevemente las secciones relevantes para entender la vulnerabilidad, no siendo el objetivo de esta entrada explicar todo acerca del protocolo, pero sí lo suficiente. Por lo que se explicarán Header, question y Additional Records.

1. Header

ID: Identificador de 16 bits que genera el que realiza la petición, este identificador se copia en la respuesta y puede ser utilizado por el que realiza la query para como que es la respuesta a su petición; pudiendo descartar respuestas de un tercero.

QR: Especifica si es una pregunta ó una respuesta.

Opcode: Indica el tipo de query.

AA: Si este bit está activo indica que el servidor de nombres que contesta es una autoridad del nombre de dominio.

TC: Mensaje truncado en la transmisión. RD: Si está activo le indicamos al servidor que continue la pregunta recursivamente. RA: En un respuesta nos indica si está activo si el servidor permite recursión. Z: no se usa. RCODE: Indica el tipo de respuesta. QDCOUNT: número de entradas en la sección de la pregunta. ANCOUNT: número de entradas en la sección dedicada a la respuesta. NSCOUNT: número de entradas en la sección dedicada a la AA. ARCOUNT: número de registros en la sección adicional.

2. Question


QNAME: nombre de dominio

QTYPE: tipo de query.


QCLASS: clase query.

3. Additional Records (Resource Record)


NAME: Nombre de dominio al cual este RR pertenece.

TYPE: contiene el tipo de RR. Especifica el significado de los datos de RDATA.

CLASS: especifica la clase de datos del campo RDATA.

TTL: Tiempo en segundos que el RR puede ser cacheado/almacenado, después debería ser eliminado. El valor de cero indica que no almacenes.

RDLENGTH: tamaño del campo RDATA.

RDATA: Variable que describe el recurso.

Ejemplo de una petición DNS

Esto sería el contenido de una query preguntando por www.google.es:


Ilustración 1: Query DNS

Observamos como tiene el bit Recursion Desired a 1 y el campo Questions a 1.

Lo siguiente sería la contestación del servidor DNS:

Ilustración 2: Response

Lo primero que se observa es como el ID es el mismo tanto en la pregunta como en la respuesta. Vemos como la respuesta incluye 5 recursos derivados de su pregunta, 2 alias y 3 registros de tipo host (A) que indican la dirección de red. Además vemos 7 Authority nameservers y 7 RR’s adicionales.

Con esto hemos visto cuales son los registros del DNS que después nos ayudarán a entender un poco mejor el ataque de Dan Kaminsky y cómo se realiza una petición sensilla a un servidor DNS. En una entra posterior veremos ataques existentes y el nuevo descubierto por Dan Kaminsky.