Las vulnerabilidades, consideradas críticas, podrían permitir el compromiso de dispositivos Android de manera remota, tan sólo con enviar paquetes maliciosos, especialmente construidos para ella, vía inalámbrica y sin requerir intervención alguna del usuario.
Las vulnerabilidades han sido descubiertas por investigadores del equipo Tencent’s Blade. Han sido bautizadas colectivamente como QualPwn, y residen en el firmware de los chipsets Qualcomm que dan alimentación a cientos de millones de dispositivos Android, tanto smartphones como tablets.
Según los investigadores, hay, fundamentalmente, dos vulnerabilidades críticas en los chipsets Qualcomm y una en el controlador Qualcomm del kernel de Linux para Android. Si se encadenan ambas vulnerabilidades, esto podría llevar a los atacantes a obtener el control completo sobre los dispositivos Android que se encontraran en su rango de emisión / recepción inalámbrica.
Los investigadores de Tencent’s Blade han publicado un breve artículo donde exponen los códigos asociados a las vulnerabilidades, así como algunas preguntas frecuentes relacionados con el hallazgo que han recibido por parte de la comunidad.
A continuación enumeramos someramente las vulnerabilidades:
CVE – 2019 – 10539 – Se trata de un buffer overflow que reside en el firmwareWLAN de Qualcomm y afecta a la función del área vecina de red (NAN) debido a una comprobación insuficiente acerca la longitud máxima permitida cuando se parsea una determinada cabecera.
CVE – 2019 – 10540 – Este segundo fallo está relacionado con otro buffer overflow que también reside en la misma función. El parámetro vulnerable, esta vez, es el atributo ‘NAN availability’.
CVE-2019-10538 – El tercer fallo de seguridad se encuentra en el controlador Qualcommdel kernel de Linux para Android que pude ser explotado enviando de forma subsiguiente peticiones maliciosas desde el chipsetWifi para sobreescribir partes del kernel relacionadas con el sistema operativo.
Una vez comprometido el kernel, éste da al atacante control pleno sobre el sistema, incluyendo la capacidad para instalar rootkits, extraer información sensible y llevar a cabo otras acciones maliciosas, todo esto evadiendo las características de detección.
A pesar de que los investigadores han testeado sus denominados ataques QualPwn contra dispositivos Google Pixel 2 y Pixel 3 que están siendo ejecutados sobre chips Qualcomm Snapdragon 835 y Snapdragon 845, las vulnerabilidades podrían afectar a muchos otros chipsets, según el aviso publicado por el propio fabricante.
Google ya ha liberado las actualizaciones de seguridad para esas vulnerabilidades como parte de su boletín de seguridad para Android de agosto de 2019. Se recomienda aplicar este parche en cuanto esté disponible. Dado que Android es extremadamente lento para liberar sus actualizaciones, los investigadores han tenido a bien no publicar al completo los detalles técnicos de la explotación.
El investigador de seguridad Dominik Penner ha descubierto recientemente una vulnerabilidad en KDE que permite ejecutar comandos del sistema al abrir un directorio con un fichero .directory manipulado.
Se ha descubierto una vulnerabilidad no parcheada aún en el entorno de escritorio KDE. Afecta a las versiones 4 y 5(KDE Plasma), y la víctima solamente necesita abrir un directorio para que el comando malicioso sea ejecutado.
La vulnerabilidad se produce gracias a los ficheros «.directory», que son ficheros similares a los ficheros «desktop.ini» de Windows. En estos ficheros se especifican diferentes variables de configuración para el directorio en el que se encuentran.
Una de estas variables es «Icon», que se puede configurar indicando el path a una imagen que utilizará el navegador de ficheros Dolphin como icono de la carpeta en los diferentes menús. Esta es una de las variables que permite el uso de «shell expansion».
La idea de la funcionalidad shell expansion es proporcionar la posibilidad al usuario de incluir un valor dinámico a las variables, ya que en algunos casos esta opción podría ser útil. Sin embargo, esta funcionalidad permite que se acabe inyectando un comando de consola que acabará ejecutándose.
En la prueba de concepto realizada por Penner, se puede ver cómo simplemente descargando y descomprimiendo un fichero ZIP que contiene un directorio con un «.directory» que explota la vulnerabilidad, el atacante es capaz de obtener una shell inversa con la que consigue control de la máquina de la víctima.
Prueba de concepto que abre la calculadora
Como se puede ver en la vídeo anterior de la prueba de concepto realizada por Hispasec, simplemente con un fichero «.directory» y abusando la funcionalidad «shell expansion«, es posible ejecutar cualquier comando, comprometiendo la máquina de la víctima.
Aunque estos ficheros de configuración se llaman «.directory», en nuestras pruebas hemos podido comprobar que KDE también permite aquellos llamados «_directory».
La vulnerabilidad aún no está corregida, por lo que recomendamos a los usuarios de KDE que tengan especial cuidado hasta que se solucione y mantener actualizado el sistema.
El Department of Homeland Security de los estados unidos ha publicado una alerta avisando a los propietarios de aviones pequeños y pidiendo que realicen las mitigaciones recomendadas para evitar que un atacante se aproveche de la vulnerabilidad para tomar el control de la avioneta.
La vulnerabilidad descubierta y publicada en este reporte de Rapid7, reside en las implementaciones modernas del bus de datos CAN (Controller Area Network), un popular estándar de redes que se aplica en algunos vehículos y aeronaves que posibilita que los microcontroladores y dispositivos se comuniquen entre sí.
La investigación llevada a cabo en los laboratorios de Rapid7 empleó el el uso de dos sistemas de dos fabricantes distintos para realizar el ataque. Lo que encontraron fue:
Fabricante X
En la implementación realizada por el que llamaremos: Fabricante X, se descubrió que el CAN ID 0x205 era el responsable de la presión y temperatura del aceite además de las lecturas de temperatura de dos culatas. Enviando un mensaje elaborado utilizando este CAN ID, en Rapid7 fueron capaces de enviar mensajes falsos relativos a la presión, temperatura del aceite y lecturas falsas de la temperatura de dos culatas.
También se identificaron, para esta implementación, algunos CAN ID más como el 0x241 que es el encargado de la brújula o los 0x281-284, encargados de la altitud y el sistema de referencia de rumbo (AHRS), actuando el AHRS como nodo 1. Los nodos 2,3 y 4 hacían referencia a los IDs 0x291-294, 0x2A1-2A4 y 0x2B1-2B4 respectivamente.
Los mensajes de AHRS fueron modificados mediante ingeniería inversa utilizando mensajes de falsificados de unidades AHRS inexistentes, logrando cambiar la altitud de la aeronave mostrada, lo que muestra una posición incorrecta de la avioneta.
CAN IDs falsificados. Fuente: rapid7.com
La naturaleza del bus de datos CAN permite a cualquier dispositivo con acceso físico a los a los CANs enviar mensajes falsos al bus. Los paquetes CAN no disponen de ninguna dirección de destino ni ningún otro mecanismo de autenticación, lo que presenta el problema de no poder identificar quién está enviando dichos mensajes. Esta característica lo hace especialmente sencillo de implementar, pero dificulta mucho su configuración de forma segura al utilizar un medio compartido y, como hemos hecho alusión, no presentar ningún mecanismo de identificación.
Fabricante Y
Por otro lado, en la implementación realizada por el que llamaremos Fabricante Y, Rapid7 identificó el CAN ID 0x10342200 era el encargado de controlar y mostrar la presión del aceite. Rapid7 fue capaz de mostrar cómo, creando mensajes elaborados y utilizando este CAN ID, eran capaces de enviar lecturas falsas relativas a la presión del aceite.
Paquetes CAN manipulados. Fuente: rapid7.com
También se detectó que la brújula electrónica utilizaba CAN ID 0x10A8200 y 0x10A82100 para estos mensajes. El CAN ID 0x10A8200 actuó como un paquete de encabezado, con el tercer byte actuando como un indicador de longitud. Los campos de rumbo magnético, tiempo y fuerza del campo magnético fueron modificados por técnicas de análisis de protocolo estándar.
Mensaje de la brújula de la aeronave. Fuente: rapid7.com
Algunas mitigaciones
Como se ha visto, muchas de estas vulnerabilidades derivan de problemas de seguridad física. El DHS así lo menciona y da algunas recomendaciones en la sección de «Mitigations» de la alerta publicada. Entre sus propuestas como posibles mitigaciones tenemos:
Restringir lo mejor posible los accesos físicos a las aeronaves.
Realizar un análisis de impacto y uno de evacuación para así poder elaborar medidas de seguridad efectivas
A lo largo de la historia del ransomware hemos visto diferentes vectores de ataque. En esta nueva entrada vamos a descubrir cómo los atacantes utilizan el protocolo RDP de Microsoft para introducir el ransomware en los equipos de sus vícitimas.
El protocolo RDP es utilizado habitualmente para conectarse de forma remota a los escritorios de oficinas, por lo que se ha convertido en un vector de ataque atractivo para los ciberdelincuentes y que puede causar la parálisis de una PYME con una alarmante facilidad.
La siguiente imagen es una búsqueda de escritorios remotos en Shodan. Como podemos ver, Shodan nos devuelve casi 5 millones de resultados (51.154 dispositivos encontrados en España), lo que no quiere decir que todas ellas tengan RDP activo, el grueso de la búsqueda solo serán dispositivos con el puerto 3389 abierto, pero podemos intuir que hay un gran número de posibles víctimas, y muchas de ellas pertenecerán a empresas y organizaciones que pueden quedar paralizadas si sus datos son comprometidos.
¿Cómo explotan los cibercriminales RDP?
Existen dos vectores de ataque distintos, hemos visto ataques que explotan vulnerabilidades en RDP y que son algo más sofisticados pero la gran mayoría de las intrusiones en los sistemas que utilizan este protocolo se han llevado a cabo utilizando fuerza bruta para romper contraseñas débiles, o mucho más fácil, buscar las contraseñas en BBDD leakeadas.
Una vez que los atacantes tienen acceso al equipo de la víctimas solo tienen que desactivar manualmente el antivirus que se esté utilizando e instalar el software de rescate para infectar el equipo.
Los resultados de un ataque de ransomware pueden resultar devastadores para las PYMES pero no solo afecta al pequeño comercio, se han dado casos de hospitales que han sido infectados y han tenido que pagar el rescate para poder tener acceso a sus archivos.
En el último año grupos como Matrix y SamSam han ido abandonando los distintos vectores de ataque para dedicarse casi por completo a la infección por RDP. Como ya vimos en este mismo blog el pasado 31 de mayo, más de 1 millón de máquinas eran vulnerables a BlueKeep (CVE-2019-0708), lo que podría desencadenar un «brote de ransomware por todo el mundo en cuestión de horas» según Matt Boddy, experto en seguridad de Sophos.
Según explicó Matt, en la actualidad hay más de 3 millones de dispositivos vulnerables a ataques por RPD, se ha estado informando sobre cómo todos los honeypots fueron descubiertos en pocas horas para su explotación, tan solo porque estaban expuesto en Internet.
La conclusión que nos aportaba era la de reducir el uso del protocolo RDP siempre que sea posible y utilizar contraseñas robustas que dificulten los ataques por fuerza bruta. Todas las empresas deben actuar en consecuencia e implementar protocolos de seguridad que ayuden a minimizar el riesgo y la exposición para protegerse contra estos cibercriminales.
Durante los últimos días hemos oído hablar de Machete, el malware utilizado por un grupo de hackers presuntamente de habla hispana y que se encuentra activo desde 2014, fecha en la que comenzó a ser estudiado por Kaspersky.
Se cree que los atacantes son hispanohablantes ya que en el código del malware aparecen palabras escritas en español, como se puede ver en la siguiente imagen:
Ejemplos de palabras en español usadas en el código de Machete Fuente de la imagen: ESET
Apoyando esta teoría encontramos el registro de pulsaciones de teclado (keystrokes logs) y los datos del portapapeles, en ambos casos presentados en español a pesar de que al principio se encontraban escritos en inglés, lo cual, según ESET, podría ser indicio de ćodigo copiado. No obstante algunos investigadores insisten en que la existencia de código y registros en español no significa que el grupo sea de habla hispana, sino que puede ser un simple mecanismo de despiste.
A pesar de que Machete comenzó con actuaciones más genéricas en toda Latinoamérica, en los últimos años ha empezado a centrarse en países más específicos como Ecuador (16%), Colombia (7%), Nicaragua (2%), y finalmente Venezuela(75%), donde se concentran la mayoría de sus acciones.
El procedimiento para infectar el equipo objetivo es el siguiente: Machete envía correos electrónicos directamente a sus víctimas, emails que van cambiando de un blanco a otro. Estos correos electrónicos contienen un enlace o un adjunto con un archivo comprimido y autoextraíble, el cual ejecuta el malware a la par que abre un documento que funciona como señuelo. Los documentos que utiliza Machete son documentos reales robados en ataques previos, lo cual hace más fácil la tarea de engañar a sus blancos. Estos documentos usados como señuelo suelen ser enviados y recibidos legítimamente varias veces al día en las organizaciones objetivo del malware, aprovechando así los atacantes la oportunidad para elaborar correos electrónicos de phishing que resultan ser muy convincentes.
Pero, ¿sabemos realmente cómo funciona este malware?
Machete: análisis técnico
Entre 2014 y 2017 el malware era distribuido en paquetes de archivos que al ser extraídos causaban la ejecución de varios componentes py2exe de Machete: py2exe es una herramienta que convierte los scripts de Python en archivos ejecutables de Windows, los cuales no requieren que Python esté instalado para ser ejecutados.
La nueva versión de Machete, vista por primera vez en abril de 2018, hace uso de un archivo de descarga en su primera etapa. Este archivo instala los componentes del backdoor en un sistema que ha sido comprometido.
Componentes de Machete Fuente de la imagen: ESET
Como se ve en la imagen, el archivo descargable es un autoextraíble (RAR SFX) que abre otro archivo, pudiendo éste ser un PDF o un documento de Microsoft Office, el cual es usado como señuelo para luego ejecutar el descargable. Este último contiene el binario (el componente py2exe) y un archivo de configuración con la URL objetivo, la cual se presenta como un string cifrado.
Componentes del descargable
Lo que se aprecia en la siguiente imagen es un ejemplo de un archivo de configuración para un descargable autoextraíble:
Configuración de un descargable de Machete Fuente de la imagen: ESET
El archivo .exe que se ve en la imagen es un RAR SFX muy similar en cuanto a estructura al payload final usado por Machete. Contiene un py2exe ejecutable y un archivo de configuración con la URL desde la que descargar Machete. El archivo de configuración, llamado mswe, es una cadena cifrada AES (Advanced Encryption Standard) y codificada en base64 de .
La ejecución del descargable es la siguiente:
El directorio de trabajo del descargable es %APPDATA%\GooDown.
Se crea la tarea programada ChromeDow para ejecutar el descargable cada 3-6 minutos.
Se lee y se descifra la URL del archivo de configuración mswe.
Se ejecuta Machete.
Se elimina la tarea del descargable.
Código del descargable Fuente de la imagen: ESET
Ofuscación
Los ejecutables py2exe contienen un bloque de texto codificado en base64 y comprimido con zlib el cual, después de ser decodificado, muestra el ćodigo de la imagen. La ofuscación tiene lugar mediante el uso de pyminifier con el parámetro -gzip.
Ofuscación extra de Machete Fuente de la imagen: ESET
Tras esta ofuscación encontramos código con nueva ofuscación, incluyendo nombres aleatorios de variables y código basura. Este método se denomina pyobfuscate, un proyecto ya usado en versiones anteriores de Machete.
Ejemplo de la primera capa de ofuscación de Machete Fuente de la imagen: ESET
Componentes del backdoor
Cuando se ejecuta el RAR SFX se extraentres componentes py2exey un único archivo de configuración (jer.dll) que contiene texto codificado en base64 el cual se corresponde con las strings cifradas en AES.
Componentes ejecutables py2exe de Machete Fuente de la imagen: ESET
GoogleCrash.exe (programación y persistencia)
Es el componente principal del malware, el primero que se ejecuta y lanza los dos siguientes programando su ejecución y creando Tareas de Programación de Windows (Windows Task Scheduler) para dar lugar a la persistencia.
Se lee el número de la versión en el archivo jer.dll; este número tiene 4 dígitos y a veces incluye un ‘.0’ al final (ejemplo: 1111.0). En el caso de que el equipo de la víctima ya hubiese sido comprometido previamente y el número de la versión en el nuevo archivo de configuración fuese mayor que el existente, los archivos, procesos y tareas de la instalación antigua de Machete se borran y se instala la nueva versión.
El componente espía se ejecuta cada 3 minutos, el de comunicación cada 10 minutos y el de persistencia, cada 30 minutos. Los archivos ejecutables se copian en:
%APPDATA%\Chrome\Google\
%APPDATA%\Gchrome\
Como acción final se crea un archivo que contiene la dirección MAC y el hostname cifrados y se usa para identificar a la víctima (archivo chrom.dll).
Chrome.exe (componente espía)
Se encarga de recoger información sobre la víctima. Ejecuta operadores basados en temporizadores. Los datos obtenidos se guardan en diferentes subcarpetas que dependerán del tipo de datos que se robe (capturas de pantalla, logs de pulsaciones, etc.). El componente de comunicación enviará estos datos a un servidor remoto.
Las capturas de pantalla se realizan cada cinco minutos usando ImageGrab de Python Imaging Library (PIL). El nombre del archivo se codifica con ROTI3 y luego la imagen se cifra (con AES) y se mueve a la carpeta Winde.
Otra de las funcionalidades del malware es crear una lista de los archivos modificados cada año. Para ello se crea un archivo de texto cada año que contiene una lista de los archivos que han sido modificados ese mismo año (solo si la lista no existe ya). Este proceso se ejecuta cada 60 segundos, buscando archivos en todos los drives; si la lista ya existía pero se han encontrado nuevos archivos, se borran los antiguos para sustituirlos.
Además de documentos de Microsoft Office e imágenes, las listas incluyen archivos de backup, de bases de datos, keys criptográficas (PGP), documentos de OpenOffice, vectores de imágenes, y archivos de sistemas para información geográfica (mapas topográficos, rutas de navegación, etc).
El acceso al portapapeles se consigue creando una ventana y añadiendo los siguientes mensajes:
M_DRAWCLIPBOARD, WM_CHANGECBCHAIN
WM_DESTROY
Una vez hecho esto, el payload ya habrá sido incluido en la función OnDrawClipboard. El contenido del portapapeles junto con la ventana de la cual procede la operación se guardan en un archivo HTML llamado Hser, que se almacenará en el mismo directorio que las capturas de pantalla.
Se lleva a cabo a su vez la detección de nuevos dispositivos insertados que son extraíbles, lo cual se logra mediante la creación de una ventana de alto nivel. Para esta ventana se usa el nombre Device Change Demo y el payload se puede encontrar en la función onDeviceChange. Cuando se inserta un archivo de dispositivos extraíbles, se copian los ejecutables del malware (de la carpeta Gchrome) a la carpeta root del nuevo dispositivo. Luego, cada archivo en ese dispositivo que coincide con una de las extensiones deseadas se copia y se cifra en la carpeta Winde, del dispositivo local. Además, cuando se detecta un dispositivo extraíble también se comprueba la existencia de un nombre de archivo específico. Si este último se encuentra, los archivos de cada dispositivo son copiados y cifrados a un dispositivo extraíble en una carpeta escondida. Este archivo específico no se encuentra en ninguna parte del código de Machete y el nombre del archivo puede variar de una víctima a otra. Esto es una forma de exfiltrar los datos en los casos en los que el atacante tiene acceso físico a un ordenador previamente comprometido por Machete.
Por otro lado, los datos obtenidos durante el proceso de keylogging se guardan en la carpeta Hser. En la siguiente imagen podemos observar las variables keyids adaptadas para el teclado español, relacionado esto con algunos de los indicios previamente mencionados que hacen sospechar que el grupo de atacantes es hispanohablante:
Keys en una distribución en español Fuente de la imagen: ESET
La información de los usuarios de Chrome y Firefox se obtiene creando un archivo comprimido de la carpeta de datos del usuario para ambos navegadores. Estos archivos comprimidos (FIREPERF.zip y CHROMEPER.zip) se guardan en la carpeta Winde, mientras que los archivos originales se guardan en las siguientes carpetas:
También se recoge información sobre las redes Wi-Fi disponibles ejecutando los siguientes comandos en Windows:
netsh wlan show networks mode=bssid
netsh wlan show interfaces
El resultado de estos comandos es parseado y se crea un diccionario que contiene la información sobre los puntos de acceso de la dirección MAC, mostrando qué red Wi-Fi presenta una mayor disponibilidad. Esta información se envía a un JSON de la API de Servicios de Localización de Mozilla, la cual proporciona coordenadas de geolocalización cuando obtiene datos como puntos de acceso Wi-Fi. El uso de la API de Mozilla tiene la ventaja de que permite llevar a cabo el proceso de geolocalización sin hacer uso de un GPS real y puede ser más efectivo que otros métodos. Por ejemplo, se puede usar la dirección IP para obtener una localización aproximada, aunque no sea tan exacta.
GoogleUpdate.exe (comunicación)
Se encarga de comunicarse con el servidor remoto. La configuración para iniciar la conexión se lee del archivo jer.dll (el dominio, nombre de usuario y la contraseña). El principal medio de comunicación de Machete es vía FTP, aunque en 2019 también se incluyó el método HTTP por si, por alguna razón, la conexión FTP fallase.
La principal funcionalidad de este componente es subir archivos cifrados situados en la carpeta Winde a diferentes subdirectorios del C&C.
Código para subir archivos en Winde Fuente de la imagen: ESET
En esta etapa se lee la lista de archivos generados por el componente Chrome.exe (almacenado en la carapeta Loc) y se cifran dichos archivos (temporalmente en la carpeta Winde), subiéndose a su vez al servidor C&C. Una vez se sube un archivo, éste se borra de la carpeta Winde, así como también se borra la línea correspondiente de la lista de archivos.
Los operadores de Machete, dejando archivos específicos en el servidor, también pueden actualizar las configuraciones, los archivos de malware, las listas de archivos, o ejecutar otros binarios. Por lo tanto, pueden personalizar el comportamiento del malware si quieren conseguir datos más específicos. Si un archivo jer.dll existe en el servidor cuando se ejecuta GoogleUpdate.exe, el archivo de configuración local jer.dll se sobreescribe con la actualización. Después de ser usado, se borra del servidor. Si existe un archivo bers.dll, reemplaza la lista de archivos del año actual, situado en la carpeta Loc, para que así los operadores de Machete puedan conseguir archivos específicos del equipo comprometido.
Nuevos componentes
En junio de 2019 se empezaron a ver cambios en la estructura de Machete, mientras se mantenían sus funcionalidades principales. Parece ser que Machete ha sido reescrito para usar diferentes librerías desde la implementación de la actualización, quizás con la intención de evadir su detección.
Las tareas de esta nueva versión se dividen en seis componentes que ya no son ejecutables py2exe. Se empaquetan los scripts de Python para componentes maliciosos, un ejecutable original para Python 2.7 y todas las librerías usadas en un archivo autoextraíble llamado python27.exe. Este binario es distribuido junto con el documento usado como señuelo.
Configuración para la autoextracción de python27.exe Fuente de la imagen: ESET
Se crea la carpeta C:\Python2.7, la cual contiene los scripts maliciosos y las librerías de Python en el subdirectorio DLL. El primer componente que se ejecuta es _hashlbi.pyw, el cual es similar a GoogleCrash.exe pero con código diferente. Este componente crea las carpetas del malware y programa las tareas para ejecutar el resto de componentes, además de copiar archivos de Microsoft Office y crear directorios con nombres basados en el SHA-256 de esos archivos. Otros componentes son:
_clypes.pyw: este componente ejecuta procesos (cada tres o cuatro horas) buscando navegadores webs.
_bsdbd.pyw: realiza capturas de pantalla y accede al portapapeles y a los drives desechables.
_elementree.pyw: lleva a cabo la geolocalización con un código similar al que se ha descrito previamente.
_mssi.pyw: keylogging.
_multiproccessing.pyw: comunicación.
Nombres de dominio
Inicialmente se vieron tres nombres de dominios usados en los archivos de configuración de Machete, y todos ellos apuntaban a la misma dirección IP durante 2019, pero una petición de DNS pasiva mostró otras dos direcciones IP que estaban activas durante 2018. En la siguiente tabla se puede ver la información sobre estos dominios:
Tabla de dominios e IPs correspondientes Fuente de la tabla: ESET
Conclusiones
A pesar de que numerosos investigadores han publicado en varias ocasiones descripciones técnicas e IoCs de Machete, el grupo detrás de este malware ha conseguido continuar operando mediante la introducción de pequeños cambios a su código y a la infraestructura, evadiendo así diferentes medidas de seguridad. Podemos concluir que, tal y como se señala en el estudio de ESET en el que se basa este artículo, quienes han fallado realmente son las organizaciones víctimas ya que no han hecho suficiente hincapié en la creación de conciencia y la aplicación de políticas de seguridad para que los empleados no caigan en este tipo de ataques.
Investigadores de ProofPoint han descubierto una nueva campaña de phishing que utiliza AWS (Amazon Web Services) para alojar las webs fraudulentas.
A finales de julio ProofPoint detectaba que algunos de sus phishings monitorizados estaban alojados en AWS, algo poco habitual dadas las restricciones a las que están sometidos para su temprana detección.
La tendencia en los ataques de phishing parece estar tomando un nuevo camino: cada vez se hace más habitual encontrar los kits fraudulentos en servicios de almacenamiento en la nube como GitHub, Dropbox o Google Drive.
Pero no solo están almacenando los kits en la nube, además aprovechan servicios como WeTransfer o DocuSign para distribuir páginas que redirijan a los phishingy eludir así las defensas del correo electrónico a la hora de comprobar si la URL es fraudulenta. Los atacantes aprovechan un servicio legítimo que genera una falsa confianza en la víctima de la que aprovecharse para que haga clic en el correo y abra el archivo HTML que la redirija a la página fraudulenta.
Algo similar está ocurriendo con AWS. Los cibercriminales están utilizando diferentes técnicas de codificación mediante JavaScript para evitar que las páginas sean detectadas como una amenaza. Hay que tener en cuenta que los atacantes buscan en todo momento no ser detectados, por ello han incrementado el uso de plataformas de almacenamiento en la nube para alojar estas páginas falsas.
Como ya hemos visto, AWS no es la única empresa que se está viendo afectada por este problema. Otras como Microsoft o Github lo han sufrido.
La característica está ya disponible en todos los dispositivos Pixel y estará en los próximos días también disponible para todos los dispositivos Android cuyas versiones sean superior a la 7 y permitirá, de forma local, la autenticación biométrica en servicios de Google a través de la huella dactilar.
Imagen: proandroiddev.com
Para los usuarios de Chromeen Android, es posible a partir de hoy autenticarse en este servicio utilizando el sensor del smartphone encargado de leer la huella dactilar. De este modo se evita tener que introducir manualmente la contraseña en cada proceso de autenticación. La característica forma parte de un grupo de nuevas implementaciones llevadas a cabo por Google, orientadas a la verificación local de la identidad del usuario, que permiten la adopción de métodos utilizados para desbloquear el dispositivo Android – patrones, pin, contraseña, huella dactilar – para acceder a servicios de Google.
Este mecanismo aprovecha las ventajas de la estandarización del protocolo de autenticación promovido por el proyecto FIDO2, que a su vez descansa sobre los avances y propuestas de otros estándares reconocidos como WebAuthn de W3C y FIDO–CTAP; ambos núcleos fundamentales del proyecto FIDO2. Como característica muy notable, en tanto que es una parte fundamental del diseño de este estándar, cabe destacar que la huella dactilar nunca se envía al servidor de Google. Sólo se envía la confirmación de que el recurso se escaneó correctamente y de que la prueba criptográfica se satisfizo correctamente.
Por otro lado, la iniciativa implica una centralización de las competencias y recursos relacionados con la autenticación, dado que la propuesta pasa, al menos inicialmente, por el uso de la plataforma de gestión de contraseñas de Google. Una gestión netamente local de credenciales de manera robusta, manteniendo el control local de los recursos y descentralizando la misma, para evitar puntos únicos de fallo (SPOF), sólo sería posible con la utilización de software libre destinado específicamente a satisfacer esta necesidad, como el gestor de contraseñas Keepass.
Adicionalmente y, coincidiendo en este caso con la opinión de Google, esta arquitectura debería ser complementadacon factores de doble autenticación, como el envío de confirmaciones a otros dispositivos, típicamente, el envío de mensajes de texto a dispositivos controlados físicamente por el usuario.
Para más información, adjuntamos el recurso correspondiente a la ponencia de Christian Braand, Product Manager, Security & Privacy de Google, donde se abordan todas estas cuestiones con mayor profundidad.
El investigador de seguridad Eyal Itkin ha descubierto 6 vulnerabilidades diferentes en las cámaras Canon DSLR. Algunas de ellas pueden utilizarse para lograr la ejecución de código de forma remota.
Imagen de BleepingComputer.com
Las vulnerabilidades se han descubierto en el protocolo de transferencia de imágenes (Picture Transfer Protocol, PTP) y permiten la ejecución remota de código.
En el caso de aquellas cámaras que permiten una conexión wireless, las vulnerabilidades pueden explotarse de forma remota a través de un punto de acceso WiFi malicioso. De esta forma, una cámara podría ser atacada simplemente conectándose a la red WiFi.
Para aquellos dispositivos que no soportan conexiones wireless, es posible explotar las vulnerabilidades a través de la conexión USB, lo que permite a un atacante ejecutar código malicioso en el dispositivo al conectarlo al ordenador.
Los investigadores analizaron el protocolo PTP de transferencia de imágenes implementado por las cámaras Canon. Estudiaron los 148 comandos soportados y obtuvieron una lista de 38 comandos que permitían proporcionar un buffer como parámetro de entrada.
La lista de vulnerabilidades y comandos vulnerables es la siguiente:
CVE-2019-5994. Buffer Overflow en el comando SendObjectInfo (código 0x100C)
CVE-2019-5998. Buffer Overflow en el comando NotifyBtStatus (código 0x91F9)
CVE-2019-5999. Buffer Overflow en el comando BLERequest (código 0x914C)
CVE-2019-6000. Buffer Overflow en el comando SendHostInfo (código 0x91E4)
CVE-2019-6001. Buffer Overflow en el comando SetAdapterBatteryReport (código 0x91FD)
CVE-2019-5995. Vulnerabilidad en la actualización de firmware que permite la actualización silenciosa a un firmware malicioso
Además de las vulnerabilidades encontradas, gracias al trabajo de ingeniería inversa realizado, Itkin encontró una forma de cifrar ficheros almacenados en la tarjeta de memoria. Para ello, utiliza las mismas funciones criptográficas utilizadas por la cámara durante el proceso de actualización para verificar que el firmware es legítimo.
Haciendo uso de dichas funciones, desarrolló como prueba de concepto un ransomware que infecta la cámara utilizando las vulnerabilidades y cifra las fotos de la tarjeta de memoria.
Prueba de concepto del ransomware
Las vulnerabilidades fueron reportadas a Canon el 31 de Marzo, y el pasado 30 de Julio se publicó en Europa la versión 1.0.3 del firmware que corrige estos fallos de seguridad.
Si eres propietario de alguna de estás cámaras, te recomendamos que actualices el firmware y evites conectar tu dispositivo a redes WiFi que no son de confianza.
Como suele ser frecuente ya en Microsoft, el segundo martes de cada mes se publica su paquete mensual de actualizaciones de seguridad, conocido por su nombre en inglés «Patch Tuesday». Este mes Microsoft ha parcheado 93 fallos de seguridad y ha publicado dos avisos incluyendo mitigaciones para problemas relacionados con la seguridad que afectan a productos y servicios de su compañía.
Aunque, como ha dicho hace unas horas el investigador de seguridad Sergio de los Santos a través de su Twitter, «las estrellas» entre todas las vulnerabilidades y todos los fallos de seguridad son 4 fallos que afectan a RDS (el servicio de escritorio remoto de Windows)
De estos cuatro CVEs, son los 2 primeros los fallos más graves. De hecho, en el blog del propio Simon Pope -Director de Respuestas a Incidentes en el Centro de Repuesta de Seguridad de Microsoft (MSRC)- se apuntó que estos fallos eran susceptibles de incluir en su explotación capacidades de replicación y pivotaje propias de un gusano, recordando al fallo BlueKeep que Microsoft ya solucionó en mayo.
Esto significa que los atacantes pueden explotar los errores para apoderarse de un ordenador y luego pivotar a otros ordenadores sin ninguna interacción del usuario.
Los parches CVE-2019-1181 y CVE-2019-1182 son de la mayor urgencia, por buenas razones.
Pero los cuatro errores de ejecución remota de código (RCE) en el componente RDS no son los únicos RCE parcheados este mes.
También hay siete RCEs que afectan al motor de secuencias de comandos Chakra (incluido en Microsoft Edge y otras aplicaciones de Microsoft), dos RCEs en la tecnología hipervisor del programa de virtualización Microsoft Hyper-V, seis RCEs en el componente de gráficos de Microsoft, uno en Outlook, dos en Word, dos en el cliente DHCP de Windows, dos en el componente anterior de Scripting Engine y uno en el motor VBScript.
En resumidas cuentas, el Patch Tuesday de agosto es, sin duda, voluminoso y crítico. De las 93 vulnerabilidades que Microsoft parcheó hoy, 29 están clasificadas como críticas y 64 tienen una clasificación de gravedad importante.
Además, aprovechando esta ocasión, Microsoft también ha querido recordarles a los usuarios que Windows 7 y Windows Server 2008 R2 no tendrán soporte extendido y no recibirán actualizaciones a partir del 14 de enero de 2020.
«We strongly recommend that you update any computers running Windows 7 or Windows Server 2008 R2 so you will continue receiving security updates,»
Desde Hispasec Sistemas recomendamos también que tengáis actualizados vuestros sistemas y vuestro software a la última versión disponible para evitar ataques como los expuestos en el presente artículo.
Más información
Security Updates de agosto de 2019 https://portal.msrc.microsoft.com/en-us/security-guidance/releasenotedetail/312890cc-3673-e911-a991-000d3a33a34d
Blog de Simon Pope https://msrc-blog.microsoft.com/2019/08/13/patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-1181-1182/
Micorosft corrige en mayor BlueeKeep https://www.zdnet.com/article/microsoft-patches-windows-xp-server-2003-to-try-to-head-off-wormable-flaw/
El fallo afecta a todas las versiones desde Windows XP, permitiendo leer y escribir comunicaciones de MSCTF para escapar de un sandbox y escalar privilegios
El equipo de seguridad Google Project Zero ha descubierto que la comunicación entre servidor y cliente del servicio Ctfmon es insegura, siendo empleada por el Text Services Framework (TSF), responsable de notificar a las aplicaciones de cambios en el mapeado de teclado y el método de entrada.
Los fallos descubiertos permiten conectarse a una sesión CTF para leer el texto que se introduce en cualquier ventana (incluyendo contraseñas) y manipular su entrada, aunque pertenezca a otra sesión. Este error permite a un usuario sin permisos esperar a que el administrador se encuentre disponible para escalar privilegios. El fallo también puede ser aprovechado por aplicaciones que usan el sandbox AppContainer para comunicarse con otras aplicaciones fuera del sandbox.
Los fallos en Ctfmon dejan inservible el User Interface Privilege Isolation (UIPI) introducido en Windows Vista, permitiendo entre otras cosas tomar el control de la ventana de consentimiento (UAC). Como puede comprobarse en el siguiente vídeo puede ser usado para escalar privilegios en el sistema.
El problema no es debido a una única vulnerabilidad, sino del mismo protocolo CTF. Al no requerirse ningún tipo de autenticación, pudiendo conectarse a cualquier sesión existente, se puede obtener el control completo sobre cualquier comunicación. Lo único que se solicita al conectarse a una sesión es el id del hilo, el id de proceso y el HWND (el ID de ventana) empleado por la sesión, pudiendo el cliente mentir sin que MSCTF compruebe si es cierto.
Si utilizas LibreOffice es el momento de actualizar a su ultima versión 6.2.6/6.3.0 en la que se corrigen tres vulnerabilidades críticas que pueden dar pie a ejecutar código en tu ordenador.
LibreOffice es una suite de ofimática libre y de código abierto. Está entre las alternativas más populares a Microsoft Office, y disponible tanto para sistemas Windows como para Linux y macOS.
La primera de las vulnerabilidades (CVE-2019-9850), descubierta por Alex Inführ (@insertscript), es capaz de saltarse la protección de otra vulnerabilidad (CVE-2019-9848) reportada hace un mes y parcheada en la versión 6.2.5, en la que era posible ejecutar código remoto gracias a LibreLogo, un ambiente de programación simple que se utiliza para mover una imagen vectorial. Internamente los comandos escritos en el documento se traducen al lenguaje Python y se ejecutan. El problema es que la traducción no se realiza bien, y en ocasiones, si se escribe código Python directamente en el documento, al traducirse se mantiene igual. A partir de la versión 6.2.5 ya no era posible llamar a LibreLogo desde un controlador de eventos como puede ser MouseOver. Como decíamos al principio del párrafo, la nueva vulnerabilidad es capaz de saltarse esta protección debido a una insuficiente validación de URL, permitiendo llamar al evento que ejecuta LibreLogo.
La segunda vulnerabilidad (CVE-2019-9851) descubierta por Gabriel Masei de 1&1 también tiene relación con la reportada el mes pasado y descrita anteriormente (CVE-2019-9848). Como ya explicamos, para arreglar el fallo se inhabilitó la opción de ejecutar LibreLogo desde el documento a partir de un controlador de eventos, haciendo hincapié en «desde el documento» ya que esta nueva vulnerabilidad aprovecha la opción que brinda LibreOffice de ejecutar scripts preinstalados en eventos globales como puede ser ‘document-open‘ para cargar LibreLogo y así poder ejecutar comandos.
Por último, la tercera vulnerabilidad (CVE-2019-9852), descubierta por Nils Emmerich de ERNW Research GmbH, tiene relación con la anunciada en febrero de este año (CVE-2018-16858) ya que es posible evadir la protección, habilitando de nuevo el ataque ‘directory transversal‘ que permitiría ejecutar un script alojado en algún lugar del sistema de ficheros de la víctima.
La ejecución exitosa de cualquiera de estas vulnerabilidades dejaría nuestro sistema al descubierto, dándole acceso al atacante.
Desde Hispasec recomendamos que si usas LibreOffice lo actualices a su ultima versión 6.2.6/6.3.0 para prevenir este tipo de ataques.
Se ha producido un ciberataque cuyo objetivo ha sido los sistemas hospitalarios franceses, específicamente al grupo ‘Ramsay Healt Care’.
Ramsay Healt Care es una compañía de salud francesa, que actualmente tienen un total de 120 centros hospitalarios, los cuales se han visto afectados por un ataque informático.
El ataque se produjo el pasado 10 de agosto y llegó a afectar a 120 establecimientos sanitarios del grupo ‘Ramsay Healt Care’, llegando incluso a provocar un apagón informático en el centro hospitalario localizado en Marsella.
Sobre el ataque no se han dado detalles, y aún no se sabe el origen del mismo, pero por la magnitud de dicho ataque, se puede confirmar que ha sido un ataque totalmente dirigido a la compañía y que no se trata de un ‘malware’ genérico. Una curiosidad sobre la detección del ataque, es que no fue detectado por los sistemas de protección y/o detección instalados en la compañía, sino debido a un mal funcionamiento de los servidores de correo, lo que llevó a los especialista de seguridad de redes a confirmar la infección sufrida en los servidores.
Sobre la profundidad del ataque, si se puede confirmar de los sistemas de salud de los pacientes no se han visto comprometidos, y, aunque los expertos de seguridad confirman que el ataque ha sido detenido a tiempo, no son capaces de confirmar o desmentir si se ha producido una fuga de información sobre los datos de los pacientes. Debido al miedo a que algún sistema pueda seguir infectado, la compañía ha tomado medidas temporales a modo de contramedida llegando a volver al papel y lápiz para la redacción de las recetas médicas.
Se especula que el ataque se haya producido por un ransomware, ya que la compañía ha recibido peticiones de rescate, ‘modus’ operandis’ de este tipo de malware, pero hasta el momento no se ha confirmado nada.
Aunque el ataque en sí ha sido bastante grave, se puede confirmar que toda medida de seguridad de un equipo informático puede no ser suficiente, y más, pensando en que un ataque a estas infraestructuras críticas pueden tener efectos devastadores pudiendo llegar a costar incluso vidas humanas, ya que muchos de estos sistemas de salud aún contienen software muy antiguos y desfasados debido a que la criticidad de estos sistemas dificultan el mantenimiento o actualización.
Actualmente Ramsay Healt Care ha puesto el caso en manos de las fuerzas de seguridad del estado, y aún no se sabe nada sobre los ciberdelincuentes que realizaron el ataque.
En esta era digital, el éxito de casi todas
las empresas de marketing, publicidad y análisis pasa por el seguimiento de los
usuarios a través de Internet para identificarlos y conocer sus intereses para
proporcionarles anuncios específicos.
La mayoría de estas soluciones se basan en cookies de terceros, un conjunto de cookies en un dominio distinto al que está navegando, que permite a empresas como Google y Facebook tomarle las huellas del usuario con el fin de realizar un seguimiento de todos sus movimientos en varios sitios.
Sin embargo, si está utilizando Kaspersky
Antivirus, una vulnerabilidad en el software de seguridad ha expuesto un
identificador único asociado con usted a cada sitio web que ha visitado en los
últimos 4 años, lo que podría haber permitido que esos sitios y otros servicios
de terceros lo rastreen a través de la web incluso si ha bloqueado o borrado
las cookies de terceros oportunamente.
La vulnerabilidad, identificada como CVE-2019-8286 y descubierta por el investigador de seguridad independiente Ronald Eikenberg, reside en la forma en que funciona un módulo de escaneo de URL integrado en el software antivirus, llamado Kaspersky URL Advisor.
De forma predeterminada, la solución de
seguridad de Internet de Kaspersky inyecta un archivo JavaScript alojado
remotamente directamente en el código HTML de cada página web que visita, para
todos los navegadores, incluso en modo incógnito, en un intento de comprobar si
la página pertenece a la lista de direcciones web sospechosas y de phishing.
Bueno, no es ninguna sorpresa, ya que la
mayoría de las soluciones de seguridad de Internet funcionan de la misma manera
para supervisar las páginas web en busca de contenido malicioso.
Sin embargo, Eikenberg encuentra que la URL de
este archivo JavaScript contiene una cadena que es única para cada usuario de
Kaspersky, una especie de UUID (Universally Unique Identifier) que puede ser
fácilmente capturado por sitios web, otros servicios de publicidad y análisis
de terceros, poniendo enu riesgo la privacidad de sus usuarios.
«Es una mala idea porque otros scripts que se ejecutan en el contexto del dominio del sitio web pueden acceder al código HTML en cualquier momento y, por lo tanto, al ID de Kaspersky inyectado. Esto significa en lenguaje sencillo que cualquier sitio web puede simplemente leer el ID de Kaspersky del usuario y utilizarlo indebidamente para el seguimiento».
Ronald Eikenberg
Eikenberg informó de sus hallazgos a Kaspersky, quien reconoció el problema y lo parcheó el mes pasado asignando un valor constante (FD126C42-EBFA-4E12-B309-BB3FDDD723AC1) para todos los usuarios en lugar de utilizar UUID en la URL JavaScript.
«Kaspersky ha corregido un problema de seguridad (CVE-2019-8286) en sus productos que podría comprometer potencialmente la privacidad del usuario al utilizar el identificador único del producto que era accesible a terceros», explica la compañía en su aviso.
Sin embargo, la función de Kaspersky URL
Advisor todavía permite a los sitios web y servicios de terceros averiguar si
un visitante tiene software de Kaspersky instalado en su sistema, lo que el
investigador cree que puede ser abusado por estafadores y ciberdelincuentes
indirectamente.
Las versiones actualizadas de los productos
Kaspersky Antivirus, Internet Security, Total Security, Free Antivirus y Small
Office Security ya han sido entregadas a los usuarios afectados.
Sin embargo, los usuarios que deseen desactivar por completo este seguimiento pueden desactivar manualmente la función del URL Advisor desde settings→ additional→ network→ desmarcar la casilla de procesamiento de tráfico, como se muestra en la siguiente captura de pantalla.
La puerta trasera no se debe a un fallo de codificación por parte de los responsables de Webmin, sino que fue inyectada maliciosamente por un anónimo y persistió durante varias versiones a lo largo de más de un año en los repositorios de SourceForge, de donde era descargada por millones de usuarios.
Logotipo de la aplicación Webmin
Hace una semana, se filtró al público una vulnerabilidad crítica zero-day en Webmin. Hoy sabemos, gracias a los responsables del mantenimiento del proyecto, que el fallo de seguridad no responde a un error de programación por parte de los desarrolladores, sino que un atacante anónimo consiguió inyectar la puerta trasera en algún punto de la infraestructura. Para colmo, la puerta trasera sobrevivió a varias actualizaciones de Webmin (concretamente, desde la 1.882 hasta la 1.921) permaneciendo oculta durante al menos un año, tiempo durante el que pudo ser descargada por millones de usuarios, dado que Webmin es considerada la aplicación open-source más popular para la gestión de sistemas UNIX a través de interfaz web.
La historia del caso apunta a Özkan Mustafa Akkuş. En su perfil público se le relaciona con una empresa de ciberseguridad Turca y se define a sí mismo como investigador. Sin embargo, contraviniendo las buenas prácticas que regulan el proceso de investigación sobre seguridad informática y publicación de vulnerabilidades, decidió unilateralmente, según la versión de Joe Cooper, desarrollador del proyecto, publicar el hallazgo sin tomar las medidas oportunas para prevenir al fabricante acerca del fallo, lo que en la práctica, supone haber puesto en riesgo a toda la comunidad de usuarios. Adicionalmente, Akkus también publicó un módulo de Metasploit para automatizar la explotación de dicho fallo.
Según el propio Akkus, el fallo de seguridad radica en la página de reseteo de contraseña, que permite a un atacante remoto y no autenticado ejecutar comandos de forma arbitraria, con permisos de administrador, en todos aquellos sistemas afectados por este fallo. La explotación sería posible simplemente añadiendo una «tubería» (|) en el campo «old password» a través de peticiones post. Un carácter que, típicamente, sirve para dirigir la salida de un determinado comando para ser procesado por otro inmediatamente subsiguiente.
En un artículo publicado por Joe cooper, desarrollador del proyecto, se explica que aún continúan investigando cómo y cuándo se introdujo la backdoor, pero ya se ha podido confirmar que el ataque incluyó la suplantación de las descargas de Webmin oficiales, que fueron sustituidas por paquetes troyanizados en los repositorios de SourceForge. Los repositorios oficiales de Webmin en Github, sin embargo, permanecieron intactos y no fueron afectados por este ataque.
Además, Cooper incide en que la característica que aprovecha este fallo de seguridad no se encuentra por defecto habilitada, por lo que el impacto de este fallo se reduce a sólo aquellos sistemas que tuvieran manualmente habilitada la característica en cuestión – a saber, una característica situada en el menú de configuración de la autenticación, que permitía alertar a los usuarios cuya contraseña había expirado y ofrecerles la posibilidad de renovarla-.
Más tarde, un investigador reveló que el fallo afectaba a versiones más antiguas de lo esperado, detectando, adicionalmente, que se había conseguido modificar el código fuente de los paquetes para que la característica antes mencionada se encontrase habilitada por defecto, a diferencia de la configuración que tenía en el código fuente original.
Si efectuamos una búsqueda en Shodan, podemos ver que la aplicación Webmin se encuentra accesible al público en más de 14,790 sistemas de todo el mundo, la mayoría localizados en Estados Unidos, Japón, Reino Unido, Rusia y Alemania.
Afortunadamente, los responsables del proyecto ya han eliminado la puerta trasera. Además, su última actualización también contiene los parches para las vulnerabilidades XSS que fueron descubiertas por otro investigador que sí informó al fabricante siguiendo las buenas prácticas recomendadas, lo que le valió para ser recompensado con una suma de dinero por su labor de bug bounty.
A finales de marzo de este mismo año Kaspersky informaba sobre un nuevo vector de ataque para los ciberdelincuentes. Se trata de los proveedores de servicios gestionados (MSP – Manage Service Provider), un objetivo que puede llegar a ser muy lucrativo.
En especial, el ransomware Sodin (también conocido como Sodinokibi y REvil) ha dado muchos quebraderos de cabeza a diferentes expertos en el mundo de la seguridad. Sodin aprovechó una vulnerabilidad en servidores Oracle WebLogic para introducirse en los sistemas de los MSP y, además, no es necesaria la participación del usuario para activarse.
Propagación de Sodin
Los atacantes aprovecharon la vulnerabilidad CVE-2019-2725 para ejecutar un comando en PowerShell en un servidor de Oracle WebLogic y cargar un dropper (Software diseñado para instalar algún tipo de malware) que, más tarde, instalaría el ransomware Sodin.
En abril, Oracle lanzó los parches para corregir la vulnerabilidad de la que hablamos más arriba, pero a finales de junio se descubrió la vulnerabilidad CVE-2019-2729, similar a la anterior.
En algunos casos los atacantes utilizaron las consolas de acceso en remoto Webroot y Kaseya para enviar el troyano. En otros casos los atacantes consiguieron penetrar en la infraestructura de los MSP mediante una conexión RDP y descargaron el ransomware en los ordenadores de los clientes.
Esquema criptográfico
Sodin utiliza un esquema híbrido para cifrar los archivos. el contenido del archivo es cifrado mediante el algoritmo salsa20, y las claves con un algoritmo asimétrico de curva elíptica.
Generación de la clave
La configuración de Sodin contiene el campo pk, que se guarda en el registro con el nombre sub_key; esta es la clave pública de 32 bytes del distribuidor del troyano.
cuando se ejecuta, el troyano genera un nuevo par de claves de sesión. la clave pública se guarda en el registro con el nombre pk_key, mientras que la clave privada se cifra usando el algoritmo ECIES, con la clave sub_key y se almacena en el registro con el nombre sk_key.
La misma clave de sesión privada también se cifra con otra clave pública codificada en el cuerpo del troyano. El resultado del cifrado se almacena en el registro con el nombre 0_key.
Si alguien conoce la clave privada correspondiente a la clave con la que se ha cifrado 0_key, puede descifrar los archivos de la víctima, incluso sin la clave privada para sub_clave. Todo indica que los desarrolladores del troyano crearon una forma de descifrar archivos a espaldas de los distribuidores.
fragmento del procedimiento de generación y almacenamiento
Cifrado de archivos
Durante el cifrado de cada archivo se genera un nuevo par de claves asimétricas, file_pub y file_priv. A continuación se calcula el SHA3-256 y el resultado se utiliza como clave simétrica para cifrar el contenido del archivo con el algoritmo Salsa20.
Además de los datos descritos anteriormente también se encuentra un archivo para la inicialización del cifrado Salsa20.
Los archivos cifrados reciben una nueva extensión arbitraria, la nota de rescate se guarda junto a los archivos cifrados y el fondo de pantalla generado por el malware se configura en el escritorio.
fondo de pantallademandas de los delincuentes
Como podemos ver, se está consiguiendo un grado muy alto de especialización y sofisticación por parte de los desarrolladores de malware que, a día de hoy, pone a prueba a los analistas de todo el mundo.
El Banco Central Europeo ha confirmado que ha sido víctima de un ciberataque exponiendo información de contacto de sus subscriptores
Con sede en Alemania, el BCE es el banco central de los 19 países europeos que han adoptado el euro como moneda única y es el responsable de supervisar las políticas de protección de los sistemas bancarios de estos países.
A través de un comunicado publicado el jueves, el BCE informó de una brecha de seguridad producida en la web de su sistema BIRD (Banks’ Integrated Reporting Dictionary – Banco Internacional de Reconstrucción y Desarrollo), que estaba alojada en un proveedor diferente al resto de la infraestructura del Banco Central.
Lanzado en 2015, BIRD es la institución del Banco Mundial encargada de la financiación, asistencia y apoyo a las economías del Segundo Mundo o economías en proceso de desarrollo.
En el momento de escribir esta noticia, la web de BIRD muestra un aviso a los visitantes indicando que el sitio está caído por labores de mantenimiento.
Según la agencia Reuters, hay evidencias de que el sitio web de BIRD fue comprometido en diciembre de 2018, aunque la brecha de seguridad ha sido descubierta la pasada semana durante una labor de mantenimiento rutinaria.
Los atacantes instalaron malware en la máquina que aloja BIRD para hospedar software de phishing, lo que les pudo haber permitido robar información de emails, nombres y cargos laborales de 481 subscriptores.
El BCE asegura que la información robada no contiene contraseñas y que sus sistemas internos no se han visto afectados ya que la infraestructura de BIRD está físicamente separada del resto de sistemas críticos.
Esta no es la primera vez que el BCE se ve afectado por una brecha de seguridad; En 2014, unos atacantes desconocidos lograron comprometer la base de datos asociada al sitio web principal del Banco Central, exponiendo los datos de contacto de las personas registradas a los eventos celebrados por el Banco Central.
El investigador de seguridad Vasily Kravets ha hecho público un nuevo «día cero» en la popular plataforma de juegos Steam, que permite escalar privilegios en sistemas Windows.
Kravets ya fue noticia el pasado 17 de agosto por el descubrimiento de otra vulnerabilidad que permitía escalar privilegios a través de Steam, la cual reportó a la compañía a través de su programa de «bug bounty». Sin embargo, Valve prohibió a Kravets el acceso a su sistema de recompensas.
Por este motivo, Vasily Kravets ha revelado públicamente esta otra vulnerabilidad a la cual se le ha asignado el identificador CVE-2019-15316.
A continuación se explican los detalles técnicos sobre la explotación. Ésta consta de tres fases:
Primera fase: preparación del entorno
El primer paso será adaptar la estructura de ficheros de Steam. Nuestro objetivo será tener el ejecutable «Steam.exe» y «steamclient.dll» en una misma carpeta, sin la carpeta «bin». Esto podemos conseguirlo de dos formas:
Método 1: Renombrar/eliminar la carpeta «bin» de la raíz de Steam.
Método 2: Cambiar el parámetro «InstallPath» en la clave de registro «HKLM\SOFTWARE\Wow6432Node\Valve\steam» y mover «Steam.exe» y «steamclient.dll» al nuevo path elegido.
Una vez tenemos la estructura de ficheros deseada, necesitamos crear las carpetas «b1», «b2», «b3», «b4» en ese mismo directorio. Copiaremos «steamservice.dll» en «b1», «b2» y «b3» y colocaremos nuestra versión manipulada de la DLL en «b4».
Segunda fase: intercambiar el fichero
Registro de ejecución de Steam Client. Fuente: amonitoring.ru
En la captura de pantalla puede verse el registro del servicio «Steam Client» legítimo. En la parte señalada puede observarse cómo la DLL es leída y copiada a la carpeta «C:\Program Files (x86)\Common Files\Steam» para posteriormente ser leída. Este mecanismo será el que utilicemos para copiar la librería modificada.
A continuación se detallan los pasos necesarios para provocar la condición de carrera de tipo TOCTOU (TIME OF CHECK TO TIME OF UPDATE) necesaria para evadir a los mecanismos anti-secuestro implementados en el cliente Steam.
Creamos la carpeta «bin» dentro de nuestra estructura de ficheros y ejecutamos el siguiente comando desde la consola: CreateMountPoint.exe С:\{DIRECTORIO_PREPARADO}\bin C:{DIRECTORIO_PREPARADO}\b1
En la primera terminal hacemos SetOpLock.exe C:\{DIRECTORIO_PREPARADO}\b1\steamservice.dll
Ejecutamos el servicio «Steam Client»
Eliminamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin, creamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin (mismo nombre y lugar) y ejecutamos lo siguiente en una segunda terminal: CreateMountPoint.exe С:\{DIRECTORIO_PREPARADO}\bin C:\{DIRECTORIO_PREPARADO}\b2
En la segunda terminal hacemos: SetOpLock.exe C:\{DIRECTORIO_PREPARADO}\b2\steamservice.dll
Liberamos el «oplock» de la primera terminal.
Eliminamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin, creamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin (mismo nombre y lugar) y ejecutamos lo siguiente en la primera terminal: CreateMountPoint.exe С:\{DIRECTORIO_PREPARADO}\bin C:\{DIRECTORIO_PREPARADO}\b3
En la primera terminal hacemos: SetOpLock.exe C:\{DIRECTORIO_PREPARADO}\b3\steamservice.dll
Liberamos el «oplock» de la segunda terminal.
Eliminamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin, creamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin y ejecutamos lo siguiente en una segunda terminal: CreateMountPoint.exe С:\{DIRECTORIO_PREPARADO}\binC:{DIRECTORIO_PREPARADO}\b2
En la segunda terminal ejecutamos: SetOpLock.exe C:\{DIRECTORIO_PREPARADO}\b2\steamservice.dll
Liberamos el «oplock» de la primera terminal.
Eliminamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin, creamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin y ejecutamos lo siguiente en una segunda terminal: CreateMountPoint.exe С:\{DIRECTORIO_PREPARADO}\bin C:{DIRECTORIO_PREPARADO}\b3
En la primera terminal ejecutamos: SetOpLock.exe C:\{DIRECTORIO_PREPARADO}\b3\steamservice.dll
Liberamos el «oplock» de la segunda terminal.
Eliminamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin, creamos la carpeta С:\{DIRECTORIO_PREPARADO}\bin y ejecutamos lo siguiente en una segunda terminal: CreateMountPoint.exe С:{DIRECTORIO_PREPARADO}\bin C:{DIRECTORIO_PREPARADO}\b4
Eliminamos el «oplock» de la primera terminal.
Lo que intentamos hacer es redirigir los primeros 5 accesos al archivo original y en el sexto dar el cambiazo hacia nuestra DLL manipulada.
En el siguiente esquema puede verse el flujo normal a la izquierda y a la derecha el comportamiento modificado para nuestra explotación.
Flujo de la carga de la DLL. Fuente: amonitoring.ru
Fase 3: modificar la librería inyectable
Tras realizar ingeniería inversa sobre el servicio «Steam Client», Kravets determinó el punto en el que colocar el «payload», este es, la función «int WINAPI SteamService_RunMainLoop()». Cuya existencia es requerida por el servicio para su funcionamiento.
Kravets también ha compartido dos pruebas de concepto en su página web que ilustran lo explicado anteriormente:
Silence APT , un grupo de cibercriminales de habla rusa, conocido por atacar organizaciones financieras, principalmente en los antiguos estados soviéticos y países vecinos, está ahora atacando agresivamente a bancos en más de 30 países de América, Europa, África y Asia.
Activo desde al menos 2016, este grupo ha ido modificando su forma de operar hasta que, a día de hoy, se le considera uno de los grupos de amenazas persistentes (APT) más sofisticados del mundo. Silence APT ha actualizado su TTP único (tácticas, técnicas y procedimientos) convirtiéndose en una amenaza a nivel global.
«Además, el grupo ha reescrito completamente el cargador TrueBot, el módulo de primera etapa, del cual depende el éxito de todo el ataque. Los ciberdelincuentes también comenzaron a usar Ivoke, un cargador sin archivos y un agente EDA, ambos escritos en PowerShell».
Investigador del Grupo IB
EDA es un agente de PowerShell diseñado para controlar sistemas comprometidos mediante la realización de tareas a través de línea de comandos y el tráfico mediante el protocolo DNS. Está basado en los proyectos Empire y dnscat2.
Al igual que la mayoría de los grupos de cibercriminales, Silence también utiliza correos electrónicos de phishing con Docs adjuntos los cuales contienen exploits en sus macros.
Para elegir sus objetivos, el grupo crea primero una «lista de posibles objetivos» unida a una lista actualizada de correos de sus trabajadores, la cual consiguen mediante «correos electrónicos de reconocimiento».
«Estas campañas ya no se centraron solo en Rusia y los antiguos países soviéticos, sino que se extendieron por Asia y Europa. Desde nuestro último informe público, Silence ha enviado más de 170,000 correos electrónicos de reconocimiento a bancos en Rusia, la ex Unión Soviética, Asia y Europa.»
Informe público de los investigadores
Los investigadores del Grupo IB no compartieron los nombres de los bancos a los que apuntó Silence APT, pero dijeron que el grupo atacó con éxito a los bancos en India (en agosto de 2018), Rusia (en febrero de 2019, el «Banco de TI» ruso), Kirguistán (en mayo de 2019 ), Rusia (en junio de 2019) y Chile, Ghana, Costa Rica y Bulgaria (en julio de 2019).
Se recomienda a todas las organizaciones financieras reforzar sus protocolos de seguridad para no ser víctima de estos ataques.
Se ha hecho pública una vulnerabilidad en Bitdefender Antivirus Free 2020 que podría permitir la ejecución de código arbitrario con privilegios de SYSTEM.
Cuando se inician el ‘Servicio de actualización de BitDefender’ (updatesrv.exe) y el ‘Servicio de seguridad de BitDefender’ (vsserv.exe), se carga la biblioteca ServiceInstance.dll. Esta intenta a su vez cargar la biblioteca RestartWatchDog.dll a través de la función ‘LoadLibraryW’.
El fallo de seguridad se encuentra en este punto y es causado por la existencia de una ruta de búsqueda no controlada en la biblioteca ServiceInstance.dll, y por la falta de validación de certificado digital contra el binario, es decir que no se comprueba si la DLL que se está cargando está firmada o no. Esto podría permitir la carga de código malicioso en una DLL que, además, se ejecutaría como SYSTEM(la cuenta de usuario con mayores privilegios en el sistema).
Además, hay que considerar la persistencia una vez logrado explotar la vulnerabilidad ya que, como se ha comentado anteriormente, el intento de carga de la DLL se realiza cada vez que se inician los servicios de BitDefender Antivirus Free 2020.
La vulnerabilidad, a la que se ha asignado el identificador CVE-2019-15295, fue descubierta por Peleg Hadar, investigador de seguridad de la empresa Safebreach, reportada a Bitdefender el pasado 17 de julio, y confirmada por Bitdefender el 14 de agosto. No se ha hecho pública hasta el momento para permitir que la empresa pudiese corregir el error de seguridad y lanzar una versión de su antivirus gratuito exenta del problema, la 1.0.15.138.
Se encuentran afectadas las versiones 1.0.15.119 y anteriores de Bitdefender Antivirus Free 2020, por lo que se recomienda actualizar a la última versión disponible.
Un prolífico hacker que llevó a cabo estafas de phishing contra cientos de empresas de todo el mundo ha recibido la orden de devolver más de 1,1 millones de dólares (más de 922.000 libras esterlinas) en criptomonedas a sus víctimas.
Grant West, un residente de 27 años de
Kent, Inglaterra, tomó como objetivo a varias empresas conocidas de
todo el mundo desde 2015 para obtener los datos financieros de
decenas de miles de clientes y luego los vendió en foros
clandestinos a cambio de Bitcoins u otras criptomonedas.
West, que operaba bajo el apodo en
línea de ‘Courvoisier’, escondió las criptomonedas resultantes en
múltiples cuentas y ‘wallets’, que fueron confiscadas por la
policía metropolitana tras el arresto de West en septiembre de 2017
tras una investigación de dos años de duración denominada
‘Operación Draba’.
La Unidad de Delitos Cibernéticos de la Policía Metropolitana (MPCCU) también incautó una tarjeta SD de la casa de West, que contenía aproximadamente 78 millones de nombres de usuario y contraseñas individuales, así como 63.000 datos de tarjetas de crédito y débito.
Las autoridades también recuperaron
una computadora portátil que West utilizó para llevar a cabo
ataques de phishing que contenían información financiera personal
de más de 100.000 personas en un archivo conocido como «fullz».
El portátil en realidad pertenecía a la novia de West.
Tras la investigación, los detectives
encontraron pruebas de que West llevó a cabo estafas de phishing en
los sitios web de 17 grandes empresas, entre ellas Uber, Sainsbury’s,
Nectar, Groupon, T Mobile, AO.com, Argos, la bolsa finlandesa de
Bitcoin, la British Cardiovascular Society, Truly Experiences Ltd y M
R Porter.
En una de sus estafas, West se hizo
pasar por el servicio de entrega de alimentos «Just Eat»,
entre julio y diciembre de 2015, en un intento de robar la
información financiera de 165.000 clientes. Aunque no pudo obtener
ningún dato financiero de sus clientes, el ataque le costó a la
empresa aproximadamente 200.000 libras esterlinas.
Además de esto, West también ganaba dinero vendiendo cannabis que enviaba a sus clientes a través de la Dark Web. También proporcionaba guías «how-to» que instruían a otros estafadores en línea sobre cómo llevar a cabo ataques cibernéticos.
En el momento de su detención, los fondos confiscados de las múltiples cuentas y wallets de West ascendían a unos 1,6 millones de libras esterlinas, pero el valor fluctuante de Bitcoin y otras monedas digitales redujo los fondos confiscados a 922.978,14 libras esterlinas.
West fue encarcelado el 25 de mayo en
el Tribunal de Southwark Crown, la pena es de 10 años y ocho meses
por 10 cargos de delitos penales, incluidos dos cargos de
conspiración para cometer fraude y dos cargos de posesión de bienes
criminales.
Ahora, justo hoy, el juez del Tribunal
de Southwark Crown concedió la confiscación de sus fondos
(£922,978.14) en virtud de la Ley de los Activos del Crimen y le
dijo a West que si rechazaba la orden de confiscación, cumpliría
otros cuatro años, dijo el Servicio de Policía Metropolitana (MPS)
en una declaración publicada hoy.
«Ahora se venderá la ‘criptocurrency‘ y las víctimas recibirán una indemnización por los daños causados por el crimen organizado cometido por West«, dijo el MPC.
El Jefe de la MPCCU, Detective Inspector Jefe Kirsty Goldsmith, dijo: «El MPS está comprometido a asegurar que los individuos que cometen crímenes en la Dark Web sean identificados, procesados, y sus bienes criminales sean confiscados.»
