Ciberdelincuentes están usando sofisticado método para ocultar vulnerabilidades en código fuente

Investigadores han encontrado una nueva forma de codificar código fuente potencialmente maligno. Este método está siendo utilizado para que los verificadores humanos observen una versión inofensiva y los compiladores vean la versión invisible y maligna.

El método ha sido denominado como ataque Trojan Source y aprovecha las sutilezas de los estándares de codificación de texto como Unicode. Este es utilizado para producir código fuente cuyos tokens están codificados lógicamente en un orden diferente al que se muestran. Esto genera vulnerabilidades que no se pueden percibir directamente por verificadores humanos de código.

La investigación fue revelada por los investigadores de la Universidad de Cambridge Nicholas Boucher y Ross Anderson en un artículo (PDF) que publicaron recientemente.

Boucher y Anderson dijeron que los ataques ponen en peligro todo el código fuente. Es decir, que representa “una amenaza inmediata tanto para el software de origen como para el compromiso de la cadena de suministro en toda la industria.

Para demostrar sus hallazgos, los investigadores han publicado pruebas de concepto (PoC) de ataques en diferentes lenguajes de programación. Por ejemplo, publicaron PoCs para C, C++, C#, JavaScript, Java, Rust, Go y Python, aunque los investigadores sospechan que el ataque también funciona contra “la mayoría de los demás lenguajes modernos.”

Divulgación coordinada para dos CVEs

Los investigadores han coordinado la divulgación con 19 organizaciones, muchas de las cuales ahora están lanzando actualizaciones. Estas actualizaciones abordan la vulnerabilidad en los compiladores de código, intérpretes, editores de código y repositorios. Algunas de esas organizaciones descartaron la notificación porque no coincidía con las vulnerabilidades con las que están más familiarizadas.

Hay dos CVEs involucradas, ambos emitidos por MITRE contra la especificación Unicode. Lo que los investigadores llamaron un ataque “potencialmente devastador” contra el algoritmo bidireccional Unicode (BiDi) hasta la versión 14.0 se ha identificado como CVE-2021-42574. BiDi admistra el orden en que se muestra el texto. Por ejemplo, de izquierda a derecha con el alfabeto latino, o de derecha a izquierda con caracteres árabes o hebreos.

Un ataque relacionado se basa en el uso de caracteres visualmente similares, conocidos como homoglyphs, identificado como CVE-2021-42694.

Con respecto al ataque BiDi, el documento explica que los sistemas informáticos necesitan una forma determinista de resolver la direccionalidad conflictiva cuando se trata de escrituras mixtas. Es decir, escrituras latinas mezcladas con árabe, que tienen órdenes de visualización conflictivas.

En Unicode, ese conflicto generalmente lo administra el algoritmo BiDi. Pero a veces, el algoritmo no es suficiente, en cuyo caso Unicode usa caracteres de control de anulación que insertan caracteres invisibles. Esto es necesario para permitir el cambio de orden de visualización de caracteres.

El antiguo hack de anulación de derecha a izquierda de Unicode

El hack de anulación de Unicode BiDi, conocido como la técnica de derecha a izquierda (RLO), es un antiguo ataque que sigue siendo desempolvado. Las anulaciones permiten que incluso los caracteres de un solo script se muestren en un orden diferente al de su codificación lógica, Un hecho que se ha aprovechado anteriormente para disfrazar el nombre real ejecutable malicioso y propagarlo por correo electrónico.

Más recientemente, en 2018, los atacantes utilizaron RLO para enviar malware de criptominería explotando una vulnerabilidad de día cero en la aplicación de mensajería de Telegram.

Lo que hace posible estos ataques es que la mayoría de los lenguajes de programación “bien diseñados” evitan los caracteres de control arbitrarios que se encuentran en el código fuente, ya que arruinan la lógica. Los caracteres de anulación aleatoria de BiDi normalmente darán como resultado un error de sintaxis del compilador o del intérprete. Estos errores se evitan metiéndolos en comentarios o cadenas, los cuales son ignorados por los compiladores e intérpretes.

Si bien tanto los comentarios como las cadenas tendrán una semántica específica de la sintaxis que indica su inicio y final, estos límites no son respetados por las anulaciones de Bidi. Por lo tanto, al colocar caracteres de anulación de Bidi exclusivamente dentro de los comentarios y las cadenas, podemos pasarlos de contrabando al código fuente de una manera que la mayoría de los compiladores aceptarán.

Nuevo ataque a la cadena de suministro

Los investigadores sugirieron que, si junta todo, un atacante obtiene la capacidad de crear un código fuente perfectamente válido y perfectamente malicioso. Ese códigopodría usarse para crear un nuevo ataque a la cadena de suministro que se puede llevar a cabo en el código fuente.

