- El código Clod ejecuta comandos peligrosos cuando lo trata como una rutina de recuperación
- Un único mensaje de error falso desencadena toda la cadena de ataques ocultos
- Los escáneres estáticos y los firewalls no vieron más que simples resoluciones DNS
Los investigadores del equipo 0din de Mozilla han demostrado cómo se puede utilizar el código de la nube para abrir un shell inverso oculto en el dispositivo de un desarrollador.
El exploit no requirió código malicioso dentro del proyecto clonado, ya que cada archivo visible pasó la revisión normal sin sospechas.
En cambio, la peligrosa instrucción llegó más tarde, obtenida en tiempo de ejecución de un registro de texto DNS que ningún escáner inspeccionaría jamás.
Cómo un error de configuración de rutina se convierte en un punto de entrada
El ataque comenzó con un extraordinario archivo Markdown que explicaba cómo instalar un paquete llamado Axiom, una sencilla herramienta de seguimiento.
Ejecutar la herramienta sin iniciarla genera un mensaje de error simple que indica al usuario que ejecute un comando de configuración específico.
El equipo de investigación observó que este patrón se parece mucho a la resolución típica de problemas de los desarrolladores, razón por la cual evadió las sospechas de manera tan efectiva.
Cloud Code, simplemente tratando de ser útil, sigue esas instrucciones escritas automáticamente, tratando la corrección documentada como una recuperación de error de rutina normal.
Este único comando desencadenó un script de shell oculto que buscaba silenciosamente un registro de texto DNS totalmente controlado por el atacante remoto.
El registro se decodifica en un comando de shell inverso codificado en base64, que se ejecuta de forma silenciosa y se conecta directamente al servidor remoto del atacante.
La persistencia alguna vez fue posible en el interior, ya que un atacante podía colocar una clave SSH o programar un trabajo cron oculto.
Un único enlace de repositorio compartido en una publicación de trabajo o mensaje de chat puede exponer a todos los desarrolladores que lo abran de forma sencilla.
Las herramientas de seguridad habituales, como el software antivirus o la protección mediante cortafuegos, no detectaron este fallo porque ninguno de los pasos individuales parecía sospechoso por sí solo.
Las herramientas de escaneo de código estático solo registran una búsqueda de DNS de rutina, lo que no indica que esté sucediendo nada malicioso.
El monitoreo de la red no registró más que una simple resolución de nombre de dominio, y el propio agente vio el comando como una configuración previamente autorizada.
0din enfatizó que los agentes codificadores deben inspeccionar exactamente qué script de configuración se ejecutará antes de ejecutar cualquier cosa.
Concluye que los desarrolladores nunca deberían confiar en un repositorio desconocido, sin importar cuán genéricos parezcan sus archivos de configuración.
Este caso sugiere que las herramientas de inteligencia artificial basadas en modelos de lenguaje grandes pueden necesitar una protección de tiempo de ejecución más sólida.
Hasta que dichos agentes puedan evaluar de manera significativa lo que realmente ejecuta un comando, seguirá siendo difícil prevenir ataques indirectos similares.
La lección más amplia se extiende más allá del código obstruido, ya que la mayoría de los sistemas de IA agentes comparten puntos ciegos similares a la hora de inyectar indicaciones indirectas.
Por ahora, tratar la automatización desconocida como un riesgo real es la protección más confiable disponible para la mayoría de los desarrolladores independientes.
Siga TechRadar en Google News Y Agréganos como fuente preferida Recibe noticias, reseñas y opiniones de nuestros expertos en tu feed.
