El descubrimiento de un malware con potencial dañino en sistemas GNU/Linux siempre es noticia, quizá por la imagen creada en torno a este sistema operativo como 'inmune a los virus'. Pero con Symbiote, cuya existencia acaba de ser dada a conocer ahora, estamos ante un caso extremo de sofisticación a la hora de eludir los métodos tradicionales de detección.
En teoría, su nombre procede de su capacidad para funcionar sin ejecutables, limitándose a 'inyectarse' en los procesos en ejecución y convertirlos en maliciosos; esto es posible porque la carga 'viral' reside en una biblioteca con extensión .SO, que los procesos cargan porque los atacantes, previamente, han hecho uso de la variable de entorno LD_PRELOAD.
Lo que me pregunto es cómo cambia el valor de la variable sin ejecutar ningún proceso para ello.
#2 De alguna forma se tuvo que instalar ese software. Un usuario estándar no puede instalar esas bibliotecas pero quizá sí leerlas si de algún modo residen en su raíz o en un temporal y un ejecutable las carga gracias al "ld_preload".
Quien no instale ni descargue nada extraño no debería por qué preocuparse, al menos es la impresión que tengo.
#5 Sí, pero para ello el usuario debería utilizar repositorios no oficiales, y eso que cada desarrollo es un mundo. Generalmente las herramientas GPL están bastante cuidadas pero es cierto que alguien podría meter la mano.
Yo utilizo Gentoo y no olvidaré nunca lo que sucedió hace 3 años, y aún con estas sigue siendo mi favorita: Github de Gentoo comprometido [ENG]
Quien utilice repositorios no oficiales o se instale un pquete de una fuente desconocida o no fiable está en riesgo, pero no sólo por esto sino por cualquier otra infección. Ahora bien, ¿podría comprometerse un sistema bien montado si un usuario estándar sin permisos pretende ejecutar algo? Tengo dudas, pero con los casos expansivos de ciberataque y aprovechándose de alguna vulnerabilidad (o descuido) no me extrañaría tampoco.
#14 No hace mucho, "alguien" accedió de alguna manera al repositorio de gentó y las consecuencias pudieron ser enormes; se paró rápido pues gentoó tiene un sistema en el que se compila todo, pero imagínate que en un sistema como debían, por ponerte un ejemplo, si accede.n y logran comprometer la seguridad, incluyendo código malicioso en cualquier paquete de uso común, al día siguiente, tienes un problema pues cualquiera que actualice su sistema, recibirá ese código sin enterarse de nada (un usuario normal).
Un saludo.
#15 para "acceder" tendrían que poder firmar el paquete con la clave privada de Debian y además poder subirlo a los servidores. Puede ser que ocurra, pero es una tarea muy complicada a añadir al desarrollo del propio virus.
#16 Después de ver,lo que lograron hacer en gentoo, estoy de acuerdo contigo en que no es algo para principiantes... pero si se ha conseguido por un lado, podría hacerse por el otro.
Si comprometes un repositorio con un tráfico considerable, puede infectar a muchos con una sola actualización; supongo también, que no debería durar más que el tiempo que tarden todos los demás repositorios, en "quejarse" de que los hashes no coinciden.
Ya podemos ir diciendo que Linux, ya no es lo que era....
Los archivos .so son bibliotecas dinámicas. Lo mismo que las .dll en Windows. Los ejecutables las cargan "sobre la marcha" cuando el código que necesitan ejecutar está ahí.
Supongo (porque la información tiende a 0) que todo pasa por sustituír un .so de uso común en el sistema por uno malicioso. No explican el vector de ataque.
el LD_PRELOAD unicamente indica de donde se debe cargar la biblioteca. Supongo que lo utilizarán para que los programas la carguen en lugar de la legítima....
#4 Podría ser una vulnerabilidad que tenga que ver con los PATH, como hace años pasaba en Windows con un Explorer.exe malicioso en carpetas distintas a las suya.
Si no se usa la ruta completa en todas y cada una de las llamadas/cargas, se puede dejar un archivo malicioso en otra ruta del PATH con más preferencia.
Comentarios
En teoría, su nombre procede de su capacidad para funcionar sin ejecutables, limitándose a 'inyectarse' en los procesos en ejecución y convertirlos en maliciosos; esto es posible porque la carga 'viral' reside en una biblioteca con extensión .SO, que los procesos cargan porque los atacantes, previamente, han hecho uso de la variable de entorno LD_PRELOAD.
Lo que me pregunto es cómo cambia el valor de la variable sin ejecutar ningún proceso para ello.
#2 De alguna forma se tuvo que instalar ese software. Un usuario estándar no puede instalar esas bibliotecas pero quizá sí leerlas si de algún modo residen en su raíz o en un temporal y un ejecutable las carga gracias al "ld_preload".
Quien no instale ni descargue nada extraño no debería por qué preocuparse, al menos es la impresión que tengo.
#3 En una actualización infectada: es la manera más lógica que se me ocurre (hablo desde la ignorancia y seguramente,este equivocado)
#5 Sí, pero para ello el usuario debería utilizar repositorios no oficiales, y eso que cada desarrollo es un mundo. Generalmente las herramientas GPL están bastante cuidadas pero es cierto que alguien podría meter la mano.
Yo utilizo Gentoo y no olvidaré nunca lo que sucedió hace 3 años, y aún con estas sigue siendo mi favorita: Github de Gentoo comprometido [ENG]
Github de Gentoo comprometido [ENG]
gentoo.orgQuien utilice repositorios no oficiales o se instale un pquete de una fuente desconocida o no fiable está en riesgo, pero no sólo por esto sino por cualquier otra infección. Ahora bien, ¿podría comprometerse un sistema bien montado si un usuario estándar sin permisos pretende ejecutar algo? Tengo dudas, pero con los casos expansivos de ciberataque y aprovechándose de alguna vulnerabilidad (o descuido) no me extrañaría tampoco.
#3 pero entonces el virus solo afectaría a ese usuario en concreto y no a todo el sistema.
#5 para eso tendrían que infiltrar a gente en el grupo que compila los paquetes supongo.
#14 No hace mucho, "alguien" accedió de alguna manera al repositorio de gentó y las consecuencias pudieron ser enormes; se paró rápido pues gentoó tiene un sistema en el que se compila todo, pero imagínate que en un sistema como debían, por ponerte un ejemplo, si accede.n y logran comprometer la seguridad, incluyendo código malicioso en cualquier paquete de uso común, al día siguiente, tienes un problema pues cualquiera que actualice su sistema, recibirá ese código sin enterarse de nada (un usuario normal).
Un saludo.
#15 para "acceder" tendrían que poder firmar el paquete con la clave privada de Debian y además poder subirlo a los servidores. Puede ser que ocurra, pero es una tarea muy complicada a añadir al desarrollo del propio virus.
#16 Después de ver,lo que lograron hacer en gentoo, estoy de acuerdo contigo en que no es algo para principiantes... pero si se ha conseguido por un lado, podría hacerse por el otro.
Si comprometes un repositorio con un tráfico considerable, puede infectar a muchos con una sola actualización; supongo también, que no debería durar más que el tiempo que tarden todos los demás repositorios, en "quejarse" de que los hashes no coinciden.
Ya podemos ir diciendo que Linux, ya no es lo que era....
Jo jo jo… el lumpen usando Windows.. jojo, expuestos a mil viruses… jojojjj…
…
…
.. O-oh nooooo!!!!!!!!!!
Los archivos .so son bibliotecas dinámicas. Lo mismo que las .dll en Windows. Los ejecutables las cargan "sobre la marcha" cuando el código que necesitan ejecutar está ahí.
Supongo (porque la información tiende a 0) que todo pasa por sustituír un .so de uso común en el sistema por uno malicioso. No explican el vector de ataque.
el LD_PRELOAD unicamente indica de donde se debe cargar la biblioteca. Supongo que lo utilizarán para que los programas la carguen en lugar de la legítima....
#4 Podría ser una vulnerabilidad que tenga que ver con los PATH, como hace años pasaba en Windows con un Explorer.exe malicioso en carpetas distintas a las suya.
Si no se usa la ruta completa en todas y cada una de las llamadas/cargas, se puede dejar un archivo malicioso en otra ruta del PATH con más preferencia.
Alguna otra fuente sobre el tema?
#7 https://www.intezer.com/blog/research/new-linux-threat-symbiote/
Yo estoy usando GNU/Linux Debian en modo paranoico y de momento no le ha entrado el COVID ni nada, que yo sepa.
#9 yo estoy usando GNU/Linux Manjaro en modo distendido y de momento no le ha entrado el COVID ni nada, que yo sepa.
#el plural de virus es virus
Yo uso linuz porque ejque no tiene birus, decían los caragranos.