El 23 de mayo de 2023, Barracuda anunció una vulnerabilidad (CVE-2023-2868) en su dispositivo Email Security Gateway que ya estaba siendo explotada en octubre de 2022. El 15 de junio de 2023, Mandiant publicó un análisis detallado de las actividades y los actores de amenazas implicados en la campaña que estaba explotando activamente la CVE-2023-2868. Posteriormente, el equipo de amenazas emergentes de Proofpoint publicó una regla de detección Suricata (SID 2046280) para detectar intentos de explotación de la vulnerabilidad notificada. Durante una reunión con un cliente Vectra AI , se planteó la preocupación de que la regla existente podría no estar funcionando como se esperaba. Después de realizar las pruebas iniciales, descubrimos que la regla no alertaba sobre un exploit de prueba de concepto específico, a pesar de la entrega satisfactoria de la carga útil del exploit.
Analizamos la regla y el exploit relacionado e identificamos la brecha de detección específica, causada por un orden no determinista del contenido relacionado con el exploit dentro de la carga útil del exploit (en la sección "Un breve vistazo al exploit de prueba de concepto", más adelante, se ofrecen más detalles). Una vez identificada la brecha, pudimos reescribir una regla para proporcionar la cobertura de detección necesaria. Tras enviar nuestros hallazgos al equipo EmergingThreats de Proofpoint, publicaron una nueva regla de detección M2. Este informe proporciona una explicación del proceso de análisis y redacción de reglas utilizado para la regla de detección M2 que eliminó el falso negativo confirmado.
TL;DR
La regla ET de Proofpoint es defectuosa debido a que asume que todo el mundo sigue las reglas, incluso aquellos que no lo hacen. En este análisis, encontramos un archivo TAR manipulado que desliza una carga útil más allá de la regla de detección de ET para CVE-2023-2868 porque el autor del exploit no siguió las reglas. E incluso con una regla de detección mejorada en su lugar, la preocupación sigue siendo: si nos encontramos con otra estructura de archivo manipulado mañana, ¿podría eludir las reglas de detección de ET de nuevo?
1. Anatomía de CVE-2023-2868
El informe de Mandiant proporciona una explicación de la vulnerabilidad, pero para mayor comodidad, la hemos resumido con la siguiente ilustración. Como puede ver, ciertas versiones de Barracuda Email SecurityAppliance son vulnerables a una vulnerabilidad de inyección.
Para identificar esta carga maliciosa, el Equipo de Investigación de Amenazas Emergentes desarrolló una sala de detección que buscaba "'`" (comilla simple, tilde invertida) y "`'" (comillas simples) en determinados tipos de paquetes. Como veremos, su método de construcción de reglas permitió que algunas Pruebas de Concepto pasaran desapercibidas.
2. Un breve vistazo al exploit de prueba de concepto
Centrando nuestra atención en el exploit de la prueba de concepto de vulnerabilidad (PoC), disponible aquí, empezamos a identificar qué carga útil subyacente se utiliza y debería activar la regla de detección de amenazas emergentes. Como se muestra a continuación, la variable "CMD" utiliza la misma estructura básica de comandos que se describe en el informe de Mandiant:
Tenga en cuenta que la variable "PAYLOAD" comienza con la comilla simple y la marca de verificación y termina la variable "CMD" con la marca de verificación y la comilla simple. Esto es lo que activará la inyección de comandos.
Un vistazo al PdC por cable en hexadecimal
Aquí está la salida de una representación hexadecimal del archivo tar generado que contiene la carga útil mostrada arriba:
"PAYLOAD", que son los patrones de inyección, están resaltados en rojo. La cadena de comandos asignada a la variable "CMD" está resaltada en azul:].
Observe en la parte superior del archivo que algunos restos de la variable CMD están presentes, así como los patrones de inyección \x60\x27 (back tick, comilla simple). Volveremos a esta parte importante más adelante.
Una estructura de archivo Tar normal
Antes de entrar en los defectos de la regla de detección, es importante entender la estructura de un archivo tar normal. Los archivos tar se organizan en bloques de 512 bytes. Básicamente, el formato de un archivo tar es:
- "Cabecera" contiene el nombre del archivo, además de algunos metadatos adicionales.
- "Contenido" contiene los datos reales del archivo.
Un vistazo a un archivo normal de Tar en hexadecimal
Lo que se considera un archivo Tar "normal" es un fichero que ha sido creado por una utilidad que sigue las reglas y respeta el formato TAR de los sistemas UNIX o el formato USTAR definido por el estándar POSIX 1003.1. Este es un volcado hexadecimal de un archivo tar normal que contiene tres ficheros normales llamados 1, 2 y 3, utilizando la utilidad tar:
Podemos ver el archivo llamado 1, seguido de algunos códigos de bytes y, a continuación, el contenido del archivo "hola 1", al que sigue el archivo llamado 2 y así sucesivamente. Claramente, la utilidad de creación de archivos tar coloca los datos de cabecera y contenido en orden descendente basándose en los nombres de los ficheros. En otras palabras, es consciente de las reglas dictadas por el estándar de formato de archivo y las respeta.
Cabe destacar que la estructura del archivo es diferente de la generada por el exploit y presentada en la primera sección. El exploit PoC contiene una serie de comandos en la cabecera en lugar de nombres de archivos, como era de esperar. Para hacer esto posible, el autor del exploit tuvo que ser un poco astuto.
Disección del exploit R7
El exploit escrito por el equipo Rapid7 Security Researcher tiene una parte dedicada, con comentarios, a la clase Ruby "TarWriter":
Este exploit anula las comprobaciones de tamaño de nombre de archivo que se hacen originalmente por la función "split_name() " aquí:
Se han eliminado 3 sentencias "if" de la función original. Estas 3 sentencias elevan "TooLongFileName" para verificar si:
1. La ruta del archivo es demasiado larga
2. El nombre del archivo es demasiado largo
3. La ruta base del archivo es demasiado larga
Si se observa la carga útil del exploit y se cuentan los caracteres, se obtienen 129 bytes:
Según el código de la PoC, si el comando a ejecutar tiene más de 100 bytes, se dividirá en varias "entradas de archivo" en el archivo tar. Ponemos "entradas de archivo" entre comillas dobles porque el archivo tar malicioso en realidad no contiene archivos, sino una secuencia de escape y comandos incrustados que el atacante quiere ejecutar.
Revisando el volcado hexadecimal del archivo tar malicioso, ahora podemos entender por qué la primera entrada en el archivo tar es una `' colgando (back tick, comilla simple) y el final de la variable CMD, que debería venir al final del comando.
Dado que el comando excede el límite de 100 bytes impuesto en la estructura de nombres de archivo para la cabecera de un archivo, el comando se dividió en dos entradas de archivo con la segunda entrada de archivo conteniendo sólo la terminación p"`' (letra p, comilla doble, tilde invertida, comilla simple). Esa entrada de archivo aparece al principio del archivo tar porque el contenido del archivo tar se ordena en orden descendente y una cadena p"`' (letra p, comilla doble, tilde invertida, comilla simple) va antes que una cadena ``s (comilla simple, tilde invertida, letra s) cuando se ordena en orden descendente:
Mientras que el orden dentro de un archivo tar es consistente, el orden de la secuencia de escape y el contenido del comando de la carga útil del exploit no será determinista desde la perspectiva de la regla de detección porque el orden variará dependiendo de la longitud combinada y los caracteres utilizados en los comandos incrustados dentro de la carga útil.
3. Explicación de alto nivel de la regla de detección:
Una vez que tuvimos una mejor comprensión de la vulnerabilidad, lo que se necesita para explotarla, y confirmamos qué patrones necesitan ser discriminados dentro del exploit, dirigimos nuestra atención a la regla de detección del archivo emerging-exploit.rules:
Para simplificar, esta regla busca 3 patrones:
1. Cualquier paquete SMTP proveniente de cualquier lugar, destinado a cualquier servidor SMTP contenido en el mapeo $SMTP_SERVERS. Tenga en cuenta que, por defecto, Suricata asigna $SMTP_SERVERS a $HOME_NET, por lo que cualquier servidor SMTP interno estará cubierto por la regla.
a. Que contenga un adjunto de archivo tar válido; el adjunto debe coincidir con los números mágicos de archivo de un archivo TAR.
b. Que contiene en su interior estos dos patrones "|27 60|" y "|60 27|".
Las palabras clave buscadas son la representación hexadecimal de los siguientes caracteres ASCII"'`" (comilla simple, tilde invertida) y "`'" (comillas simples). Los caracteres "'`" (comilla simple, tilde invertida) se utilizan para desencadenar la ejecución del comando como se ha explicado anteriormente. A continuación se muestra la representación hexadecimal del exploit con los 3 patrones resaltados que busca la regla de detección:
Volviendo a la regla, vemos que también hay un parámetro "distancia" y "dentro de" que se pueden emparejar para afinar una regla. Los parámetros se utilizan del siguiente modo:
- Distancia: fija el cursor en el punto de inicio del análisis.
- Distancia: 0 significa que el patrón puede estar en cualquier lugar después de la coincidencia anterior +0bytes. Así que justo después de \x27\x60 en nuestro ejemplo anterior.
- Dentro de: Limita cuánto después del último partido la regla necesita mirar hacia adelante.
- Dentro de: 500 significa que sólo habrá coincidencia si el contenido coincide con la carga útil dentro de los 500 bytes.
Los parámetros within y distance se explican en la documentación de Suricata.
4. Defectos observados en la regla original en comparación con nuestro exploit
Como dice el refrán, "una imagen vale más que mil palabras", a continuación se muestra cómo se comporta la regla de detección en el exploit Rapid7:
Este fragmento de la norma:
El volcado anterior muestra fácilmente por qué la regla de detección nunca se activa: en nuestro ejemplo, nunca encontrará el otro patrón, ya que está situado al principio del archivo.
5. Una regla de detección M2 variante para este exploit no detectado
A la luz de los hallazgos anteriores, una nueva regla de detección M2, revisión 2, ha sido publicada el 29 de septiembre por el equipo de Amenazas Emergentes de Proofpoint como SID 2048146:
A continuación se muestra un resumen de lo que comprueba la regla de detección M2, utilizando la misma representación hexadecimal del mismo exploit de archivo tar que antes:
6. Resolución
A la luz de las evidentes deficiencias de la regla ET original de Proofpoint (SID 2046280), queda claro que confiar únicamente en reglas y normas fijas tiene sus límites en el panorama en constante evolución de la ciberseguridad. La eterna sabiduría del General MacArthur, "Las reglas están hechas para romperse", sirve como un duro recordatorio de que los actores maliciosos explotarán cualquier vulnerabilidad, incluidos los conjuntos de reglas rígidas.
A través de este análisis, hemos sido testigos de un excelente ejemplo de las limitaciones de este enfoque, a través de la manipulación de una estructura de archivo TAR que permitió que una carga útil se deslizara más allá de la detección inicial de ET para CVE-2023-2868. Este suceso subraya la urgencia de adoptar una estrategia de seguridad más adaptable y dinámica.
De cara al futuro, es imperativo abandonar la rigidez y adoptar un paradigma de seguridad más holístico y proactivo. En lugar de limitarnos a ponderar las probabilidades de que se produzca otra infracción de las normas, debemos esforzarnos activamente por mejorar nuestras medidas de ciberseguridad mediante la evolución constante de nuestros mecanismos de detección y defensa. Al reconocer las limitaciones de las reglas fijas, podemos prepararnos mejor para un futuro incierto en el que las ciberamenazas evolucionan continuamente. Al hacerlo, podemos reforzar nuestra postura de seguridad y protegernos mejor contra los actores maliciosos que buscan persistentemente eludir las reglas. Adoptar una estrategia que vaya más allá de la dependencia exclusiva de las tecnologías basadas en reglas no sólo se alinea con el enfoque multicapa de Defense-inDepth, sino que también invita al lector a adoptar las estrategias más eficaces en la actualidad, incluido el modelo de Zero Trust .
En aras de ofrecer una recomendación inmediatamente aplicable, ofrecemos la siguiente orientación:
Para las implantaciones de Suricata que utilizan el archivo emerging-all.rules y tienen una gestión automatizada de las actualizaciones del conjunto de reglas, la regla de detección revisada ya debería estar en su lugar, suponiendo que el actualizador se haya ejecutado después del 29/9/23. Para comprobar que el conjunto de reglas aplicado actualmente contiene la regla de detección revisada, busque "2048146" en los archivos locales del conjunto de reglas. Si el SID 2048146 no está presente en ninguno de los conjuntos de reglas aplicados actualmente, actualice los conjuntos de reglas a la última fuente disponible de Emerging Threats.
Calendario:
- 19/9/23: Presentación de los resultados a través del portal del ET. No he recibido ningún acuse de recibo.
- 21/9/23: Envío de un correo electrónico a support@emergingthreats.net para registrar el envío e informar al equipo de Amenazas Emergentes de la política de divulgación responsable de Google que se seguirá en este caso.
- 9/21/23: ET Security Researcher me respondió por correo electrónico y acordó publicar una versión M2 de la regla de detección como parte de su publicación diaria, hoy 7 PM ET.
- 21/9/23: Se ha observado que la regla de detección de la variante M2 recientemente publicada no dispara una alerta contra el exploit R7.
- 21/9/23: Se envió un correo electrónico a un investigador de ET Security sobre el fallo en la detección de la carga útil del exploit con la nueva regla de detección M2.
- 9/29/23: Una revisión 2 de la regla de la variante M2 liberada a las 7PM ET y detecta con éxito la carga útil del exploit R7.
Referencia:
Documentación sobre Suricata: https://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords
html#dentrohttps://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords.html#distance
Github POC explotar: https://github.com/cfielding-r7/poc-cve-2023-2868/blob/main/poc_cve_2023_2868.rb
Explicación del exploit: https://www.mandiant.com/resources/blog/barracuda-esg-exploited-globally
Regla ET: http://rules.emergingthreats.net/open/suricata-5.0/emerging-all.rules