Después del reciente incidente del gran firewall Chino inyectando un JavaScript modificando en el buscador Baidu para realizar ataques DDoS a GitHub crecen las dudas acerca de este tipo de ataques. Ya hemos visto que existen muchas técnicas de ataque DDoS, algunas usando JavaScript en el navegador.





Para un ataque DDoS basado en JavaScript, cualquier ordenador con un navegador puede estar apuntado en el ataque, por lo que el volumen potencial de ataque será casi ilimitado.

Ejemplos de ataques DDoS basados en JavaScript

También hay  ataques basados en HTML como un ataque iframe (muy viejo)

function imgflood() { 
  var TARGET = 'victim-website.com'
  var URI = '/index.php?'
  var pic = new Image()
  var rand = Math.floor(Math.random() * 1000)
  pic.src = 'http://'+TARGET+URI+rand+'=val'
}
setInterval(imgflood, 10)  

Este script crea una etiqueta de imagen en la página 100 veces por segundo. Esta imagen apunta a "victim-website.com" con parámetros de consulta aleatorios. Cada visitante a un sitio que contiene este script se convierte en un participante involuntario en un ataque DDoS contra "victim-website.com". Los mensajes enviados por el navegador son peticiones HTTP válidas, haciendo de esta una capa 7 ataque. Estos ataques pueden ser más peligrosos que los ataques basados en la red como NTP y reflexión DNS. En lugar de simplemente "la obstrucción de las tuberías", con una gran cantidad de datos, de capa 7 ataques causan el servidor web y backend para hacer el trabajo, la sobrecarga de los recursos de la página web y haciendo que no responda.

Si un atacante crea un sitio con este JavaScript incrustado en la página, los visitantes del sitio se hacen participantes del ataque DDoS. Contra mayor tráfico tenga el sitio,  más grande será el ataque DDoS. Desde los sitios de ataque construido propósito no suelen tener muchos visitantes, el volumen de ataque suele ser baja. Realización de un ataque DDoS verdaderamente masiva con esta técnica requiere un poco más de creatividad. 

Muchos sitios web se construyen utilizando un conjunto común de bibliotecas JavaScript. Con el fin de ahorrar ancho de banda y mejorar el rendimiento, muchos sitios terminan utilizando bibliotecas JavaScript alojados por un tercero. El más popular biblioteca de JavaScript en la Web es jQuery, con alrededor del 30% de todos los sitios web que utilizan alguna versión de ella a partir de 2014. Otros scripts populares incluido en muchos sitios web incluyen el SDK de Facebook y Google Analytics.

En septiembre de 2014, RiskIQ informó que el sitio web de jQuery.com se vio comprometido, que alberga una biblioteca de JavaScript muy popular que fácilmente podría haber sido reemplazado por uno malicioso. La amenaza de atacantes inyectan JavaScript malicioso en millones de sitios ya no era pura ficción.

El problema de los activos de terceros sean comprometidos no es nuevo No existen mecanismos de HTTP para permitir que un sitio web para bloquear un script se ejecute si ha sido manipulado. Para resolver este problema, el W3C ha propuesto una nueva característica llamada subrecurso Integridad (SRI) Subresource Integrity (SRI). Esta característica permite a un sitio web para decirle al navegador que sólo se ejecute un script si coincide con lo que espera el sitio.


Tome la siguiente etiqueta de script:

script src="https://code.jquery.com/jquery-1.10.2.min.js"> 

 

El navegador se descargará el archivo .js y ejecutarlo sin importar el contenido del archivo que hay. Si alguien de fuera pudiera comprometer los servidores del sitio de alojamiento y reemplazar el archivo con un script malicioso, el navegador podría ejecutarlo sin lugar a dudas.

Con SRI, se puede decir que el navegador no se ejecute la secuencia de comandos si no coincide con lo que usted espera. Esto se hace usando un hash criptográfico. Un hash criptográfica es una manera de identificar de forma exclusiva una pieza de datos. Es como una huella digital: no hay dos archivos tienen el mismo hash. Con SRI, puede incluir un hash de la versión auténtica de la secuencia de comandos con un atributo llamado "integridad". Después de descargar el script, el navegador calcular su hash y compararlo con el hash esperado de la etiqueta de script. Si no coinciden, entonces el guión ha sido manipulado y el navegador no lo utilizará.

El atributo crossorigin y Cross-Origen de intercambio de recursos (CORS) encabezados son necesarios para scripts con SRI con el fin de garantizar la correcta aplicación del navegador política del mismo origen y prevenir Scripting (XSS) ataques Cross-Site.

 

 Esta función no está soportada por muchos navegadores, pero está en desarrollo para Chrome y Firefox.

El probable ataque de China usando el Gran Firewall Chino

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.

 

 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. E

Estudio de Google Safe Browsing sobre las inyecciones basadas en JavaScript

Para proteger a los usuarios de contenido malicioso, Google implementa la infraestructura de navegación segura (Safe Browsing) de los análisis de las páginas web con los navegadores web que se ejecutan en máquinas virtuales.

Mientras que Safe Browsing no observa el tráfico a nivel de red, que permite una buena visibilidad a nivel de protocolo HTTP. Como tal nuestra infraestructura recogió este ataque, también. El uso de navegación segura de datos, podemos ofrecer una línea de tiempo más completo del ataque y arrojar luz sobre lo que ocurrió cuando las inyecciones. 

 

A mediados de marzo los investigadores de seguridad detectaron una serie de ataques DDoS a nivel mundial contra la censura en la red. Desde entonces se ha estado investigando este golpe contra estas páginas web para poder identificar el origen del mismo y el método utilizado, pudiendo descubrir así una nueva forma de ataque prácticamente invisible.

La sustitución de Javascript cesó por completo el 20 de marzo, pero las inyecciones en las páginas HTML continuó. Considerando que la sustitución Javascript rompe la funcionalidad del contenido original, la inyección en HTML no lo hace. Aquí HTML se modifica para incluir tanto una referencia al contenido original, así como el ataque Javascript como se muestra a continuación: 

iframe src="http://pan.baidu.com/s/1i3[...]?t=Zmh4cXpXJApHIDFMcjZa" style="position:absolute; left:0; top:0; height:100%; width:100%; border:0px;" scrolling="yes">/iframe>

js
[... regular attack Javascript ...]

Fuentes:

https://blog.cloudflare.com/an-introduction-to-javascript-based-ddos/

http://www.securitybydefault.com/2015/03/china-probablemente-ataca-github.html

http://googleonlinesecurity.blogspot.com.es/2015/04/a-javascript-based-ddos-attack-as-seen.html

https://citizenlab.org/2015/04/chinas-great-cannon/