Como uma Falha Simples de IDOR permitiu Account Takeover
Introdução
No mundo da cibersegurança, muitas vezes assumimos que as falhas mais perigosas são aquelas complexas e tecnicamente difíceis de encontrar. No entanto, a realidade dos programas de Bug Bounty prova frequentemente o contrário. Neste artigo, vou partilhar como descobri uma vulnerabilidade de IDOR (Insecure Direct Object Reference) numa aplicação de gestão financeira que me permitiu assumir o controlo de qualquer conta de utilizador, incluindo administradores, em questão de minutos.
O Que é um IDOR?
Para quem está a começar, o IDOR ocorre quando uma aplicação expõe uma referência direta a um objeto (como um ficheiro, um ID de base de dados ou uma conta) e não verifica se o utilizador que está a fazer o pedido tem, de facto, permissão para aceder a esse objeto. É como se um banco te deixasse ver o saldo de outra pessoa apenas porque mudaste o número da conta no URL.
A Descoberta
O meu alvo era uma aplicação web do tipo SaaS (Software as a Service). Comecei a minha análise mapeando as funcionalidades básicas que qualquer utilizador teria: login, recuperação de palavra-passe e edição de perfil.
Ao utilizar uma ferramenta de proxy para analisar o tráfego entre o meu navegador e o servidor, foquei-me na funcionalidade "Atualizar Perfil". Notei que, ao submeter o pedido para alterar o meu próprio endereço de e-mail, o servidor recebia um conjunto de dados onde o meu número de identificação de utilizador (User ID) estava explicitamente visível e acessível para edição.
Isto levantou imediatamente uma suspeita: o que aconteceria se eu mudasse esse número?
A Exploração
Para testar a minha teoria, criei duas contas distintas: a conta do "Atacante" e a conta da "Vítima".
Entrei na conta do Atacante e iniciei o processo de alteração de e-mail.
Intercetei o pedido antes de este chegar ao servidor.
Substituí o ID do Atacante pelo ID da Vítima.
Alterei o campo de e-mail para um endereço que eu controlava e enviei o pedido.
O servidor respondeu com uma mensagem de "Sucesso".
Para confirmar o impacto, fui verificar a conta da Vítima. O e-mail tinha sido efetivamente alterado para o meu. O sistema tinha confiado cegamente no ID que eu forneci, ignorando que a minha sessão autenticada pertencia a outro utilizador.
Escalando para Account Takeover (ATO)
Alterar o e-mail de um utilizador é grave, mas o verdadeiro perigo reside no que se pode fazer a seguir. Com o e-mail da vítima alterado para um endereço que eu controlo, o passo seguinte foi trivial:
Saí da aplicação e fui à página de login.
Selecionei a opção "Esqueci-me da palavra-passe".
Inseri o novo e-mail (o meu) associado à conta da vítima.
Recebi o link de recuperação, defini uma nova palavra-passe e entrei na conta da vítima com acesso total.
O Impacto
A gravidade desta falha é considerada crítica. Num cenário real, um atacante poderia automatizar este processo para sequestrar centenas de contas, aceder a dados financeiros sensíveis, ler mensagens privadas e destruir a reputação da empresa. Como os IDs dos utilizadores eram sequenciais, era extremamente fácil prever quais os números alvo.
Como Corrigir
A correção para este tipo de vulnerabilidade não envolve "magia", mas sim boas práticas de controlo de acesso. O servidor nunca deve confiar nos IDs enviados pelo utilizador para operações sensíveis.
Em vez disso, a aplicação deve validar sempre se o ID do utilizador que está a tentar fazer a alteração (obtido através do token de sessão segura) corresponde ao ID da conta que está a ser modificada. Se não corresponder, o pedido deve ser rejeitado imediatamente.
Conclusão
Esta descoberta reforça uma lição importante para developers e pentesters: nunca confiem na entrada de dados do utilizador. As validações devem ser sempre feitas no lado do servidor (backend) e não apenas no interface visual.
Cronologia
10/05 - Vulnerabilidade descoberta durante testes manuais.
10/05 - Relatório submetido à equipa de segurança da empresa.
12/05 - Falha triada e classificada como Crítica.
15/05 - Correção implementada e verificada.
20/05 - Recompensa (Bounty) atribuída.
No mundo da cibersegurança, muitas vezes assumimos que as falhas mais perigosas são aquelas complexas e tecnicamente difíceis de encontrar. No entanto, a realidade dos programas de Bug Bounty prova frequentemente o contrário. Neste artigo, vou partilhar como descobri uma vulnerabilidade de IDOR (Insecure Direct Object Reference) numa aplicação de gestão financeira que me permitiu assumir o controlo de qualquer conta de utilizador, incluindo administradores, em questão de minutos.
O Que é um IDOR?
Para quem está a começar, o IDOR ocorre quando uma aplicação expõe uma referência direta a um objeto (como um ficheiro, um ID de base de dados ou uma conta) e não verifica se o utilizador que está a fazer o pedido tem, de facto, permissão para aceder a esse objeto. É como se um banco te deixasse ver o saldo de outra pessoa apenas porque mudaste o número da conta no URL.
A Descoberta
O meu alvo era uma aplicação web do tipo SaaS (Software as a Service). Comecei a minha análise mapeando as funcionalidades básicas que qualquer utilizador teria: login, recuperação de palavra-passe e edição de perfil.
Ao utilizar uma ferramenta de proxy para analisar o tráfego entre o meu navegador e o servidor, foquei-me na funcionalidade "Atualizar Perfil". Notei que, ao submeter o pedido para alterar o meu próprio endereço de e-mail, o servidor recebia um conjunto de dados onde o meu número de identificação de utilizador (User ID) estava explicitamente visível e acessível para edição.
Isto levantou imediatamente uma suspeita: o que aconteceria se eu mudasse esse número?
A Exploração
Para testar a minha teoria, criei duas contas distintas: a conta do "Atacante" e a conta da "Vítima".
Entrei na conta do Atacante e iniciei o processo de alteração de e-mail.
Intercetei o pedido antes de este chegar ao servidor.
Substituí o ID do Atacante pelo ID da Vítima.
Alterei o campo de e-mail para um endereço que eu controlava e enviei o pedido.
O servidor respondeu com uma mensagem de "Sucesso".
Para confirmar o impacto, fui verificar a conta da Vítima. O e-mail tinha sido efetivamente alterado para o meu. O sistema tinha confiado cegamente no ID que eu forneci, ignorando que a minha sessão autenticada pertencia a outro utilizador.
Escalando para Account Takeover (ATO)
Alterar o e-mail de um utilizador é grave, mas o verdadeiro perigo reside no que se pode fazer a seguir. Com o e-mail da vítima alterado para um endereço que eu controlo, o passo seguinte foi trivial:
Saí da aplicação e fui à página de login.
Selecionei a opção "Esqueci-me da palavra-passe".
Inseri o novo e-mail (o meu) associado à conta da vítima.
Recebi o link de recuperação, defini uma nova palavra-passe e entrei na conta da vítima com acesso total.
O Impacto
A gravidade desta falha é considerada crítica. Num cenário real, um atacante poderia automatizar este processo para sequestrar centenas de contas, aceder a dados financeiros sensíveis, ler mensagens privadas e destruir a reputação da empresa. Como os IDs dos utilizadores eram sequenciais, era extremamente fácil prever quais os números alvo.
Como Corrigir
A correção para este tipo de vulnerabilidade não envolve "magia", mas sim boas práticas de controlo de acesso. O servidor nunca deve confiar nos IDs enviados pelo utilizador para operações sensíveis.
Em vez disso, a aplicação deve validar sempre se o ID do utilizador que está a tentar fazer a alteração (obtido através do token de sessão segura) corresponde ao ID da conta que está a ser modificada. Se não corresponder, o pedido deve ser rejeitado imediatamente.
Conclusão
Esta descoberta reforça uma lição importante para developers e pentesters: nunca confiem na entrada de dados do utilizador. As validações devem ser sempre feitas no lado do servidor (backend) e não apenas no interface visual.
Cronologia
10/05 - Vulnerabilidade descoberta durante testes manuais.
10/05 - Relatório submetido à equipa de segurança da empresa.
12/05 - Falha triada e classificada como Crítica.
15/05 - Correção implementada e verificada.
20/05 - Recompensa (Bounty) atribuída.
Introdução
No mundo da cibersegurança, muitas vezes assumimos que as falhas mais perigosas são aquelas complexas e tecnicamente difíceis de encontrar. No entanto, a realidade dos programas de Bug Bounty prova frequentemente o contrário. Neste artigo, vou partilhar como descobri uma vulnerabilidade de IDOR (Insecure Direct Object Reference) numa aplicação de gestão financeira que me permitiu assumir o controlo de qualquer conta de utilizador, incluindo administradores, em questão de minutos.
O Que é um IDOR?
Para quem está a começar, o IDOR ocorre quando uma aplicação expõe uma referência direta a um objeto (como um ficheiro, um ID de base de dados ou uma conta) e não verifica se o utilizador que está a fazer o pedido tem, de facto, permissão para aceder a esse objeto. É como se um banco te deixasse ver o saldo de outra pessoa apenas porque mudaste o número da conta no URL.
A Descoberta
O meu alvo era uma aplicação web do tipo SaaS (Software as a Service). Comecei a minha análise mapeando as funcionalidades básicas que qualquer utilizador teria: login, recuperação de palavra-passe e edição de perfil.
Ao utilizar uma ferramenta de proxy para analisar o tráfego entre o meu navegador e o servidor, foquei-me na funcionalidade "Atualizar Perfil". Notei que, ao submeter o pedido para alterar o meu próprio endereço de e-mail, o servidor recebia um conjunto de dados onde o meu número de identificação de utilizador (User ID) estava explicitamente visível e acessível para edição.
Isto levantou imediatamente uma suspeita: o que aconteceria se eu mudasse esse número?
A Exploração
Para testar a minha teoria, criei duas contas distintas: a conta do "Atacante" e a conta da "Vítima".
Entrei na conta do Atacante e iniciei o processo de alteração de e-mail.
Intercetei o pedido antes de este chegar ao servidor.
Substituí o ID do Atacante pelo ID da Vítima.
Alterei o campo de e-mail para um endereço que eu controlava e enviei o pedido.
O servidor respondeu com uma mensagem de "Sucesso".
Para confirmar o impacto, fui verificar a conta da Vítima. O e-mail tinha sido efetivamente alterado para o meu. O sistema tinha confiado cegamente no ID que eu forneci, ignorando que a minha sessão autenticada pertencia a outro utilizador.
Escalando para Account Takeover (ATO)
Alterar o e-mail de um utilizador é grave, mas o verdadeiro perigo reside no que se pode fazer a seguir. Com o e-mail da vítima alterado para um endereço que eu controlo, o passo seguinte foi trivial:
Saí da aplicação e fui à página de login.
Selecionei a opção "Esqueci-me da palavra-passe".
Inseri o novo e-mail (o meu) associado à conta da vítima.
Recebi o link de recuperação, defini uma nova palavra-passe e entrei na conta da vítima com acesso total.
O Impacto
A gravidade desta falha é considerada crítica. Num cenário real, um atacante poderia automatizar este processo para sequestrar centenas de contas, aceder a dados financeiros sensíveis, ler mensagens privadas e destruir a reputação da empresa. Como os IDs dos utilizadores eram sequenciais, era extremamente fácil prever quais os números alvo.
Como Corrigir
A correção para este tipo de vulnerabilidade não envolve "magia", mas sim boas práticas de controlo de acesso. O servidor nunca deve confiar nos IDs enviados pelo utilizador para operações sensíveis.
Em vez disso, a aplicação deve validar sempre se o ID do utilizador que está a tentar fazer a alteração (obtido através do token de sessão segura) corresponde ao ID da conta que está a ser modificada. Se não corresponder, o pedido deve ser rejeitado imediatamente.
Conclusão
Esta descoberta reforça uma lição importante para developers e pentesters: nunca confiem na entrada de dados do utilizador. As validações devem ser sempre feitas no lado do servidor (backend) e não apenas no interface visual.
Cronologia
10/05 - Vulnerabilidade descoberta durante testes manuais.
10/05 - Relatório submetido à equipa de segurança da empresa.
12/05 - Falha triada e classificada como Crítica.
15/05 - Correção implementada e verificada.
20/05 - Recompensa (Bounty) atribuída.
No mundo da cibersegurança, muitas vezes assumimos que as falhas mais perigosas são aquelas complexas e tecnicamente difíceis de encontrar. No entanto, a realidade dos programas de Bug Bounty prova frequentemente o contrário. Neste artigo, vou partilhar como descobri uma vulnerabilidade de IDOR (Insecure Direct Object Reference) numa aplicação de gestão financeira que me permitiu assumir o controlo de qualquer conta de utilizador, incluindo administradores, em questão de minutos.
O Que é um IDOR?
Para quem está a começar, o IDOR ocorre quando uma aplicação expõe uma referência direta a um objeto (como um ficheiro, um ID de base de dados ou uma conta) e não verifica se o utilizador que está a fazer o pedido tem, de facto, permissão para aceder a esse objeto. É como se um banco te deixasse ver o saldo de outra pessoa apenas porque mudaste o número da conta no URL.
A Descoberta
O meu alvo era uma aplicação web do tipo SaaS (Software as a Service). Comecei a minha análise mapeando as funcionalidades básicas que qualquer utilizador teria: login, recuperação de palavra-passe e edição de perfil.
Ao utilizar uma ferramenta de proxy para analisar o tráfego entre o meu navegador e o servidor, foquei-me na funcionalidade "Atualizar Perfil". Notei que, ao submeter o pedido para alterar o meu próprio endereço de e-mail, o servidor recebia um conjunto de dados onde o meu número de identificação de utilizador (User ID) estava explicitamente visível e acessível para edição.
Isto levantou imediatamente uma suspeita: o que aconteceria se eu mudasse esse número?
A Exploração
Para testar a minha teoria, criei duas contas distintas: a conta do "Atacante" e a conta da "Vítima".
Entrei na conta do Atacante e iniciei o processo de alteração de e-mail.
Intercetei o pedido antes de este chegar ao servidor.
Substituí o ID do Atacante pelo ID da Vítima.
Alterei o campo de e-mail para um endereço que eu controlava e enviei o pedido.
O servidor respondeu com uma mensagem de "Sucesso".
Para confirmar o impacto, fui verificar a conta da Vítima. O e-mail tinha sido efetivamente alterado para o meu. O sistema tinha confiado cegamente no ID que eu forneci, ignorando que a minha sessão autenticada pertencia a outro utilizador.
Escalando para Account Takeover (ATO)
Alterar o e-mail de um utilizador é grave, mas o verdadeiro perigo reside no que se pode fazer a seguir. Com o e-mail da vítima alterado para um endereço que eu controlo, o passo seguinte foi trivial:
Saí da aplicação e fui à página de login.
Selecionei a opção "Esqueci-me da palavra-passe".
Inseri o novo e-mail (o meu) associado à conta da vítima.
Recebi o link de recuperação, defini uma nova palavra-passe e entrei na conta da vítima com acesso total.
O Impacto
A gravidade desta falha é considerada crítica. Num cenário real, um atacante poderia automatizar este processo para sequestrar centenas de contas, aceder a dados financeiros sensíveis, ler mensagens privadas e destruir a reputação da empresa. Como os IDs dos utilizadores eram sequenciais, era extremamente fácil prever quais os números alvo.
Como Corrigir
A correção para este tipo de vulnerabilidade não envolve "magia", mas sim boas práticas de controlo de acesso. O servidor nunca deve confiar nos IDs enviados pelo utilizador para operações sensíveis.
Em vez disso, a aplicação deve validar sempre se o ID do utilizador que está a tentar fazer a alteração (obtido através do token de sessão segura) corresponde ao ID da conta que está a ser modificada. Se não corresponder, o pedido deve ser rejeitado imediatamente.
Conclusão
Esta descoberta reforça uma lição importante para developers e pentesters: nunca confiem na entrada de dados do utilizador. As validações devem ser sempre feitas no lado do servidor (backend) e não apenas no interface visual.
Cronologia
10/05 - Vulnerabilidade descoberta durante testes manuais.
10/05 - Relatório submetido à equipa de segurança da empresa.
12/05 - Falha triada e classificada como Crítica.
15/05 - Correção implementada e verificada.
20/05 - Recompensa (Bounty) atribuída.
1 likes
Comentários (1)
Queres participar na discussão? Faz login ou cria conta.