¿Algún precedente histórico para las bibliotecas de código abierto como un vector de ataque?

5

Tengo curiosidad por saber si existen casos notables históricamente de personas que colocan deliberadamente exploits en bibliotecas de código de código abierto utilizadas por otros, ya sea algo relativamente obvio con la esperanza de que nadie lo compruebe, o con algo malintencionado que sea fácilmente explotable una puerta trasera?

Me parece que el aumento en los tipos de desarrolladores que unen ciegamente las bibliotecas llevaría a un mundo en el que esto es mucho más común, pero tengo problemas para identificar cualquier caso real que ocurra.

Me parece que inyectar un código arbitrario sin garantías de terceros no confiables es un esfuerzo de alto riesgo que las startups están lanzando con un abandono imprudente, así que me pregunto por qué no estoy al tanto de ninguna catástrofe.

    
pregunta Kevin Dolan 13.07.2016 - 05:59
fuente

1 respuesta

1

Tienes razón, la inyección deliberada no es común en el mundo de código abierto, en parte porque el proceso lo hace caro, pero sobre todo porque no es necesario.

La mayoría de los proyectos de código abierto que ganan terreno tienen usuarios que ejercen muchos casos de uso y necesitan cuidadores cuidadosos que respondan a los problemas y conozcan a sus comprometidos, por lo que las solicitudes arbitrarias de nuevos desarrolladores pasan por un proceso de investigación y para obtener sus En el código, los participantes deben invertir en hacer crecer una reputación y crear confianza. Todo esto dificulta la inyección deliberada de vulnerabilidades.

Y no es necesario porque el software es vulnerable por defecto. Desde la perspectiva de un atacante, no hay razón para ir a través de una farsa de confianza para inyectar vulnerabilidades, porque ya habrá algunas en cualquier base de código, solo hay que buscarlas. Y como el código está abierto, puede buscarlos sin que nadie sepa que los está buscando.

En el mundo de código cerrado / comercial, la inyección es mucho más común, por ejemplo:

enlace

Para aquellos atacantes a esa escala, tiene sentido construir y luego sacrificar la confianza, aunque ese es un ejercicio muy costoso. El infame caso de Dual_EC_DRBG es instructivo, porque fue una inyección en un mundo que se parecía a la fuente abierta en términos de dinámica, con el resultado de que un actor previamente confiable (NSA) que trabajaba en un proceso abierto (NIST) previamente sin problemas ha sacrificado para siempre Credibilidad propia y del proceso. Compruebe wikipedia para más detalles.

El modelo que sugiere, terceros que utilizan un proceso que no requiere confianza para inyectar ataques o vulnerabilidades, describe con precisión el modelo de entrega de malware web.

Las capas de código de terceros arbitrarias, no auditables y dirigidas con precisión de javascript, flash, etc., que entregan anuncios, captan métricas, proveen botones para compartir y hacen muchas otras cosas, se cargan en el navegador en nombre de los primeros dominio de la parte que el usuario está visitando, generalmente con muy poco o ningún conocimiento de la primera parte o del usuario. Es altamente riesgoso para los usuarios y, por supuesto, las catástrofes ocurren todo el tiempo:

enlace

    
respondido por el Jonah Benton 04.08.2016 - 06:52
fuente

Lea otras preguntas en las etiquetas