En el mundo de la seguridad informática, hay fallos que cambian las reglas del juego. Copy Fail (técnicamente registrado como CVE-2022-0847) es uno de ellos. No es solo un error de código; es un fallo conceptual en cómo el Kernel de Linux gestiona la memoria caché, permitiendo que un usuario sin permisos pueda «reescribir» archivos protegidos del sistema.

Hoy analizamos qué hay detrás de la web copy.fail y cómo un simple script de Python puede comprometer un servidor entero.

¿Qué es exactamente el «Copy Fail»?

El nombre «Copy Fail» (Fallo de Copia) describe perfectamente el problema: el kernel falla al intentar realizar una operación de escritura segura.

Normalmente, si intentas modificar un archivo de «solo lectura», el sistema debería crear una copia nueva para ti (Copy-on-Write). Sin embargo, debido a este fallo, el Kernel permite escribir directamente en la caché de páginas (la memoria RAM donde se guarda el archivo para ir más rápido), saltándose todas las restricciones de permisos.

Análisis del exploit: Del script a la ejecución

El código que circula asociado a copy.fail es una obra de ingeniería minimalista. Vamos a desgranar la línea que más nos llamó la atención:

f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))

1. El objetivo: El binario su

El script abre el archivo /usr/bin/su. Este binario es fundamental porque tiene permisos SUID, lo que significa que cuando se ejecuta, lo hace con la autoridad del superusuario (root).

2. La carga útil (Payload) cifrada

Para evitar ser detectado por antivirus o sistemas de inspección de tráfico, el código malicioso no viaja en texto plano. Se encuentra en una cadena hexadecimal que el script:

1. Convierte a binario.
2. Descomprime (mediante zlib).
3. Trata como un bloque de datos cifrado (en el sentido de que está oculto y empaquetado).

3. La inyección en memoria

Utilizando la vulnerabilidad Copy Fail, el script inyecta estos datos directamente en la memoria caché del archivo /usr/bin/su. No modifica el archivo en el disco duro, sino la versión que el sistema tiene cargada en la RAM. Al ejecutar su, el sistema corre el código inyectado (el shellcode) en lugar del programa original.

¿Por qué es tan peligroso para tu empresa?

La peligrosidad de Copy Fail reside en su naturaleza efímera y potente:

• Es extremadamente fácil de usar: Un atacante solo necesita ejecutar un script de Python. No requiere compilar código complejo en la máquina víctima ni descargar herramientas externas pesadas; basta con un intérprete de Python y acceso a una terminal básica
• Es difícil de detectar: Al no modificar archivos físicos en el almacenamiento, muchas herramientas de integridad de archivos no dan la alarma de inmediato.
• Acceso total: En menos de un segundo, un usuario invitado se convierte en el dueño absoluto del servidor.
• Sin huella persistente: El ataque no modifica el archivo /usr/bin/su en el disco duro. Solo altera la copia que vive en la memoria RAM. Si el servidor se reinicia, la evidencia desaparece de la memoria caché.
• Bypass de protecciones estándar: Al operar a nivel de caché de páginas del kernel, puede evadir sistemas de detección de intrusiones que solo vigilan cambios en el sistema de archivos.

---

Plan de Acción: Cómo parchear y protegerse

Si gestionas infraestructura Linux, el «Copy Fail» debe estar en tu radar de prioridades. Aquí te explicamos cómo asegurar tus equipos:

1. Identificación y Actualización

Este fallo afecta a los Kernels de Linux desde la versión 5.8. Si tus servidores corren versiones antiguas de las ramas 5.10, 5.15 o 5.16, eres vulnerable.

• Acción inmediata: Actualiza el kernel a las versiones corregidas: 5.16.11, 5.15.25, 5.10.102 o superiores.

2. Monitorización del Sistema

Es posible configurar el demonio de auditoría de Linux (auditd) para monitorizar llamadas al sistema sospechosas. Vigilar el uso inusual de splice() o intentos de escritura anómalos en binarios SUID puede proporcionar una alerta temprana.

3. Reducción de la superficie de ataque

• Limitar intérpretes: Si un servidor de producción no necesita Python, elimínalo. Menos herramientas disponibles para el atacante significan menos caminos para el exploit.
• Hardening de SUID: Revisa qué archivos tienen permisos de superusuario y elimina los que no sean críticos.
  • Auditoría de SUID: Ejecute find / -perm -4000 para identificar qué archivos tienen privilegios de root y elimine el bit SUID de aquellos que no sean estrictamente necesarios para la operación del servidor.
  • Restricción de intérpretes: En entornos de producción críticos, limite el acceso a Python, compiladores y otras herramientas de desarrollo a usuarios específicos o elimínelos de las imágenes de contenedores.
  • Sistemas de Control de Acceso (MAC): El uso de SELinux o AppArmor con perfiles estrictos puede bloquear la capacidad de un proceso para interactuar con sockets AF_ALG o realizar operaciones de splice no autorizadas, añadiendo una barrera defensiva incluso si el kernel es vulnerable.

---

En TIIZSS, entendemos que la seguridad del Kernel es la base de la confianza digital. El caso de Copy Fail nos recuerda que incluso las piezas más estables del software pueden tener grietas. Mantenerse actualizado no es una opción, es una necesidad vital para la continuidad del negocio.

¿Desea una auditoría de seguridad para verificar la resistencia de su infraestructura ante ataques de escalada de privilegios? Nuestro equipo técnico está especializado en hardening de sistemas Linux y detección de vulnerabilidades de memoria. Contacte con nosotros para asegurar su entorno.