Los métodos de seguridad implementados en MacOS no son los mejores, aun así los atacantes los empiezan a tener en cuenta. Parece que los creadores de Shlayer, un malware bastante popular en esta plataforma, han encontrado una forma de eludir Gatekeeper y la notarización de MacOS. Así, este malware podría ejecutarse sin lanzar ninguna alerta. En realidad el truco es bastante simple: se viste a un script como una aplicación sobre la que se puede hacer doble clic… y el sistema hace el resto porque los scripts no son analizados por GateKeeper.

El malware se ha estado distribuyendo por Google a través del posicionamiento de enlaces maliciosos que incitaban al usuario a actuzliar algún software popular. En realidad se descargaban un script que lanzaba otra serie de payloads fuera del radar de GateKeeper.

A este fallo se le ha otorgado el CVE-2021-30657 y parece que ha sido arreglado en la última actualización.

Más información: https://objective-see.com/blog/blog_0x64.html

Pagar o no pagar a los criminales que cifran los datos de una compañía, esa es la cuestión. AXA ha tomado una decisión en Francia: la cobertura del ciberseguro no devolverá el dinero del rescate a los clientes que paguen por la extorsión. Esta decisión se ha tomado en el contexto de una mesa redonda del senado en Francia que abordaba "la devastadora epidemia global de ranswomare".

La decisión de la aseguradora es de gran calado. La situación es crítica, los daños multimillonarios y las víctimas no solo se enfrentan a datos perdidos sino al filtrado público de la información si no pagan. La sensación de impotencia es generalizada. Los ciberseguros como el de AXA que podían llegar a cubrir el gasto por el pago del rescate han concluido que esta cláusula animaba precisamente a la menos traumática de las soluciones: ceder a la extorsión. Y no solo ha hecho que el negocio del seguro no sea rentable sino que ha alimentado la propia industria del cibercrimen. Recordemos que una de las estrategias contra los atacantes es que si no se les paga, el negocio de la extorsión dejará de serles rentable. Pero, ¿qué alternativa tienen muchas organizaciones que, de no pagar, se ven obligadas a cerrar? O ceden a la extorsión y alimentan el proceso que fortalece a los atacantes (y se perpetúa contra otras futuras compañías que serán venideras víctimas)… o se resisten al pago y lo pierden todo.

El negocio del ransomware no solo debe estrangularse evitando financiar la extorsión, sino también mejorando la seguridad de las compañías y con unas leyes eficaces que persigan a los criminales con penas que desincentiven los ataques. Fácil de decir, complejo de implementar. Pero una sola aproximación no basta. La decisión de AXA ha demostrado que normalizar el pago y asumir el riesgo tampoco es una opción viable por sí sola.

Más información:
https://abcnews.go.com/Technology/wireStory/insurer-axa-halts-ransomware-crime-reimbursement-france-77540351

Parchear solo 55 fallos viene siendo una anomalía para un martes de Microsoft, cuando lleva ya un buen tiempo solucionando cada mes por encima de las 100. Lo más destacado:

* Se siguen solucionando fallos en Exchange. Cinco esta vez. Uno ya se conocía.

* Hay cuatro críticas. La más importantes en la implementación de la pila del protocolo HTTP (http.sys) que permitiría la ejecución de código en el servidor. Es un problema gusanable. Las otras en hyper-V, OLE Automation, y el motor de scripting de IE 11.

* No se debe pasar por alto que el fallo en HTTP afecta también a Windows 10. Merece la pena enfatizar que no es un problema de IIS sino del sistema operativo.

* Otra vulnerabilidad importante sobre la que no se ha dado mucha información es un fallo en el sistema Wireless que permitiría revelar información.

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

La orden ejecutiva firmada por Biden pretende modernizar las defensas en ciberseguridad. Los puntos acción básicos son:

* Permite a las compañías privadas (en especial los que alojan servidores) compartir información con el gobierno. Esto agilizará el proceso de investigación.
* Mejorar y adoptar los estándares de ciberseguridad en el gobierno federal. (2FA, criptografía, SDLC…).
* Mejorar las cadenas de suministro, como ha demostrado el ataque SolarWinds. Se tendrá una especie de certificado que lo acredita, similar al de la energía o emisiones.
* Una junta o comisión de revisión de ciberseguridad privada y pública. Cuando ocurra un accidente, se gestionará y sacarán conclusiones de manera coordinada. Esta comisión está inspirada en la que ya tiene la aeronáutica, en la que el sector privado y público se reúne después de grandes incidentes aéreos.
* Se creará un sistema estándar de respuesta a incidentes tanto interno como externo.
* Mejorar la capacidad de defensa de la red federal. Quizás la medida más genérica.
* Mejorar la capacidad de remediación e investigación. Quizás esto se resume fundamentalmente en mejorar los sistemas de logs.

