IA utilizada para detectar problemas de seguridad
Hace pocos días, Daniel Stenberg (el autor de Curl) dio a conocer en su blog, una publicación en la cual expresa no solo como una crítica el uso de herramientas de inteligencia artificial, sino en forma de reclamo, las molestias que esto genera a él y a su equipo, los informes de seguridad generados por las herramientas de inteligencia artificial.
Y es que en su publicación, Daniel Stenberg menciona que durante muchos años el proceso de verificar todos los informes y descartar entre los problemas de seguridad “basura” y “reales”, no era algo que supusiera un esfuerzo adicional, pues menciona que «los informes basura normalmente también han sido muy fáciles y rápidos de detectar y descartar».
Con el reciente auge de la inteligencia artificial, se han revolucionado muchas tareas que anteriormente requerían muchas horas de intervención humana. Entre los casos más mencionados en este blog, hemos abordado los temas de IAs dedicadas a la programación, generación de imágenes, edición de video, como ChatGPT, Copilot, Bard, entre otras.
En el ámbito específico de la programación, Copilot generó numerosas críticas, siendo la principal preocupación la posibilidad de enfrentar demandas legales. Sin embargo, en el otro extremo de la balanza, la intervención de la inteligencia artificial ha transformado significativamente diversas áreas. Por ejemplo, en la detección de errores y problemas de seguridad en el código, las IAs han desempeñado un papel crucial. Muchas personas han adoptado estas herramientas para identificar posibles fallos y vulnerabilidades en el código, a menudo participando en programas de recompensas por la detección de problemas de seguridad.
Curl no escapó de esta tendencia, y Daniel Stenberg expresó en su blog que, después de varios meses de contener su opinión, finalmente explotó en desacuerdo con el uso de herramientas de inteligencia artificial. La razón detrás de su frustración fue la creciente cantidad de informes «basura» generados por el uso de estas herramientas.
En la publicación, se destaca que estos informes poseen una apariencia detallada, están redactados en un lenguaje normal y parecen ser de alta calidad. Sin embargo, sin un análisis cuidadoso, resultan ser engañosos, ya que reemplazan problemas reales con contenido de baja calidad que aparenta ser valioso.
El proyecto Curl, que ofrece recompensas por la identificación de nuevas vulnerabilidades, ha recibido un total de 415 informes sobre posibles problemas. De este conjunto, solo 64 fueron confirmados como vulnerabilidades reales, 77 describieron errores no relacionados con la seguridad y, sorprendentemente, 274 (66%) no contenían información útil, consumiendo el tiempo de los desarrolladores que podría haberse dedicado a algo útil.
Los desarrolladores se ven obligados a perder mucho tiempo analizando informes inútiles y verificando varias veces la información contenida allí, ya que la calidad externa del diseño crea confianza adicional en la información y existe la sensación de que el desarrollador no entendió algo.
Por otro lado, generar un informe de este tipo requiere un esfuerzo mínimo por parte del solicitante, que no se molesta en comprobar si hay un problema real, sino que simplemente copia a ciegas los datos recibidos de los asistentes de IA, esperando tener suerte en la lucha por recibir una recompensa.
Daniel Stenberg, comparte dos ejemplos de este tipo de informes basura:
- En el primer caso, justo antes de la divulgación planificada de la información sobre una vulnerabilidad crítica en octubre, se recibió un informe a través de HackerOne indicando que ya existía un parche público para resolver el problema. Sin embargo, el informe resultó ser «falso», ya que contenía datos sobre problemas similares y fragmentos de información detallada sobre vulnerabilidades pasadas, compilados por el asistente de inteligencia artificial de Google, Bard. Aunque la información parecía novedosa y relevante, carecía de conexión con la realidad.
- En el segundo caso, se recibió un informe sobre un desbordamiento de búfer en el manejo de WebSocket. Este informe provenía de un usuario que ya había informado sobre vulnerabilidades a varios proyectos a través de HackerOne. Para reproducir el problema, el informe proporcionaba instrucciones generales sobre cómo enviar una solicitud modificada y un ejemplo de corrección.
A pesar de verificar detalladamente tres veces el código, el desarrollador no encontró ningún problema. Sin embargo, dado que el informe estaba redactado de tal manera que generaba “cierta” confianza e incluso presentaba una solución propuesta, persistía la sensación de que algo no encajaba.
En un esfuerzo por aclarar cómo el usuario logró eludir la verificación de tamaño, se menciona que las explicaciones no contenían información adicional y solo analizaban causas comunes obvias de desbordamiento de búfer no relacionadas con el código de Curl. Las respuestas recordaban a la comunicación con un asistente de IA, y después de intentos inútiles para descubrir exactamente cómo se manifestaba el problema, Daniel Stenberg finalmente se convenció de que en realidad no existía ninguna vulnerabilidad y cerro el tema como no “aplicable”.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.