Inicio del ataque a la cadena de suministro
Hay muchas formas de ataques a la cadena de suministro - pirateo de repositorios, ataques iniciados por desarrolladores, manipulación de bibliotecas, secuestro de dominios, la lista continúa - pero un ataque en el que el malware busca deliberadamente tu software de desarrollo e infecta otros proyectos en tu sistema durante la compilación es algo diferente.
Aunque no se trata de un suceso reciente, muestra a la perfección la naturaleza avanzada y la innovación que conlleva la preparación de ataques de este tipo. La siguiente historia se basa en un informe creado por el equipo de seguridad de GitHub, disponible aquí. Ocurrió a principios de 2020, pero es tan interesante hoy como entonces por los giros inesperados que da el malware para infectar otras piezas de software no relacionadas.
La amenaza encubierta del ecosistema de código abierto
El Equipo de Respuesta a Incidentes de Seguridad (SIRT) de GitHub recibió una alerta sobre repositorios que, sin saberlo, servían proyectos de código abierto infectados con malware. El programa malicioso, llamado "Octopus Scanner", estaba diseñado específicamente para atacar proyectos de NetBeans. Utilizaba el proceso de compilación y los artefactos resultantes para propagarse.
Reduzcamos esto un poco. Cuando clonabas y construías el código contenido en uno de esos repositorios infectados, el malware buscaba activamente instalaciones de NetBeans (NetBeans es un IDE Java, Entorno de Desarrollo Integrado). Si lo encontrara, se integraría en el proceso de compilación de cualquier otro proyecto construido dentro de NetBeans, de forma que se incluiría a sí mismo (el malware) dentro de cualquier software de compilación. Dado que NetBeans es una herramienta para desarrolladores, si se encontrara, se utilizaría naturalmente para escribir código y crear varias aplicaciones Java diferentes, cada una de las cuales incluiría el malware.
Este descubrimiento fue alarmante no sólo por la existencia del malware, sino por su alcance potencial. Los repositorios afectados eran de código abierto, lo que significa que cualquier desarrollador u organización podía clonar sin saberlo el código infectado e introducir inadvertidamente vulnerabilidades en sus aplicaciones o sistemas.
Pero, ¿en qué afecta esto a los desarrolladores Java?
El mensaje subyacente: La necesidad de una cadena de suministro segura
Como desarrollador Java, es posible que se pregunte cómo asegurarse de que las bibliotecas y dependencias que utiliza son seguras. El incidente de Octopus Scanner subraya la importancia de proteger la cadena de suministro del código abierto. No se trata sólo de parchear las últimas CVE. Se trata de mantener la integridad de todo el ecosistema de desarrollo y distribución de software.
Entre en SecureChain para Java. Imagine un servicio en el que todas las dependencias y bibliotecas de Java que necesita han sido examinadas y analizadas en busca de vulnerabilidades. Se acabaron las dudas y las búsquedas en foros para determinar si es seguro utilizar una biblioteca. Securechain para Java ofrece un repositorio de dependencias de Java, que le garantiza que sólo utiliza bibliotecas libres de puertas traseras o vulnerabilidades conocidas.
Escáner Octopus: Una mirada más de cerca
El funcionamiento del Octopus Scanner era polifacético:
- Identificación e infección: El malware identificaba el directorio NetBeans del usuario, enumeraba todos los proyectos e incrustaba una carga maliciosa en los archivos de proyecto y en los archivos JAR de compilación.
- Persistencia: La carga maliciosa garantizaba que cada vez que se creaba un proyecto de NetBeans, se ejecutaba, lo que aseguraba aún más la propagación del malware.
- Sutileza: A diferencia de otros programas maliciosos, los propietarios de los repositorios no eran conscientes de que estaban introduciendo código backdoored, lo que complica aún más su detección y mitigación.
- Flexibilidad: Cuando se ejecutaba, soltaba tanto la carga útil como los componentes de software de mando y control en archivos JAR de otras aplicaciones. Esto permitía una gran diversificación y adaptabilidad por parte de los operadores del malware, ya que podían cambiar lo que se estaba desplegando en los sistemas infectados en caso de que se desplegaran contramedidas.
Como estaba muy dirigido, yendo específicamente a por los desarrolladores de Java, si no se encontraba NetBeans, no hacía nada en el sistema infectado. A diferencia de muchas otras formas de malware y ciberataques, que a veces van a por el mayor número de objetivos posibles con la esperanza de que un pequeño porcentaje de las víctimas previstas caiga en la trampa (como el ransomware o el phishing de correo electrónico), los ataques a la cadena de suministro golpean a los usuarios finales antes incluso de que tengan la oportunidad de hacer algo al respecto. Si el software que instalas ya está protegido, ninguna herramienta de seguridad podrá protegerte.
A la altura del desafío
El enfoque proactivo de GitHub en la gestión del incidente de Octopus Scanner, combinado con las herramientas que ofrece para detectar vulnerabilidades en las dependencias, establece un punto de referencia sobre cómo deben operar las plataformas de código abierto. Sin embargo, los desarrolladores individuales y las organizaciones también deben desempeñar su papel asegurándose de que utilizan fuentes fiables para sus dependencias de código.
A medida que la línea que separa una auténtica biblioteca de una puerta trasera se hace cada vez más difusa, la necesidad de un servicio como SecureChain para Java se convierte en algo primordial. No se trata solo de escribir código eficiente; se trata de escribir código seguro.
Reflexiones finales
El incidente del Octopus Scanner es un gran ejemplo de las vulnerabilidades presentes en el ecosistema de código abierto. También muestra lo variados y avanzados que pueden ser estos ataques. Aunque plataformas como GitHub están haciendo su parte, corresponde a los desarrolladores asegurarse de que sus dependencias proceden de fuentes fiables y verificadas.
Con SecureChain para Javapuede crear con confianza sus aplicaciones Java sabiendo que todas las bibliotecas y dependencias que utiliza están libres de vulnerabilidades. En un mundo en el que el código se comparte libremente, asegurémonos de que lo que compartimos es seguro.
Proteja sus proyectos Java. Confíe en SecureChain para Java.