Newsletter - 2024-35
Tabla de Contenidos
SonicWall Actualiza su Firmware para Corregir Vulnerabilidad Crítica
| Categoría | Seguridad Informática |
| Nombre vulnerabilidad | CVE-2024-40766 |
| Brecha | Control de acceso inapropiado |
| Criticidad | Crítica (CVSS: 9.3) |
| Fuente | SonicWall |
SonicWall ha lanzado actualizaciones de seguridad para abordar una falla crítica que afecta sus firewalls, la cual, si se explota con éxito, podría otorgar a actores malintencionados acceso no autorizado a los dispositivos. La vulnerabilidad, rastreada como CVE-2024-40766 (puntuación CVSS: 9.3), ha sido descrita como un error de control de acceso inapropiado.
“Se ha identificado una vulnerabilidad de control de acceso inapropiado en el acceso de gestión de SonicWall SonicOS, que potencialmente podría llevar a un acceso no autorizado a recursos y, en condiciones específicas, causar el bloqueo del firewall,” dijo la compañía en un aviso publicado la semana pasada.
“Este problema afecta a los dispositivos SonicWall Firewall Gen 5 y Gen 6, así como a los dispositivos Gen 7 que ejecutan SonicOS 7.0.1-5035 y versiones anteriores.”
El problema ha sido abordado en las siguientes versiones - SonicWall indicó que la vulnerabilidad no es reproducible en la versión de firmware SonicOS superior a 7.0.1-5035, aunque se recomienda a los usuarios instalar el firmware más reciente.
El proveedor de equipos de red no menciona que la falla haya sido explotada en la naturaleza. Dicho esto, es imperativo que los usuarios tomen medidas para aplicar rápidamente los parches y protegerse contra posibles amenazas.
Se insta a los consumidores que no puedan aplicar el parche de inmediato a restringir el acceso de gestión del firewall a fuentes confiables o deshabilitar el acceso de gestión WAN del firewall desde fuentes de Internet.
El año pasado, Mandiant, propiedad de Google, reveló que un presunto actor de amenazas con nexos en China, rastreado como UNC4540, apuntó a dispositivos SonicWall Secure Mobile Access (SMA) 100 sin parches para instalar Tiny SHell y establecer una persistencia a largo plazo.
Varios grupos de actividad vinculados a China han aumentado sus operaciones para enfocarse en la infraestructura de borde para violar objetivos y mantener el acceso remoto sin atraer atención.
Esto incluye un conjunto de intrusiones denominado Velvet Ant que fue descubierto recientemente aprovechando una explotación de día cero contra dispositivos Cisco Switch para propagar un nuevo malware llamado VELVETSHELL, una versión híbrida personalizada de Tiny SHell y 3proxy.
Observe cómo los expertos simulan amenazas del mundo real para demostrar ventajas convincentes. Obtenga pasos y herramientas accionables para aprovechar todo el potencial de GenAI mientras protege sus datos sensibles. Obtenga las últimas noticias, conocimientos de expertos, recursos exclusivos y estrategias de líderes de la industria, todo de forma gratuita.
NGate: Malware para Pago Sin Contacto en Android
| Categoría | Malware/Phishing |
| Nombre vulnerabilidad | NGate |
| Brecha | Captura y retransmisión de datos NFC |
| Criticidad | Alta |
| Fuente | The Hacker News |
Investigadores de ciberseguridad han descubierto un nuevo malware para Android que puede retransmitir los datos de pago sin contacto de las tarjetas de crédito y débito de las víctimas a un dispositivo controlado por el atacante con el objetivo de realizar operaciones fraudulentas.
La empresa de ciberseguridad eslovaca está rastreando el nuevo malware como NGate, indicando que observó la campaña de crimen cibernético dirigida a tres bancos en Chequia. El malware tiene la capacidad única de retransmitir datos de las tarjetas de pago de las víctimas, a través de una aplicación maliciosa instalada en sus dispositivos Android, al teléfono Android rooteado del atacante.
La actividad es parte de una campaña más amplia que ha estado dirigida a instituciones financieras en Chequia desde noviembre de 2023, utilizando aplicaciones web progresivas maliciosas (PWAs) y WebAPKs. El primer uso registrado de NGate fue en marzo de 2024.
El objetivo final de los ataques es clonar los datos de comunicación de campo cercano (NFC) de las tarjetas de pago físicas de las víctimas utilizando NGate y transmitir la información a un dispositivo atacante que luego emula la tarjeta original para retirar dinero de un cajero automático.
NGate tiene sus raíces en una herramienta legítima llamada NFCGate, desarrollada originalmente en 2015 con fines de investigación de seguridad por estudiantes del Laboratorio de Redes Móviles Seguras en TU Darmstadt.
Se cree que las cadenas de ataque implican una combinación de ingeniería social y phishing por SMS para engañar a los usuarios a instalar NGate dirigiéndolos a dominios de corta duración que imitan sitios web bancarios legítimos o aplicaciones de banca móvil oficiales disponibles en la tienda Google Play.
Hasta la fecha, se han identificado hasta seis aplicaciones diferentes de NGate entre noviembre de 2023 y marzo de 2024, cuando las actividades cesaron probablemente tras el arresto de un joven de 22 años por las autoridades checas en relación con el robo de fondos de cajeros automáticos.
Además de abusar de la funcionalidad de NFCGate para capturar el tráfico NFC y pasarlo a otro dispositivo, NGate solicita a los usuarios que ingresen información financiera sensible, incluidos el ID de cliente bancario, fecha de nacimiento y el código PIN de su tarjeta bancaria. La página de phishing se presenta dentro de un WebView.
“También les pide que activen la función NFC en su smartphone,” dijeron los investigadores. “Luego, se instruye a las víctimas que coloquen su tarjeta de pago en la parte posterior de su smartphone hasta que la aplicación maliciosa reconozca la tarjeta.”
Los ataques adoptan un enfoque insidioso en el que las víctimas, después de haber instalado la aplicación PWA o WebAPK a través de enlaces enviados por mensajes SMS, tienen sus credenciales phished y posteriormente reciben llamadas del actor de amenazas, quien finge ser un empleado del banco y les informa que su cuenta bancaria ha sido comprometida como resultado de instalar la aplicación.
Posteriormente, se les instruye a cambiar su PIN y validar su tarjeta bancaria utilizando una aplicación móvil diferente (es decir, NGate), cuyo enlace de instalación también se envía a través de SMS. No hay evidencia de que estas aplicaciones se distribuyeran a través de la tienda Google Play.
En una declaración compartida con The Hacker News, Google confirmó que no encontró ninguna aplicación que contuviera el malware en el mercado oficial de Android. La compañía también dijo que los usuarios están automáticamente protegidos contra las versiones conocidas de NGate por Google Play Protect, que está habilitado por defecto en dispositivos Android con Google Play Services, incluso cuando las aplicaciones se descargan de fuentes de terceros.
“NGate utiliza dos servidores distintos para facilitar sus operaciones,” explicaron los investigadores. “El primero es un sitio web de phishing diseñado para atraer a las víctimas a proporcionar información sensible y capaz de iniciar un ataque de retransmisión NFC. El segundo es un servidor de retransmisión NFCGate encargado de redirigir el tráfico NFC desde el dispositivo de la víctima al del atacante.”
Ataque del Grupo Qilin a Synnovis
| Categoría | Ransomware |
| Nombre vulnerabilidad | Robo de credenciales en Google Chrome |
| Brecha | Explotación del controlador de dominio |
| Criticidad | Alta |
| Fuente | Infosecurity Magazine |
El grupo de ransomware Qilin, responsable del reciente ataque a Synnovis, ha sido observado robando credenciales almacenadas en Google Chrome tras obtener acceso a la red de un objetivo. Investigadores de Sophos X-Ops detectaron esta actividad, la cual es inusual para los grupos de ransomware y podría multiplicar el caos inherente en situaciones de ransomware.
En el caso observado por Sophos, Qilin no solo realizó un ataque de extorsión, sino que también desplegó un esquema de recolección de credenciales. El grupo apuntó a los navegadores Google Chrome, que actualmente mantienen más del 65% del mercado de navegadores.
Una vez que el grupo alcanzó un controlador de dominio objetivo, editó la política de dominio predeterminada para introducir un Objeto de Política de Grupo (GPO) basado en inicio de sesión que contenía dos elementos. El primero, un script PowerShell llamado IPScanner.ps1, se escribió en un directorio temporal dentro del volumen compartido del sistema (SYSVOL) en el controlador de dominio específico involucrado. Este script intentaba recolectar datos de credenciales almacenados en el navegador Chrome. El segundo elemento, un script por lotes llamado logon.bat, contenía los comandos para ejecutar el primer script.
Esta combinación resultó en la recolección de credenciales guardadas en navegadores Chrome en máquinas conectadas a la red. Cada vez que alguien iniciaba sesión en un endpoint infectado, el logon.bat lanzaba el script IPScanner.ps1, creando dos archivos: un archivo de base de datos SQLite llamado LD y un archivo de texto llamado temp.log. Estos archivos se escribían de vuelta en un nuevo directorio creado en el volumen SYSVOL del dominio y se nombraban según el nombre del host del dispositivo en el que se ejecutaban. Todas las credenciales de los dispositivos se almacenaban en la base de datos LD.
Una vez que los archivos con las credenciales recolectadas eran robados y exfiltrados, el atacante eliminaba todos los archivos y limpiaba los registros de eventos tanto del controlador de dominio como de las máquinas infectadas, luego encriptaba los archivos y dejaba la nota de rescate. Sophos detectó el esquema porque Qilin, “en una demostración de confianza en que no serían atrapados o perderían su acceso a la red”, dejó el GPO activo en la red durante más de tres días.
Un compromiso exitoso de este tipo significaría que no solo los defensores deben cambiar todas las contraseñas de Active Directory; también deberían (en teoría) solicitar que los usuarios finales cambien sus contraseñas para docenas, potencialmente cientos, de sitios de terceros donde los usuarios han guardado sus combinaciones de nombre de usuario y contraseña en el navegador Chrome. Si ellos, u otros atacantes, deciden también extraer credenciales almacenadas en los endpoints, podría abrirse un nuevo capítulo oscuro en la historia continua del cibercrimen.
Para mitigar este tipo de ataque de recolección de credenciales del navegador, Sophos recomendó las siguientes medidas:
Un grupo de extorsión aprovecha la desconfiguración de la nube para atacar 110.000 dominios
| Categoría | Ciberseguridad en la Nube |
| Nombre vulnerabilidad | Exposición de archivos de variables de entorno (.env) |
| Brecha | Exposición pública de información sensible como credenciales de AWS |
| Criticidad | Alta |
| Fuente | Palo Alto Networks’ Unit 42 |
Un grupo de actores maliciosos, utilizando técnicas avanzadas de automatización y un amplio conocimiento de la arquitectura en la nube, llevó a cabo una campaña de extorsión que apuntó a 110,000 dominios. Los atacantes obtuvieron archivos de variables de entorno (.env) expuestos públicamente, que contenían credenciales válidas de Amazon Web Services (AWS).
Los archivos .env contenían información sensible, como credenciales pertenecientes a varias aplicaciones encontradas en servidores web mal configurados. Los investigadores de la unidad de inteligencia de amenazas Unit 42 de Palo Alto Networks indicaron que los atacantes explotaron configuraciones incorrectas en las organizaciones víctimas que expusieron sus archivos .env. No hubo vulnerabilidades ni configuraciones incorrectas en los servicios de AWS.
La operación de extorsión configuró su infraestructura de ataque en los entornos AWS de las organizaciones, utilizando estos para escanear más de 230 millones de objetivos únicos en busca de información sensible. La campaña resultó en la identificación de más de 90,000 variables únicas en los archivos .env, de las cuales 7,000 pertenecían a servicios en la nube de las organizaciones y 1,500 estaban vinculadas a cuentas en redes sociales.
Los atacantes no cifraron los archivos sensibles encontrados, sino que los exfiltraron y luego plantaron una nota de rescate en el contenedor de almacenamiento en la nube comprometido. El uso de técnicas extensivas de automatización indica que estos grupos de actores maliciosos son hábiles y conocen bien los procesos y técnicas avanzadas de arquitectura en la nube.
Los investigadores de Unit 42 señalaron varios problemas de seguridad, incluyendo la exposición de variables de entorno y el uso de credenciales de larga duración, además de no implementar una arquitectura de privilegios mínimos.
Un portavoz de AWS afirmó que ni los servicios ni la infraestructura de AWS se vieron afectados por los hallazgos de los investigadores. Los problemas descritos en el blog fueron resultado de un actor malicioso que abusó de aplicaciones web mal configuradas que permitían el acceso público a archivos de variables de entorno. Estos archivos contenían varios tipos de credenciales, incluidas las de AWS, que luego fueron utilizadas para llamar a las APIs de AWS.
Para protegerse de tales amenazas, los investigadores recomendaron el uso de roles de IAM que actúan como claves de acceso temporales, seguir el principio de privilegio mínimo al otorgar permisos y desactivar regiones no utilizadas dentro de una cuenta de AWS.
Comprobación de la seguridad de las aplicaciones
| Categoría | Seguridad de Aplicaciones |
| Nombre vulnerabilidad | Actualización de seguridad |
| Brecha | Usuarios |
| Criticidad | Media |
| Fuente | The Home of the Security Bloggers Network |
Este artículo proporciona una serie de preguntas y recomendaciones para evaluar y mejorar la seguridad de aplicaciones (AppSec) en las organizaciones. Incluye preguntas sobre el desarrollo de software interno, el enfoque en la seguridad de aplicaciones, los desafíos en la implementación de una estrategia robusta de AppSec, y las prácticas de DevSecOps utilizadas.
Entre los principales desafíos identificados se encuentran la falta de presupuesto, personal capacitado insuficiente, la complejidad de integrar la seguridad en el ciclo de vida del desarrollo, la resistencia de los equipos de desarrollo y mantener el ritmo con las amenazas de seguridad en evolución.
Las prácticas recomendadas incluyen pruebas automatizadas de seguridad de aplicaciones (AST), gestión de secretos para evitar almacenar secretos en repositorios de código fuente, y la revisión manual de código por especialistas en seguridad. Además, se subraya la importancia de la capacitación en seguridad para los desarrolladores y la evaluación continua del riesgo en aplicaciones no desarrolladas activamente.
Para determinar el nivel de inversión en AppSec, se sugiere basarse en el riesgo percibido y el panorama de amenazas, los puntos de referencia y estándares de la industria, los patrones históricos de gasto y las recomendaciones de terceros.