CyberEDU — Injection | Writeup | 3whoSec

În acest writeup voi parcurge pas cu pas rezolvarea challenge-ului Injection de pe CyberEDU, din cadrul TFCCTF 2022.

Este un challenge de Web Security în care trebuie să investigăm aplicația, să vedem cum funcționează input-ul și să găsim o metodă de a ajunge la flag. Pe scurt: o aplicație care prelucrează input-ul nostru într-un mod periculos — ceea ce ne duce direct cu gândul la Command Injection.

Recon & Enumeration

După ce pornesc challenge-ul, primesc IP-ul și portul serverului.

Deschid aplicația în Firefox pentru a vedea ce avem la dispoziție.

Înainte să încerc să atac direct aplicația, vreau să fac puțină enumeration și să văd dacă există directoare sau fișiere interesante.

Pentru asta folosesc dirsearch.

Instalare dirsearch (dacă nu îl aveți deja)

sudo apt install dirsearch -y

sudo apt install dirsearch -y

Comanda folosită pentru scanare

dirsearch -u http://<IP>:<PORT>

dirsearch -u http://<IP>:<PORT>

Explicația comenzii

• -u http://: → Specifică URL-ul țintă (înlocuiește <IP> și <PORT> cu valorile primite de la platformă)

Aștept ca scanarea să se termine și mă uit prin rezultate.

Printre rezultate apare și:

/flag.php

/flag.php

Dar acesta răspunde cu:

200 OK

200 OK

Dar conținutul este complet gol — nu există nimic util acolo. Este doar o pagină care răspunde cu status 200, dar fără informații.

Deci momentan /flag.php nu ne oferă nimic util și continuăm investigația.

Analizarea aplicației

Mă întorc la pagina principală.

Observ că aplicația primește un input de la utilizator și îl folosește într-o comandă de sistem. În cazul nostru, aplicația pare să execute o comandă de tip ping pe baza input-ului nostru.

Aici apare un lucru foarte important: aplicația ia input-ul nostru și îl folosește într-o comandă de sistem. Asta ridică imediat posibilitatea unei vulnerabilități de Command Injection.

Testarea Command Injection

În loc să trimit doar o adresă IP validă, încerc să introduc un command separator și o comandă proprie.

Payload-uri testate

127.0.0.1; ls
127.0.0.1 | ls

127.0.0.1; ls
127.0.0.1 | ls

Explicația separatorilor

; --> Execută comanda de după, indiferent de rezultatul primei comenzi

| → Trimite output-ul primei comenzi ca input pentru a doua comandă (pipe)

&& → Execută a doua comandă doar dacă prima a reușit

|| → Execută a doua comandă doar dacă prima a eșuat

cmd sau $(cmd) --> Substituție de comandă — output-ul devine argument

Ideea este simplă: vreau să verific dacă serverul execută și comanda ls, pe lângă comanda originală.

După trimiterea request-ului, rezultatul apare în răspuns.

Asta este confirmarea că input-ul nostru este interpretat de shell și că putem executa comenzi suplimentare. Avem, deci, Command Injection.

Enumeration prin Command Injection

Acum că știm că putem executa comenzi, putem folosi această vulnerabilitate pentru a face mai multă enumeration.

Rulez:

127.0.0.1; ls

127.0.0.1; ls

și primesc două fișiere foarte interesante:

index.php
flag.php

index.php
flag.php

index.php pare să fie fișierul principal al aplicației. Dar flag.php este evident mult mai interesant.

Înainte să citesc flag-ul, vreau să văd și codul aplicației, așa că încep cu index.php.

Citirea index.php

Folosesc din nou command injection pentru a citi conținutul fișierului.

Comanda folosită

127.0.0.1; cat index.php

127.0.0.1; cat index.php

Acum putem vedea codul PHP al aplicației.

Acest lucru ne confirmă că avem acces la fișierele de pe server și că vulnerabilitatea ne permite să executăm comenzi care pot citi conținut local.

Explicația comenzii

127.0.0.1; ->Închide comanda de ping și permite următoarea comandă

cat index.php ->Afișează conținutul fișierului index.php

Citirea flag.php

Avem acum o țintă foarte clară: flag.php.

Folosesc aceeași vulnerabilitate pentru a-i afișa conținutul.

Comanda folosită

127.0.0.1; cat flag.php

127.0.0.1; cat flag.php

Pentru a putea vedea flag-ul, trebuie să inspectăm aplicația, deoarece răspunsul căutat se află în comentarii.

Ce s-a întâmplat?

Hai să recapitulăm rapid.

Am început cu enumeration folosind dirsearch. Am găsit /server-status, dar acesta răspundea cu 200 OK și conținut gol — nimic util.

Apoi am analizat aplicația și am observat că input-ul nostru era folosit într-o comandă de sistem.

Am testat dacă putem introduce propriile comenzi folosind command separators precum ; și |. Testul a funcționat.

De aici am folosit ls pentru a vedea ce fișiere sunt disponibile și am găsit index.php și flag.php.

Am citit index.php pentru a analiza codul aplicației, iar apoi am citit flag.php și am obținut flag-ul.

Deci întregul lanț a fost:

Enumeration → Command Injection → Command Execution → File Enumeration → File Read → Flag

Concluzie

Challenge-ul Injector este un exemplu foarte bun de Command Injection.

Partea importantă nu a fost doar să găsim payload-ul, ci să observăm că input-ul nostru ajunge într-o comandă de sistem și să testăm dacă putem controla execuția acelei comenzi.

Iar odată ce am avut command execution, restul challenge-ului a devenit o problemă de enumeration și file reading.

Lecții cheie

• Niciodată să nu treci input-ul userului direct într-o comandă de sistem. Folosește funcții sigure și validare strictă.
• Command separators sunt periculoși: ;, |, &&, ||, `, $().
• Enumeration-ul continuă și după ce găsești un vuln. ls, cat, whoami, id sunt primii pași după command execution.
• dirsearch rămâne un tool esențial în orice challenge de Web Security.
• 200 OK nu înseamnă mereu ceva util — uneori e doar o pagină goală.

Video_Complet_pe_YouTube

Embedded content

Break it. Understand it. Secure it.

Writeup realizat de 3whoSec.