Descubren una técnica con la que los códigos dañinos pueden ser invisibles al ojo humano: las ciberamenazas cobran una nueva dimensión

Un ojo humano no lo detectaría, pero un compilador sí.

Dos investigadores de la Universidad de Cambridge, Nicholas Boucher y Ross Anderson, han detallado en un nuevo estudio cómo los ciberdelincuentes pueden explotar algunos trucos para ocultar código dañino y que este sea imperceptible para las personas, y no así para los compiladores.

"¿Qué pasaría si fuera posible engañar a un compilador introduciendo instrucciones que no coincidan con lógica visible en un código fuente? Demostramos que no solo es posible en una amplia gama de compiladores modernos, sino que además es fácilmente explotable", confirman Boucher y Anderson en un artículo técnico que han publicado este mismo lunes.

El hallazgo, del que se ha hecho eco ThreatPost, ha sido bautizado como ataques Trojan Source, y para su revelación los dos investigadores han tenido que coordinar hasta a 19 compañías, que en estos momentos están publicando parches de seguridad para evitar que esta vulnerabilidad en sus compiladores de código pueda ser aprovechada.

Según Boucher y Anderson, este tipo de técnicas permitirían camuflar ciberataques de tal manera que suponen una "amenaza inmediata" tanto a programas informáticos propios como a los ofrecidos por proveedores, con lo que se podría ver comprometida toda la industria. 

Rayo de esperanza en la lucha contra el ransomware: por qué este golpe contra una mafia de ciberdelincuentes se asestó 'en secreto'

En su investigación demuestran con pruebas concretas de concepto cómo estos ataques surten efectos en lenguajes como C, C++, JavaScript, Java, Rust, Go o Python, aunque los propios investigadores reconocen en su artículo la sospecha de que esta técnica también funcionaría contra "la mayoría de lenguajes modernos".

Boucher y Anderson han conseguido etiquetar dos vulnerabilidades bajo el estándar CVE. Son la CVE-2021-42574 y la CVE-2021-42694. La primera está relacionada con el algoritmo BiDi del sistema Unicode, un estándar internacional que garantiza la presencia de caracteres en la red, mientras que la segunda está relacionada con los homoglifos, caracteres en apariencia similares a otros.

Por ejemplo, ᴏracle.com y oracle.com.

El estándar Unicode, además de garantizar la presencia de caracteres, también garantiza normas como el orden de lectura (de izquierda a derecha, de derecha a izquierda o de arriba a abajo) en función de qué tipo de alfabeto o ideogramas se están empleando en la escritura. Así, los especialistas han desgranado que conjugando esas dos vulnerabilidades, se garantizan ciberataques de código.

Ciberataques por código imposibles de determinar, y que recuerdan a un truco conocido como RLO que lo que hace es cambiar el orden el que se disponen los caracteres de una extensión (EXE o JPG) por ejemplo para que parezca que un archivo malicioso es inocuo.

La UE quiere reducir el poder de las grandes empresas tecnológicas: esto es todo lo que se sabe sobre sus nuevas y ambiciosas propuestas

Si un archivo termina en phylexe.doc, los atacantes pueden introducir un carácter especial e invisible que forma parte del estándar Unicode. Se trata del carácter que obliga a la máquina a leer una serie de caracteres de derecha a izquierda, como se requiere en idiomas como el árabe o el hebreo. 

De este modo, si se introduce ese carácter invisible justo antes de la 'd' de .doc', el resultado será este: phydoc.exe

De esta manera, un usuario que reciba un archivo adjunto al correo electrónico podrá pensar que ha recibido un documento de Microsoft Word. En realidad, el documento se trata de un ejecutable malicioso, y así lo interpretará el ordenador.

Este truco RLO ahora evoluciona y llega al mismísimo código. El problema ahora es cómo se puede abordar un problema que puede resultar invisible a ojo de los expertos en ciberseguridad. Aunque la respuesta no está clara y la comunidad ya está atajando este problema, Jon Gaines, experto en seguridad de aplicaciones en nVisium, considera lo siguiente a ThreatPost.

Gaines propone que los especialistas que quieran comprobar si un código incluye estos trucos, lo copien y lo peguen a un editor hexadecimal. 

Si el código se reescribe, el objetivo que trata de defenderse no sabrá si hay algún carácter Unicode oculto que esté tratando de forzar esta vulnerabilidad. Un editor hexadecimal sí podrá dar pistas sobre qué hace el código en realidad.