El lado oscuro del código abierto: cuando lo "desactivado" sigue activo

El software, incluso cuando se supone que tiene funcionalidades deshabilitadas o no esenciales, puede estar exponiendo una complejidad que no debería a usuarios no autenticados. Esta es la cruda realidad que ha puesto de manifiesto el equipo Frontier Red Team de Anthropic. Armados con su inteligencia artificial Claude, han examinado 25 proyectos de código abierto, desvelando la friolera de 493 problemas relacionados con:

  • Exposición innecesaria de código.
  • Configuraciones contradictorias.
  • Ejecución de código antes de las comprobaciones de seguridad pertinentes.

La clave aquí es la "reducción de la superficie de ataque", una estrategia que busca limitar las partes del software a las que un atacante puede llegar. En lugar de esperar a que surja una vulnerabilidad, los desarrolladores pueden restringir el acceso a funciones que no son necesarias o adelantar las verificaciones de seguridad antes de procesar información compleja.

Errores de configuración que abren puertas traseras

La investigación se centró en tres tipos de exposición crítica:

  1. Código accesible por defecto sin una funcionalidad intencionada.
  2. Combinaciones de ajustes que debilitan las protecciones de forma inesperada.
  3. Código sensible o complejo que se ejecuta antes de cualquier verificación de seguridad o interacción de usuario.

De los 11 proyectos analizados que deberían restringir el acceso a usuarios autenticados, todos contenían código que era accesible antes de la autenticación. Aunque estos hallazgos no eran directamente explotables por sí solos, aumentaban significativamente la superficie de ataque.

Pero lo más alarmante llegó con las interacciones de configuración. Claude identificó 162 combinaciones de configuraciones sensibles a la seguridad que eran aceptadas sin errores, advertencias ni documentación clara sobre su comportamiento combinado. En 94 de estos casos, las configuraciones deshabilitaban silenciosamente un control de seguridad.

Imagina esto: en cuatro proyectos distintos, las reglas de acceso basadas en el nombre de host dependían de una configuración separada para las búsquedas de DNS inverso. Si estas búsquedas se desactivaban, el servidor comparaba la regla del nombre de host con la dirección IP del cliente. ¿El resultado? Las reglas de denegación basadas en el nombre de host fallaban, permitiendo conexiones que los administradores pretendían bloquear.

Otro ejemplo espeluznante: dos configuraciones que, al combinarse, hacían que un servidor configurado para requerir certificados de cliente aceptara conexiones de cualquiera. Lo peor es que los administradores no recibían ninguna advertencia de que el requisito del certificado se había desactivado. Según Anthropic, estas opciones conflictivas habían existido en el software durante 21 años.

Como bien señaló Chris Rohlf de Anthropic, "estas técnicas no eliminan las vulnerabilidades desconocidas en el código, pero sí hacen que las vulnerabilidades sean más difíciles de alcanzar".

OpenSSH como caso de estudio: reduciendo la superficie de ataque con IA

Incluso proyectos tan robustos como OpenSSH, que proporciona acceso remoto seguro, no son inmunes. Claude identificó aproximadamente 4.500 líneas de código criptográfico experimental accesibles para clientes no autenticados, incluso cuando los administradores habían excluido explícitamente el algoritmo.

Este código implementaba ML-DSA-44, un algoritmo de firma post-cuántico. OpenSSH procesaba la clave suministrada antes de verificar si su tipo estaba permitido. Anthropic informó del problema a los mantenedores de OpenSSH y proporcionó parches. Aunque OpenSSH 10.5 movió la verificación antes del análisis, Claude aún detectó dos brechas más: un cliente podía falsear el tipo de clave y el procesamiento de certificados aún podía alcanzar el código de verificación de firma antes de las comprobaciones de configuración relevantes.

Tras un trabajo colaborativo, los cambios en OpenSSH 10.6 lograron reducir el código accesible antes de la autenticación en aproximadamente un quinto en una compilación por defecto. El beneficio fue claro: restringir el acceso innecesario sin tener que buscar una vulnerabilidad específica en ese código.

La metodología de Anthropic: una habilidad de Claude para la seguridad

Anthropic ha integrado estas técnicas en una "habilidad" reutilizable de Claude, que planea incorporar a OSS Scanner, su servicio gratuito de escaneo de seguridad para proyectos de código abierto. Esta habilidad se encarga de:

  • Detectar código innecesariamente expuesto por defecto.
  • Identificar funcionalidades accesibles antes de la autenticación o de otros controles de seguridad.
  • Descubrir combinaciones de configuraciones que debilitan las protecciones de forma silenciosa.

Claude valida sus hallazgos mediante trazas de ejecución dinámica. Para las configuraciones por defecto, implementa "puertas" propuestas y compara las compilaciones modificadas con una línea base utilizando las propias pruebas del proyecto. Cualquier cambio de comportamiento en una configuración no predeterminada se revisa manualmente. Para el resto, Claude propone cambios como mover una verificación de configuración o rechazar configuraciones conflictivas.

Este enfoque va más allá del análisis de código. Claude también puede comparar registros de tiempo de ejecución con configuraciones para identificar funcionalidades innecesarias, como analizadores no utilizados o protocolos heredados, que los operadores podrían deshabilitar para reducir el riesgo de seguridad. Una herramienta potente para un problema complejo.