Pesquisa de VulnerabilidadeVulnerability Research
OWASP DefectDojo — Web Privilege Escalation (CVE-2023-48171)OWASP DefectDojo — Web Privilege Escalation (CVE-2023-48171)
A validação que impedia um Staff User de virar Superuser só existia no
navegador. O servidor aceitava o campo is_superuser direto no request — e pronto,
você vira o sensei do dojo.The check that stopped a Staff User from
becoming a Superuser lived only in the browser. The server happily accepted an
is_superuser field straight from the request — and just like that, you become the
sensei of the dojo.
- CVE ID
- CVE-2023-48171
- Severity
- High
- Affected
- DefectDojo 1.5.3.0
- Vendor
- OWASP DefectDojo
- Disclosure
- Coordenada · corrigida na 1.5.3.1Coordinated · fixed in 1.5.3.1
- Researcher
- Felipe Novais (crwl3y) — Vultus
Você já imaginou uma ferramenta de cibersegurança tendo vulnerabilidades? Pra quem é de fora da área pode soar contraintuitivo. Mas foi exatamente o que rolou com o DefectDojo 1.5.3.0 no começo de janeiro de 2019.Have you ever imagined a cybersecurity tool having vulnerabilities? It may sound counterintuitive for people outside of the field. Yet that is exactly what happened with DefectDojo 1.5.3.0 at the beginning of January 2019.
ConteúdoContents
IntroduçãoIntroduction
A gente implantou o DefectDojo 1.5.3.0, a ferramenta open source de DevSecOps com gestão de vulnerabilidades de aplicação pra fluxos manuais e automatizados. Dá pra usar no estilo tradicional ou plugar no seu pipeline de CI/CD DevSecOps. A gente estava procurando uma ferramenta de segurança pra facilitar o workflow de pentest e avaliação de vulnerabilidades, e deixar a vida dos nossos analistas mais leve (a gente ama eles <3). Aí me deram a tarefa de testar a ferramenta pra ver se ela ajudaria o time. Durante o teste, eu fiquei com o papel de Staff User.We rolled out DefectDojo 1.5.3.0, the open-source DevSecOps tool with application vulnerability management for both manual and automated flows. You can run it the traditional way or wire it into your CI/CD DevSecOps pipeline. We were hunting for a security tool to ease the pentest and vulnerability-assessment workflow and make our analysts' lives easier (we love them <3). So I was tasked with testing the tool to see whether it would benefit the team. During the test, I was assigned the role of a Staff User.
No meio dos testes, esbarrei em funcionalidades que eu, como Staff User, não conseguia acessar — e meu chefe estava ocupado demais pra me dar acesso ou liberar o que eu queria. Como red team operator, em vez de pedir ou simplesmente esperar, fui tentar achar meu próprio caminho pra dentro do sistema. Foi assim que cheguei numa vulnerabilidade de Web Privilege Escalation.During testing I ran into features that I, as a Staff User, simply couldn't access — and my boss was too busy to grant me access or change what I wanted. As a red team operator, instead of asking or just waiting around, I went looking for my own way into the system. That's how I landed on a Web Privilege Escalation vulnerability.
Web Privilege EscalationWeb Privilege Escalation
Na ausência de controles que definam corretamente as permissões sobre quais usuários fazem alterações num software web, um agente malicioso pode usar esses vetores pra ganhar um nível de acesso maior e tirar alguma vantagem disso — tipo acessar a conta de outros usuários ou conteúdo protegido por nível de acesso. Às vezes é um teste complexo, que exige fuzzing nos inputs pra descobrir as roles ou escalar privilégios em camadas. Outras vezes, é tão simples quanto jogar um parâmetro de query string na URL, assim:When there are no controls to correctly set permissions over which users can make changes in a web application, a malicious agent can abuse these vectors to gain a higher access level and turn that into some advantage — like accessing other users' accounts or content protected by access level. Sometimes it's a complex test that requires fuzzing the inputs to discover the roles or to escalate them in layers. Other times it's as simple as dropping a query-string parameter into the URL, like this:
GET /system_configurations?isadmin=1
O erro de confiar no clienteThe misassumption of trusting the client
Repita comigo: "Nunca confie em dados do cliente." Essa frase é dita em alto e bom som na comunidade de cibersegurança e até aparece em algumas aulas de boas práticas pra desenvolvedores. O principal proxy de um atacante pra conseguir um foothold num sistema é algum input que o usuário consegue controlar.Repeat after me: "Never trust client data." This phrase is spoken loud and clear across the cybersecurity community and even shows up in some developer best-practices classes. An attacker's main proxy for getting a foothold in a system is some input the user can control.
Virando sensei do dojoGetting yourself sensei status in the dojo
No DefectDojo, um Staff User pode criar e editar as roles de outros usuários. Aparentemente, porém, a intenção era que os Staff Users só pudessem criar e editar usuários comuns e outros Staff Users — nunca um Superuser onipotente. Pelo menos é o que a interface te leva a acreditar.In DefectDojo, a Staff User can create and edit other users' roles. Apparently, though, the intent was that Staff Users could only create and edit normal users and other Staff Users — never an omnipotent Superuser. At least, that's what the interface leads you to believe.
O problema é que essa validação só era aplicada no lado do cliente, pela navegação do usuário no browser (o cliente). O formulário de criação/edição de usuário, pro Staff User, não tem um checkbox pra marcar que o usuário é Superuser. Mesmo assim, o servidor aceita que um Staff User crie ou edite as roles pra escalar o privilégio até Superuser — ou criar um Superuser — se o input for setado direto no request.The problem is that this validation was only enforced on the client side, through the user's navigation in the web browser (the client). The user create/edit form shown to a Staff User has no checkbox to mark a user as Superuser. Yet the server still accepts that a Staff User creates or edits the roles to escalate the privilege up to Superuser — or to create a Superuser outright — if the input is set directly in the request.
ExploitExploit
Como Staff User, no envio de um formulário de criar ou editar usuário — cujos
endpoints são POST /user/add e POST /user/<id>/edit,
respectivamente — dá pra setar um campo chamado is_superuser pra marcar ou desmarcar
e fazer o usuário receber a role de Super User durante a criação ou alteração de qualquer
conta.As a Staff User, when submitting a create-user or edit-user form —
whose endpoints are POST /user/add and POST /user/<id>/edit,
respectively — you can set a field named is_superuser to toggle it on or off and make
the user hold the Super User role during the creation or change of any account.
Ou seja: mesmo que o formulário não mostre o checkbox pra que o Bob médio não clique nele no navegador, o servidor ainda aceita esse parâmetro setado — o que torna possível escalar o privilégio de um Staff User pra Superuser.In other words: even though the form doesn't show the checkbox so the average Bob doesn't click it in the browser, the server still accepts that parameter when it's set — which makes it possible to escalate a Staff User's privilege to Superuser.
Essa alteração podia ser feita com uma ferramenta de proxy web com capacidade de tampering, tipo Burp Suite ou OWASP ZAP — ou, mais simples ainda, só usando o Developer Tools do navegador. O ponto é: o request seria algo parecido com esta representação simplificada de um HTTP POST:This change could be made with a web proxy tool that supports tampering, like Burp Suite or OWASP ZAP — or, even simpler, just using the browser's Developer Tools. The point is that the request would look something like this simplified HTTP POST:
POST /user/add
csrfmiddlewaretoken=<redacted>&username=<redacted>&first_name=a&last_name=<redacted>&email=<redacted>=&add_user=Edit+User&is_active=on&is_staff=on
E podia ser modificado pra ficar assim (repara no campo
is_superuser):And it could be modified to look like this
(pay attention to the is_superuser field):
POST /user/add
csrfmiddlewaretoken=<redacted>&username=<redacted>&first_name=a&last_name=<redacted>&email=<redacted>=&add_user=Edit+User&is_active=on&is_staff=on&is_superuser=on
Desse jeito, um agente malicioso com a role de Staff User poderia editar a si mesmo pra ganhar a role de Super User — e até trancar os outros usuários pra fora da aplicação. A única coisa que impede o Bob médio de tirar proveito dessa falha é o fato de o checkbox não aparecer no formulário de criar/editar usuário.This way, a malicious agent with a Staff User role could edit itself to grant a Super User role — and even lock the other users out of the application. The only thing keeping the average Bob from taking advantage of this flaw is that the checkbox doesn't show up in the create/edit user form.
ImpactoImpact
Virar Super User no DefectDojo significa que você consegue acessar a interface
do Django Admin (pelo caminho /admin). E é má notícia se qualquer usuário além do
Super User pretendido conseguir acessar as System Settings. Por esse caminho, um usuário poderia
potencialmente acessar os dados de outros usuários, alterar configurações globais do sistema pra
injetar dados maliciosos, controlar as chaves de integração da API, e por aí vai.Becoming
a Super User in DefectDojo means you can reach the Django Admin interface (via the
/admin path). And it's bad news if any user besides the intended Super User can reach
the System Settings. Down that road, a user could potentially access other users' data, change
system-wide configurations to plant malicious data, control the API integration keys, and so
on.
MitigaçãoMitigation
Felizmente, o problema foi resolvido no mesmo mês em que foi reportado, e a gente recebeu uma resposta rápida do time. Na época foi um hotfix, que depois foi tagueado na release 1.5.3.1. Pra ficar protegido dessa vulnerabilidade, atualize o DefectDojo pra última versão.Thankfully, the issue was resolved in the same month it was reported, and we got a fast response from the team. At the time it was a hotfix, later tagged into release 1.5.3.1. To stay safe from this vulnerability, update DefectDojo to the latest version.
É bom ver que hoje, anos depois da descoberta, o software cresceu ainda mais e melhorou bastante sua maturidade de segurança desde lá atrás.It's good to see that today, years after the discovery, the software has grown even further and improved its security maturity a lot since back then.
TimelineTimeline
- 2019-01-09Vulnerabilidade reportada ao time do DefectDojo.Vulnerability reported to the DefectDojo team.
- 2019-01-28Pull Request com o patch mergeado na branch master.Pull Request patch merged to the master branch.
- 2019-02-04Security Advisory publicado.Security Advisory published.
- 2023-11-09CVE ID solicitado.CVE ID requested.
- 2023-11-16Tentativa de contato com o time do DefectDojo pra coordenar e revisar o post de disclosure/PoC.Reached out to the DefectDojo team to coordinate and review the disclosure/PoC post.
LinksLinks
- Pull Request com o patch mergeado na branch master (patch commit).Pull Request patch merged to the master branch (patch commit).
- Security Advisory.Security Advisory.
ReferênciasReferences
- Web App Privilege Escalation, por 21y4d (Zeyad AlMadani).Web App Privilege Escalation, by 21y4d (Zeyad AlMadani).
- OWASP Guide 03 — Testing for Privilege Escalation.OWASP Guide 03 — Testing for Privilege Escalation.