Según los investigadores “al inyectar caracteres de anulación Unicode Bidi en comentarios y cadenas, un adversario puede producir código fuente sintácticamente válido en la mayoría de los lenguajes modernos para los que el orden de visualización de los caracteres presenta una lógica que diverge de la lógica real”, “En efecto, anagramamos el programa A en el programa B”, afirmaron.

Un ataque de este tipo sería difícil de detectar para un verificador de código humano, dado lo apto que se ve el código fuente renderizado. Si el cambio en la lógica es lo suficientemente sutil como para pasar desapercibido en las pruebas posteriores, un adversario podría introducir vulnerabilidades específicas sin ser detectado.

Eso no es todo…

Pero espera, se pone peor. El documento advirtió: los caracteres de anulación Bidi persisten en las funciones de copiar y pegar en la mayoría de los navegadores, editores y sistemas operativos modernos. Esto significa que cualquier desarrollador que copie código de una fuente no confiable en una base de código protegida puede introducir inadvertidamente una vulnerabilidad invisible.

Ese tipo de copia peligrosa de código ha ocurrido antes en exploits de seguridad del mundo real. Un ejemplo fue en junio de 2020, cuando se descubrió que al menos 26 repositorios de código de fuente abierta estaban infectados con el malware Octopus Scanner. Generalmente, Octopus Scanner ataca apunta al entorno de desarrollo integrado Apache NetBeans de Java. Octopus Scanner se encontró anidado en los repositorios de código fuente de GitHub, solo esperando para tomar el control de las máquinas de desarrollo.

La gran cantidad de copia y pega código desde GitHub, Stack Overflow y otros repositorios hace que esta sea una posibilidad real como vector de ataque.

El investigador de seguridad John Bambenek, dijo que sería un “flujo de ataque bastante difícil” de mantener discretamente. No obstante, el tipo de atacante que puede envenenar una cadena de suministro son los que son lo suficientemente hábiles como para preocuparse. Las empresas de ingeniería de software deberían… actualizar sus compiladores lo antes posible. Esto porque los grupos que se entrometen en la cadena de suministro son los grupos exactos que tienen la sofisticación para administrar este flujo de ataque y el deseo de utilizar tales técnicas.

¿Cómo mitigar lo invisible?

Lo más preocupante es que este escenario demuestra lo imprudente que puede ser copiar y pegar código.

Siempre es mejor reescribirlo tú mismo y te sugerimos habilitar IDE´s o editores de texto para mostrar Unicode.

Alternativamente, si estás copiando y pegando código, debes abrir el código que copiaste y pegaste dentro de un editor hexadecimal para verificarlo. Esperamos que se publiquen rápidamente parches para la mayoría de los compiladores, pero mientras tanto, esta sería una solución eficaz a corto plazo.

Los ataques de homoglifo son aún peores

Los ataques de Trojan Source que se basan en BiDi RLO pueden empeorar aún más si un atacante utiliza homoglifos. Un ejemplo reciente es una campaña de julio de 2020 en la que los spammers intentaron engañar a los usuarios para que revelaran sus contraseñas de PayPal. En el ataque, los ciberdelincuentes cambiaron la “l” minúscula en el nombre de la marca por la “I” mayúscula visualmente similar.

Estos ataques de dominio se vuelven aún más severos con la introducción de Unicode. Recordemos que Unicode tiene un conjunto mucho mayor de caracteres visualmente similares, u homoglifos, que ASCII.

Por lo tanto, los ataques de homoglifos son los favoritos de los spammers como los estafadores de “Paypai”.  El uso de homoglifos en URLs es un peligro reconocido, uno en el que Unicode se ha centrado en informes de seguridad como este.

El hecho de que la vulnerabilidad de Trojan Source afecte a casi todos los lenguajes informáticos hace que sea una oportunidad única para una comparación de respuestas entre plataformas y proveedores de todo el sistema y ecológicamente válida. Dado que pueden lanzarse fácilmente ataques poderosos a la cadena de suministro utilizando estas técnicas, es esencial que las organizaciones que participan en una cadena de suministro de software implementen defensas.

Explotación de Unicode

La posibilidad de explotar Unicode no es sorprendente. Sin embargo, el hecho de que tantos compiladores analicen felizmente Unicode sin defensas, y cuán efectiva es la técnica para introducir código en bases de código, sí es sorprendente. El ataque es un hack realmente inteligente que muchos ni siquiera sabíamos que era posible. 

En el lado positivo, los investigadores realizaron un escaneo de vulnerabilidades generalizado que no arrojó evidencia de que la vulnerabilidad haya sido explotada hasta ahora. En el lado aterrador, no hay defensas contra Trojan Source. Por lo tanto, todos deberíamos orar para que los desarrolladores de compiladores y editores de código parcheen rápidamente.