Parece obvio, pero nadie había caído en la cuenta. El cortafuegos de Windows, no aplica sobre WSL 2, el sistema de Linux en Windows. En cierta manera, hay que tenerlo en cuenta y puede ser relevante.

Windows Subsystem for Linux tiene dos versiones. En la primera, se trataba de un kernel Linux que se traducía a llamadas a Windows. En este caso, el cortafuegos integrado (tanto entrante como saliente) de Windows, finalmente recogía esas peticiones y su configuración aplicaba. Pero WSL 2 es distinto, se trata de un kernel Linux completo en Hiper-V. Y por tanto, obvia e ignora el cortafuegos del sistema operativo donde se aloja. ¿Puede ser una vía de escape para atacantes? Esta curiosidad la han descubierto desarrolladores de VPN, que se han dado cuenta de que puede se filtre algo de tráfico a través del subsistema, puesto que ellos, por ejemplo, bloqueaban en Windows todo su tráfico que no pasase por su túnel VPN.

No estaría demás tener en cuenta que, además de usar el wf.msc (comando para acceder al sistema completo de cortafuegos de Windows), se complementara con una lista de Iptables, dado el caso.

Más información: https://mullvad.net/en/blog/2020/9/30/linux-under-wsl2-can-be-leaking/

Desde que en 2012 Tavis Ormandi ridiculizara la seguridad de los sistemas Sophos, o desde que Joxean Koret publicara en 2015 el “Antivirus Hacker's Handbook”, cada cierto tiempo aparecen noticias sobre la inseguridad de los antivirus. Se plantea la duda de quién vigila al vigilante y surgen las preocupaciones. En realidad, cualquier sistema de defensa sufre de vulnerabilidades y su importancia (como en el resto de los fallos de otros sistemas) depende de sus características, capacidad de respuesta y utilidad para el atacante. No es lo mismo que permita ejecutar código en el sistema que eludir las protecciones. Efectivamente, a los sistemas de defensa se les presupone un especial cuidado en la forma de programar, de evitar vulnerabilidades, de anticiparse a los fallos comunes que pueden cometer otros programadores. Pero es imposible estar libre de ellas, más cuando a la complejidad de la operativa propia del antivirus, añadimos que por definición debe tener el control del sistema por completo. Así que, como indicábamos, cada cierto tiempo aparecen estos fallos con ciertos titulares alarmistas.

CyberArk ha publicado una serie de fallos que, aunque no excesivamente graves, sí resultan preocupantemente comunes. Afectan a Kaspersky, McAfee, Symantec, Fortinet, Checkpoint, Trend Micro, Avira, Microsoft, Avast y F-Secure. Casi todas corregidas y que se pueden resumir en tres categorías:

* Muchos programas no establecen correctamente los permisos del directorio de sistema ProgramData. Esto puede llevar a elevación de privilegios.

* Otros tantos confían en sistemas de instalación de terceros que no actualizan. Así, si estos son vulnerables a DLL Hijacking, durante la instalación se podría realizar este ataque.

Investigando bajo estas premisas han conseguido corregir varios CVE en los sistemas antivirus. Pero no, por muchos titulares que se escriban a partir de esta información del tipo “los antivirus podrían hacer el sistema operativo más inseguro”, no por ello es necesario prescindir de estos sistemas de defensa.

Más información: https://www.cyberark.com/resources/threat-research-blog/anti-virus-vulnerabilities-who-s-guarding-the-watch-tower

El acoso legal contra la compañía que considere pagar una extorsión de ransomware continúa en Estados Unidos. En julio de 2019 la confederación de alcaldes de Estados Unidos en su encuentro anual, recomendó no pagar. Si se paga, se les incentiva para seguir atacando, decían. En ese caso el estamento no iba más allá del puro posicionamiento “moral”, pues no resultaba vinculante. Luego se fue más allá. Dos propuestas de dos senadores (uno demócrata y uno republicano) contemplaban en enero de 2020 que se prohibiese gastar dinero público en estos rescates. El senador republicano proponía, además, que se cree un fondo para ayudar a las organizaciones a mejorar su ciberseguridad.

