La NASA sorprende y deleita a todos los amantes de los viajes espaciales con la revelación de un código secreto oculto en el paracaídas del rover Perserverance. Un joven estudiante francés de informática, Maxence Abela, publicó seis horas después del “amartizaje” un tweet con el criptograma ingeniosamente resuelto.

Utilizando código binario escondido en el patrón de colores del paracaídas, los ingenieros habían codificado el famoso lema del Jet Propulsion Laboratory (JPL) de la NASA: “DARE MIGHTY THINGS”, palabras tomadas de un discurso del presidente Teodoro Roosevelt en 1899: atreverse a cosas poderosas. El código binario correspondía a diferentes valores numéricos, los cuales codificaban a su vez las letras: (1, A), (2, B), (3, C), y así sucesivamente.

Posteriormente, la NASA desveló que el anillo exterior del paracaídas codificaba las coordenadas GPS de la ubicación del JPL: 34°11’58” N 118°10’31” W. Ambos códigos pueden apreciarse en una imagen publicada por el propio laboratorio.

Los ingenieros del JPL ciertamente viven a la altura de su lema.

Más información: https://www.20minutos.es/noticia/4597119/0/la-nasa-escondio-un-mensaje-secreto-en-el-paracaidas-del-rover-perseverance/

Hacía tiempo que Microsoft no sacaba parches fuera de ciclo. Y hacía más aún que no eran para Exchange ("on premises", no "on line"). Estos parches cubren cuatro vulnerabilidades graves que combinadas permiten acceso completo al servidor. Se sabe que estos fallos estaban siendo explotados por actores chinos (apodados Hafnium). Estos problemas (reportados por Volexity) se conocen desde enero y además resultan bastante sencillos de aprovechar si el Exchange está expuesto directamente a Internet.

Las vulnerabilidades aprovechadas por los atacantes se conocen ahora como CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 y CVE-2021-27065. Con ellas conseguían insertar una shell en el servidor y controlarlo. Se espera que los exploits sean públicos en breve.

Más información: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901

Si no conocías el problema de Slipstreaming 2.0, es el momento de ponerse al día porque está teniendo un importante impacto en los navegadores. El año pasado se publicó la versión 2 de este fallo, que a su vez deriva de la técnica de NAT pinning de 2010.

Estos fallos, por resumir, permiten a través de JavaScript del navegador, acceder directamente a cualquier puerto TCP o UDP de la red interna. Aprovechan problemas de dispositivos NAT (routers) que escanean el puerto 5060 para crear reglas de “forwarding”. Se les confunde manipulando paquetes para hacer forwarding de todos los puertos y “ver” la red interna. Para conseguirlo el sistema de NAT debe soportar ALG (Application Level Gateways), obligatorio para protocolos SIP, H323, FTP…

En la versión 87 de Chrome ya se bloqueó el acceso a 5060 y 5061. En enero de 2021 ha añadido los puertos 69, 137, 1719, 1720 (H.323), 1723 y 6566 para seguir mitigando el problema. Bloquearon el 554 pero se echaron atrás y la noticia es que ahora lo volverán a bloquear. Todas las webs o FTP a los que se acceda por esos puertos tendrán el error “ERR_UNSAFE_PORT”.

Con esto se consigue que aunque el navegador ejecute el JavaScript malicioso, no pueda comunicarse con el servidor de control a través de esos puertos con la información sobre la red interna y eludir el NAT.

Más información: https://www.bleepingcomputer.com/news/security/google-chrome-to-block-port-554-to-stop-nat-slipstreaming-attacks/

Segundo martes de mes más que interesante para Microsoft. Por un lado, deja de tener soporte Edge con motor EdgeHTML y queda solo Edge con motor basado Chromium (blink). De hecho, se han corregido 82 vulnerabilidades este mes, pero en otros se afirma que han sido más de cien. La razón es que algunos cuentan los CVE de Chromium.

Cuando los a administradores todavía se enfrentan a las gravísimas vulnerabilidades ProxyLogon que están siendo explotadas en Exchange se corrigen 82 fallos nuevos, 10 críticos y dos nuevos ya explotados por atacantes. Una elevación de privilegios y un RCE en Edge (antiguo) e Interne Explorer. Otros fallos a destacar son un RCE en el servidor DNS (otra vez) y en Hyper-V.

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

