PHP - Deserialization + Autoload Classes
PreviousBasic Java Deserialization (ObjectInputStream, readObject)NextCommonsCollection1 Payload - Java Transformers to Rutime exec() and Thread Sleep
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Primeiro, você deve verificar o que são Classes Autoloading.
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.
Passos:
Você encontrou uma deserialização e não há nenhum gadget no código atual do app
Você pode abusar de uma função spl_autoload_register como a seguinte para carregar qualquer arquivo local com extensão .php
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.
Um exemplo de gadget será: O:10:"tmp_passwd":0:{}
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, eu enviei um array serializado com ambos os objetos como:
Você pode ver primeiro o carregador sendo carregado e depois o payload
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:
Resumo do payload
Carregar o autoload do composer de uma webapp diferente no mesmo contêiner
Carregar um gadget phpggc para abusar de uma biblioteca da outra webapp (a webapp inicial vulnerável à deserializaçã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 da webapp não pode escrever em nenhuma pasta de nenhuma webapp)
A parte final do nosso payload irá carregar o arquivo php gerado que executará comandos
Eu precisei chamar essa deserializaçã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:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