Se sigue yendo más allá. Ahora la Oficina de Control de Activos Extranjeros de la Tesorería (OFAC) comunica que “las empresas que facilitan los pagos de ransomware a los ciberdelincuentes en nombre de las víctimas, incluidas instituciones financieras, empresas de seguros y empresas involucradas en análisis forense y respuesta a incidentes no solo fomentan las futuras demandas de pago de ransomware, sino que también corren el riesgo de violar las regulaciones de la OFAC”. El objetivo sería multar tanto a los que pagan, a los intermediarios y a los que reciben el dinero (si es que pudiesen ser identificados).

En realidad se resume en que en vez de pagar, se debería colaborar con las fuerzas del orden y no involucrar a intermediarios “tapadera” bajo pena de cometer ya algo ilegal y tipificado. ¿La razón? El negocio del ransomware se ha industrializado tanto, que se han estandarizado ciertas figuras. Por supuesto, muchas empresas siguen necesitando pagar para recuperar su información y a raíz de esta necesidad, surge una oportunidad de negocio en los intermediarios que interactúan con los atacantes para darle una capa de legalidad al pago del rescate. Por ejemplo, la empresa afectada disfraza el pago de “consultoría” con una compañía que, por su lado, compensa a los atacantes y obtiene los datos necesarios para recuperar el negocio… más su comisión. Incluso en el caso de las aseguradoras, puede que les compense más pagar a los atacantes que al afectado por los daños sufridos, por lo que se convierten también en una especie de intermediarias.

Más información: https://krebsonsecurity.com/2020/10/ransomware-victims-that-pay-up-could-incur-steep-fines-from-uncle-sam/

Desde febrero no se bajaba de 100 vulnerabilidades en un mes. En este segundo martes de octubre, han sido 87 las vulnerabilidades corregidas. 21 de ellas ejecución de código remoto, pero “solo” 12 críticas. Bastantes (seis) vulnerabilidades han sido previamente reveladas como públicas aunque no parece que ninguna esté siendo aprovechada por atacantes.

La más grave CVE-2020-16898 es un fallo en la implementación de la pila TCP, en concreto en el protocolo ICMPv6 en los paquetes de anuncio de enrutamiento. La posibilidad de ser explotada es alta, incluso que se reproduzca como un gusano. Para deshabilitar esta funcionalidad temporalmente es necesario ejecutar:

netsh int ipv6 set int *NUMEROINTERFAZ* rabaseddnsconfig=disable

El número de la interfaz de red se puede saber a través del comando:

netsh interface ip show interfaces

Hay otra ejecución de código en el Windows Graphics Device Interface (GDI+) y una elevación grave en Hyper-V.

Más información: https://portal.msrc.microsoft.com/en-us/security-guidance

JScript no es JavaScript, sino una implementación propia de Microsoft del estándar ECMAScript, utilizada en Internet Explorer pero en desuso (prácticamente desde que apareció). JScript, como muchas otras tecnologías propias de Microsoft diseñadas en contraposición de un estándar aceptado, tenía tres problemas:

* Quedó obsoleto en 2009 con la aparición de IE 8, pero por supuesto, por compatibilidad hacia atrás se mantenía en los últimos Internet Explorer. En concreto se interpretaba en las librerías jscript.dll (para las versiones más antiguas de JScript) y jscript9.dll (en esta última más moderna se interpreta JavaScript y JScript). La primera librería podía renombrarse o cambiar permisos para estar seguro, en la segunda a consecuencia de unir también JavaScript, no permitía esta mitigación.

* Sufría de vulnerabilidades. Al menos una grave por año en los últimos tiempos, aprovechada siempre por atacantes avanzados.

* Aun así, no podía ser deshabilitado desde las zonas de Internet Explorer, donde habitualmente se podía fortalecer el navegador deshabilitando muchas funciones potencialmente peligrosas.

