Veamos algunos datos generales de los resultados del #CyberSecurityReport20H1.

* Con respecto a Microsoft, el número total de fallos descubiertos y corregidos es de más de 600 durante el semestre. Qihoo es de nuevo la que descubre más fallos, con un total de 237 vulnerabilidades reportadas a Microsoft en lo que llevamos de año, pero con respecto al trimestre anterior, los números cambian sustancialmente (el semestre pasado fueron 79). Google pasa de descubrir 35 en el último semestre de 2019 a sólo 5 en esta primera mitad de 2020. Microsoft pasa de 48 a 17.

* En total, en iPhone se han parcheado 60 CVEs en el pasado semestre, de los cuales 5 poseen la categoría de críticos y permiten la ejecución de código arbitrario. A pesar de representar un descenso en las cifras (a falta de la segunda mitad de año), 2020 no está siendo un buen año para la seguridad de iOS.

* De los datos de Bitsight se puede observar que el inquebrantable Conficker vuelve a recuperar el “trono” de las amenazas más virulentas, mientras que también observamos un dato ciertamente preocupante: en la mayoría de los sectores se aprecia un aumento sustancial de tiempo requerido para neutralizar una amenaza.

Más información: https://empresas.blogthinkbig.com/cybersecurityreport20h1-microsoft-corrige-muchas-mas-vulnerabilidades-descubre-bastantes-menos/

Aunque parezca mentira, desde hace muchos años existe una simple estafa en la que se apremia a un usuario a saldar un pago retrasado. Puede ser una tarjeta de crédito, un impuesto… Y se le pide que, para solucionar el problema, pague en tarjetas regalo de Apple. La víctima proporciona al atacante el pin y el número por el valor acordado y éste revende la tarjeta, compra material o lo blanquea de alguna forma.

Apple ha sido demandada en California por no poner remedio efectivo a esta situación más allá de advertir en una web de la existencia de este tipo de estafas. Según los demandantes Apple se queda con un 30% de comisión, sean o no destinadas a estafadores. Apple afirma que el 100% del dinero no es recuperable tras una estafa, pero según los demandantes (que ahora buscan más pruebas para la demanda) no es cierto, y que dispone del tiempo suficiente tras una denuncia para intentar devolver al menos ese 30% de comisión a las víctimas.

Según los demandantes, Apple ha violado la California Consumers Legal Remedies Act (CLRA), y que Apple se ha beneficiado de unos 300 millones de dólares del valor total de mil millones en estafas.

Más información: https://www.zdnet.com/article/apple-sued-for-not-taking-action-against-itunes-gift-card-scams/

La carrera para proteger a largo plazo los datos sensibles contra la amenaza de los ordenadores cuánticos ha entrado en la recta final. Tras tres años de análisis de los candidatos propuestos, el NIST ha anunciado los ganadores de la segunda ronda para la selección del nuevo estándar de criptografía post-cuántica. En la tercera y última ronda, el NIST especificará uno o más algoritmos resistentes a la computación cuántica para firma digital, cifrado de clave pública y generación de claves criptográficas. Los algoritmos que pasan a la tercera ronda son Classic McEliece, CRYSTALS-KYBER, NTRU y SABER, en las categorías de cifrado de clave pública y gestión de claves; y CRYSTALS-DILITHIUM, FALCON y Rainbow, en la categoría de firma digital.

De acuerdo con el informe Post-Quantum Cryptography (PQC): A Revenue Assessment publicado el 25 de junio por la firma de analistas de tecnología cuántica Inside Quantum Technology, el mercado de software y chips de criptografía post-cuántica se disparará hasta los 9.500 millones de dólares para 2029. Aunque las capacidades de la PQC se incorporarán en numerosos dispositivos y entornos, según el informe, los ingresos de PQC se concentrarán en los navegadores web, IoT, 5G, las fuerzas de seguridad, servicios financieros, servicios de salud y la propia industria de la ciberseguridad.

Más información: https://www.nist.gov/news-events/news/2020/07/pqc-standardization-process-third-round-candidate-announcement

El grupo de atacantes Oilrig, también conocido como APT34, ha sido el primero en incorporar DoH como parte de sus ataques. Algo que se preveía y que han hecho aprovechando herramientas de terceros.

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 han aprovechado.

