CISCO ha confirmado que está investigando una supuesta infracción de datos, después de que un actor de amenazas comenzara a venderlos en un conocido foro de hacking.
“Cisco está al tanto de los informes de que un actor alega haber obtenido acceso a ciertos archivos relacionados con Cisco”, dijo un portavoz de Cisco a BleepingComputer. “Hemos iniciado una investigación para evaluar esta afirmación y nuestra investigación está en curso”.
Esta declaración se produce después de que un conocido actor de amenazas llamado “IntelBroker” dijera que él y otros dos actores llamados “EnergyWeaponUser” y “zjj” ingresaron a redes de Cisco el pasado 6 de octubre de 2024 y robaron una gran cantidad de datos de desarrolladores de la empresa.
(Supuestos) datos comprometidos: proyectos Github, proyectos Gitlab, proyectos SonarQube, código fuente, credenciales codificadas, certificados, SRC de clientes, documentos confidenciales de Cisco, tickets de Jira, tokens API, depósitos privados de AWS, SRC de tecnología de Cisco, compilaciones de Docker, depósitos de Azure Storage, ¡Claves públicas y privadas, certificados SSL, productos premium de Cisco y más!.
IntelBroker también compartió muestras de los datos supuestamente robados, incluida una base de datos, información del cliente, documentación diversa del cliente y capturas de pantalla de portales de gestión de clientes. Sin embargo, el actor de amenazas no proporcionó más detalles sobre cómo se obtuvieron los datos.
En junio, IntelBroker comenzó a vender o filtrar datos de numerosas empresas, incluidas T-Mobile, AMD y Apple. Fuentes familiarizadas con el ataque dijeron que fueron robado de un proveedor externo de servicios administrados para DevOps y desarrollo de software. Se desconoce si la violación de Cisco está relacionada con estas violaciones de junio.
La vulnerabilidad surge del uso de una cadena de formato controlada externamente en el demonio fgfmd de FortiOS, que permite a atacantes remotos no autenticados ejecutar código o comandos arbitrarios a través de solicitudes especialmente diseñadas.
Según los análisis de Shadowserver, se han identificado aproximadamente 87.390 direcciones IP asociadas con dispositivos Fortinet potencialmente vulnerables. Estados Unidos lidera con 14.000 dispositivos afectados, seguido de Japón (5.100) e India (4.800).
La vulnerabilidad afecta a las versiones 7.0 a 7.4.2 de FortiOS, así como a varias versiones de FortiPAM, FortiProxy y FortiWeb. Fortinet ha publicado parches para los productos afectados y recomienda encarecidamente a los usuarios que actualicen sus sistemas a las versiones seguras más recientes. FortiOS 6.x no está afectado.
Como solución temporal, Fortinet recomienda eliminar el acceso a fgfm para cada interfaz. Sin embargo, esto puede impedir que FortiManager detecte FortiGate.
Explotación activa
La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE.UU. (CISA) ha agregado CVE-2024-23113 a su catálogo de vulnerabilidades explotadas conocidas (KEV), citando evidencia de explotación activa en la naturaleza.
Dado el uso generalizado de los productos Fortinet en redes empresariales y gubernamentales, esta vulnerabilidad representa un riesgo significativo para las organizaciones de todo el mundo. Los expertos en seguridad instan a tomar medidas inmediatas para mitigar la amenaza:
Actualizar los dispositivos afectados a las últimas versiones parcheadas.
Implementar las soluciones alternativas recomendadas si no es posible aplicar parches de inmediato.
Supervisar los sistemas para detectar cualquier signo de acceso no autorizado o actividad sospechosa.
Realizar una auditoría de seguridad exhaustiva de la infraestructura de red.
A medida que los actores de amenazas continúan apuntando a las vulnerabilidades conocidas, es fundamental actuar con rapidez para proteger la infraestructura crítica y los datos confidenciales de posibles ataques.
El Instituto Nacional de Estándares y Tecnología (NIST), el organismo federal que establece estándares tecnológicos para agencias gubernamentales, organizaciones de estándares y empresas privadas, ha propuesto prohibir algunos de los requisitos de contraseña más molestos y sin sentido. Los principales: reinicios obligatorios, uso obligatorio o restringido de ciertos personajes y el uso de preguntas de seguridad.
Elegir contraseñas seguras y almacenarlas de forma segura es una de las partes más desafiantes de un buen régimen de ciberseguridad. Aún resulta más difícil cumplir con las reglas de contraseñas impuestas por empleadores, agencias federales y proveedores de servicios en línea. A menudo, las reglas (aparentemente para mejorar la higiene de la seguridad) en realidad la socavan. Y, sin embargo, los legisladores anónimos imponen los requisitos de todos modos.
La semana pasada, NIST publicó su segundo borrador público de SP 800-63-4, la última versión de sus Directrices de identidad digital. Una sección dedicada a las contraseñas agrega una gran cantidad de prácticas de sentido común muy necesarias que desafían las políticas comunes. Un ejemplo: las nuevas reglas prohíben el requisito de que los usuarios finales cambien periódicamente sus contraseñas. Este requisito surgió hace décadas, cuando no se entendía bien la seguridad de las contraseñas y era común que las personas eligieran nombres comunes, palabras del diccionario y otros secretos que se adivinaban fácilmente.
Desde entonces, la mayoría de los servicios requieren el uso de contraseñas más seguras compuestas por caracteres o frases generadas aleatoriamente. Cuando las contraseñas se eligen correctamente, el requisito de cambiarlas periódicamente, generalmente cada uno a tres meses, en realidad puede disminuir la seguridad porque la carga adicional incentiva contraseñas más débiles que son más fáciles de configurar y recordar para las personas.
Otro requisito que a menudo hace más daño que bien es el uso obligatorio de ciertos caracteres, como al menos un número, un carácter especial y una letra mayúscula y minúscula. Cuando las contraseñas son lo suficientemente largas y aleatorias, no resulta beneficioso exigir o restringir el uso de ciertos caracteres. Y nuevamente, las reglas que rigen la composición pueden llevar a que las personas elijan códigos de acceso más débiles.
Las últimas directrices del NIST ahora establecen que:
Los verificadores NO DEBEN imponer reglas de composición (por ejemplo, requerir mezclas de diferentes tipos de caracteres) para contraseñas y;
Los verificadores NO DEBEN exigir a los usuarios que cambien las contraseñas periódicamente. Sin embargo, los verificadores DEBEN forzar un cambio si hay evidencia de compromiso del autenticador.
En versiones anteriores de las directrices, algunas de las reglas utilizaban las palabras “NO DEBRÏA” (should), lo que significa que la práctica no se recomienda como mejor práctica. “NO DEBEN” (must), por el contrario, significa que la práctica debe prohibirse para que una organización cumpla.
El último documento contiene varias otras prácticas de sentido común, que incluyen:
Los verificadores DEBEN exigir que las contraseñas tengan una longitud mínima de ocho caracteres aunque DEBERÍAN exigir que las contraseñas tengan una longitud mínima de 15 caracteres.
Los verificadores DEBERÍAN permitir una longitud máxima de contraseña de al menos 64 caracteres.
Los verificadores DEBERÍAN aceptar todos los caracteres ASCII [RFC20] impresos y el carácter de espacio en las contraseñas.
Los verificadores DEBERÍAN aceptar caracteres Unicode [ISO/ISC 10646] en las contraseñas. Cada código Unicode DEBE contarse como un solo carácter al evaluar la longitud de la contraseña.
Los verificadores NO DEBEN imponer otras reglas de composición (por ejemplo, requerir mezclas de diferentes tipos de caracteres) para las contraseñas.
Los verificadores NO DEBEN exigir a los usuarios que cambien las contraseñas periódicamente. Sin embargo, los verificadores DEBEN forzar un cambio si hay evidencia de compromiso del autenticador.
Los verificadores NO permitirán que el suscriptor almacene una pista a la que pueda acceder un reclamante no autenticado.
Los verificadores NO DEBEN solicitar a los suscriptores que utilicen autenticación basada en conocimientos (KBA) (por ejemplo, “¿Cómo se llamaba su primera mascota?”) ni preguntas de seguridad al elegir contraseñas.
Los verificadores DEBEN verificar toda la contraseña enviada (es decir, no truncarla).
Durante años, los críticos han denunciado la locura y el daño que resultan de muchas reglas de contraseñas comúnmente aplicadas. Y, sin embargo, los bancos, los servicios en línea y las agencias gubernamentales se han aferrado en gran medida a ellos de todos modos. Las nuevas directrices, en caso de que sean definitivas, no son universalmente vinculantes, pero podrían proporcionar puntos de conversación persuasivos a favor de acabar con las tonterías.
El Centro de respuesta a emergencias informáticas de Japón (JPCERT/CC) ha compartido consejos para detectar diferentes ataques de bandas de ransomware basándose en entradas en los registros de eventos de Windows, lo que proporciona una detección oportuna de los ataques en curso antes de que se propaguen demasiado en una red.
JPCERT/CC dice que la técnica puede ser valiosa a la hora de responder a ataques de ransomware, y que identificar el vector de ataque entre varias posibilidades es crucial para una mitigación oportuna. La estrategia de investigación propuesta por JPCERT/CC cubre cuatro tipos de registros de eventos de Windows: registros de aplicación, seguridad, sistema y configuración.
Estos registros a menudo contienen rastros dejados por ataques de ransomware que podrían revelar los puntos de entrada utilizados por los atacantes y su “identidad digital”.
A continuación se muestran algunos ejemplos de rastros de ransomware destacados en el informe de la agencia:
Phobos: deja rastros al eliminar copias de seguridad del sistema (ID de evento: 612, 524, 753). 8base y Elbie generan registros similares.
Midas: cambia la configuración de red para propagar la infección, dejando el ID de evento 7040 en los registros.
BadRabbit: registra el ID de evento 7045 al instalar un componente de cifrado.
Bisamware: registra el inicio (1040) y el final (1042) de una transacción de Windows Installer.
Akira, Lockbit3.0, HelloKitty, Abysslocker, Avaddon, Bablock y otros programas maliciosos creados a partir del cifrado filtrado de Lockbit y Conti leaked encryptor generan eventos similares.
Shade, GandCrab, AKO, AvosLocker, BLACKBASTA y Vice Society, dejan rastros muy similares (ID de evento: 13, 10016). Ambos errores se deben a la falta de permisos al acceder a aplicaciones COM para eliminar instantáneas de volumen, que el ransomware normalmente elimina para evitar una fácil restauración de archivos cifrados.
Es importante tener en cuenta que ningún método de detección debe tomarse como garantía de una protección adecuada contra el ransomware, pero el monitoreo de registros específicos puede cambiar las reglas del juego cuando se combina con otras medidas para detectar ataques antes de que se propaguen demasiado en una red.
JPCERT/CC señala que las cepas de ransomware más antiguas, como WannaCry y Petya, no dejaban rastros en los registros de Windows, pero la situación ha cambiado con el malware moderno, por lo que la técnica ahora se considera efectiva.
En 2022, SANS también compartió una guía sobre cómo detectar diferentes familias de ransomware mediante registros de eventos de Windows.
Durante un ataque de denegación de servicio distribuido (DDoS) dirigidoo a organizaciones de los sectores de servicios financieros, Internet y telecomunicaciones, los ataques volumétricos alcanzaron un máximo de 3,8 terabits por segundo, el mayor registrado públicamente hasta la fecha. El ataque consistió en una andanada de más de 100 ataques DDoS hipervolumétricos que inundaron la infraestructura de la red con datos basura.
En un ataque DDoS volumétrico, el objetivo se ve inundado con grandes cantidades de datos hasta el punto de consumir el ancho de banda o agotar los recursos de las aplicaciones y dispositivos, dejando a los usuarios legítimos sin acceso.
Routers ASUS, dispositivos MikroTik, DVR y servidores web
Muchos de los ataques dirigidos a la infraestructura de red del objetivo (capas de red y de transporte L3/4) superaron los dos mil millones de paquetes por segundo (pps) y los tres terabits por segundo (Tbps).
Según investigadores de la empresa de infraestructura de Internet Cloudflare, los dispositivos infectados se extendieron por todo el mundo, pero muchos de ellos estaban ubicados en Rusia, Vietnam, Estados Unidos, Brasil y España.
El actor de amenazas detrás de la campaña aprovechó múltiples tipos de dispositivos comprometidos, que incluían una gran cantidad de Routers domésticos ASUS (CVE 9.8, vulnerabilidad descubierta por Censys), dispositivos Mikrotik, DVR y servidores web.
Los investigadores afirman que la red de dispositivos maliciosos utilizó principalmente el Protocolo de datagramas de usuario (UDP) en un puerto fijo, un protocolo con transferencias de datos rápidas pero que no requiere establecer una conexión formal.
Normalmente, los actores de amenazas que lanzan ataques DDoS dependen de grandes redes de dispositivos infectados (botnets) o buscan formas de amplificar los datos entregados al objetivo, lo que requiere una cantidad menor de sistemas.
En un informe de esta semana, la empresa de computación en la nube Akamai confirmó que las vulnerabilidades CUPS recientemente reveladas en Linux podrían ser un vector viable para ataques DDoS. Después de escanear la Internet pública en busca de sistemas vulnerables a CUPS, Akamai descubrió que más de 58.000 estaban expuestos a ataques DDoS al explotar el problema de seguridad de Linux.
Más pruebas revelaron que cientos de “servidores CUPS vulnerables devolverán señales repetidamente después de recibir las solicitudes iniciales, y algunos de ellos parecen hacerlo sin cesar en respuesta a las respuestas HTTP/404”.
Estos servidores envían miles de solicitudes a los sistemas de prueba de Akamai, lo que muestra un potencial significativo de amplificación al explotar las fallas de CUPS.
Importante brecha de seguridad que afecta a Caterpillar Inc., una de las mayores fabricantes de maquinaria de construcción a nivel mundial. Según los informes, se ha filtrado una gran cantidad de información sensible, que incluye proyectos internos, datos de empleados y clientes, información financiera, diseños de fabricación y correspondencia privada.
El volumen de datos comprometidos asciende a 80 GB e incluye detalles confidenciales de la compañía. La publicación realizada por los atacantes revela que también han obtenido contraseñas de navegadores y herramientas de reconocimiento de la red.
Los atacantes han ofrecido el acceso a esta información y han proporcionado capturas de pantalla como prueba de la violación de seguridad. Además, han afirmado que llevan un largo tiempo dentro de la red de la empresa y han advertido sobre las posibles consecuencias de este incidente.
CrowdStrike inició una investigación después de recibir informes generalizados de hosts de Windows que experimentaban una pantalla azul de la muerte (BSOD). En la última actualización proporcionada al momento de escribir este artículo, la compañía dijo que está en proceso de revertir los cambios que pueden haber causado el problema.
El BSOD parece ser causado por una actualización reciente del sensor CrowdStrike Falcon. Según se informa, los dispositivos afectados entran en bucles BSOD que los hacen inoperables.
Se recomienda una solución alternativa que implica iniciar sistemas en modo seguro y eliminar un componente de CrowdStrike.
El director ejecutivo de CrowdStrike, George Kurtz, dijo en un comunicado en la plataforma de redes sociales X que los problemas se deben a un “defecto encontrado en una única actualización de contenido para los hosts de Windows”.
“Los hosts Mac y Linux no se ven afectados. Esto no es un incidente de seguridad ni un ciberataque. El problema ha sido identificado, aislado y se ha implementado una solución”, añadió Kurtz.
Organizaciones de todo el mundo han informado de importantes cortes de energía, incluidos aeropuertos, bancos, medios de comunicación y hospitales. Sin embargo, al menos algunos de estos incidentes parecen deberse a una interrupción del servicio en la nube de Microsoft que no está relacionada con CrowdStrike. Algunos sitios web de noticias parecen estar mezclando los dos incidentes.
Aún así, la mala actualización de CrowdStrike está causando problemas a muchos, incluidos los principales aeropuertos de todo el mundo. American Airlines le dijo a la BBC que a los vuelos no se les permitió despegar y que el incidente se atribuyó a un “problema técnico con CrowdStrike”.
Incluso Google Cloud informó de un incidente que afectó a su Compute Engine y señaló que “las máquinas virtuales de Windows que utilizan csagent.sys de Crowdstrike fallan y se reinician inesperadamente”.
Kevin Beaumont, un reputado experto en ciberseguridad, dijo que la actual interrupción global de TI es causada por CrowdStrike, no por Microsoft, que ha resuelto sus propios problemas.
Las acciones de CrowdStrike que cotizan en bolsa han bajado aproximadamente un 20% en las operaciones previas a la comercialización en el momento de la publicación.
Si se ha visto afectado por el error, aquí hay un workaround (otra) que se puede aplicar de forma temporal.
Arrancar Windows en Modo Seguro
Buscar la carpeta de CrowdStrike (C:\Windows\System32\drivers\CrowdStrike)
Buscar y borrar el archivo C-00000291*.sys
Reiniciar el ordenador
No se hicieron esperar los memes sobre el incidente:
GitLab advirtió hoy que una vulnerabilidad crítica en las ediciones GitLab Community y Enterprise de su producto permite a los atacantes ejecutar trabajos de canalización como cualquier otro usuario.
Las canalizaciones de GitLab son una característica del sistema de integración continua/implementación continua (CI/CD) que permite a los usuarios ejecutar automáticamente procesos y tareas en paralelo o secuencialmente para crear, probar o implementar cambios de código.
La plataforma GitLab DevSecOps tiene más de 30 millones de usuarios registrados y es utilizada por más del 50% de las empresas Fortune 100, incluidas T-Mobile, Goldman Sachs, Airbus, Lockheed Martin, Nvidia y UBS.
La falla corregida en la actualización de seguridad de hoy está identificada como CVE-2024-6385 y recibió una calificación de gravedad de puntuación base CVSS de 9,6 sobre 10. Afecta a todas las versiones de GitLab CE/EE desde 15.8 a 16.11.6, 17.0 a 17.0.4 y 17.1 a 17.1.2. En determinadas circunstancias que GitLab aún no ha revelado, los atacantes pueden aprovecharlo para activar una nueva canalización como usuario arbitrario.
Los atacantes apuntan a GitLab porque aloja varios tipos de datos corporativos confidenciales, incluidas claves API y código propietario, lo que genera un impacto significativo en la seguridad después de una infracción.
Un mes antes, solucionó una vulnerabilidad de gravedad alta (CVE-2024-4835) que permite a actores de amenazas no autenticados hacerse cargo de cuentas en ataques de secuencias de comandos entre sitios (XSS).
Como advirtió CISA en mayo, los actores de amenazas también están explotando activamente otra vulnerabilidad de GitLab sin necesidad de clic (CVE-2023-7028) parcheada en enero. Esta vulnerabilidad permite a atacantes no autenticados secuestrar cuentas mediante restablecimiento de contraseña.
En un avance sorprendente, Google Drive, ahora se puede utilizar para arrancar sistemas operativos Linux al permitir la creación de sistemas booteables, eliminando la dependencia de las unidades USB. Esta innovación podría cambiar la forma en que manejamos y transportamos sistemas operativos.
Hasta ahora, las unidades USB eran indispensables tanto para almacenar archivos como crear discos de arranque, necesarios para instalar o ejecutar otros sistemas operativos. Mientras que los sistemas de almacenamiento de archivos como Dropbox y Google Drive se han hecho cargo de un gran porcentaje de la tarea anterior de las unidades USB, no han sido capaces de actuar como medios de arranque. Pero, puede que eso ya no sea así, ya que esta guía es la primera que conocemos capaz de utilizar Google Drive para arrancar en un sistema Linux.
Sin embargo, un nuevo método permite utilizar Google Drive para esta tarea, marcando un hito en la tecnología de almacenamiento en la nube. Este proceso innovador no es sencillo y requiere dos componentes clave:
FUSE (Filesystem in Userspace): permite la creación de sistemas de archivos en el espacio de usuario, lo cual es esencial para que Google Drive pueda interactuar de manera efectiva con el proceso de arranque del sistema operativo.
Etapa del proceso de arranque de Linux: durante el arranque de Linux, el kernel descomprime un sistema de archivos temporal conocido como initramfs, que se utiliza para cargar el sistema de archivos real. Este paso es aprovechado para integrar el soporte de red y FUSE, permitiendo que Google Drive sea utilizado como medio de arranque.
El método aprovecha Dracut, una herramienta que permite usar una instalación de Linux existente para construir infraestructuras personalizadas. En este caso, las infraestructuras se construyen para incluir el soporte adecuado para la red y FUSE.
El concepto inicial de este proyecto se ejecutó en un contenedor, utilizando un proyecto existente llamado google-drive-ocamlfuse para interactuar con Google Drive. Tras resolver varios problemas de acceso root, red, enlaces simbólicos defectuosos y tiempos de espera en el sistema, la configuración se trasladó a un portátil para probarla en hardware real. El sistema funcionó, demostrando que Google Drive puede, de hecho, usarse para arrancar un sistema Linux.
El proyecto comenzó como un desafío personal para superar a un amigo que logró arrancar Linux desde un sistema de archivos en red (NFS). La idea evolucionó para intentar algo más complejo: arrancar Linux desde Google Drive.
Proceso de arranque de Linux
El proceso incluye varios pasos, como la configuración del firmware (BIOS/UEFI) para cargar el cargador de arranque, que a su vez carga el kernel de Linux. El kernel descomprime un sistema de archivos temporal (initramfs) en la RAM, permitiendo montar el sistema de archivos real. En este punto, se puede montar un sistema de archivos FUSE, crucial para este proyecto.
Prueba de concepto
La prueba de concepto incluyó la creación de un initramfs personalizado con soporte de red y los binarios necesarios de FUSE. Utilizando Dracut y construyendo sobre Arch Linux, se creó una imagen EFI para probar el arranque en hardware real.
Montaje en Google Drive
Se utilizó google-drive-ocamlfuse para montar Google Drive en el sistema. Sin embargo, se encontraron varios problemas, como la gestión de enlaces simbólicos y la velocidad de acceso, lo que requirió ajustes adicionales y soluciones creativas. Finalmente, el proyecto logró arrancar un sistema Linux completo desde Google Drive, marcando un hito en el uso de tecnologías de almacenamiento en la nube para tareas típicamente reservadas a hardware local.
Posibles aplicaciones futuras
Aunque el proyecto tiene un componente experimental y lúdico, sus aplicaciones prácticas podrían incluir arrancar sistemas Linux desde otros recursos en la nube, como servidores SSH o repositorios Git, llevando el concepto de computación nativa en la nube a nuevas fronteras. Si bien el autor considera la posibilidad de comercializar esta tecnología, reconoce que aún hay desafíos y áreas de mejora, lo que deja la puerta abierta para futuros desarrollos y exploraciones.
Aunque el creador original del proyecto admite que esta innovación puede parecer «algo tonta», reconoce que existen posibles casos de uso en el mundo real para una tecnología como esta. Sin embargo, no se espera que las unidades USB desaparezcan de nuestros escritorios a corto plazo. Para aquellos que no se sientan preparados para enfrentar un desafío técnico de esta magnitud, se recomienda comenzar con la serie Linux Fu de Al Williams.
Este desarrollo abre una nueva dimensión en la forma en que gestionamos nuestros sistemas operativos, mostrando que la nube y el almacenamiento local pueden integrarse de maneras novedosas y útiles. Y puede ofrecer varias ventajas, como la portabilidad del sistema operativo, la posibilidad de acceder a tu entorno de trabajo desde cualquier lugar con conexión a internet y la reducción de la necesidad de hardware de almacenamiento local.
Microsoft ha anunciado nuevas mejoras de ciberseguridad para las cuentas de correo electrónico personales de Outlook como parte de su ‘Iniciativa Futuro Seguro’, incluida la desactivación de la autenticación básica (nombre de usuario + contraseña) para el 16 de septiembre de 2024.
El gigante también anunció el fin del soporte para las aplicaciones ‘Correo’ y ‘Calendario’ en Windows, la desactivación de Outlook Light y la eliminación de la capacidad de los usuarios para acceder a cuentas de Gmail a través de Outlook.com.
Pasar a la autenticación moderna
A partir del 16 de septiembre de 2024, la autenticación básica (nombre de usuario y contraseña) para clientes de Outlook se eliminará de todas las cuentas personales de Outlook, incluidas Outlook.com, Hotmail.com y Live.com.
El método de autenticación básico no es seguro ya que envía credenciales por cable sin cifrado, lo que permite que las herramientas de monitoreo de redes las capturen. Además, los navegadores y otras aplicaciones suelen almacenar en caché las credenciales de autenticación básicas hasta que se reinicia el navegador, lo que permite que otras personas con acceso al dispositivo las utilicen.
“Si bien la autenticación básica fue el estándar durante bastante tiempo, también facilitó a los delincuentes capturar la información de inicio de sesión de una persona”, explica Microsoft. “Esto aumentó el riesgo de que esas credenciales robadas se reutilicen para obtener acceso al correo electrónico o a los datos personales de una persona. Los ataques cibernéticos basados en correo electrónico solo han aumentado con el tiempo, por lo que exigimos una autenticación moderna para todos los clientes de Outlook para ayudar a proteger mejor sus cuentas personales.”
Al cambiar a métodos de autenticación más modernos, las credenciales de autenticación básicas serán reemplazadas por una autenticación basada en tokens respaldada por autenticación multifactor (MFA).
Sin embargo, estos cambios causarán problemas a los usuarios que utilicen aplicaciones más antiguas que solo admiten la autenticación básica, porque ya no podrán acceder a las cuentas de correo electrónico de Outlook.com, Hotmail.com o Live.com después del 16 de septiembre.
En su lugar, los usuarios deberán cambiar a las últimas versiones de Outlook, Outlook para Windows, Apple Mail, Thunderbird u otros clientes de correo electrónico compatibles que admitan métodos de autenticación modernos.
Los usuarios con una suscripción a Microsoft 365 pueden usar la versión de Outlook incluida en su plan, mientras que aquellos que usan Outlook 2021 (compilación 11601.10000 o superior) ya están equipados con la ‘Autenticación moderna’ y no se verán afectados.
Anuncios de EoL
Microsoft también anunció la desactivación de las aplicaciones Correo y Calendario, alentando a los usuarios existentes a migrar al nuevo Outlook para Windows, que ofrece seguridad mejorada. Mail y Calendar permanecerán en Microsoft Store hasta el 31 de diciembre de 2024 y, después de esa fecha, ya no serán compatibles.
Se agregará una opción de “cambiar a Outlook” a las interfaces de ambas aplicaciones para agilizar el proceso de migración para los usuarios afectados.
Otra obsolescencia es la versión “ligera” de Outlook Web App, cuyo soporte finaliza el 19 de agosto de 2024. Esta versión liviana se proporcionó para usuarios con navegadores web más antiguos y con menos capacidades. Microsoft ahora lo está retirando debido a la experiencia muy degradada y los estándares de seguridad más bajos a los que se adhiere.
Microsoft también anunció que, a partir del 30 de junio de 2024, Outlook.com ya no permitirá a los usuarios acceder a cuentas de Gmail. Sin embargo, los clientes independientes de Outlook para Windows y Mac seguirán ofreciendo esta funcionalidad.
Finalmente, como efecto secundario de la desactivación de Cortana, ‘Reproducir mis correos electrónicos’ y ‘Búsqueda por voz’ en Outlook móvil también se eliminarán a finales de este mes.
Investigadores de Top10VPN han descubierto una nueva vulnerabilidad de seguridad derivada de un defecto de diseño en el estándar Wi-Fi IEEE 802.11 que permite engañar a las víctimas para conectarse a una red inalámbrica menos segura y escuchar el tráfico de su red (downgrade).
El Ataque de Confusión SSID, rastreado como CVE-2023-52424, impacta todos los sistemas operativos y los clientes Wi-Fi, incluidas las redes hogareñas, corporativas y mesh que se basan en los protocolos de WEP, WPA3, 802.11x/EAP y AMPE.
El método “implica rebajar a las víctimas a una red menos segura mediante la inspección de un nombre de red confiable (SSID) para que puedan interceptar su tráfico o llevar a cabo más ataques”, dijo Top10VPN, que colaboró con los investigadores Ku Leuven y Mathy Vanhoef.
“Un ataque exitoso de confusión SSID también hace que cualquier VPN con esta funcionalidad se desactive automáticamente en redes de confianza, dejando expuesto el tráfico de la víctima”.
El problema que sustenta el ataque es el hecho de que el estándar Wi-Fi no requiere que el nombre de la red (SSID o el identificador del conjunto de servicios) siempre se autentiquen y que las medidas de seguridad solo se requieran cuando un dispositivo opta para unirse a una red en particular.
Al crear un ataque adversario en el medio (Adversary-in-the-Middle – AitM), el efecto neto de este comportamiento es que un atacante podría engañar a un cliente para que se conecte a una red Wi-Fi no confiable, distinta de a la que pretendía conectarse.
“En nuestro ataque, cuando la víctima quiere conectarse a su red de confianza, lo engañamos para que se conecte a una red diferente y que utiliza las mismas credenciales de la red original”, describieron los investigadores Héloïse Gollier y Vanhoef. “Como resultado, el cliente de la víctima pensará y mostrará al usuario que está conectado a ‘Trusted-net’, mientras que en realidad está conectado a ‘Wrong-net'”.
En otras palabras, a pesar de que las contraseñas u otras credenciales se verifican mutuamente cuando se conectan a una red Wi-Fi protegida, no hay garantía de que el usuario se conecte a la red correcta a la que desea.
Hay ciertos requisitos previos para lograr el ataque de downgrade:
La víctima quiere conectarse a una red Wi-Fi confiable
Hay una red deshonesta disponible con las mismas credenciales de autenticación que la primera
El atacante está dentro del rango para realizar un AitM entre la víctima y la red de confianza
Las mitigaciones propuestas para contrarrestar esta confusión de SSID incluyen una actualización del estándar Wi-Fi 802.11 incorporando el SSID como parte del handshake 4 vías cuando se conecta a redes protegidas, así como mejoras a la protección de baliza que permiten un “cliente almacenar una baliza de referencia que contiene el SSID de la red y verifica su autenticidad durante el handshake de 4 vías”.
Las balizas (beacon) se refieren a los marcos de gestión que un punto de acceso inalámbrico transmite periódicamente para anunciar su presencia. Contiene información como el SSID, el intervalo de tiempo de la baliza y las capacidades de la red, entre otras.
“Las redes pueden mitigar el ataque evitando la reutilización de las credenciales entre los SSID”, dijeron los investigadores. “Las redes empresariales deben usar distintos nombres comunes del servidor Radius, mientras que las redes domésticas deben usar una contraseña única por SSID”.
Los hallazgos se producen casi tres meses después de que se revelaron dos fallas de derivación de autenticación en software Wi-Fi de código abierto como WPA_Supplicant e Intel’s Inet Wireless Daemon (IWD) que podría engañar a los usuarios para unirse a un clon malicioso de una red legítima o permitir que un atacante pueda unirse a una red de confianza sin una contraseña.
En agosto pasado, Vanhoef también reveló que el cliente de Windows para Cloudflare WARPCloudflare WARP podría ser engañado para filtrar todas las solicitudes de DNS, permitiendo efectivamente a un adversario falsificar las respuestas de DNS e interceptar casi todo el tráfico.
DNS emplea una variedad de mecanismos para garantizar la disponibilidad, proteger la seguridad y mejorar la confiabilidad. Sin embargo, en este paper investigadores de la Universidad Tsinghua de Pekín, revelan que estos mecanismos inherentes, incluidos el tiempo de espera, la agregación de consultas y la respuesta rápida, pueden transformarse en vectores de ataque maliciosos; y proponen un nuevo ataque DoS denominado DNSBomb [PDF / Github].
DNSBomb explota múltiples mecanismos de DNS ampliamente implementados para acumular consultas de DNS que se envían a baja velocidad, para amplificar las consultas en respuestas de gran tamaño y concentrar todas las respuestas de DNS en una ráfaga de pulsaciones periódicas, cortas y de gran volumen para saturar simultáneamente los sistemas de destino.
A través de una evaluación exhaustiva de 10 software de DNS convencionales, 46 servicios de DNS públicos y alrededor de 1,8 millones de solucionadores de DNS abiertos, la investigación demuestra que todos estos podrían explotarse para llevar a cabo ataques DNSBomb más prácticos y potentes que los ataques DoS conocidos anteriormente.
Experimentos a pequeña escala muestran que la magnitud máxima del pulso puede acercarse a 8,7 Gb/s y el factor de amplificación del ancho de banda podría superar las 20.000 veces. Los ataques controlados realizados provocan la pérdida total de paquetes o la degradación del servicio en conexiones con y sin estado (TCP, UDP y QUIC).
El paper además, presenta soluciones de mitigación efectivas con evaluaciones detalladas y los investigadores informaron responsablemente sus hallazgos a todos los proveedores afectados y recibieron el reconocimiento de 24 de ellos, los cuales están parcheando su software utilizando las soluciones planteadas.
GIT está llamando actualizar a la la última versión GIT 2.45.1, lanzada el 14 de mayo de 2024, que aborda cinco vulnerabilidades. Las plataformas afectadas son Windows, MacOS, Linux e incluso *BSD, ¡por lo que estas soluciones son importantes para todos!
Esta versión se coordinó con Visual Studio y Github Desktop, que incluyen un subconjunto de GIT. También están lanzando varias actualizaciones de defensa en profundidad para corregir los siguientes errores:
CVE-2024-32002 (Critico, Windows & MacOS): los repositorios de Git con submódulos pueden engañar a Git para ejecutar un hook desde el directorio .git/ durante una operación de clonación (git clone), lo que lleva a la Ejecución de Código Remoto (RCE). Existe un exploit público y funcional para esta vulnerabilidad que permite ejecutar código en el cliente.
CVE-2024-32004 (Alto): un atacante puede crear un repositorio local que ejecute código arbitrario cuando se clona.
CVE-2024-32465 (Alto): la clonación de los archivos .ZIP que contienen repositorios Git pueden evitar las protecciones, potencialmente ejecutando hooks inseguros.
CVE-2024-32020 (Bajo): los clones locales en el mismo disco pueden permitir a los usuarios no confiables modificar archivos vinculados en la base de datos de objetos del repositorio clonado.
CVE-2024-32021 (Bajo): la clonación de un repositorio local con enlaces simbólicos puede dar lugar a los archivos arbitrarios en el directorio “objects/”
La actualización a la última versión de GIT es esencial para proteger contra estas vulnerabilidades. Si no puede actualizar de inmediato, tenga cuidado de donde clone los repositorios.
Según nuevos datos de Sophos, el compromiso del protocolo de escritorio remoto (RDP) ha alcanzado niveles récord en ataques de ransomware.
La empresa analizó 150 de sus casos de respuesta a incidentes de 2023 y descubrió que el abuso de RDP se presentaba en el 90 % de ellos para brindar a los actores de amenazas acceso remoto a entornos Windows.
Sophos describió la tasa de abuso de RDP como “sin precedentes” y dijo que explicaba parcialmente por qué los servicios remotos externos eran la forma más popular para que los actores de amenazas obtuvieran acceso inicial en ataques de ransomware, lo que representó el 65% de los casos el año pasado.
En un caso, los atacantes lograron comprometer a la misma víctima cuatro veces en seis meses a través de puertos RDP expuestos. Una vez dentro, pudieron moverse lateralmente a través de sus redes, descargando archivos binarios maliciosos, deshabilitando la protección de endpoints y estableciendo acceso remoto, dijo Sophos.
RDP ofrece varias ventajas para los actores de ransomware:
Es extremadamente popular entre los administradores de red.
Los atacantes pueden abusar de él para acceder de forma remota sin activar ninguna alarma AV o EDR.
Ofrece una GUI fácil de usar.
El servicio a menudo está mal configurado, lo que significa que está expuesto públicamente y protegido sólo con credenciales fáciles de descifrar.
A veces se utilizan cuentas con privilegios elevados para RDP, lo que amplifica el daño que se puede causar.
Los administradores suelen desactivar funciones de seguridad como la autenticación a nivel de red.
Muchas organizaciones olvidan segmentar sus redes, lo que ayuda a los atacantes RDP
“Los servicios remotos externos son un requisito necesario, pero riesgoso, para muchas empresas. Los atacantes comprenden los riesgos que plantean estos servicios y buscan activamente subvertirlos debido a la recompensa que se esconde detrás”, argumentó John Shier, CTO de campo de Sophos.
Exponer los servicios sin una cuidadosa consideración y mitigación de sus riesgos conduce inevitablemente a un compromiso. Un atacante no tarda mucho en encontrar y violar un servidor RDP expuesto y, sin controles adicionales, para luego también vulnerar servidores Active Directory que están del otro lado.
Si bien todos los ataques de ransomware tienen resultados negativos, aquellos que comienzan explotando vulnerabilidades sin parches son particularmente brutales para sus víctimas. Las organizaciones afectadas por ataques que comenzaron de esta manera reportan resultados considerablemente más graves que aquellas cuyos ataques comenzaron con credenciales comprometidas, incluida una mayor propensión a:
Tener copias de seguridad comprometidas (tasa de éxito del 75% frente al 54% para credenciales comprometidas)
Tener datos cifrados (tasa de cifrado del 67% frente al 43% para credenciales comprometidas)
Pagar el rescate (tasa de pago del 71% frente al 45% para credenciales comprometidas)
Cubrir el costo total del rescate internamente (el 31% financió el rescate completo internamente frente al 2% para las credenciales comprometidas)
Costos generales de recuperación de ataques 4 veces mayores ($3 millones frente a $750.000 para credenciales comprometidas)
Tiempo de recuperación más lento (el 45% tardó más de un mes frente al 37% para las credenciales comprometidas)
El informe completo se puede descargar desde aquí y aquí.
El flagelo de los ataques a la cadena de suministro de software es una técnica de ataque informático cada vez más común que oculta código malicioso en un programa legítimo ampliamente utilizado y puede adoptar muchas formas.
Los delincuentes informáticos pueden penetrar un servidor de actualización para dejar su malware, o incluso ingresar a la red donde se desarrolló el software para corromperlo desde el código fuente. O, en el caso de un atacante de la cadena de suministro de software como el reciente backdoor en XY Utils, donde los atacante pasaron dos años “ofreciendo ayuda cortésmente”.
La puerta trasera en XZ Utils
Durante el fin de semana pasado, la comunidad de ciberseguridad y software de código abierto quedó impactada por la noticia de que una versión experimental relativamente nueva de XZ Utils (una utilidad de compresión integrada en muchas distribuciones populares de Linux) contenía una puerta trasera que habría permitido a los delincuentes informáticos, en posesión de un clave privada específica, conectarse al sistema de puerta trasera y ejecutar sus propios comandos como administrador.
Sólo un trabajo de detective casual llevado a cabo por un solitario ingeniero de Microsoft, Andrés Freund, que había detectado un extraño retraso en la ejecución del protocolo de conexión remota SSH en una versión de la variante de Linux Debian, captó el truco de espionaje antes de que terminara en muchos millones de sistemas en todo el mundo.
Esa puerta trasera de XZ Utils, ahora está claro, fue insertada nada menos que por el principal mantenedor del código de XZ Utils, un desarrollador que se hacía llamar “Jia Tan”. A raíz del descubrimiento de la puerta trasera, un misterio se filtra en el mundo de la tecnología: ¿quién es Jia Tan y para quién trabajó realmente él o ella (o muy probablemente ellos)?
Jia Tan aprovechó el enfoque de codificación colaborativo del software de código abierto mediante el cual cualquiera puede sugerir cambios a un programa en repositorios de código como GitHub, donde otros programadores revisan los cambios antes de integrarlos en el software. Un vistazo a la historia documentada de Jia Tan en el mundo de la programación de código abierto revela que aparecieron por primera vez en noviembre de 2021 con el nombre de usuario de GitHub JiaT75, luego hicieron contribuciones a otros proyectos de código abierto usando el nombre Jia Tan, o a veces Jia Cheong Tan, durante más de un año antes de comenzar a enviar cambios a XZ Utils.
En enero de 2023, el código de Jia Tan se estaba integrando en XZ Utils. Durante el próximo año, tomarían en gran medida el control del proyecto de manos de su mantenedor original, Lasse Collin, un cambio impulsado en parte por correos electrónicos molestos enviados a Collin por un puñado de usuarios quejándose de actualizaciones lentas. No está claro si esos usuarios fueron cómplices involuntarios o si realmente trabajaron con Jia Tan para persuadir a Collin de que renunciara al control. Finalmente, Jia Tan agregó su puerta trasera sigilosa a una versión de XZ Utils en febrero de este año.
Ese enfoque inhumanamente paciente, junto con las características técnicas y la sofisticación de la propia puerta trasera, ha llevado a muchos en el mundo de la ciberseguridad a creer que Jia Tan debe, de hecho, ser un identificador operado por atacantes informáticos patrocinados por el Estado (y muy buenos).
“Esta operación de varios años fue muy astuta y la puerta trasera implantada es increíblemente engañosa”, dice Costin Raiu, quien hasta el año pasado se desempeñó como investigador principal y jefe del equipo de investigación y análisis global de la firma rusa de ciberseguridad Kaspersky. “Yo diría que se trata de un grupo respaldado por un Estado-nación, uno con objetivos a largo plazo en mente y que permite invertir en la infiltración de varios años en proyectos de código abierto”.
En cuanto a qué nación, Raiu nombra a los sospechosos habituales: China, Rusia y Corea del Norte. Dice que todavía es demasiado pronto para conocer al verdadero culpable. “Una cosa está clara. Esto fue más astuto que todos los ataques anteriores a la cadena de suministro de software que he visto”.
Un programador muy privado y muy ocupado
A medida que ha aumentado el escrutinio en torno a Jia Tan desde la revelación de la puerta trasera de XZ Utils el viernes pasado, los investigadores han notado que la persona tiene una seguridad operativa notablemente buena. El reportero de seguridad independiente Brian Krebs escribe que no pudo encontrar ningún rastro cero de la dirección de correo electrónico de Jia Tan fuera de los mensajes que enviaron a otros contribuyentes de código abierto, incluso después de rastrear las bases de datos violadas. Jia Tan también parece haber enrutado todas sus comunicaciones a través de una VPN con una dirección IP de Singapur.
La falta de cualquier otra presencia en línea vinculada a Jia Tan apunta a que la cuenta es una “persona inventada con un solo propósito” e indica cuánta sofisticación, paciencia y pensamiento se puso en el desarrollo de la puerta trasera, dice Will Thomas, instructor de SANS Institute, una empresa de formación en ciberseguridad. La personalidad de Jia Tan ha desaparecido desde que se descubrió la puerta trasera. La cuenta de GitHub de Jia Tan ha sido suspendida, según le dice a WIRED un portavoz de la compañía.
De hecho, las únicas huellas reales que Jia Tan parece haber dejado atrás fueron sus contribuciones a la comunidad de desarrollo de código abierto, donde fueron un colaborador prolífico: de manera inquietante, el primer cambio de código de Jia Tan fue a la biblioteca de compresión “libarchive”, otro componente muy ampliamente utilizado. Ese primer cambio intercambió una función con una alternativa menos segura, potencialmente intentando otro cambio de código malicioso, señala el desarrollador Evan Boehs en su detallada cronología de Jia Tan, aunque el problema ya se solucionó.
En total, Jia Tan realizó 6.000 cambios de código en al menos siete proyectos entre 2021 y febrero de 2024, según Michael Scott, cofundador de la empresa de ciberseguridad NetRise, que anteriormente trabajó en el grupo de guerra cibernética del Cuerpo de Marines bajo el Comando Cibernético de EE.UU.
Determinar todos los efectos ramificados de esos cambios es casi imposible, afirma Scott. Debido a que esos cambios, conocidos como “confirmaciones”, a menudo se agrupan en colecciones en un proceso conocido como “aplastamiento de confirmaciones”, no siempre es evidente qué cambios exactos realizó Jia Tan. Y la dificultad de rastrear cuál de las muchas versiones de una biblioteca como libarchive terminó en qué software agrega otra capa de ofuscación. “Va a ser un poco complicado tirar de este hilo y tratar de descubrir dónde terminaron todas estas cosas”, dice Scott.
Scott señala que, durante todo este tiempo, Jia Tan también estuvo enviando correos electrónicos a otros contribuyentes, escribiendo en un tono “muy conciso, muy seco”, pero no hostil, que Scott compara con el resultado de ChatGPT. Jordi Mas, un desarrollador que contribuyó a XZ Utils y había enviado “comentarios” por correo electrónico de Jia Tan, dice en retrospectiva que la cuenta fue a niveles adicionales para generar confianza en la persona.
En última instancia, Scott sostiene que esos tres años de cambios de código y correos electrónicos corteses probablemente no se dedicaron a sabotear múltiples proyectos de software, sino a construir una historia de credibilidad en preparación para el sabotaje de XZ Utils específicamente, y potencialmente de otros proyectos en el futuro. “Simplemente nunca llegó a ese paso porque tuvimos suerte y encontramos sus cosas. Así que eso ya está quemado y tendrá que volver al punto de partida”.
Tics técnicos y zonas horarias
A pesar de la personalidad de Jia Tan como un solo individuo, su preparación de años es un sello distintivo de un grupo de hackers bien organizado y patrocinado por el estado, argumenta Raiu. También lo son las características técnicas del código malicioso XZ Utils que agregó Jia Tan.
Raiu señala que, a primera vista, el código realmente parece una herramienta de compresión. “Está escrito de una manera muy subversiva”, dice. También es una puerta trasera “pasiva”, dice Raiu, por lo que no llegaría a un servidor de comando y control que podría ayudar a identificar al operador de la puerta trasera. En cambio, espera a que el operador se conecte a la máquina de destino a través de SSH y se autentique con una clave privada, una generada con una función criptográfica particularmente potente conocida como ED448.
El cuidadoso diseño de la puerta trasera podría ser obra de hackers estadounidenses, señala Raiu, pero sugiere que eso es poco probable, ya que Estados Unidos normalmente no sabotearía proyectos de código abierto y, si lo hiciera, la Agencia de Seguridad Nacional probablemente usaría un sistema criptográfico resistente a los cuánticos. La función ED448 no es. Eso deja a los grupos no estadounidenses con un historial de ataques a la cadena de suministro, sugiere Raiu, como el China’s APT41, North Korea’s Lazarus Group, y Russia’s APT29.
A primera vista, Jia Tan ciertamente parece del este de Asia, o debería parecerlo. La zona horaria de los compromisos de Jia Tan es UTC+8: esa es la zona horaria de China, y está a sólo una hora de la de Corea del Norte. Sin embargo, un análisis realizado por dos investigadores, Rhea Karty y Simon Henniger, sugiere que Jia Tan simplemente pudo haber cambiado la zona horaria de su computadora a UTC+8 antes de cada confirmación. De hecho, varias confirmaciones se realizaron con una computadora configurada en una zona horaria de Europa del Este o del Medio Oriente, tal vez cuando Jia Tan olvidó hacer el cambio.
“Otro indicio de que no son de China es el hecho de que trabajaron en días festivos chinos importantes”, dicen Karty y Henniger, estudiantes del Dartmouth College y de la Universidad Técnica de Munich, respectivamente. Señalan que Jia Tan tampoco envió un nuevo código en Navidad o Año Nuevo. Boehs, el desarrollador, añade que gran parte del trabajo comienza a las 9am y termina a las 5pm para las zonas horarias de Europa del Este o Medio Oriente. “El rango de tiempo de los compromisos sugiere que este no fue un proyecto que hicieron fuera del trabajo”, dice Boehs.
Aunque eso deja a países como Irán e Israel como posibilidades, la mayoría de las pistas conducen a Rusia, y específicamente al grupo de hackers APT29 de Rusia, sostiene Dave Aitel, ex hacker de la NSA y fundador de la empresa de ciberseguridad Immunity.
Aitel señala que APT29, que se cree que trabaja para la agencia de inteligencia extranjera de Rusia, conocida como SVR, tiene una reputación de atención técnica que pocos grupos de hackers tienen. APT29 también llevó a cabo el compromiso de Solar Winds, quizás el ataque a la cadena de suministro de software más hábilmente coordinado y eficaz de la historia. En comparación, esa operación coincide mucho más con el estilo de la puerta trasera de XZ Utils que con los ataques más crudos a la cadena de suministro de APT41 o Lazarus.
“Es muy posible que se trate de otra persona. Pero, si estás buscando los ataques a la cadena de suministro más sofisticados del planeta, esos serán nuestros queridos amigos en el SVR”.
Los investigadores de seguridad coinciden, al menos, en que es poco probable que Jia Tan sea una persona real, o incluso una persona que trabaje sola. En cambio, parece claro que la persona era la encarnación en línea de una nueva táctica de una organización nueva y bien organizada, una táctica que casi funcionó. Eso significa que deberíamos esperar ver a Jia Tan regresar con otros nombres: contribuyentes aparentemente educados y entusiastas a proyectos de código abierto, que ocultan las intenciones secretas de un gobierno en sus compromisos de código.
Los investigadores han demostrado un nuevo ataque acústico de canal lateral en los teclados que puede deducir la entrada del usuario en función de sus patrones de escritura, incluso en malas condiciones, como entornos con ruido.
Aunque el método logra una tasa de éxito promedio del 43%, que es significativamente menor que otros métodos presentados en el pasado, no requiere condiciones de grabación controladas ni una plataforma de escritura específica.
Esto lo hace más aplicable en ataques reales y, dependiendo de algunos parámetros específicos del objetivo, puede producir suficientes datos confiables para descifrar la entrada general del objetivo con algún análisis posterior a la captura.
El ataque acústico
Los investigadores Alireza Taheritajar y Reza Rahaeimehr de la Universidad de Augusta en Estados Unidos han publicado un artículo técnico [PDF] que presenta los detalles de su exclusivo método acústico de canal lateral.
El ataque aprovecha las emisiones de sonido distintivas de diferentes pulsaciones de teclas y el patrón de escritura de los usuarios capturado por software especializado para recopilar un conjunto de datos.
Es fundamental recopilar algunas muestras de escritura del objetivo para que las pulsaciones de teclas y palabras específicas puedan correlacionarse con las ondas sonoras.
El documento profundiza en los posibles métodos para capturar texto, pero podría ser a través de malware, sitios web maliciosos o extensiones de navegador, aplicaciones comprometidas, secuencias de comandos entre sitios o teclados USB comprometidos.
La escritura del objetivo puede grabarse usando un micrófono oculto cerca de él o de forma remota usando dispositivos comprometidos en las proximidades, como teléfonos inteligentes, computadoras portátiles o parlantes inteligentes.
El conjunto de datos capturado incluye muestras de tipeo en diversas condiciones, por lo que se deben registrar múltiples sesiones de tipeo, lo cual es crucial para el éxito del ataque. Sin embargo, los investigadores dicen que el conjunto de datos no tiene por qué ser particularmente grande.
Luego, el conjunto de datos se utiliza para entrenar un modelo estadístico que produce un perfil completo de los patrones de escritura individuales del objetivo en función de los intervalos de tiempo entre pulsaciones de teclas.
Los investigadores descubrieron que aceptar una desviación del 5% para el modelo estadístico es crucial, ya que el comportamiento al escribir varía ligeramente incluso cuando una persona escribe la misma palabra dos veces.
Por ejemplo, cualquier intervalo registrado entre A y B que se encuentre entre 95 milisegundos (100 – 5%) y 105 milisegundos (100 + 5%) podría considerarse una coincidencia.
La desviación también ayuda a mitigar el impacto de los errores o el ruido en la grabación, asegurando que las discrepancias menores no provoquen una falta de coincidencia.
El método predice el texto escrito analizando grabaciones de audio de la actividad del teclado, y la precisión se mejora al filtrar las predicciones a través de un diccionario de inglés.
Lo que hace que el ataque sea diferente en comparación con otros enfoques es que puede alcanzar una precisión de predicción de escritura del 43 % (en promedio) incluso cuando:
las grabaciones contienen ruido ambiental
las sesiones de escritura grabadas para el mismo objetivo se llevaron a cabo en diferentes modelos de teclado.
las grabaciones fueron tomadas usando un micrófono de baja calidad
el objetivo es libre de utilizar cualquier estilo de escritura
Por otro lado, el método tiene limitaciones que en ocasiones hacen que el ataque sea ineficaz.
Por ejemplo, puede ser difícil perfilar a las personas que rara vez usan una computadora y no han desarrollado un patrón de mecanografía consistente, o a los mecanógrafos profesionales que escriben muy rápido.
Los resultados de las pruebas de 20 sujetos de prueba han producido un amplio rango de éxito, desde el 15% hasta el 85%, lo que hace que algunos sujetos sean mucho más predecibles y susceptibles que otros.
Los investigadores también observaron que la amplitud de la forma de onda producida se acentúa menos cuando se utilizan teclados silenciosos (interruptores mecánicos o de membrana con amortiguador de sonido), lo que puede obstaculizar la eficacia del entrenamiento para el modelo de predicción y reducir las tasas de detección de pulsaciones de teclas.