Esta orden ejecutiva se traducirá en que las empresas deberán cumplir unos estándares mínimos, se procedimentará, se auditará… se generará una industria más sana, más vigilada por ella misma. Más robusta y unida, esperamos. Sin embargo, todavía se echan de menos leyes más claras contra los atacantes que agilicen la posibilidad de perseguirlos, identificarlos e imponer sanciones a nivel mundial. Se debe estrangular la actividad de los atacantes desde todos esos ángulos. Un problema tan grave, aunque de naturaleza técnica, no puede solucionarse solamente desde ese mismo ángulo. Si solo nos concentramos en parchear y responder, en auditar y certificar, no avanzaremos lo suficiente. En todo caso es esta orden es una gran noticia y un primer paso en esa dirección.

Más información: https://empresas.blogthinkbig.com/presidente-nuevas-propuestas-ciberseguridad-casa-blanca/

XCSSET es un malware conocido desde agosto de 2020 para Mac y que innova en aspectos interesantes. Está escrito en AppleScript y habitual descubridor de fallos de seguridad en el sistema que explota en forma de zero day. Ahora se ha visto que aprovechaba un problema en el sistema de Transparency Consent and Control (TCC) para eludir la seguridad y hacer capturas de pantalla a sus víctimas.

El parche CVE-2021-30713 soluciona este fallo en Apple que ahora se ha corregido, aunque ya tarde, tras ser aprovechado por el malware. El TCC controla qué aplicaciones tienen acceso a qué recursos (preguntar si se puede acceder al micrófono, pantalla, etc.). Los creadores de XCSSET consiguieron obtener acceso a estos recursos sin alertar al usuario y consiguieron “solo” que el malware capturase la pantalla (podrían haber hecho más). El malware, de manera bastante ingeniosa, buscaba otras apps ya instaladas en el sistema con esa capacidad de por ejemplo acceder a la pantalla y se hacía pasar por ellas, creando prácticamente al vuelo una mini app con el ID autorizado correspondiente que se hacía pasar y aprovechaba la original con los permisos.

Lo interesante es que XCSSET ha conseguido explotar hasta tres fallos de seguridad en Apple previamente desconocidos para, entre otras cosas, robar cookies de Safari.

Más información: https://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/

Este mes tenemos menos vulnerabilidades (50, lo que viene siendo la mitad de lo que últimamente se soluciona cada mes) pero a cambio, muchas más críticas: cinco. Y para colmo, seis vulnerabilidades están siendo ya aprovechadas por atacantes. Se trata fundamentalmente de elevaciones de privilegios. En la librería DWM Core, en NTFS, en el Kernel y en el Microsoft Enhanced Cryptographic Provider. La última es una ejecución de código remoto en la plataforma MSHTML.

Los dos fallos relacionados con el Microsoft Enhanced Cryptographic Provider están emparentados con un grave problema que solución Adobe hace bien poco (CVE-2021-28550) y que estaba siendo aprovechado por atacantes enviado PDF que permitían le ejecución de código.

Otro fallo que destacar afecta a Kerberos, puesto que un atacante podría eludir la autenticación.
Por último, un problema de ejecución de código en Defender, fácil de aprovechar.

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

Google quiere matar la URL para salvar Internet y aún no sabe cómo. Una de las iniciativas que introdujo hace poco, se ha demostrado inútil en la práctica y finalmente ha sido retirada. Se trata de la funcionalidad en Chrome que permitía “aligerar” las URLs ocultando todo lo que no fuera el dominio. Se supone que esto hacía que los usuarios fueran más conscientes ante un caso de phishing, al quedar más relevante el dominio a la vista y no sepultado por datos engañosos en la URL.

En un principio puede tener sentido, pero no gustó ni a los usuarios avanzados (lógico) ni ha ayudado a los menos avanzados. Realmente no ha servido para nada y tras un año han dado marcha atrás. Ha trascendido que realmente han comprobado que no funciona para proteger en la práctica, así que de nuevo se verá por defecto toda la URL en la barra del navegador y abandona así su experimento… por segunda vez. Ya intentó algo parecido en 2014.

Más información: https://therecord.media/google-abandons-experiment-to-show-simplified-domain-urls-in-chrome/

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