Los SIEM suelen utilizarse en ambientes de alta seguridad o regulados, donde se requiere un monitoreo y análisis de logs periódico en busca de incidentes de seguridad. Ayudan a que una red esté más segura, sí… pero… nos preguntamos un poco más allá: ¿realmente los logs de los equipos de nuestra infraestructura están adecuadamente protegidos? Vamos a abordar en esta entrada unas pautas mínimas que se deben tener en cuenta para securizar un SIEM, poniendo como ejemplo y caso de uso una investigación particular sobre Splunk, uno de los SIEM más conocidos.

Hace un tiempo atrás, en uno de nuestros webinars de #11PathsTalks, @holesec y @DaPriMar nos hablaban sobre qué es un SIEM y sobre correlación avanzada. Analizaremos las distintas cuestiones que pueden influir de forma positiva o negativa en la seguridad de un SIEM, pero en este caso nos basaremos en Splunk. Como cualquier SIEM, permite buscar, monitorear y analizar información generada por diferentes equipos de la infraestructura, en su caso por medio de una interfaz web. Este software captura, indexa y correlaciona información en tiempo real en un repositorio que permite generar gráficos, reportes, alertas y diferentes visualizaciones. Según su web, tiene más de 3700 clientes, incluyendo más de la mitad de las Fortune 100. Las versiones de Splunk más utilizadas son tres: Splunk Free, Splunk Enterprise y Splunk Cloud. También hay una versión light que se utiliza principalmente para AWS pero que no analizaremos en esta oportunidad.

Si bien es posible analizar un SIEM desde muchos posibles vectores de ataque, para esta primera aproximación en particular nos gustaría centrarnos en 4 puntos en concreto:

1. Métodos de autenticación
2. Usuarios de instalación
3. Administración e instalación de aplicaciones
4. Exposición a Internet

En base a esto y trabajando en el análisis sobre las diferentes versiones, nos hemos encontrado con algunas curiosidades que mencionamos a continuación, y que podrían servir como “molde” para el análisis de cualquier sistema de este tipo. 

Splunk Free no posee ningún tipo de autenticación, cualquier usuario que conozca la dirección IP y el puerto correspondiente puede iniciar sesión en Splunk con privilegios administrativos. En la misma web del fabricante indica claramente que esta versión no es adecuada para ambientes corporativos.

Splunk Enterprise posee varias opciones de métodos de autenticación a elegir (Splunk, LDAP, Scripted, SAML, ProxySS) que se configuran en el archivo

$SPLUNK_HOME/etc/system/local/authentication.conf.

La autenticación propia de Splunk (método de autenticación seleccionado por defecto) tampoco es adecuada para ambientes corporativos ya que el único parámetro de contraseña que permite configurar es la longitud de contraseña, y por defecto se encuentra configurada con valor 0. Splunk no permite configurar bloqueo por intentos fallidos de acceso, lo cual lo hace susceptible a ataques de fuerza bruta, ni tampoco reglas que garanticen la complejidad de contraseñas. El usuario por defecto de la versión Enterprise es admin y su correspondiente contraseña “changeme”. 

Splunk Cloud viene en dos versiones diferentes, Managed Splunk Cloud y Self-Service Splunk Cloud. Para diferenciar uno de otro se puede analizar la URL. Las URLs de los Self-Service son del estilo: https://prd-*.cloud.splunk.com y las URLs de los Managed son del estilo: https://*.splunkcloud.com. En los Splunk Self-Service los usuarios se autentican con su cuenta de splunk.com que tiene restricciones de longitud y complejidad de contraseña. En los Splunk Managed los usuarios pueden autenticarse por medio de SAML, aunque suele utilizarse la autenticación propia de Splunk ya que viene por defecto. Si bien trae configurada una longitud máxima de 8 caracteres, es el único parámetro que permite configurar. 

Es importante tener en cuenta que al configurar Splunk para utilizar otro método de autenticación que no sea la autenticación propia (como por ejemplo LDAP), todas las cuentas de usuario locales con autenticación propia de Splunk siguen activas (incluyendo la cuenta admin). Para eliminar todas las cuentas locales se debe dejar en blanco el archivo $SPLUNK_HOME/etc/passwd. Este archivo no debe ser eliminado, ya que , en caso contrario, se vuelve al usuario por defecto admin con contraseña “changeme”.

Tanto Splunk Free como Enterprise pueden ser instalados con privilegios de root en plataformas Linux/Unix, con privilegios administrativos en plataformas Windows o con usuarios con menores privilegios en ambas plataformas, configurando adecuadamente los permisos necesarios en el sistema de ficheros. Esta última opción es la más recomendada en ambientes corporativos ya que reduce la superficie de ataques en caso de que Splunk sea comprometido. La documentación de instalación de Splunk indica cómo realizar la instalación con usuarios con privilegios restringidos en las diferentes plataformas. También los universal forwarders o clientes de Splunk que se instalan en los equipos de los cuales se van a recolectar logs, deben ser instalados con usuarios de privilegios limitados, puesto que podrían ser usados para ejecutar comandos o scripts enviados desde el servidor Splunk utilizándolo como deployment server.

