Categoría: Estilo de vida

Se filtran 11.000 mensajes privados de WikiLeaks

Una activista ha filtrado miles de mensajes privados de la famosa organización conocida por publicar secretos de interés público.

La periodista Emma Best ha publicado más de 11.000 mensajes directos de un grupo de Twitter utilizado por WikiLeaks.

“En varios momentos del chat, hay ejemplos de homofobia, transfobia, sexismo, racismo, antisemitismo y otros contenidos y lenguajes objetables”, explica Best.

Los mensajes filtrados muestran el fuerte favoritismo republicano de la organización, ya que en algunos, escritos seguramente por el fundados de WikiLeaks Julian Assange, llamaban a la candidata Hillary Clinton “sádica” y “sociópata” entre otros. Además, especificaban que sería mucho mejor para el partido Republicano ganar.

También se ven mensajes relacionados con el ex presidente de los Estados Unidos, Barack Obama.

“Obama es solo un centralizador. Es malo porque representacionalmente no se ve ni actúa como lo que él representa. Hillary tiene una confusión de representación similar, pero conducirá activamente la máquina a un lugar oscuro”.

En respuesta a la publicación, WikiLeaks afirma que “Se han manipulado algunos registros pero son útiles de otras maneras”.

El fundador de WikiLeaks, Assange, permanece en la embajada ecuatoriana en Londres, pero los últimos informes indican que Ecuador quiere retirar su asilo político y entregarlo a las autoridades británicas.

Más información:
 
Post de Emma Best:

Incidente de seguridad en Reddit

Reddit, el popular sitio de agregación de noticias y marcadores sociales habría sido hackeado en junio de este año. Registros de eventos, copias de bases de datos y el código fuente (ahora privativo) de Reddit, podría haber sido extraído por el atacante.

Si tienes una cuenta en Reddit, es posible que hayas recibido un correo electrónico como este:

Según un responsable de Reddit, durante el intervalo de tiempo entre el 14 y el 18 de junio, varios servidores de la infraestructura de Reddit habrían sido atacados, con el resultado de la extracción de datos de usuarios, en concreto, direcciones de correo electrónico actuales y una copia de las credenciales de acceso que data del año 2007.

Respecto a las contraseñas, se trataría del grueso correspondiente al año 2007. Una copia de seguridad de los inicios del sitio. Además, y sorprende por la época, las credenciales no estaban guardadas en texto plano (hash + sal). Dado el transcurso de tiempo, es bastante improbable que las contraseñas que puedan extraerse de ahí sean útiles hoy día, aunque no es sorprendente ver cuentas cuyas contraseñas no han sido cambiadas en lustros.

Además, han sido extraídas listas de correos electrónicos de usuarios actuales, procedentes del sistemas de envío de resúmenes de noticias. Estas sí serían actuales, en concreto de todos los usuarios que tuvieran marcada dicha opción durante el día 3 y el 17 de junio. Repetimos: solo un listado de direcciones de correos electrónicos, nada de credenciales, en principio.

Eso respecto a los datos de usuario, pero llama la atención en el post que hace el responsable de Reddit, una anotación que puede pasar desapercibida:

As the attacker had read access to our storage systems, other data was accessed such as Reddit source code, internal logs, configuration files and other employee workspace files, but these two areas are the most significant categories of user data.

Es decir, que la filtración de datos de usuario, que no es precisamente un botín rebosante de maravedies, solo es una pizca de lo acontecido; aunque sí es lo que determina las posibles sanciones administrativas. El código fuente del Reddit actual, privativo, podría estar durmiendo en el disco duro de su asaltante.

Aunque el código fuente de Reddit siempre ha sido publicado con una licencia de fuente abierta, la compañía cerró el código fuente de la aplicación principal (aunque sigue publicando proyectos laterales y herramientas). Según el artículo publicado por el responsable de Reddit, el atacante habría tenido acceso a este código, recordemos, una versión muy distinta a la última versión libre publicada; ya que el sitio recibió un completo lavado de cara a inicios de este mismo año.

Respecto del ataca en si, llama la atención un aspecto importante:

we learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept. We point this out to encourage everyone here to move to token-based 2FA.

Aunque las cuentas de empleados que habrían sido hackeadas poseían doble factor de autenticación, este era un mensaje SMS y habría sido interceptado. Ojo, no estamos frente a un ataque oportunista contra servidores y mala configuración. Nos está desvelando una parte importante de como se desarrolló el plan del atacante: fue a por los empleados, y es más que probable que echara mano de ingeniería social o algo más complejo para hacerse con el código de los mensajes SMS enviados a los empleados.

En un comentario aparte, el mismo responsable, comenta que contrataron hace dos meses y medio a un jefe de seguridad. Lo que no deja de llamar la atención, que una compañía con un gran público en Internet, no lo tuviera ya desde hace años.

Como podemos ver, no solo se trata de construir una infraestructura segura. Un ataque centrado en las personas suele ser más fructífero que uno enfocado en la complejidad técnica. En este caso, ni tan siquiera un segundo factor de autenticación ha parado al atacante, quien de una forma u otra se hizo con los mensajes SMS. Es desde luego un ataque muy personalizado, del que sabemos poco pero podemos inferir mucho.

Más información:
 

Vulnerabilidad de 2007 permite escalar privilegios en Solaris

Investigadores de SpiderLabs, el equipo élite de seguridad de Trustwave, han descubierto que una vulnerabilidad de Solaris parcheada hace 9 años no fue totalmente mitigada y todavía se puede escalar privilegios

Un usuario no privilegiado puede ejecutar código en un contexto privilegiado, permitiendo el control total del sistema operativo. Este es el resumen de la vulnerabilidad descubierta en 2007 y publicada en 2009 en la conferencia CanSecWest. El mismo año de su publicación se parcheó, pero investigadores de Trustwave han encontrado resquicios en el parche por donde meterse, y poder seguir explotando la vulnerabilidad. Esta “nueva” vulnerabilidad tiene asignado el identificador CVE-2018-2892.

Si bien la explotación de vulnerabilidades, o exploiting, es un campo que en los últimos años se ha complicado bastante, la explotación de esta vulnerabilidad en concreto no es complicada de entender. Especialmente porque no parece haber protecciones genéricas contra exploiting por parte del sistema operativo (o al menos en la entrada del blog de SpiderLabs no se mencionan). La vulnerabilidad se encuentra en un manejador de ioctl, esto es, una parte de un controlador (driver) que recibe peticiones de aplicaciones posiblemente no privilegiadas. Como en la mayoría de los sistemas operativos para PC, los controladores corren en contexto privilegiado. Lo que tenemos entonces es que recibimos una petición desde el lado no privilegiado, y la manejamos en el lado privilegiado. Si el manejo es robusto, no hay problema. Si el manejo es débil… Vulnerabilidad.

En la vulnerabilidad original (antes de parchear), el error es flagrante. En el manejador de ioctl se usan directamente dos argumentos que vienen del lado no privilegiado: uno que se usa para indicar dónde escribir en memoria privilegiada, y otro para indicar el tamaño a escribir. Esos dos argumentos son pasados a una función que se encarga de copiar memoria del lado no privilegiado al privilegiado, y junto con un tercer argumento que especifica el contenido a copiar, tenemos la forma de escribir lo que queramos (tercer argumento y segundo especificando el tamaño) donde queramos (primer argumento).

En la llamada a ‘copyin’, ‘uap->addr’ sería nuestro tercer argumento, y los otros dos, el primero y el segundo respectivamente

Se entiende que el tercer argumento (lo que se copia) aun siendo controlable por el usuario no permite explotación por sí solo si se copia donde se debe, pero si podemos controlar dónde se copia, podemos hacer que sobreescriba código crítico del lado privilegiado y nos permite ejecutar código arbitrario en ese contexto. El parche se antoja sencillo entonces: vale con controlar que el primer argumento no permita escribir fuera del tiesto, y que el segundo argumento no permita escribir más de la cuenta. Y en eso consistió el parche de 2009.