Con la actualización de octubre, Microsoft ha incluido una entrada en el registro que deshabilita JScript en Internet Explorer 11 para aquellos que sigan usándolo. Algo que siempre debió poder hacerse a través de la configuración de zonas de seguridad, pero que solo ahora es posible. Las instrucciones para conseguirlo, en el apartado de más información.

Más información: https://support.microsoft.com/en-us/help/4586060/option-to-disable-jscript-execution

Aunque ya van tres en un año, sigue siendo noticia encontrar vulnerabilidades aprovechadas por atacantes en Chrome. Se acaba de corregir un fallo en FreeType (librería de código abierto) que al parecer estaban siendo aprovechado por atacantes. No se han dado más detalles al respecto.

La versión 86.0.4240.111 corrige este fallo, encontrado por el equipo ProjectZero de la propia Google. FreeType ha corregido también el fallo en su código. Lo interesante del fallo en Chrome son varios aspectos:

* Lo difícil en Chrome no es encontrar vulnerabilidades sino convertirlas en algo útil. Y para ello es necesario eludir su sandbox, siempre un reto. Parece que en este fallo también lo han conseguido.

* Se supone que los atacantes lo han conseguido, aunque no se han dado detalles. Y el fallo, que parece no trivial, ha sido encontrado en FreeType, de código abierto, aun habiendo pasado varios procesos de fuzzing.

* FreeType es usado en otros proyectos… también podrían ser vulnerables. Ahora los atacantes tienen una oportunidad para analizar el parche y entender cómo funciona el problema.

Esta nueva versión también corrige otros fallos graves, solo que no parecen aprovechados por atacantes o son más difíciles de explotar.

Más información: https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html

El control de entrada a un Store de apps o sistema similar es útil, pero no infalible. Los hay más o menos eficaces. Por ejemplo del desastre de Google Play (donde el adware y malware es constante) hasta la cuasi inexpugnable AppStore de Apple (aunque a veces vulnerada), pasando por Web Store de Chrome donde a veces se cuela malware. Ninguno se ha librado. Ahora le ha tocado al nuevo sistema de “notarización” de Apple.

La notarización, en marcha desde principios de año, escanea automáticamente las apps de MacOS antes de ser distribuidas. Si pasan esta prueba, se meten en la lista blanca de GateKeeper y así ya no aparecen pop ups sobre seguridad. Pero ya les han colado adware y malware.

* La primera vez en agosto. Cuarenta programas que en realidad eran Shlayer y BundleCore.

* La segunda vez en octubre, seis apps han conseguido entrar como lista blanca en GateKeeper. En realidad se trataba del adware MacOffers. Se hacían pasar por instaladores de Flash (un clásico en el adware y malware).

Por cierto, en este último caso se usaba esteganografía para ocultar el malware. Una imagen JPEG contenía también un archivo zip en base64 que en realidad alojaba la aplicación maliciosa.

Más información: https://www.intego.com/mac-security-blog/apple-notarizes-new-mac-malware-again/

Como indicábamos en una noticia anterior, “Lo difícil en Chrome no es encontrar vulnerabilidades sino convertirlas en algo útil. Y para ello es necesario eludir su sandbox, siempre un reto.”. Parece que tras el fallo en FreeType que afectaba a Chrome y descubierto también por Project Zero hace algunas semanas, ahora se hace público cómo conseguían los atacantes “escapar” y elevar privilegios.

El fallo en concreto CVE-2020-17087, se encuentra en el driver Windows Kernel Cryptography (cng.sys). Se trata de un desbordamiento de enteros. Como es muy grave y ha sido encontrado siendo usado por atacantes, Google le ha dado siete días a Microsoft para corregirlo. Al no haberlo solucionado, ha ofrecido públicamente todos los detalles (prueba de concepto incluida) y espera que sea corregido el 10 de noviembre en el siguiente ciclo natural de parches.

Más información: https://bugs.chromium.org/p/project-zero/issues/detail?id=2104

