La criptografía tradicional no sirve de mucho en el mundo IoT, con dispositivos «constreñidos», con escasos recursos de memoria, procesador, ancho de banda y energía. Ante el crecimiento explosivo de dispositivos IoT e IIoT, en el último decenio los criptógrafos han propuesto diversas primitivas criptográficas ligeras que ofrecen un compromiso razonable entre seguridad, rendimiento y coste con respecto a la criptografía convencional. El Instituto de Estándares y Tecnología Americano (NIST) como la Organización Internacional de Estándares (ISO/CEI) están trabajando intensamente en la búsqueda, prueba y estandarización de métodos que puedan utilizarse con garantías para la Criptografía Ligera.

El 30 de marzo de 2021 NIST completó la revisión de los candidatos de la segunda ronda en el proceso de normalización de la Criptografía Ligera. Los diez finalistas que pasan a la ronda final son:

* ASCON
* Elefante
* GIFT-COFB
* Grain128-AEAD
* ISAP
* Fotón-Escarabajo
* Rómulo
* Sparkle
* TinyJambu
* Xoodyak

Se espera que la ronda final del proceso de normalización dure aproximadamente 12 meses.

Más información: https://www.miragenews.com/lightweight-cryptography-standardization-536985

Era noticia en enero un malware para Android capaz de enviar mensajes a través de WhatsApp a los contactos de la víctima. Aprovechaba las notificaciones recibidas en el teléfono para responderlas rápidamente con un enlace que parece ser de la Play Store, pero que en realidad redirige otra URL desde donde descargar el malware. La víctima se convierte así en prescriptora del malware a sus contactos.

Se vuelve a encontrar otra con características similares de propagación pero ahora en Google Play. O sea, ha pasado todas las barreras de seguridad del market. La aplicación (un supuesto servicio falso para ver contenido de Netflix) se encargaba de esconderse como servicio y:

* Superponerse sobre nuevas ventanas para intentar robar credenciales.

* Ignorar la optimización de betería para que se siga ejecutando siempre como servicio.

* Con el acceso a notificaciones, permite capturar las notificaciones de WhatsApp. De ahí toma los datos necesarios para responder rápidamente a esa notificación y difundirse a sí mismo a los contactos de la víctima.

El malware para Andorid sigue innovando.

Más información: https://research.checkpoint.com/2021/new-wormable-android-malware-spreads-by-creating-auto-replies-to-messages-in-whatsapp/

Este martes Microsoft ha corregido 114 vulnerabilidades. Los detalles más interesantes son:

* 4 de ellas se conocían ya. Una revelación de información en Installer. Un fallo en NTFS que permitía corromper el disco duro con solo un comando. Un problema en RPC y otro en la librería Azure ms-rest-nodeauth.

* Como es habitual, un fallo de elevación de privilegios que los atacantes estaban usando y que es descubierto por Kaspersky.

* Nada menos que 27 fallos de ejecución remota se corrigen en el sistema RPC (remote procedure call).

* Cuatro nuevos fallos de Exchange que han sido encontrados por la NSA. Muy graves, permiten ejecución de código sin autenticación.

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

La semana pasada se reportaron de forma independiente dos graves fallos en Chromium que permitían la ejecución de código (aunque luego haya que salir de la sandbox con otro fallo). Esta semana, se descubre que uno de ellos está siendo aprovechado en China para atacar a clientes de WeChat. ¿Por qué esta aplicación?

Muchas apps usan en su interior código de Chromium para renderizar código web. Pero no todas le activan el sandbox en este uso, como sí lo hacen los navegadores Chrome, Opera, Edge… por tanto estos fallos tienen sentido en enlaces web abiertos por WeChat porque facilitan la explotación.

Interesante uso de los fallos de ejecución sin salir de Sandbox en Chrome. También interesantes dos datos más:

* Chrome todavía no ha solucionado uno de ellos, mientras Edge sí.

* Se cree que uno de los dos fallos ha sido descubierto precisamente por el carácter abierto de los repositorios de código y sus changelogs. Los atacantes podrían haber estado vigilando los cambios de seguridad en el repositorio y creado un exploit para estos fallos antes de que el parche saliera a producción.

Más información: https://therecord.media/recent-chromium-bug-used-to-attack-chinese-wechat-users/

Dentro del plan de deshacerse de Emotet, esta semana se ha dado otro paso. En un principio se secuestraron los dominios y command and controls usados por el malware, para que fuesen en la medida de lo posible, “desactivados”. Ahora, la policía va a enviar desde esos servidores un mensaje al malware instado en los sistemas para que se elimine por completo.

En concreto se trata de una librería EmotetLoader.dll que se encargará de detener el servicio, borrar claves de registro e intentar borrar ficheros. No siempre lo consigue y por tanto dejará restos en algunos sistemas infectados. Pero no importa, una vez detenido el servicio, en el próximo reinicio no conseguirá arrancar. Además, ya se encuentra bastante inactivo al neutralizar los propios dominios a los que se conecta y desde donde precisamente se ha enviado esta actualización autodestructiva. Se calcula que se limpiarán 1.6 millones.

Más información: https://www.redscan.com/news/rise-and-fall-emotet-botnet/

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