Estamos a una semana del descubrimiento de PHP2Shell, la vulnerabilidad de seguridad que puso en riesgo a gran parte de los sitios web y tuvo ocupados a los departamentos de seguridad informática de gobiernos y grandes corporaciones, y a desarrolladores web freelance por igual. Aunque voy a comentar cómo solucionarlo en Ubuntu en el siguiente artículo, el eje de este artículo es el desafío que plantea para el mundo del código abierto.

No es la primera vez que utilizo la analogía del cuento de los tres cerditos. Como los tres cerditos, gran parte de los usuarios de software libre y de código abierto nos sentíamos seguros porque «cualquiera podía auditar el código y, si se encontraba alguna vulnerabilidad, la comunidad enseguida publicaba una solución». Otros argumentaban que el sistema de permisos de Linux hacía casi imposible un ataque, salvo que el propio usuario cometiera la necedad de permitirlo.

Pues lamento decirles que nuestro lobo consiguió un misil balístico intercontinental y las paredes de la casa del tercer cerdito ya no sirven para nada.

Los problemas preexistentes

No es que la masificación de la Inteligencia Artificial haya causado el problema. Lo que hizo fue facilitar que los delincuentes informáticos aprovecharan varios problemas que ya existían y que muchos, inclusive este humilde bloguero, veníamos comentando hace tiempo. Esos problemas son:

Los programadores son seres humanos

Un programa informático está compuesto por cientos de miles de líneas de código. Líneas de código que hasta hace poco tiempo escribían personas desde cero (o utilizando bibliotecas escritas por otras personas). Los seres humanos nos sentimos mal, tenemos problemas, nos gusta quien está sentado en el cubículo de al lado, queremos sabotear a nuestro jefe y hay muchas otras razones para que aparezcan errores. Para eso existen las versiones de prueba. Pero no es posible detectar todos los problemas hasta que el programa se ejecuta en el mundo real.

Que algo se pueda hacer no significa que se haga

Es cierto que el código está ahí para que cualquiera pueda leerlo, pero digamos la verdad: revisar el código de otro no es la parte más divertida. La mayoría de los voluntarios de las comunidades del software libre y de código abierto prefiere hacer sus propios programas antes que arreglar los de los demás. La superabundancia de anotadores Markdown y reproductores de video que tenemos son una muestra.

Los desarrolladores no viven del aire

Aunque hoy por hoy la participación de desarrolladores rentados aumentó considerablemente, muchas bibliotecas clave son mantenidas por usuarios voluntarios que lo hacen en su tiempo libre. Un caso muy conocido del 2008 fue el que ocurrió con la biblioteca de funciones criptográficas OpenSSL en Debian.

Dos horas antes de comerse las 12 pasas de uva y brindar por el Año Nuevo, un desarrollador de Debian modificó el código de OpenSSL para corregir las advertencias que daba una herramienta de análisis de memoria. El problema es que, al hacerlo, redujo la capacidad de incorporar datos aleatorios al generador de números pseudoaleatorios. Esto hacía que las claves criptográficas generadas fueran más vulnerables a ataques de fuerza bruta.

Nadie se dio cuenta del error y se publicó en septiembre del 2006 tanto en Debian como en sus distribuciones derivadas. Recién en el 2008 se detectó el problema. Mientras tanto, estuvieron afectadas:

• Claves privadas y públicas de autenticación de servidores.
• Claves criptográficas de redes privadas virtuales.
• Certificados de autenticidad de sitios web.
• Claves utilizadas para firmar registros DNS.

La segunda guerra fría

Tanto la infraestructura física como el software son objetivos militares. Es por eso que las potencias utilizan técnicas de sabotaje que en el pasado estaban reservadas para los delincuentes informáticos. Los proyectos de código abierto, por los problemas que describimos más arriba, son una excelente puerta de entrada, como lo demostró el caso de XZ Utils.

XZ Utils es una biblioteca muy utilizada por las distribuciones Linux para comprimir y descomprimir archivos. Un desarrollador que se identificaba con el seudónimo Jia Tan (JiaT75) se ganó la confianza del mantenedor original del proyecto y consiguió cada vez más privilegios hasta que fue autorizado a modificar el código. Ahí empezó a introducir software malicioso. Al mismo tiempo, «usuarios» empezaron a presionar al mantenedor original para que incorporara más desarrolladores. Un delincuente informático, utilizando una clave privada específica, podía utilizar la puerta trasera de Jia Tan para ejecutar comandos en forma remota en los sistemas afectados.

El asunto se descubrió en marzo del 2024 y, aunque no hay pruebas, sí existe la sospecha de que hay un servicio de inteligencia detrás de Jia Tan.

Los aprendices de brujo

Una incorporación reciente a los problemas del código abierto es el vibe coding. Seguramente conoces la historia, popularizada por Walt Disney, del ayudante de un brujo que se pone a hacer magia sin tener idea de lo que está haciendo. Bueno, las redes sociales están convenciendo a bastante gente de que crear el próximo Photoshop o AutoCAD está al alcance de un prompt.

El problema está en que el modelo hace lo que uno le dice o lo que cree que es más probable que uno le esté diciendo. Esto no trae mayores consecuencias si te hiciste una app para jugar al tres en raya en tu móvil. Pero puede ser desastroso si hiciste una tienda online para tu negocio y olvidaste pedirle que tome precauciones para procesar y proteger los datos de las tarjetas de crédito de tus clientes. Imagínate un edificio construido por robots dirigidos por gente que no tiene la menor noción de arquitectura e ingeniería.

A una semana de PHP2Shell. Las lecciones que podemos aprender

Llegados a este punto, tengo que aclarar que estoy hablando de las vulnerabilidades del software libre y del código abierto porque escribo en un blog que la mayor parte del tiempo se dedica a hablar sobre eso. El software privativo también tiene sus problemas de seguridad, y bastante graves. Y es probable que tarden más en descubrirse.

Siendo justos, muchas de las vulnerabilidades descubiertas en los últimos años lo fueron por laboratorios independientes dedicados a investigarlas y, como se quejó Linus Torvalds, en algunos casos la posibilidad de que se dieran las condiciones para aprovecharlas era muy remota. Sin embargo, gracias a las herramientas de Inteligencia Artificial, las vulnerabilidades se descubren más rápido y el nivel de conocimiento necesario para aprovecharlas es menor.

Si algo podemos sacar de lo que pasó la semana pasada es que la Inteligencia Artificial no reduce la necesidad de aprender cosas, sino que la aumenta. De la misma manera que los delincuentes informáticos incrementan su poder de crear y aprovechar vulnerabilidades, los desarrolladores tienen que incrementar su capacidad de evitarlas y corregirlas, las empresas que se benefician del software libre tienen que devolver algo de lo que se llevan y los usuarios tenemos que entender nuestra responsabilidad en mantener nuestros sistemas actualizados.

Por cierto, si no se entendió el título y la foto del artículo, es un juego entre la expresión «Hablemos del elefante en la habitación», que se usa para expresar que hay un problema que no se puede ignorar, y la mascota del proyecto PHP.

Artículo original