¿Cuáles son los riesgos y las posibilidades o escenarios por los cuales alguien establece mascaradas de repositorios maven y/o flujos de IP para proporcionar copias enmascaradas de la biblioteca del original pero inyectadas con código malicioso o dañino?¿Qué tan seguro es usar Maven?
¿Cuáles son los pasos y las prácticas para prevenir tales riesgos y posibilidades?
supongo que un atacante dedicación y capacidad podría realizar un ataque MITM e interceptar todas las peticiones a los repositorios de Maven públicos, cuidado de inyectar malicioso bytecode en los artefactos JAR, luego recalcula y suministra los hashes SHA1.
Para el cliente, parecería un artefacto legítimo: el JAR binario y el SHA1 coinciden y serán los mismos aunque verifiquen los duplicados alternativos.
Supongo que la única solución real es solicitar que los repositorios centrales admitan HTTPS (y confíen en que TLS no se ha roto).
Alternativamente, un enfoque práctico podría ser configurar un proxy Maven (Artifactory o Nexus) servido a través de HTTPS a clientes internos. Esto reduce la superficie de ataque y significa que solo tendrá que asegurar las líneas de comunicación desde ese servidor al mundo exterior. Revisaría periódicamente que los JAR y los hash del proxy coincidan con los de las réplicas públicas mediante una red totalmente independiente y confiable.
Si realmente, realmente quiere estar segura que no sería confiando binarias de lugar, estaría descargando toda código fuente y la revisión de ellos con la mano delante de ellos la compilación de sí mismo, pero que se supone que tiene suficientes recursos calificados y tiempo para realizar las revisiones y para comenzar, confíe en toda su cadena de herramientas de construcción.
Bueno, la seguridad en las capas como siempre dicen.
O podría utilizar un enfoque de lista blanca –
No es necesario que intercepten todas las solicitudes, solo lo suficiente para inyectar un JAR defectuoso. Y si trabajas en una computadora portátil usando wifi, no se necesita un atacante ingenioso, incluso con WPA. – aij
El ataque MITM no funciona en maven central ya que usa las firmas PGP para artefactos. –
Si utiliza repositorios conocidos (repositorio central maven, repositorio jboss) es muy baja la posibilidad de inyectar código dañino. Los virus informáticos, su ISP o ISP de su ISP para hacerlo, deben entrometerse en los servidores DNS o cambiar las rutas de acceso para algunos destinos. Creo que eso es bastante improbable; lo mismo no solo se trata de los repositorios maven, sino también de todos los servicios de Internet (correo electrónico, http, voip, etc.). Además, el mismo riesgo es descargar archivos JAR directamente de los sitios del proyecto.
De todos modos, si usted quiere tener un control total que usted puede configurar su propio repositorio de Maven (http://nexus.sonatype.org/)
Cada archivo disponible en el repositorio debe tener MD5 o SHA suma de comprobación generada - De esta forma puede validar si lo que descargó es realmente lo que quería. Pero, si el atacante (virus) es lo suficientemente inteligente como para interceptar su transferencia de datos y desordenar los archivos JAR, también será lo suficientemente inteligente como para interceptar sumas de comprobación md5/sha. La defensa en contra de esto es proporcionar firmas PGP para sumas de verificación y artefactos: los artefactos de lanzamiento cargados en repo central están obligados a hacerlo (archivos .asc)
La buena idea es usar Nexus Professional: usted podría configurar conjunto de adquisiciones para verificar la firma de PGP contra un servidor de clave pública cada vez que se descarga artefacto. Más información acerca de firmas PGP con Maven se puede encontrar aquí:
https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
Puedo pensar en varios escenarios, aunque el primero no es específico de Maven.
envenenamiento de caché DNS
Los datos DNS se utiliza para llegar a los repositorios estándar podría ser envenenados, causando Maven para descargar los artefactos de un repositorio diferente. Ver the wikipedia article on DNS cache poisoning.
repositorios no estándar
cualquier repositorio se agrega a la configuración de Maven podría proporcionar artefactos que incluyen código malicioso. Prevenga esto usando solo repositorios de terceros en los que confíe.
envenenamiento Repositorio
Basado en Guide to uploading artifacts to the Central Repository de Maven, parece que el repositorio central de Maven publica artefactos de los anfitriones del repositorio aprobados, por lo que la seguridad de los artefactos depende del huésped. No sé detalles sobre el proceso de convertirse en un servidor de repositorio aprobado, pero con tan pocos listados es probablemente oneroso.
Además, el repositorio central requiere firmas PGP para todas las implementaciones, por lo que a menos que un usuario malintencionado obtenga acceso a la clave privada para un proyecto, no creo que esto sea posible.
modificación Artefacto durante la transmisión (hombre en el medio)
Maven hace la verificación automática de suma de control para todos los artefactos, así que el atacante tendría que modificar el artefacto y las sumas de comprobación se acompañan para inyectar código malicioso. No sé si podría evitarlo por completo, pero para asegurarse de prestar atención a las sumas de comprobación, asegúrese de que su política de suma de comprobación no esté configurada para ignorar. Vea el settings doc.
Como han mencionado otros comentaristas, una buena manera de evitar que el código malicioso penetre en la implementación de producción es utilizar sólo un repositorio Maven interna para la liberación de producción se basa. Al restringir el acceso a la adición de dependencias a ese repositorio, puede asegurarse de que todas sean verificadas en el nivel que elija, p. verificación doble de suma de verificación, exploración de fuente.
Relacionados: http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/ –
He escrito una regla de plugin Enforcer para este propósito: https://github.com/gary-rowe/BitcoinjEnforcerRules –
@GaryRowe Parece que su complemento evita las descargas posteriores que no coinciden con las sumas de comprobación registradas por horneando las sumas de comprobación en la compilación (que reduce la superficie de ataque, lo cual es bueno), pero esto no parece proteger en el momento en que se crea la compilación por primera vez y la lista de suma de comprobación se escribe (o se genera). Básicamente, evitas que la construcción se envenene * a otra persona * ¿verdad? ¿Es eso una comprensión correcta de tu complemento? – Gus