Resumen de seguridad de diciembre de 2020

SSL.com desea a todos nuestros clientes y visitantes una temporada navideña feliz, segura y saludable, ¡y un próspero 2021! Esperamos que el nuevo año sea un poco menos, umm ... interesante que 2020 ha sido en algunos aspectos, pero estamos seguros de que no pasará un mes sin noticias importantes del mundo de la seguridad de redes, certificados digitales y PKI.

Vulnerabilidad DoS de OpenSSL

Cubrimos este tema en un blog a principios de este mes, pero vale la pena repetirlo. Una vulnerabilidad de alta gravedad en OpenSSL se descubrió que afecta a todas las versiones de OpenSSL 1.0.2 y 1.1.1 anteriores a 1.1.1i. Esta vulnerabilidad podría aprovecharse para crear un ataque de denegación de servicio (DoS). OpenSSL 1.1.1i, lanzado el 8 de diciembre de 2020, incluye una corrección.

Los usuarios de OpenSSL deben actualizar sus instalaciones lo antes posible. Hay dos caminos para aplicar la corrección:

  • Los usuarios de OpenSSL 1.1.1 y los usuarios de 1.0.2 no compatibles deben actualizar a 1.1.1i.
  • Los clientes de soporte premium de OpenSSL 1.0.2 deben actualizar a 1.0.2x.

Actualmente, OpenSSL está instalado en la mayoría de los servidores web HTTPS. Puede leer más sobre la vulnerabilidad en SSL.com blog, y en el proyecto OpenSSL Aviso de seguridad.

Para llevar de SSL.com: Si es un usuario de OpenSSL y aún no lo ha hecho, lea OpenSSL's asesor sobre la vulnerabilidad y actualice su instalación lo antes posible.

Cloudflare aboga por nuevos protocolos de privacidad

Tim Anderson reportaron en The Register que Cloudflare está "presionando para que se adopten nuevos protocolos de Internet que, según dice, permitirán una 'Internet que respete la privacidad'". Estos protocolos incluyen DNS sobre HTTPS (DoH), cifrado adicional para TLS apretón de manosy mejoras de seguridad para el manejo de contraseñas de usuarios.

DoH ajeno

DNS sobre HTTPS (DoH) aborda un eslabón débil en la privacidad de Internet al cifrar las consultas y respuestas de DNS, que históricamente se han enviado como texto sin formato. DoH ajeno (ODoH)  lleva la protección de la privacidad de DNS un paso más allá al evitar que los servidores DoH conozcan la dirección IP del cliente:

La esencia de ODoH es que introduce un proxy de red entre el cliente y el servidor DoH. El proxy no tiene visibilidad de la consulta DNS, que solo puede leer el servidor DoH. El servidor no tiene conocimiento de la dirección IP del cliente. La consulta es privada, siempre que el proxy y el servidor no estén en connivencia.

Cloudflare ya ha declarado soporte para ODoH, que fue desarrollado por ingenieros de Cloudflare, Apple y Fastly. Puede obtener más información consultando su papel en arxiv.org.

Hola de cliente cifrado (ECH)

Hola de cliente cifrado (ECH) ofrece cifrado de protocolo de enlace mejorado en TLS, ir más allá SNI cifrado (ESNI), que solo protege la Indicación de nombre de servidor (SNI) en el TLS apretón de manos. Ingeniero de investigación de Cloudflare Christopher Patton escribe,

Si bien ESNI dio un importante paso adelante, no alcanza nuestro objetivo de lograr un cifrado de protocolo de enlace completo. Aparte de estar incompleto, solo protege al SNI, es vulnerable a un puñado de ataques sofisticados, que, aunque es difícil de lograr, apunta a debilidades teóricas en el diseño del protocolo que deben abordarse.
...
En última instancia, el objetivo de ECH es garantizar que TLS las conexiones realizadas a diferentes servidores de origen detrás del mismo proveedor de servicios ECH son indistinguibles entre sí.