No es ningún secreto que las muestras de malware detectan dónde están siendo ejecutadas. Esto les permite reprimir sus acciones si se sienten observadas en una sandbox, donde las compañías detonan los ejecutables para ver qué efectos tiene y clasificarlos mejor, además de recolectar los efectos en el sistema y considerarlos IoCs. Pero en le caso del phishing no es tan habitual.

Se han detectado ya casos de páginas de phishing que usan JavaScript para detectar el motor de renderizado, la profundidad de color y otros parámetros típicos que pueden sugerir que se está ejecutando bien en máquina virtual o bien en un navegador de pruebas en el que se pretende automatizar la detección de casos de phishing. Esto es tan sencillo de detectar para el atacante como para el analista de falsificar, por lo que comienza una caza del gato y el ratón para la detección de estos casos de forma automática en sandboxes, igual que ocurre con las muestras de malware.

Más información: https://www.bleepingcomputer.com/news/security/phishing-sites-now-detect-virtual-machines-to-bypass-detection/

La gravedad de las últimas vulnerabilidades en Exchange (en concreto CVE-2021-26855, ProxyLogon) ha obligado a Microsoft a realizar un movimiento interesante: Ha incluido en Microsoft Defender, el “antivirus integrado” la mitigación del problema de seguridad de forma automática. Con solo actualizar se mitigará la vulnerabilidad (no quedará corregida hasta que se parchee, pero los atacantes tendrán más dificultad para aprovecharla).

Aunque existe parche oficial desde el día 2 de marzo, a raíz de la aparición de exploits públicos, muchos actores relevantes están aprovechando el fallo en masa para hacerse con los servidores Exchange de compañías. Ahora, Microsoft Defender Antivirus and System Center Endpoint Protection aplicará una mitigación sin necesidad de que el administrador haga nada. Defender, en este caso, da un paso más hacia ese Endpoint Protection completo que vigilia en muchos aspectos la seguridad del sistema, no solo desde el punto de vista del antivirus o del simple análisis de ficheros.

También es relevante que se distribuya una mitigación a través de este sistema cuando Microsoft tradicionalmente las ha distribuido a través de parches “one click” que se descargaban aparte.

Más información: https://www.microsoft.com/security/blog/2021/03/18/automatic-on-premises-exchange-server-mitigation-now-in-microsoft-defender-antivirus/

Se han dado a conocer dos graves vulnerabilidades en OpenSSL. CVE-2021-3450 permite eludir por completo la verificación de un certificado. Curiosamente, el fallo se introdujo al intentar eludir ciertos tipos de parámetros de curvas en certificados sospechosos que ya dieron problemas en Windows en 2020. Al implementar este check se elude un check previo y al final no se valida bien si una no CA puede emitir certificados. Solo afecta si se ha activado el flag X509_V_FLAG_X509_STRICT (no activo por defecto). Se introdujo en 1.1.1h y se corrige en 1.1.1k.

CVE-2021-3449 es una desreferencia a puntero nulo en servidor, y por tanto permite una denegación de servicio en muchos de los servidor TLS operados con OpenSSL actuales, puesto que el fallo afecta en la configuración por defecto (con renegociación activa). Solo hay que enviar un ClientHello especial durante la renegociación (omitiendo un dato que se ofreció durante la negociación inicial). Afecta a todo 1.1.1 y se corrige también en 1.1.1k.

Más información: https://www.openssl.org/news/secadv/20210325.txt

Más ataques del tipo cadena de suministro, y esta vez a PHP. Alguien ha entrado en el GIT oficial del código PHP y añadido una puerta trasera. Si se usa esta versión, un atacante tendría que entrar con la cadena "zerodium" en un User-Agent "falso" con una doble T al final y podría ejecutar código en el servidor. Teniendo en cuenta que casi el 80% de las páginas web usan PHP, esto daría miedo, sino fuera porque es poco probable que hayan usado esta última versión troyanizada por el poco tiempo que ha estado “disponible”.

Lo que sí debe preocupar es que hayan llegado tan lejos en un código tan crítico. Aunque el “commit” con las líneas maliciosas se hayan hecho en nombre de cuentas de desarrolladores conocidas, lo más probable es que hayan comprometido por entero el servidor. Por ello ahora están usando como repositorio principal el mirror del que ya disponía la organización; que ya se plantea seguir usándolo y abandonar el principal.

Más información: https://news-web.php.net/php.internals/113838

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