En algún momento ya hemos mencionado que las nuevas CA con más peso de facto son los navegadores. Han impuesto una nueva longevidad a los certificados, mucho más corta de lo que las propias CA “tradicionales” querían aun habiéndose votado en el CAB/Forum que no debía acortarse a un año. Apple lanzó la primera piedra no hace mucho y… todos le siguieron. Pero la política hacia la autonomía continúa. Ahora Chrome tendrá su propio Root Store.

Firefox lo tiene desde siempre, con un almacén propio de certificados raíz en los que confía, y sus propias políticas. Esto le otorgaba independencia pero también un dolor de cabeza a los administradores. Chrome, en todas sus plataformas, ha confiado tradicionalmente en el Root Store del sistema operativo, por lo que coincidía con el criterio de confianza de Edge, Internet Explorer en Windows, Safari si era Mac o Android si Chrome corría en esta plataforma… ahora tendrá el suyo propio.

¿Consecuencias? Relevantes con una cuota de mercado de más del 60%. Tendrá un poder especial sobre en qué certificados raíz se confía y por tanto en la experiencia de navegación de millones de usuarios, algo que hasta ahora se encontraba bajo el criterio de los sistemas operativos en mayor parte. En principio, los criterios que seguirá Chrome son los lógicos. ¿Incluirá con este movimiento más seguridad añadiendo agilidad para revocar certificados? Recordemos que Google ya dispone de sistemas propios de revocación independientes y ágiles (CRLSets) así que realmente, ya puede otorgar esa seguridad. ¿Desconfía de la root store de Windows y Apple y por tanto quiere despachar su propio criterio? En cualquier caso, con esta nueva responsabilidad, adquirirá una nueva relevancia en la gestión global de las autoridades certificadoras.

Más información: https://www.chromium.org/Home/chromium-security/root-ca-policy

Se podría decir que el Tianfu Cup es el Pwn2Own chino. Con más presión si cabe (tienen tres intentos de cinco minutos) el fin es el mismo: una competición para hacerse con el control del software, consiguiendo ejecutar código explotando fallos previamente desconocidos o con técnicas muy novedosas.

Ya el Pwn20wn suele estar dominado por investigadores chinos, pero Tianfu, más reciente, está totalmente organizado para este mercado. Y no defraudan. Qihoo 360, que ya explora buena parte de las vulnerabilidades en, por ejemplo, Windows, ha ganado esta edición. El software al que se le han encontrado fallos gravísimos de seguridad ha sido: iOS 14, Samsung Galaxy S20, Windows 10 (2004), Ubuntu, Chrome…

Y además también (aunque quizás sus fallos estén menos cotizados) a Safari, Firefox, Adobe PDF Reader, Docker (Community Edition), VMWare EXSi, QEMU, TP-Link y ASUS.

El índice de éxito es de 11 de 16 objetivos.

Más información: https://twitter.com/TianfuCup

112 vulnerabilidades corregidas este marte por Microsoft. Nada menos que 17 críticas, 5 de ellas en las extensiones de vídeo HEVC.

De las más graves:

* CVE-2020-17087, que era la pieza que faltaba en el fallo descubierto hace unas semanas en FreeType de Chrome. Con este fallo además los atacantes salían de la sandbox.

* Un problema crítico en la cola de impresión. Hay otros que permiten la elevación de privilegios en el mismo componente.

Como dato interesante, Microsoft ha comenzado a usar activamente el sistema CVSS para evaluar la gravedad de sus fallos. Aunque para ello ha omitido la habitual explicación con más texto que ofrecía en cada informe. Aunque no fuese ajustada a los estándares, ofrecía información útil que ahora ha desaparecido.

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

¿Creías que después del fallo de Kamisnky en 2008 se solucionó todo? DNS sigue siendo uno de los protocolos más débiles sobre el que se sustenta (demasiado) internet. Varias universidades han podido envenenar las cachés DNS como ya se hizo entonces. Se llama SAD DNS. Es complejo de explicar, pero vamos por partes.