Por desgracia, la comprobación del segundo parámetro es incompleta. Por definición, el segundo parámetro es de tipo ‘int’, esto es, un valor numérico que puede ser positivo o negativo. Y la comprobación introducida por el parche de 2009 sólo comprueba que no sea mayor de un cierto número positivo, no comprobando si es negativo. ¿Qué problema plantea esto? Que el segundo argumento indica en qué dirección escribir, pero de forma relativa. Existe una dirección fija en memoria, y el segundo argumento indica a qué distancia de esta dirección fija escribimos. Como se controla que el valor positivo no exceda cierto límite, no es posible salirse del tiesto por arriba, pero como el valor negativo no se controla, pues te puedes salir del tiesto por arriba…

Cabe preguntarse por qué una vulnerabilidad tan obvia termina en un punto tan delicado del sistema. Una posible respuesta se encuentra en el código fuente, donde se ve que el tipo de petición que nos lleva al código vulnerable es un tipo de petición usada con propósitos de prueba. Y es que el código escrito con este propósito es usado por los mismos desarrolladores para hacer pruebas de forma rápida y no debe ser usado por el usuario final, con lo que se programa de forma rápida y sin tener la seguridad en mente.

Finalmente, indicamos que Oracle ha publicado un parche para solucionar este problema (esperemos que definitivamente). Un parche sacado apenas hace una semana, en el que se corrige esta vulnerabilidad para las últimas versiones de Solaris 10 y 11. Para su explotación es necesario que esté configurado el módulo Sun StorageTek Availability Suite, ya que el manejador ioctl pertenece a éste.

Carlos Ledesma
@Ravenons

Más información:
 
CVE-2018-2892 – Kernel Level Privilege Escalation in Oracle Solaris
https://www.trustwave.com/Resources/SpiderLabs-Blog/CVE-2018-2892—Kernel-Level-Privilege-Escalation-in-Oracle-Solaris/

Oracle Critical Patch Update Advisory – July 2018
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.htmlInvestigadores de SpiderLabs, el equipo élite de seguridad de Trustwave, han descubierto que una vulnerabilidad de Solaris parcheada hace 9 años no fue totalmente mitigada y todavía se puede escalar privilegios

Un usuario no privilegiado puede ejecutar código en un contexto privilegiado, permitiendo el control total del sistema operativo. Este es el resumen de la vulnerabilidad descubierta en 2007 y publicada en 2009 en la conferencia CanSecWest. El mismo año de su publicación se parcheó, pero investigadores de Trustwave han encontrado resquicios en el parche por donde meterse, y poder seguir explotando la vulnerabilidad. Esta “nueva” vulnerabilidad tiene asignado el identificador CVE-2018-2892.

Si bien la explotación de vulnerabilidades, o exploiting, es un campo que en los últimos años se ha complicado bastante, la explotación de esta vulnerabilidad en concreto no es complicada de entender. Especialmente porque no parece haber protecciones genéricas contra exploiting por parte del sistema operativo (o al menos en la entrada del blog de SpiderLabs no se mencionan). La vulnerabilidad se encuentra en un manejador de ioctl, esto es, una parte de un controlador (driver) que recibe peticiones de aplicaciones posiblemente no privilegiadas. Como en la mayoría de los sistemas operativos para PC, los controladores corren en contexto privilegiado. Lo que tenemos entonces es que recibimos una petición desde el lado no privilegiado, y la manejamos en el lado privilegiado. Si el manejo es robusto, no hay problema. Si el manejo es débil… Vulnerabilidad.

En la vulnerabilidad original (antes de parchear), el error es flagrante. En el manejador de ioctl se usan directamente dos argumentos que vienen del lado no privilegiado: uno que se usa para indicar dónde escribir en memoria privilegiada, y otro para indicar el tamaño a escribir. Esos dos argumentos son pasados a una función que se encarga de copiar memoria del lado no privilegiado al privilegiado, y junto con un tercer argumento que especifica el contenido a copiar, tenemos la forma de escribir lo que queramos (tercer argumento y segundo especificando el tamaño) donde queramos (primer argumento).

