Qué es Trojan Source y cómo se cuela en tu código fuente
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Siga leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional eran insertado en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como 'myspecialexe.doc' podría parecer bastante inocente si no fuera por el RLO (Anulación de derecha a izquierda) carácter presente que revela que el nombre real es 'myspecialcod.exe'.
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestro simulación (misiones públicas) de Trojan Source, y lee el Investigación de fuentes troyanas.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Siga leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional eran insertado en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como 'myspecialexe.doc' podría parecer bastante inocente si no fuera por el RLO (Anulación de derecha a izquierda) carácter presente que revela que el nombre real es 'myspecialcod.exe'.
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestro simulación (misiones públicas) de Trojan Source, y lee el Investigación de fuentes troyanas.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Siga leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional eran insertado en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como 'myspecialexe.doc' podría parecer bastante inocente si no fuera por el RLO (Anulación de derecha a izquierda) carácter presente que revela que el nombre real es 'myspecialcod.exe'.
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestro simulación (misiones públicas) de Trojan Source, y lee el Investigación de fuentes troyanas.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Siga leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional eran insertado en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como 'myspecialexe.doc' podría parecer bastante inocente si no fuera por el RLO (Anulación de derecha a izquierda) carácter presente que revela que el nombre real es 'myspecialcod.exe'.
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestro simulación (misiones públicas) de Trojan Source, y lee el Investigación de fuentes troyanas.
%20(1).avif)
.avif)