Para poder falsear una petición DNS y devolverle al cliente una mentira, el atacante debe saber el TxID (transaction ID) y el puerto origen UDP. Esto suponía una entropía de 32 bits (adivinar dos campos de 16 bits). SAD DNS consiste (básicamente, porque el paper es muy complejo) en inferir el puerto UDP a través de un ingenioso método que se vale de los mensajes de vuelta de error ICMP. Esto deja de nuevo una entropía de 16 bits, asumible para un ataque.

¿Cómo deducir el puerto abierto del resolvedor (la víctima a la que se le va a envenenar la caché)? Lo más sencillo es escanear todos los puertos UDP y ver cuál está abierto, pero esto lleva demasiado tiempo. Pero cuando hayas terminado, ya se ha realizado la transacción y el puerto que querías estará obsoleto. Además, si se machaca un servidor consultando puertos UDP él mismo limitará las respuestas ICMP de “error puerto cerrado” para no saturar. Todos los OS implementan este límite global. Y este límite para proteger, paradójicamente, es lo que aprovecha el ataque. El límite global es de 1000 respuestas por segundo en Linux (200 en Windows). Se trata de un contador global compartido por cualquiera que le esté preguntado. Por tanto el atacante debe:

* Enviar 1000 sondas UDP al resolvedor víctima con IPs de origen falseadas probando 1000 puertos (en realidad son lotes de 50 cada 20 ms para superar otro límite de respuestas por IP).

* Si los 1000 puertos están cerrados, la víctima devolverá (a las IPs falseadas) 1000 paquetes ICMP de error indicando que no está abierto el puerto. Si está abierto, no pasa nada, lo descarta la aplicación correspondiente en ese puerto.

* No importa que el atacante no vea los ICMP respuesta (llegan a las IPs falseada). Lo que importa es ver cuánto del límite global de 1000 respuestas por segundo “se gasta” en esa tanda.

* Antes de dejar pasar ese segundo, el atacante consulta un puerto cualquiera cerrado y si el servidor le devuelve un ICMP de “puerto cerrado”… es que no se había gastado los 1000 ICPM de “error puerto cerrado” y por tanto… en ese rango de 1000 había al menos un puerto abierto. Bingo. Como el límite es global, una respuesta de puerto cerrado significa que no se gastó el límite de 1000 repuestas de “puerto cerrado” por segundo.

* De esta forma, en tandas de 1000 consultas por segundo y comprobando si gasta o no el límite de paquetes de error “puerto cerrado”, el atacante puede ir deduciendo qué puertos están abiertos. En algo más de 65 segundos (para cubrir 65.536) tendrá mapeados los puertos abiertos del servidor. Ahora adivina el TrID por fuerza bruta, y lanza varios paquetes que confundan al resolvedor.

Hay más variantes del ataque dependiendo de cómo implemente UDP la víctima, de si es un simple forwarder o un resolvedor.

Más información: https://dl.acm.org/doi/pdf/10.1145/3372297.3417280

Si macOS no respeta la privacidad, no parece que sea precisamente por la polémica alrededor del envío OCSP y de qué programas se tienen abiertos. El informe original de Jeffrey Paul, a nuestro criterio, especula en exceso. Muestra hechos, pero la interpretación (más o menos dramática de las consecuencias) está abierta y la polémica, servida. Algunas consideraciones sobre el “descubrimiento”:

* OCSP sirve para saber si un certificado que firma un programa está revocado. Esto es una protección adicional para MacOS que ya de por sí resulta bastante estricta en seguridad con lo que se ejecuta: tenemos a gatekeeper y la notarización. Mejorable, pero es una opción de seguridad añadida.

* El envío OCSP es en texto claro, y englobaría básicamente la IP y un hash del certificado relacionable con la aplicación. También puede que Akamai, que sirve de infraestructura a Apple, pueda verlo, además de alguien en la red. Pero ya ven los dominios en peticiones DNS en claro, puertos de conexión… ¿De verdad es tan dramático que alguien con acceso a la red pueda acceder, además, hashes asociados a programas ejecutados? Es más probables que la llamada a casa de cada programa aporte más información que la comprobación OCSP.

