De nuevo atacantes aprovechan DoH con fines maliciosos. Se trata de una nueva fórmula descubierta en un malware que ya se descubrió como bastante innovador en enero, ocultando caracteres en unos supuestos logs falsos que luego convertirían en tareas programadas. Pero iban más allá y ahora se han dado cuenta. Es relativamente sencillo. Los atacantes preguntan por un registro TXT de un dominio a través del DoH de Google.
En ese registro TXT contenía lo que parecía una típica firma DKIM… pero no, tras varios trucos de ofuscación en base64, en realidad permitía al malware recoger estos números: 1484238688, 1484238687, 2388371974 y 2388372143.
Que a su vez son… dicciones IPs en otro formato (prueba a hacerles ping). Este truco de usar registros TXT no es nuevo para el malware sofisticado, pero sí es nuevo el hecho de “abusar” de DoH de Google (un dominio que jamás será bloqueado) para esconderse y pasar desapercibido añadiendo capas de ofuscación.
No hace mucho, el grupo de atacantes Oilrig, también conocido como APT34 incorporó DoH como parte de sus ataques. Kaspersky descubrió que Oilrig normalmente usaba DNSExfiltrator, una herramienta de código abierto clásica para sacar información a través de una conexión DNS normal en texto claro. La herramienta ha añadido la opción de utilizar DoH y los atacantes la aprovecharon. Usando DNS “normal” eludían ciertas alarmas, pero transmitían en texto claro. Con DoH añadían cifrado y un protocolo poco habitual para exfiltrar información, con lo que pueden pasar algo más desapercibidos, apoyándose en servidores de CloudFare o Google.
Más información: https://blog.huntresslabs.com/hiding-in-plain-sight-part-2-dfec817c036f
En ese registro TXT contenía lo que parecía una típica firma DKIM… pero no, tras varios trucos de ofuscación en base64, en realidad permitía al malware recoger estos números: 1484238688, 1484238687, 2388371974 y 2388372143.
Que a su vez son… dicciones IPs en otro formato (prueba a hacerles ping). Este truco de usar registros TXT no es nuevo para el malware sofisticado, pero sí es nuevo el hecho de “abusar” de DoH de Google (un dominio que jamás será bloqueado) para esconderse y pasar desapercibido añadiendo capas de ofuscación.
No hace mucho, el grupo de atacantes Oilrig, también conocido como APT34 incorporó DoH como parte de sus ataques. Kaspersky descubrió que Oilrig normalmente usaba DNSExfiltrator, una herramienta de código abierto clásica para sacar información a través de una conexión DNS normal en texto claro. La herramienta ha añadido la opción de utilizar DoH y los atacantes la aprovecharon. Usando DNS “normal” eludían ciertas alarmas, pero transmitían en texto claro. Con DoH añadían cifrado y un protocolo poco habitual para exfiltrar información, con lo que pueden pasar algo más desapercibidos, apoyándose en servidores de CloudFare o Google.
Más información: https://blog.huntresslabs.com/hiding-in-plain-sight-part-2-dfec817c036f
Huntress
Managed Cybersecurity Platform | Huntress
Huntress is the enterprise-grade, people-powered cybersecurity platform for all businesses, not just the 1%.
129 vulnerabilidades corregidas por Microsoft en septiembre. Como de costumbre este año, pasando de las 100 y al igual que junio, la segunda vez que más fallos corrige en un mes. Sin duda 2020 terminará muy por encima de las 1000 vulnerabilidades corregidas. Especial gravedad una ejecución remota de código en SharePoint CVE-2020-1210, aunque este mes se han centrado en la herramienta: 16 fallos corregidos, 6 XSS y 7 ejecuciones de código tanto en cliente como en servidor además de otras de diferente índole.
Otra vulnerabilidad importante en Exchange, que lleva un muy mal año de fallos. CVE-2020-16875 permitiría ejecutar con SYSTEM en el servidor Exchange con solo enviar un correo. Existe una tercera ejecución de código en Active Directory, en el que un usuario del directorio podría elevar en el servidor.
Por su complejidad, el fallo en el Microsoft Component Object Model (COM) de Windows (CVE-2020-0922) se debe tener especialmente en cuenta puesto que podría impactar de múltiples formas en el sistema.
Por último, una vulnerabilidad interesante es CVE-2020-0951 que permite a un administrador eludir Windows Defender Application Control (WDAC), aunque no se han dado detalles.
Ningún fallo de los corregidos se conocía con anterioridad ni estaba siendo aprovechado por atacantes.
Más información: https://portal.msrc.microsoft.com/en-us/security-guidance/releasenotedetail/2020-Sep
Otra vulnerabilidad importante en Exchange, que lleva un muy mal año de fallos. CVE-2020-16875 permitiría ejecutar con SYSTEM en el servidor Exchange con solo enviar un correo. Existe una tercera ejecución de código en Active Directory, en el que un usuario del directorio podría elevar en el servidor.
Por su complejidad, el fallo en el Microsoft Component Object Model (COM) de Windows (CVE-2020-0922) se debe tener especialmente en cuenta puesto que podría impactar de múltiples formas en el sistema.
Por último, una vulnerabilidad interesante es CVE-2020-0951 que permite a un administrador eludir Windows Defender Application Control (WDAC), aunque no se han dado detalles.
Ningún fallo de los corregidos se conocía con anterioridad ni estaba siendo aprovechado por atacantes.
Más información: https://portal.msrc.microsoft.com/en-us/security-guidance/releasenotedetail/2020-Sep
Siempre es interesante encontrar pequeñas piezas de malware que atacan sistemas muy concretos. Suponen una fórmula distinta al malware cotidiano ya sea por el sistema que atacan, lo que pretenden, o las fórmulas utilizadas para conseguirlo. En este caso CDRThief no es un malware muy común pero aun así relevante. Ataca a plataformas VoIP (en concreto Linknat VOS2009 y VOS3000 encargadas de la logística de las centralistas VoIP (facturación, llamadas, etc).
Su función principal es robar los call detail records (CDR). O sea metadatos de llamadas que se encuentran en un MySQL en sistemas Linux. Desde la duración de la llamada a los destinatarios. Cifra sus cadenas internas de forma estática con contraseña para pasar desapercibido. Busca la contraseña del MySQL del sistema VoIP en la configuración de este y, aunque se encuentra cifrada, deben conocer bien la plataforma porque el malware sabe cómo descifrarla. Realiza consultas a la base de datos y luego envía la información robada (los datos de las llamadas) también cifrada con criptografía asimétrica a un servidor externo.
Todavía no se sabe cómo llega el malware al sistema infectado ni cuál es el fin concreto (obviamente el espionaje, pero no qué buscan los actores en concreto con este ataque). Se trata pues de una rareza muy concreta, sofisticada no tanto por sus habilidades como malware sino por sus métodos para obtener lo que necesita, lo que esconde un profundo conocimiento de su objetivo. En resumen, malware relacionado con el espionaje industrial.
Más información: https://www.welivesecurity.com/2020/09/10/who-callin-cdrthief-linux-voip-softswitches/
Su función principal es robar los call detail records (CDR). O sea metadatos de llamadas que se encuentran en un MySQL en sistemas Linux. Desde la duración de la llamada a los destinatarios. Cifra sus cadenas internas de forma estática con contraseña para pasar desapercibido. Busca la contraseña del MySQL del sistema VoIP en la configuración de este y, aunque se encuentra cifrada, deben conocer bien la plataforma porque el malware sabe cómo descifrarla. Realiza consultas a la base de datos y luego envía la información robada (los datos de las llamadas) también cifrada con criptografía asimétrica a un servidor externo.
Todavía no se sabe cómo llega el malware al sistema infectado ni cuál es el fin concreto (obviamente el espionaje, pero no qué buscan los actores en concreto con este ataque). Se trata pues de una rareza muy concreta, sofisticada no tanto por sus habilidades como malware sino por sus métodos para obtener lo que necesita, lo que esconde un profundo conocimiento de su objetivo. En resumen, malware relacionado con el espionaje industrial.
Más información: https://www.welivesecurity.com/2020/09/10/who-callin-cdrthief-linux-voip-softswitches/
WeLiveSecurity
Who is calling? CDRThief targets Linux VoIP softswitches
ESET researchers have discovered and analyze a malware named CDRThief, which targets China-made VoIP softswitches (software switches).
Darrin DeYoung es el protagonista de una vulnerabilidad reciente en Windows. Pero no el descubridor ni el que la explota, sino el que te aparece en la pantalla cuando se aprovecha este fallo. Porque Darrin DeYoung está en Windows se quiera o no.
Windows dispone de un modo “prueba comercial” o retail al que se llega pinchando cinco veces sobre la palabra Windows en la pantalla de activación. Aparecerá una pantalla de confirmación tras elevar privilegios.
Si se acepta se borra todo el sistema y pasa a modo “comercial”. Es una especie de modo demo. Cuando se reinicie, la cuenta Darrin DeYoung aparecerá en la pantalla de login dentro del grupo administradores. No tiene contraseña. La vulnerabilidad descubierta por Google en su Project Zero aprovecha la función de crear esta cuenta que normalmente debería requerir de privilegios.
Por defecto Windows tiene una tarea CloudExperienceHost\CreateObjectTask que sirve para crear clases COM elevadas con SYSTEM desde el usuario. Está involucrado en el proceso de paso a la prueba comercial mencionada antes. Esto es normal, solo que el servidor COM no están bien protegido por permisos. Permite ser lanzada desde el grupo “interactivo” o sea, no solo procesos y por usuarios.
Así, si un atacante puede jugar con esto creando tareas que llamen a clases elevadas, resulta que de alguna forma se puede llamar a CreateRetailDemoAccount a través de ese CloudExperienceHost y elevar. La PoC hace justo eso, lanza la tarea, y aprovecha para llamar a la función de creación de cuenta demo que habitualmente debería estar protegida.
Se trata de un fallo muy similar a otro ocurrido en 2015. El problema (CVE-2020-1471) ya ha sido corregido en las actualizaciones de septiembre.
Más información: https://bugs.chromium.org/p/project-zero/issues/detail?id=2051
Windows dispone de un modo “prueba comercial” o retail al que se llega pinchando cinco veces sobre la palabra Windows en la pantalla de activación. Aparecerá una pantalla de confirmación tras elevar privilegios.
Si se acepta se borra todo el sistema y pasa a modo “comercial”. Es una especie de modo demo. Cuando se reinicie, la cuenta Darrin DeYoung aparecerá en la pantalla de login dentro del grupo administradores. No tiene contraseña. La vulnerabilidad descubierta por Google en su Project Zero aprovecha la función de crear esta cuenta que normalmente debería requerir de privilegios.
Por defecto Windows tiene una tarea CloudExperienceHost\CreateObjectTask que sirve para crear clases COM elevadas con SYSTEM desde el usuario. Está involucrado en el proceso de paso a la prueba comercial mencionada antes. Esto es normal, solo que el servidor COM no están bien protegido por permisos. Permite ser lanzada desde el grupo “interactivo” o sea, no solo procesos y por usuarios.
Así, si un atacante puede jugar con esto creando tareas que llamen a clases elevadas, resulta que de alguna forma se puede llamar a CreateRetailDemoAccount a través de ese CloudExperienceHost y elevar. La PoC hace justo eso, lanza la tarea, y aprovecha para llamar a la función de creación de cuenta demo que habitualmente debería estar protegida.
Se trata de un fallo muy similar a otro ocurrido en 2015. El problema (CVE-2020-1471) ya ha sido corregido en las actualizaciones de septiembre.
Más información: https://bugs.chromium.org/p/project-zero/issues/detail?id=2051
A pesar de que en agosto la vulnerabilidad se calificó como de “poco probable su explotación” ya existe una prueba de concepto para aprovechar el fallo conocido como ZeroLogon. Esto permite, ni más ni menos, que cualquier usuario se haga con el control de la red interna de un sistema solo con tener acceso al controlador de dominio.
Ya son cuatro las pruebas de concepto de CVE-2020-1472, en Python y .Net que permiten aprovechar el fallo en el Netlogon Remote Protocol. El problema es que se usa mal AES con el (lentísimo) modo CFB8. La función ComputeNetlogonCredential, en vez de aleatorizar los vectores de iniciación para cada byte, usa siempre un valor fijo… todo cero. El atacante envía una media de 256 intentos de bloques de ceros hasta que consigue autenticarse y en este caso la PoC deshabilita la contraseña.
Por si fuera poco, también se ha hecho pública una prueba de concepto para CVE-2020-16875, una ejecución de código en Exchange que fue parcheada en septiembre.
Más información: https://github.com/SecuraBV/CVE-2020-1472
Ya son cuatro las pruebas de concepto de CVE-2020-1472, en Python y .Net que permiten aprovechar el fallo en el Netlogon Remote Protocol. El problema es que se usa mal AES con el (lentísimo) modo CFB8. La función ComputeNetlogonCredential, en vez de aleatorizar los vectores de iniciación para cada byte, usa siempre un valor fijo… todo cero. El atacante envía una media de 256 intentos de bloques de ceros hasta que consigue autenticarse y en este caso la PoC deshabilita la contraseña.
Por si fuera poco, también se ha hecho pública una prueba de concepto para CVE-2020-16875, una ejecución de código en Exchange que fue parcheada en septiembre.
Más información: https://github.com/SecuraBV/CVE-2020-1472
GitHub
GitHub - SecuraBV/CVE-2020-1472: Test tool for CVE-2020-1472
Test tool for CVE-2020-1472. Contribute to SecuraBV/CVE-2020-1472 development by creating an account on GitHub.
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.