Resumen de seguridad de septiembre de 2020

¡Bienvenido a la edición de septiembre del Resumen de seguridad mensual de SSL.com! Hoy hablaremos de:

• SSL.com es nuevo newsletter
• Cambios en el Foro CA / B Directrices SSL con EV
• Los planes de Rusia para prohibir protocolos que ocultan el destino del tráfico de internet
• El Ataque de mapache on TLS versiones 1.2 y anteriores
• Inseguro Internet de los objetos (IO) prácticas
  

¡Anunciamos el boletín de SSL.com!

¡SSL.com se enorgullece de anunciar nuestro nuevo boletín mensual por correo electrónico! Cada mes le enviaremos noticias e información sobre seguridad en Internet, PKIy certificados digitales, junto con información sobre nuevos productos y servicios ofrecidos por SSL.com. Para registrarse, simplemente complete el formulario a continuación. (Puede darse de baja fácilmente en cualquier momento haciendo clic en el darse de baja enlace en cada correo electrónico que enviamos.):

CA / B Forum Ballot SC30: Cambios en las pautas del certificado SSL con EV

En noticias de interés para SSL.com's SSL EV clientes, la versión actual (1.7.3) de CA / Browser Forum's Directrices del certificado SSL con EV, que entró en vigor el 20 de agosto de 2020, tiene algunos requisitos nuevos. Específicamente, como se describe en CA / B Forum Boleta SC30, las autoridades de certificación (CA), como SSL.com, ahora deben publicar la lista de agencias de registro e incorporación que utilizan al validar las solicitudes de certificado SSL con EV. (La medida está en línea con un objetivo más amplio de hacer que las fuentes de validación de EV sean consistentes entre las CA).

Como resultado, SSL.com publicará una lista de las fuentes de información que usamos al validar empresas y otras organizaciones para certificados EV. Cuando no podamos ubicar la organización de un solicitante en nuestra lista actual de fuentes, intentaremos ubicar otra fuente de información viable y agregarla a nuestra lista publicada antes de validar el pedido y emitir el certificado.

Rusia planea prohibir protocolos que ocultan el destino del tráfico

Esta historia puede parecerle familiar si se ha mantenido al día con las noticias de seguridad digital. De hecho, el mes pasado informamos en una historia de que el "Gran Cortafuegos" de China ahora bloquea el tráfico HTTPS que usa TLS 1.3 y ENSI (Indicación de nombre de servidor cifrado) en un esfuerzo por facilitar a los censores chinos ver qué sitios están intentando visitar los ciudadanos y controlar el acceso a dichos sitios.

Este mes, un informe de Catalin Cimpanu en ZDNet explicó que Rusia ahora está buscando prohibir el uso de algunos protocolos con una actualización de las leyes de tecnología que "harían ilegal el uso de protocolos de cifrado que oculten completamente el destino del tráfico". Como se señala en el artículo, estos protocolos incluirían TLS 1.3, Departamento de Salud, DoT y ESNI. El razonamiento es, por supuesto, muy parecido al razonamiento detrás de la prohibición de China: los protocolos impiden el alcance de la vigilancia y la censura por parte del estado. Del artículo:

Rusia no usa un sistema de firewall nacional, pero el régimen de Moscú se basa en un sistema llamado SORM que permite a las fuerzas del orden interceptar el tráfico de Internet con fines de aplicación de la ley directamente en la fuente, en los centros de datos de telecomunicaciones.
Además, el Ministerio de Telecomunicaciones de Rusia, Roskomnadzor, ha estado ejecutando un firewall nacional de facto a través de su poder regulador sobre los ISP locales. Durante la última década, Roskomnadzor ha estado prohibiendo los sitios web que considera peligrosos y pidiendo a los ISP que filtren su tráfico y bloqueen el acceso a los sitios respectivos.
Con TLS 1.3, DoH, DoT y ESNI se están adoptando, todas las herramientas de vigilancia y censura actuales de Rusia se volverán inútiles, ya que dependen de tener acceso a los identificadores de sitios web que se filtran del tráfico web cifrado.

La ley se encuentra actualmente bajo consideración, pendiente de comentarios del público, y se volverá a votar a principios de octubre. ZDNet señala que, dado el clima, "es casi seguro que la enmienda se aprobará".

Nuevo TLS Ataque: mapache

Ya tenemos un blog sobre el "ataque de mapache", pero vale la pena mencionarlo nuevamente, ya que el ataque puede permitir que terceros rompan SSL /TLS cifrado para leer la comunicación destinada a mantenerse segura. Como se explica en un artículo académico, el ataque explota una vulnerabilidad de sincronización en TLS versiones 1.2 y anteriores, y podría descifrar comunicaciones que incluyen nombres de usuario, contraseñas, datos de tarjetas de crédito y otra información confidencial. De nuestra publicación a principios de este mes:

Si bien suena aterrador, tenga en cuenta que este ataque solo puede tener lugar en circunstancias muy específicas y raras: el servidor debe reutilizar claves públicas Diffie-Hellman en el apretón de manos (ya se considera una mala práctica), y el atacante debe ser capaz de realizar mediciones de tiempo precisas. Además, el navegador debe admitir los conjuntos de cifrado vulnerables (a partir de junio de 2020, todos los navegadores principales los han descartado).

Internet de las cosas (vulnerables), Coffee Maker Edition

Si bien la historia anterior no fue sobre los ataques de los mapaches, esta historia es realmente sobre cafeteras. Para ser más precisos, el artículo de Dan Goodin en Ars Technica se trata de cómo una cafetera se convirtió en una "máquina de rescate" aprovechando las debilidades comunes en los dispositivos de Internet de las cosas (IoT).

Básicamente, el iKettle de los productos Smarter (mal nombrado) ha sido durante mucho tiempo un objetivo para aquellos que buscan ilustrar los peligros de los dispositivos fáciles de piratear. Desde 2015, versiones del hervidor han sido requisados ​​de forma remota mediante ingeniería inversa. Aunque la compañía ha lanzado una nueva versión del bote desde entonces, las viejas todavía están en uso, y son vulnerables a lo que las notas del artículo son ataques "listos para usar". Recientemente, un programador llamado Martin Hron decidió probar los límites de cómo se vería una brecha de seguridad en una cafetera, en el peor de los casos:

Cuando Hron conectó por primera vez su cafetera Smarter, descubrió que inmediatamente actuaba como un punto de acceso Wi-Fi que usaba una conexión no segura para comunicarse con una aplicación de teléfono inteligente. La aplicación, a su vez, se utiliza para configurar el dispositivo y, si el usuario lo elige, conectarlo a una red Wi-Fi doméstica. Sin cifrado, el investigador no tuvo problemas para aprender cómo el teléfono controlaba la cafetera y, dado que tampoco había autenticación, cómo una aplicación de teléfono no autorizada podía hacer lo mismo.
Esa capacidad todavía dejaba a Hron con solo un pequeño menú de comandos, ninguno de ellos especialmente dañino. Entonces examinó el mecanismo que usaba la cafetera para recibir actualizaciones de firmware. Resultó que se recibieron desde el teléfono, lo adivinó, sin cifrado, sin autenticación y sin firma de código.

Hay una publicación de blog extensa sobre el truco de la cafetera llamada "El fresco olor del café rescatado. " Hay también un video divertido demostrando el caos que siguió a la explotación de las vulnerabilidades de la máquina de café. Si bien es poco probable que un ataque como este llegue pronto a la cocina de alguien, es un buen recordatorio de que "inteligente" significa más que "conveniente".