lunes, 17 de noviembre de 2008

Buscador de CheetsSheet

Desde el blog Security by Default leo que han montado una web con una búsqueda personalizada de Google para buscar CheetsSheets de forma cómoda en un número determinado de webs.

Es interesante que contribuyamos con los enlaces que podamos conocer, así tendremos todos un buscador más potente y eficaz. Yo por mi parte ya he dejado un post con 2 o 3 sugerencias.

miércoles, 5 de noviembre de 2008

Ataques clásicos: El gusano de Morris

Hace unos pocos días, el 2 de Noviembre, se cumplieron 20 años de la aparición del primer gusano de Internet, el Gusano de Morris, llamado así por su creador, Robert Tappan Morris, por aquel entonces estudiante de 23 años que liberó en la entonces Arpanet el primer software (conocido) diseñado para auto-replicarse a través de la red.

El gusano no pretendía realizar ninguna acción especificamente maliciosa al infectar equipos, simplemente pretendía infectar el máximo número de sistemas posibles pero, debido a un bug en el código, el gusano provocó unos efectos no deseados, degradando en gran medida el funcionamiento de la red.

El Gusano de Morris explotaba para propagarse vulnerabilidades de los servicios SendMail y Finger, que permitieron que la infección afectara al 10% de los sistemas conectados a la red (unos 60.000 máquinas conectadas en total).
  • SendMail: La vulnerabilidad de SendMail explotada consistía en aprovechar un bug en la opción DEBUG, que si bien no estaba activada por defecto sí que era activada frecuentemente por muchos administradores en tiempo de compilación para facilitar la configuración del complicado SendMail. Este ataque permitía al Gusano de Morris ejecutar en la máquina atacada comandos shell que tenían como objetivo descargar un fichero de código C al que se le pasaban el nombre de Host, Usuario y Contraseña de la máquina origen del ataque para que este descargara una serie de ficheros que posteriormente ejecutaba, enmascarandolos con el nombre de "sh" para intentar que pareciaran ejecuciones de una Shell.
  • Finger: La vulnerabilidad de Finger explotada era debido a un bug que permitiría realizar un Buffer Overflow al pasarle una entrada de datos de más de 512 bytes, proporcionando un acceso Shell al gusano una vez explotado. Esta, según dicen, fue la vía más exitosa de infección del gusano.
  • Rsh/Rexec: Además de explotar las vulnerabilidades anteriormente mencionadas, el Gusano de Morris, una vez dentro de un sistema, intentaba aprovechar las relaciones de confianza del mismo (ficheros .rhosts y /etc/hosts.equiv) para acceder a nuevos sistemas. Para ello en primer lugar necesitaba acceder a las cuentas de los usuarios de la máquina, ya que a través de la explotación de vulnerabilidades anteriores obtenía privilegios de ejecución como "daemon", pero no como "root". Para obtener esas contraseñas utilizaba el campo de descripción del fichero /etc/passwd (llamado campo GECOS) para obtener su nombre y apellido, y de esta manera utilizar combinaciones con este nombre y una lista de contraseñas "habituales" para obtener acceso a las cuentas de los usuarios, y desde ahí aprovechar sus relaciones de confianza para propagare nuevamente.
Para los curiosos, el código fuente del gusano está publicado.

El que tenga algún detalle más sobre este gusano que lo ponga como comentarios, siempre resulta interesante conocer los detalles sobre estos "ataques clásicos".

domingo, 2 de noviembre de 2008

Vulnerabilidad Dan Kaminsky (II)

Después de la entrada Vulnerabilidad Dan Kaminsky (I) donde introducíamos una serie de conocimientos necesarios. Vamos ahora a explicar en qué consiste la vulnerabilidad descubierta durante este verano de 2008. Para poder entender en qué consiste el ataque de Dan Kaminsky deberemos primero entender los siguiente ataques al protocolo DNS:

El siguiente texto es una traducción y recopilación de información obtenida de diferentes fuentes, con la excepción de los gráficos que son obra de www.pentester.es para aclarar aún más si cabe los detalles de la vulnerabilidad.

DNS Forgery

Pueden leer la descripción de este ataque aquí.

Para que quede más claro lo mostraremos con unos gráficos resumidos:






Llegados a este punto por probabilidad el atacante puede adivinar uno de los QID’s generados para las consultas del DNS VICTIMA. Si adivina el QID’s podrá generar una respuesta con lo podrá suplantar la respuesta que debía llegar de OTRO DNS.

DNS RRset poisoning

Pueden leer una traducción y explicación buena aquí.

Ataque de Dan Kaminsky

El ataque está basado en una combinación de los dos anteriores ataques. Y se trata de lo siguiente:

Generamos gran cantidad de querys recursivas de nivel 3 solicitando dominos como aaaa.ejemplo.es, aaac.ejemplo.es, bbbb.ejemplo.es, etc. A la vez que le enviamos la query, enviamos la respuesta hasta que seamos más rápidos que el servidor legítimo y coincida con alguno de los QID’s generados por el servidor DNS a comprometer en sus querys al OTRO SERVIDOR.
Cuando esto pase anotará en la cache una entrada de tercer nivel del estilo ababab.ejemplo.es tiene la ip 1.2.3.4. Esta entrada para lo único que sirve es para envenenar la cache de DNS, y por si solo no vale para nada, ya que nadie va a visitar esta entrada. En ese instante tiene sentido utilizar el segundo ataque que consiste en colocar en los paquetes de respuesta en el campo adicional entradas como www.ejemplo.es, mail.ejemplo.es apuntando a direcciones no legítimas. Estos campos adicionales serán aceptados porque pertenecen al mismo dominio de la petición.

Ejemplo:

- El atacante realiza N peticiones de *.google.es al servidor DNS a comprometer.

- Al mismo tiempo envía respuestas al servidor a comprometer. Esas respuestas llevan en el campo de RR adicionales entradas como:

www.google.es 1.2.3.4
gmail.google.com etc. 1.2.3.4
Siendo estas direcciones NO legítimas.

- En el momento que el QID’s de la petición (servidor dns victima -> servidor dns legítimo) y de la respuesta (atacante -> servidor víctima) coincide se almacena en la cache; al tener los recursos adicionales cualquier petición a www.google.es, gmail.google.es, serás servida por 1.2.3.4 y no por las direcciones de legítimas de Google.

A continuación se muestra un diagrama que trata de comprender todo el ataque:




Espero sobretodo que este último gráfico ayude a entender bien el ataque y en qué consiste.