En la llamada a ‘copyin’, ‘uap->addr’ sería nuestro tercer argumento, y los otros dos, el primero y el segundo respectivamente

Se entiende que el tercer argumento (lo que se copia) aun siendo controlable por el usuario no permite explotación por sí solo si se copia donde se debe, pero si podemos controlar dónde se copia, podemos hacer que sobreescriba código crítico del lado privilegiado y nos permite ejecutar código arbitrario en ese contexto. El parche se antoja sencillo entonces: vale con controlar que el primer argumento no permita escribir fuera del tiesto, y que el segundo argumento no permita escribir más de la cuenta. Y en eso consistió el parche de 2009.

Por desgracia, la comprobación del segundo parámetro es incompleta. Por definición, el segundo parámetro es de tipo ‘int’, esto es, un valor numérico que puede ser positivo o negativo. Y la comprobación introducida por el parche de 2009 sólo comprueba que no sea mayor de un cierto número positivo, no comprobando si es negativo. ¿Qué problema plantea esto? Que el segundo argumento indica en qué dirección escribir, pero de forma relativa. Existe una dirección fija en memoria, y el segundo argumento indica a qué distancia de esta dirección fija escribimos. Como se controla que el valor positivo no exceda cierto límite, no es posible salirse del tiesto por arriba, pero como el valor negativo no se controla, pues te puedes salir del tiesto por arriba…

Cabe preguntarse por qué una vulnerabilidad tan obvia termina en un punto tan delicado del sistema. Una posible respuesta se encuentra en el código fuente, donde se ve que el tipo de petición que nos lleva al código vulnerable es un tipo de petición usada con propósitos de prueba. Y es que el código escrito con este propósito es usado por los mismos desarrolladores para hacer pruebas de forma rápida y no debe ser usado por el usuario final, con lo que se programa de forma rápida y sin tener la seguridad en mente.

Finalmente, indicamos que Oracle ha publicado un parche para solucionar este problema (esperemos que definitivamente). Un parche sacado apenas hace una semana, en el que se corrige esta vulnerabilidad para las últimas versiones de Solaris 10 y 11. Para su explotación es necesario que esté configurado el módulo Sun StorageTek Availability Suite, ya que el manejador ioctl pertenece a éste.


Más información:
 

Se propaga una versión maliciosa del software Ammy Admin

Durante los días 13 y 14 de julio la aplicación descargada desde la web oficial del software de control de escritorio remoto Ammy Admin contenía software malicioso.

Se ha verificado que los días señalados, el software gratuito incluía un malware bancario y troyano detectado por ESET como Win32/Kasidet.

Este malware tenía dos objetivos principales:

1. Robar archivos que puedan contener credenciales y/o monederos de criptomonedas. Para ello el software buscaba nombres de archivos que coincidieran con:

  • pass.txt
  • passwords.txt
  • wallet.dat
  • bitcoin

2. Reportar procesos que incluyan alguna de las siguientes características:

  • armoryqt
  • bitcoin
  • exodus
  • electrum
  • jaxx
  • keepass
  • kitty
  • mstsc
  • multibit
  • putty
  • radmin
  • vsphere
  • winscp
  • xshell

La URL del C&C está detectada en VT por 8/67 antivirus:
https://www.virustotal.com/#/url/b2d4d7676b8fd81b257a96adf2a025402148bfae539cb347116bea54bb81fa09/detection

Aunque si verificamos directamente los hashes de las muestras, podemos ver que tienen un ratio de detección mayor al del C&C.

Instaladores:
Servicio:
No es la primera noticia de las que hemos hablado en Una al día sobre alteración de un software legítimo para añadirle contenido malicioso, de hecho, las noticias de los dos últimos días van encaminadas en este sentido, estas noticias son:
Malware hallado en el repositorio AUR de Arch Linux
Roban las claves privadas de un popular monedero de Ethereum a través de la extensión Hola VPN.

Desde Hispasec recomendamos a los usuarios mantener sus antivirus activos y actualizados a la hora de descargar cualquier software. Y, en caso de duda, verificar por algun servicio adicional para asegurarnos que no incluya software malicioso en el código.

