¿Qué lecciones aprendimos con el truco GFW / Baidu / GitHub de China?

Gracias por el A2A.

Para mí, la parte realmente aterradora de esto es que involucró la inyección de JavaScript en sesiones web de usuarios regulares de Internet que no habían estado (al menos tan cerca como podemos ver) sujetos a ninguna infección de malware.

La causa raíz de esto es un repositorio corrupto (intencionalmente, en este caso) de JavaScript que contiene elementos destinados a aumentar la carga en el sitio de destino.

Pienso en cosas como esta todo el tiempo: cuántas bibliotecas usa un sitio determinado, cuántas referencias de terceros hace un sitio, cuánto de “el sitio” realmente no está en “el sitio” …

En SlideStorm, me encontré con esto cuando teníamos un cliente que estaba detrás de un firewall de lista blanca, y tuve que compilar una lista de sitios que tenían que estar en la lista blanca para que el sitio funcionara. Claro, esperaba Google Analytics, y un montón de cosas de las bibliotecas de las API de Google, pero la lista seguía y seguía y seguía … y tuve que preguntarme “¿Realmente podemos confiar en todo esto?”

Hay un montón de artículos populares sobre 3 razones por las que deberías dejar que Google aloje jQuery por ti y, aunque no estoy particularmente preocupado por Google en , la tendencia es inquietante: los desarrolladores dependen cada vez más del código que no está bajo su control , servido desde una infraestructura que no está bajo su control y que es imposible de monitorear o auditar.

No puede prohibir JavaScript, tanto como me gustaría, porque aproximadamente el 100% de todos los sitios web dejarían de funcionar inmediatamente.

Y tampoco puede prohibir el uso de bibliotecas desarrolladas y alojadas por terceros. Porque aproximadamente el 100% de todos los desarrolladores web dejarían de funcionar inmediatamente … (ok, eso es aproximadamente la mitad en broma, pero solo la mitad)

La protección HTTPS es un paso en la dirección correcta, pero aún no hace nada si hay un nivel de participación de estado-nación. Si voy a corromper el repositorio y los CDN asociados, puede apostar a que voy a proporcionar certificados SSL de reemplazo o encontrar otra forma de evitarlo. (Solo he estado pensando en esto durante unos 20 minutos, pero estoy seguro de que puedo llegar a algo con el tiempo dado)

No estoy seguro de cuál será la solución correcta. HTTPS en todas las páginas, todo el tiempo, hará mucho para eliminar la piratería informal, pero para algo de esta escala, estoy bastante seguro de que necesitaremos una nueva clase de solución.

HTTPS y contenido validado es la única forma de evitar esto. Este tipo de inyección se puede realizar en cualquier puerta de enlace.

En otra nota, los desarrolladores de sitios web deben tratar de evitar el uso de contenido menos confiable o desconocido en sus sitios. En este caso, el contenido de terceros alojado en China tiene los puntos de aplicación GFW como posibles vectores de explotación. Esto es menos cierto para el contenido fuera de China que pasa por diferentes rutas y proveedores.

Por último, una modificación a la pila del protocolo TCP para verificar los valores TTL adecuados en las respuestas para garantizar que estén en la secuencia adecuada es una opción extrema. Sin embargo, esto se puede implementar fácilmente y solo requiere cambios del cliente.

El ataque GitHub nos ha presentado un vector de amenazas completamente nuevo y una clase de ataques DDoS. Con los últimos ataques, hemos visto la inyección de código JavaScript en las sesiones web de usuarios habituales de Internet que de otra manera no están infectados ni son vulnerables.

¿Qué significa esto? Esto significa que todos podemos ser “armados” simplemente por el simple hecho de navegar por la web.

La única forma de defenderse contra este ataque, que yo sepa, es implementar HTTPS en todas partes para evitar ataques de inyección de JavaScript. ¿Por qué? Porque HTTPS proporciona una verificación de integridad en toda la sesión web.

Con HTTPS, sabe que está navegando por el contenido exacto proporcionado por los servidores web que está visitando. Sin HTTPS, sus sesiones podrían ser manipuladas y usted no notaría la diferencia.

También vea mi respuesta aquí:
¿Por qué los sitios como TechCrunch [ http://techcrunch.com ] no usan un certificado SSL?

Venganza:

También se cree que GreatFire es uno de los principales objetivos del ataque DDoS que golpeó a GitHub durante la semana pasada, que algunos han acusado al gobierno chino de lanzar . El gobierno chino no ha negado su participación en los ataques, que dependen de una pieza de javascript que dirige el tráfico de Baidu fuera de China a los servidores de GitHub “.
ZDNET Google inicia la principal autoridad de certificación digital de China CNNIC