Con desafíos tan complejos como la miríada de tecnologías involucradas, la necesidad de una representación precisa con respecto a todo lo cibernético sigue siendo un esfuerzo esquivo.
Esto es particularmente cierto en el caso de la información entregada en forma de IoC (Indicadores de compromiso) que, durante años, han sido la piedra angular de muchos productos de seguridad basados en artefactos forenses y mecanismos de detección de intrusos similares. Compartir estos IoC de manera tokenizada y consumible también ha asegurado que la comunidad cibernética en general se mantenga visiblemente comprometida con los últimos patrones de ataque, cualquiera que sea su origen o nivel de sofisticación.
Existe un intento de recopilar información sobre amenazas en una nueva variante de IoC mediante la toma de huellas digitales de las condiciones iniciales que dominan las respuestas de cliente y servidor TLS independientemente de la plataforma subyacente. De hecho, JA3 ahora se ha incorporado a una multitud de herramientas de seguridad como un método para detectar aplicaciones maliciosas, especialmente aquellas implementadas a escala masiva y sin tener en cuenta la detección trivial.
Comenzaremos examinando brevemente las condiciones determinantes que rodean el proceso de protocolo de enlace de TLS en lo que respecta al conjunto de extensiones utilizadas por JA3 para el tráfico asociado con huellas digitales entre el cliente y el servidor, ampliando nuestro enfoque para abarcar aspectos relevantes de las capacidades de hash y etiquetado asociadas con JA3 en la identificación de plataformas de malware y agentes C2. Finalmente, exploraremos algunas de las deficiencias asociadas con JA3 a la luz de los intentos de eludir el núcleo de su funcionalidad.
Indice
Una cartilla TLS / SSL
Los datos sensibles requieren los mecanismos de protección más sólidos. Durante varios años, los principales estándares y protocolos, como Secure Sockets Layer (SSL), dominaron la escena de los túneles seguros al lograr una interacción adecuada entre el rendimiento y la confidencialidad, proporcionando comunicaciones seguras a través de medios no confiables como Internet.
A pesar de su éxito inicial, SSL se erosionó progresivamente bajo muchas debilidades criptográficas y sesgos estadísticos marcados por fallas en el diseño del protocolo que indicaban el potencial de ataques de fuerza bruta.
Posteriormente, Transport Level Security (TLS) se convirtió en la siguiente variante evolutiva después de una larga cadena de revisiones y mejoras que implicaron la adopción de nuevas formas de primitivas criptográficas y conjuntos de cifrado, la negociación de claves de sesión en lugar de enfoques distribuidos tempranos y mejores costes de cálculo. Fue precisamente esta agilidad criptográfica la que le dio a TLS su calidad multifacética, cubriendo una gama más amplia de aplicaciones de red y proporcionando servicios críticos como la confidencialidad y la integridad.
Para comprender cómo JA3 aprovecha ciertos atributos de TLS, echemos un vistazo más de cerca a la secuencia de conexión inicial del protocolo.
Inmediatamente después del protocolo de enlace de TCP, el lado del cliente envía un mensaje ClientHello que contiene combinaciones de algoritmos criptográficos compatibles por la persona que llama, detalles de versiones, extensiones, una lista de métodos de compresión y otros parámetros de sesión en bloques de datos de la aplicación.
En respuesta, el servidor envía su propio mensaje ServerHello cuando se ha confirmado un conjunto satisfactorio de algoritmos. El paquete también se formula con la propia versión del servidor de los parámetros de conexión utilizados por el cliente. A partir de entonces, el servidor y el cliente proceden a verificar la autenticidad del otro a través de certificados digitales, después de lo cual ambas partes calculan los secretos maestros y pre-maestro utilizados para derivar las claves de sesión, los mensajes de envoltura y las estructuras restantes de túnel de tráfico.
Los parámetros TLS que se ofrecen en el mensaje ClientHello contienen varias propiedades de identificación que están directamente relacionadas con la aplicación cliente.
Estas características estáticas incluyen compilaciones de SO, paquetes, bibliotecas e incluso atribuciones de procesos. Este nivel de granularidad es particularmente útil para crear huellas digitales con un alto grado de precisión que se puede aprovechar para identificar la misma aplicación durante sesiones futuras.
De manera similar, los servidores TLS construyen sus paquetes ServerHello basados en los de ClientHello , así como en su propio subconjunto de identificadores integrados como:
- Nombre y versión del sistema operativo
- Bibliotecas del lado del servidor
- Otras configuraciones personalizadas
Una vez más, esta relación simbiótica entre los paquetes de saludo del cliente y el servidor dicta la forma en que los servidores responden de forma única a una aplicación específica, proporcionando una excelente oportunidad para una identificación rápida.
Origen y funcionalidad de firmas JA3
Las firmas JA3, también conocidas como hashes JA3, aprovechan estas etapas iniciales de negociación y cualquier elemento estático combinado (transmitido en claro) para identificar de forma única las aplicaciones cliente en múltiples sesiones.
Este enfoque es similar a implementaciones anteriores en las que ciertos campos y extensiones se combinaron en una sola gota cohesiva compuesta de conjuntos de cifrado con huellas digitales para ayudar con desafíos recurrentes como la reducción de colisiones.
Cuando SFE decidió invertir tiempo y recursos en la construcción de JA3, la idea era capitalizar estas iniciativas anteriores; después de todo, como se mencionó anteriormente, la toma de huellas dactilares sistemáticamente de los paquetes TLS ClientHello de esta manera proporcionó un alto grado de precisión. Estratégicamente, todo lo que se requería era hacer que el proceso de toma de huellas dactilares fuera independiente de la herramienta y el destino.
Después de varios intentos e iteraciones adaptadas a los arreglos elegibles de los elementos del paquete inicial y las bibliotecas, el consenso fue recopilar y tomar las huellas digitales de los valores decimales de los bytes pertenecientes a:
- Número de versión de TLS
- Conjuntos de cifrado aceptados
- Longitud de las extensiones
- Curvas y formatos elípticos
Delimitado por comas y guiones, cada firma única se construiría conectando en cadena todos los valores pertinentes en el siguiente orden:
TLSVersion, Ciphers, Extensions, EllipticCurves, EllipticCurvePointFormats
A su vez, los campos vacíos, como las extensiones TLS, se compondrían de comas consecutivas así:
769,4–5–10–9–100–98–3–6–19–18–99 ,,,
Finalmente, la cadena tiene un hash MD5 para producir una huella digital de 32 caracteres que es fácil de compartir y consumir a través de una multiplicidad de herramientas de seguridad.
Por cierto, la codificación JA3 también requería tener en cuenta una serie de valores de campo TLS no reservados, como los recopilados por GREASE (Generate Random Extensions And Sustain Extensibility) de Google para desalentar que las implementaciones aleatorias impacten negativamente en el ecosistema, para obtener un hash uniforme resultante si las aplicaciones aprovecharon estos valores de GREASE o no.
Siguiente parada: JA3S
Con la toma de huellas dactilares del cliente TLS fuera del camino, la progresión natural sugirió que la toma de huellas dactilares de los mensajes TLS ServerHello sería igualmente ventajosa.
El enfoque fue completamente similar al de JA3 con dos diferencias clave:
- los hash JA3S se crearon utilizando los valores decimales de un subconjunto de campos JA3, a saber, TLSVersion, Cipher, Extensions
- La toma de huellas dactilares de un servidor basándose únicamente en su mensaje de saludo. fue percibido como insuficiente.
En cambio, SFE se centró en la forma en que los servidores responden al mismo cliente en la extensión de varias conexiones para descubrir que, aunque las respuestas del servidor varían cuando responden a diferentes clientes, generarán la misma respuesta para el mismo cliente cada vez.
Implementación
Observar cómo los clientes establecen conexiones TLS brinda una amplia oportunidad para que los defensores de la red separen el malware básico del tráfico legítimo. Los signos distintivos que dejan atrás los C2 personalizados, o básicamente cualquier software potencialmente no deseado, en relación con el sistema operativo host, constituyen una forma única de detección. Por ejemplo, un servidor C2 particular que se ejecuta en Kali Linux generaría un par de firmas único que se puede consumir fácilmente.
A primera vista, la eficacia de las firmas JA3 / S es difícil de refutar. Después de todo, las desviaciones de las firmas de referencia son siempre una propuesta lucrativa; uno que es históricamente entendido y perseguido trivialmente por los analistas de seguridad.
Teniendo esto en cuenta, la creación de perfiles de aplicaciones se convierte en una cuestión de «alimentar» programáticamente sus herramientas utilizando recursos como la API REST de JA3er para comenzar a inspeccionar su tráfico. Poco después, estará en condiciones de separar las aplicaciones legítimas (o incluso mal configuradas) de las ilegítimas, con un enfoque potencial en casos poco comunes de servicios permitidos que llegan a dominios sospechosos, por nombrar algunos.
Por ejemplo, las herramientas de seguridad como RSA Netwitness pueden producir el valor JA3 de los clientes y servidores TLS observados en una sesión de red almacenados como valores de texto utilizando meta elementos independientes.
Aunque la referencia cruzada de hashes JA3 usando ja3er.com constituye una pieza importante del rompecabezas, se puede obtener una imagen más completa emparejándolos con sus contrapartes JA3S. Nuevamente, esto se debe a que los parámetros en el mensaje ServerHello están vinculados criptográficamente a los presentes en el lado ClientHello. Por ejemplo, una versión específica del popular servidor web Nginx responderá a una versión específica del navegador Firefox de la misma manera, siempre.
Desde el punto de vista de un defensor, esta nueva capacidad para crear emparejamientos JA3 / S se puede utilizar para identificar combinaciones únicas de tecnologías cliente-servidor, como las vinculadas al malware y cualquier infraestructura C2 relacionada.
En consecuencia, se pueden establecer mecanismos de alerta para advertir de cualquier hash recién adquirido que el personal de seguridad pueda recopilar, compartir y eliminar rápidamente. Un escenario menos riguroso puede implicar la identificación de aplicaciones cliente mal configuradas que acceden a instancias y servicios específicos a los que pueden no tener derecho, o scripts no autorizados y programas potencialmente no deseados que se ejecutan en su entorno.
Limitaciones
A pesar de su popularidad, las firmas JA3 / S están plagadas de importantes inconvenientes. Por un lado, la taxonomía JA3 que se desarrolla aplicando hash a los lados del cliente y del servidor de la ecuación es propensa a las inexactitudes acumuladas por la producción de diferentes hashes relacionados con la misma aplicación, o por las colisiones de hash resultantes de generar la misma firma JA3 para diferentes aplicaciones.
Esto se debe en parte a que JA3 ignora las extensiones no criptográficas como la Indicación de nombre del servidor (SNI) o la información del certificado, dejando solo un puñado de campos cuyo espacio de permutación limitado deja espacio para firmas duplicadas.
En este sentido, catalogar muestras de malware con JA3 es un desafío porque las sutilezas del sistema operativo y las bibliotecas de programación específicas de la estación de trabajo del atacante entran en juego al determinar los valores hash finales.
Además, la naturaleza unidireccional de los algoritmos y funciones hash hace que ciertas operaciones sean extremadamente difíciles (si no imposibles) de lograr, como extraer y examinar los valores individuales que se incluyeron en el hash para correlacionar aspectos iniciales como los campos TLS condicionales y las versiones del protocolo.
Limitaciones similares han permitido una serie de técnicas de evasión que giran en función de la capacidad de una fuente determinada para obtener acceso de bajo nivel a apretones de manos y flujos de claves, lo que ayuda a los actores de amenazas a manipular y aleatorizar ClientHellos a voluntad para derrotar la identificación adecuada.
Conclusión
Cuando se combinan con métricas más tradicionales, los métodos de huellas digitales como JA3 pueden proporcionar una forma rápida y fácil de enriquecer los IoC en todos los ámbitos. Algunos de los mejores casos de uso destacan la posibilidad de identificar pasivamente implementaciones y botnets populares de C2, detectar patrones de tráfico cambiantes a lo largo del tiempo que apuntan a posibles desajustes de protocolo e incluso detectar compromisos de equipos rojos o pentesters que toman atajos en sus implementaciones.
En esencia, JA3 no asume que sea un generador de señales de alta fidelidad y, por lo tanto, no debe tratarse como tal. Las detecciones basadas en firmas son tan buenas como los datos contextualizados y los indicadores adicionales que los rodean, así que prepárate para incluir JA3 / S en una combinación que combine el comportamiento de línea de base predominante, los procesos de host y las características de destino de dominio con cualquier conocimiento potencial de huellas digitales de TLS evite inundar a sus analistas con una avalancha de falsos positivos.
En resumen, a medida que los marcos de detección continúan creciendo, la imposibilidad percibida de mirar dentro del tráfico cifrado puede aliviarse mediante una toma de huellas digitales adecuada; uno que tenga en cuenta un conjunto más amplio de condiciones del host y de la red en respuesta directa a los esfuerzos en curso de los atacantes y los actores de amenazas para eludir las defensas adecuadas.