Más información:
 
Web oficial de Ammy Admin:

OSX.Dummy: el malware “tonto” para macOS que pone el objetivo en los usuarios de criptodivisas

El malware ha sido descubierto por el investigador Remco Verhoef (@remco_verhoef) y analizado en profundidad por Patrick Wardle (@patrickwardle). Utiliza métodos bastante simples de infección y persistencia y pone el blanco sobre los usuarios de criptodivisas.

 

Hoy hemos analizado una nueva muestra de malware para Mac. Lo he llamadoOSX.Dummy porque:

  • El método de infección es estúpido.
  • El enorme tamaño del binario es estúpido.
  • El mecanismo de persistencia es patético (y por tanto también estúpido).
  • Las capacidades son más bien limitadas (y por tanto, más bien estúpidas).
  • Es trivial detectarlo en cada paso (es así de estúpido).
  • … Y, finalmente, porque guarda la contraseña del usuario en el fichero‘dumpdummy’.

Y así ha sido el bautizo de OSX.Dummy. El malware fue señalado en primera instancia por Remco Verhoef en el artículo “Crypto community target of MacOS malware” para el Internet Storm Center del instituto SANS. En el articulo, Verhoef comenta que durante los últimos días había notado un aumento de mensajes en grupos de Slack y Discord haciéndose pasar por miembros importantes de los mismos. Estos mensajes pedían ejecutar este script:

De forma que la victima se infectara a si misma, en un intento bastante ingenuo (“El método de infección es estúpido”). Este script descarga un fichero MachO de 34 MB (“El enorme tamaño del binario es estúpido”). A la hora de su articulo, no era detectado por ningún motor anti-virus. A día de hoy, ya son 4 motores los que lo señalan como malware.
El análisis de la muestra realizado por Verhoef mostraba referencias a Pkg, un empaquetador que une aplicaciones JavaScript y el servidor node.js en un único ejecutable. El análisis del comportamiento de la muestra arroja la generación de varios ficheros con el objetivo de asegurar la persistencia del malware (“El mecanismo de persistencia es patético”).

En cada inicio se ejecuta el fichero ‘/var/root/script’, cuyo el objetivo es conectarse al punto de control para establecer una shell inversa para poder ejecutar comandos como superusuario de forma remota.

En este punto es donde Patrick Wardle toma el relevo y, además de bautizarlo como hemos visto al principio, encuentra algunos datos interesantes adicionales:

  • El fichero ‘/tmp/dumpdummy’ (ya mencionado por Verhoef) sirve para almacenar la contraseña de sudo.
  • El binario no está firmado. Estos binarios serían bloqueados por GateKeeper en una situación normal. Sin embargo, al ejecutarse a través de linea de comandos, GateKeeper no lo analiza.
  • El tamaño del binario es debido a que varias librerías, como OpenSSL y V8 de Google, se encuentran compiladas estáticamente.
A pesar de ambos análisis, aun está por descubrir por qué el atacante tenía como objetivo la comunidad de usuarios de criptodivisas, ya que el malware no tiene ninguna funcionalidad especifica para las mismas.
Crypto community target of MacOS malware:
https://isc.sans.edu/diary/23816

OSX.Dummy: new mac malware targets the cryptocurrency community
https://objective-see.com/blog/blog_0x32.html

Casi 400 modelos de cámaras Axis expuestos a ataques remotos

Se han descubierto 7 vulnerabilidades que afectan a 390 modelos diferentes de cámaras de la marca, que permitirían acceder sin credenciales, escalar privilegios y ejecutar comandos arbitrarios

Las vulnerabilidades han sido descubiertas por la empresa de seguridad VDOO, en un proyecto interno enfocado a la seguridad de cámaras IP. Éstas son:

  • CVE-2018-10658: bloqueo del proceso ‘/bin/ssid’.
  • CVE-2018-10659: bloqueo del proceso ‘/bin/ssid’.
  • CVE-2018-10660: inyección de comandos shell.
  • CVE-2018-10661: salto del proceso de autenticación
  • CVE-2018-10662: elevación de permisos usando funcionalidad ‘.srv’ de dbus.
  • CVE-2018-10663: lectura fuera del buffer en proceso ‘/bin/ssid’.
  • CVE-2018-10664: bloqueo del proceso httpd.