Usando DNS “normal” eludían ciertas alarmas, pero transmitían en texto claro. Con DoH añaden 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.

Esta es precisamente una de las polémicas alrededor de DoH, pero si se quiere privacidad en la resolución de nombres, es el precio que se de pagar.

Más información: https://www.zdnet.com/article/iranian-hacker-group-becomes-first-known-apt-to-weaponize-dns-over-https-doh/

A pesar de que en agosto se supone que han endurecido las medidas para poder evitar que se cuelen extensiones maliciosas en la Web Store de Chrome… ha vuelto a ocurrir. AdGuard ha descubierto 300 extensiones maliciosas que robaban información del usuario para prestar servicios de adware, disfrazadas de bloqueadores de anuncios falsos. Nada nuevo, lamentablemente. AdGuard va más allá y se queja abiertamente de la gestión de Google.

“Hemos necesitado tres semanas y una entrada de blog pública para que las retiren”. “Google falla a la hora de manejar la seguridad de Web Store”. Afirma un responsable de AdGuard. Y es que efectivamente, la Web Store sigue la misma filosofía que Google Play, donde es habitual encontrar adware y malware cada poco.

En junio se colaron 106 extensiones que trabajaban de forma coordinada para robar información del usuario. En mayo y abril, se detectaron más de 70. Se trataba de extensiones que se hacían pasar por gestores de wallets de bitcoins pero que en realidad robaban la información de las carteras de las víctimas. A principios de 2019, ElevenPaths encontró una extensión que robaba tarjetas de crédito de las webs y que llevaba un año online.

Más información: https://adguard.com/en/blog/fake-ad-blockers-part-3.html

120 vulnerabilidades corregidas este mes en productos Microsoft. Se cumplen así 6 meses con más de 100 vulnerabilidades corregidas en cada uno. Antes de esto, solo una vez en 2017 se sobrepasaron las 100 correcciones por mes.

* Parece que han corregido un fallo ya conocido en la forma en la que se firmaban los binarios y permitía dar por válidos ficheros mal firmados. Estaba siendo aprovechada por atacantes. (CVE-2020-1464).

* El otro fallo conocido está en Internet Explorer, una ejecución de código (CVE-2020-1380).

* Algunos de los fallos críticos importantes: En el lector de PDF de Edge, en el framework .NET (Se aprovecha subiendo un fichero a un sistema web), en el motor MSHTML y de scripting de Edge, en Outlook, en Microsoft Windows Codecs Library, el en Windows Media.

CVE-2020-1472 es especialmente interesante, se da en los controladores de dominio y se trata de una elevación vulnerando el Netlogon Remote Protocol (NRP). Este parche no soluciona el problema por completo. Si se aplica en servidores y clientes Windows, los clientes Windows no podrán elevar en el Controlador aprovechando la vulnerabilidad. Pero sí podrán los clientes no Windows que seguirán pudiendo usar NRP vulnerable. Hasta que en febrero de 2021 Microsoft fuerce por defecto el Remote Procedure Call (RPC) seguro con un canal de Netlogon seguro, el fallo no estará completamente solucionado. En resumen, este parche de agosto introduce en realidad una clave del registro FullSecureChannelProtection, que permitirá subsanar el problema, pero obviamente solo para los Windows. A partir de febrero esa clave estará activa independientemente de su valor. Microsoft ha publicado una guía para esto.

Más información: https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

No toda la información cifrada posee el mismo valor. Algunos datos lo pierden inmediatamente tras su uso, mientras que otros pueden conservarlo durante muchos años. Los ordenadores cuánticos amenazan con romper el cifrado basado en RSA, Diffie-Hellman y Curvas Elípticas, los pilares de la criptografía actual. ¿En qué momento debería una organización inquietarse y comenzar la transición hacia una criptografía cuántico-resistente?

En 2015, el director del IQC propuso la siguiente ecuación para que cada organización calcule el momento: D + T ≥ Q. Esta ecuación establece que debemos empezar a preocuparnos por el impacto de los ordenadores cuánticos cuando D (la cantidad de tiempo durante el cual deseamos que nuestros datos estén seguros) sumado a T (el tiempo que tardarán nuestros sistemas de seguridad en pasar de la criptografía clásica a la post-cuántica), sea mayor que Q (el tiempo que tardarán la computación cuántica la potencia necesaria para romper los protocolos de cifrado existentes). El valor que se baraja hoy para Q es alrededor de quince años.

