RotaJakiro: nuevo malware de Linux disfrazado de proceso systemd

 

El laboratorio de investigación 360 Netlab anunció la identificación de un nuevo malware para Linux, con nombre en código RotaJakiro y que incluye una implementación de backdoor que permite controlar el sistema. Los atacantes podrían haber instalado software malicioso después de explotar vulnerabilidades no reparadas en el sistema o adivinar contraseñas débiles.

El backdoor se descubrió durante el análisis del tráfico sospechoso de uno de los procesos del sistema identificados durante el análisis de la estructura de la botnet utilizada para el ataque DDoS. Antes de esto, RotaJakiro pasó desapercibido durante tres años, en particular, los primeros intentos de verificar archivos con hash MD5 en el servicio VirusTotal que coinciden con el malware detectado datan de mayo de 2018.

Lo llamamos RotaJakiro basándonos en el hecho de que la familia usa cifrado rotativo y se comporta de manera diferente root/non-root accountscuando se ejecuta.

RotaJakiro presta bastante atención para ocultar sus rastros, utilizando múltiples algoritmos de encriptación, que incluyen: el uso del algoritmo AES para encriptar la información del recurso dentro de la muestra; Comunicación C2 mediante una combinación de AES, XOR, ROTATE encryptiony ZLIB compression.

Una de las características de RotaJakiro es el uso de diferentes técnicas de enmascaramiento cuando se ejecuta como usuario sin privilegios y root. Para ocultar su presencia, el malware utilizó los nombres de proceso systemd-daemon, session-dbus y gvfsd-helper, que, dado el desorden de las distribuciones modernas de Linux con todo tipo de procesos de servicio, a primera vista parecían legítimos y no despertaron sospechas.

RotaJakiro utiliza técnicas como AES dinámico, protocolos de comunicación encriptados de doble capa para contrarrestar el análisis de tráfico binario y de red.
RotaJakiro primero determina si el usuario es root o no root en tiempo de ejecución, con diferentes políticas de ejecución para diferentes cuentas, a continuación, descifra los recursos sensibles relevantes.

Cuando se ejecuta como root, los scripts systemd-agent.conf y sys-temd-agent.service se crearon para activar el malware y el ejecutable malicioso se ubicó dentro de las siguientes rutas: /bin/systemd/systemd -daemon y /usr/lib/systemd/systemd-daemon (funcionalidad duplicada en dos archivos).

Mientras que cuando se ejecutó como un usuario normal, se utilizó el archivo de ejecución automática $HOME/.config/au-tostart/gnomehelper.desktop y se realizaron cambios en .bashrc, y el archivo ejecutable se guardó como $HOME/.gvfsd/.profile/gvfsd-helper y $HOME/.dbus/sessions/session-dbus. Ambos archivos ejecutables se lanzaron al mismo tiempo, cada uno de los cuales monitoreaba la presencia del otro y lo restauraba en caso de apagado.

RotaJakiro admite un total de 12 funciones, tres de las cuales están relacionadas con la ejecución de complementos específicos. Desafortunadamente, no tenemos visibilidad de los complementos y, por lo tanto, no conocemos su verdadero propósito. Desde una perspectiva amplia de puerta trasera, las funciones se pueden agrupar en las siguientes cuatro categorías.

Informar la información del dispositivo
Robar información sensible
Gestión de archivos / complementos (consultar, descargar, eliminar)
Ejecución de un complemento específico

Para ocultar los resultados de sus actividades en el backdoor, se utilizaron varios algoritmos de cifrado, por ejemplo, se utilizó AES para cifrar sus recursos y para ocultar el canal de comunicación con el servidor de control, además del uso de AES, XOR y ROTATE en combinación con compresión usando ZLIB. Para recibir comandos de control, el malware accedió a 4 dominios a través del puerto de red 443 (el canal de comunicación usó su propio protocolo, no HTTPS y TLS).