De estas vulnerabilidades, las catalogadas con los identificadores CVE-2018-10661, CVE-2018-10662 y CVE-2018-10660 permiten en su conjunto tomar el control total de las cámaras por el atacante sin la necesidad de autenticación. La empresa de seguridad ha puesto algunos ejemplos de las acciones que podrían realizarse:
  • Acceder a la transmisión de vídeo.
  • Bloquear la transmisión de vídeo.
  • Tomar el control de la cámara para activarla/desactivarla o rotarla.
  • Añadir la cámara a una botnet.
  • Alterar o cambiar el firmware de la cámara.
  • Utilizar la cámara para infiltrarse en la red.
  • Inutilizar la cámara.
  • Emplear la cámara para otros ataques, como DDoS o minería de bitcoin.
Las otras vulnerabilidades descritas, con los identificadores CVE-2018-10658, CVE-2018-10659 y CVE-2018-10664, permitirían afectar al funcionamiento de la cámara, sin que se requiera autenticación para ninguna de ellas. Finalmente, la vulnerabilidad CVE-2018-10663 permite la revelación de información sin autenticación.
La empresa que ha descubierto las vulnerabilidades asegura que no hay pruebas de que haya habido explotación, recomendando a todos los usuarios afectados actualizar de inmediato. Axis ha liberado un listado de los modelos afectados.
Las vulnerabilidades en dispositivos IoT se encuentran a la orden del día, evidenciando la necesidad de preocuparse por la seguridad de estos dispositivos y mantenerlos actualizados. No sólo es importante por la posible pérdida de privacidad (como en este caso acceder al streaming de vídeo) sino también porque permiten acceder al resto de la red para vulnerar otros dispositivos.

FP Lazy State Restore: nueva vulnerabilidad en los procesadores Intel Core

Intel ha publicado una nueva vulnerabilidad que afecta a sus procesadores la cual aprovecha debilidades en la ejecución especulativa, al igual que Meltdown y Spectre.

Extraída de betanews.com

Era de esperar: una vez que los investigadores han puesto el ojo sobre los microprocesadores, era solo cuestión de tiempo que fueran descubriéndosemás vulnerabilidades y con mayor frecuencia. Desde el descubrimiento de Spectre y Meltdown, hemos asistido a un desfile de fallos de seguridad relacionados con la ejecución especulativaHoy tratamos FP Lazy State Restore.

Aunque no se han dado muchos detalles técnicos de la vulnerabilidad, a la que se ha asignado el identificador CVE-2018-3665, se ha publicado que el error está relacionado con la forma de guardar y restaurar los registros de estado de la unidad de coma flotante (Floating Point Unit, FPU, y de ahí el nombre de la vulnerabilidad: ‘Floating Point Lazy State Restore’).

¿Y por qué el “lazy“? La FPU guarda el estado de las operaciones que está realizando. Cuando se da un cambio de contexto en el procesador, este puede indicar a la FPU que este estado sea guardado automáticamente o de forma “vaga”. En este último caso, el estado no se guarda hasta que el nuevo proceso ejecute una operación de punto flotante que requiera salvar datos en los registros de la unidad. Es decir, en esta modalidad la FPU no realiza salvado ni recuperación de estados a no ser que realmente se necesite, ahorrando varios ciclos de computación.

Al igual que las dos vulnerabilidades antes mencionadas, el error está efectivamente relacionado con la ejecución especulativa, pero en este caso es el software el que puede elegir entre el guardado inmediato o “vago” de contexto, por lo que los fabricantes de sistemas operativos podrán corregir esta vulnerabilidad a través de una actualización de software.

Aunque no existen muchos detalles más allá de estos, parece ser similar a la variante 3A de Spectre (Rogue System Register Read). Este error podría permitir la obtención de información sensible almacenada por distintas aplicaciones, incluyendo claves de cifrado, lo que la convierte en una vulnerabilidad con un fuerte impacto.

