Estamos tan sorprendidos como cualquiera al informar que otro mes ha pasado volando. Y, aunque pasó rápido, agosto estuvo lleno de noticias de seguridad. Este mes echaremos un vistazo a:
- Internet de las cosas vulnerable a través de protocolos de comunicación inseguros
- China Bloques TLS 1.3 y ENSI
- Vulnerabilidad de wolfSSL descubierta
- Lanzamiento de la versión tres del estándar PKCS # 11 de OASIS
Internet de las cosas dejada abierta a través de protocolos de comunicación inseguros
Más de 3.7 millones de dispositivos IoT (Internet de las cosas) se han dejado abiertos al ataque a través de dos protocolos de comunicación inseguros de igual a igual: Red CS2 P2P y Shenzhen Yunni iLNKP2P.
Un artículo de Shaun Nichols en El registro se mete en los problemas que han dejado cosas como cámaras web, monitores para bebés y otros dispositivos conectados a Internet vulnerables al secuestro. Los dos protocolos son utilizados por millones de dispositivos en todo el mundo, lo que significa que cualquiera que quiera fisgonear o algo peor puede acceder a esos dispositivos.
Los errores fueron encontrados por Paul Marrapese, que tiene un sitio completo, cámara pirateada, dedicado a las vulnerabilidades. `` Hasta agosto de 2020, se han encontrado más de 3.7 millones de dispositivos vulnerables en Internet '', dice el sitio, que enumera los dispositivos afectados y consejos sobre qué hacer si tiene algún equipo en riesgo. (Resumen: deséchelo o intente cortarlo con un firewall).
Por supuesto, como señala Nichols, las vulnerabilidades no terminan con los dispositivos en los que se ejecutan los protocolos de comunicación.
... tenga en cuenta que estos dispositivos se encuentran en las redes Wi-Fi y LAN de las personas, por lo que una vez que haya tomado una cámara de seguridad, o lo que sea, puede acceder a las máquinas adyacentes para explotarlas, o usar las direcciones MAC de la red inalámbrica cercana para identificar la ubicación del hardware de las bases de datos de Google, etc.
Para leer el artículo completo, "y así sucesivamente", que es bastante, recomendamos leer el artículo completo, también nos lleva a un Charla DEFCON de Paul Marrapese que ofrece una mirada en profundidad para cualquiera que esté interesado o preocupado por los riesgos de seguridad:
Los grandes bloques cortafuegos TLS 1.3 y ENSI
Agosto también trajo noticias que el Gran Cortafuegos de China ahora bloquea HTTPS tráfico que usa TLS 1.3 y ESNI (Indicación de nombre de servidor cifrado). Ambas tecnologías dificultan que los censores chinos vean a qué sitios los ciudadanos intentan conectarse y que los censores controlen el acceso a esos sitios web.
Una articulación reporte de IYouPort, la Universidad de Maryland y el Great Firewall Report confirmaron la prohibición, según un artículo por Catalin Cimpanu de ZDNet. La prohibición, que entró en vigor a finales de julio, todavía permite el tráfico HTTPS que utiliza versiones anteriores de TLS y sin cifrar SNI, lo que permite a los censores del gobierno ver a qué dominios intentan llegar los ciudadanos.
Por el momento, los grupos que lanzaron el reporte han identificado seis formas de eludir la prohibición del lado del cliente y cuatro formas de evitarla del lado del servidor, pero tanto el grupo como el artículo de ZDNet reconocen que estas soluciones no son una solución a largo plazo como el "juego del gato y el ratón" entre la tecnología y La censura china avanza.
Vulnerabilidades en wolfSSL descubiertas
Gérald Doussot de la empresa de seguridad cibernética Grupo NCC una publicación asesoría técnica el 24 de agosto describiendo un TLS 1.3 vulnerabilidad en versiones de loboSSL antes de 4.5.0. La versión 4.5.0 de la biblioteca wolfSSL, que contiene una solución, se lanzó el 17 de agosto, antes de la publicación del aviso del Grupo NCC, y el Grupo NCC recomienda que los usuarios actualicen a la versión más nueva y segura.
Según NCC Group:
wolfSSL implementa incorrectamente el TLS 1.3 máquina de estado del cliente. Esto permite a los atacantes en una posición de red privilegiada suplantar completamente cualquier TLS 1.3 servidores y leer o modificar información potencialmente sensible entre clientes que utilizan la biblioteca wolfSSL y estos TLS servidores.
Como se describe en Sitio web de wolfSSL, la biblioteca SSL embebida de wolfSSL en cuestión “es un SSL ligero, portátil y basado en lenguaje C /TLS biblioteca dirigida a entornos de IoT, integrados y RTOS principalmente debido a su tamaño, velocidad y conjunto de funciones ". El hecho de que estas vulnerabilidades se encuentren en Internet de las cosas y de que las “cosas” en las que se encuentra wolfSSL asciendan a miles de millones hace que valga la pena notarlo. Se recomienda encarecidamente una actualización de la versión fija disponible de la biblioteca.
Lanzamiento de la versión tres del estándar PKCS # 11 de OASIS
Un agosto de 19 anuncio en el blog de PrimeKey nos dio una pista sobre el hecho de que la versión 3 de la interfaz de token criptográfico PKCS # 11 estándar de OASIS se publicó en junio de 2020.
PKCS # 11 existe desde 1995 y, como lo describe el propio blog, es una “API independiente de la plataforma para acceder y utilizar funciones criptográficas en módulos de seguridad de hardware (HSM), tarjetas inteligentes, tokens USB, TPM y similares. "
Según clave principal (proveedores del software de autoridad de certificación EJBCA), el estándar PKCS # 11 ha tenido algunos problemas con los problemas de estandarización relacionados con los mecanismos definidos por el proveedor en los tokens de hardware que limitan su utilidad como API estándar. La versión anterior del estándar también ha tenido algunos problemas para mantenerse al día con el rápido ritmo del desarrollo criptográfico en estos días, por lo que la versión tres es un cambio necesario y bienvenido. Como señala el blog:
En general, ha funcionado sorprendentemente bien a lo largo de los años, pero ha habido matices sutiles que requieren consideración al intentar utilizar un nuevo token que afirma ser compatible con PKCS # 11, lo que provoca problemas de interoperabilidad entre clientes y servidores.
La adición de nuevos mecanismos criptográficos estandarizados en PKCS # 11 v3.0 (incluidas las firmas SHA3 y EdDSA) permitirá a PrimeKey y a otros proveedores de software implementarlos de manera estandarizada en módulos de seguridad de hardware y tokens que admitan el nuevo estándar.