Los dominios (cdn.mirror-codes.net, status.sublineover.net, blog.eduelects.com y news.thaprior.net) se registraron en 2015 y fueron alojados por el proveedor de alojamiento de Kiev Deltahost. Se integraron 12 funciones básicas en la puerta trasera, lo que permitió cargar y ejecutar complementos con funcionalidad avanzada, transferir datos del dispositivo, interceptar datos confidenciales y administrar archivos locales.

Desde la perspectiva de la ingeniería inversa, RotaJakiro y Torii comparten estilos similares: el uso de algoritmos de cifrado para ocultar recursos sensibles, la implementación de un estilo de persistencia bastante anticuado, tráfico de red estructurado, etc.

Finalmente si estás interesado en conocer más al respecto sobre la investigación realizada por 360 Netlab, puedes consultar los detalles dirigiéndote al siguiente enlace.

from Linux Adictos https://ift.tt/3nMbOWZ
via IFTTT

Se identifico una vulnerabilidad en Composer que compromete el repositorio PHP de Packagist

Hace pocos dias se dio a conocer la noticia de que se ha identificado una vulnerabilidad crítica en el administrador de dependencias de Composer (CVE-2021-29472) que permite ejecutar comandos arbitrarios en el sistema al procesar un paquete con un valor de URL especialmente formado que determina la dirección para descargar el código fuente.

El problema se manifiesta en los componentes GitDriver, SvnDriver y HgDriver utilizados con los sistemas de control de fuente Git, Subversion y Mercurial. La vulnerabilidad se corrigió en las versiones Composer 1.10.22 y 2.0.13.

En particular, el repositorio de paquetes Packagist predeterminado de Composer, que contiene 306.000 paquetes de desarrollador PHP y ofrece más de 1.400 millones de descargas mensuales, se ve particularmente afectado.

En el ecosistema PHP, Composer es la principal herramienta para administrar e instalar dependencias de software. Los equipos de desarrollo de todo el mundo lo utilizan para facilitar el proceso de actualización y garantizar que las aplicaciones funcionen sin esfuerzo en todos los entornos y versiones.

El experimento mostró que si había información sobre el problema, los atacantes podían tomar el control de la infraestructura de Packagist e interceptar las credenciales de los mantenedores o redirigir la descarga de paquetes a un servidor de terceros, organizando la entrega de variantes de paquetes con cambios maliciosos a sustituir una puerta trasera durante la instalación de dependencias.

El peligro para los usuarios finales está limitado por el hecho de que el contenido de composer.json suele estar definido por el usuario y los enlaces a la fuente se pasan al acceder a repositorios de terceros, que suelen ser fiables. El golpe principal recayó sobre el repositorio Packagist.org y el servicio Private Packagist, que llaman a Composer con la transferencia de datos recibidos de los usuarios. Los atacantes podrían ejecutar su código en servidores Packagist colocando un paquete especialmente diseñado.

El equipo de Packagist resolvió la vulnerabilidad dentro de las 12 horas posteriores a la notificación de la vulnerabilidad. Los investigadores notificaron en forma privada a los desarrolladores de Packagist el 22 de abril y el problema se solucionó el mismo día. Una actualización pública de Composer con una solución para la vulnerabilidad se publicó el 27 de abril y los detalles se revelaron el 28 de abril. Una auditoría de los registros en los servidores de Packagist no reveló ninguna actividad sospechosa asociada con la vulnerabilidad.

Los errores de inyección de argumentos son una clase de errores realmente interesante que a menudo se pasan por alto durante las revisiones de código y se pasan por alto por completo en las interacciones de caja negra

El problema se debe a un error en el código de validación de URL en el archivo raíz composer.json y en los enlaces de descarga de origen. El error ha estado presente en el código desde noviembre de 2011. Packagist usa capas especiales para administrar las descargas de código sin estar vinculado a un sistema de control de fuente específico, que se ejecuta llamando a «fromShellCommandline» con argumentos de línea de comando.