Actualmente la vulnerabilidad no afecta a los procesadores AMD, tampoco a las últimas versiones de OpenBSD, DragonflyBSD, Linux con kernel 4.9 o las versiones de Windows más modernas, aunque Microsoft no ha dado muchos detalles al respecto más allá de confirmar un parche en julio.

También se sabe que Intel está trabajando con el equipo de Red Hat para dar solución a este problema con la máxima celeridad.

New ‘Lazy FP State Restore’ Vulnerability Found in All Modern Intel CPUs:

https://thehackernews.com/2018/06/intel-processor-vulnerability.html

 

RedHat. Lazy FPU Save/Restore

MysteryBot, el nuevo troyano “todo en uno” para Android

Por si fuera poco el nivel de malware existente en los dispositivos Android en estos tiempos, ahora se le suma la propia evolución de LokiBot, que supone una nueva familia de malware denominada como MysteryBot.

El malware ha sido detectado por investigadores de ThreatFabric durante uno de sus análisis rutinarios de la familia Lokibot, de la cual hereda ciertos comportamientos. Concretamente, ha sido detectado gracias a que MysteryBot tiene el mismo servidor de control que Lokibot.

Podemos corroborar esta información utilizando la plataforma Koodous, en la cual en este momento ya existen muestras clasificadas como MysteryBot:

Las novedades que trae este malware es la combinación de varias vías de ataque que pasamos a desgranar a continuación:

Registro de pulsaciones: El malware guarda las pulsaciones que realiza el usuario en la pantalla, aunque además tiene algunas novedades: también detecta si el teléfono está en horizontal o vertical, datos que utiliza para calcular qué se ha pulsado en el teléfono teniendo en cuenta las dimensiones del dispositivo. Tiene módulos de las familias CryEye yAnubis y, según el código analizado por ThreatFabric, parece estar aún en desarrollo.

RansomwareEste comportamiento resulta ya familiar en el malware móvil, y trata en cifrar el dispositivo para posteriormente pedir un rescate monetario a cambio de su descifrado. En este caso la muestra no cifra datos, sino que los comprime en un archivo zip con contraseña, la cual actualmente no tiene mucha robustez (solo 8 caracteres).

Ataques de superposición: La característica más novedosa de este malware, no tanto por lo que hace si no por su ejecución. Este comportamiento permitía qué, cuando un usuario abre una aplicación legítima, el malware aprovechará para mostrar una interfaz superpuesta, engañando al usuario de forma poco sospechosa. Sin embargo, tras la introducción de Android 7 y 8 ya no era posible realizar ataques de superposición, lo que ha llevado a los creadores de malware a buscar nuevas técnicas. Esta familia abusa del permiso ‘PACKAGE_USAGE_STATS’, que junto con el uso de la claseAccessibilityService y un cálculo correcto de tiempos le permite realizar ataques de superposición con éxito.

Sin duda el malware es novedoso y aprovecha las últimas técnicas de ataque en Android. Actualmente se desconoce si los atacantes tienen alguna campaña de promoción, pero lo que sí podemos observar en la captura facilitada anteriormente es que la intención eshacerse pasar por la aplicación Adobe Flash Player.

Desde Hispasec recomendamos siempre instalar en Android aplicaciones desde repositorios oficiales, pero además que se realicen unas comprobaciones mínimas como verificar al desarrollador de la aplicación o que sea enlazada desde la página oficial de la compañía.

Más información:

MysteryBot; a new Android banking Trojan ready for Android 7 and 8:

BackSwap, el banker que simula ser un usuario

A pesar de que los bankers están perdiendo popularidad, en favor de los malware de minado de criptomonedas, los investigadores de ESET han descubierto una nueva familia de malware bancario que simula las pulsaciones de un usuario para evitar ser detectado.

El malware simplifica el proceso de inyección monitorizando el bucle de mensajes del sistema de ventanas de Windows e inyectando el código en la consola JavaScript del navegador cuando se detecta que el usuario se conecta a la página del banco.

