El Banco Central Europeo cierra el portal «BIRD» tras sufrir un ataque
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.
Más Información:
Sodin, el ransomware que se aprovecha de los MSP
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 undropper (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 vulnerabilidadCVE-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ónRDP 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.
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.
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.
Más información:
Distribución de Phishings a través de servicios legítimos
Investigadores de ProofPoint han descubierto una nueva campaña de phishingque utiliza AWS (Amazon Web Services) para alojar las webs fraudulentas.
Distribución de Phishings a través de servicios legítimos
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 phishing y 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.
Más información:
Ataque de ransomware vía RDP afecta a las PYMES
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.
Más información:
Descubierta vulnerabilidad que permite manipular pequeñas avionetas
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.
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.
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.
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
Más información:
ICS Alert (ICS-ALERT-19-211-01)
https://www.us-cert.gov/ics/alerts/ics-alert-19-211-01
Investigating CAN Bus Network Integrity in Avionics Systems
https://www.rapid7.com/research/report/investigating-can-bus-network-integrity-in-avionics-systems/
Vulnerabilidad en ElasticSearch: bases de datos convertidas en Botnet «Zombies»
ElasticSearch, un motor de análisis con el que se pueden realizar búsquedas muy rápidas, escrito en Java y partícipe de la filosofía del desarrollo de código abierto, se ha convertido en uno de los objetivos de los cibercriminales en la actualidad debido al aumento de su popularidad. Recientemente se ha descubierto una nueva vulnerabilidad que compromete su funcionamiento: la transformación de sus bases de datos en botnets destinadas a realizar ataques de denegación de servicios distribuidos (DDoS). Este ataque es realizado a partir del malware Setag, con trazas del malware BillGates, descubierto por primera vez en 2014.
Para llevar a cabo el ataque, el malware se aprovecha de las bases de datos o servidores de ElasticSearch que, o bien son públicos, o han sido expuestos. El ataque es realizado en dos fases diferentes:
1ª FASE: el dropper ejecuta el script s67.sh, el cual define qué shell usar y dónde encontrarla, tratando posteriormente de deshabilitar el firewall. Se descargará entonces un segundo script (s66.sh) usando el comando curl (o wget en caso de que el comando curl no funcione).
Fuente la imagen: Trend Micro
2ª FASE: el segundo script descargado también define qué shell usar y deshabilita el firewall del sistema. En cambio, este script eliminará algunos archivos posiblemente relacionados con la minería de criptomonedas, así como otros de configuración almacenados en el directorio /tmp. Después el script matará algunos de estos procesos que tienen que ver con la minería de criptomonedas, entre otros. El siguiente paso será eliminar los rastros de la infección inicial y matar procesos que tienen lugar en puertos TCP. En esta segunda etapa también se descargan los binarios.
Fuente de la imagen: Trend Micro
Fuente de la imagen: Trend Micro
Los atacantes hacen uso de dominios desechables, ya que éstos permiten cambiar las URLs cuando son detectadas. Además, el uso de sitios web comprometidos también permite al atacante evadir cierto tipo de detecciones. Estas páginas web comprometidas contienen el payload a descargar.
Fuente de la imagen: Trend Micro
En cuanto a los binarios, Trend Micro detectó una backdoor variable que roba información sobre el sistema y que tiene la capacidad de iniciar ataques DDoS. Estas muestras contienen rasgos característicos del malware BillGates, aparecido por primera vez en 2014 y conocido por provocar secuestros de sistemas y ataques DDoS, funcionalidades que también se encuentran en Setag. El payload cuenta con código que previene acciones de debugging y además revisa si el archivo ha sido manipulado. Este malware también reemplaza las herramientas de sistema afectadas con una copia propia y las transfiere al directorio /usr/bin/dpkgd. Para lograr la persistencia se ejecuta un script que crea una copia de sí mismo en las siguientes rutas:
- /etc/rc{1-5}.d/S97DbSecuritySpt
- /etc/rc{1-5}.d/S99selinux
- /etc/init.d/selinux
- /etc/init.d/DbSecuritySpt
1. Anti-debugging (arriba a la izquierda)
2. Ejecución en etapas múltiples (arriba en el centro)
3. Tipos de ataques DDoS (arriba a la derecha)
4. Lista de herramientas que reemplaza (abajo)
Fuente de la imagen: Trend Micro
Como conclusión, se recomienda a cualquier empresa que use ElasticSearch que esté al tanto de las posibles vulnerabilidades que vayan apareciendo, y que de la misma forma implementen el parche publicado por ElasticSearch para solucionar el problema actual.
Más información
New malware attack turns Elasticsearch databases into DDoS botnet
¿Qué es y cómo funciona Elasticsearch?
Investigadores de ‘Project Zero’ publican exploits remotos para iOS
Los investigadores han publicado finalmente pruebas de concepto detalladas de exploits que podrían aprovechar de forma remota vulnerabilidades existentes en el código de iOS de Apple a través de un mensaje especialmente elaborado y enviado vía iMessage.
Según las pruebas de concepto, la explotación de algunas de estas vulnerabilidades no requeriría de intervención alguna por parte del usuario, lo que eleva la clasificación del riesgo de estas brechas. Todas fueron reportadas a Apple por Samuel Gross y Natalie Silvanovich, miembros de Project Zero. La compañía parcheó las vulnerabilidades la semana pasada con su actualización 12.4 para iOS.
De esas vulnerabilidades descubiertas, al menos cuatro no requieren de intervención alguna del usuario y tendrían que ver con fallos de corrupción de memoria que tienen lugar cuando se intenta acceder a la misma una vez ha quedado liberada. Este fallo podría, según los investigadores, permitir la ejecución de código arbitrario en aquellos dispositivos iOS afectados.
Los investigadores, sin embargo, aún no han publicado todas las vulnerabilidades descubiertas. Dado que una de ellas (CVE-2019-8641) no ha sido mitigada en la última actualización, el equipo de Project Zero ha decidido mantenerla en privado por ahora.
Otra de las vulnerabilidades, catalogada como CVE-2019-8646, responde a un fallo de tipo ‘lectura fuera de límites’ que puede ser aprovechado de forma remota simplemente mediante el envío de un mensaje vía iMessage. Pero, en vez de la ejecución de código arbitrario, este fallo permite la lectura del contenido de archivos guardados en el dispositivo iOS de la víctima, gracias a la filtración de memoria.
A continuación enumeramos las vulnerabilidades publicadas y los enlaces asociados a cada una de ellas:
- CVE-2019-8647 (Ejecución remota de código vía iMessage)
- CVE-2019-8662 (Ejecución remota de código vía iMessage)
- CVE-2019-8660 (Ejecución remota de código vía iMessage)
- CVE-2019-8646 (Lectura de archivos vía iMessage)
Dado que ya han sido publicadas pruebas de concepto que explotan con éxito estos fallos, es muy recomendable la actualización de todos los dispositivosiOS, ya sean iPhone, iPad o iPod a la última actualización para iOS 12.4.
Ataque basado en tiempo permite saber si estás usando el modo incógnito de Chrome
La API del sistema de archivos de Chrome es mucho más rápida en modo incógnito, lo que permite conocer si se está utilizando este modo.
A partir de la versión 76 de Google Chrome se añadió como novedad una implementación de la API FileSystem (API de Sistema de Archivos) para el modo incógnito. Esta novedad se incluyó para prevenir que los sitios web pudiesen saber si este modo estaba en uso en función de la disponibilidad de esta API.
No obstante, la implementación que realiza no escribe a disco como es habitual, sino a memoria. Estas escrituras resultan mucho más rápidas yestables, lo que permite diferenciar fácilmente si el modo incógnito está en uso. Además, en esta modalidad la cuota de disco asignada es mucho menor, lo que ayuda a diferenciarlo.
El problema ya era conocido desde 2018 por los mismos desarrolladores de Chrome, proponiendo como alternativa cifrar los datos a disco y mantener los metadatos en memoria. No obstante, tal y como sugiere el investigador Jesse Li, que ha realizado esta investigación, cifrar los datos a disco dejaría evidencias para el resto de usuarios del sistema de que se está usando el modo incógnito por la mera existencia de estos ficheros cifrados y su tamaño.
El investigador ha publicado una Prueba de Concepto (PoC) para que cualquiera pueda comprobar en su máquina los resultados de su estudio, la cual también cuenta con una demo en su sitio web.
Más información:
Detecting incognito mode in Chrome 76 with a timing attack:
https://blog.jse.li/posts/chrome-76-incognito-filesystem-timing/
chrome-filesystem-timing:
https://github.com/veggiedefender/chrome-filesystem-timing
Demo:
https://jse.li/chrome-filesystem-timing/
+54 11 7078-0111
+54 911 7013-0298
Comments are closed.