[25/01/2022] Las palabras "caos" e "ingeniería" no suelen ir juntas. Al fin y al cabo, los buenos ingenieros mantienen el caos a raya. Sin embargo, últimamente los desarrolladores de software están desplegando lo que llaman vagamente "caos" en cantidades cuidadosas para reforzar sus sistemas informáticos revelando fallas ocultas. Los resultados no son perfectos -todo lo caótico no puede ofrecer garantías-, pero las técnicas suelen ser sorprendentemente eficaces, al menos en algunas ocasiones, y eso hace que merezcan la pena.
El proceso puede ser especialmente útil para los analistas de seguridad, porque su trabajo consiste en encontrar las puertas traseras no documentadas ni previstas. Las pruebas caóticas no pueden identificar todas las fallas de seguridad, pero pueden revelar vulnerabilidades peligrosas y sin parches que no fueron imaginadas por los desarrolladores. Una buena ingeniería del caos puede ayudar tanto a los equipos de DevSecOps como a los de DevOps, porque a veces los problemas de fiabilidad o resistencia pueden ser también debilidades de seguridad. Los mismos errores de codificación pueden a menudo bloquear el sistema o dar lugar a intrusiones.
¿Qué es la ingeniería del caos?
El término es un neologismo que pretende unificar diferentes técnicas que han tenido cierto éxito. Algunos utilizan palabras como "fuzzing" o "glitching" para describir la forma en la que se ajusta un sistema informático y, tal vez, se desequilibra y se bloquea. Inyectan comportamientos aleatorios que pueden estresar el software mientras observan atentamente si aparecen fallas de funcionamiento o bugs. A menudo se trata de modos de falla que podrían tardar años en revelarse en un uso regular.
John Gilmore, uno de los fundadores de la Electronic Freedom Foundation (EFF) y miembro del equipo de desarrollo de varios proyectos clave de código abierto, afirma que la codificación es un proceso de refinamiento continuo y que la ingeniería del caos es una forma de acelerar la búsqueda de todas las vías de ejecución posibles. "El verdadero valor del código de larga duración es que la mayoría de los errores han sido sacudidos por los primeros 10 millones de personas que lo han ejecutado, los primeros 20 compiladores que lo han compilado, los primeros cinco sistemas operativos en los que se ejecuta. Los que luego han sido probados mediante fuzzing y pruebas de penetración (por ejemplo, Google Project Zero) tienen muchas menos rutas de código sin explorar que cualquier pieza de código nueva", explica.
A Gilmore le gusta contar una anécdota de los años 70, cuando trabajaba para Data General, uno de los primeros fabricantes de minicomputadoras. Descubrió que, al accionar un interruptor de encendido en momentos aleatorios, el estado del sistema operativo quedaba desordenado. "En lugar de arreglar el problema, los ingenieros del sistema operativo afirmaron que accionar el interruptor no era una prueba válida". comenta Gilmore, antes de añadir: "Como resultado, Data General está muerta ahora".
La idea no es nueva en la fabricación de computadoras ni en otros campos de la ingeniería. Los fabricantes de autos, por ejemplo, prueban los nuevos modelos en los desiertos en verano y en las regiones del norte en invierno. Los arquitectos construyen estructuras de prueba y las sobrecargan vigilando que no fallen.
La informática, sin embargo, ha sido un campo relativamente matemático. Muchos investigadores de seguridad crean elaboradas pruebas lógicas que ofrecen todas las certezas de las buenas matemáticas. Sin embargo, la complejidad del software moderno es mucho mayor de lo que nuestras herramientas lógicas son capaces de modelar. La mayoría de los ámbitos de la seguridad informática están lejos de entenderse con la precisión que nos gusta y eso abre la puerta a los actos aleatorios.
El nombre evita deliberadamente la palabra "ciencia" y toda la tradición de construir, probar y finalmente entender el mundo a través de modelos cuidadosamente construidos y curados. Incluso utilizar la palabra "ingeniería" no es exactamente justo, porque la ingeniería suele ser tan rigurosa, planificada y metódica como lo que ocurre en los laboratorios de ciencias. La ingeniería del caos está más cerca de soltar un toro en una cacharrería o de soltar un cerdo engrasado en la cafetería del instituto.
Técnicas de ingeniería del caos
Las técnicas utilizadas por los ingenieros del caos son a menudo enloquecedoramente simples, pero sorprendentemente retorcidas. Implican doblar y distorsionar el hogar normalmente protector del software, subvirtiendo muchos de los servicios que los programadores daban por sentado. Una prueba sencilla, por ejemplo, simplemente borra la mitad de los paquetes de datos que llegan a través de la conexión a Internet. Otra puede engullir casi toda la memoria libre, de modo que el software se debate en busca de lugares donde almacenar los datos.
Las pruebas suelen realizarse a un nivel superior. Los equipos de DevSecOps pueden simplemente apagar algún subconjunto de los servidores para ver si los diversos paquetes de software que se ejecutan en la constelación son lo suficientemente resistentes para soportar la falla. Otros pueden simplemente añadir algo de latencia para ver si los retrasos desencadenan más retrasos que se conviertan en una bola de nieve y finalmente pongan el sistema de rodillas.
Casi todos los recursos, como la memoria RAM, el espacio en el disco duro o las conexiones a bases de datos, son susceptibles de experimentación. Algunas pruebas cortan el recurso por completo y otras solo restringen severamente el recurso para ver cómo se comporta el software cuando es exprimido.
Las fallas de seguridad se revelan a menudo de forma indirecta. Los problemas de desbordamiento del búfer, por ejemplo, son relativamente fáciles de exponer para las herramientas de caos, al inyectar demasiados bytes en un canal. Puede que las herramientas no penetren realmente en el software, pero revelan dónde alguien podría explotar este desbordamiento del búfer para inyectar código malicioso.
El fuzzing también es experto en revelar fallas en la lógica de análisis. A veces los programadores no prevén todas las formas diferentes en que se pueden configurar los parámetros, dejando una puerta trasera potencial. Bombardear el software con entradas aleatorias y semiestructuradas puede activar estos modos de falla antes de que los atacantes las encuentren.
El área también se ha vuelto más sofisticada. Algunos investigadores han ido más allá de la inyección estrictamente aleatoria, y han creado sofisticadas herramientas de fuzzing que utilizan el conocimiento del software para guiar el proceso mediante lo que suelen llamar análisis de "caja blanca". Una técnica llamada fuzzing gramatical comenzaría con una definición de la estructura de datos esperada, y luego utilizaría esta gramática para generar datos de prueba antes de subvertir la definición con la esperanza de identificar una falla de análisis. Las estrategias más profundas pueden tratar de identificar sistemáticamente todas las posibles vías de ejecución del código. Microsoft, por ejemplo, construyó una herramienta llamada SAGE que utilizó para señalar los posibles errores, observando las posibles ramas y creando entradas que las probaran todas.
Un reto para cualquier ingeniero del caos es detectar las fallas que podrían revelarse durante las cargas extremas. Mientras que los cierres totales suelen ser fáciles de detectar, puede ser más difícil ver cuando las fallas menos flagrantes conducen a sutiles fallas de seguridad. Muchos de los problemas que podrían descubrirse no comprometen ningún dato o acceso, pero aun así podrían revelar problemas que deberían abordarse y solucionarse.
Herramientas de ingeniería del caos
Este ámbito está pasando rápidamente de ser una salsa secreta desplegada por equipos inteligentes de DevSecOps, a formar parte habitual del ciclo de desarrollo. Las herramientas que comenzaron como proyectos paralelos y experimentación de skunkworks para los ingenieros, y ahora están creciendo hasta convertirse en partes confiables de muchas tuberías de CI/CD. Muchas de las herramientas siguen siendo proyectos de código abierto producidos por otros especialistas en DevSecOps y compartidos abiertamente. Otras están atrayendo la atención comercial. Unas pocas empresas dedicadas están suministrando herramientas propias a un mercado que se está expandiendo rápidamente.
Algunas herramientas también están diseñadas para operar más profundamente dentro de las pilas de software. Por ejemplo, ChaosMachine, una herramienta de investigación desarrollada en el KTH Royal Institute of Technology de Suecia, inyecta falsas excepciones en el código de bytes que se ejecuta en las máquinas virtuales Java. De este modo, se ponen a prueba los mecanismos de gestión de errores que ya deberían estar escritos en el código.
Las decenas de buenas herramientas de ingeniería del caos suelen centrarse en un lenguaje o plataforma concretos. Pythonfuzz, por ejemplo, llama repetidamente a funciones con datos aleatorios mientras observa si hay fugas de memoria, bloqueos u otras fallas. OSS-Fuzz de Google trabaja con múltiples lenguajes y proyectos, y la empresa los utiliza para probar las contribuciones de código abierto a su ecosistema, como las extensiones de Chrome.
Otras herramientas se centran en plataformas concretas. Netflix fue uno de los pioneros en este ámbito y creó una colección de herramientas para probar su infraestructura, que depende en gran medida de Amazon Web Services. Una de las primeras herramientas, Chaos Monkey, llega aleatoriamente a los clústeres de máquinas y termina algunas para ver si la falla total de una instancia conlleva algún problema. Netflix ha creado herramientas similares que denomina Simian Army. Incluye Latency Monkey, Chaos Gorilla y Chaos Kong, que pueden ralentizar las redes o incluso apagar conjuntos enteros de máquinas.
La mayoría de las otras plataformas tienen herramientas enfocadas a sembrar problemas. Chaos Platform de Proofdock, por ejemplo, está dirigida a Azure. El Chaos Monkey de Google Cloud es una versión del original reescrita para funcionar con la API de GCP.
Algunos proyectos están diseñados para compartir ideas y código entre muchas plataformas. Un proyecto de código abierto llamado Litmus se dirige a todas las principales nubes y máquinas que se ejecutan en las instalaciones. La plataforma Litmus admite "ChaosExperiments" que pueden dirigirse al software que se ejecuta en diferentes nubes. Su ChaosEngine despliega los experimentos y hace un seguimiento de los resultados.
Muchas herramientas están pensadas para traspasar los límites de los equipos y unir a los desarrolladores que prueban el código en las primeras etapas con los equipos de DevOps que gestionan los conductos CI/CD y vigilan el software que se ejecuta en producción. ChaosToolkit, por ejemplo, es un proyecto de código abierto diseñado para integrarse en cualquier canal de construcción y añadir retos más complejos y caóticos al nuevo código. También se basa en una gran colección de controladores y plugins para trabajar en muchas nubes diferentes e instalaciones locales.
El proveedor de herramientas de desarrollo de software Cavisson tiene un producto llamado "NetHavoc" que inyecta fallas llamadas "havocs" que pueden exponer las fallas del software, incluidas las vulnerabilidades de seguridad. Uno de los havocs corromperá los paquetes y distorsionará los resultados del DNS. Otros harán que la aplicación se quede sin memoria o espacio en el disco.
"Puede matar un servidor, puede terminar una instancia, puede teletransportar y distorsionar los mensajes en sus colas de mensajes", explica Mrigank Mishra, un director de producto de Cavisson. "Al final del día, todo se reduce al caso de uso que la organización está buscando".
Algunas herramientas profundizan porque los problemas se producen dentro del código cuando la entrada se aleja de las expectativas. Cryptofuzz, por ejemplo, trabaja directamente con algunas bibliotecas de criptografía responsables de cifrar las conexiones SSL. Busca problemas de seguridad como fallas, fugas de memoria, desbordamientos de búfer y variables no inicializadas.
La ingeniería del caos se expande
El área sigue creciendo. Muchas de las opciones de código abierto se están expandiendo y generando nuevas versiones llenas de mejoras. Algunas empresas están empezando a incorporar opciones de creación de caos en sus herramientas de desarrollo, conjuntos de pruebas y auditorías de seguridad. El área se está expandiendo porque no está definida de forma concreta; de hecho, es más bien una colección de técnicas para hacer lo que no se debe en el momento adecuado.
A primera vista, la ingeniería del caos es fácil. Basta con accionar los interruptores y ajustar los datos hasta que algo se rompa. Pero el verdadero arte consiste en buscar los lugares adecuados para juguetear y empezar a añadir ruido. Los ingenieros del caos no son tanto ingenieros como sujetos retorcidos y bromistas malintencionados con una racha de maldad. Normalmente se les ignoraría o se les mostraría la puerta en oficinas educadas, pero su capacidad para encontrar los puntos débiles, los talones de Aquiles, requiere adoptar actitudes antisociales que socavan y subvierten deliberadamente las suposiciones que los desarrolladores hicieron al escribir los primeros borradores. Si un poco de mal comportamiento puede revelar los defectos en una fase temprana del proceso, antes de que el código pase a producción, todos ganan.
Basado en el artículo de Peter Wayner (CSO) y editado por CIO Perú