Four Ways to Forge a Bundle My Own Verifier Calls Clean: Refusal-Site Mutation Testing of an Evidence-Bundle Verifier

En el mundo digital moderno, los sistemas de software suelen basarse en una idea simple pero poderosa: confiar, pero verificar. Cuando un programa informático afirma haber resuelto un problema difícil o haber analizado un conjunto masivo de datos, produce un informe. Para asegurar que este informe sea honesto, otros programas actúan como auditores. Estos auditores comprueban las matemáticas, verifican que los archivos de datos no hayan sido manipulados y confirman que las cifras del resumen coincidan con la evidencia bruta. Si todo cuadra, el auditor da luz verde y el resultado se publica para que el mundo lo vea. Este proceso es la columna vertebral de la fiabilidad del software, permitiendo que extraños confíen en el trabajo de otros sin necesidad de conocerse entre sí. Sin embargo, para que este sistema funcione, el propio auditor debe ser perfecto. Si el auditor no logra detectar una mentira, o peor aún, si declara que una mentira es verdadera sin haber examinado realmente la evidencia, el sistema entero colapsa. El peligro no es solo que se cuele un mal resultado, sino que el auditor pueda estar tan averiado que apruebe una prueba sin haber ejecutado la prueba en absoluto.

Un investigador llamado Erik Hill se propuso examinar uno de esos auditores, un programa diseñado para verificar paquetes de evidencia para un sistema fuera de línea. Quería saber una pregunta específica y perturbadora: ¿con qué frecuencia este programa dice "aprobado" cuando en realidad no ha comprobado nada? Para averiguarlo, no se limitó a buscar errores; construyó una herramienta para romper sistemáticamente su propio auditor. Tomó cada una de las líneas de código del programa que supuestamente debían rechazar un paquete defectuoso y, una por una, las desactivó. Luego, observó si la suite de pruebas del programa se daba cuenta. Si las pruebas seguían pasando después de eliminar una línea de rechazo, significaba que esa línea de rechazo era peso muerto: no estaba haciendo ningún trabajo en absoluto. Los resultados fueron sorprendentes. Al inicio del estudio, dos tercios de los puntos de rechazo del auditor eran invisibles para las pruebas. El programa podía ser despojado de la mayor parte de su capacidad para decir "no" y seguir reportando una puntuación perfecta. Era como si un guardia de seguridad hubiera sido entrenado para buscar artículos robados, pero los ejercicios de entrenamiento nunca hubieran incluido un artículo robado, por lo que el guardia nunca aprendió a buscar uno.

El estudio comenzó con una sacudida de un experto externo. Un ingeniero independiente envió un paquete de evidencia donde las cifras principales eran completamente falsas y, aun así, el auditor imprimió un aprobado perfecto. El fraude costó solo cuatro bytes de crear. El ingeniero había reemplazado un archivo con un marcador de posición diminuto y vacío, y debido a que el auditor no verificó que el archivo estuviera realmente allí, asumió que todo estaba bien. Hill reparó este agujero específico, pero luego aplicó su propia herramienta sistemática al programa reparado. Descubrió que el problema no era solo un error, sino un patrón. Descubrió cuatro formas más de engañar al auditor, encontrando en cada ocasión que el programa se saltaba una comprobación por completo. Uno de estos trucos consistía en cambiar una sola letra mayúscula en una etiqueta de severidad, lo que causaba que el programa ignorara el peso de un fallo de comprobación. Otro consistía en eliminar una clave de una lista, lo que provocaba que el programa se saltara una comparación porque el elemento que debía comparar no estaba presente. En cada caso, el programa no estaba fallando al realizar un cálculo difícil; simplemente estaba fallando al no iniciar el cálculo.

