jueves, 27 de noviembre de 2008

Aire Fresco en Information Gathering

La pasada semana tuve la suerte de poder desplazarme a Barcelona junto con unos compañeros de trabajo para poder asistir al IV OWASP Meeting Spain, en la que se trataron diversos temas sobre el nuevo framework para auditoría web w3af, el análisis de eco de aplicaciones web, la visión de Microsoft sobre la seguridad de sus propias aplicaciones e Information Gathering.

La que os vengo a comentar hoy (las otras ya las comentaré en otro momento) es la presentación que hizo




  • Google Sets: Otro gran trabajo de Google que nos facilita mucho el trabajo. Imaginad que vemos las cabeceras de un correo, o realizamos una transferencia de zona y vemos el nombre de tres máquinas: "turia", "ebro" y "jucar". Sólo tenemos que introducirlas en Google Sets y este relaciona las tres palabras y nos da uno montón de palabras más relacionadas con estas. Esto resulta muy muy útil sobretodo porque los administradores de sistemas tienden a poner nombres de una temática similar a sus sistemas, por lo que esta lista puede ser de mucha utilidad para realizar una resolución inversa de nombres y descubrir nuevos objetivos. Poniendoselo difícil a Google, intento introducir "shodan", "nidan", "sandan" (números en Japonés) y efectivamente lo reconocer y me saca una lista con otros números en Japonés.
  • Pipl: Web que le metes el nombre de una persona y te saca todas las referencias que encuentra de una persona, muy interesnte también. He probado a poner mi propio nombre y hasta sale una referencia a un compañero de carrera que me incluyó en los agredecimientos de su Proyecto Final de Carrera.
  • UserCheck: Esta es una web que cuando vi la presentación sencillamente me encantó, tiene referencia a un montón de sitios web y redes socialesa las cuales consulta para saber si un nombre de usuario concreto está dado de alta en alguno de ellos. Sin embargo, no he podido encontrar la web, si alguien sabe donde está por favor que ponga comentario.
Otro día os comentaré cosas de otras presentaciones que tampoco tuvieron ningún desperdicio.

ACTUALIZACIÓN 31/12/2008: Según leo en el blog personal de Christian Martorella, la web de UserCheck estaba en realidad en www.usernamecheck.com, desde este enlace sí que se puede ver la web que aparece en la presentación.

jueves, 20 de noviembre de 2008

¿Ataque a Ministerios.es?

Hace unas horas ha pasado por mis manos un correo electrónico de estos en cadena diciendo que la web www.ministerios.es había sufrido un defacement por parte de algún seguidor de la Huelga de Ingenieros Informáticos del 19 de Noviembre. Tras comprobar el enlace, efectivamente nos encontrabamos con la siguiente web:


Hay que ser un poco cautos, no sería la primera vez que alguien registra un dominio que parece corresponderse con una entidad o persona física (pasó hace poco con un conocidísimo político catalan que no disponía del dominio .es correspondiente a su nombre) y lo hace pasar como una web hackeada.

Vamos rapidamente a www.nic.es para obtener más detalles sobre este dominio y observamos lo siguiente:



Como podemos ver la persona registradora es una "Persona Física", al contrario de lo que sucede con otros dominios como mec.es, que está a nombre del propio Ministerio de Educación y Ciencia, por lo que en principio nos haría pensar que se trataría de uno de estos "defacements falsos".

No obstante, hay dos cosas que me resultan inquietantes, en primer lugar el dominio no se acaba de registrar, sino que lleva años ofreciendo servicio, y en segundo lugar, si buscamos la web en archive.org (ya comentaré el uso de esta herramienta en otro post) podemos ver que efectivamente ha estado ofreciendo servicios de "índice" de las webs ministeriales. Además, buscando el nombre de la persona propietaria del dominio enconrtamos en LinkedIn un consultor de SAP de la empresa HP, que en principio no parece tener nada que ver con ningún Ministerio.

Todo esto me hace plantearme varias posibilidades:
  1. Un particular lleva años ofreciendo este servicio de manera desinteresada y un intruso ha aprovechado alguna debilidad en el proveedor del hosting para hacer un defacement.
  2. Idem que el anterior pero el propietario del dominio, en apoyo de las movilizaciones del día 19 de Noviembre ha decidido simular un defacement en su web.
  3. Existe una relación no inmediata entre dicha persona y los Ministerios

¿Qué opinais?

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.