El chiste sobre alguien en Nebraska

Alguna vez leí o escuché en alguna parte algo así como que, en el mundo digital, hay muchos problemas fundamentales de estructura y seguridad a los que no prestamos suficiente atención. Fue precisamente esta afirmación una de las que hizo ignición en los recovecos de mi memoria cuando vi por primera vez el chiste sobre alguien en Nebraska, en torno al cual gira este blog post:

Este chiste forma parte de xkcd, un webcómic creado por el caricaturista, ingeniero y escritor estadounidense Randall Munroe. Lo que el autor intenta mostrar aquí es la dependencia entre los elementos de un sistema o arquitectura digital global representado como una torre de bloques, como un Jenga, los cuales simbolizan los componentes de software. Así, a medida que ascendemos desde la base de la torre, los componentes de niveles superiores dependen de más y más componentes de niveles inferiores.

En realidad, no es que nuestros sistemas dependan de lo que hace un individuo específico por allá en Nebraska. A lo que este chiste —al mismo tiempo alarma— parece apuntar es a dar un ejemplo de una realidad general que venimos experimentando desde hace muchos años: diversos programas o componentes de software, algunos de ellos pequeños, mantenidos principalmente por motivos personales por una o pocas personas no famosas o desconocidas, en cualquier parte del mundo, soportan gran parte de nuestra infraestructura digital actual.

Si bien la caricatura de Randall representa la realidad mencionada, cuando revisamos su caption, podemos leer algo como lo siguiente: Algún día ImageMagick se romperá definitivamente y tendremos un largo período de lucha mientras intentamos recomponer la civilización a partir de los escombros. Este es un ejemplo concreto, quizá exagerado pero ilustrativo. ImageMagick es un software libre y de código abierto para procesar, crear, mostrar, editar y convertir imágenes rasterizadas, creado por allá en 1987 por John Cristy, el cual ha sido y es bastante usado en diversas aplicaciones, especialmente las destinadas a servicios web, y al que han contribuido a lo largo del tiempo comunidades de ingenieros y desarrolladores.

Aunque muchas otras librerías y APIs pueden llevar a cabo las tareas de ImageMagick, esta parece haberse convertido en el paquete por defecto. El problema con esta librería es que, por allá en 2016, se descubrieron cinco vulnerabilidades en ella (lo cual terminó llevando el nombre de "ImageTragick"), una de las cuales, al ser explotada, permitiría la ejecución remota de código (RCE, sigla en inglés para remote code execution). Este hallazgo prendió las alarmas entre ingenieros y desarrolladores, significando un alto riesgo potencial ya que si ImageMagick se estropeaba, multitud de programas que dependían de ella fallarían, al menos temporalmente, mostrando un desequilibrio y colapso en "la torre."

Hoy en día, muchos de nosotros sabemos, aunque seguramente muchos más lo ignoran, que tanto las más pequeñas como las más grandes compañías y organizaciones de todo el mundo emplean componentes de software de código abierto de terceros. Casi todo el software existente depende de este tipo de productos desarrollados y mantenidos por individuos y comunidades de desarrolladores. Pero, ¿por qué?

Una de las razones principales es el ya típico proverbio: "No reinventes la rueda." Es decir, si esa obra humana ya resultó suficientemente funcional, no pierdas el tiempo y dedícate a construir algo nuevo. En el universo del software, son muchas las personas que crean y comparten código públicamente y de forma gratuita, el cual cumple funciones específicas, algunas de ellas muy básicas. Así que, los demás no tienen que construir sus aplicaciones desde cero; no necesitan desarrollar todos los componentes de sus productos. Simplemente recurren a lo que ya ha sido creado y compartido por la comunidad, lo que les permite un desarrollo tecnológico más barato, sencillo y eficiente.

En otras palabras, aquí estamos hablando de reutilización y modularidad, principios que se vienen utilizando desde hace mucho tiempo pero que hoy son fundamentales en la ingeniería de software. Así, cuando un grupo de desarrolladores se propone crear una aplicación, lo que termina construyendo es una cadena o árbol de dependencias con múltiples componentes de software de código abierto previamente desarrollados por separado por otros ingenieros, algunos de ellos de unas pocas líneas de código que cumplen funciones específicas.