Ahora bien, cambiar la tecnología de cifrado de una organización no es tarea fácil. El grupo de trabajo Quantum-Safe Cryptography (QSC) del ETSI publicó el 11 de agosto un informe técnico para ayudar a las organizaciones en su migración hacia la criptografía post-cuántica, en el que define un marco de acciones a tomar. El marco de migración, y el plan de migración que lo documenta, comprende las tres etapas siguientes:

1. Recopilación del inventario.
2. Preparación del plan de migración.
3. Ejecución de la migración.

Este informe ayudará a dar los pasos hacia una criptografía más longeva.

Más información: https://www.etsi.org/newsroom/press-releases/1805-2020-08-etsi-releases-migration-strategies-and-recommendations-for-quantum-safe-schemes

Desde febrero ha circulado en la sombra una vacuna contra la familia de malware Emotet gracias a un fallo en su código. Curiosamente, esta “vulnerabilidad” en el código de un malware ha permitido evitar la infección de muchas máquinas pero además, casi consigue un CVE.

Analistas que le pisaban los talones a la familia Emotet descubrieron que escribía una rama del registro (codificada con XOR) para persistir. Pero también comprobaba su existencia antes de establecerla. Bastaba con crear en el sistema limpio esta rama del registro con un valor falso, y el malware tendría un desbordamiento de búfer cuando lo leyese. Dejaría de funcionar y no infectaría la máquina.

Con este planteamiento crearon un sistema (EmoCrash) muy simple que creaba la rama en sistemas limpios y esto evitaba la infección. Como ventaja adicional, el hecho de que este intento de crear la rama fuese identificable a través de logs muy específico, permita recuperar muestras “inactivas” o muertas en sistemas que afortunadamente no habían sido infectados gracias a la vacuna.

Para evitar que el malware notase que se estaba desarrollando la vacuna, actuaron sigilosamente. A través de Team Cymru proporcionaron el script a 125 CERTs de todo el mundo. Desafortunadamente el 14 de agosto, Emotet modificó su código y la vacuna ya no es efectiva.
Como pequeño intento de troleo final, el investigador James Quinn que descubrió el problema, solicitó un CVE para Emotet… que la organización Mitre denegó porque no se asignan CVEs a malware…

Más información: https://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/

Malos tiempos para la seguridad de los cajeros. Hace poco se conoció que algunos atacantes estaban aprovechando un fallo en la lógica de cajeros pertenecientes a Banco Santander y presentes en Estados Unidos. Con tarjetas falsas o de prepago legítimas, conseguían sacar dinero o sobrepasar su saldo con un “truco” en el uso de las pantallas.

En principio no relacionado, el CERT de Estados Unidos ha comunicado varios fallos de seguridad en el software de los cajeros automáticos más importantes del mercado:

* En la marca NCR, en su modelo posterior a APTRA XFS 05.01.00. Dos fallos graves. Uno en el USB HID que conecta el dispensador con el ordenador. Permitiría ser SYSTEM en el sistema si se tiene acceso físico. Otro fallo es en el cálculo de claves de sesión. Permitiría que el atacante las generase y sacar dinero. Ciertas versiones de APTRA vulnerables no tienen soporte desde 2015.

* De la misma marca, las versiones APTRA XFS 04.02.01 y 05.01.00 sufren tres vulnerabilidades. Una porque directamente no cifra una comunicación, otra por usar claves de 512 bits en certificados RSA para firmar su software. Y otra porque no comprueba bien el software al actualizarse y permitiría ejecutar código desde un USB. Todas necesitan acceso al cajero.

* La otra marca dominante, Diebold Nixdorf también tiene problemas. Sus cajeros ProCash 2100xe que corran Wincor Probase versión 1.1.30 no cifran la comunicación con sus Cash/Check Deposit Modules (CCDM). Este fallo ya lo conocía la compañía desde febrero.

Más información: https://kb.cert.org/vuls/id/116713

