Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe 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.
Estamos em uma situação onde encontramos uma **deserialização PHP em uma webapp** sem **nenhuma** biblioteca vulnerável a gadgets dentro de **`phpggc`**. No entanto, no mesmo contêiner havia uma **webapp composer diferente com bibliotecas vulneráveis**. Portanto, o objetivo era **carregar o carregador do composer da outra webapp** e abusar dele para **carregar um gadget que irá explorar essa biblioteca com um gadget** da webapp vulnerável à deserialização.
* Para isso, você usa uma deserialização onde o nome da classe vai estar dentro de **`$name`**. Você **não pode usar "/" ou "."** em um nome de classe em um objeto serializado, mas o **código** está **substituindo** os **sinais de sublinhado** ("\_") **por barras** ("/"). Assim, um nome de classe como `tmp_passwd` será transformado em `/tmp/passwd.php` e o código tentará carregá-lo.\
Se você tiver um **upload de arquivo** e puder fazer upload de um arquivo com **extensão `.php`**, você pode **abusar dessa funcionalidade diretamente** e obter RCE.
No meu caso, eu não tinha nada assim, mas havia dentro do **mesmo contêiner** outra página da web do composer com uma **biblioteca vulnerável a um gadget `phpggc`**.
* Para carregar essa outra biblioteca, primeiro você precisa **carregar o carregador do composer daquela outra aplicação web** (porque o da aplicação atual não acessará as bibliotecas da outra). **Sabendo o caminho da aplicação**, você pode conseguir isso muito facilmente com: **`O:28:"www_frontend_vendor_autoload":0:{}`** (No meu caso, o carregador do composer estava em `/www/frontend/vendor/autoload.php`)
* Agora, você pode **carregar** o **carregador do composer da outra app**, então é hora de **`gerar o payload phpgcc`** para usar. No meu caso, eu usei **`Guzzle/FW1`**, que me permitiu **escrever qualquer arquivo dentro do sistema de arquivos**.
* NOTA: O **gadget gerado não estava funcionando**, para que funcionasse eu **modifiquei** aquele payload **`chain.php`** do phpggc e defini **todos os atributos** das classes **de privado para público**. Caso contrário, após deserializar a string, os atributos dos objetos criados não tinham valores.
* Agora temos a maneira de **carregar o carregador do composer da outra app** e ter um **payload phpggc que funciona**, mas precisamos **fazer isso na MESMA REQUISIÇÃO para que o carregador seja carregado quando o gadget for usado**. Para isso, enviei um array serializado com ambos os objetos como:
* Agora, podemos **criar e escrever um arquivo**, no entanto, o usuário **não pôde escrever em nenhuma pasta dentro do servidor web**. Então, como você pode ver na carga útil, o PHP chamando **`system`** com algum **base64** é criado em **`/tmp/a.php`**. Em seguida, podemos **reutilizar o primeiro tipo de carga útil** que usamos como LFI para carregar o carregador do composer da outra webapp **para carregar o arquivo gerado `/tmp/a.php`**. Basta adicioná-lo ao gadget de desserialização: 
* **Carregar o autoload do composer** de um webapp diferente no mesmo contêiner
* **Carregar um gadget phpggc** para abusar de uma biblioteca do outro webapp (o webapp inicial vulnerável à desserialização não tinha nenhum gadget em suas bibliotecas)
* O gadget irá **criar um arquivo com um payload PHP** nele em /tmp/a.php com comandos maliciosos (o usuário do webapp não pode escrever em nenhuma pasta de nenhum webapp)
* A parte final do nosso payload irá **carregar o arquivo php gerado** que executará comandos
Eu precisei **chamar essa desserialização duas vezes**. Nos meus testes, na primeira vez o arquivo `/tmp/a.php` foi criado, mas não carregado, e na segunda vez foi carregado corretamente.
Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.