En una vida anterior antes de unirme a Huntress, fui administrador y arquitecto de Splunk. Con el tiempo, noté algunas funciones y comportamientos de Splunk que pensé que podrían ser explotables, y quise profundizar en esa sospecha para ver si tenía razón. Durante el último año, estuve investigando la viabilidad de usar Splunk como servidor de comando y control (C2) "living off the land".
Dato curioso: un ataque Living off the Land (LotL) describe un ciberataque en el que los intrusos usan software y funciones legítimas disponibles en el sistema para realizar acciones maliciosas en él. Los operadores de ciberataques LotL buscan en los sistemas objetivo herramientas, como componentes del sistema operativo o software instalado, que puedan usar para lograr sus objetivos. Los ataques LotL a menudo se clasifican como sin archivos (fileless) porque no dejan ningún rastro. (Kaspersky)
Lo que descubrí es que no solo es posible, sino que es aterrador en cuanto a las capacidades. Quiero informar a la comunidad en general, ya que son problemas que se pueden corregir con cambios arquitectónicos sencillos.
Tus herramientas de seguridad tienen la misma probabilidad de ser atacadas que cualquier otra cosa. Las empresas deberían prestar tanta atención a las actividades que ocurren alrededor de sus herramientas de TI y seguridad como a sus sistemas críticos. Traitorware es un término divertido que encontré recientemente para describir la técnica de usar herramientas establecidas para vivir del entorno.
¿Sabías que? Traitorware, según lo definen Alberto Rodriguez y Erik Hunstad, es:
1. Software que traiciona la confianza depositada en él para realizar acciones maliciosas
2. Software confiable con intención original benigna usado para acciones maliciosas
Usando las funciones principales de Splunk (al ser una herramienta de ingesta de logs), se puede abusar fácilmente de él para robar datos de un sistema.
***AVISO IMPORTANTE***
Esto no es una vulnerabilidad, un error ni un nuevo exploit dentro de Splunk. Son configuraciones que Splunk admite, e incluso brinda en su documentación. Esto es solo una demostración para mostrar que los actores de amenazas pueden abusar de las herramientas de TI y seguridad y usar su funcionalidad principal con fines maliciosos.
Profundizando
El Universal Forwarder (UF) de Splunk incluye ejecución remota de código (RCE) como una función; no necesité usar eso para esta prueba de concepto (POC). Usando configuraciones personalizadas de Splunk, pude definir una nueva "salida" para que se enviaran los logs, que era un servidor rsyslog malicioso que yo controlaba. Splunk usa archivos de configuración en cascada para funcionar, y cada "app" dentro de Splunk es un paquete de configuración que anulará las mismas configuraciones especificadas en el directorio del sistema (la configuración "raíz"). Por ejemplo,
system\outputs.conf
192.168.0.255 es el servidor Splunk real que recibe los logs de este sistema.
<app directory>\local\outputs.conf
Ambos archivos de configuración son válidos y se cargarán en memoria. La configuración de la APP tendría prioridad si la línea [tcpout:<NAME>] fuera idéntica entre ambos archivos.
Esta es la base que usé para abusar de la lógica de Splunk. Dado que podía agregar configuraciones al archivo outputs.conf cargado en memoria, todo lo que tenía que hacer era asegurarme de crear nuevas configuraciones en lugar de sobrescribir las existentes. En un entorno empresarial de Splunk, los cambios en configuraciones existentes probablemente se notarían rápido, ya que tendrían un impacto inmediato en los flujos de logs existentes. Sin embargo, las configuraciones adicionales posteriores pueden ser difíciles de rastrear.
Entonces, creé una nueva app de Splunk para implementar con las siguientes dos configuraciones:
outputs.conf
Lo anterior define la salida para los logs; en este caso, es un servidor Ubuntu que ejecuta rsyslog en el puerto 514. El atributo sendCookedData=false desactiva el envío de los datos "cocinados" de Splunk, que son metadatos e información adicional que usa Splunk. Esto debe desactivarse cuando se usa un receptor externo. De lo contrario, terminarás con resultados que se ven así:
inputs.conf
Este archivo le indica al UF de Splunk qué directorio monitorear y fuerza el enrutamiento de logs para usar la ruta "syslog" definida en outputs.conf, pero solo para este directorio. El resto de los logs en el sistema se enviarán a Splunk como se esperaba, lo que nos permite monitorear y absorber estos archivos prácticamente sin ser detectados. En general, Splunk puede ingerir cualquier archivo guardado en disco usando este método. Para nuestro caso de uso, solo se monitorea un único archivo txt.
contenido de secretpassword.txt:
Después de que estos paquetes de configuración se envían al endpoint, ya sea colocándolos manualmente en la carpeta SplunkUniversalForwarder o usando un Splunk Deployment Server, el Splunk Universal Forwarder comenzará a leer y enviar logs según los archivos inputs.conf y outputs.conf que encuentre definidos bajo <Splunk Install>\etc\*. Los archivos creados para esta prueba de concepto están bajo <Splunk Install>\etc\apps\MaliciousAppName\local
Y unos minutos después, en el servidor rsyslog, escondidos entre el ruido de los logs internos de Splunk UF, tenemos nuestros datos exfiltrados:
Remediación
Este ataque se puede realizar de forma local en un endpoint comprometido o de forma remota desde un servidor de implementación comprometido.
Para Splunk:
- Divide los roles de Splunk entre distintos dispositivos y realiza segmentación de redes según sea necesario
- Usa TLS para la comunicación entre instancias de Splunk si lo deseas, especialmente recomendado si alguna parte de la infraestructura de Splunk está expuesta a internet
- Documentación de Splunk para configurar TLS
- Usa una contraseña de administrador generada aleatoriamente, o deshabilita la cuenta de administrador predeterminada
- Limita el tráfico saliente permitido por Splunk, por ejemplo limitando el tráfico a puertos exclusivos de Splunk o deshabilitando el acceso a internet
- Evita instalar el Splunk UF en endpoints de escritorio
- Si tu implementación de Splunk requiere instalar el UF en endpoints de escritorio, asegúrate de contar con otros controles compensatorios para proteger al agente de manipulaciones. El Splunk UF se ejecuta como NT Authority\System de forma predeterminada en Windows; asegurarte de que los usuarios no sean administradores limita significativamente las posibilidades de manipulación.
- Usa la arquitectura de referencia de Splunk como base para una implementación segura
Recomendaciones generales para herramientas de TI / Seguridad:
- Monitorea los logs internos de las herramientas de TI / Seguridad en busca de comportamiento sospechoso
- Segmentación de redes de estas herramientas
- Limita el tráfico saliente solo a los puertos y protocolos necesarios
- Usa una estrategia de defensa en capas tanto para métodos de detección basados en red como en endpoints.
