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/

¿Hasta dónde están dispuestos a llegar los atacantes profesionales para ganar “clientes” a los que extorsionar con ransomware? Hasta el punto de crear una compañía falsa con el único objetivo de reclutar pentesters incautos que le hicieran el trabajo sucio de entrar en las compañías atacadas sin saberlo. Los trabajadores, ya durante la entrevista, tenían que pasar una prueba: entrar en los sistemas de supuestos clientes de esa compañía falsa. Se les daban herramientas típicas de estos atacantes y se les incitaba a pasar la prueba para ver hasta dónde podían llegar “en un cliente”. Los atacantes, una vez con acceso a la víctima, lanzaban el ransomware. El supuesto trabajador creía su objetivo cumplido.

El grupo FIN7 ha hecho esto a mediados de 2020 con una empresa falsa llamada Combi Security y ahora con Bastion Secure. Decían dedicarse a la seguridad del sector público. Se ha sabido todo gracias a que Gemini Advisory, una compañía legítima se infiltró en el proceso de contratación (por Telegram) y se le pidió el trabajo de, sin firmar nada, entrar en una empresa usando las típicas herramientas de FIN7. Había respondido a algunos anuncios online en los que Bastion Secure pedía pentesters.

¿Por qué hacer esto? Una contratación en una supuesta compañía legítima es mucho más barato (unos 1200 dólares al mes en Rusia) que pagar a alguien en el underground que, al saber lo que ganan los atacantes y el riesgo que corre, probablemente pida más.

Más información: https://therecord.media/cybercrime-gang-sets-up-fake-company-to-hire-security-experts-to-aid-in-ransomware-attacks/amp/

Todavía tenemos que lidiar no solo con el malware en Google Play, sino con las estafas del tipo de suscripción a mensajes SMS premium sin consentimiento explícito del usuario, lo que hará que pague hasta unos 40 dólares al mes (en el caso de que el país limite este gasto). En ciertos países este tipo de malware es más lucrativo que en otros. En este caso, las últimas apps en Google Play encontradas por Avast (disfrazadas de otras utilidades) han tenido más impacto en Egipto, Arabia Saudí, Paquistán… No han tenido tanto impacto en España porque desde que la regulación cambió al respecto para hacer más compleja este tipo de suscripción inadvertida, no es tan sencillo crear este tipo de estafas.

La noticia aquí por tanto no el malware en Google Play ni las apps atacando ciertos países, sino curiosamente que en España, durante 2013 y hasta 2015, fueron precisamente ciertos grupos de atacantes españoles los que innovaron en este tipo de técnicas, con malware muy inteligente capaz de mejorar sus técnicas para volver a colarse una y otra ven el market y suscribir a los usuarios a este tipo de mensajes. Pero a pesar de todo, solo los detuvo de verdad un cambio en la legislación al respecto.

Más información: https://blog.avast.com/premium-sms-scam-apps-on-play-store-avast

Existen una serie de caracteres Unicode que se utilizan para cambiar el sentido del texto y favorecer la lectura en otros idiomas como el hebreo, de derecha a izquierda. Son invisibles pero, insertados en una cadena, invierten el sentido de las letras. Ya se han realizado históricamente ataques con este truco. Por ejemplo, se conocen ataques en los que se crea el nombre de un fichero con este carácter insertado: fichero[U+202E]slx.cmd y en explorador de Windows mostraría el nombre del fichero como “ficherodmc.xls”.

En la universidad de Cambridge, lo que han hecho es probar esto en diferentes lenguajes y compiladores, en los comentarios. Esto podría permitir que se diera la vuelta a un “if” y desbloquear una comprobación de seguridad. Por ejemplo, un comentario aparentemente inocentes del tipo:

/* solo para administradores */ If (isAdmin)

Podría quedar en:

/* If (isAdmin) solo para administradores */

Si se insertan varios tipos de caracteres invisibles en el punto adecuado. Se introduciría el condicional en el comentario, anulándolo e insertando el carácter en el punto exacto del comentario.

Vim, Notepad++, VisualStudio… pero sobre todo, GitHub y BitBucket son vulnerables a este problema. Y en un mundo donde cada vez el código es más colaborativo, podría llegar a suponer un problema que se escondan este tipo de “troyanos” invisibles al ojo humano. Rust ya ha corregido la vulnerabilidad en su compilador oficial.

Más información: https://arxiv.org/pdf/2111.00169.pdf

Envenenar paquetes open source usados en la programación está de moda. Dos paquetes NPM (repositorio de node.js), con 22 millones de descargas han aparecido comprometidos porque han comprometido las cuentas de sus desarrolladores.

