**Serialização** é o processo de transformar um objeto em um formato de dados que pode ser restaurado posteriormente. As pessoas frequentemente serializam objetos para salvá-los em armazenamento ou para enviar como parte de comunicações.
**Desserialização** é o processo inverso, pegando dados estruturados de algum formato e reconstruindo-o em um objeto. Atualmente, o formato de dados mais popular para serializar dados é o JSON. Antes disso, era o XML.
Em muitas ocasiões, você pode encontrar algum código no lado do servidor que desserializa algum objeto fornecido pelo usuário. Nesse caso, você pode enviar uma carga maliciosa para fazer com que o lado do servidor se comporte de maneira inesperada.
**Você deve ler:** [**https://cheatsheetseries.owasp.org/cheatsheets/Deserialization\_Cheat\_Sheet.html**](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization\_Cheat\_Sheet.html) **para aprender como atacar.**
Se você olhar para os resultados, poderá ver que as funções **`__wakeup`** e **`__destruct`** são chamadas quando o objeto é desserializado. Note que em vários tutoriais você encontrará que a função **`__toString`** é chamada ao tentar imprimir algum atributo, mas aparentemente isso **não está mais acontecendo**.
O método **`__unserialize(array $data)`** é chamado **em vez de `__wakeup()`** se ele for implementado na classe. Ele permite desserializar o objeto fornecendo os dados serializados como um array. Você pode usar este método para desserializar propriedades e realizar quaisquer tarefas necessárias na desserialização.
Você pode ler um exemplo **PHP explicado aqui**: [https://www.notsosecure.com/remote-code-execution-via-php-unserialize/](https://www.notsosecure.com/remote-code-execution-via-php-unserialize/), aqui [https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf](https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf) ou aqui [https://securitycafe.ro/2015/01/05/understanding-php-object-injection/](https://securitycafe.ro/2015/01/05/understanding-php-object-injection/)
[**PHPGCC**](https://github.com/ambionics/phpggc) pode ajudá-lo a gerar payloads para abusar de deserializações em PHP.\
Observe que em vários casos você **não será capaz de encontrar uma maneira de abusar de uma deserialização no código-fonte** da aplicação, mas você pode ser capaz de **abusar do código de extensões PHP externas.**\
Então, se possível, verifique o `phpinfo()` do servidor e **pesquise na internet** (e até mesmo nos **gadgets** do **PHPGCC**) alguns possíveis gadgets que você poderia abusar.
Se você encontrou um LFI que está apenas lendo o arquivo e não executando o código php dentro dele, por exemplo, usando funções como _**file\_get\_contents(), fopen(), file() ou file\_exists(), md5\_file(), filemtime() ou filesize()**_**. Você pode tentar abusar de uma **deserialização** que ocorre quando **lê** um **arquivo** usando o protocolo **phar**.\
A seguinte página apresenta a técnica de **abusar da desserialização insegura em bibliotecas python yamls** e termina com uma ferramenta que pode ser usada para gerar carga útil de desserialização RCE para **Pickle, PyYAML, jsonpickle e ruamel.yaml**:
JS **não tem funções "mágicas"** como PHP ou Python que serão executadas apenas para criar um objeto. Mas tem algumas **funções** que são **frequentemente usadas mesmo sem serem chamadas diretamente** como **`toString`**, **`valueOf`**, **`toJSON`**.\
Se abusar de uma desserialização, você pode **comprometer essas funções para executar outro código** (potencialmente abusando de poluições de protótipos) e poderia executar código arbitrário quando elas são chamadas.
Outra **maneira "mágica" de chamar uma função** sem chamá-la diretamente é **comprometer um objeto que é retornado por uma função assíncrona** (promessa). Porque, se você **transformar** esse **objeto de retorno** em outra **promessa** com uma **propriedade** chamada **"then" do tipo função**, ela será **executada** apenas porque é retornada por outra promessa. _Siga_ [_**este link**_](https://blog.huli.tw/2022/07/11/en/googlectf-2022-horkos-writeup/) _para mais informações._
Como você pode ver no último trecho de código, **se a flag for encontrada**, `eval` é usado para desserializar a função, então basicamente **a entrada do usuário está sendo usada dentro da função `eval`**.
No entanto, **apenas serializar** uma função **não a executará** já que seria necessário que alguma parte do código esteja **chamando `y.rce`** em nosso exemplo e isso é altamente **improvável**.\
De qualquer forma, você poderia apenas **modificar o objeto serializado****adicionando alguns parênteses** para executar automaticamente a função serializada quando o objeto for desserializado.\
No próximo trecho de código, **observe o último parêntese** e como a função `unserialize` executará automaticamente o código:
Como foi indicado anteriormente, esta biblioteca irá obter o código após `_$$ND_FUNC$$_` e irá **executá-lo** usando `eval`. Portanto, para **autoexecutar o código**, você pode **excluir a parte de criação da função** e o último parêntese e **apenas executar um JS em uma linha**, como no exemplo a seguir:
Você pode [**encontrar aqui**](https://opsecx.com/index.php/2017/02/08/exploiting-node-js-deserialization-bug-for-remote-code-execution/) **mais informações** sobre como explorar essa vulnerabilidade.
A diferença interessante aqui é que os **objetos padrão integrados não são acessíveis**, porque estão fora do escopo. Isso significa que podemos executar nosso código, mas não podemos chamar os métodos dos objetos integrados. Então, se usarmos `console.log()` ou `require(something)`, o Node retorna uma exceção como `"ReferenceError: console is not defined"`.
No entanto, podemos facilmente recuperar o acesso a tudo porque ainda temos acesso ao contexto global usando algo como `this.constructor.constructor("console.log(1111)")();`:
O pacote **não inclui nenhuma funcionalidade de desserialização** e requer que você a implemente por conta própria. O exemplo deles usa `eval` diretamente. Este é o exemplo oficial de desserialização:
O principal problema com objetos desserializados em Java é que **callbacks de desserialização foram invocados durante a desserialização**. Isso torna possível para um **atacante****aproveitar esses callbacks** e preparar uma carga útil que abusa dos callbacks para **realizar ações maliciosas**.
Procure dentro do código por classes e funções de serialização. Por exemplo, procure por classes que implementam `Serializable`, o uso de `java.io.ObjectInputStream` ou funções `readObject` ou `readUnshare`.
* Cabeçalho `Content-type` de uma resposta HTTP definido como `application/x-java-serialized-object`
*`1F 8B 08 00` Hex previamente comprimido
*`H4sIA` Base64 previamente comprimido
* Arquivos da web com extensão `.faces` e parâmetro `faces.ViewState`. Se você encontrar isso em um aplicativo da web, dê uma olhada no [**post sobre desserialização Java JSF VewState**](java-jsf-viewstate-.faces-deserialization.md).
Se você quer **aprender sobre como funciona uma exploração de deserialização Java**, você deve dar uma olhada em [**Deserialização Java Básica**](basic-java-deserialization-objectinputstream-readobject.md), [**Deserialização Java DNS**](java-dns-deserialization-and-gadgetprobe.md) e [**Carga Útil do CommonsCollection1**](java-transformers-to-rutime-exec-payload.md).
Você pode tentar **verificar todas as bibliotecas** conhecidas por serem vulneráveis e que o [**Ysoserial**](https://github.com/frohoff/ysoserial) pode fornecer uma exploração. Ou você pode verificar as bibliotecas indicadas em [Java-Deserialization-Cheat-Sheet](https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet#genson-json).\
Você também pode usar o [**gadgetinspector**](https://github.com/JackOfMostTrades/gadgetinspector) para procurar possíveis cadeias de gadgets que possam ser exploradas.\
Ao executar o **gadgetinspector** (depois de construí-lo), não se preocupe com as toneladas de avisos/erros que ele está passando e deixe-o terminar. Ele escreverá todas as descobertas em _gadgetinspector/gadget-results/gadget-chains-year-month-day-hore-min.txt_. Por favor, note que o **gadgetinspector não criará uma exploração e pode indicar falsos positivos**.
Usando a extensão do Burp [**gadgetprobe**](java-dns-deserialization-and-gadgetprobe.md), você pode identificar **quais bibliotecas estão disponíveis** (e até mesmo as versões). Com essas informações, pode ser **mais fácil escolher um payload** para explorar a vulnerabilidade.\
[**Leia mais sobre o GadgetProbe aqui**](java-dns-deserialization-and-gadgetprobe.md#gadgetprobe)**.**\
O GadgetProbe é focado em desserializações de \*\* `ObjectInputStream` \*\*.\*\*
Usando a extensão do Burp [**Java Deserialization Scanner**](java-dns-deserialization-and-gadgetprobe.md#java-deserialization-scanner), você pode **identificar bibliotecas vulneráveis** exploráveis com o ysoserial e **explorá-las**.\
[**Leia mais sobre o Java Deserialization Scanner aqui.**](java-dns-deserialization-and-gadgetprobe.md#java-deserialization-scanner)\
O Java Deserialization Scanner é focado em desserializações de **`ObjectInputStream`**.
Você também pode usar o [**Freddy**](https://github.com/nccgroup/freddy) para **detectar vulnerabilidades de desserialização** no **Burp**. Este plugin detectará vulnerabilidades relacionadas não apenas ao `ObjectInputStream`, mas também a bibliotecas de desserialização de **Json** e **Yml**. No modo ativo, ele tentará confirmá-las usando payloads de sleep ou DNS.\
[**Você pode encontrar mais informações sobre o Freddy aqui.**](https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2018/june/finding-deserialisation-issues-has-never-been-easier-freddy-the-serialisation-killer/)
Não se trata apenas de verificar se alguma biblioteca vulnerável é usada pelo servidor. Às vezes, você pode ser capaz de **alterar os dados dentro do objeto serializado e contornar algumas verificações** (talvez conceder privilégios de administrador dentro de um aplicativo da web).\
Se você encontrar um objeto serializado Java sendo enviado para um aplicativo da web, **você pode usar o** [**SerializationDumper**](https://github.com/NickstaDB/SerializationDumper) **para imprimir em um formato mais legível para humanos o objeto de serialização que está sendo enviado**. Saber quais dados você está enviando tornaria mais fácil modificá-los e contornar algumas verificações.
A ferramenta mais conhecida para explorar desserializações Java é o [**ysoserial**](https://github.com/frohoff/ysoserial) ([**baixe aqui**](https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar)). Você também pode considerar o uso do [**ysoseral-modified**](https://github.com/pimps/ysoserial-modified), que permitirá que você use comandos complexos (com pipes, por exemplo).\
Observe que esta ferramenta está **centrada** em explorar **`ObjectInputStream`**.\
Eu **começaria usando o payload "URLDNS"** antes de um payload RCE para testar se a injeção é possível. De qualquer forma, observe que talvez o payload "URLDNS" não esteja funcionando, mas outro payload RCE esteja.
Ao criar um payload para **java.lang.Runtime.exec()**, você **não pode usar caracteres especiais** como ">" ou "|" para redirecionar a saída de uma execução, "$()" para executar comandos ou até mesmo **passar argumentos** para um comando separados por **espaços** (você pode fazer `echo -n "hello world"`, mas não pode fazer `python2 -c 'print "Hello world"'`). Para codificar corretamente o payload, você pode [usar esta página da web](http://www.jackson-t.ca/runtime-exec-payloads.html).
Sinta-se à vontade para usar o próximo script para criar **todos os possíveis payloads de execução de código** para Windows e Linux e, em seguida, testá-los na página da web vulnerável:
Você pode **usar** [**https://github.com/pwntester/SerialKillerBypassGadgetCollection**](https://github.com/pwntester/SerialKillerBypassGadgetCollection) **junto com o ysoserial para criar mais exploits**. Mais informações sobre essa ferramenta nos **slides da apresentação** onde a ferramenta foi apresentada: [https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next\_slideshow=1](https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next\_slideshow=1)
[**marshalsec** ](https://github.com/mbechler/marshalsec)pode ser usado para gerar payloads para explorar diferentes bibliotecas de serialização **Json** e **Yml** em Java.\
Para compilar o projeto, eu precisei **adicionar** essas **dependências** ao `pom.xml`:
Leia mais sobre esta biblioteca Java JSON: [https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html](https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html)
* Se você quiser testar alguns payloads ysoserial, você pode **executar este aplicativo da web**: [https://github.com/hvqzao/java-deserialize-webapp](https://github.com/hvqzao/java-deserialize-webapp)
Alguns dos objetos de sua aplicação podem ser forçados a implementar `Serializable` devido à sua hierarquia. Para garantir que seus objetos de aplicação não possam ser desserializados, um método `readObject()` deve ser declarado (com um modificador `final`) que sempre lança uma exceção:
A classe `java.io.ObjectInputStream` é usada para desserializar objetos. É possível fortalecer seu comportamento criando uma subclasse. Essa é a melhor solução se:
A ideia geral é substituir [`ObjectInputStream.html#resolveClass()`](https://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass\(java.io.ObjectStreamClass\)) para restringir quais classes são permitidas para desserialização.
Como essa chamada acontece antes de um `readObject()` ser chamado, você pode ter certeza de que nenhuma atividade de desserialização ocorrerá, a menos que o tipo seja um que você deseja permitir.
Um exemplo simples disso é mostrado aqui, onde a classe `LookAheadObjectInputStream` é garantida de não desserializar nenhum outro tipo além da classe `Bicycle`:
Se você não possui o código ou não pode esperar por uma correção, usar um agente para tecer fortalecimento em `java.io.ObjectInputStream` é a melhor solução.\
Usando essa abordagem, você só pode colocar em uma lista negra tipos maliciosos conhecidos e não colocá-los em uma lista branca, já que você não sabe quais objetos estão sendo serializados.
* Palestra sobre deserialização e ysoserial: [http://frohoff.github.io/appseccali-marshalling-pickles/](http://frohoff.github.io/appseccali-marshalling-pickles/)
* Palestra sobre gadgetinspector: [https://www.youtube.com/watch?v=wPbW6zQ52w8](https://www.youtube.com/watch?v=wPbW6zQ52w8) e slides: [https://i.blackhat.com/us-18/Thu-August-9/us-18-Haken-Automated-Discovery-of-Deserialization-Gadget-Chains.pdf](https://i.blackhat.com/us-18/Thu-August-9/us-18-Haken-Automated-Discovery-of-Deserialization-Gadget-Chains.pdf)
* Artigo sobre Marshalsec: [https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true](https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true)
Descubra o que é **Injeção JNDI, como abusá-la via RMI, CORBA e LDAP e como explorar o log4shell** (e exemplo dessa vulnerabilidade) na seguinte página:
> A API **Java Message Service** (**JMS**) é uma API de middleware orientada a mensagens Java para enviar mensagens entre dois ou mais clientes. É uma implementação para lidar com o problema produtor-consumidor. O JMS é uma parte da Plataforma Java, Enterprise Edition (Java EE), e foi definido por uma especificação desenvolvida na Sun Microsystems, mas que desde então tem sido guiada pelo Java Community Process. É um padrão de mensagens que permite que componentes de aplicativos baseados em Java EE criem, enviem, recebam e leiam mensagens. Ele permite que a comunicação entre diferentes componentes de um aplicativo distribuído seja fracamente acoplada, confiável e assíncrona. (De [Wikipedia](https://en.wikipedia.org/wiki/Java\_Message\_Service)).
Basicamente, há **um monte de serviços usando JMS de maneira perigosa**. Portanto, se você tiver **privilégios suficientes** para enviar mensagens para esses serviços (geralmente precisará de credenciais válidas), poderá enviar **objetos maliciosos serializados que serão desserializados pelo consumidor/assinante**.\
Isso significa que, nessa exploração, todos os **clientes que vão usar essa mensagem serão infectados**.
Você deve lembrar que, mesmo que um serviço seja vulnerável (porque está desserializando de forma insegura a entrada do usuário), você ainda precisa encontrar gadgets válidos para explorar a vulnerabilidade.
A ferramenta [JMET](https://github.com/matthiaskaiser/jmet) foi criada para **conectar e atacar esses serviços enviando vários objetos maliciosos serializados usando gadgets conhecidos**. Esses exploits funcionarão se o serviço ainda estiver vulnerável e se algum dos gadgets usados estiver dentro do aplicativo vulnerável.
O .Net é semelhante ao Java em relação a como os exploits de desserialização funcionam: o **exploit** irá **abusar de gadgets** que **executam** algum **código interessante quando** um objeto é **desserializado**.
Você pode procurar pela string codificada em Base64 **AAEAAAD/////** ou qualquer outra coisa que **possa ser desserializada** no back-end e que permita controlar o tipo desserializado. Por exemplo, um **JSON** ou **XML** contendo `TypeObject` ou `$type`.
Nesse caso, você pode usar a ferramenta [**ysoserial.net**](https://github.com/pwntester/ysoserial.net) para **criar os exploits de desserialização**. Depois de baixar o repositório git, você deve **compilar a ferramenta** usando o Visual Studio, por exemplo.
Se você quiser aprender sobre **como o ysoserial.net cria seus exploits**, você pode [**verificar esta página onde é explicado o gadget ObjectDataProvider + ExpandedWrapper + Json.Net formatter**](basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md).
* **`--gadget`** usado para indicar o gadget a ser abusado (indique a classe/função que será abusada durante a desserialização para executar comandos).
* **`--formatter`**, usado para indicar o método para serializar o exploit (você precisa saber qual biblioteca o back-end está usando para desserializar a carga útil e usar a mesma para serializá-la)
* \*\*`--output` \*\* usado para indicar se você deseja o exploit em **raw** ou codificado em **base64**. _Observe que o **ysoserial.net** irá **codificar** a carga útil usando **UTF-16LE** (codificação usada por padrão no Windows), portanto, se você obter o raw e apenas codificá-lo a partir de um console linux, poderá ter alguns problemas de **compatibilidade de codificação** que impedirão o exploit de funcionar corretamente (na caixa JSON do HTB, a carga útil funcionou em UTF-16LE e ASCII, mas isso não significa que sempre funcionará)._
O **ysoserial.net** também tem um **parâmetro muito interessante** que ajuda a entender melhor como cada exploit funciona: `--test`. Se você indicar esse parâmetro, o **ysoserial.net** tentará o **exploit localmente**, para que você possa testar se sua carga útil funcionará corretamente. Esse parâmetro é útil porque, se você revisar o código, encontrará trechos de código como o seguinte (de [ObjectDataProviderGenerator.cs](https://github.com/pwntester/ysoserial.net/blob/c53bd83a45fb17eae60ecc82f7147b5c04b07e42/ysoserial/Generators/ObjectDataProviderGenerator.cs#L208)):
Isso significa que, para testar a exploração, o código chamará [serializersHelper.JsonNet\_deserialize](https://github.com/pwntester/ysoserial.net/blob/c53bd83a45fb17eae60ecc82f7147b5c04b07e42/ysoserial/Helpers/SerializersHelper.cs#L539).
No código anterior é vulnerável ao exploit criado. Portanto, se você encontrar algo semelhante em um aplicativo .Net, isso significa que provavelmente esse aplicativo também é vulnerável.\
Portanto, o parâmetro **`--test`** nos permite entender **quais trechos de código são vulneráveis** ao exploit de deserialização que **ysoserial.net** pode criar.
Dê uma olhada neste POST sobre **como tentar explorar o parâmetro \_\_ViewState do .Net** para **executar código arbitrário**. Se você **já conhece os segredos** usados pela máquina vítima, [**leia este post para saber como executar código**](exploiting-\_\_viewstate-knowing-the-secret.md)**.**
Não permita que o fluxo de dados defina o tipo de objeto para o qual o fluxo será desserializado. Você pode evitar isso, por exemplo, usando o `DataContractSerializer` ou `XmlSerializer`, se possível.
Se você precisar desserializar fluxos de dados que definem seu próprio tipo, restrinja os tipos que são permitidos ser desserializados. Deve-se estar ciente de que isso ainda é arriscado, pois muitos tipos nativos do .Net são potencialmente perigosos em si mesmos. Por exemplo:
Objetos `FileInfo` que referenciam arquivos que estão realmente no servidor podem, quando desserializados, alterar as propriedades desses arquivos, como torná-los somente leitura, criando um potencial ataque de negação de serviço.
Mesmo que você tenha limitado os tipos que podem ser desserializados, lembre-se de que alguns tipos têm propriedades arriscadas. `System.ComponentModel.DataAnnotations.ValidationException`, por exemplo, tem uma propriedade `Value` do tipo `Object`. Se este tipo for permitido para desserialização, um invasor pode definir a propriedade `Value` para qualquer tipo de objeto que escolher.
Os invasores devem ser impedidos de direcionar o tipo que será instanciado. Se isso for possível, até mesmo `DataContractSerializer` ou `XmlSerializer` podem ser subvertidos, por exemplo.
Tente se manter atualizado sobre os gadgets de deserialização inseguros conhecidos do .Net e preste atenção especial onde tais tipos podem ser criados pelos seus processos de deserialização. **Um desserializador só pode instanciar tipos que ele conhece**.
Tente manter qualquer código que possa criar gadgets potenciais separado de qualquer código que tenha conectividade com a internet. Como exemplo, `System.Windows.Data.ObjectDataProvider` usado em aplicativos WPF é um gadget conhecido que permite a invocação arbitrária de métodos. Seria arriscado ter uma referência a este assembly em um projeto de serviço REST que desserializa dados não confiáveis.
Ruby tem dois métodos para implementar serialização dentro da biblioteca **marshal**: o primeiro método é **dump** que converte o objeto em fluxos de bytes **(serializar)**. E o segundo método é **load** para converter o fluxo de bytes em objeto novamente (**desserializar**).\
Ruby usa HMAC para assinar o objeto serializado e salva a chave em um dos seguintes arquivos:
Cadeia de gadgets de deserialização genérica do Ruby 2.X para RCE (mais informações em [https://www.elttam.com/blog/ruby-deserialization/](https://www.elttam.com/blog/ruby-deserialization/)):
Outra cadeia de RCE para explorar o Ruby On Rails: [https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/](https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/)
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira 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 do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do 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 suas técnicas 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).