Microsoft cierra el año con 58 vulnerabilidades corregidas el segundo martes de diciembre. 9 de ellas críticas y un CVSS máximo de 8.8 en Microsoft Dynamics. Exchange y Excel son especialmente castigados con seis y ocho fallos respectivamente , cinco de ellos con ejecución de código en el caso de Exchange.

Se ha hecho público además una alerta de spoofing de DNS. En principio relacionado con la fragmentación pero no explícitamente con SAD DNS. Microsoft recomienda limitar el tamaño del búfer para evitar fragmentación, lo que se traducirá en más conexiones más pequeñas al puerto 53.

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

Ya se conocen los detalles dl ataque a FireEye, del que publicaron muchos detalles, entre ellos, las reglas Yara para detectar potenciales ataques que se pudieran derivar del robo de sus propias herramientas. Lo más interesante es que desvela una operación encubierta muy sofisticada a la cadena de suministro.

Y es sofisticada porque han troyanizado una herramienta muy habitual de gestión de red, llamada Orion de la compañía SolarWinds, la han vuelto a firmar con el certificado legítimo de la compañía y la han subido para su descarga. Esto implica que puede haber muchos otros afectados.

A pesar de haberse hecho público estos detalles este mismo lunes (lo que implica que se conocía desde hace más tiempo) resulta llamativo que la DLL troyanizada no era detectada en masa por los antivirus a la hora de hacer el anuncio. Incluso seguía colgada en el repositorio oficial. El certificado tampoco estaba revocado.
Si la gestión de FireEye ha sido ejemplar en otros aspectos de esta crisis. ¿Se podía haber mejorado la coordinación con todos los actores para dejar atados los aspectos "reactivos" antes de la publicación de los detalles? ¿Desvelarlo así haya sido, quizás, una maniobra de presión sobre SolarWinds?

Más información: https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html

El Consejo Europeo adoptó el pasado 14 de diciembre una Resolución sobre el cifrado en la que destaca la necesidad de que se garantice la seguridad a pesar del cifrado. Lo interesante es que el Consejo observa la necesidad de que se vele por que las fuerzas o cuerpos de seguridad y las autoridades judiciales competentes puedan ejercer sus facultades legítimas, tanto en línea como fuera de línea, para proteger nuestras sociedades y a nuestra ciudadanía.

Sin embargo, se dan casos en los que el cifrado hace extremadamente difícil o prácticamente imposible el acceso a las pruebas electrónicas y su análisis. Según la Resolución, la UE buscará un equilibrio adecuado a la hora de velar, por un lado, por la aplicación y el uso continuados de una sólida tecnología de cifrado, y por otro, por que las fuerzas o cuerpos de seguridad y el poder judicial puedan ejercer sus facultades en las mismas condiciones que en el mundo fuera de línea.

La Resolución no dice más, pero abre la puerta a la custodia de claves y a las puertas traseras en el software y hardware de cifrado.

Más información: https://www.consilium.europa.eu/en/press/press-releases/2020/12/14/encryption-council-adopts-resolution-on-security-through-encryption-and-security-despite-encryption/

De las 83 vulnerabilidades publicadas por Microsoft, 10 son críticas. Al menos durante dos meses se ha bajado de 100 fallos por mes, algo que fue la tónica durante la mayor parte de 2020.

Una de las más graves es el fallo en Microsoft defender, CVE-2021-1647, que ya está siendo aprovechada por atacantes y permite ejecución de código. Probablemente se explote al analizar un fichero especialmente manipulado.

El RPC Runtime de Windows también sufre un fallo grave que parece sencillo de explotar. CVE-2021-1658.

No se tienen muchos más detalles de la mayoría de las vulnerabilidades puesto que si bien Microsoft introdujo no hace mucho el estándar CVSS en sus alertas para valorar su criticidad, eliminó el párrafo con las explicaciones necesarias para entender mejor en qué consistían los fallos.

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

¿Parchear o no parchear los sistemas que han llegado a su fin de ciclo (EOL), pero que todavía siguen siendo populares? Ya se discutió el asunto cuando XP, tras trece años siendo soportado por Microsoft, terminó recibiendo un parche en 2017 (mucho después de su fin) para intentar detener Wannacry.

Cisco no quiere parchear las últimas 74 vulnerabilidades en varios de sus dispositivos populares, porque han terminado su ciclo de vida, e invita a los usuarios a adquirir las versiones más recientes. Por ahora, ninguno de los fallos parece crítico. La decisión, aunque no guste a los usuarios, debe ser respetada. Los fabricantes deben avanzar, soltar lastre de versiones antiguas para enfocarse en las más recientes y (supuestamente) robustas. Aunque no hay duda de que hay un componente de negocio, puede llegar a entender esa decisión. Abrir la veda a un soporte infinito, no beneficia el progreso hacia sistemas más seguros. ¿Lo hizo bien Microsoft entonces? En el caso de Wannacry, la gravedad del problema lo requería. El fallo era “gusanable” y el parque de XP todavía existente prometía perpetuar la difusión. Puntualmente, realizó un ejercicio de responsabilidad para también cuidar del resto de sus productos.

Más información: https://www.zdnet.com/article/cisco-says-it-wont-patch-74-security-bugs-in-older-rv-routers-that-reached-eol/

Ya lo hemos dicho en muchas ocasiones, el malware para Android no para de evolucionar hacia técnicas cada vez más parecidas al mundo más “maduro” del malware para PC. En este caso se ha encontrado un APK fraudulento capaz de enviar mensajes a través de WhatsApp a los contactos de la víctima. Aprovecha 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.

Si bien esto es relativamente habitual en malware para Android a través de SMS, no lo es tanto esta fórmula a través de mensajería instantánea que puede resultar más creíble y por tanto derivar en más infecciones.

La página a la que redirige (que toma de un servidor, no es siempre la misma) se parece mucho a una app de Huawei supuestamente en Google Play. En realidad se trata de estafas relacionadas con el adware.

Más información: https://thehackernews.com/2021/01/beware-new-wormable-android-malware.html

¿Pueden ser los expertos en seguridad, víctimas a su vez de otros supuestos expertos? Google ha destapado una operación que supera cualquier otra actividad delictiva que hubiera tenido en su objetivo a expertos en ciberseguridad por su elaborada maquinaria para llegar a ellos.

La campaña parece orquestada por el gobierno norcoreano. Se han tomado la molestia de construir perfiles de supuestos investigadores de vulnerabilidades y exploits en Twitter, que apoyaban la labor de los otros, se daban a conocer en la comunidad y alardeaban de sus habilidades (de nuevo, respaldadas entre ellos). Como por ejemplo un supuesto exploit para un fallo en Defender solo apoyado por un vídeo falso, que fue descubierto por la comunidad de investigadores reales pero respaldada por los perfiles falsos. También crearon blogs falsos con investigaciones, algunas plagiadas.
Y una vez ganada la confianza, ahora el ataque. Contactaban por privado con conocidos investigadores y le pasaban un proyecto en Visual Studio con el que pedían su ayuda. Este cargaba una DLL maliciosa en el sistema del verdadero experto.

Existe otra vía de ataque a los investigadores reales. Parece que tras visitar con Chrome los blogs de los atacantes (investigadores falsos) algunos se han infectado con malware, aunque este punto no está claro aún porque parece que implicaría el uso de un 0day.

Han usado Twitter, LinkedIn, Telegram, Discord, Keybase y el correo. Se conocen más de 10 perfiles de investigadores falsos por ahora.

Más información: https://blog.google/threat-analysis-group/new-campaign-targeting-security-researchers/

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/