Para medir qué tan extendido estaba este problema, Hill ejecutó su herramienta de eliminación contra el código del auditor. Encontró 112 lugares donde el programa debía decir "no". Cuando los eliminó uno por uno, 75 de ellos pudieron ser eliminados sin que ninguna prueba fallara. Esto significaba que 75 de los 112 puntos de rechazo eran efectivamente invisibles para las comprobaciones de seguridad del sistema. El programa tenía una puntuación de 0.330, lo que indicaba que solo cerca de un tercio de sus mecanismos de rechazo estaban siendo realmente probados. Los dos tercios restantes eran "aprobaciones vacuas": comprobaciones que reportaban éxito a pesar de que nunca habían examinado la evidencia. Esto no es un fallo raro; es un defecto estructural donde la red de seguridad tiene agujeros por los que nadie ha intentado caer. Las pruebas comprobaban que el programa se ejecutaba, no que realmente mirara los datos.

Hill probó un enfoque común para solucionar tales problemas: simplemente corregir los errores específicos que se encontraron y añadir una prueba para cada uno. Reparó los cuatro fraudes que había descubierto y añadió nuevas pruebas para asegurar que esos trucos específicos no volvieran a funcionar. Sorprendentemente, esto no mejoró la puntuación de seguridad general. El programa seguía teniendo los mismos 75 puntos de rechazo invisibles. Las nuevas pruebas solo cubrían los nuevos agujeros que acababa de parchear, dejando el resto del sistema igual de ciego que antes. Fue solo cuando cambió su estrategia cuando las cifras se movieron. En lugar de arreglar errores, escribió una nueva prueba para cada uno de los la 75 puntos de rechazo invisibles, obligando al programa a demostrar que podía activar cada uno de ellos. Este enfoque sistemático elevó la puntuación de 0.330 a 1.000, demostrando que cada punto de rechazo podía, de hecho, ser activado. La lección fue clara: arreglar errores conocidos no hace que un sistema sea seguro; debes demostrar que cada uno de los mecanismos de seguridad puede realmente funcionar.

El estudio también reveló un problema más profundo sobre cómo se construyen estos sistemas. El investigador descubrió que el auditor a menudo trataba de forma distinta los informes legibles por humanos de los archivos de datos brutos utilizados para la verificación. Cuando un paquete incluía un informe destinado a la lectura de una persona, el auditor frecuentemente fallaba al verificar si el informe coincidía con los datos subyacentes. Era como si el auditor confiara en la página de resumen pero ignorara los recibos. Esto ocurrió en múltiples proyectos diferentes, lo que sugiere un hábito común entre los desarrolladores: vinculan los datos que la computadora comprueba, pero dejan los datos que los humanos leen sin verificar. El investigador descubrió que esta brecha permitía que se colaran afirmaciones falsas, donde un informe podía decir "todos los defectos corregidos" mientras los datos mostraban lo contrario.

A lo largo del estudio, las propias herramientas del investigador le fallaron de maneras que reflejaban el mismo problema que estaba estudiando. Sus instrumentos de medición a veces reportaban éxito incluso cuando no estaban midiendo nada. En una ocasión, una herramienta diseñada para detectar fallos devolvió una puntuación perfecta porque la suite de pruebas base ya había fallado, causando que la herramienta malinterpretara el error como un éxito. Esto sucedió siete veces durante la investigación, incluyendo una vez donde la herramienta dio una puntuación perfecta mientras el sistema estaba roto. Estos fallos no fueron ocultados; fueron documentados en el artículo para mostrar que las herramientas utilizadas para verificar el software son tan vulnerables a estos errores de "aprobación vacua" como el software que deben comprobar.

La conclusión final del trabajo es un llamado a un tipo diferente de pruebas. El investigador argumenta que no podemos confiar en una lista de errores conocidos para mantener un sistema seguro. Si un sistema tiene una puerta de seguridad que nunca ha sido observada fallando, nunca ha sido observada funcionando. La única forma de estar seguro es probar sistemáticamente cada una de las puertas para asegurar que realmente puedan activarse. El estudio demostró que un sistema puede parecer perfecto en el papel mientras está fundamentalmente roto en la práctica. Al obligar al auditor a demostrar que podía rechazar datos malos de todas las formas posibles, el investigador convirtió un sistema que era ciego a sus propios fallos en uno que estaba totalmente verificado. El trabajo se mantiene como un recordatorio de que, en el mundo de la confianza digital, el error más peligroso no es un fallo de comprobación, sino una comprobación que nunca ocurrió.