Es el momento de actualizar Firefox para Android a su versión 80 porque sufre un fallo de seguridad muy fácil de explotar. Permite a un atacante en la misma red WiFi abrir arbitrariamente cualquier URL en el navegador de la víctima, si que esta deba generar ninguna acción. Simple y mágicamente, se abre una web elegida por el atacante en Firefox, y la única condición es estar en la misma red y que la víctima tenga corriendo Firefox.
El fallo es simple. El atacante desde la misma red WiFi engaña al navegador indicándole que hay un servidor SSDP (Simple Service Discovery Protocol) con una configuración determinada. Firefox siempre está buscando servidores SSDP en otros dispositivos, por si pudiera proyectar algo en ellos. Así que cuando encuentra el del atacante, este le responde con un XML con las especificaciones del dispositivo UPnP que puede encontrar en la red. Y en ellas puede ir la URL maliciosa que el atacante hace visitar a la víctima sin que esta tenga que hacer absolutamente nada. La página aparecerá visitada en su dispositivo.
Existe prueba de concepto muy sencilla de ejecutar.
Más información: https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/red-team-tech-notes/-/blob/master/firefox-android-2020/ffssdp.py
El fallo es simple. El atacante desde la misma red WiFi engaña al navegador indicándole que hay un servidor SSDP (Simple Service Discovery Protocol) con una configuración determinada. Firefox siempre está buscando servidores SSDP en otros dispositivos, por si pudiera proyectar algo en ellos. Así que cuando encuentra el del atacante, este le responde con un XML con las especificaciones del dispositivo UPnP que puede encontrar en la red. Y en ellas puede ir la URL maliciosa que el atacante hace visitar a la víctima sin que esta tenga que hacer absolutamente nada. La página aparecerá visitada en su dispositivo.
Existe prueba de concepto muy sencilla de ejecutar.
Más información: https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/red-team-tech-notes/-/blob/master/firefox-android-2020/ffssdp.py
GitLab
firefox-android-2020/ffssdp.py · master · GitLab.com / GitLab Security Division / Security Operations Department / Red Team / Red…
As we come across interesting things that we want to share with the community we will document them here as a tech note.
Sobre ZeroLogon y la necesidad de cambiar también el valor del registro (segunda fase del parche), surgía la duda de cómo aplicando solo la primera fase del parche se rompía la PoC. No se sabía exactamente por qué. Ahora se conoce que Microsoft hizo más de lo que contó.
En 0patch han reverseado el parche. No solo añadía los nuevos eventos y la posibilidad de bloquear toda comunicación RPC no segura a través de un valor de registro, sino que introducía 29 instrucciones más. Oficialmente, el cambio era: "If none of the first 5 bytes of the client challenge is unique, the server MUST fail session-key negotiation without further processing of the following steps."
¿Qué significa? La PoC enviaba "todo ceros" como desafío y a cambio una de cada 256 veces se devolvía el acceso sin necesidad de conocer la contraseña. Ahora el protocolo comprueba si el challenge que se envía comienza por 00000, 11111, 22222, 33333…. Esta era la base que aprovecha el exploit para acertar esa una de cada 256 veces. Con el parche, si es así, ahora el servidor aborta cuando le llega un valor como ese.
Así, en realidad no han solucionado el fallo de serie en AES-CFB8 sino que se han centrado en que el vector de explotación no funcione. En este caso, parece que se corta de raíz el problema actual porque enviar challenges que sean "todos los dígitos iguales" es una condición indispensable el para hacer funcionar el exploit.
En resumen, aplicando el parche sin cambiar el valor del registro se está a salvo de esta PoC, que no es poco. ¿Existe alguna forma de eludir esta solución que, sin anunciarla bien, ha introducido Microsoft? Probablemente no, aunque aun así puede tener sentido adelantarse a febrero para estar seguros y realizar ya el cambio en el registro.
Más información: https://blog.0patch.com/2020/09/micropatch-for-zerologon-perfect.html
En 0patch han reverseado el parche. No solo añadía los nuevos eventos y la posibilidad de bloquear toda comunicación RPC no segura a través de un valor de registro, sino que introducía 29 instrucciones más. Oficialmente, el cambio era: "If none of the first 5 bytes of the client challenge is unique, the server MUST fail session-key negotiation without further processing of the following steps."
¿Qué significa? La PoC enviaba "todo ceros" como desafío y a cambio una de cada 256 veces se devolvía el acceso sin necesidad de conocer la contraseña. Ahora el protocolo comprueba si el challenge que se envía comienza por 00000, 11111, 22222, 33333…. Esta era la base que aprovecha el exploit para acertar esa una de cada 256 veces. Con el parche, si es así, ahora el servidor aborta cuando le llega un valor como ese.
Así, en realidad no han solucionado el fallo de serie en AES-CFB8 sino que se han centrado en que el vector de explotación no funcione. En este caso, parece que se corta de raíz el problema actual porque enviar challenges que sean "todos los dígitos iguales" es una condición indispensable el para hacer funcionar el exploit.
En resumen, aplicando el parche sin cambiar el valor del registro se está a salvo de esta PoC, que no es poco. ¿Existe alguna forma de eludir esta solución que, sin anunciarla bien, ha introducido Microsoft? Probablemente no, aunque aun así puede tener sentido adelantarse a febrero para estar seguros y realizar ya el cambio en el registro.
Más información: https://blog.0patch.com/2020/09/micropatch-for-zerologon-perfect.html
0Patch
Micropatch for Zerologon, the "perfect" Windows vulnerability (CVE-2020-1472)
by Mitja Kolsek, the 0patch Team The Zerologon vulnerability allows an attacker with network access to a Windows Domain Controller...
Del código filtrado de código en Windows XP, se pueden destacar algunos asuntos a falta de un análisis a fondo del código.
* No es el único. En mayo de 2020 se filtró el código de la Xbox original y NT 3.5; en 2017, algunas partes de Windows 10; y en 2004, algunas partes de NT y 2000. Esta recopilación, contiene muchos de esos leaks.
* De los 43 Gbs de datos, 27 Gbs corresponden a las patentes de Microsoft. Además contiene un buen puñado de artículos anteriores, documentales relacionados sobre Microsoft, vídeos con declaraciones… Todos ya conocidos pero reunidos bajo una misma temática.
* En la recopilación se incluye un windows_xp_source.rar, cifrado con contraseña. El autor de la recopilación insta a crackear el hash $RAR3$*0*c9292efa2e495f90*044d2e5042869449c10f890c1cced438“ para conocer su contenido.
* El fichero más llamativo es Nt5src.7z de aproximadamente 2.4 Gbs. Contiene el código del kernel 5 (compartido por 2003 y XP).
* La inmensa mayoría de los ficheros están fechados el 2 de septiembre de 2002. El Service Pack salió oficialmente el día 9.
Más información: https://empresas.blogthinkbig.com/curiosidades-sobre-filtrado-codigo-windows-xp/
* No es el único. En mayo de 2020 se filtró el código de la Xbox original y NT 3.5; en 2017, algunas partes de Windows 10; y en 2004, algunas partes de NT y 2000. Esta recopilación, contiene muchos de esos leaks.
* De los 43 Gbs de datos, 27 Gbs corresponden a las patentes de Microsoft. Además contiene un buen puñado de artículos anteriores, documentales relacionados sobre Microsoft, vídeos con declaraciones… Todos ya conocidos pero reunidos bajo una misma temática.
* En la recopilación se incluye un windows_xp_source.rar, cifrado con contraseña. El autor de la recopilación insta a crackear el hash $RAR3$*0*c9292efa2e495f90*044d2e5042869449c10f890c1cced438“ para conocer su contenido.
* El fichero más llamativo es Nt5src.7z de aproximadamente 2.4 Gbs. Contiene el código del kernel 5 (compartido por 2003 y XP).
* La inmensa mayoría de los ficheros están fechados el 2 de septiembre de 2002. El Service Pack salió oficialmente el día 9.
Más información: https://empresas.blogthinkbig.com/curiosidades-sobre-filtrado-codigo-windows-xp/
Think Big
Curiosidades sobre el filtrado de código de Windows XP
La atención se centraba hace unos días en Reddit, dentro de una comunidad que se caracteriza por sus teorías conspiranoicas. Según las noticias consistía
Parece obvio, pero nadie había caído en la cuenta. El cortafuegos de Windows, no aplica sobre WSL 2, el sistema de Linux en Windows. En cierta manera, hay que tenerlo en cuenta y puede ser relevante.
Windows Subsystem for Linux tiene dos versiones. En la primera, se trataba de un kernel Linux que se traducía a llamadas a Windows. En este caso, el cortafuegos integrado (tanto entrante como saliente) de Windows, finalmente recogía esas peticiones y su configuración aplicaba. Pero WSL 2 es distinto, se trata de un kernel Linux completo en Hiper-V. Y por tanto, obvia e ignora el cortafuegos del sistema operativo donde se aloja. ¿Puede ser una vía de escape para atacantes? Esta curiosidad la han descubierto desarrolladores de VPN, que se han dado cuenta de que puede se filtre algo de tráfico a través del subsistema, puesto que ellos, por ejemplo, bloqueaban en Windows todo su tráfico que no pasase por su túnel VPN.
No estaría demás tener en cuenta que, además de usar el wf.msc (comando para acceder al sistema completo de cortafuegos de Windows), se complementara con una lista de Iptables, dado el caso.
Más información: https://mullvad.net/en/blog/2020/9/30/linux-under-wsl2-can-be-leaking/
Windows Subsystem for Linux tiene dos versiones. En la primera, se trataba de un kernel Linux que se traducía a llamadas a Windows. En este caso, el cortafuegos integrado (tanto entrante como saliente) de Windows, finalmente recogía esas peticiones y su configuración aplicaba. Pero WSL 2 es distinto, se trata de un kernel Linux completo en Hiper-V. Y por tanto, obvia e ignora el cortafuegos del sistema operativo donde se aloja. ¿Puede ser una vía de escape para atacantes? Esta curiosidad la han descubierto desarrolladores de VPN, que se han dado cuenta de que puede se filtre algo de tráfico a través del subsistema, puesto que ellos, por ejemplo, bloqueaban en Windows todo su tráfico que no pasase por su túnel VPN.
No estaría demás tener en cuenta que, además de usar el wf.msc (comando para acceder al sistema completo de cortafuegos de Windows), se complementara con una lista de Iptables, dado el caso.
Más información: https://mullvad.net/en/blog/2020/9/30/linux-under-wsl2-can-be-leaking/
Mullvad VPN
Linux under WSL2 can be leaking | Mullvad VPN
We have found that you could be leaking your Internet traffic when running Linux under WSL2 (Windows Subsystem for Linux 2).
Desde que en 2012 Tavis Ormandi ridiculizara la seguridad de los sistemas Sophos, o desde que Joxean Koret publicara en 2015 el “Antivirus Hacker's Handbook”, cada cierto tiempo aparecen noticias sobre la inseguridad de los antivirus. Se plantea la duda de quién vigila al vigilante y surgen las preocupaciones. En realidad, cualquier sistema de defensa sufre de vulnerabilidades y su importancia (como en el resto de los fallos de otros sistemas) depende de sus características, capacidad de respuesta y utilidad para el atacante. No es lo mismo que permita ejecutar código en el sistema que eludir las protecciones. Efectivamente, a los sistemas de defensa se les presupone un especial cuidado en la forma de programar, de evitar vulnerabilidades, de anticiparse a los fallos comunes que pueden cometer otros programadores. Pero es imposible estar libre de ellas, más cuando a la complejidad de la operativa propia del antivirus, añadimos que por definición debe tener el control del sistema por completo. Así que, como indicábamos, cada cierto tiempo aparecen estos fallos con ciertos titulares alarmistas.
CyberArk ha publicado una serie de fallos que, aunque no excesivamente graves, sí resultan preocupantemente comunes. Afectan a Kaspersky, McAfee, Symantec, Fortinet, Checkpoint, Trend Micro, Avira, Microsoft, Avast y F-Secure. Casi todas corregidas y que se pueden resumir en tres categorías:
* Muchos programas no establecen correctamente los permisos del directorio de sistema ProgramData. Esto puede llevar a elevación de privilegios.
* Otros tantos confían en sistemas de instalación de terceros que no actualizan. Así, si estos son vulnerables a DLL Hijacking, durante la instalación se podría realizar este ataque.
Investigando bajo estas premisas han conseguido corregir varios CVE en los sistemas antivirus. Pero no, por muchos titulares que se escriban a partir de esta información del tipo “los antivirus podrían hacer el sistema operativo más inseguro”, no por ello es necesario prescindir de estos sistemas de defensa.
Más información: https://www.cyberark.com/resources/threat-research-blog/anti-virus-vulnerabilities-who-s-guarding-the-watch-tower
CyberArk ha publicado una serie de fallos que, aunque no excesivamente graves, sí resultan preocupantemente comunes. Afectan a Kaspersky, McAfee, Symantec, Fortinet, Checkpoint, Trend Micro, Avira, Microsoft, Avast y F-Secure. Casi todas corregidas y que se pueden resumir en tres categorías:
* Muchos programas no establecen correctamente los permisos del directorio de sistema ProgramData. Esto puede llevar a elevación de privilegios.
* Otros tantos confían en sistemas de instalación de terceros que no actualizan. Así, si estos son vulnerables a DLL Hijacking, durante la instalación se podría realizar este ataque.
Investigando bajo estas premisas han conseguido corregir varios CVE en los sistemas antivirus. Pero no, por muchos titulares que se escriban a partir de esta información del tipo “los antivirus podrían hacer el sistema operativo más inseguro”, no por ello es necesario prescindir de estos sistemas de defensa.
Más información: https://www.cyberark.com/resources/threat-research-blog/anti-virus-vulnerabilities-who-s-guarding-the-watch-tower
Cyberark
Anti-Virus Vulnerabilities: Who’s Guarding the Watch Tower?
This blog entry is a special anti-malware edition showcasing how the most common bugs security products suffer from can allow a standard user to escalate into a privileged user. What we found...
El acoso legal contra la compañía que considere pagar una extorsión de ransomware continúa en Estados Unidos. En julio de 2019 la confederación de alcaldes de Estados Unidos en su encuentro anual, recomendó no pagar. Si se paga, se les incentiva para seguir atacando, decían. En ese caso el estamento no iba más allá del puro posicionamiento “moral”, pues no resultaba vinculante. Luego se fue más allá. Dos propuestas de dos senadores (uno demócrata y uno republicano) contemplaban en enero de 2020 que se prohibiese gastar dinero público en estos rescates. El senador republicano proponía, además, que se cree un fondo para ayudar a las organizaciones a mejorar su ciberseguridad.
Se sigue yendo más allá. Ahora la Oficina de Control de Activos Extranjeros de la Tesorería (OFAC) comunica que “las empresas que facilitan los pagos de ransomware a los ciberdelincuentes en nombre de las víctimas, incluidas instituciones financieras, empresas de seguros y empresas involucradas en análisis forense y respuesta a incidentes no solo fomentan las futuras demandas de pago de ransomware, sino que también corren el riesgo de violar las regulaciones de la OFAC”. El objetivo sería multar tanto a los que pagan, a los intermediarios y a los que reciben el dinero (si es que pudiesen ser identificados).
En realidad se resume en que en vez de pagar, se debería colaborar con las fuerzas del orden y no involucrar a intermediarios “tapadera” bajo pena de cometer ya algo ilegal y tipificado. ¿La razón? El negocio del ransomware se ha industrializado tanto, que se han estandarizado ciertas figuras. Por supuesto, muchas empresas siguen necesitando pagar para recuperar su información y a raíz de esta necesidad, surge una oportunidad de negocio en los intermediarios que interactúan con los atacantes para darle una capa de legalidad al pago del rescate. Por ejemplo, la empresa afectada disfraza el pago de “consultoría” con una compañía que, por su lado, compensa a los atacantes y obtiene los datos necesarios para recuperar el negocio… más su comisión. Incluso en el caso de las aseguradoras, puede que les compense más pagar a los atacantes que al afectado por los daños sufridos, por lo que se convierten también en una especie de intermediarias.
Más información: https://krebsonsecurity.com/2020/10/ransomware-victims-that-pay-up-could-incur-steep-fines-from-uncle-sam/
Se sigue yendo más allá. Ahora la Oficina de Control de Activos Extranjeros de la Tesorería (OFAC) comunica que “las empresas que facilitan los pagos de ransomware a los ciberdelincuentes en nombre de las víctimas, incluidas instituciones financieras, empresas de seguros y empresas involucradas en análisis forense y respuesta a incidentes no solo fomentan las futuras demandas de pago de ransomware, sino que también corren el riesgo de violar las regulaciones de la OFAC”. El objetivo sería multar tanto a los que pagan, a los intermediarios y a los que reciben el dinero (si es que pudiesen ser identificados).
En realidad se resume en que en vez de pagar, se debería colaborar con las fuerzas del orden y no involucrar a intermediarios “tapadera” bajo pena de cometer ya algo ilegal y tipificado. ¿La razón? El negocio del ransomware se ha industrializado tanto, que se han estandarizado ciertas figuras. Por supuesto, muchas empresas siguen necesitando pagar para recuperar su información y a raíz de esta necesidad, surge una oportunidad de negocio en los intermediarios que interactúan con los atacantes para darle una capa de legalidad al pago del rescate. Por ejemplo, la empresa afectada disfraza el pago de “consultoría” con una compañía que, por su lado, compensa a los atacantes y obtiene los datos necesarios para recuperar el negocio… más su comisión. Incluso en el caso de las aseguradoras, puede que les compense más pagar a los atacantes que al afectado por los daños sufridos, por lo que se convierten también en una especie de intermediarias.
Más información: https://krebsonsecurity.com/2020/10/ransomware-victims-that-pay-up-could-incur-steep-fines-from-uncle-sam/
Krebs on Security
Ransomware Victims That Pay Up Could Incur Steep Fines from Uncle Sam
Companies victimized by ransomware and firms that facilitate negotiations with ransomware extortionists could face steep fines from the U.S. federal government if the crooks who profit from the attack are already under economic sanctions, the Treasury Department…
Desde febrero no se bajaba de 100 vulnerabilidades en un mes. En este segundo martes de octubre, han sido 87 las vulnerabilidades corregidas. 21 de ellas ejecución de código remoto, pero “solo” 12 críticas. Bastantes (seis) vulnerabilidades han sido previamente reveladas como públicas aunque no parece que ninguna esté siendo aprovechada por atacantes.
La más grave CVE-2020-16898 es un fallo en la implementación de la pila TCP, en concreto en el protocolo ICMPv6 en los paquetes de anuncio de enrutamiento. La posibilidad de ser explotada es alta, incluso que se reproduzca como un gusano. Para deshabilitar esta funcionalidad temporalmente es necesario ejecutar:
netsh int ipv6 set int *NUMEROINTERFAZ* rabaseddnsconfig=disable
El número de la interfaz de red se puede saber a través del comando:
netsh interface ip show interfaces
Hay otra ejecución de código en el Windows Graphics Device Interface (GDI+) y una elevación grave en Hyper-V.
Más información: https://portal.msrc.microsoft.com/en-us/security-guidance
La más grave CVE-2020-16898 es un fallo en la implementación de la pila TCP, en concreto en el protocolo ICMPv6 en los paquetes de anuncio de enrutamiento. La posibilidad de ser explotada es alta, incluso que se reproduzca como un gusano. Para deshabilitar esta funcionalidad temporalmente es necesario ejecutar:
netsh int ipv6 set int *NUMEROINTERFAZ* rabaseddnsconfig=disable
El número de la interfaz de red se puede saber a través del comando:
netsh interface ip show interfaces
Hay otra ejecución de código en el Windows Graphics Device Interface (GDI+) y una elevación grave en Hyper-V.
Más información: https://portal.msrc.microsoft.com/en-us/security-guidance
JScript no es JavaScript, sino una implementación propia de Microsoft del estándar ECMAScript, utilizada en Internet Explorer pero en desuso (prácticamente desde que apareció). JScript, como muchas otras tecnologías propias de Microsoft diseñadas en contraposición de un estándar aceptado, tenía tres problemas:
* Quedó obsoleto en 2009 con la aparición de IE 8, pero por supuesto, por compatibilidad hacia atrás se mantenía en los últimos Internet Explorer. En concreto se interpretaba en las librerías jscript.dll (para las versiones más antiguas de JScript) y jscript9.dll (en esta última más moderna se interpreta JavaScript y JScript). La primera librería podía renombrarse o cambiar permisos para estar seguro, en la segunda a consecuencia de unir también JavaScript, no permitía esta mitigación.
* Sufría de vulnerabilidades. Al menos una grave por año en los últimos tiempos, aprovechada siempre por atacantes avanzados.
* Aun así, no podía ser deshabilitado desde las zonas de Internet Explorer, donde habitualmente se podía fortalecer el navegador deshabilitando muchas funciones potencialmente peligrosas.
Con la actualización de octubre, Microsoft ha incluido una entrada en el registro que deshabilita JScript en Internet Explorer 11 para aquellos que sigan usándolo. Algo que siempre debió poder hacerse a través de la configuración de zonas de seguridad, pero que solo ahora es posible. Las instrucciones para conseguirlo, en el apartado de más información.
Más información: https://support.microsoft.com/en-us/help/4586060/option-to-disable-jscript-execution
* Quedó obsoleto en 2009 con la aparición de IE 8, pero por supuesto, por compatibilidad hacia atrás se mantenía en los últimos Internet Explorer. En concreto se interpretaba en las librerías jscript.dll (para las versiones más antiguas de JScript) y jscript9.dll (en esta última más moderna se interpreta JavaScript y JScript). La primera librería podía renombrarse o cambiar permisos para estar seguro, en la segunda a consecuencia de unir también JavaScript, no permitía esta mitigación.
* Sufría de vulnerabilidades. Al menos una grave por año en los últimos tiempos, aprovechada siempre por atacantes avanzados.
* Aun así, no podía ser deshabilitado desde las zonas de Internet Explorer, donde habitualmente se podía fortalecer el navegador deshabilitando muchas funciones potencialmente peligrosas.
Con la actualización de octubre, Microsoft ha incluido una entrada en el registro que deshabilita JScript en Internet Explorer 11 para aquellos que sigan usándolo. Algo que siempre debió poder hacerse a través de la configuración de zonas de seguridad, pero que solo ahora es posible. Las instrucciones para conseguirlo, en el apartado de más información.
Más información: https://support.microsoft.com/en-us/help/4586060/option-to-disable-jscript-execution
Microsoft
Option to disable JScript execution in Internet Explorer
Describes how to disable JScript execution in Internet Explorer.
Aunque ya van tres en un año, sigue siendo noticia encontrar vulnerabilidades aprovechadas por atacantes en Chrome. Se acaba de corregir un fallo en FreeType (librería de código abierto) que al parecer estaban siendo aprovechado por atacantes. No se han dado más detalles al respecto.
La versión 86.0.4240.111 corrige este fallo, encontrado por el equipo ProjectZero de la propia Google. FreeType ha corregido también el fallo en su código. Lo interesante del fallo en Chrome son varios aspectos:
* Lo difícil en Chrome no es encontrar vulnerabilidades sino convertirlas en algo útil. Y para ello es necesario eludir su sandbox, siempre un reto. Parece que en este fallo también lo han conseguido.
* Se supone que los atacantes lo han conseguido, aunque no se han dado detalles. Y el fallo, que parece no trivial, ha sido encontrado en FreeType, de código abierto, aun habiendo pasado varios procesos de fuzzing.
* FreeType es usado en otros proyectos… también podrían ser vulnerables. Ahora los atacantes tienen una oportunidad para analizar el parche y entender cómo funciona el problema.
Esta nueva versión también corrige otros fallos graves, solo que no parecen aprovechados por atacantes o son más difíciles de explotar.
Más información: https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html
La versión 86.0.4240.111 corrige este fallo, encontrado por el equipo ProjectZero de la propia Google. FreeType ha corregido también el fallo en su código. Lo interesante del fallo en Chrome son varios aspectos:
* Lo difícil en Chrome no es encontrar vulnerabilidades sino convertirlas en algo útil. Y para ello es necesario eludir su sandbox, siempre un reto. Parece que en este fallo también lo han conseguido.
* Se supone que los atacantes lo han conseguido, aunque no se han dado detalles. Y el fallo, que parece no trivial, ha sido encontrado en FreeType, de código abierto, aun habiendo pasado varios procesos de fuzzing.
* FreeType es usado en otros proyectos… también podrían ser vulnerables. Ahora los atacantes tienen una oportunidad para analizar el parche y entender cómo funciona el problema.
Esta nueva versión también corrige otros fallos graves, solo que no parecen aprovechados por atacantes o son más difíciles de explotar.
Más información: https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html
Chrome Releases
Stable Channel Update for Desktop
The stable channel has been updated to 86.0.4240.111 for Windows, Mac & Linux which will roll out over the coming days/weeks. A list of all...
El control de entrada a un Store de apps o sistema similar es útil, pero no infalible. Los hay más o menos eficaces. Por ejemplo del desastre de Google Play (donde el adware y malware es constante) hasta la cuasi inexpugnable AppStore de Apple (aunque a veces vulnerada), pasando por Web Store de Chrome donde a veces se cuela malware. Ninguno se ha librado. Ahora le ha tocado al nuevo sistema de “notarización” de Apple.
La notarización, en marcha desde principios de año, escanea automáticamente las apps de MacOS antes de ser distribuidas. Si pasan esta prueba, se meten en la lista blanca de GateKeeper y así ya no aparecen pop ups sobre seguridad. Pero ya les han colado adware y malware.
* La primera vez en agosto. Cuarenta programas que en realidad eran Shlayer y BundleCore.
* La segunda vez en octubre, seis apps han conseguido entrar como lista blanca en GateKeeper. En realidad se trataba del adware MacOffers. Se hacían pasar por instaladores de Flash (un clásico en el adware y malware).
Por cierto, en este último caso se usaba esteganografía para ocultar el malware. Una imagen JPEG contenía también un archivo zip en base64 que en realidad alojaba la aplicación maliciosa.
Más información: https://www.intego.com/mac-security-blog/apple-notarizes-new-mac-malware-again/
La notarización, en marcha desde principios de año, escanea automáticamente las apps de MacOS antes de ser distribuidas. Si pasan esta prueba, se meten en la lista blanca de GateKeeper y así ya no aparecen pop ups sobre seguridad. Pero ya les han colado adware y malware.
* La primera vez en agosto. Cuarenta programas que en realidad eran Shlayer y BundleCore.
* La segunda vez en octubre, seis apps han conseguido entrar como lista blanca en GateKeeper. En realidad se trataba del adware MacOffers. Se hacían pasar por instaladores de Flash (un clásico en el adware y malware).
Por cierto, en este último caso se usaba esteganografía para ocultar el malware. Una imagen JPEG contenía también un archivo zip en base64 que en realidad alojaba la aplicación maliciosa.
Más información: https://www.intego.com/mac-security-blog/apple-notarizes-new-mac-malware-again/
The Mac Security Blog
Apple notarizes new Mac malware… again - The Mac Security Blog
Intego exclusive: For the second time in six weeks, Apple has been caught notarizing Mac malware. This OSX/MacOffers (MaxOfferDeal) variant uses steganography and has a 0% detection rate on VirusTotal.
Como indicábamos en una noticia anterior, “Lo difícil en Chrome no es encontrar vulnerabilidades sino convertirlas en algo útil. Y para ello es necesario eludir su sandbox, siempre un reto.”. Parece que tras el fallo en FreeType que afectaba a Chrome y descubierto también por Project Zero hace algunas semanas, ahora se hace público cómo conseguían los atacantes “escapar” y elevar privilegios.
El fallo en concreto CVE-2020-17087, se encuentra en el driver Windows Kernel Cryptography (cng.sys). Se trata de un desbordamiento de enteros. Como es muy grave y ha sido encontrado siendo usado por atacantes, Google le ha dado siete días a Microsoft para corregirlo. Al no haberlo solucionado, ha ofrecido públicamente todos los detalles (prueba de concepto incluida) y espera que sea corregido el 10 de noviembre en el siguiente ciclo natural de parches.
Más información: https://bugs.chromium.org/p/project-zero/issues/detail?id=2104
El fallo en concreto CVE-2020-17087, se encuentra en el driver Windows Kernel Cryptography (cng.sys). Se trata de un desbordamiento de enteros. Como es muy grave y ha sido encontrado siendo usado por atacantes, Google le ha dado siete días a Microsoft para corregirlo. Al no haberlo solucionado, ha ofrecido públicamente todos los detalles (prueba de concepto incluida) y espera que sea corregido el 10 de noviembre en el siguiente ciclo natural de parches.
Más información: https://bugs.chromium.org/p/project-zero/issues/detail?id=2104
En algún momento ya hemos mencionado que las nuevas CA con más peso de facto son los navegadores. Han impuesto una nueva longevidad a los certificados, mucho más corta de lo que las propias CA “tradicionales” querían aun habiéndose votado en el CAB/Forum que no debía acortarse a un año. Apple lanzó la primera piedra no hace mucho y… todos le siguieron. Pero la política hacia la autonomía continúa. Ahora Chrome tendrá su propio Root Store.
Firefox lo tiene desde siempre, con un almacén propio de certificados raíz en los que confía, y sus propias políticas. Esto le otorgaba independencia pero también un dolor de cabeza a los administradores. Chrome, en todas sus plataformas, ha confiado tradicionalmente en el Root Store del sistema operativo, por lo que coincidía con el criterio de confianza de Edge, Internet Explorer en Windows, Safari si era Mac o Android si Chrome corría en esta plataforma… ahora tendrá el suyo propio.
¿Consecuencias? Relevantes con una cuota de mercado de más del 60%. Tendrá un poder especial sobre en qué certificados raíz se confía y por tanto en la experiencia de navegación de millones de usuarios, algo que hasta ahora se encontraba bajo el criterio de los sistemas operativos en mayor parte. En principio, los criterios que seguirá Chrome son los lógicos. ¿Incluirá con este movimiento más seguridad añadiendo agilidad para revocar certificados? Recordemos que Google ya dispone de sistemas propios de revocación independientes y ágiles (CRLSets) así que realmente, ya puede otorgar esa seguridad. ¿Desconfía de la root store de Windows y Apple y por tanto quiere despachar su propio criterio? En cualquier caso, con esta nueva responsabilidad, adquirirá una nueva relevancia en la gestión global de las autoridades certificadoras.
Más información: https://www.chromium.org/Home/chromium-security/root-ca-policy
Firefox lo tiene desde siempre, con un almacén propio de certificados raíz en los que confía, y sus propias políticas. Esto le otorgaba independencia pero también un dolor de cabeza a los administradores. Chrome, en todas sus plataformas, ha confiado tradicionalmente en el Root Store del sistema operativo, por lo que coincidía con el criterio de confianza de Edge, Internet Explorer en Windows, Safari si era Mac o Android si Chrome corría en esta plataforma… ahora tendrá el suyo propio.
¿Consecuencias? Relevantes con una cuota de mercado de más del 60%. Tendrá un poder especial sobre en qué certificados raíz se confía y por tanto en la experiencia de navegación de millones de usuarios, algo que hasta ahora se encontraba bajo el criterio de los sistemas operativos en mayor parte. En principio, los criterios que seguirá Chrome son los lógicos. ¿Incluirá con este movimiento más seguridad añadiendo agilidad para revocar certificados? Recordemos que Google ya dispone de sistemas propios de revocación independientes y ágiles (CRLSets) así que realmente, ya puede otorgar esa seguridad. ¿Desconfía de la root store de Windows y Apple y por tanto quiere despachar su propio criterio? En cualquier caso, con esta nueva responsabilidad, adquirirá una nueva relevancia en la gestión global de las autoridades certificadoras.
Más información: https://www.chromium.org/Home/chromium-security/root-ca-policy
Se podría decir que el Tianfu Cup es el Pwn2Own chino. Con más presión si cabe (tienen tres intentos de cinco minutos) el fin es el mismo: una competición para hacerse con el control del software, consiguiendo ejecutar código explotando fallos previamente desconocidos o con técnicas muy novedosas.
Ya el Pwn20wn suele estar dominado por investigadores chinos, pero Tianfu, más reciente, está totalmente organizado para este mercado. Y no defraudan. Qihoo 360, que ya explora buena parte de las vulnerabilidades en, por ejemplo, Windows, ha ganado esta edición. El software al que se le han encontrado fallos gravísimos de seguridad ha sido: iOS 14, Samsung Galaxy S20, Windows 10 (2004), Ubuntu, Chrome…
Y además también (aunque quizás sus fallos estén menos cotizados) a Safari, Firefox, Adobe PDF Reader, Docker (Community Edition), VMWare EXSi, QEMU, TP-Link y ASUS.
El índice de éxito es de 11 de 16 objetivos.
Más información: https://twitter.com/TianfuCup
Ya el Pwn20wn suele estar dominado por investigadores chinos, pero Tianfu, más reciente, está totalmente organizado para este mercado. Y no defraudan. Qihoo 360, que ya explora buena parte de las vulnerabilidades en, por ejemplo, Windows, ha ganado esta edición. El software al que se le han encontrado fallos gravísimos de seguridad ha sido: iOS 14, Samsung Galaxy S20, Windows 10 (2004), Ubuntu, Chrome…
Y además también (aunque quizás sus fallos estén menos cotizados) a Safari, Firefox, Adobe PDF Reader, Docker (Community Edition), VMWare EXSi, QEMU, TP-Link y ASUS.
El índice de éxito es de 11 de 16 objetivos.
Más información: https://twitter.com/TianfuCup
Twitter
TianfuCup (@TianfuCup) | Twitter
The latest Tweets from TianfuCup (@TianfuCup). Tianfu Cup PWN Contest Official Account
112 vulnerabilidades corregidas este marte por Microsoft. Nada menos que 17 críticas, 5 de ellas en las extensiones de vídeo HEVC.
De las más graves:
* CVE-2020-17087, que era la pieza que faltaba en el fallo descubierto hace unas semanas en FreeType de Chrome. Con este fallo además los atacantes salían de la sandbox.
* Un problema crítico en la cola de impresión. Hay otros que permiten la elevación de privilegios en el mismo componente.
Como dato interesante, Microsoft ha comenzado a usar activamente el sistema CVSS para evaluar la gravedad de sus fallos. Aunque para ello ha omitido la habitual explicación con más texto que ofrecía en cada informe. Aunque no fuese ajustada a los estándares, ofrecía información útil que ahora ha desaparecido.
Más información: https://msrc.microsoft.com/update-guide/
De las más graves:
* CVE-2020-17087, que era la pieza que faltaba en el fallo descubierto hace unas semanas en FreeType de Chrome. Con este fallo además los atacantes salían de la sandbox.
* Un problema crítico en la cola de impresión. Hay otros que permiten la elevación de privilegios en el mismo componente.
Como dato interesante, Microsoft ha comenzado a usar activamente el sistema CVSS para evaluar la gravedad de sus fallos. Aunque para ello ha omitido la habitual explicación con más texto que ofrecía en cada informe. Aunque no fuese ajustada a los estándares, ofrecía información útil que ahora ha desaparecido.
Más información: https://msrc.microsoft.com/update-guide/
¿Creías que después del fallo de Kamisnky en 2008 se solucionó todo? DNS sigue siendo uno de los protocolos más débiles sobre el que se sustenta (demasiado) internet. Varias universidades han podido envenenar las cachés DNS como ya se hizo entonces. Se llama SAD DNS. Es complejo de explicar, pero vamos por partes.
Para poder falsear una petición DNS y devolverle al cliente una mentira, el atacante debe saber el TxID (transaction ID) y el puerto origen UDP. Esto suponía una entropía de 32 bits (adivinar dos campos de 16 bits). SAD DNS consiste (básicamente, porque el paper es muy complejo) en inferir el puerto UDP a través de un ingenioso método que se vale de los mensajes de vuelta de error ICMP. Esto deja de nuevo una entropía de 16 bits, asumible para un ataque.
¿Cómo deducir el puerto abierto del resolvedor (la víctima a la que se le va a envenenar la caché)? Lo más sencillo es escanear todos los puertos UDP y ver cuál está abierto, pero esto lleva demasiado tiempo. Pero cuando hayas terminado, ya se ha realizado la transacción y el puerto que querías estará obsoleto. Además, si se machaca un servidor consultando puertos UDP él mismo limitará las respuestas ICMP de “error puerto cerrado” para no saturar. Todos los OS implementan este límite global. Y este límite para proteger, paradójicamente, es lo que aprovecha el ataque. El límite global es de 1000 respuestas por segundo en Linux (200 en Windows). Se trata de un contador global compartido por cualquiera que le esté preguntado. Por tanto el atacante debe:
* Enviar 1000 sondas UDP al resolvedor víctima con IPs de origen falseadas probando 1000 puertos (en realidad son lotes de 50 cada 20 ms para superar otro límite de respuestas por IP).
* Si los 1000 puertos están cerrados, la víctima devolverá (a las IPs falseadas) 1000 paquetes ICMP de error indicando que no está abierto el puerto. Si está abierto, no pasa nada, lo descarta la aplicación correspondiente en ese puerto.
* No importa que el atacante no vea los ICMP respuesta (llegan a las IPs falseada). Lo que importa es ver cuánto del límite global de 1000 respuestas por segundo “se gasta” en esa tanda.
* Antes de dejar pasar ese segundo, el atacante consulta un puerto cualquiera cerrado y si el servidor le devuelve un ICMP de “puerto cerrado”… es que no se había gastado los 1000 ICPM de “error puerto cerrado” y por tanto… en ese rango de 1000 había al menos un puerto abierto. Bingo. Como el límite es global, una respuesta de puerto cerrado significa que no se gastó el límite de 1000 repuestas de “puerto cerrado” por segundo.
* De esta forma, en tandas de 1000 consultas por segundo y comprobando si gasta o no el límite de paquetes de error “puerto cerrado”, el atacante puede ir deduciendo qué puertos están abiertos. En algo más de 65 segundos (para cubrir 65.536) tendrá mapeados los puertos abiertos del servidor. Ahora adivina el TrID por fuerza bruta, y lanza varios paquetes que confundan al resolvedor.
Hay más variantes del ataque dependiendo de cómo implemente UDP la víctima, de si es un simple forwarder o un resolvedor.
Más información: https://dl.acm.org/doi/pdf/10.1145/3372297.3417280
Para poder falsear una petición DNS y devolverle al cliente una mentira, el atacante debe saber el TxID (transaction ID) y el puerto origen UDP. Esto suponía una entropía de 32 bits (adivinar dos campos de 16 bits). SAD DNS consiste (básicamente, porque el paper es muy complejo) en inferir el puerto UDP a través de un ingenioso método que se vale de los mensajes de vuelta de error ICMP. Esto deja de nuevo una entropía de 16 bits, asumible para un ataque.
¿Cómo deducir el puerto abierto del resolvedor (la víctima a la que se le va a envenenar la caché)? Lo más sencillo es escanear todos los puertos UDP y ver cuál está abierto, pero esto lleva demasiado tiempo. Pero cuando hayas terminado, ya se ha realizado la transacción y el puerto que querías estará obsoleto. Además, si se machaca un servidor consultando puertos UDP él mismo limitará las respuestas ICMP de “error puerto cerrado” para no saturar. Todos los OS implementan este límite global. Y este límite para proteger, paradójicamente, es lo que aprovecha el ataque. El límite global es de 1000 respuestas por segundo en Linux (200 en Windows). Se trata de un contador global compartido por cualquiera que le esté preguntado. Por tanto el atacante debe:
* Enviar 1000 sondas UDP al resolvedor víctima con IPs de origen falseadas probando 1000 puertos (en realidad son lotes de 50 cada 20 ms para superar otro límite de respuestas por IP).
* Si los 1000 puertos están cerrados, la víctima devolverá (a las IPs falseadas) 1000 paquetes ICMP de error indicando que no está abierto el puerto. Si está abierto, no pasa nada, lo descarta la aplicación correspondiente en ese puerto.
* No importa que el atacante no vea los ICMP respuesta (llegan a las IPs falseada). Lo que importa es ver cuánto del límite global de 1000 respuestas por segundo “se gasta” en esa tanda.
* Antes de dejar pasar ese segundo, el atacante consulta un puerto cualquiera cerrado y si el servidor le devuelve un ICMP de “puerto cerrado”… es que no se había gastado los 1000 ICPM de “error puerto cerrado” y por tanto… en ese rango de 1000 había al menos un puerto abierto. Bingo. Como el límite es global, una respuesta de puerto cerrado significa que no se gastó el límite de 1000 repuestas de “puerto cerrado” por segundo.
* De esta forma, en tandas de 1000 consultas por segundo y comprobando si gasta o no el límite de paquetes de error “puerto cerrado”, el atacante puede ir deduciendo qué puertos están abiertos. En algo más de 65 segundos (para cubrir 65.536) tendrá mapeados los puertos abiertos del servidor. Ahora adivina el TrID por fuerza bruta, y lanza varios paquetes que confundan al resolvedor.
Hay más variantes del ataque dependiendo de cómo implemente UDP la víctima, de si es un simple forwarder o un resolvedor.
Más información: https://dl.acm.org/doi/pdf/10.1145/3372297.3417280
Si macOS no respeta la privacidad, no parece que sea precisamente por la polémica alrededor del envío OCSP y de qué programas se tienen abiertos. El informe original de Jeffrey Paul, a nuestro criterio, especula en exceso. Muestra hechos, pero la interpretación (más o menos dramática de las consecuencias) está abierta y la polémica, servida. Algunas consideraciones sobre el “descubrimiento”:
* OCSP sirve para saber si un certificado que firma un programa está revocado. Esto es una protección adicional para MacOS que ya de por sí resulta bastante estricta en seguridad con lo que se ejecuta: tenemos a gatekeeper y la notarización. Mejorable, pero es una opción de seguridad añadida.
* El envío OCSP es en texto claro, y englobaría básicamente la IP y un hash del certificado relacionable con la aplicación. También puede que Akamai, que sirve de infraestructura a Apple, pueda verlo, además de alguien en la red. Pero ya ven los dominios en peticiones DNS en claro, puertos de conexión… ¿De verdad es tan dramático que alguien con acceso a la red pueda acceder, además, hashes asociados a programas ejecutados? Es más probables que la llamada a casa de cada programa aporte más información que la comprobación OCSP.
* Se suponía que la imposibilidad de bloquear el acceso al dominio de comprobación OCSP resultaba en un signo de la intencionalidad de Apple. En realidad puede interpretarse como un intento de mejorar la seguridad, para que ningún malware pueda evitar la comprobación.
En resumen, ¿un grave problema de privacidad? No tanto. Y en todo caso, es habitual sacrificar algo de privacidad por una mayor seguridad. En este caso, una pequeña parte, pensamos. Microsoft con su SmartScreen recolecta una enorme telemetría sobre el uso de los programas que ejecuta el usuario. A cambio ofrece una seguridad adicional que para muchos merece la pena. Aun así, después de todo, Apple no recogerá más las IPs, entre otras mejoras en el futuro.
Más información: https://sneak.berlin/20201112/your-computer-isnt-yours/
* OCSP sirve para saber si un certificado que firma un programa está revocado. Esto es una protección adicional para MacOS que ya de por sí resulta bastante estricta en seguridad con lo que se ejecuta: tenemos a gatekeeper y la notarización. Mejorable, pero es una opción de seguridad añadida.
* El envío OCSP es en texto claro, y englobaría básicamente la IP y un hash del certificado relacionable con la aplicación. También puede que Akamai, que sirve de infraestructura a Apple, pueda verlo, además de alguien en la red. Pero ya ven los dominios en peticiones DNS en claro, puertos de conexión… ¿De verdad es tan dramático que alguien con acceso a la red pueda acceder, además, hashes asociados a programas ejecutados? Es más probables que la llamada a casa de cada programa aporte más información que la comprobación OCSP.
* Se suponía que la imposibilidad de bloquear el acceso al dominio de comprobación OCSP resultaba en un signo de la intencionalidad de Apple. En realidad puede interpretarse como un intento de mejorar la seguridad, para que ningún malware pueda evitar la comprobación.
En resumen, ¿un grave problema de privacidad? No tanto. Y en todo caso, es habitual sacrificar algo de privacidad por una mayor seguridad. En este caso, una pequeña parte, pensamos. Microsoft con su SmartScreen recolecta una enorme telemetría sobre el uso de los programas que ejecuta el usuario. A cambio ofrece una seguridad adicional que para muchos merece la pena. Aun así, después de todo, Apple no recogerá más las IPs, entre otras mejoras en el futuro.
Más información: https://sneak.berlin/20201112/your-computer-isnt-yours/
sneak.berlin
Your Computer Isn't Yours
The personal website of Jeffrey Paul.
Se han hecho públicas casi 50.000 direcciones IP de dispositivos VPN de Fortinet vulnerables al fallo CVE-2018-13379, que como indica su CVE, tiene ya dos años aunque se hizo pública en 2019. El problema es que el trabajo está ya totalmente hecho para los atacantes. Por un lado existe un exploit público funcional, y por otro ya alguien se ha encargado de hacer el filtrado de potenciales candidatos a ser atacados (que habitualmente implica una búsqueda en Shodan). Esto implica una presión adicional para aquellos que todavía no hayan aplicado el parche. No se sabe si absolutamente todos las IPs son verdaderas y atacables (hay algunos honeypots), aunque parece que el atacante ya hizo el ejercicio de atacarlas para estar seguro de poder recuperar la información.
El atacante tendría acceso con este fallo a archivos del sistema habitualmente no accesibles. En concreto sslvpn_websession, permitiría facilitar el acceso remoto. Los afectados son: FortiOS de 6.0.0 a 6.0.4; FortiOS de 5.6.3 a 5.6.7; FortiOS de 5.4.6 a 5.4.12.
Desde esta web se puede comprobar si una determinada dirección IP se encuentra en esa lista: https://www.segu-info.com.ar/find-ip-FG-IR-18-384
Más información: https://www.bleepingcomputer.com/news/security/hacker-posts-exploits-for-over-49-000-vulnerable-fortinet-vpns/amp/
El atacante tendría acceso con este fallo a archivos del sistema habitualmente no accesibles. En concreto sslvpn_websession, permitiría facilitar el acceso remoto. Los afectados son: FortiOS de 6.0.0 a 6.0.4; FortiOS de 5.6.3 a 5.6.7; FortiOS de 5.4.6 a 5.4.12.
Desde esta web se puede comprobar si una determinada dirección IP se encuentra en esa lista: https://www.segu-info.com.ar/find-ip-FG-IR-18-384
Más información: https://www.bleepingcomputer.com/news/security/hacker-posts-exploits-for-over-49-000-vulnerable-fortinet-vpns/amp/
Segu-Info
Vulnerabilidad Fortinet FG-IR-18-384 / CVE-2018-13379
CVE-2018-13379 / FG-IR-18-384
Usar un segundo factor de autenticación siempre es buena idea. Aunque no siempre son del todo efectivos. Un ejemplo son los códigos por SMS, un método en extinción que se sabe obsoleto y que es mucho menos robusto que otras soluciones. Pero también puede que el sistema de 2FA esté mal implementado, como ha ocurrido con cPanel, al que se le ha encontrado un fallo importante en este aspecto.
Se podía adivinar por fuerza bruta, en cuestión de minutos, unos parámetros que eludían el 2FA. Si el atacante disponía de la contraseña de la víctima por cualquier motivo, en este caso el segundo factor no cumplía su misión.
Dada la popularidad de cPanel y la cantidad de sitios web que lo usan como sistema de gestión de hostings, el fallo es relevante. Ha sido solucionado en las últimas versiones del programa.
Más información: https://www.digitaldefense.com/news/zero-day-cpanel-and-webhost-manager/
Se podía adivinar por fuerza bruta, en cuestión de minutos, unos parámetros que eludían el 2FA. Si el atacante disponía de la contraseña de la víctima por cualquier motivo, en este caso el segundo factor no cumplía su misión.
Dada la popularidad de cPanel y la cantidad de sitios web que lo usan como sistema de gestión de hostings, el fallo es relevante. Ha sido solucionado en las últimas versiones del programa.
Más información: https://www.digitaldefense.com/news/zero-day-cpanel-and-webhost-manager/
Digital Defense
Zero Day: cPanel® & WHM® Vulnerability - Digital Defense
Vulnerability for cPanel and WebHost Manager version 11.90.0.5 (90.0 Build 5); two-factor authentication bypass flaw could affect over 70 million domains.
El navegador es el nuevo campo de batalla del malware y el interés por los atacantes en las extensiones así lo confirma. No es nuevo que se cuelen extensiones maliciosas en un Web Store (en especial el de Chrome) pero sí que es noticia que lo hagan para Edge… aunque ahora es más sencillo porque al estar basado en Chromium, las extensiones son compatibles.
Se han encontrado 18 extensiones maliciosas que en esta ocasión, inyectaban publicidad. Se hacían pasar por VPNs que ni siquiera tenían versiones oficiales. En otra tanda, los atacantes simulaban versiones de extensiones oficiales, pero a las que habían añadido contenido malicioso.
Más información: www.zdnet.com/article/microsoft-removes-18-malicious-edge-extensions-for-injecting-ads-into-web-pages
Se han encontrado 18 extensiones maliciosas que en esta ocasión, inyectaban publicidad. Se hacían pasar por VPNs que ni siquiera tenían versiones oficiales. En otra tanda, los atacantes simulaban versiones de extensiones oficiales, pero a las que habían añadido contenido malicioso.
Más información: www.zdnet.com/article/microsoft-removes-18-malicious-edge-extensions-for-injecting-ads-into-web-pages
ZDNet
Microsoft removes 18 malicious Edge extensions for injecting ads into web pages
Some extensions mimicked official apps while others copied popular Chrome extensions.
Microsoft cierra el año con 58 vulnerabilidades corregidas el segundo martes de diciembre. 9 de ellas críticas y un CVSS máximo de 8.8 en Microsoft Dynamics. Exchange y Excel son especialmente castigados con seis y ocho fallos respectivamente , cinco de ellos con ejecución de código en el caso de Exchange.
Se ha hecho público además una alerta de spoofing de DNS. En principio relacionado con la fragmentación pero no explícitamente con SAD DNS. Microsoft recomienda limitar el tamaño del búfer para evitar fragmentación, lo que se traducirá en más conexiones más pequeñas al puerto 53.
Más información: https://msrc.microsoft.com/update-guide
Se ha hecho público además una alerta de spoofing de DNS. En principio relacionado con la fragmentación pero no explícitamente con SAD DNS. Microsoft recomienda limitar el tamaño del búfer para evitar fragmentación, lo que se traducirá en más conexiones más pequeñas al puerto 53.
Más información: https://msrc.microsoft.com/update-guide
Ya se conocen los detalles dl ataque a FireEye, del que publicaron muchos detalles, entre ellos, las reglas Yara para detectar potenciales ataques que se pudieran derivar del robo de sus propias herramientas. Lo más interesante es que desvela una operación encubierta muy sofisticada a la cadena de suministro.
Y es sofisticada porque han troyanizado una herramienta muy habitual de gestión de red, llamada Orion de la compañía SolarWinds, la han vuelto a firmar con el certificado legítimo de la compañía y la han subido para su descarga. Esto implica que puede haber muchos otros afectados.
A pesar de haberse hecho público estos detalles este mismo lunes (lo que implica que se conocía desde hace más tiempo) resulta llamativo que la DLL troyanizada no era detectada en masa por los antivirus a la hora de hacer el anuncio. Incluso seguía colgada en el repositorio oficial. El certificado tampoco estaba revocado.
Si la gestión de FireEye ha sido ejemplar en otros aspectos de esta crisis. ¿Se podía haber mejorado la coordinación con todos los actores para dejar atados los aspectos "reactivos" antes de la publicación de los detalles? ¿Desvelarlo así haya sido, quizás, una maniobra de presión sobre SolarWinds?
Más información: https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
Y es sofisticada porque han troyanizado una herramienta muy habitual de gestión de red, llamada Orion de la compañía SolarWinds, la han vuelto a firmar con el certificado legítimo de la compañía y la han subido para su descarga. Esto implica que puede haber muchos otros afectados.
A pesar de haberse hecho público estos detalles este mismo lunes (lo que implica que se conocía desde hace más tiempo) resulta llamativo que la DLL troyanizada no era detectada en masa por los antivirus a la hora de hacer el anuncio. Incluso seguía colgada en el repositorio oficial. El certificado tampoco estaba revocado.
Si la gestión de FireEye ha sido ejemplar en otros aspectos de esta crisis. ¿Se podía haber mejorado la coordinación con todos los actores para dejar atados los aspectos "reactivos" antes de la publicación de los detalles? ¿Desvelarlo así haya sido, quizás, una maniobra de presión sobre SolarWinds?
Más información: https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
Google Cloud Blog
SolarWinds Supply Chain Attack Uses SUNBURST Backdoor | Google Cloud Blog
A highly evasive attacker leverages a supply chain attack trojanizing SolarWinds Orion business software updates in order to distribute SUNBURST malware.