Splunk Free y Enterprise pueden administrarse de diversos modos: desde la consola web, el Splunk CLI, modificando los archivos de configuración correspondientes en el sistema operativo o utilizando la REST API. Tanto Splunk Free como Enterprise permiten la instalación de aplicaciones “custom” o creadas por el usuario (por ejemplo en Python) además de las presentes en Splunkbase, que es el repositorio oficial de aplicaciones y add-ons de Splunk. La instalación de aplicaciones creadas por el usuario presenta riesgos, ya que una vez comprometido el servidor Splunk se podría instalar cualquier tipo de aplicación maliciosa que, por ejemplo, permita administrar el servidor por medio de un web shell o un reverse shell (siempre teniendo en cuenta los permisos de la cuenta de usuario utilizada para la instalación de Splunk), o se envíe a los universal forwarders para comprometer a los equipos clientes de Splunk.

En Splunk Cloud no se tiene acceso para administrar Splunk desde el CLI ni al sistema de ficheros para modificar los archivos de configuración. Se pude utilizar Splunk Web y la REST API para realizar algunas tareas administrativas. Tampoco se puede instalar cualquier aplicación, sino únicamente las aprobadas por Splunk para ser usadas en un ambiente cloud. Las aplicaciones antes de ser aprobadas pasan por una validación por medio de la herramienta AppInspect que determina si cumplen con los requisitos de seguridad definidos, como por ejemplo: no requerir elevación de privilegios con sudo, su, groupadd o useradd, no usar reverse shells, no manipular archivos fuera del directorio de la aplicación, no manipular procesos fuera del control de la aplicación ni el sistema operativo, ni reiniciar el servidor.

Búsqueda en Shodan de servidores Splunk

 

En el caso de Splunk Free y Enterprise, no es recomendable exponer la interfaz web (puerto por defecto 8080) ni la interfaz de management (puerto 8089) a Internet. Sin embargo, lamentablemente, es una práctica bastante común como se puede apreciar en el buscador Shodan buscando por http.component:”splunk” donde aparecen casi 8000 equipos. También es posible identificar de qué tipo de Splunk se trata analizando el código fuente de la página de login del mismo Splunk:

[dirección ip=”” n=””]:[puerto]/en-US/account/login?return_to=%2Fen-US%2F[/puerto][/dirección]

• “isFree”:true nos indica que se trata de un Splunk Versión Free (sin autenticación)
• “instance_type”:”cloud” nos indica de que se trata de Splunk versión Cloud
• “instance_type”:”download” y “product_type”:”enterprise” nos indican que se trata de un Splunk Versión Enterprise.
• “hasLoggedIn”:false nos indica que ningún usuario inició sesión en el equipo, lo cual es un claro indicador de que ese Splunk aún mantiene la contraseña por defecto ya que nadie pudo iniciar sesión para cambiarla.

Como dato curioso, para el caso particular del análisis de Splunk, nos hemos encontrado con que al momento de instalación, se crea un archivo con la clave a utilizar para cifrar información de autenticación en archivos de configuración y para cifrar las claves utilizadas por las diferentes aplicaciones. Esta clave se encuentra en el archivo

$SPLUNK_HOME/etc/auth/splunk.secret

y es única por cada instalación de Splunk. Las aplicaciones que se bajan de Splunkbase (como por ejemplo el addon que permite la integración con Active Directory, o los que permiten integrar Splunk con dispositivos de comunicaciones) necesitan almacenar credenciales en los archivos de configuración de la propia aplicación. Splunk cifra esas contraseñas por medio de splunk.secret. El riesgo en este caso, es que una vez comprometido el servidor Splunk, se puede utilizar la misma API de Splunk para descifrar la contraseña de estas aplicaciones con un simple script de Python y así poder comprometer otros componentes de la infraestructura.

Como en muchos otros ámbitos, se pueden proteger los equipos de la infraestructura, y el servidor donde se encuentra instalado el SIEM eligiendo adecuadamente la versión a utilizar y configurándolo de manera segura (siguiendo las mejores prácticas del fabricante). Lógicamente, ante una infraestructura tan delicada, cualquier error podría exponer información muy valiosa para los atacantes, e incluso algunas veces podría dar a conocer claves de las aplicaciones internas de la organización. En este ejemplo nos hemos centrado en Splunk como “caso práctico” pero, en general para realizar el hardening de un SIEM, deberían considerarse los siguientes aspectos:

• Utilizar un usuario no privilegiado (ni root ni administrador) para la instalación
• Modificar las contraseñas por defecto apenas instalado
• Seleccionar un método de autenticación robusto y asegurarse que no existan formas fáciles de eludirlo (como vimos en el caso de Splunk que requería borrar el archivo $SPLUNK_HOME/etc/passwd)
• Utilizar certificados en la interfaz web, preferentemente no autogenerados
• Deshabilitar el componente web en caso de no utilizarlo
• No exponer los puertos del SIEM a redes no confiables
• Actualizar el SIEM regularmente, e incorporarlo en el alcance de las auditorias o test de intrusión que se realicen periódicamente
• Activar la auditoria propia del SIEM y monitorear los eventos resultantes

Para cerrar este post, y dado que hemos hablado de Splunk durante nuestro análisis, recopilamos a continuación los enlaces propios del fabricante con las mejores prácticas para proteger estos equipos:

• Best practices in protecting splunk enterprise
• Community: Deploy Hardened Splunk
• Documentation Splunk latest security hardeningstandards