<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 do 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 github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Como você reagiria se eu lhe dissesse que [GWT, um framework de aplicação web open-source bastante popular originalmente desenvolvido no Google](https://www.gwtproject.org/) continha uma vulnerabilidade de deserialização Java não autenticada que foi abertamente discutida em 2015 e 2020, mas ainda estava sem correção no final de 2023? E se eu também sugerisse que a vulnerabilidade estava em um nível tão baixo que garantir a segurança de aplicações web vulneráveis escritas usando este framework provavelmente exigiria mudanças arquitetônicas nessas aplicações ou no próprio framework?
Se você é como eu, sua reação inicial seria de incredulidade. Certamente uma vulnerabilidade que poderia expor os proprietários de aplicações a execução de código no lado do servidor por atacantes não autenticados teria sido corrigida em menos de oito anos após sua descoberta. Se nenhuma correção tivesse sido emitida, pelo menos os recursos vulneráveis do framework teriam sido marcados como obsoletos, e a documentação do framework forneceria sugestões para substituir o código vulnerável por alternativas atualizadas. No mínimo, os desenvolvedores do framework teriam atualizado os tutoriais "primeiros passos" e outras documentações para indicar o perigo inerente de usar os recursos vulneráveis em vez de destacar a funcionalidade.
Surpreendentemente, nenhuma dessas suposições é verdadeira. Oito anos depois, a vulnerabilidade ainda está sem correção, e as únicas indicações do perigo antes deste post no blog eram [uma issue no GitHub de 2020 com uma resposta estilo "WONTFIX"](https://github.com/gwtproject/gwt/issues/9709), [algumas discussões nos Grupos do Google de 2015 que nunca levaram à correção do problema subjacente](https://groups.google.com/g/google-web-toolkit/c/j36D9-11JF4/m/OZwNQgvSAgAJ), e [um post no blog de 2015 que sugere corretamente que o problema poderia ser resolvido assinando os dados serializados](https://gwtnews.blogspot.com/2015/11/re-java-deserialization-vulnerability\_55.html), exceto que tal funcionalidade nunca foi adicionada ao GWT. Há até [um post no blog de 2020 que afirma incorretamente que o GWT não é vulnerável](https://gwtnews.blogspot.com/2020/06/re-security-vulnerabilities-with-gwt\_52.html), porque supostamente nunca transmite objetos Java serializados pela rede.
Neste post no blog, explicarei a vulnerabilidade no GWT (originalmente "Google Web Toolkit", às vezes referido como "GWT Web Toolkit"), mostrarei como explorar uma aplicação web GWT vulnerável, como configurar uma aplicação web GWT intencionalmente vulnerável para testar, determinar se sua própria aplicação baseada em GWT é vulnerável e discutir possíveis mitigações.
GWT permite que desenvolvedores (entre outras coisas) escrevam aplicações web em Java que têm alguma lógica rodando no servidor (Tomcat, Jetty, etc.) e alguma nos navegadores dos usuários. O SDK do GWT gera qualquer código JavaScript do lado do cliente necessário quando o projeto Java é compilado. GWT inclui uma espécie de mini-JRE escrita em JavaScript para esse propósito. Geralmente, o GWT compila objetos Java personalizados tanto para o cliente quanto para o servidor, e esses objetos são trocados usando um formato de serialização de texto delimitado por pipe que ambos os lados podem analisar. Por exemplo, a seguinte solicitação inclui um array de objetos `String` e um objeto `CustomClass1`, e as propriedades que descrevem esses objetos são representadas como strings ou dígitos:
**FIGURA 1** - Exemplo de requisição GWT-RPC com dados de objeto legíveis por humanos
No entanto, [o GWT também possui um conceito chamado "classes aprimoradas"](https://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideSerializableTypes), que (em um nível alto) são objetos Java que atendem a certos critérios (consulte a documentação vinculada se desejar entender os detalhes). Essas classes aprimoradas são processadas apenas usando código do lado do servidor, mas são transmitidas para e do cliente como parte do estado da aplicação, apesar de serem opacas para o cliente. Você pode pensar nisso como sendo análogo ao ViewState em aplicações ASP.NET, exceto sem suporte para criptografia ou assinaturas criptográficas.
Quando as classes aprimoradas entram em cena, elas aparecem em requisições e respostas GWT codificadas usando uma variação não padrão do Base64. Por exemplo, o valor `rO0ABXcEAAAAAA==` na seguinte requisição:
Decodificar os dados revela o uso do formato de serialização de objetos Java (o cabeçalho `0xACED` é a pista, e faz com que a versão codificada sempre comece com `rO0`). No entanto, o uso do formato pelo GWT é ligeiramente diferente da serialização Java padrão. Tentar substituir o valor com a saída de [`ysoserial`](https://github.com/frohoff/ysoserial), por exemplo, fará com que o servidor retorne mensagens de erro em vez de deserializar o objeto. Por exemplo:
Isso pode levar um pentester a acreditar que o GWT estava realizando algum tipo de validação de dados antes de deserializar o(s) objeto(s), rejeitando classes inesperadas, mas essa suposição seria incorreta.
Piorando a situação, se o código de autenticação ou autorização de uma aplicação for manipulado dentro da aplicação GWT (em vez de um filtro separado aplicado no nível do servidor de aplicação, por exemplo), então quaisquer vulnerabilidades de deserialização são exploráveis por chamadores não autenticados ou não autorizados. Isso ocorre porque o GWT deserializa os dados da requisição antes de passá-los para a função correspondente do lado do servidor.
Se você já tem uma aplicação baseada em GWT ao vivo para testar, pode usar as etapas desta seção para tentar explorá-la. Se você não tem acesso a uma aplicação existente, a seção "Construindo um exemplo de aplicação vulnerável para testar", abaixo, irá guiá-lo rapidamente na implantação de uma para praticar.
Primeiro, você precisará de um payload de deserialização. Como mencionei anteriormente neste post, a serialização do GWT é baseada no formato padrão Java, mas usa um padrão específico que impedirá que a saída de ferramentas de exploração padrão funcione. Em vez de o fluxo conter diretamente um único objeto, ele começa com um inteiro indicando o número de campos no fluxo. Para cada campo, o fluxo contém uma string que representa o nome do campo e um objeto arbitrário para o valor do campo.
Não encontrei uma maneira fácil de adicionar as informações necessárias a um objeto, e `ysoserial` não parecia estar sendo ativamente mantido, então [criei um fork que adiciona os recursos necessários](https://github.com/BishopFox/ysoserial-bf) (e também incorpora algum código adicional que outros submeteram para inclusão no `ysoserial`). Ele pode gerar todos os payloads padrão do `ysoserial` (incluindo vários que não haviam sido mesclados na filial principal), mas adiciona uma opção `--gwt` para criar esses payloads formatados para uso em uma requisição GWT-RPC. A opção `--gwt` requer um parâmetro adicional, que é o nome do campo a ser incluído no fluxo de objetos. O nome específico do campo geralmente é irrelevante, mas algum valor precisa ser especificado para que o GWT reconheça o payload como válido. No exemplo abaixo, o campo será nomeado bishopfox:
GWT-RPC usa uma versão personalizada do Base64 onde o caractere + foi substituído por $, e o caractere / substituído por \_, então o próximo passo é codificar o payload.
**FIGURA 5** - Gerando e codificando payload URLDNS
Objetos serializados também podem ser codificados e decodificados em Python ao incluir a opção `altchars=b'$_'` ao chamar `base64.b64encode` ou `base64.b64decode`. Por exemplo:
Assim como qualquer outra suspeita de vulnerabilidade de desserialização Java, sugiro começar com o payload `ysoserial URLDNS` configurado para carregar uma URL baseada no nome do host atual do Burp Suite Collaborator.
Após gerar e codificar o payload, use uma ferramenta como o módulo Repeater do Burp Suite para enviar uma versão modificada da solicitação que contém o payload codificado em vez do valor original. Se bem-sucedido, é provável que você receba uma resposta indicando que o nome do campo era inválido:
7|0|10|http://127.0.0.1:8888/stockwatcher/|259823D3B8B1029302496D0C7E009509|com.google.gwt.sample.stockwatcher.client.CheckCustomClassService|checkCustomClass1|com.google.gwt.sample.stockwatcher.client.CustomClass1/1972642674|rO0ABXcEAAAAAXQACWJpc2hvcGZveHNyABFqYXZhLnV0aWwuSGFzaFNldLpEhZWWuLc0AwAAeHB3DAAAAAI…omitted for brevity…0AAEueHg=|com.google.gwt.sample.stockwatcher.client.CustomClass2/69504871|java.sql.Date/730999118|1|2|1|2|3|4|1|5|5|6|
Se você começou usando um payload `URLDNS` apontando para o nome do host do seu Collaborator, você deve ser capaz de validar que algo solicitou essa URL, ou pelo menos resolveu o nome DNS. Existem ambientes tão restritos que não permitem nem a resolução de nomes DNS públicos, mas são muito incomuns.
Como qualquer outra vulnerabilidade de deserialização Java, a exploração significativa requer uma cadeia de gadgets baseada em classes carregadas no servidor. [A documentação para nosso fork personalizado do `ysoserial` inclui uma maneira de gerar rapidamente payloads para todas as suas cadeias de gadgets de execução de comando de propósito geral](https://github.com/BishopFox/ysoserial-bf).
Como mencionei na seção "GWT e classes aprimoradas", acima, o GWT deserializa pedidos antes de executar qualquer código nas funções associadas ao GWT-RPC. Isso muitas vezes significa que uma função GWT-RPC vulnerável pode ser explorada sem credenciais, ou com credenciais de baixo privilégio, mesmo que a função GWT-RPC exija autenticação e autorização quando chamada normalmente. Portanto, se você confirmar que uma função é vulnerável, prossiga testando para ver se ela funciona sem autenticação. Se a função GWT-RPC normalmente requer credenciais de alto privilégio, tente enviar o payload de exploração usando dados de autenticação de uma conta de baixo privilégio, como se inscrever para um teste gratuito do produto que você está testando.
## Construindo um Exemplo de Aplicação Vulnerável para Testar
Quando comecei a pesquisar este tópico originalmente, não consegui encontrar nenhum projeto de código aberto que usasse o GWT de maneira vulnerável. O projeto de exemplo do GWT exigia muitas etapas manuais para criar, e o resultado não fazia uso do mecanismo de serialização vulnerável. Para facilitar a prática de exploração de aplicações baseadas em GWT, [criei uma versão do projeto de exemplo do GWT que não só usa serialização binária, mas também inclui arquivos JAR vulneráveis a várias cadeias de gadgets do `ysoserial`](https://github.com/BishopFox/VulnerableGWTApp).
Use as instruções de "início rápido" para implantar rapidamente uma aplicação web GWT vulnerável que pode ser explorada usando várias das cadeias de gadgets incluídas com a versão personalizada do `ysoserial` discutida acima.
## Minha Aplicação GWT é Vulnerável?
Se você ver classes Java codificadas em Base64 em qualquer tráfego para uma aplicação baseada em GWT, a aplicação é quase certamente vulnerável.
Também vale a pena verificar os arquivos de política de serialização GWT-RPC da aplicação para ver se algum deles contém o decorador `@ClientFields`. Cada arquivo de política contendo um ou mais instâncias do decorador `@ClientField` indica pelo menos um método GWT-RPC que deve ser vulnerável.
Os arquivos de política de serialização são gerados durante o processo de construção do GWT. Se você tiver acesso ao código do lado do servidor, procure por arquivos com a extensão `.gwt.rpc`:
Se o design da aplicação resultar em uma classe que o servidor precisa trocar usando serialização binária Java GWT-RPC, ela terá um `@ClientFields decorator`, conforme mostrado abaixo:
Se você estiver realizando um teste de conhecimento zero de uma aplicação web, precisará coletar os nomes fortes distintos do GWT-RPC usados pela aplicação e, em seguida, usar esses nomes fortes para acessar os arquivos de política. Neste exemplo de solicitação, o nome forte é `259823D3B8B1029302496D0C7E009509`:
Pode ser mais eficiente procurar no histórico do seu proxy interceptador por `strongName =`, o que deve fornecer uma lista dos arquivos JavaScript gerados pelo GWT que se referem aos nomes fortes, mesmo que suas ações dentro da aplicação web não tenham necessariamente gerado tráfego para os métodos vulneráveis. Por exemplo:
```
…omitted for brevity…
var $gwt_version = "2.10.0";
var $strongName = '259823D3B8B1029302496D0C7E009509';
…omitted for brevity…
```
**FIGURA 11** - Exemplo de referência de nome forte em um arquivo JavaScript de aplicação web GWT
Uma vez que você conhece o(s) nome(s) forte(s) para a aplicação, os arquivos de política devem estar dentro do mesmo diretório, nomeados usando o(s) nome(s) forte(s) com a extensão `.gwt.rpc`. Por exemplo:
**Requisição**
```
GET /stockwatcher/259823D3B8B1029302496D0C7E009509.gwt.rpc HTTP/1.1
Como mostrado acima, o arquivo de política para esse nome forte contém duas classes com o `@ClientFields decorator`.
Esta é uma ótima maneira de construir uma lista de verificação do tráfego para observar enquanto usa o aplicativo. Se você testou todos os recursos que conhece e ainda não viu um ou mais deles em uso, precisará ou investigar o código-fonte ou considerar a construção manual de pedidos para quaisquer métodos GWT-RPC restantes. O protocolo de serialização GWT-RPC é complicado, então este post não fornecerá instruções para a criação manual de pedidos, mas [Brian Slesinsky escreveu um bom guia sobre o protocolo em 2012](https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit) que você pode consultar se desejar seguir essa opção.
<summary><strong>Aprenda AWS hacking 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 github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
