13 diciembre 2012

Cómo no hackearon el whois de facebook.com

Este lunes se cayó Facebook. Entre los posibles motivos que circularon sobre su caída se encontraba el de que habían hackeado su DNS. Este rumor se fundaba en que en ese momento alguien hizo un whois desde la consola al dominio facebook.com y se encontró lo siguiente:

whois de facebook.com

Efectivamente, Facebook no ha puesto eso ahí ni creo que le haga muy feliz verlo. Pero no han hackeado su DNS ni la base de datos de Whois, como se llegó a decir. Al menos no en el significado más extendido de la palabra hackear.

Es un hack en el significado de que se ha aprovechando de una forma original una característica de un sistema para un fin para el que no estaba previsto (spam, básicamente) y es algo que se lleva haciendo con los dominios más populares desde antes incluso de que existiera la primera red social. Lo sufren, entre otros, Google, Yahoo, Microsoft y prácticamente cualquier dominio popular que se nos ocurra.

Si nos fijamos, lo que nos muestra son subdominios de otros dominios que no tienen nada que ver. Por ejemplo, facebook.com.more.info.at.www.beyondwhois.com es un subdominio de beyondwhois.com y yo diría que su propietario tiene algo que ver con que ese subdominio aparezca ahí.
Pero espera, ¿subdominios? ¿No se supone que whois es sólo para consultar información de registro de dominios y no debería listar subdominios? Pues no exactamente.

El uso más popular de whois es comprobar los datos de un dominio (titularidad, registrador, DNS, etc.) pero tiene más usos, como obtener el rango y operador al que pertenece una dirección IP o la conectividad de un sistema autónomo.

Fijándonos en la respuesta del servidor a algunas peticiones de whois veremos qué tipos de datos nos está dando:
  • inetnum:        1.1.1.0 - 1.1.1.255
    Nos está dando información sobre un rango de direcciones IP.
  • as-block:       AS3209 - AS3353
    Nos da información sobre un sistema autónomo.
  • Domain Name: FACEBOOK.COM
    En esta respuesta nos incluye información sobre un dominio.
  • Server Name: FACEBOOK.COM.LOVED.BY.WWW.SHQIPHOST.COM
    En este caso, sin embargo, la información se refiere a un servidor DNS.
Bien, ya tenemos la primera pista: las entradas 'falsas' son de distinto tipo (servidores de nombres) que la 'real' (nombre de dominio). De hecho, si en la solicitud a whois indicamos que queremos información sobre un nombre de dominio, los demás subdominios ya no aparecerán:

whois domain facebook.com

Ahora ya sabemos que las otras entradas que aparecían eran servidores DNS.
Pero entonces, ¿whois también nos lista servidores DNS? Parece que sí, vamos a comprobarlo:

whois a.ns.facebook.com

Efectivamente, así es. ¿Por qué sucede esto?

En la respuesta que nos da el servidor whois podemos ver que también se incluye la dirección IP a la que apunta ese subdominio. Este es un registro glue.
Vamos a ver en qué consiste y qué utilidad tiene, pero primero vamos a recordar cómo funciona la resolución de un nombre de host obviando algunos detalles:
  1. Queremos acceder a www.google.com así que le preguntamos a los servidores raíz root-servers.net.
  2. root-servers.net nos dice que debemos preguntarle a gtld-servers.net ya que es el NS que figura para la zona com.
  3. gtld-servers.net nos dice que debemos preguntarle a ns1.google.com ya que es el NS que figura para la zona google.com
  4. ns1.google.com finalmente nos da la dirección IP de www.google.com
Podemos reproducir todo este proceso con dig:

dig www.google.com

Como podemos ver, cuando root-servers.net nos dice que preguntemos a gtld-servers.net, añade una sección adicional a la respuesta en donde nos dice las direcciones IP de gtld-servers.net y lo mismo cuando gtld-servers.net nos dice que preguntemos a ns1.google.com. De esta forma, evitamos más consultas DNS para tener que resolver también esos nombres de host. Y esta es la primera utilidad de los registros glue.

registros glue gtld-servers.net y google.com

Ahora supongamos que Google no hubiese creado registros glue para sus NS, volvamos repasar los pasos anteriores para poder resolver www.google.com:
  1. Queremos acceder a www.google.com así que le preguntamos a root-servers.net.
  2. root-servers.net nos dice que debemos preguntarle a gtld-servers.net ya que es el NS que figura para la zona com y además nos da las direcciones IP de gtld-servers.net.
  3. gtld-servers.net nos dice que debemos preguntarle a ns1.google.com ya que es el NS que figura para la zona google.com
  4. gtld-servers.net no nos dio la dirección IP de ns1.google.com (no tiene glue record) y nosotros no la sabemos, así que tenemos que inicar otra petición para resolverlo.
  5. Pedimos a root-servers.net que nos resuelva el dominio ns1.google.com.
  6. root-servers.net nos dice que debemos preguntarle a gtld-servers.net ya que es el NS que figura para la zona com y además nos da las direcciones IP de gtld-servers.net. (= paso 2)
  7. gtld-servers.net nos dice que debemos preguntarle a ns1.google.com ya que es el NS que figura para la zona google.com (= paso 3)
  8. ... (= paso 4)
Entraríamos en un bucle sin fin, del que sólo salimos si creamos un registro glue para que los servidores raíz conozcan la dirección IP de los NS.

Bien, ¿qué tiene todo esto que ver con el caso de los subdominios falsos en el whois de facebook.com? Pues que son simplemente registros glue. Cuando hacemos una petición a whois por facebook.com sin decirle el tipo, busca en todos los tipos de registro que conoce (nombres de dominio y registros glue) los que empiezan por facebook.com.

Así que estos spammers lo que han hecho ha sido crear subdominios de sus dominios que sean registros glue para que aparezcan en las búsquedas de whois.

Artículo cortesía de Jesús Pérez 

3 comments :

Tommy dijo...

Genial !! Una explicación muy buena

Thomas dijo...

Buen artículo
El lunes par la noche no me funcionaba Facebook. Hice un nslookup y no resolvía. Probé cómo un par de servidores DNS pero seguía sin resolver. En verdad me quedé un poco perplejo!

Alex dijo...

Buena explicación, desconocia el comando dig.