El meollo del problema es que el método ProcessExecutor permitió especificar cualquier parámetro de llamada adicional en la URL. Tal escape faltaba en los controladores GitDriver.php, SvnDriver.php y HgDriver.php. El ataque GitDriver.php se vio obstaculizado por el hecho de que el comando «git ls-remote» no admitía la especificación de argumentos adicionales después de la ruta.

Un ataque a HgDriver.php resultó posible pasando el parámetro «–config» a la utilidad «hq», que permite organizar la ejecución de cualquier comando manipulando la configuración «alias.identify».

Al enviar un paquete de prueba con una URL similar a Packagist, los investigadores se aseguraron de que después de ser publicado, su servidor recibiera una solicitud HTTP de uno de los servidores de Packagist en AWS que contenía una lista de los archivos en el directorio actual.

Cabe señalar que los mantenedores no identificaron ningún signo de explotación previa de esta vulnerabilidad en la instancia pública del packagist.

Finalmente si estás interesado en conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/3h2XLLs
via IFTTT

Spectre: una nueva variante amenaza y su solución pasa por afectar al rendimiento de tu CPU

Spectre logo

Si lo recuerdas, ya dijimos que Spectre iba a traer mucha cola, y que no sería algo que se solucionaría fácil en las CPUs afectadas, e incluso que no tendría solución a corto plazo hasta que no llegasen nuevos diseños de silicio que no cometan los mismos errores. Pues bien, ahora se ha detectado una nueva variante de la vulnerabilidad para la que no funcionan las soluciones aportadas hasta el momento.

Esta nueva variante afectan a todos los procesadores modernos con microcaché, tanto las de Intel como las de AMD. El problema ya no es ni siquiera ese, sino que cuando se parchee para solucionar estos problemas de seguridad, volverían a causar penalizaciones en el rendimiento bastante significativas. Si las de Spectre ya tuvieron un impacto considerable, los parches para estas reducirán bastante más el rendimiento. Y si no las parcheas, estarás expuesto a ellas…

Un equipo de investigadores, dirigido por Ashish Venkat, de la Universidad de Virginia, ha descubierto esta nueva vulnerabilidad que puede ser explotada cuando la CPU está obteniendo datos de la caché de micro-operaciones. Es decir, que afectaría a todos los procesadores AMD desde 2017 y de Intel desde 2011 que utilizan este tipo de caché especial.

Ambas compañías han sido informadas de esta nueva vulnerabilidad con antelación antes de realizar el anuncio público, para que tuvieran tiempo de reaccionar. Pero ninguna e las dos compañías ha lanzado aún ninguna actualización de su microcódigo que pueda solucionar este problema de seguridad. No obstante, no te debes asustar demasiado, ya que el riesgo no es muy alto, ya que las circunstancias para que se pueda realizar un ataque son algo remotas. Además, está la citada pérdida de rendimiento, que podría generar más problemas de los que solucionaría el parcheado…

Según el documento que se ha publicado por parte de estos investigadores, existen tres posibles vías para solucionar el problema:

  • Vaciar la caché de micro-ops en los cruces de dominio. Pero, para eso, las CPUs nuevas, necesitan vaciar también el TLB. Eso tiene consecuencias de rendimiento bastante severa, ya que el procesamiento no podría seguir hasta que el iTLB (TLB para instrucciones) no se rellene.
  • Se puede dividir la caché de micro-ops en función de los privilegios. Esta partición se traduciría en el aumento de dominios de protección, y una infrautilización de esta caché, por lo que también tendría impacto negativo en el rendimiento.
  • Implementar monitorización basada en el contador de rendimiento que detecta anomalías. Pero es una técnica propensa a errores y degrada el rendimiento si se hace un sondeo frecuente.

Por ahora, toca espera a ver qué solución aportan las compañías y cuándo se lanzan las actualizaciones del firmware…

from Linux Adictos https://ift.tt/3xLIhBC
via IFTTT