Otro problema de procesamiento de cadenas en Apple. En 2015 se popularizó lo que se llamó “effective power”. Si se recibía una serie de caracteres Unicode (se precedía de la cadena “effective power”, pero no era esencial, el teléfono se bloqueaba. En febrero de 2018 se hizo viral que un carácter especial del indio Telegu, enviado a los sistemas Apple, podían potencialmente llegar a “brickear” el teléfono. En abril del 2020 también se consiguió un efecto parecido con caracteres Sindhi (también indio) y una bandera italiana. El sistema se bloqueaba cuando recibía estos caracteres en una notificación.

Esta vez es una cadena "%p%s%s%s%s%n" como nombre del SSID de una WiFi lo que puede hacer que se quede sin conectividad el teléfono si alguien intenta conectarse a esa red en un iOS.

Más información: https://thehackernews.com/2021/06/beware-connecting-to-this-wireless.html

Otra vez el programa de soporte de DELL le juega malas pasadas. Encadenando varias vulnerabilidades se puede llegar a controlar todo el sistema en lo que se ha llamado BIOSDisconnect. Poder ejecutar a ese nivel implica poder pasar totalmente desapercibido en una intrusión. El problema afecta a 128 modelos y, aunque parezca raro, afecta a los sistemas con Secure Boot, específicamente diseñados para que esto no ocurra.

El fallo es que la tecnología Bios Connect permite, en tiempo de “boot” conectarse por HTTPS a servidores de Dell y reconfigurar todo sus sistemas descargando una imagen. Los fallos ocurren por un lado por una validación del certificado inválida que permite que la Bios se conecte a otros sitios sin quejares, y por otros fallos de desbordamiento que permiten ejecutar código arbitrario sin restricciones a nivel UEFI.

Dell ya ha publicado actualizaciones de la BIOS para solucionarlo. También se puede deshabilitar BiosConnect del propio sistema.

Más información: https://eclypsium.com/2021/06/24/biosdisconnect/

El malware Crackonosh sorprende no por su finalidad ni su fórmula de difusión sino por su técnica para pasar desapercibido. Para difundirse, utiliza los cracks y descargas “warez” típicas que el propio usuario ejecuta, incluso a veces en modo administrador. Con lo que su fórmula para llegar al usuario es poco interesante. Sin embargo, una vez ejecutado modifica el sistema para ejecutarse en modo a prueba de fallos o “safe mode” y se reinicia en ese modo. En este formato, Windows lanza lo mínimo imprescindible (drivers incluidos) para funcionar y por tanto, no se lanza el sistema antivirus. Una vez en este formato, deshabilita el Defender y consulta si existe otro antivirus para anularlo también. En el próximo reinicio “normal” ya no funcionarán.

También deshabilita las actualizaciones y pone un icono de “check” verde falso en el sistema para que el usuario no perciba nada raro. Algo muy interesante es que no utiliza un command and control al uso, sino que envía paquetes UDP a IPs a al azar. Si encuentra en ellas nuevas versiones de sí mismo, se actualiza desde ese sistema infectado.

Finalmente, mina Monero tomando “prestados” recursos del sistema mientras pasa desapercibido. Esto le ha permitido pasar desapercibido desde 2018.

Más información: https://decoded.avast.io/danielbenes/crackonosh-a-new-malware-distributed-in-cracked-software/

Microsoft se ha dado tanta prisa en sacar parche para #printNightmare, que no ha esperado a tenerlo para todas las versiones. "Updates are not yet available for Windows 10 1607, Server 2016, or Server 2012". En todo caso queda menos de una semana para el ciclo normal de julio y es posible que en ese momento se parchee por completo.

Al parecer el parche KB5005010 no cubre tampoco por completo la vulnerabilidad de raíz, sino que se limita a intentar que no se carguen impresoras por red filtrando la ruta UNC cuando el Point&Print está configurado.

El parche ha incluido adicionalmente una clave de registro RestrictDriverInstallationToAdministrators configurable para restringir aun más la instalación.

Más información: https://support.microsoft.com/es-es/topic/kb5005010-restricting-installation-of-new-printer-drivers-after-applying-the-july-6-2021-updates-31b91c02-05bc-4ada-a7ea-183b129578a7

Otro fallo un poco absurdo en Windows. Parece ser que desde la versión 1809 de Windows, se les ha colado un permiso de lectura de usuario en el fichero SAM y en los archivos que representan las ramas del registro SYSTEM y SECURITY. ¿Qué significa? Que cualquier usuario puede acceder al fichero y obtener los hashes NTLM de las contraseñas. ¿Es grave? Sí, porque:

* Este fichero no debería ser accesible, solo por administradores y SYSTEM.

* Aunque las contraseñas estén cifradas, se puede crackear. Y si no es así, se pueden utilizar los hashes en crudo para acceder a sitios en red, por ejemplo, además de otras técnicas ya conocidas en las que se pueden utilizar como contraseña. Incluso se podría cambiar la contraseña de administrador conociendo solo el hash.

* Aunque un usuario no puede acceder al SAM bloqueado si no es administrador, se pueden usar también otras técnicas para eludirlo y aprovechar ese erróneo permiso de escritura. La más sencilla es acceder a la copia automática que hace el sistema de shadow copies de Windows.

* No solo con la SAM. Con acceso a SYSTEM y SECURITY también se puede tener bastante control sobre el sistema.

Microsoft ha reconocido el fallo con el CVE-2021-36934, y publicado una mitigación en forma de comando que elimina ese permiso que debe ser ejecutado como administrador.

icacls %windir%\system32\config\*.* /inheritance:e

Más información:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934

Windows ha metido la pata con los permisos en la SAM y permite elevar privilegios… y ahora parece que le toca al kernel de Linux. Qualys ha descubierto que creando, montando y borrando una estructura de directorio profunda con una ruta mayor de 1GB (un millón de directorios anidados, que ocupan unos 5GB de ram), se gana root. Así, este fallo permite elevar privilegios a cualquier usuario aprovechando el problema en el sistema de ficheros.

Se tiene prueba de concepto y al menos ya la mayoría de distribuciones disponen de parche. Qualys lo descubrió en junio y alertó de forma responsable del problema. Parece que se introdujo en julio de 2014 (versión 3.16).

https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt

Después de #printNightmare, y de #SeriousSAM, llega PetitPotam. Se trata de solicitar desde la red interna se peticiones SMB al protocolo MS-EFSRPC de la víctima. Al intentar autenticarse, compartirá su hash NTLM con el atacante. A partir de ahí, con técnicas conocidas de “pass the hash” puede hacerse con el controlador de dominio. En realidad es una nueva forma de explotar viejos problemas de los que el entorno de controlador de dominio de Windows sufre desde hace años. La raíz del fallo es que el atacante “provoca” a la víctima para autenticarse, de forma que le envía todo lo que necesita para robarle la información necesaria para hacerse pasar por él.

En este caso, después de “provocar” a la víctima el ataque se aprovecha el hecho de que los “Active Directory Certificate Services” usan NTLM sobre HTTP para autenticarse. Se trata de intentar obtener un certificado válido a través de IIS una vez se tiene el hash “robado”. Pero esto en realidad no tiene nada que ver con PetitPotam.

Existe una prueba de concepto. Microsoft ha emitido un “advisory” pero curiosamente en él los detalles sobre el ataque son muy escasos. Básicamente los de siempre contra relay attacks NTLM: activar Extended Protection for Authentication (EPA) o firmar los paquetes SMB. Microsoft ni siquiera menciona el vector de ataque MS-EFSRPC, pero se verá obligado a parchearlo en un futuro, porque es donde radica el fallo, en poder “pedir” a ese protocolo que una víctima intente “sin querer” autenticarse contra otra. El hecho de que luego ese hash se “aproveche” de “Active Directory Certificate Services” es simplemente una fórmula para ganar el objetivo de control del directorio activo, puesto que con ese certificado, atacante lo que hará probablemente será intentar obtener un Ticket de Kerberos firmado.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/ADV210003

PetitPotam sigue sin estar resuelto, y Microsoft sigue recomendado mirar la luna y no el dedo, esto es: deshabilitar la Web PKI en un dominio cuando en realidad el problema son dos: seguir usando protocolo de autenticación NTLM en general, y el hecho de poder conectarte por RPC a al las llamadas MS-EFSR sin autenticación. Pero a alguien se ha acordado de una solución alternativa, puesto que no se sirve parar el servicio de cifrado por completo ni por supuesto bloquear el acceso RPC al sistema: bloquear filtros RPC concretos con netsh.
En la comunicación con pipes efsrpc y lsarpc, cliente y servidor intercambian un UUID concreto para saber de qué hablan, como indica la propia documentación:

“Remote servers MAY respond to EFSRPC messages sent using the well-known endpoint \pipe\lsarpc. When connecting to \pipe\efsrpc, the server interface is identified by UUID [df1941c5-fe89-4e79-bf10-463657acf44d], version 1.0. When connecting to \pipe\lsarpc, the server interface is identified by UUID [c681d488-d850-11d0-8c52-00c04fd90f7e”

El truco consiste en bloquear estos UUID con estos comandos (guardados en un fichero txt):

rpc
filter
add rule layer=um actiontype=block add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quit

Y luego ejecutarlo con netsh -f fichero.txt

Más información: https://twitter.com/gentilkiwi/status/1421949715986403329

Microsoft va a arriesgarse y bajo el nombre de “super duper secure mode” va a sacrificar velocidad por seguridad en el navegador. Un movimiento interesante, que todavía es un “experimento”. La mitad (literalmente) de los fallos en Edge y navegadores en general vienen por JavaScript y su JIT (compilación Just in time) ya sea en motores V8, antiguo Chakra, etc. Esto aporta velocidad al “precompilar” código JavaScript pero a su vez es una enorme puerta de entrada para atacantes.

Pero esto es una apuesta porque:

* Beneficios: Eliminando JIT, atajan el problema. La mitad de vulnerabilidades, de actualizaciones, etc. Y como efecto colateral, por fin Microsoft podría meter su tecnología de mitigación de exploits y CET, ACG. Actualmente deshabilitados en el procesador JavaScript del navegador porque con JIT daban muchos falsos positivos, parecía siempre que estaban explotando algo. Se cierra una enorme puerta para los atacantes pero además será más difícil explotar las “puertas restantes”.

* Inconvenientes: Velocidad de proceso. Pero Microsoft ha estado haciendo muchas pruebas de laboratorio y en teoría, no se notaría tanto. La carga de páginas cae un 17% en el peor de los casos, pero en otros puntos (RAM, consumo de energía) puede incluso ganar algo.

En resumen, todavía no muy concluyentes los resultados, pero con esta opción piensan apartar una tecnología de hace unos 15 años que quizás ya no aporte tanto (JIT), y atajar un grave problema que sí tiene un impacto muy negativo.

Más información: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/

Muy pocas vulnerabilidades corregidas este mes (44 contando las “puras” de Microsoft y 51 contando las compartidas con Cromium) por Microsoft teniendo en cuenta el desastre en elevaciones de privilegios y Exchange que hemos sufrido en las últimas semanas. 7 son críticas, dos ya eran conocidas y una estaba siendo aprovechada por atacantes.

* De las dos conocidas, una es la famosa relacionada con la cola de impresión. CVE-2021-36936. Como hubo varios fallos al respecto, en realidad Microsoft ha atacado al comportamiento de la infame funcionalidad Point and Print, que parece origen de todos los problemas. En cualquier caso, parece que por las pruebas realizadas por varios investigadores, todavía no está por completo resuelto el problema.

* La otra es petitPotam CVE-2021-36942. Lo que ha hecho es bloquear el acceso a las llamadas API que se usaban para forzar un intento de autenticación NTLM.

* Una de las más graves sin embargo es CVE-2021-26424. Se trata de ejecución de código en la pila TCP/IP que gestiona ipv6.

* Otra muy graves es un fallo en Windows Update Medic service, que recupera el sistema de un estado dañado.

* También se han corregido 6 fallos en Chromium.

Más información: https://msrc.microsoft.com/update-guide

Es difícil seguirle la pista a todos los fallos relacionados con la cola de impresión de Microsoft que están apareciendo últimamente. Justo después de publicar una actualización que se supone corrige (aunque no está del todo confirmado que los solucione de raíz) problemas de elevación en print spooler, Microsoft acaba de reconocer otro fallo que permite elevar fácilmente a SYSTEM. CVE-2021-36958.

No da solución, solo recomienda desactivar la cola de impresión (e impedir que se imprima). Lo curioso es que ha reconocido este fallo 8 meses después de que un investigador lo reportara en diciembre de 2020. Quizás se ha visto presionada por los descubrimientos del creador de Mimikatz, que ha estado analizando los fallos desde #printNighmare.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36958

Aunque se parcheó en julio, ahora han salido los detalles de CVE-2021-33766, o ProxyToken en Exchange, que se une a la mala racha reciente de este sistema en cuestión de vulnerabilidades. Permite robar información del inbox de cualquier usuario y resulta muy sencilla de explotar con un POST donde viaje el correo de la víctima y una cookie con valor “SecurityToken=x”.

En Exchange se crean puertos 80 y 443 para su front end y 81 y 444 para su back end al que redirige esperando que resuelva la autenticación delegada si ve el SecurityToken no vacío. Pero por algún motivo, el back end (el ECP, Exchange control panel) deja pasar todo lo que le llegue con el SecurityToken no vacío porque el módulo DelegatedAuthModule que debería encargarse de autenticar, no se carga por defecto.

Para explotarlo el atacante debe conocer además un “ECP canary”, que es como una cookie de sesión. Pero cuando se intenta atacar el sistema devuelve un 500 con un valor válido que se puede reinyectar junto con la cookie “SecurityToken=x” y modificar la configuración del Exchange.

Más información: https://www.zerodayinitiative.com/blog/2021/8/30/proxytoken-an-authentication-bypass-in-microsoft-exchange-server

La NSA ha publicado un FAQ sobre criptografía cuántica, en el que aclara de forma muy sencilla algunas dudas interesantes sobre el presente y futuro de esta tecnología. Algunas respuestas interesantes:

* La NSA no sabe cuándo o incluso si en algún momento existirá un ordenador cuántico con poder suficiente como para explotar el sistema de clave pública actual. A esto se le llama un Cryptographically Relevant Quantum Computer”.

* Esto no lo dice en el FAQ, pero en 2014 se supo a través de Snowden que la NSA ya invirtió en 80 millones de dólares en un sistema un sistema cuántico capaz de romper la criptografía actual. Lo llamó “Owning de net”.

* También es importante tener en cuenta que desde 2016 puso en marcha un Post-Quantum Standardization Effort para que los algoritmos de clave pública fueran resistentes a los potenciales peligros cuánticos.

Se trata de una curiosa frase que seguramente está cuidadosamente redactada con alguna intención. En todo caso, nunca se sabe cómo se desarrollará al hardware necesario para construir el ordenador cuántico y a la vez cuánto se va a avanzar en la algoritmia necesaria para poder romper las claves actuales.

Más información: https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.PDF

Escribir sobre una vulnerabilidad en ActiveX en 2021 no deja de ser curioso. Microsoft se ha visto obligado a publicar un aviso porque los atacantes ya la están aprovechando. Se explota a través de Office. El documento tiene la habilidad de usar MSHTML (algo del tipo mshtml:// que invoca al motor de Internet Explorer en Office) a través de un objeto OLE para ver contenido web y a partir de aquí lanza un ActiveX, que no es más que una funcionalidad ya antigua de Microsoft para ejecutar código en el contexto del navegador, pero que se mantiene internamente integrado en muchos aspectos del sistema operativo. Por supuesto la ejecución ocurre de forma transparente. El fichero HTML que trae el documento es un .CPL especialmente manipulado que finalmente ejecuta una DLL.

Se espera que puedan publicar un parche para la semana que viene. Mientras, la recomendación es desactivar ActiveX en todas las zonas de Internet Explorer.

Más info:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444

Spook.js es una investigación universitaria para eludir las contramedidas que impuso Chrome en el verano de 2018 a los ataques de Spectre y Meltdown. Para impedir que se abusaran los métodos predictivos del procesador y por tanto una web tuviera acceso a datos de otra en Chrome por convivir en el mismo proceso, Chrome separó totalmente los dominios. Cada uno a su proceso y por tanto zonas de memora independientes. Esto se llamó Site Isolation.

El ataque consigue tomar cualquier dato en la memoria de una web procesada por Chrome… desde otra web procesada y solo con JavaScript. Aunque se puede usar el ataque desde una web con JavaScript, se ha implementado como extensión por una buena razón: Chrome separa los procesos de ejemplo.com y ejemplo.net y por supuesto cualquier otro diferente, pero no separa uno.ejemplo.com y dos.ejemplo.com y por tanto conviven en el mismo proceso y por tanto puede acceder por JavaScript eludiendo Site Isolation.

El ataque en todo caso no es fácil de completar y es difícil que se lleve a la vida real. Sin embargo, al menos Chrome ha reaccionado e implementará Strict Extension Isolation, una forma de que no se pueda bajo ningún concepto compartir dominios entre extensiones.

Más información: https://www.spookjs.com

Uno de los mitos más extendidos (y equivocados) es que el software libre o de código abierto es más seguro por definición porque existen miles de ojos mirándolo y corrigiendo problemas. En un mundo ideal sí, pero la realidad es que los fallos están ahí, sea abierto o cerrado, de igual forma. Incluso en el código abierto más popular puede retrasarse la detección de fallos. Según un estudio de GitHub se tardan de media cuatro años en detectar un fallo de seguridad, aunque solo un mes en arreglarlo. Cuando cada vez más, el software en general depende de piezas open source (el 94% en GitHub), esto es un problema global que se ha materializado en ataques de supply chain que pueden poner en peligro importantes infraestructuras.

Así que HackerOne, el programa de bug bounty ha dado un paso adelante a través del Internet Bug Bounty (IBB) que pondrá foco en código open source con la particularidad de que la recompensa se dividirá 80/20 entre los que la encuentren y los voluntarios que deben arreglarla. Así se incentiva el ecosistema. Los pagos van de 300 a 5000 dólares por las más críticas.

Más información: https://www.hackerone.com/internet-bug-bounty

Si no se gestiona bien la política de vulnerabilidades, las grandes compañías pueden llevarse un susto (y dar mala imagen) como ha ocurrido con Apple. Un investigador ruso bajo el nick de IllusionOfChaos, alegaba que desde mayo había reportado 4 vulnerabilidades nuevas en iOS 15 y que solo habían arreglado una en 14.7 sin mencionarlo siquiera. Tras contactar con Apple, el investigador asegura que se disculparon y que lo solucionaron en la siguiente release, pero hubo varias y nunca ocurrió.
Los fallos eran:

* Un fallo que permite acceso a todo tipo de datos privados y personales del teléfono.

* Dos fallos en NeHelper, uno que permite saber si existen otras apps instaladas y otro que permite usar Wi-Fi a una app sin requerirlo.

El cuarto arreglado en una versión anterior era en Analyticsd y permitía también acceso a información sensible.

Los fallos no son gravísimos, pero son importantes. Esto ha desatado un pequeño debate sobre las prioridades de Apple y el trato que reciben los investigadores con ánimo de ayudar en la compañía.

Más información: https://habr.com/en/post/579714/

Tras muchos reveses a la seguridad en Exchange (abanderados principalmente por ProxyLogon y varios fallos en el servicio de impresión) Microsoft decide una nueva estrategia de seguridad. En estos servidores va a desplegar de forma inminente un servicio llamado Microsoft Exchange Emergency Mitigation (EM). Se encargará de mitigar la explotación de fallos de seguridad hasta que exista parche.
En realidad ese servicio se conectará cada hora al Office Config Service (OCS) y se descargará mitigaciones en ficheros XML con mitigaciones de tres tipos:

* Reglas de rewrite para el IIS.
* Deshabilitar ciertos servicios.
* Deshabilitar app pools.

Un paso muy interesante porque mitigará muchos fallos que los administradores no se atreven a aplicar, pero por otro lado puede resultar intrusivo (en estos casos puede deshabilitarse). Se cierra la ventana a los atacantes. Igual que en los primeros 2000 Microsoft hizo automáticos los parches y poco después comenzó a crear pequeños programas para mitigar graves fallos que debían aplicarse a mano, ahora estas mitigaciones se vuelven automáticas.

Más información: https://techcommunity.microsoft.com/t5/exchange-team-blog/new-security-feature-in-september-2021-cumulative-update-for/ba-p/2783155

Apache está sufriendo varios problemas debido a una vulnerabilidad trivial y unos parches ineficaces. Con solo una petición, se puede conseguir ejecutar código en el servidor. El fallo CVE-2021-41773, se introdujo en la versión 2.4.49, en septiembre.

Se solucionó en la versión 2.4.50, pero no del todo, se trataba de un parche que realmente no solucionaba el problema y seguía siendo vulnerable (CVE-2021-42013), por lo que la versión 2.4.51, hasta ahora, parece que realmente protege del problema porque filtra todo “%%”.

El problema original recuerda mucho a los problemas de ruta transversal y codificación que sufrió IIS en 2000, y que también costó solucionar (parches para los parches constantemente). El el caso de Apache se trata de llamar en rutas ejecutables /cgi-bin al bash a través de ../../ disfrazando uno de los puntos de su codificación %2e. El segundo parche se pudo eludir codificando a su vez más y mejor estos caracteres con %%32%65.

En cualquier caso, son necesarias circunstancias especiales que no se dan por defecto para ser vulnerable con lo que el riesgo se mitiga. Por ejemplo es necesario que mod_cgi esté activo y Apache tenga permisos sobre /bin que es donde estarán los binarios interesantes para ejecutar. No por ello hay que desestimar su importancia puesto que si no se puede ejecutar, quizás sí leer ciertas fuentes de ficheros.

Más información: https://twitter.com/roman_soft/status/1446252280597078024

Este mes Microsoft parchea 81 vulnerabilidades, 3 de ellas críticas y una está siendo aprovechada por atacantes. Se trata de una elevación de privilegios en win32k.sys.

Se ha arreglado, sin demasiado detalle, otro fallo en la cola de impresión y otro en Exchange, los quebraderos de cabeza más importantes ahora para la compañía.

El fallo de elevación (CVE-2021-40449) es curioso. Se han basado en otro de 2016 para programar el exploit. Está totalmente diseñado para funcionar en servidores (lo que denota profesionalidad). Es un user-after-free en la función NtGdiResetDC del driver. La técnica es típica para la elevación, se establece un callback en la función en modo usuario, pero a la hora de la llamada del driver y en medio de la ejecución, se llama otra vez a la función y se ocupa el espacio de la memoria con una función del kernel arbitraria que se ejecutará en el contexto del kernel.

Los atacantes instalaban una herramienta que Kaspersky ha llamado MysterySnail RAT para controlar el sistema:

Más información: https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/

Si creíamos que los exploit kits estaban muertos, no parece que lo estén tanto. Lo fueron todo hace unos 10 años, podían explotar a unos navegadores todavía muy débiles y con muchos plugins vulnerables. Sin embargo apenas eran una herramienta válida para los atacantes desde hace años precisamente por lo complicado de aprovechar fallos en navegadores robustos, así que cambiaron al malware de macro entre otras estrategias y residualmente existen exploit kits para Internet Explorer.

Avast ha descubierto sin embargo que Magnitud Exploit Kit está usando una vulnerabilidad compleja y contra uno de los navegadores más difíciles de explotar, Chrome. Al parecer utilizan un fallo de abril para vulnerar a Chrome y otro fallo en Windows para elevar privilegios y poder atacar a la víctima. El primer exploit era público pero el de Windows no. ¿Han invertido tiempo en deducirlo? No es propio de este tipo de bandas de perfil más bajo. Es más, solo se conoce un ataque en junio que aprovechase esta cadena de fallos y con un perfil muy alto de atacantes y víctimas específicas. ¿Cómo lo han conseguido los de Magnitud?

Más información: https://therecord.media/exploit-kit-adds-rare-chrome-browser-attack-chain/