Que Internet se ha metido en nuestras vidas de lleno desde hace unos años está claro tiempo atrás. Familiares y amigos se comunican por los servicios de las redes sociales diariamente, mucho más incluso que en el mundo físico sin necesidad de smartphones y conexiones de datos. Y ayer, muchos de ellos, fueron conscientes de cuánto lo necesitan. Se dieron cuenta que no funcionaba el Twitter, y por tanto los haters no podía desahogarse. Se dieron cuenta de que no funcionaba WhatsApp, y por tanto no podían pasarse memes, pero tampoco funcionaba NetFlix y no podían poner a las niñas a Masha y el Oso para que estuvieran calmados o escuchar música en Spotify mientras hacía running.
Figura 1: "Winter is Comming" Algunas reflexiones sobre el DDOS que tumbó Twitter y Whats y alertó al mundo |
La lista de servicios - de los masivos - que se vieron afectados fue larga. XBOX, Twilio, Paypal, Play Station Network o CNN también estaban entre los afectados. Y entonces sí, entonces el mundo más allá de los que saben qué es una dirección IPv4 o una dirección IPv6 se empezó a preguntar... ¿Qué está pasando aquí? ¿Qué ha sucedido que sí que está afectando a mi vida?
La respuesta era tan sencilla, como tan difícil de hacer entender a la gente. Fue un ataque DDOS masivo contra los servidores DNS de una de las empresas que dan soporte a muchos de estos servidores y a muchos de los usuarios. Un ataque contra la petición de resolución de nombres que corta el contacto entre los clientes y los proveedores de servicios. Ya está, no funcionan los DNS y la infraestructura de Internet comienza a fallar
Los DNS en Internet
Que los DNS son una pieza clave en la infraestructura de Internet es algo que lo sabemos desde hace mucho tiempo. Si estos están atacados por un DDOS y no pueden resolver los nombres de dominio se acabó la conectividad, pero ya en el pasado hemos visto otros fallos, como el de Dan Kaminsky, que podrían haber tumbado todos esos servicios de igual forma modificando los valores de las respuestas a las direcciones IP.
Internet no nació pensando en todos estos ataques, y muchos servicios han ido evolucionando su funcionamiento añadiendo capas de seguridad sobre los estándares originales, como es el caso del DNS, pero que aún no se ha añadido globalmente en todos los servidores, donde muy pocos utilizan a día de hoy, por poner un ejemplo, DNSEC para firmar las resoluciones de los valores dados. Contra el caso de un ataque DDOS el problema no recae en el servicio DNS, sino en la red en sí.
Figura 2: Verificación de Web Browser en CloudFlare |
Supongamos el caso de un ataque de denegación de servicio contra la página web de una empresa. Si un adversario quiere hacer un DDOS, a nivel de HTTP se puede poner una Cloud por delante que filtre los bots atacantes de los usuarios legítimos, como hace por ejemplo CloudFlare, pero si se hace a los servicios DNS deben ser los routers que procesan las peticiones TCP o UDP sobre las que lleguen las peticiones DNS de resolución las que discriminen si esa petición llega desde una máquina legítima o no. Tarea un poco más compleja.
Un ejemplo de Anti-DDOS
Supongamos que la empresa DYN, objetivo de este ataque concreto, quiere detener este DDOS. Para ello, debe tener un red de protección previa a que el tráfico llegue a sus servidores. Si no fuera así, todo el tráfico del ataque DDOS llegaría hasta su red y, aunque lo detectase y lo descartara con un "drop", las peticiones de servicio no podrían ser procesadas porque el tráfico de llegar hasta el router ya está colapsado. Es decir, el paquete no-malicioso sería como un comprador habitual de un establecimiento que no puede llegar a la puerta del establecimiento porque es día de rebajas y está colapsada la puerta por las personas que vienen a por las ofertas.
Para ello, la empresa debe tener una red previa, proporcionada por el operador que le proporciona las conexiones a Internet, que fuera eliminando - antes de que lleguen a su router - las peticiones. Es decir, supongamos que el supermercado que tiene la puerta colapsada en día de rebajas decide poner en las 4 esquinas de las calles desde las que les llegan los compradores de rebajas cuatro puntos de control. Así, el tráfico masivo de nuevos compradores se dividiría por 4, quedando solo el 25% en cada punto de control. El comprador habitual pasaría uno de esos puntos de control con solo el 25% del tráfico del ataque para que luego, en la puerta de entrada del supermercado solo se encuentre y comparta entrada con otros compradores habituales.
Si el tiempo de cruzar uno de esos cuatro puntos de control fuera aún muy lento, lo que debería considerar el supermercado es en contratar más personas para procesar en menos tiempo el 25% del tráfico que pasa por cada uno de esos puntos de control o crear nuevos puntos de control en una capa más alejada, para conseguir un mayor desglose del tráfico.
Así es como funcionan los sistemas escudo que dan los ISPs desde la red, utilizando tecnologías como ARBOR para crear lo que se denominan escudos AntiDDOS proporcionados desde la red, que es lo que parece que podría haber hecho DYN para conseguir proteger sus servicios DNS, es decir, llamar a su proveedor de conexiones de red y solicitar la contratación de estos escudos Anti-DDOS desde la red.
¿Cómo se puede conseguir tanta potencia para hacer un ataque DDOS tan fuerte?
Los ataques DDOS a los servidores DNS pueden ser hechos de mucha forma. Ya vimos en el pasado - hace ya unos añitos - como se habían conseguido hacer ataques de gran potencia de tráfico mediante vulnerabilidades de DNS Amplification, como sucedió cuando se produjo el ataque a los servidores de SpamHaus. En ese caso, un spammer enfadado con las listas RBL fue capaz de tumbar los servidores con peticiones DNS por UDP spoofeadas en las que usaba como dirección de origen la de su objetivo para que los propios servidores DNS tumbaran a SpamHaus.
Pero si nos vamos a momentos más recientes, controlando routers, impresoras y equipos Windows, mediante bugs conocidos, exploits públicos, contraseñas por defecto o simple malware desplegado con kits de explotación, hemos visto como un grupo como Lizard Squad era capaz de tumbar en el pasado los servidores Play Station Network y de XBOS y hacer que el propio Kim Dot Com pagara con bonos de Mega para que pudiera seguir jugando a sus juegos.
Y sin irnos tan lejos, AKAMAI dejó sin protección la web de Brian Krebs debido a la virulencia del ataque producido por una botnet de este tipo. Una botnet hecha con dispositivos del mundo del IoT del que ya se había avisado hace tiempo que había preocuparse.
¿Quién ha podido estar detrás?
Las especulaciones son como siempre de todo tipo. ¿Podría ser Korea del Norte atacando a EEUU para devolver una respuesta proporcionada al ataque de DDOS que sufrió como "castigo" por el ataque a SONY? ¿Podría ser un ataque para meter el miedo contra el voto electrónico? ¿Podría tener algo que ver con las elecciones en EEUU para que se beneficie el mensaje de uno u otro candidato? ¿Podría no ser nada más que una nueva versión de Lizard Squad enfadados por el bloqueo de alguna cuenta en Twitter? ¿Podría ser un ataque de ISIS por esos mismos bloqueos en Twitter?
Ahora es tiempo para especulaciones, por supuesto, y para la conspiranoia. Pero si un estado tuviera esta botnet lista - que no dudo que algunos países tengan estas posibilidades - habría que ver si una operación así pone de manifiesto sus cartas. Lo que hemos visto en el pasado es que los ataques entre naciones han sido siempre sibilinos, utilizando 0days que no fueran detectados para evitar que dejaran de ser útiles, porque en el momento que se lanzan, los investigadores pueden descubrir cómo se ha hecho, qué han utilizando y dónde estaba el fallo aprovechado.
Figura 4: El ataque a Brian Krebs superó los 400 GPS con NTP Amplification |
Hasta que no tengamos los detalles podría ser cualquiera cosa, pero viendo cómo fue el ataque a Brian Krebs, mi opinión iría más hacia esa dirección. Es decir, hacia alguien que ya tiene esa botnet creada con dispositivos IoT, routers y switches - como hacía la NSA - y que ahora está disfrutando con el uso de la misma en estos ataques DDOS. Me apuesto un camiseta de LUCA o de la FOCA a que en breve veremos más de estos y puede que, incluso los dispositivos de tu casa o de tu empresa sean parte de este ataque.
Saludos Malignos!
Hay algo que me llama mucho la atencion. Se supone que muchos de los servidores DNS a los que se accede desde la mayoria de las conexiones domesticas tienen una cache, aparte de las direcciones almacenadas en las tablas locales de los equipos. ¿No debería haber mitigado eso el alcance del ataque?
ResponderEliminarHay que recordar los ttl
ResponderEliminarTodo este tema en cierta manera se puede minimizar si los fabricantes de dispositivos (DVRs, Routers, Cámaras Ip, etc.) Tuvieran un mecanismo diferente de hacer llegar al usuario final sus dispositivos en cuanto a contraseñas y servicios por defecto se referiere.
ResponderEliminarEl usuario final en el 90% de los casos no tiene ni idea de como cambiar cambiar la contraseña por defecto y cerrar puertos como telnet y usar en vez de eso un SSH,etc. Saludos Chema y Saludos Malignos.
Uno de los mayores problemas que veo en el IoT hoy día es que todo el mundo tiene smartphone, smart TV, routers, WiFi, domótica, coche conectado, termostato WiFi, y hasta básculas conectadas a la nube. Pero a los fabricantes no les importa que sea seguro, lo que quieren es venderlo cuanto antes (os suena Galaxy NOTE 7?) y en masa. Lo de la seguridad lo dejan al usuario. Pero claro, le has vendido una báscula a una señora que a duras penas sabe ponerla en marcha, por supuesto que ella confía en que sus kilos de más a causa de su depresión no acaben en el ordenador de un cyberdelincuente.
ResponderEliminarLos que nos ganamos el pan con esto del IT más vale que nos pongamos las pilas y empecemos a asegurar los productos. Los usuarios (ojalá) empezarán a demandar seguridad antes de comprar, y solo así conseguiremos que la industria invierta en seguridad.
Excelentes observaciones Guillermo, yo que distribuyo seguridad informática puedo avalar tu punto de vista. Saludos!
EliminarEn realidad las botnets que hay en IoT son acausa de un pesimo desarrollo, esta plagado de Codigo de novatos, total mente saturado de fallos de seguridad.
ResponderEliminarBrujo !! Si ya esta el source code navegando por la red ! https://github.com/jgamblin/Mirai-Source-Code
ResponderEliminarObvio que habrán más ataques !
Completamente de acuerdo con Guillermo Ochoa, el IoT debería obligarte a cubrir unos parámetros fundamentales, deberías de venir por defecto en la Interface y punto.
ResponderEliminarNo sé, aquí algo no cuadra. Dyn en teoría tiene una infraestructura DNS de más de 20 nodos Anycast mundial y en el ataque sólo quedan afectados nodos del Este de USA lo que implica que no se ha distribuido el tráfico en la red anycast. Por otro lado la afectación de un nodo repercute en otro nodo al otro lado del mundo que es incapaz de ofrecer datos del dominio afectado ¿Cómo se come eso?
ResponderEliminarDejando a un lado (ya se que es mucho dejar) 0 days,uso de software desfasado, demoras en las actualizaciones y demás... los fabricantes en su gran mayoría desarrollan un producto con una configuración por defecto y es nuestra responsabilidad cambiarla y dotarla de seguridad. Esto es algo de lo que debemos concienciarnos.
ResponderEliminarDiscrepo, la seguridad la debe poner el fabricante, ¿o a caso compras un coche sin cinturón de seguridad? Además, el fabricante debe -facilitar- poder cambiar esa configuración por defecto. La mayoría de la gente no sabe cambiar la contraseña de la red Wifi, sin embargo la utilizan y envían datos críticos a través de ella (cuentas bancarias, usuarios y contraseñas, emails, etc.).
ResponderEliminarNo podemos dejar algo tan crítico como la seguridad a cargo de usuarios inexpertos.
¿Los fabricantes deben proporcionar la seguridad de los dispositivos? Pero si ya se olvidan de los móviles de 800 euros al cabo de un año y pico, cuando han lanzado un producto nuevo, ¡cómo esperamos que actualicen una balanza conectada!
ResponderEliminarTotalmente de acuerdo corruptus.
ResponderEliminarTotalmente de acuerdo corruptus.
ResponderEliminarTengo un servidor de pruebas con ubuntu que , deduzco, se utilizó la semana pasada para el ataque. En el momento del ataque mi red se volvió inaccesible,las luces del switch iban a toda leche. Antes de detectar que era ese servidor comprobé que si intentaba acceder a mi router desde lan, quien respondía era el apache de ese ubuntu, ahí ya me quedé ojiplatico y apagué ese servidor que tengo virtualizado y todo volvió a la normalidad.
ResponderEliminarSoluciones de Cisco como OpenDNS pudieron mitigar el efecto del ataque para sus clientes (de pago y gratis!):
ResponderEliminarThe Register: ”OpenDNS is about the only major public DNS provider weathering the storm
Why OpenDNS succeeded where ISP DNS failed when Dyn was unavailable: http://www.computerworld.com/article/3135504/cloud-computing/why-opendns-succeeded-where-isp-dns-failed-when-dyn-was-unavailable.html?idg_eid=d5d8326c323742a4ed7bf4fd3dac54c4&token=%23tk.CTWNLE_nlt_co