* Se suponía que la imposibilidad de bloquear el acceso al dominio de comprobación OCSP resultaba en un signo de la intencionalidad de Apple. En realidad puede interpretarse como un intento de mejorar la seguridad, para que ningún malware pueda evitar la comprobación.

En resumen, ¿un grave problema de privacidad? No tanto. Y en todo caso, es habitual sacrificar algo de privacidad por una mayor seguridad. En este caso, una pequeña parte, pensamos. Microsoft con su SmartScreen recolecta una enorme telemetría sobre el uso de los programas que ejecuta el usuario. A cambio ofrece una seguridad adicional que para muchos merece la pena. Aun así, después de todo, Apple no recogerá más las IPs, entre otras mejoras en el futuro.

Más información: https://sneak.berlin/20201112/your-computer-isnt-yours/

Se han hecho públicas casi 50.000 direcciones IP de dispositivos VPN de Fortinet vulnerables al fallo CVE-2018-13379, que como indica su CVE, tiene ya dos años aunque se hizo pública en 2019. El problema es que el trabajo está ya totalmente hecho para los atacantes. Por un lado existe un exploit público funcional, y por otro ya alguien se ha encargado de hacer el filtrado de potenciales candidatos a ser atacados (que habitualmente implica una búsqueda en Shodan). Esto implica una presión adicional para aquellos que todavía no hayan aplicado el parche. No se sabe si absolutamente todos las IPs son verdaderas y atacables (hay algunos honeypots), aunque parece que el atacante ya hizo el ejercicio de atacarlas para estar seguro de poder recuperar la información.

El atacante tendría acceso con este fallo a archivos del sistema habitualmente no accesibles. En concreto sslvpn_websession, permitiría facilitar el acceso remoto. Los afectados son: FortiOS de 6.0.0 a 6.0.4; FortiOS de 5.6.3 a 5.6.7; FortiOS de 5.4.6 a 5.4.12.

Desde esta web se puede comprobar si una determinada dirección IP se encuentra en esa lista: https://www.segu-info.com.ar/find-ip-FG-IR-18-384

Más información: https://www.bleepingcomputer.com/news/security/hacker-posts-exploits-for-over-49-000-vulnerable-fortinet-vpns/amp/

Usar un segundo factor de autenticación siempre es buena idea. Aunque no siempre son del todo efectivos. Un ejemplo son los códigos por SMS, un método en extinción que se sabe obsoleto y que es mucho menos robusto que otras soluciones. Pero también puede que el sistema de 2FA esté mal implementado, como ha ocurrido con cPanel, al que se le ha encontrado un fallo importante en este aspecto.

Se podía adivinar por fuerza bruta, en cuestión de minutos, unos parámetros que eludían el 2FA. Si el atacante disponía de la contraseña de la víctima por cualquier motivo, en este caso el segundo factor no cumplía su misión.

Dada la popularidad de cPanel y la cantidad de sitios web que lo usan como sistema de gestión de hostings, el fallo es relevante. Ha sido solucionado en las últimas versiones del programa.

Más información: https://www.digitaldefense.com/news/zero-day-cpanel-and-webhost-manager/

El navegador es el nuevo campo de batalla del malware y el interés por los atacantes en las extensiones así lo confirma. No es nuevo que se cuelen extensiones maliciosas en un Web Store (en especial el de Chrome) pero sí que es noticia que lo hagan para Edge… aunque ahora es más sencillo porque al estar basado en Chromium, las extensiones son compatibles.

Se han encontrado 18 extensiones maliciosas que en esta ocasión, inyectaban publicidad. Se hacían pasar por VPNs que ni siquiera tenían versiones oficiales. En otra tanda, los atacantes simulaban versiones de extensiones oficiales, pero a las que habían añadido contenido malicioso.

Más información: www.zdnet.com/article/microsoft-removes-18-malicious-edge-extensions-for-injecting-ads-into-web-pages

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/