Seguro que muchos de los lectores de este blog, teniendo en cuenta cuál es su público más habitual, ya habrán notado que el funcionamiento de GitHub esta mañana ha sido intermitente.
Como es habitual, este mal funcionamiento del servicio se debió a un nuevo ataque DDoS, como se puede comprobar en la página de estado de GitHub.
Siendo los ataques a GitHub tan habituales, ¿por qué prestarle atención a este en concreto? Porque, en primer lugar, según la información disponible, este parece tener un atacante identificado con bastante probabilidad: el Gran Firewall chino. Sin embargo, tampoco es el primer ataque conocido con este origen: recordemos que, a principios de enero, el Gran Firewall hizo que el nombre de dominio de webs censuradas como Facebook resolviese a la dirección IP de la organización ciberactivista francesa La Quadrature du Net, provocando un volumen de tráfico para el que no estaban preparados y que provocó una denegación de servicio.
¿Por qué sucedió esto? Entre las hipótesis más probables barajadas se encuentra la de que haya sido una acción intencionada del Gobierno chino para usar el Gran Firewall por el que pasa la conexión de todos sus ciudadanos para convertir a todos los que quisieran visitar Facebook en atacantes de La Quadrature du Net, una organización que defiende los derechos y libertades en Internet, claramente opuesta a la postura del Gobierno chino con respecto a Internet.
Otras hipótesis barajada es la de que no haya sido una orden que proviniese del Gobierno chino, sino que un empleado con acceso al Gran Firewall esté aprovechando su infraestructura para vender servicios de DDoS a terceras personas.
En cualquier caso, tampoco podemos asegurar que lo que haya pasado --y que es otra hipótesis que se ha planteado-- no sea simplemente que, cuando el Gran Firewall bloquea algún sitio --como Facebook, en este caso-- lo que haga sea que el dominio resuelva a cualquier dirección IP aleatoria y, en este caso, por azar, le ha tocado a una dirección IP de La Quadrature du Net (aunque, de ser esto lo que están haciendo, habría otros rangos de direcciones IP mejores para hacer esto).
No obstante, habiendo también precedentes de ataques con evidencias de proceder del Gran Firewall chino, ¿qué tiene de especial este ataque para que hayamos decidido hablar de él? Lo que hace este ataque interesante son tres motivos:
El atacante pudo interceptar las peticiones que solicitaban descargar el código de tracking de Baidu detectando las peticiones a http://hm.baidu.com/h.js para desviarlo a su propio código malicioso. En la siguiente captura, podemos ver a la izquierda el código de tracking actual de Baidu y a la derecha el código que se descargaba durante el ataque según Slashdot:
Si bien ambos códigos están ofuscados, se puede ver que son diferentes ya que el método de empaquetado es distinto y la longitud del código difiere bastante, siendo el código original mucho más largo.
Si desofuscamos el código y comparamos ambas versiones, teniendo de nuevo a la izquierda el código actual y legítimo de Baidu y a la derecha el código del ataque, vemos de nuevo que ambos códigos son totalmente distintos y que el código legítimo es mucho más largo:
Echando un vistazo al código se puede ver rápidamente que el de la izquierda sí tiene la apariencia de ser un código de tracking, mientras que el de la derecha lo único que hace es activar un temporizador que, cada dos segundos, lanza una petición para descargar el contenido de https://github.com/greatfire/ y https://github.com/cn-nytimes/.
Esto provoca que cada usuario que visite una página que use el código de tracking de Baidu esté cada dos segundos haciendo peticiones a GitHub y, de este modo, está participando sin darse cuenta en un ataque DDoS.
Nótese, además, que esta suplantación de código no solo afecta a ciudadanos chinos, sino también a cualquier ciudadano extranjero que intente descargar el código de Baidu, ya que, al estar Baidu alojado en China, su conexión pasaría del mismo modo por el Gran Firewall y se realizaría la suplantación de código igualmente, como le sucedió al investigador de Insight-labs.
Como ese código que descargaba no era JavaScript, sino HTML, probablemente se generará un error en la consola del navegador y no pasará nada. ¿Cómo aprovechó esto GitHub? Reemplazó el código de las páginas atacadas para incluir en su lugar únicamente la siguiente instrucción JavaScript:
Como se puede ver en la siguiente captura de pantalla:
Y sirvió ese contenido con Content-Type application/javascript:
Así, reemplazado el contenido de esas direcciones por esa instrucción JavaScript y sirviéndolo con el Content-Type correspondiente, el contenido descargado sí se procesaba correctamente como JavaScript y lo que ejecutaba era la única sentencia que incluía, que lo que hacía era mostrar una advertencia al usuario:
Fuente: Insight-labs
De este modo, con esa advertencia se consiguen tres objetivos:
Sin embargo, dos conclusiones como mínimo creo que se pueden extraer de todo esto:
Como es habitual, este mal funcionamiento del servicio se debió a un nuevo ataque DDoS, como se puede comprobar en la página de estado de GitHub.
Siendo los ataques a GitHub tan habituales, ¿por qué prestarle atención a este en concreto? Porque, en primer lugar, según la información disponible, este parece tener un atacante identificado con bastante probabilidad: el Gran Firewall chino. Sin embargo, tampoco es el primer ataque conocido con este origen: recordemos que, a principios de enero, el Gran Firewall hizo que el nombre de dominio de webs censuradas como Facebook resolviese a la dirección IP de la organización ciberactivista francesa La Quadrature du Net, provocando un volumen de tráfico para el que no estaban preparados y que provocó una denegación de servicio.
¿Por qué sucedió esto? Entre las hipótesis más probables barajadas se encuentra la de que haya sido una acción intencionada del Gobierno chino para usar el Gran Firewall por el que pasa la conexión de todos sus ciudadanos para convertir a todos los que quisieran visitar Facebook en atacantes de La Quadrature du Net, una organización que defiende los derechos y libertades en Internet, claramente opuesta a la postura del Gobierno chino con respecto a Internet.
Otras hipótesis barajada es la de que no haya sido una orden que proviniese del Gobierno chino, sino que un empleado con acceso al Gran Firewall esté aprovechando su infraestructura para vender servicios de DDoS a terceras personas.
En cualquier caso, tampoco podemos asegurar que lo que haya pasado --y que es otra hipótesis que se ha planteado-- no sea simplemente que, cuando el Gran Firewall bloquea algún sitio --como Facebook, en este caso-- lo que haga sea que el dominio resuelva a cualquier dirección IP aleatoria y, en este caso, por azar, le ha tocado a una dirección IP de La Quadrature du Net (aunque, de ser esto lo que están haciendo, habría otros rangos de direcciones IP mejores para hacer esto).
No obstante, habiendo también precedentes de ataques con evidencias de proceder del Gran Firewall chino, ¿qué tiene de especial este ataque para que hayamos decidido hablar de él? Lo que hace este ataque interesante son tres motivos:
- La forma en la que se ha llevado a cabo, que es ciertamente original e inusual y solo posible para alguien con acceso a una infraestructura que pueda interceptar las comunicaciones de millones de personas, como el Gran Firewall chino.
- La respuesta de GitHub, que también ha sido original.
- El atacante chino ha usado también usuarios extranjeros para llevar a cabo su ofensiva, poniendo en evidencia una vez más el diseño de Internet basado en la confianza y suposición de buena fe entre las partes y en cómo nos vemos afectados cuando un gran actor como es China traiciona ese principio de buena fe.
Cómo se ha llevado a cabo el ataque
Según las investigaciones de Insight-labs, el modo en el que fue lanzado el ataque fue «secuestrando» el código de tracking de Baidu. Como, sin duda, la mayoría de los lectores sabrán, Baidu es el buscador local chino que tiene prácticamente la hegemonía del mercado, sobre todo tras la retirada de Google al negarse a seguir colaborando con la censura tras recibir un ataque con origen en China. Al igual que Google tiene su servicio Analytics, Baidu tiene un servicio similar de tracking para analizar las visitas recibidas por las páginas web que decidan usar este servicio.El atacante pudo interceptar las peticiones que solicitaban descargar el código de tracking de Baidu detectando las peticiones a http://hm.baidu.com/h.js para desviarlo a su propio código malicioso. En la siguiente captura, podemos ver a la izquierda el código de tracking actual de Baidu y a la derecha el código que se descargaba durante el ataque según Slashdot:
Si bien ambos códigos están ofuscados, se puede ver que son diferentes ya que el método de empaquetado es distinto y la longitud del código difiere bastante, siendo el código original mucho más largo.
Si desofuscamos el código y comparamos ambas versiones, teniendo de nuevo a la izquierda el código actual y legítimo de Baidu y a la derecha el código del ataque, vemos de nuevo que ambos códigos son totalmente distintos y que el código legítimo es mucho más largo:
Echando un vistazo al código se puede ver rápidamente que el de la izquierda sí tiene la apariencia de ser un código de tracking, mientras que el de la derecha lo único que hace es activar un temporizador que, cada dos segundos, lanza una petición para descargar el contenido de https://github.com/greatfire/ y https://github.com/cn-nytimes/.
Esto provoca que cada usuario que visite una página que use el código de tracking de Baidu esté cada dos segundos haciendo peticiones a GitHub y, de este modo, está participando sin darse cuenta en un ataque DDoS.
Nótese, además, que esta suplantación de código no solo afecta a ciudadanos chinos, sino también a cualquier ciudadano extranjero que intente descargar el código de Baidu, ya que, al estar Baidu alojado en China, su conexión pasaría del mismo modo por el Gran Firewall y se realizaría la suplantación de código igualmente, como le sucedió al investigador de Insight-labs.
Cómo mitigó GitHub el ataque
Si bien el ataque tiene una cierta originalidad --aunque no hubiese sido posible sin la gran cantidad de tráfico que se puede manipular teniendo acceso al Gran Firewall-- la respuesta de GitHub fue más original todavía, ya que el script malicioso no sólo envía una petición para descargar el contenido de https://github.com/greatfire/ y https://github.com/cn-nytimes/, sino que, debido a la forma en la que está programado, también intenta ejecutar ese código como si fuera JavaScript.Como ese código que descargaba no era JavaScript, sino HTML, probablemente se generará un error en la consola del navegador y no pasará nada. ¿Cómo aprovechó esto GitHub? Reemplazó el código de las páginas atacadas para incluir en su lugar únicamente la siguiente instrucción JavaScript:
alert("WARNING: malicious javascript detected on this domain")
Como se puede ver en la siguiente captura de pantalla:
Y sirvió ese contenido con Content-Type application/javascript:
Así, reemplazado el contenido de esas direcciones por esa instrucción JavaScript y sirviéndolo con el Content-Type correspondiente, el contenido descargado sí se procesaba correctamente como JavaScript y lo que ejecutaba era la única sentencia que incluía, que lo que hacía era mostrar una advertencia al usuario:
Fuente: Insight-labs
De este modo, con esa advertencia se consiguen tres objetivos:
- Advertir al visitante (y probablemente al dueño de la web cuando la visite) de que esa web incluye un script malicioso.
- Retrasar el tiempo entre peticiones: ya que la función window.alert() es bloqueante, el resto del script no continuará hasta que el usuario haga clic en aceptar, por lo que se introduce un retraso en esa temporización de dos segundos.
- Dar la opción al usuario de detener el ataque. Esta nueva variante del script (la versión troyanizada por GitHub de la versión troyanizada por el Gran Firewall del script de Baidu) estaría mostrando alertas con un intervalo de dos segundos, algo sin duda muy molesto para el usuario. La mayoría de navegadores modernos, para evitar la ejecución de scripts molestos, a partir de la segunda alerta dan al usuario la opción de abortar la ejecución del script:
- Si el usuario, molesto, marca esa casilla antes de hacer clic en aceptar, se detendría el ataque. A base de provocarle una molestia, GitHub puede conseguir que el usuario colabore para detener el ataque.
Conclusión
Como era de esperar, ni en este caso ni en el de La Quadrature du Net hay información oficial ni ninguna explicación por parte de ningún responsable chino que pueda aclarar qué es lo que ha pasado, por lo que lo único con lo que nos podemos quedar es con conjeturas como estas, pero no podremos saber con certeza qué ha pasado.Sin embargo, dos conclusiones como mínimo creo que se pueden extraer de todo esto:
- La dependencia de la comunidad de software libre de un servicio centralizado como es GitHub. Si bien hay alternativas a GitHub de código abierto (GitHub no es código abierto), como GitLab, su hegemonía es indiscutible y, aunque esto puede ser un indicativo de la calidad de su servicio, queda en evidencia lo vulnerables que somos a las caídas del mismo, en las que parece que una parte de la actividad de desarrollo se detiene.
- El diseño de Internet pertenece a otros tiempos y está basado en relaciones de confianza en las que se asume por adelantado la buena fe de todas las partes. Si bien algunos protocolos han ido añadiendo capas y remiendos de seguridad, la arquitectura de Internet todavía es vulnerable a la traición a la buena fe de alguna de las partes, sobre todo al más bajo nivel, como ya se ha demostrado en repetidas ocasiones.
Artículo cortesía de Jesús Perez
14 comments :
La respuesta de Github jajaj brillante :D
Pero deberían haberlo escrito en alguna variedad de chino para hacerlo realmente eficiente.
Podrian haber metido noticias censuradas en china como parte de la alerta, asi se saltan las restricciones chinas, gracias al ataque chino!
Ahora me pregunto, que ganan con hacer eso contra github?, es lo que no entiendo.
Estaría bueno si el artículo se enriqueciera un poco más con explicaciones sobre la parte enlazada de http hijacking.
Gracias.
Fíjate que digo que «el atacante chino ha usado también usuarios extranjeros para llevar a cabo su ofensiva» y, de hecho, gran parte de la investigación la ha hecho un chino residente en el extranjero mientras visitaba una web china desde fuera de China.
Por otra parte, GitHub parece estar bloqueado en China: http://viewdns.info/chinesefirewall/?domain=github.com
Por todo esto, lo más probable es que casi todos los que hayan visto el mensaje lo hayan hecho desde fuera de China y creo que hubiese sido menos efectivo poner el mensaje en chino.
Tienes razón, tenía que haber contado un poco cuáles son las motivaciones de China para atacar GitHub.
Las URLs de GitHub que se usaron para el ataque se corresponden con dos proyectos que intentan evadir la censura de china en Internet.
Lo expliqué un poco en el enlace que puse en mi blog a este artículo: https://es.chuso.net/github-ddos-gran-firewall-china-baidu-troyano.html
Aunque en realidad da igual qué URLs de GitHub hayan usado porque el ataque acaba afectando a todo GitHub por igual, pero el uso de esas URLs deja en evidencia cuáles fueron los motivos.
Gracias por tu comentario.
No me pareció necesario dar detalles demasiado técnicos porque ya está explicado en el artículo enlazado de Insight-labs, que fue quien hizo la investigación. Habría hecho un artículo más técnico si pudiera incluir más investigación propia, pero en este caso no tenía mucho que añadir a lo investigado por Insight-labs y quise escribir un artículo haciendo que la información disponible para un público más técnico fuese un poco más comprensible para un público un poco más generalizado explicándolo de forma más accesible.
La primera conclusión no es del todo cierta. Al ser un repositorio Git, la gente puede seguir trabajando sobre su repositorio local hasta que se restaure el servicio.
Y aunque no fuese Git, también podrías seguir trabajando localmente. Lo que no puedes hacer es clonar nuevos repositorios, consultar documentación, hacer push de los commits para que estén accesibles a otros desarrolladores, consultar issues, etc. Aunque el diseño de Git sea distribuido y descentralizado, en la práctica, los proyectos alojados en GitHub están centralizados en GitHub.
Yo me di cuenta de la caída cuando necesité consultar la documentación de un proyecto que estaba alojada en GitHub y cuando necesité descargar un script que también estaba alojado en GitHub.
Gracias por la entrada y por la respuesta.
Es cierto que hay diferentes formas de verlo. Sin embargo, soy de la opinión de que la mayoría de usuarios de una página china, incluso desde el extranjero (desde cualquier país), hablarán alguna variedad de chino y no necesariamente inglés.
Por ejemplo, yo vivo en un país de habla no hispana pero sigo visitando algunas páginas españolas. En caso de recibir un mensaje en la lengua local o en inglés normalmente no achacaría el problema a dicha página española. De todas las decenas de hispanohablantes que conozco aquí solo dos hablan la lengua local mejor que yo y solo uno entiende algunas cosillas; el resto, tristemente cero, así que los mensajes en la lengua local o incluso en inglés (la mayoría no tienen formación técnica) lamentablemente no servirían para nada en su caso.
Como decía, es solo mi opinión basada en mi experiencia. Un saludo.
Tiene sentido lo de los proyectos, pero afectaba a todo github por eso mismo digo, tenia mas sentido no se, un hackeo a los que hacen ese desarrollo no a la plataforma que lo alberga, ademas... es muy idiota pensar que anulando github (si fuera posible) anulas el codigo.
jaj capo
https://github.com/greatfire y https://github.com/cn-nytimes siguen caídos..
Publicar un comentario