Por Canuto  

Anthropic afirma que Claude identificó 493 problemas de exposición innecesaria en 25 proyectos de código abierto. El análisis buscó reducir el código accesible sin depender de encontrar una vulnerabilidad concreta. En OpenSSH, los mantenedores incorporaron cambios que limitaron el acceso a código experimental de análisis de claves.
***

  • Según Anthropic, Claude analizó más de cinco millones de líneas de código y examinó más de 17.000 opciones de configuración en 25 proyectos.
  • El análisis identificó combinaciones que debilitaban controles de seguridad y código accesible antes de la autenticación.
  • Anthropic afirma que los mantenedores incorporaron cambios en OpenSSH 10.5 y 10.6 para restringir el acceso a código de análisis de claves.

Claude detectó 493 problemas de exposición en proyectos de código abierto

Reducir el código que puede alcanzar un atacante, incluso sin descubrir una vulnerabilidad específica, puede limitar el impacto de fallas desconocidas.

Anthropic sostiene que su modelo Claude puede ayudar a conseguirlo al localizar funcionalidades expuestas sin necesidad y proponer barreras para restringirlas. En un análisis de 25 proyectos de código abierto, que sumaban más de cinco millones de líneas de código, la compañía reportó 493 problemas relacionados con configuraciones y rutas de ejecución. El caso más destacado terminó en cambios para OpenSSH.

Una defensa que no depende de encontrar cada vulnerabilidad

La seguridad del software suele centrarse en identificar una falla concreta y corregirla, una tarea que no garantiza que desaparezcan otros riesgos en la misma base de código. Anthropic plantea complementar ese enfoque con la reducción de la superficie de ataque: identificar las partes del programa que un despliegue realmente necesita exponer y restringir las demás, aunque todavía no se haya probado que contienen una vulnerabilidad.

El razonamiento parte de que una falla desconocida puede causar menos daño si el código afectado no está disponible para cualquier conexión o no se ejecuta antes de una verificación importante. La técnica no elimina errores ni demuestra que una aplicación esté libre de vulnerabilidades, pero puede hacer más difícil alcanzar ciertas rutas de ejecución, incluidas aquellas que un atacante podría buscar activamente.

El artículo de Anthropic, firmado por Chris Rohlf, presenta tres formas de buscar exposiciones innecesarias. La primera examina funcionalidades activas con la configuración predeterminada que no parecen necesarias para las funciones habilitadas; la segunda detecta opciones que, al combinarse, producen efectos inesperados sobre las protecciones.

La tercera forma revisa código complejo y sensible para la seguridad que se ejecuta demasiado pronto, por ejemplo, antes de autenticar a un cliente, antes de una interacción del usuario o antes de que una sesión avance a un estado determinado. En todos los casos, el objetivo consiste en ubicar el código y moverlo detrás de una barrera adecuada, no en asumir que cada hallazgo ya constituye una intrusión o una vulnerabilidad explotable.

Qué encontró el análisis en 25 proyectos

Según Anthropic, Claude examinó proyectos escritos en lenguajes como C, C++, Java, PHP y Python, y elaboró un inventario de más de 17.000 opciones de configuración. De ese total, 3.842 estaban relacionadas con controles o funciones relevantes para la seguridad, una base que permitió revisar tanto los valores por defecto como las interacciones entre opciones.

Anthropic clasificó los proyectos en tres grupos: públicos, protegidos y privados. Los públicos atienden a cualquier usuario que pueda llegar al servicio o procesan datos de terceros que no pueden identificar; los protegidos están destinados a usuarios autenticados, mientras que los privados sirven al entorno del operador y no necesariamente incluyen autenticación como parte de su función.

Los resultados sumaron 493 problemas en las tres técnicas. La cohorte protegida concentró una parte especialmente llamativa: los 11 proyectos de ese grupo tenían código alcanzable de manera no prevista, aunque Anthropic indicó que no representaba un porcentaje significativo de las líneas totales de ninguno de ellos.

En esos proyectos, Claude señaló 93 superficies innecesarias accesibles antes de la autenticación con la configuración predeterminada, 37 puntos donde se ejecutaba código o se registraba estado antes de autenticar y 61 combinaciones de configuración que debilitaban silenciosamente un control previo a la autenticación. La empresa precisó que esos hallazgos no eran, por sí solos, explotables de inmediato, pero ampliaban el código expuesto sin una necesidad aparente.

Combinaciones de opciones que debilitan protecciones

El análisis identificó 162 combinaciones de configuración sensibles a la seguridad que el software aceptaba sin error ni advertencia y cuyo comportamiento conjunto tampoco estaba documentado. En 94 casos, la combinación desactivaba silenciosamente un control de seguridad; en los otros 68, Claude encontró incoherencias, como rutas que seguían disponibles pese a que una opción indicaba que debían estar deshabilitadas.

Entre las inconsistencias detectadas figuraban opciones en conflicto cuya precedencia dependía del orden en el archivo de configuración, además de protecciones administrativas que no surtían efecto mientras el código correspondiente seguía siendo alcanzable. Algunas combinaciones podían ser poco habituales, reconoce el análisis, pero los proyectos permitían que un administrador las configurara y desplegara sin advertirle claramente de sus consecuencias.