El problema, como ilustró Randall, es que muchos de estos proyectos de componentes de software de código abierto fundamentales para proyectos a gran escala suelen ser mantenidos por muy pocas personas. A diferencia de grandes empresas como Linux, por ejemplo, muchos otros proyectos no reciben suficiente atención. Quienes los conservan suelen ser expertos en ellos que a menudo trabajan demasiado y por poco o ningún dinero, principalmente como hobby, y sobre quienes recae toda la responsabilidad. Sin embargo, por motivos como el cansancio o la búsqueda de mejores oportunidades, algunos de estos proyectos pueden ser abandonados. Este inconveniente, unido a las vulnerabilidades de seguridad que puedan estar allí presentes, suele suponer un riesgo considerable para la integridad y seguridad de "todo el sistema".

Además del caso de ImageMagick, otros casos ilustrativos de este preocupante problema han sido, por ejemplo, los de Heartbleed y left-pad. Heartbleed es un bug descubierto en 2014 en OpenSSL, una librería que permite comunicaciones cifradas a través de la Internet, por ejemplo, para el comercio electrónico. Este, a diferencia de otros, es un componente de software relativamente grande ya que, por aquel entonces, contaba con alrededor de 500 mil líneas de código. Según se informa en un sencillo sitio web dedicado a esta vulnerabilidad, Heartbleed permitía robar la información protegida, en condiciones normales, por el cifrado SSL/TLS utilizado para asegurar la Internet.

Al parecer, este caso se calificó de irresponsabilidad por parte del equipo de OpenSSL, ya que conocían previamente un problema latente al que no prestaron suficiente atención. Tardaron cerca de dos años en detectar Heartbleed. Lo peor es que, aparentemente, el mantenimiento del componente afectado dependía solo de dos sujetos, ambos voluntarios y con exceso de trabajo. Se dice que, a pesar de lo ocurrido, las donaciones para este proyecto crecieron muy poco, pasando de unos 2.000 a 9.000 dólares al año. (Esta falta de financiación es algo frecuente en la historia del desarrollo de software de código abierto y algo que queremos destacar en una futura entrada del blog).

Para un caso similar más reciente, véase el de Log4j, una librería de código abierto de Apache en la que se descubrió una vulnerabilidad que permitía a atacantes remotos ejecutar código arbitrario en los sistemas expuestos.

En lo que respecta a left-pad, resulta que un joven llamado Azer Koçulu había estado desarrollando código para npm, un reconocido y ampliamente usado servicio de desarrollo web para encontrar e instalar paquetes de software de código abierto escritos en JavaScript. Cuando npm, en un embrollo que no merece la pena mencionar aquí, actuó aparentemente en contra de los principios básicos de la cultura del código abierto en relación con un paquete en el que Koçulu había estado trabajando, este optó por abandonarlo, concretamente borrarlo, allá por 2016, lo que provocó colapso en muchos proyectos y sitios web que dependían de él.

¿Que cada quien trabaje en todos los componentes de sus propios productos de software? Eso no es viable. Lo que parece más factible en estos momentos es mantener intacta la cultura del código abierto, pero contribuir en mayor medida a su mantenimiento y seguridad. Como ya han dicho muchos, ¿por qué las grandes empresas del sistema capitalista que dependen de estos proyectos públicos y gratuitos no contribuyen a su financiación o de alguna otra forma? ¿Dónde está el apoyo institucional y gubernamental? Todo esto sigue siendo insuficiente.

Aparte de ir creando conciencia sobre esta situación, intentando minimizar la ignorancia al respecto, y de buscar financiamiento para proyectos de los que todos dependemos, muchas compañías de diferentes sectores industriales también podemos contribuir a la seguridad de nuestra infraestructura digital. ¡Ojo! El hecho de que no tengamos que reinventar la rueda no significa que debamos pasarlo por alto. ¿No podemos acaso aprender sobre ella? Si bien no tenemos que desarrollar los componentes de software de terceros que utilizamos en nuestros productos, sí deberíamos conocerlos, revisarlos, actualizarlos, mejorarlos.

Aquí es donde entra en juego la tan mencionada lista de materiales de software (SBOM, sigla en inglés para software bill of materials). Utilízala como un inventario organizado de todos los componentes de terceros utilizados por tu aplicación. A partir de ahí, descarta aquellos paquetes que sean innecesarios, solicita una evaluación de vulnerabilidades de seguridad sobre el resto y, si es posible, contribuye con revisión, código o fondos, especialmente a aquellos componentes de software que desempeñen un papel crítico para mantener viva tu compañía.

Si deseas saber cómo Fluid Attacks puede ayudarte con el SBOM, el análisis de composición de software (SCA) y más pruebas de seguridad, no dudes en contactarnos.