12 mar 2018

Cuando GitHub sufrió un ataque ChDoS

En estos últimos días se ha visto la noticia por todos lados: GitHub ha sufrido el (ya segundo) mayor ataque de denegación de servicio de la historia en cantidad de tráfico, alcanzando la friolera de 1,35Tbps. Para conseguirlo, se ha hecho uso de servidores memcached vulnerables, que han sido utilizados como amplificadores (más info aquí). No obstante, es destacable que el ataque se haya resuelto en tan solo 10 minutos; aunque no tuvo la misma suerte hace unos años, cuando sufrió uno que afectó gravemente al servicio durante días. ¿Qué tipo de ataque? Un (permitidme la licencia) ChDoS: una denegación de servicio... usando chinos. 

Fue a finales de marzo del año 2015 cuando se produjo esta denegación (la mayor en la historia de GitHub hasta ese momento), con origen en China. El ataque tenía como objetivo dos repositorios: GreatFire (un conocido grupo que luchaba en aquel momento contra la censura del gobierno chino) y CN-NYTimes (grupo que hospedaba mirrors del New York Times, bloqueado en China). La denegación comenzó en la madrugada (GMT) del jueves 26 de marzo e incluyó un curioso vector de ataque.

Inicialmente, se "secuestró" el código de tracking del buscador chino Baidu. Alguien con acceso a la red troncal del país pudo interceptar las peticiones de descarga del código para desviarlo a uno propio malicioso (que puede verse aquí). Este código enviaba peticiones a ambos repositorios cada dos segundos y aumentaba drásticamente el tiempo de vida de los paquetes SYN+ACK enviados en estas conexiones. De este modo, se atacaba por dos frentes distintos: DoS por inundación (se inyectó en un 1% de los internautas chinos, que al hacer peticiones a GitHub cada dos segundos generaban una inundación HTTP que ya quisiera Anonymous en los años del LOIC) y DoS por bloqueo de los recursos de los servidores, dado que están mucho tiempo esperando la terminación del three-way handshake (y no es posible atender otras peticiones mientras tanto).

Pero si el ataque chino ya fue original, la solución de GitHub lo fue aún más: comprobaron que el código malicioso además de descargar el contenido de los repositorios, lo intentaba ejecutar pese a ser un HTML (¿qué importan los errores cuando quieres ver el mundo arder?). Por tanto, cambiaron el código por un alert en JavaScript, por lo que a todos los usuarios a los que se inyectaba el código malicioso les aparecía el cuadro de texto. Con esto consiguieron mitigar el ataque de tres maneras: alertando al usuario con el mensaje que aparecía, reduciendo el número de peticiones (ya que un alert es bloqueante, y hasta que el usuario no eliminase el cuadro de texto no se hacía la siguiente petición) y dando la posibilidad de parar el ataque (cuando una web genera más de una alerta, los navegadores dan la opción de evitar que aparezcan más, abortando la ejecución del script).



Ejemplo de alerta mostrada a los usuarios infectados. Fuente: Insight-labs

Por tanto, aquellos días de 2015 fueron, cuanto menos, curiosos. Una gran mano negra utilizó la infraestructura de red de China para convertir a sus ciudadanos en los zombies de una botnet con la cual atacar GitHub; que se las arregló para informar a los usuarios de su pertenencia a una botnet, forzándoles a parar la ejecución del script para evitar infinitas alertas en su navegador.

Tras esto, el ataque fue evolucionando (junto con las defensas de GitHub) haciendo uso de técnicas más comunes, hasta alcanzar las 118 horas de anomalía. Pero eso ya no tiene tanto interés... ¿no?

¡Saludos!

Artículo cortesía de Luis Vazquez (@macgruap)

No hay comentarios:

Publicar un comentario