El malware se distribuye mediante campañas de spam dirigidas principalmente a usuarios Polacos, en donde el gancho suele ser la actualización de una aplicación legítima, como TPVCGateway, SQLMon, DbgView, WinRAR Uninstaller, 7Zip, OllyDbg o FileZilla Server.

Estas aplicaciones están modificadas para ejecutar el código malicioso contenido en la función _initterm(), que es la que inicializa los punteros y variables antes de la ejecución del ‘main()’. Esto dificulta la detección, al no verse ningún comportamiento anómalo al inicio de la ejecución del programa.

Ejecución del código malicioso. Fuente: www.welivesecurity.com

Pero la novedad que introduce esta nueva familia es el procedimiento de inyección, que no utiliza complejos procesos de inyección, ni implementaciones específicas para los distintos navegadores. En lugar de esto, el malware utiliza el bucle de mensajes de Windows para detectar si la víctima está accediendo a la banca electrónica y cargar el código JavaScript malicioso en el navegador. Para ello el troyano guarda en el portapapeles el código y lo pega en la consola JavaScript del navegador simulando las pulsaciones de las teclas CTRL+SHIFT+J (para abrir la consola) CTRL+V y ENTER (para pegar y ejecutar el código) y finalmente la combinación para cerrarla, todo ello sin que la víctima perciba nada más que un pequeño cuelgue del navegador.

En nuevas versiones el malware utiliza la barra de direcciones para inyectar el código malicioso. Simulando también las pulsaciones de un usuario para evitar los mecanismos de seguridad.

Hasta el momento las muestras encontradas están dirigidas a bancos Polacos, pero como siempre, desde Hispasec recomendamos no abrir correos con adjuntos no solicitados o no confiables.

Algunos IOCs:

LA LUMBALGIA

La lumbalgia es el dolor localizado en la parte baja de la espalda, desde la costilla hasta los glúteos, cuyo origen tiene que ver con la estructura músculo-esquelética de la columna vertebral. Este afecta a un 80% de personas por lo menos una vez en la vida.

SÍNTOMAS

  • Dificultad para moverse que puede ser lo ponerse de pie.
    La lumbalgia es el dolor localizado en la parte baja de la espalda,
    desde la costilla hasta los glúteos, cuyo origen tiene que ver con la
    estructura músculo-esquelética de la columna vertebral. Este afecta a un
    80% de personas por lo menos una vez en la vida.

 

  • Dolor que se irradia por la pierna o un dolor que también pasa por la ingle, la nalga o la parte superior del  muslo, pero que rara vez llega debajo de la rodilla.

 

  • Área localizada que es dolorosa con la palpación, sobre todo a nivel de la cintura.

FACTORES DE RIESGO

Factores Personales:

  1. Estrés
  2. Depresión
  3. Mal estado físico
  4. Obesidad
  5. Tabaquismo
  6. Edad

“A partir de los 30 años se producen cambios degenerativos en el disco de la columna que conducen a una pérdida de resistencia del mismo”.  

¿CÓMO PREVENIRLA?

  1. En la ocina, mantener la espalda recta en contacto con el respaldar de la silla.
  2. No superar el peso límite permitido por persona (25 kg. en hombres y 15 kg. en mujeres).
  3. Si tienes dolor lumbar, acude al médico.
    La atención precoz disminuye la posibilidad de desarrollar un problema crónico. No se automedique.
  4. Si cargas peso realiza el esfuerzo con las piernas, no fuerces la espalda.
  5. Evitar el uso prolongado de fajas ya que provoca debilidad en la pared abdominal.

DATOS ADICIONALES

  1. En más del 85% de casos, el dolor lumbar no se puede atribuir a una enfermedad especíca o a  una alteración de la columna vertebral.
  2. Tanto trabajadores sedentarios como activos pueden padecerlo, pues es una enfermedad que está inuenciada por otros factores y no solo por factores laborales.
  3. Otro problema frecuente que generan dolor lumbar son la estenosis espinal y la hernia de disco.