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
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/
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
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
TECHCOMMUNITY.MICROSOFT.COM
New security feature in September 2021 Cumulative Update for Exchange Server | Microsoft Community Hub
As part of our continued work to help you protect your Exchange Servers, in the September 2021 Cumulative Update CU we have added a new feature called the...
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
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
Twitter
RCE exploit both for Apache 2.4.49 (CVE-2021-41773) and 2.4.50 (CVE-2021-42013):
root@CT406:~# curl 'http://192.168.0.191/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh' --data 'echo Content-Type: text/plain; echo; id'
uid=1(daemon) gid=1(daemon)…
root@CT406:~# curl 'http://192.168.0.191/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh' --data 'echo Content-Type: text/plain; echo; id'
uid=1(daemon) gid=1(daemon)…
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/
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/
Securelist
MysterySnail attacks with Windows zero-day
We detected attacks with the use of an elevation of privilege exploit on multiple Microsoft Windows servers. Variants of the malware payload used along with the zero-day exploit were detected in widespread espionage campaigns. We are calling this cluster…
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/
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/
therecord.media
Exploit kit adds rare Chrome browser attack chain
The operators of the Magnitude exploit kit have added support for an attack chain targeting the Chrome web browser, a rare sighting since the very few exploit kits that are still active today have only targeted Internet Explorer over the past few years.
¿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/
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
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
Avast
UltimaSMS: A widespread premium SMS scam on the Google Play Store
An array of scam apps, including a fake photo editor, camera filter, and various games, have been promoted via Instagram and TikTok channels.
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
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
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/
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/
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
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
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
Telegram
TCCT Quiz Game
A Telefonica Tech quiz bot
Aunque ya se conocían fórmulas para descargar inadvertidamente ficheros a través de las plantillas de Office alojadas en remoto, ahora los ciertos atacantes sofisticados están usando… plantillas en ficheros RTF abiertos con Word. RTF es un formato en texto plano con una serie de etiquetas. Los atacantes se han dado cuenta de que añadiendo en la etiqueta \template una URL (incluso ofuscada) en vez de un archivo interno y renombrando el fichero a rtf.doc (para que sea abierto por Word en vez de Wordpad) se descarga el recurso en el destino. Importante destacar que no se ejecuta, sino que se solo se descarga algo en el sistema. También que es posible que aparezca un diálogo advirtiendo de que se está descargando.
Aun así, es una técnica importante porque permite que el fichero RTF modificado llegue con más facilidad al correo del destinatario puesto que es una técnica poco detectada. Una vez ahí, al abrirlo permite al atacante descargar otro fichero en el sistema objetivo de forma directa. En cierta forma es una vuelta de tuerca al viejo sistema conocido en el que se embebían recursos ejecutables dentro de un RTF que se distribuía por correo.
Más información: https://www.proofpoint.com/us/blog/threat-insight/injection-new-black-novel-rtf-template-inject-technique-poised-widespread
Aun así, es una técnica importante porque permite que el fichero RTF modificado llegue con más facilidad al correo del destinatario puesto que es una técnica poco detectada. Una vez ahí, al abrirlo permite al atacante descargar otro fichero en el sistema objetivo de forma directa. En cierta forma es una vuelta de tuerca al viejo sistema conocido en el que se embebían recursos ejecutables dentro de un RTF que se distribuía por correo.
Más información: https://www.proofpoint.com/us/blog/threat-insight/injection-new-black-novel-rtf-template-inject-technique-poised-widespread
Proofpoint
RTF Template Injection: Phishing Attachment Techniques | Proofpoint US
Proofpoint has conducted research on a new phishing attachment technique called RTF template injection, which APT threat actors are using. Learn more.
Si bien Firefox ha sido tradicionalmente más lento a la hora de incluir mejoras de seguridad en su código, se posiciona a la vanguardia en esta ocasión añadiendo RLBox, una sandbox para librerías de terceros. Firefox (y muchos otros antes) ya ejecuta en su propia sandbox el contenido de cada web y cada web a su vez en su propio proceso. Pero todavía hay un problema con el uso de librerías de terceros por parte del motor de renderizado de esa web dentro de ese proceso. Imaginemos que un fallo en la librería de proceso de vídeo, audio, fuentes, etc. permite la ejecución de código. Aprovechando el fallo, el atacante podría, sin salir de ese proceso sandboxeado por página, tener el control de esa página. Suficientemente peligroso si por ejemplo hablamos de una web de correo, o de almacenamiento en la nube.
RLBox lo que permite es precisamente crear una sandbox ligera, dentro del motor de renderizado, que aísla y comprueba las llamadas a librerías de terceros. Una mejora adicional al hecho de que el motor de renderizado de cada web esté ya de por sí dentro de un proceso ya aislado. Lo consigue llamando a las librerías y las funciones en un espacio de memoria separado y comprobado las entradas y las salidas.
Para conseguirlo se utiliza el estándar WebAssembly (código y compilado que se llama con JavaScript) para “normalizar” las funciones de la librería y una API de llamada a RLBox, que aísla las llamadas y realiza las comprobaciones de los resultados devueltos.
Por ahora lo han hecho con las librerías Graphite, Hunspell, y Ogg en
Firefox 95. Expat y Woff2 llegará en Firefox 96. RLBox puede ser usado en otros navegadores.
Más información: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/
RLBox lo que permite es precisamente crear una sandbox ligera, dentro del motor de renderizado, que aísla y comprueba las llamadas a librerías de terceros. Una mejora adicional al hecho de que el motor de renderizado de cada web esté ya de por sí dentro de un proceso ya aislado. Lo consigue llamando a las librerías y las funciones en un espacio de memoria separado y comprobado las entradas y las salidas.
Para conseguirlo se utiliza el estándar WebAssembly (código y compilado que se llama con JavaScript) para “normalizar” las funciones de la librería y una API de llamada a RLBox, que aísla las llamadas y realiza las comprobaciones de los resultados devueltos.
Por ahora lo han hecho con las librerías Graphite, Hunspell, y Ogg en
Firefox 95. Expat y Woff2 llegará en Firefox 96. RLBox puede ser usado en otros navegadores.
Más información: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/
Mozilla Hacks – the Web developer blog
WebAssembly and Back Again: Fine-Grained Sandboxing in Firefox 95
In Firefox 95, we're shipping a sandboxing technology called RLBox — developed with researchers at UC San Diego and the University of Texas
Novedades recientes e importantes sobre el fallo en Log4j. Se aprovecha una validación de entrada incorrecta al procesar solicitudes LDAP en variables de entorno que podría permitir la ejecución remota de código. Se publicó el parche 2.15.0 para mitigar el problema, bajo el CVE-2021-44228.
Pero no es suficiente. Se ha publicado otro CVE, CVE-2021-45046 para solucionar un problema que todavía persiste y que ha sido corregido en 2.16.0 eliminando fundamentalmente la clase JndiLookup.
También se está alertando de que el hecho de mantener versiones de Java más o menos recientes no elimina la vulnerabilidad. Por tanto, independientemente de la versión del entorno Java del que se disponga, es importante actualizar la librería Log4j en sí hasta la última versión e incluso aplicar medidas adicionales.
Más información: https://thehackernews.com/2021/12/second-log4j-vulnerability-cve-2021.html
Pero no es suficiente. Se ha publicado otro CVE, CVE-2021-45046 para solucionar un problema que todavía persiste y que ha sido corregido en 2.16.0 eliminando fundamentalmente la clase JndiLookup.
También se está alertando de que el hecho de mantener versiones de Java más o menos recientes no elimina la vulnerabilidad. Por tanto, independientemente de la versión del entorno Java del que se disponga, es importante actualizar la librería Log4j en sí hasta la última versión e incluso aplicar medidas adicionales.
Más información: https://thehackernews.com/2021/12/second-log4j-vulnerability-cve-2021.html
👍1
La seguridad en los navegadores ha mejorado mucho en los últimos años, pero las decenas de 0days encontrados en Chrome en los últimos tiempos, están haciendo reaccionar a la industria. Chrome ha anunciado que implementará una especificación de la W3C llamada private network access (PNA) que protegerá de que los atacantes accedan a recursos internos como routers o servidores a través de CSRF en el navegador.
Por su lado, Edge ha ido un poco más allá. Implementará un modo de navegación específicamente diseñado para mejorar la seguridad contra vulnerabilidades no conocidas (0days). Para ello, pone en marcha una serie de cambios en el registro que, activados, permitirán forzar esta seguridad y permitir excepciones. Son EnhanceSecurityMode, EnhanceSecurityModeBypassListDomains y EnhanceSecurityModeEnforceListDomains
Esto permitirá activar en el navegador tres mitigaciones contra exploits genéricos:
* Hardware-enforced Stack Protection: Que permite protección a nivel procesador (que soporte tecnología Shadow stack en AMD y llamada CET en Intel) contra ataques típicos de desbordamiento de pila.
* Arbitrary Code Guard (ACG), Si bien gracias a la tecnología CIG de Windows, un proceso no puede cargar binarios no firmados, ACG evita esto mismo con código mapeado ya en memoria.
* Content Flow Guard (CFG). Una tecnología fallida (Microsoft tuvo que dejar de pagar recompensas para quien la eludiera) para intentar evitar de nuevo exploits funcionales.
Más información:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-beta-channel#version-980110823-january-14
Por su lado, Edge ha ido un poco más allá. Implementará un modo de navegación específicamente diseñado para mejorar la seguridad contra vulnerabilidades no conocidas (0days). Para ello, pone en marcha una serie de cambios en el registro que, activados, permitirán forzar esta seguridad y permitir excepciones. Son EnhanceSecurityMode, EnhanceSecurityModeBypassListDomains y EnhanceSecurityModeEnforceListDomains
Esto permitirá activar en el navegador tres mitigaciones contra exploits genéricos:
* Hardware-enforced Stack Protection: Que permite protección a nivel procesador (que soporte tecnología Shadow stack en AMD y llamada CET en Intel) contra ataques típicos de desbordamiento de pila.
* Arbitrary Code Guard (ACG), Si bien gracias a la tecnología CIG de Windows, un proceso no puede cargar binarios no firmados, ACG evita esto mismo con código mapeado ya en memoria.
* Content Flow Guard (CFG). Una tecnología fallida (Microsoft tuvo que dejar de pagar recompensas para quien la eludiera) para intentar evitar de nuevo exploits funcionales.
Más información:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-beta-channel#version-980110823-january-14
👍1
Las macros en Excel del tipo 4.0 (también llamadas XLM) permitían insertar instrucciones de programación directamente en las celdas. Las otras, las macros “normales” estaban creadas en código VBA y se compilaban y guardaban en binario en el Excel sin poder verse. Cuando los atacantes redescubrieron este estándar 4.0 de 1993, consiguieron eludir todas las restricciones hasta el momento. Y lo han estado haciendo desde hace unos 5 años hasta ahora, que Microsoft las ha deshabilitado por defecto.
Este es el último paso contra este tipo de macros. El primero fue en julio de 2021 cuando se introdujo este tipo de macros en el flujo de AMSI, esto es, su ejecución al vuelo se analizaría por un antivirus.
Paralelamente se añadió una opción en Excel para que se pudiera habilitar las macros 4.0 y que se comportasen con la misma configuración que las VBA normales. Este botón se puso con la intención inmediata (antes de final de 2021, se dijo) de deshabilitarlas por defecto y tener que habilitarlas con esa opción.
Ahora en enero se deshabilitan por fin por defecto y quien las necesite (pocos las echarán de menos, solo los atacantes) podrá habilitarlas desde esta opción.
Más información: https://techcommunity.microsoft.com/t5/excel-blog/excel-4-0-xlm-macros-now-restricted-by-default-for-customer/ba-p/3057905
Este es el último paso contra este tipo de macros. El primero fue en julio de 2021 cuando se introdujo este tipo de macros en el flujo de AMSI, esto es, su ejecución al vuelo se analizaría por un antivirus.
Paralelamente se añadió una opción en Excel para que se pudiera habilitar las macros 4.0 y que se comportasen con la misma configuración que las VBA normales. Este botón se puso con la intención inmediata (antes de final de 2021, se dijo) de deshabilitarlas por defecto y tener que habilitarlas con esa opción.
Ahora en enero se deshabilitan por fin por defecto y quien las necesite (pocos las echarán de menos, solo los atacantes) podrá habilitarlas desde esta opción.
Más información: https://techcommunity.microsoft.com/t5/excel-blog/excel-4-0-xlm-macros-now-restricted-by-default-for-customer/ba-p/3057905
TECHCOMMUNITY.MICROSOFT.COM
Excel 4.0 (XLM) macros now restricted by default for customer protection | Microsoft Community Hub
Usage of Excel 4.0 (XLM) macros are restricted by default through the Trust Center Macro Settings.
12 años. Ese es el tiempo que ha permanecido oculta una vulnerabilidad en PolKit (antes Policykit), un sistema para la gestión de permisos ampliamente usado por las distribuciones Linux más populares. El fallo está en el componente ‘pkexec’, que permite una funcionalidad similar a ‘sudo’, es decir, ejecutar un comando con los privilegios de otra cuenta o usuario. Por lo tanto, al explotarlo, permitiría la elevación de privilegios a root, dado que ‘pkexec’ es un binario SUID root.
Además de estar presente en casi todas las distribuciones Linux, la explotación es trivial. Basta, a grosso modo, con manipular únicamente las variables de entorno para llevarla a cabo. Es decir, no se trata de un exploit al uso, en el que se tiene que evadir protecciones y poseer un contexto de ejecución favorable, sino que prácticamente el éxito de la explotación está asegurado. De hecho, para esta vulnerabilidad (con CVE-2021-4043) están apareciendo gran cantidad de exploits.
Curiosamente, la base del fallo fue descrita en 2013 en un post de un investigador australiano, Ryan Mallon, que ya advirtió que inyectando un puntero nulo en el array de argumentos a un programa podría tener consecuencias desastrosas. Aunque no pudo en ese momento identificar un vector sobre el que aplicar su hallazgo. Finalmente se ha materializado en esta elevación de privilegios, recordemos, trivial de explotar.
Más información: https://github.com/berdav/CVE-2021-4034/blob/main/cve-2021-4034.c
Además de estar presente en casi todas las distribuciones Linux, la explotación es trivial. Basta, a grosso modo, con manipular únicamente las variables de entorno para llevarla a cabo. Es decir, no se trata de un exploit al uso, en el que se tiene que evadir protecciones y poseer un contexto de ejecución favorable, sino que prácticamente el éxito de la explotación está asegurado. De hecho, para esta vulnerabilidad (con CVE-2021-4043) están apareciendo gran cantidad de exploits.
Curiosamente, la base del fallo fue descrita en 2013 en un post de un investigador australiano, Ryan Mallon, que ya advirtió que inyectando un puntero nulo en el array de argumentos a un programa podría tener consecuencias desastrosas. Aunque no pudo en ese momento identificar un vector sobre el que aplicar su hallazgo. Finalmente se ha materializado en esta elevación de privilegios, recordemos, trivial de explotar.
Más información: https://github.com/berdav/CVE-2021-4034/blob/main/cve-2021-4034.c
GitHub
CVE-2021-4034/cve-2021-4034.c at main · berdav/CVE-2021-4034
CVE-2021-4034 1day. Contribute to berdav/CVE-2021-4034 development by creating an account on GitHub.
Solo 70 vulnerabilidades corregidas este martes por Microsoft. Curiosamente, ninguna crítica, aunque sí una pública sin exploit. La más grave (que no crítica, hay varias que supuestamente permiten ejecución de código) está en Sharepoint, con un CVSS de 8.8. Parece fácil de explotar aunque necesita de algunos permisos por parte del atacante (que no son tan difíciles de conseguir). Otro fallo con gravedad 8.8 en el servidor DNS parece menos probable de explotar.
El fallo que ya se conocía es una elevación de privilegios compleja de explotar.
Y la cola de impresión sigue en el ojo del huracán. Cuatro fallos corregidos, catalogados como importantes (permitirían la elevación), han sido corregidos. Parece que Microsoft está auditando bien este código desde el fiasco de printNightmare en julio de 2021.
Más información: https://msrc.microsoft.com/update-guide/vulnerability/
El fallo que ya se conocía es una elevación de privilegios compleja de explotar.
Y la cola de impresión sigue en el ojo del huracán. Cuatro fallos corregidos, catalogados como importantes (permitirían la elevación), han sido corregidos. Parece que Microsoft está auditando bien este código desde el fiasco de printNightmare en julio de 2021.
Más información: https://msrc.microsoft.com/update-guide/vulnerability/