Tomada de Conta via CSPT com Posterior Bypass de 2FA através da Cadeia de Protótipos

Passo 1. Recorrido de Caminho do Lado do Cliente

O primitivo CSPT é bastante típico: o atacante altera o caminho da solicitação de envio de convite PUT /api/v2/teams//invites/ para o endpoint de alteração de e-mail PUT /api/v2/user.

Como resultado, quando a vítima segue o link do convite, o cliente envia uma solicitação que altera o endereço de e-mail da vítima para um controlado pelo atacante.

A parte interessante é que o CSPT só dá controle sobre a URL, não sobre o corpo da solicitação. De acordo com a semântica HTTP, PUT geralmente carrega o novo estado do recurso no corpo da solicitação. Neste caso, no entanto, o servidor não exigiu estritamente que o novo e-mail fosse fornecido no corpo e o aceitou de um parâmetro de consulta em vez disso. Isso tornou a tomada de conta possível.

Passo 2. Bypass de 2FA via Cadeia de Protótipos

Em seguida, o pesquisador precisou fazer login na conta comprometida e passar pela verificação OTP. Isso foi contornado enviando proto em vez de um código válido.

O problema depende da pesquisa de propriedades JavaScript. Ao ler uma propriedade de objeto, o JavaScript primeiro verifica as próprias chaves do objeto; se a chave não for encontrada, ele continua subindo na cadeia de protótipos até Object.prototype.

Com base no comportamento observado, o servidor provavelmente verificou a validade do OTP com lógica semelhante a:

if (pendingCodes[code]) { // issue session }

Quando o atacante enviou: X-2FA-Code: proto não havia nenhuma chave própria chamada proto em pendingCodes, mas proto é uma propriedade herdada disponível em objetos JavaScript comuns. Portanto, pendingCodes["proto"] retornou o protótipo do objeto — um valor verdadeiro. A condição passou e o servidor emitiu uma sessão.

📎 Artigo: https://whoareme.com/blog/cspt-account-takeover-2fa-bypass/

💬 Discutir