A partir de la inminente versión 90, Chrome mostrará un error de certificado cuando un usuario intente acceder a cualquier web con un certificado firmado por Camerfirma. Aunque quizás no sea la CA más popular, está muy presente en España en muchas organizaciones públicas.

En Bugzilla se exponen las 26 razones por las que ha sido expulsada. Por ejemplo, decenas de fallos técnicos en otros campos de certificados que no eran capaces de revocar a tiempo. Y para ello las excusas eran variadas. Desde que la legislación local les obligaba a ciertas fórmulas que no cumplían los estándares (cosas que no demostraban)… hasta que su sistema había funcionado bien 17 años, pero que luego al crecer mucho, fallaron algunos controles internos. A veces no había ni excusas. Simplemente no contestaban a los requerimientos.

En uno de los incidentes, se supone que debían dar a conocer la existencia de una sub-CA máximo una semana después de su creación pero no lo hacían. Lo que ocurría según ellos es que “la persona encargada no estaba disponible”. Tampoco el respaldo de esa persona. Camerfirma lo intentó solucionar diciendo que pondría “un respaldo para la persona de respaldo encargada de esta comunicación”. Su personal estaba completamente “desbordado”, o “de vacaciones”. Básicamente, de todos los fallos comunes en muchos certificados (insuficiente entropía, extensiones incorrectas…), Camerfirma siempre fallaba al revocar en tiempo y forma en los certificados.

El mundo de los certificados es exigente. Pero es que así debe ser. Del buen hacer de las CA depende, literalmente, el internet que se ha construido.

Más información: https://empresas.blogthinkbig.com/26-razones-chrome-no-confia-ca-espanola-camerfirma/

Chrome, tan difícil de explotar como suculento para los atacantes. Tras el fallo en FreeType descubierto a finales de 2020 y que en realidad comprendía dos problemas (uno para explotar y otro para escapar de su sandbox), vuelve a conocerse otro 0day de verdad (del que se encuentra siendo aprovechado por atacantes) en este navegador. Es el sexto en apenas unos meses.

Se trata de un nuevo fallo parcheado en la última versión. CVE-2021-21148 es un problema de desbordamiento de heap en el motor V8 (el que procesa JavaScript). Al parecer estaba siendo usado por atacantes coreanos (y pagados por su gobierno) para atacar a reputados investigadores de seguridad. Recordemos que hace poco algunos atacantes se hicieron pasar por investigadores de seguridad para ganarse la confianza de otros legítimos, pasarles supuestos exploits e infectarlos. En aquel momento se barajó que posiblemente existía otra vía de ataque en esta campaña. Parecía que tras visitar con Chrome los blogs de los atacantes (investigadores falsos) algunos se habían infectado con malware, aunque este punto no estaba claro porque implicaría el uso de un 0day. Pues efectivamente lo había.

Y aplicamos la misma lógica ahora que cuando apareció el fallo en FreeType. ¿Es posible que esos mismos atacantes aprovecharan otro fallo en el sistema operativo para rematar su ataque?

Más información: https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html

Las extensiones del navegador Chrome son uno de los huecos que mejor aprovechan los atacantes en estos momentos. Un reciente caso encontrado en el que se usa la capacidad de sincronización de cuentas entre el navegador, es un buen ejemplo.

Los atacantes comprometieron un sistema. En vez plantar binarios, consiguieron meter una extensión en modo desarrollador (no está en el Store) con permisos para incrustar JavaScript en cada página. Así conseguían robar información de una web muy concreta que operaba la víctima. Pero iban más allá. Para conseguir exfiltrar información de una manera sencilla, elegante y sobre todo, discreta. Aprovechaban la infraestructura de Google como Command and Control. El navegador sincroniza cierta información entre cuentas, para que el usuario tenga la misma experiencia cuando se registra con su cuenta en Chrome en diferentes sistemas. Para conseguirlo envía cierta información a servidores de Google cada cierto tiempo.

El atacante conseguía así, a través de la extensión, enviar información al servidor de Google. Después solo tenía que loguearse con la cuenta de la víctima y recuperar la información gracias a ese diálogo establecido entre los navegadores y con los servidores de Google de por medio. Y todo sin binarios de por medio, solo una sencilla extensión del navegador.

Más información: https://isc.sans.edu/diary/27066

Este segundo martes del mes, Microsoft soluciona 56 fallos de seguridad. Seis de ellos ya se conocían (en .NET principalmente), y uno está siendo aprovechado por atacantes (una elevación de privilegios). Lo más destacado:

* Vuelven los fallos en el servidor DNS. Una ejecución de código.

* Otra vez la pila TCP/IP. Dos fallos de ejecución de código y una DoS. En la práctica, son desde ya tres "ping de la muerte". Afecta tanto a ipv4 como ipv6.