Se ha descubierto un fallo en Google Drive que permite a un atacante engañar muy fácilmente a un usuario. Puede pensar que descarga un documento o fotografía, pero en realidad estaría descargando cualquier otro fichero con extensión diferente. O sea, malware. Es un fallo muy simple pero que se corregirá pronto. Sin embargo, tiene algunas curiosidades. Veamos cómo se realiza el ataque:

* Un atacante sube a Google Drive un documento “normal”. PDF, JPG, etc.
* Añade como nueva versión del mismo documento por ejemplo un ejecutable que sea malware. Con extensión “exe” y que nada tenga que ver con el primero subido. Servirá.
* Envía el enlace por cualquier medio a la víctima, que podrá ver el PDF en su navegador normalmente.
* El problema es que cuando lo intente descargar… en realidad bajará el ejecutable, o sea, esa supuesta versión nueva del mismo documento.

Como el usuario ve una cosa pero descarga otra, los atacantes podrían empezar a compartir documentos maliciosos masivamente que podrían confundir a las víctimas.

Un detalle no menor sobre el que no se ha hablado lo suficiente, es que el navegador no marcará como malware ese ejecutable. Si bien ese mismo fichero sería identificado como malicioso por el propio Chrome cuando se descarga bajo cualquier otra circunstancia, en este caso, al venir de Drive, no alerta sobre su maliciosidad. La razón es que Drive se basa en la reputación de la descarga, no tanto en las características del fichero. Por tanto en realidad el fallo se aprovecha de dos circunstancias: el de las versiones maliciosas y además las alertas de descargas de malware que vienen de Drive.

Más información: https://thehackernews.com/2020/08/google-drive-file-versions.html

Interesante botnet llamada Terracotta basada en Android y alojada (cómo no) en Google Play. Perpetraba ataques de tráfico y anuncios fraudulentos de una forma peculiar tanto en su tácticas como en sus técnicas. Veamos algunos detalles.

* Consiguió en junio 2 mil millones de peticiones fraudulentas, con 65.000 teléfonos infectados.
* Se disfrazaba de aplicaciones que prometían muestras gratuitas de todo tipo: cupones, tickets, incluso zapatillas. Los usuarios debían mantener la aplicación instalada hasta recibir el pedido (cosa que nunca ocurría). Con este truco se aseguraban la persistencia.
* Escritas en React, en principio solo despistaban algunos permisos. Solo uno de los módulos contenía código muy ofuscado que se comunicaba con su C2 gracias a Firebase (que permite una comunicación menos sospechosa). Contenía también fórmulas para evitar su análisis dinámico.
* A partir de ahí bajaba más código malicioso JavaScript que conseguía descargar un APK de Chromium alterado.
* A partir de ahí, el malware alteraba todos los WebViews del sistema con el del malware, lo que le permitía simular tráfico y por tanto, estafas relacionadas con la monetización de anuncios por visitas falsas.

Más información: https://www.whiteops.com/blog/terracotta-android-malware-a-technical-study

Ya se ha puesto en marcha. A partir del uno de septiembre, los certificados TLS de más de 398 días no se darán por válidos en los navegadores. Hemos pasado de certificados con una duración habitual de hasta 20 años a principios de siglo, a certificados de como máximo algo más de año.

Los principales actores de internet (Google, Microsoft, Apple, Mozilla…) y las CAs votaron hace ahora justo un año si se debía reducir el tiempo de vida de los certificados TLS/SSL obligando a que tengan un tiempo de vida máximo. El resultado fue no. Un 35% votó a favor de la reducción: Entre ellos, Google, Cisco, Apple, Microsoft, Mozilla, Opera y Qihoo360. El resto (sobre todo las CAs) votaron en contra. Pero no importó. Los navegadores tomaron la palabra. Safari en febrero afirmó unilateralmente que marcaría como inválidos los certificados creados por más de 398 días a partir del 1 de septiembre. Firefox y Chrome le siguieron. La votación entre las partes implicadas (principalmente CAs y navegadores) no sirvió para nada y demuestra quién decide realmente.

Más información: https://cybersecuritypulse.e-paths.com/index.html?lan=es#03072020

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

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

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/

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

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

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

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

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/

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/