Coa, un parser de opciones de línea de comando y rc, un cargador de configuración se han distribuido con una sorpresa: robaban contraseñas en Windows, gracias a una variante de DanaBot que descargaban. NPM ha aconsejado activar el segundo factor de autenticación de todas las cuentas.

El impacto es imposible de calcular. Una vez más, la reflexión: ¿Hasta qué punto dependemos de software y las librerías de terceros? Y por tanto, ¿hasta qué punto dependemos de la higiene en seguridad del desarrollador de turno?

Más información: https://thehackernews.com/2021/11/two-npm-packages-with-22-million-weekly.html

55 vulnerabilidades no es mucho para un mes en Microsoft. Eso sí, 6 son críticas. Cuatro se conocían de antes y dos están siendo aprovechadas por atacantes. Estas últimas son problemas en Excel que permiten eludir protecciones pero necesitan que interactúe el usuario.

Y Exchange no se libra. CVE-2021-42321. Un grave fallo que, aunque necesite que el atacante esté autenticado, llega a una gravedad de 8.8.
También se ha solucionado un grave fallo (9.0) en Virtual Machine Bus, que permitiría a un atacante salir de la máquina virtual.

Una de las más interesantes es el fallo en RDP (CVE-2021-38666) que permitiría ejecución de código remoto pero no en el servidor, sino desde el servidor hacia el cliente si este se conecta con un cliente vulnerable. Interesante para crear “honeypots” que al final se vuelvan en contra del supuesto agresor.

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

Hay que afrontar que aunque la máxima sea “no se debe negociar con atacantes de ransomware”, la realidad es muy diferente para compañías cuya alternativa es perderlo todo. Por tanto, si se va a pagar, es necesario al menos tener en cuenta algunos consejos para la negociación. Analistas de Fox-IT, tras observar un conjunto de 700 negociaciones llevadas a cabo entre 2019 y 2020, han diseccionado algunas respuestas y consejos.

Hay que entender que la cuenta atrás empieza cuando se pulsa en el enlace para chatear con el atacante. Así, previamente hay que tener muy clara la estrategia. Localizar la zona cero, la comunicación y cuánto es posible pagar. El atacante al otro lado sabe perfectamente cuánto se puede permitir pagar la víctima, pero siempre están dispuestos a rebajar algo si el atacado sabe conseguirlo.

También es importante cambiar a un chat privado, tanto para las comunicaciones con el atacante como las internas. Tras las muchas filtraciones en los últimos tiempos, es posible que un tercero en la operación tenga acceso a la negociación e interfiera a su en beneficio propio.

Y ante todo, aunque duela, la mejor estrategia es ser profesional con el atacante al otro lado. Pedir siempre más tiempo, porque funciona, para negociar, controlar la situación y evaluar daños. Conocer bien el alcance del ataque y al propio atacante es la mayor ventaja para poder negociar el rescate con algún arma por parte del atacado.

Más información:
https://research.nccgroup.com/2021/11/12/we-wait-because-we-know-you-inside-the-ransomware-negotiation-economics/

En noviembre, Microsoft arregló una elevación de privilegios en el instalador. CVE-2021-41379. Pero lo ha hecho mal. El propio descubridor ha publicado un exploit capaz de eludir el parche y volver a elevar privilegios gracias a un fallo en el sistema de instalación de MSIs. Y funciona mejor que el anterior, incluso. Ahora mismo no hay parche y no es fácil pensar en una contramedida, como indica el propio autor.

La prueba de concepto sobrescribe los permisos de el servicio de elevación de Edge (porque Edge se ejecuta con muy pocos privilegios, pero para ciertas operaciones debe elevar). Una vez sobrescrito copia ahí un programa y consigue lanzarse ejecutado.

Aparte de la gravedad, destaca otra pregunta interesante que le hizo BleepingComputer. ¿Por qué el descubridor reporta el fallo anterior de forma responsable y en este caso lanza el exploit sin previo aviso? Desde abril de 2020, los investigadores consideran que la política de Microsoft con respecto a los bug bounty es muy deficiente y deja mucho que desear. Pagan menos cada vez.

Más información: https://github.com/klinix5/InstallerFileTakeOver

Desde Telefónica Cyber Security and Cloud Tech hemos creado un bot de Telegram que permite poner a prueba tus conocimientos sobre el mundo de la ciberseguridad y el cloud. Compite con el resto de usuarios por ser el primero en el ranking.

Comienza haciendo /start en este enlace. 20 preguntas. 15 segundos para responder. 4 intentos cada 4 horas.

Más información: https://t.me/tcct_quiz_bot