Como era de esperar, dado que ECH "solo tiene mucho sentido junto con DoH, y en el contexto de una CDN (red de distribución de contenido)", Cloudflare "se ve a sí mismo como un probable proveedor de ECH". Puede leer más sobre ECH en el IETF propuesta de borrador.

Contraseñas OPAQUE

Las contraseñas OPAQUE, "una especie de juego de palabras con la función pseudoaleatoria ajena (OPRF) combinada con el intercambio de claves autenticadas con contraseña (PAKE)", es un mecanismo para evitar por completo la transferencia de la contraseña de un usuario a un servidor. OPAQUE logra esto “haciendo que el servidor y el cliente calculen conjuntamente un hachís salado para comparar usando una segunda sal intermedia. Esto garantiza que el servidor no pueda aprender la contraseña del usuario durante la autenticación y que el usuario no aprenda la sal secreta del servidor ".

Puede obtener más información sobre las contraseñas OPAQUE en este documento [Enlace PDF] por investigadores de la Universidad de California, Irvine e IBM, y de Tatiana Bradley, ingeniera de Cloudflare blog.

Para llevar de SSL.com: Siempre nos entusiasma aprender sobre los nuevos protocolos de seguridad de red, especialmente en lo que se refiere a PKI y certificados digitales. Le brindaremos más información sobre estos y otros avances de seguridad y privacidad a medida que aparezcan y se implementen.

Credenciales FTP filtradas posiblemente vinculadas a SolarWinds Attack

A menos que haya pasado las últimas semanas en una cabina remota y sin conexión a la red (no es una mala idea ahora que lo pensamos), probablemente ya haya escuchado bastante sobre el ataque a la cadena de suministro que comprometió el software de monitoreo de TI Orion de SolarWinds y muchos de sus usuarios en el gobierno y la industria. 16 de diciembre de Ravie Lakshmanan historia in the Hacker News analiza cómo los atacantes "probablemente lograron comprometer la construcción de software y la infraestructura de firma de código de la plataforma SolarWinds Orion ya en octubre de 2019 para entregar la puerta trasera maliciosa a través de su proceso de lanzamiento de software".

La idea ... era comprometer el sistema de compilación, inyectar silenciosamente su propio código en el código fuente del software, esperar a que la empresa compilara, firmar paquetes y, por último, verificar si sus modificaciones aparecen en las actualizaciones recién lanzadas como se esperaba.

La línea de tiempo de octubre de 2019 se alinea con la del investigador de seguridad Vinoth Kumer descubrimiento, en noviembre de 2019, de un repositorio público de GitHub que filtró credenciales FTP de texto sin formato para el servidor de actualización de Solarwinds, y que este servidor era accesible con la contraseña "solarwinds123". El repositorio en cuestión había estado abierto al público "desde el 17 de junio de 2018", lo que les dio a los posibles atacantes mucho tiempo para descubrir y explotar las credenciales filtradas.

Por supuesto, no ayudó que SolarWinds también aconsejara a los usuarios que desactivaran las medidas de seguridad:

Para empeorar las cosas, el código malicioso agregado a una actualización de software de Orion puede haber pasado desapercibido para el software antivirus y otras herramientas de seguridad en los sistemas específicos debido al propio SolarWinds asesoramiento de soporte, que establece que es posible que sus productos no funcionen correctamente a menos que sus directorios de archivos estén exentos de análisis antivirus y restricciones de objetos de política de grupo (GPO).

Para llevar de SSL.com: Firma de código es un paso importante, incluso obligatorio, para mantener la confianza al distribuir software a los clientes, pero depende de un entorno seguro para el éxito. La protección de servidores cruciales con contraseñas débiles y fáciles de adivinar, y / o la exposición inadvertida de credenciales de texto sin formato al público, deja una puerta abierta a los ataques que explotan su sistema de compilación para liberar software firmado pero con troyanos.

Suscríbase al boletín de SSL.com

No se pierda los nuevos artículos y actualizaciones de SSL.com

Nos encantaría recibir tus comentarios

Responda nuestra encuesta y háganos saber lo que piensa sobre su compra reciente.