Anthropic encontró un patrón de forma independiente en cuatro proyectos sin relación entre sí. Un administrador podía definir una regla de acceso para clientes remotos con un nombre de host o un comodín, pero el servidor solo podía conocer la dirección IP si las búsquedas inversas de DNS estaban desactivadas; al comparar el nombre con una dirección IP en texto plano, la regla de denegación no coincidía y la lista terminaba fallando en modo abierto.

Algunos proyectos mencionaban en su documentación que las reglas basadas en nombres dependían de las búsquedas DNS, pero ninguno advertía que una regla de denegación configurada de ese modo podía dejar de aplicarse. En otro ejemplo descrito por Anthropic, dos opciones aceptadas en conjunto hacían que un servidor que debía exigir certificados de cliente dejara de verificar esa identidad, exponiendo a clientes no autenticados código que debía permanecer detrás del control.

El caso de OpenSSH y el análisis de claves

OpenSSH fue el proyecto donde Claude logró la mayor reducción proporcional de superficie de ataque, según la medición de Anthropic. Al rastrear las rutas de entrada del demonio SSH en la versión 10.4, el modelo encontró aproximadamente 4.500 líneas de código nuevo y experimental relacionado con el esquema de firma poscuántica ML-DSA-44/Ed25519 que un cliente no autenticado podía alcanzar con la configuración predeterminada.

El esquema ML-DSA-44/Ed25519 no estaba habilitado por defecto, pero el demonio analizaba el tipo de clave enviado por el cliente y, para los certificados, también verificaba la firma de la autoridad certificadora incrustada antes de comprobar si ese tipo de clave estaba permitido. Anthropic calculó que esas líneas equivalían a cerca del 16% del código de OpenSSH accesible antes de la autenticación en una instalación predeterminada, y comunicó el hallazgo a los desarrolladores junto con parches.

La versión 10.5 adelantó una verificación, pero Claude encontró dos lagunas en ese cambio. En la primera, el programa comprobaba el nombre del algoritmo anunciado por el cliente, mientras que el analizador dependía de una cadena de tipo dentro del bloque de claves; por eso, un cliente podía anunciar «ssh-ed25519» y enviar una clave ML-DSA para que se analizara.

La segunda laguna afectaba a certificados: como los tipos de clave de certificado estaban habilitados por defecto, el demonio podía deserializar una clave pública de autoridad certificadora y ejecutar una verificación de firma antes de consultar la configuración. Anthropic indicó que la ruta de firma de la clave de usuario sí estaba limitada por la lista de claves permitidas, pero la de la autoridad certificadora no, lo que hacía alcanzables los verificadores de firma del binario para clientes capaces de completar un intercambio de claves.

El equipo construyó una prueba de concepto y trabajó con los mantenedores en varias iteraciones. La solución final colocó las comprobaciones dentro del analizador, donde el tipo de clave y el algoritmo de firma de la autoridad certificadora se comparan con las listas permitidas antes de deserializar o verificar la firma correspondiente.

Según Anthropic, esos cambios eliminaron cerca de una quinta parte del código que un cliente no autenticado podía alcanzar en una compilación predeterminada, casi todo el código experimental relacionado con ML-DSA. La compañía indicó que los mantenedores incorporaron los cambios descritos en la versión 10.6; los certificados firmados con un algoritmo permitido todavía pueden analizarse y verificarse, pero el control correspondiente se ejecuta antes del análisis.

Cómo plantea Anthropic aplicar el método

Anthropic reunió las técnicas en una habilidad reutilizable para Claude que trabaja en tres pasadas, cada una iniciada desde cero y con una ventana de contexto vacía, salvo por un fragmento breve procedente de la etapa anterior. La primera busca código que la configuración predeterminada deja alcanzar aunque ninguna función prevista lo necesite; la segunda rastrea lo que se ejecuta antes de una barrera de autenticación o de una transición válida del protocolo.

La tercera pasada examina combinaciones de opciones que pueden desactivar silenciosamente un control o reducir su eficacia. En cada etapa, Claude inventaría puntos de entrada y confirma los hallazgos mediante rastreo dinámico del programa, con el propósito de no limitarse a señalar patrones sospechosos en el código fuente.

Para hallazgos relacionados con la configuración por defecto, la herramienta propone e implementa una barrera y compara el comportamiento de la versión modificada con el de referencia. Anthropic afirma que utiliza las pruebas del propio proyecto y una suite de regresión de caja negra para exigir resultados idénticos; si un cambio altera una configuración no predeterminada, lo reserva para que una persona decida.

En las otras pasadas, Claude puede sugerir reordenar una comprobación, imponer el orden de estados de un protocolo o rechazar una combinación durante la carga de la configuración. Anthropic dijo que trabaja para integrar la habilidad en OSS-Scanner y sostuvo que el método también podría ayudar a desactivar analizadores, protocolos heredados o paneles de control que un despliegue no necesita.

La investigación no demuestra que el análisis automatizado sustituya las auditorías ni que elimine los riesgos desconocidos. Su argumento es más acotado: reducir la cantidad de código accesible puede rebajar el impacto potencial de fallas que aún no se han descubierto, y el caso de OpenSSH muestra que incluso un proyecto ampliamente auditado puede conservar rutas que no necesitaba exponer.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados