Internet se basa en su capacidad para permitir que los dispositivos se comuniquen entre sí e, incluso cuando se creó por primera vez, los pioneros de Internet ya pensaban en la necesidad de seguridad y privacidad. A medida que Internet crecía, surgió la necesidad de mantener conversaciones cifradas "seguras" a través de la red y se adoptaron e implantaron determinados estándares criptográficos que permitían comunicaciones seguras entre clientes y servidores. Así surgieron los protocolos criptográficos Secure Sockets Layer (SSL) y Transaction Layer Security (TLS).
SSL y TLS están pensados para proteger las comunicaciones entre dos dispositivos (un cliente y un servidor). Los certificados digitales están pensados para demostrar que un servidor pertenece realmente a una entidad específica, para garantizar que un cliente está hablando con un servidor verificado y no con un dominio fraudulento. Las claves SSL/TLS garantizan que las conversaciones entre esos servidores están encriptadas y protegidas. SSL/TLS muestra un cliente de confianza; los certificados garantizan un servidor de confianza. Todo esto tiene sentido en teoría, por supuesto, pero en la práctica, las cosas se complican rápidamente.
Los ataques que aprovechan los problemas y los errores de configuración de los clientes de cifrado TLS y SSL existen desde hace décadas, en parte debido a que la propia tecnología de cifrado tiene más de 20 años. Los ciberdelincuentes se aprovechan de las debilidades de TLS y SSL porque se trata de una fruta madura que ofrece grandes recompensas a cambio de muy poco esfuerzo o riesgo para los atacantes.
El hecho de que todo lo que hay en Internet esté conectado mediante esta vieja tecnología pone prácticamente todo en peligro, pero se han hecho algunos avances para garantizar que no tengamos que tirar a la basura todo Internet y empezar de nuevo (no, esto no es una opción). Al final de este artículo hablaremos de los consejos de seguridad. Pero, primero, los ataques del mundo real.
Ataque DROWN, FREAK, Logjam, Heartbleed...TODOS LOS ATAQUES
Muchos de los ciberataques de los que oímos hablar en estos días están relacionados con SSL (OpenSSL, en particular) y los protocolos TLS, incluidos algunos ataques generalizados muy públicos en la última década, como DROWN, FREAK, Logjam y Heartbleed. Casualmente, varios de nuestros fundadores analizaron e informaron extensamente sobre estos tres conocidos ataques. CensysEl director de ingeniería David Adrian, el tecnólogo jefe Zakir Durumeric y el científico jefe J. Alex Halderman formaron parte de los equipos de investigación que fueron los primeros en informar sobre los ataques DROWN y Logjam y los primeros investigadores en medir el impacto de los ataques DROWN, Logjam, FREAK y Heartbleed. Estos ataques fueron de los primeros en demostrar el valor de escanear la Internet global para cazar ataques, medir su impacto y comprender cómo funcionaban.
Estos ataques terroríficos, con logotipos y marcas, frenéticos en los medios de comunicación, tenían algo en común, utilizaban clientes SSL y TLS para espiar los datos compartidos entre el cliente y el servidor o servidores. Los atacantes eran capaces de insertar sondas en los servidores SSL/TLS para leer la conexión entre el cliente y el servidor. Con ese acceso, los malintencionados podían leer y modificar los datos transmitidos a través de los servidores web y de correo electrónico; sólo en el caso del ataque DROWN, decenas de miles de servidores se vieron afectados.
Búsqueda de activos vulnerables desconocidos mediante el protocolo SSL/TLS para mejorar la seguridad
Censys indexa certificados TLS asociados con hosts y servicios y también rastrea algunas vulnerabilidades específicas, lo que significa que puede utilizarlo para encontrar dispositivos y certificados obsoletos e inseguros en su organización. Le mostraremos algunas de esas búsquedas, relacionadas con TLS. El mayor problema al que se enfrentan los equipos de TI es simplemente la capacidad de ver todo lo que se utiliza en su empresa, fuera de los dispositivos conocidos de propiedad corporativa. Es posible que haya algunos hosts que utilicen un protocolo TLS vulnerable y que puedan servir de vía de entrada para los atacantes. Así que empecemos por encontrarlos.
Sabemos que una longitud de clave pública débil es un indicador de que un certificado TLS es potencialmente vulnerable. Perspective Risk publicó un artículo en profundidad sobre este tema si desea profundizar en él. El tamaño de las claves criptográficas es un factor crucial en la seguridad de las claves, suponiendo que otros factores se mantengan constantes (protección de la clave privada frente a accesos no autorizados, un buen generador de números aleatorios, etc.).
En 2019, las longitudes de clave pública generalmente se consideran débiles si son inferiores a 2048 bits. Eso significa que podríamos centrarnos en buscar tamaños de clave débiles comunes para localizar hosts vulnerables a ataques de fuerza bruta.
Comience con la siguiente búsqueda y sustituya el campo de nombres analizados ("ejemplo.com") por el dominio de su organización:
https://censys.io/ipv4/help?q=443.https.tls.certificate.parsed.subject_key_info.rsa_public_key.length%3A+%5B+0+TO+2047+%5D+AND+443.https.tls.certificate.parsed.__expanded_names%3A+example.com
Este rango de búsqueda captura todas las claves públicas que están por debajo de los 2048 bits y que serían intrínsecamente débiles desde el punto de vista de la seguridad.
A continuación, busque hosts vulnerables a Heartbleed
Esta búsqueda le mostrará todos los dominios utilizados en su organización que son vulnerables a Heartbleed. Sustituya "ejemplo.com" por su dominio:
https://censys.io/ipv4?q=%28443.https.heartbleed.heartbleed_vulnerable%3A+true+AND+443.https.heartbleed.heartbeat_enabled%3A+true%29+AND+443.https.tls.certificate.parsed.names%3A+example.com
Certificados antiguos o débiles
A continuación, puede buscar certificados obsoletos o caducados de dispositivos que posea o que estén en uso en su organización, utilizando el conjunto de datos de certificados deCensys . CensysEl sistema de etiquetado ' facilita la búsqueda de estos certificados directamente en la página de resultados. A continuación se explica cómo buscarlos:
- Elija el menú desplegable "certificados" situado junto a la barra de búsqueda de Censys y seleccione parsed.names: [sudominio].
- https:// censys.io/certificates?q=aol.com - sustituya "aol.com" por su dominio
- A continuación, a partir de esos resultados, filtre hacia abajo en función del estado de confianza del certificado desde el margen izquierdo, seleccionando "No fiable" "Nunca fiable" "Autofirmado" "Caducado", etc. hasta obtener la lista de dominios que necesita explorar más a fondo.
Configuraciones TLS con algoritmos hash débiles
Si a continuación buscamos en el conjunto de datos IPv4 seleccionando "IPv4" en el menú desplegable, podemos buscar los algoritmos hash utilizados en el conjunto de cifrado, que también influyen en la seguridad TLS. Algunos algoritmos hash son vulnerables a ataques de colisión, en los que el algoritmo genera el mismo valor hash para dos entradas independientes.
Puede utilizar Censys para encontrar instancias de configuraciones TLS que utilicen algoritmos hash débiles con vulnerabilidades o ataques conocidos (SHA-1 y MD5, en nuestro ejemplo):
https:// censys.io/ipv4?q=443.https.tls.signature.hash_algorithm%3A+%2Fsha1%7Cmd5%2F+AND+443.https.tls.certificate.parsed.names%3A+example. com (de nuevo, tendrá que sustituir el dominio "example.com" de nombres analizados por el suyo propio para que esto funcione).
Estos son sólo algunos ejemplos de cómo encontrar activos vulnerables que aún no conocías a través de Censys, pero es un buen comienzo. Ocuparse de cualquiera de esos problemas antes de que sean explotados, causando daños a su negocio, mejora la seguridad general de la empresa y evita traumas en el futuro.
Algunos consejos para mejorar la higiene de la seguridad y el cumplimiento de la normativa PCI
Así que ha encontrado algunos servidores que utilizan SSL/TLS obsoletos y vulnerables en su empresa, ¿y ahora qué? En primer lugar, aborda este par de cosas primero para evitar cosas como los ataques man-in-the-middle (MITM):
- Asegúrese de configurar sus servidores para que admitan las versiones más recientes del protocolo TLS: la 1.2 es ampliamente compatible tanto en servidores como en clientes, y la 1.3 se ha finalizado y la compatibilidad es incipiente.
- Desactive TLS 1.0 si aún no lo ha hecho y TODAS las versiones de SSL
- Aunque estamos seguros de que siempre sigues nuestros consejos, vale la pena señalar que a partir de junio de 2018 debes tener deshabilitado el soporte para todas las versiones de SSL y las primeras versiones de TLS para cumplir con PCI. Más detalles al respecto aquí
- Si ha encontrado certificados antiguos caducados en dispositivos que aún están en uso, asegúrese de haber iniciado el proceso de renovación de dichos certificados y de haberlos añadido a su lista de inventario de gestión de activos.
