Los expertos de la Universidad de Cambridge describieron una vulnerabilidad que dicen afecta a los compiladores más modernos. Un nuevo método de ataque utiliza una función legítima de las herramientas de desarrollo en el que el código fuente muestra una cosa, pero compila otra completamente distinta. Y esto sucede mediante la magia de los caracteres de control Unicode.
La mayoría de las veces, los caracteres de control no aparecen en la pantalla con el resto del código (aunque algunos editores los muestran), pero modifican el texto de alguna manera. En esta tabla se incluyen los códigos para el algoritmo bidireccional (bidi) Unicode, por ejemplo.
Como probablemente ya sabes, algunos idiomas (lenguajes) humanos están escritos de izquierda a derecha (por ejemplo, español), otros de derecha a izquierda (por ejemplo, arábigo). Cuando el código contiene solo un lenguaje, no hay problema, pero cuando es necesario (cuando, por ejemplo, una línea contiene palabras en español y arábigo) el código bidi especifica la dirección del texto.
En la investigación, los autores utilizaron códigos para, por ejemplo, mover el terminador de comentarios en el código Python de la parte central de una línea al final. Aplicaron un código RLI para cambiar solo algunos caracteres, dejando el resto igual.
A la derecha está la versión que los programadores ven al revisar el código fuente; a la izquierda se muestra cómo el código se ejecutará. La mayoría de los compiladores ignora los caracteres de control. Cualquiera que revise el código pensará que la quinta línea es un comentario inofensivo, aunque de hecho una declaración de retorno temprano oculta dentro causará que el programa se salte la operación que carga a cuenta los fondos de una cuenta bancaria. En este ejemplo, en otras palabras, el programa bancario simulado despachará el dinero, pero no lo deducirá del saldo de la cuenta.
¿Por qué es peligroso?
A primera vista, la vulnerabilidad se ve muy sencilla. ¿Quién insertaría caracteres invisibles con la esperanza de engañar a los auditores de código fuente? No obstante, el problema se consideró los suficientemente grave como para justificar un código identificador de vulnerabilidades (CVE-2021-42574). Antes de publicar el artículo, los autores notificaron a los desarrolladores de los compiladores más comunes para darles tiempo para preparar parches.
El informe describe las capacidades de ataque básicas. Las dos estrategias de ejecución son ocultar un comando dentro de los comentarios, y ocultar algo en una línea que, por ejemplo, aparezca en la pantalla. En teoría, es posible lograr el efecto opuesto: crear un código que parezca un comando, pero de hecho sea parte de un comentario y no se ejecutará. Incluso es posible que existan métodos más creativos para explotar esta debilidad.
Por ejemplo, alguien podría utilizar el truco para llevar a cabo un sofisticado ataque de cadena de suministro en donde un contratista suministre a una empresa un código que parezca correcto, pero no funcione según lo planeado. Entonces, después de que se libere el producto final, un externo podría utilizar la “funcionalidad alternativa” para atacar a los clientes.
¿Qué tan peligroso es en realidad?
Poco después de que se publicó el artículo, el programador Russ Cox criticó el ataque Trojan Source. No estaba impresionado, por decirlo de alguna manera. Sus argumentos son los siguientes:
- Para nada es un ataque nuevo.
- Muchos editores de código utilizan resaltado de sintaxis para mostrar el código “invisible”.
- Los parches para los compiladores no son necesarios; basta con revisar cuidadosamente el código para detectar errores accidentales o maliciosos.
De hecho, el problema con los caracteres de control Unicode surgieron, por ejemplo, desde el 2017. También, un problema similar con homoglifos (caracteres que parecen iguales pero tienen códigos distintos) no es nuevo, y también puede ayudar a meter código externo no detectado por los verificadores manuales.
Sin embargo, el análisis crítico de Cox no niega la existencia del problema, sino que condena el informe como demasiado dramático, una descripción acertada de, por ejemplo, el artículo apocalíptico del periodista Brian Krebs sobre Trojan Source.
El problema es real, pero, por fortuna, la solución es muy sencilla. Los parches que ya están disponibles o que están por salir bloquearán la compilación de código que contenga estos caracteres. (Como se indica, por ejemplo, en este aviso de seguridad de los desarrolladores del compilador Rust). Si utilizas tus propias herramientas de desarrollo de software, te recomendamos añadir una verificación similar para caracteres ocultos, los cuales, normalmente, no deberían aparecer en los códigos fuente.
El peligro de los ataques de cadena de suministro
Muchas empresas subcontratan las labores de desarrollo a contratistas, o utilizan módulos de código abierto ya hechos en sus proyectos. Esto siempre abre la puerta a ataques mediante la cadena de suministro. Los cibercriminales pueden comprometer a un contratista o al código incrustado en un proyecto de código abierto y meter código malicioso en la versión final del software. Las auditorias de código normalmente revelan estas puertas traseras, pero si no, los usuarios finales podrían tener software de fuentes confiables, y aun así perder datos.
Trojan Source es un ejemplo de un ataque mucho más elegante. En lugar de tratar de contrabandear megabytes de código malicioso en un producto final, los atacantes pueden utilizar este enfoque para introducir un implante difícil de detectar en una parte crítica del software y explotarlo durante años.
Cómo mantenerse seguro
Para protegerse contra los ataques del tipo Trojan Source:
- Actualiza todos los compiladores de lenguaje de programación que utilices (si se han liberado parches para estos), y
- Escribe tus propios scripts que detecten un rango limitado de caracteres control en el código fuente.
De forma más general, la lucha contra los ataques de cadena de suministro potenciales requiere tanto auditorias de código manuales como una gama de pruebas automatizadas. Nunca sobra ver tu código desde la perspectiva de los cibercriminales, para tratar de detectar ese sencillo error que pudiese quebrar todo el mecanismo de seguridad. Si no cuentas, de manera interna, con los recursos para este tipo de análisis, considera involucrar expertos externos.