En el caso de la implementación de la pila TC/IP, para ipv4, la ejecución se consigue atacando a la función de “source routing” que, aunque está deshabilitado, responde con un paquete ICMP para informar sobre ello. Y en este proceso se podría aprovechar el fallo. Aunque Microsoft avisa de que es poco probable que estos fallos en la pila sean aprovechados para ejecutar código (la opinión de Microsoft suele estar sesgada) lo que sí es seguro que permiten una denegación de servicio sencilla (provocar un pantallazo azul desde la red).

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

"Cellebrite ha crackeado la aplicación Signal: han roto su cifrado extremo-a-extremo". Con este lapidario anuncio despedía el 2020 la BBC. Otros muchos periódicos y blogs se hicieron eco y cundió el pánico entre los usuarios de Signal y la curiosidad agitó a los investigadores. Romper el cifrado extremo-a-extremo de Signal serçoa una proeza. Los ingenieros de Signal, (encabezados por el carismático Moxie), investigaron el asunto y, sorpresa, todo era un malentendido. La aplicación Cellebrite Physical Analyzer puede leer los mensajes de Signal si tiene acceso físico al dispositivo y está desbloqueado. Cualquiera puede hacer eso.

Recientemente, la empresa suiza Terra Quantum acaba de anunciar que ha roto la criptografía post-cuántica. Sí, has leído bien. Por supuesto, no han publicado ningún artículo en una revista científica de prestigio donde detallen su ataque. De momento, solo contamos con su palabra y un reguero de artículos en blogs y prensa especializada que comentan el sorprendente anuncio, haciendo mucho ruido. ¿Habrá llegado el fin de nuestra esperanza en un futuro post-cuántico o se trata de otra campaña de publicidad gratuita? Vender aceite de serpiente sigue estando de moda.

Más información: https://www.bloomberg.com/news/articles/2021-02-07/a-swiss-company-says-it-found-weakness-that-imperils-encryption?srnd=technology-vp

Una vulnerabilidad siempre se puede considerar un fallo, y un fallo es un riesgo que puede, o no, suponer una amenaza. En este sentido, intuimos ya que no todas las vulnerabilidades son igual de importantes. No solo por su gravedad sino porque puedan llegar a ser realmente aprovechadas para atacar.

Kenna Security ha estudiado 18.000 vulnerabilidades catalogadas con su CVE y concluye que solo 473 fueron explotadas en 2019 de forma que supusieran una amenaza real para las compañías. Esto supone un 2,6%. De estas, a su vez, apenas un 6% han llegado a ser populares en su explotación. Un detalle interesante es que para la mitad de las vulnerabilidades, el código para explotarlas ya estaba disponible públicamente cuando se les asignó CVE y por tanto, la inmensa mayoría ya estaban corregidas para entonces.

En resumen, concluimos que hay vulnerabilidades especiales a las que prestar una particular atención. E incluso entre ellas, las hay que son aprovechadas masivamente (vulnerabilidades “estrella”) por atacantes gracias a los exploits disponibles. Con mitigar esas vulnerabilidades, se reduce mucho un riesgo muy real. ¿Por qué siguen suponiendo un problema incluso cuando existen parches? Entramos entonces en el terreno de la planificación, despliegues… Nada es tan sencillo como parece. Pero en realidad, tampoco debería ser tan complicado… por nuestro propio bien.

Más información: https://www.kennasecurity.com/resources/prioritization-to-prediction-reports/

En tiempos de pandemia, ¿qué pasa con el malware destinado a Linux? En el 2021 X-Force Threat Intelligence Index creado por IBM y Intezer se sacan interesantes conclusiones. En 2020 hubo 56 familias nuevas de malware para Linux. Por comparar, en 2015 hubo 14 y en 2010, solo 9 nuevas. Una familia debe entenderse como un conjunto de muestras similares en técnicas, código o procedimientos, aunque cambie cada archivo. ¿Por qué este interés en crear nuevo malware para Linux? Cada vez con mayor frecuencia, lo más interesante de una compañía (datos o procesamiento) se encuentra en la nube y estos servidores suelen basarse en Linux.

Y a ello se dedican los profesionales del malware como Carbanak, APT28 y APT29 o los ransomware RansomEXX y SFile, que ya han adaptado su malware a estos entornos. También aumenta el malware que intenta minar criptomonedas en servidores Linux. Todo ello, al amparo del lenguaje Go, para poder ser multiplataforma y por facilidad de programación.

Pero no olvidemos que independientemente de estas tendencias, los atacantes seguirán explotando la “fruta más al alcance” a través del malware en estaciones Windows.

Más información: https://www.intezer.com/blog/cloud-security/2020-set-record-for-new-linux-malware-families/

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/