En la descripción del ataque, Zdrnya da la siguiente secuencia de acciones. Después de obtener acceso a la computadora de la víctima, el atacante activa el modo de desarrollador en Google Chrome, lo que le permite descargar la extensión localmente, en lugar de a través de la tienda. Por lo tanto, una extensión maliciosa disfrazada de complemento de un producto de seguridad se carga en el navegador.
En el código de la extensión en sí, el investigador describe un método estándar para interactuar con la infraestructura de la nube de Google, que permite "intercambiar" datos arbitrarios entre dos navegadores. Es decir, presumiblemente el ataque se veía así: pirateamos la computadora, instalamos una extensión maliciosa, autorizamos el navegador con una cuenta de Google única. Por parte del atacante, basta con iniciar sesión con la misma cuenta para obtener datos de la computadora de la víctima.
Qué fue exactamente transferido de esta manera, el experto no revela, pero indica las limitaciones del método: el tamaño máximo de "claves" transmitidas a través de la infraestructura de Google Chrome no puede exceder los 8 KB, y su número máximo es 512. Es decir, Se pueden transferir 4 MB de datos por sesión ... Esto es suficiente para controlar una computadora infectada, así como para transferir tokens para acceder a los servicios corporativos en la nube.
Zdrnya enfatiza que no había otro software malicioso en el sistema afectado. No funcionará así para bloquear el acceso a la infraestructura de la nube de Google a nivel de políticas de red corporativa: no solo la nube está ligada a ellas, sino también, por ejemplo, verificando la disponibilidad de acceso a la red en el navegador. Como solución, el investigador propone la aplicación de políticas que prohíban la instalación de cualquier extensión en el navegador, excepto las marcadas en la lista blanca. Un método tan original de interactuar con el sistema atacado puede ignorarse durante mucho tiempo; esto abrirá el camino para que los atacantes accedan a los datos corporativos, que en condiciones normales son accesibles a través de un navegador. En la mayoría de los casos, puede tratarse de correo electrónico corporativo, herramientas de colaboración de documentos y mucho más.
Que mas paso
Continuó la historia del ataque a los expertos en seguridad de la información (ver el resumen anterior ). Se descubrió una vulnerabilidad de día cero en el motor V8 y se cerró en el navegador Google Chrome . Aunque los desarrolladores de Google no comentan sobre esto, se supone que los organizadores del ataque lo utilizaron. Además, los expertos surcoreanos encontraron otro vector del mismo ataque: a las víctimas se les enviaron archivos .mhtml con código malicioso explotando una vulnerabilidad previamente desconocida en Internet Explorer 11. El archivo supuestamente contenía información sobre una vulnerabilidad en el navegador Google Chrome 85.
Netscout, citando a investigadores chinos de Baidu Labs, informa sobre un nuevo método para amplificar un ataque DDoS utilizando un servidor de medios Plex configurado incorrectamente.
En el hilo del enlace anterior, un investigador con el sobrenombre de OverSoft habla de una cámara de video IP mal protegida con función de conteo de personas. La historia comienza con un identificador y una contraseña de red WiFi insustituibles, y se pone más triste. Dentro de la cámara, encontré un módulo de cómputo Raspberry Pi con un usuario pi predeterminado, documentos sobrantes del desarrollador (incluido un archivo mp3) y un montón de código Python. El resultado es un dispositivo que, en teoría, se conecta a una red corporativa con WiFi virtualmente inseguro y la capacidad de obtener acceso completo a una cuenta con una contraseña estándar y privilegios máximos.
El equipo de Google Project Zero publicadescripción general de las vulnerabilidades de día cero utilizadas en ataques reales el año pasado. De los 24 hoyos, ocho utilizan un nuevo método para explotar un problema ya conocido. Conclusión: es posible complicar un poco la vida de los atacantes si las vulnerabilidades se cierran después de un análisis detallado de la causa para que el problema resuelto no pueda reabrirse.
Hace más de un mes, el 4 de enero, hubo una falla importante en el mensajero de Slack. Se publicó un informe detallado sobre los resultados del incidente . La caída se debió a una combinación de razones: el primer día hábil después de las vacaciones en la mayoría de los países, los usuarios cargaron la infraestructura más de lo necesario y la herramienta de escalado automático de capacidad en Amazon Web Services no funcionó como se esperaba.
Un estudio del malware Kobalos para sistemas Linux revela un objetivo de ataque inusual: las supercomputadoras.
Un nuevo ejemplo de un ataque a la cadena de suministro: los investigadores de ESET encontraron software NoxPlayer infectado (emulación de aplicaciones de Android) distribuido directamente desde el sitio web del desarrollador.