Hacknite Wiki

Naši kolačići koriste najnovije sigurnosne tehnologije

http://chal.platforma.hacknite.hr:14003

Uz zadatak je dan i izvorni kod.

Stranica ima samo Register/Login i stranicu kojoj se pristupa nakon što se ulogira s korisnikom, a koja ispisuje samo pozdrav.

Pregledom source koda vidi se da postoji Dockerfile u kojem je definirana ENV flag varijabla, ali nema ništa što na prvi pogled pokazuje ranjivost.

Osim Dockerfilea, jedini drugi izvorni kod je server.js, u kojem se nalazi sav kod koji pokreće stranicu.

Pri analizi koda vidi se da je adminov username “administrator0”:

const ADMIN_NAME = 'administrator0';

Također se vidi da stranica koristi secret varijablu koja je sastavljena od 22 nasumična bajta, generirana pomoću crypto.randomBytes modula, što znači da bi trebala biti sigurna.

Također, FLAG je definiran kao varijabla.

Nakon toga slijedi inicijalizacija baze podataka.

U inicijalizaciji baze podataka vidi se da svaki korisnik ima ID, username, password, token, *isAdmin* varijablu (koja je po defaultu 0) te vrijeme kada je korisnik stvoren.

Također se vidi da se administratorski korisnik postavlja s vrijednošću 1 za isAdmin.

Ključan dio koda je način na koji se generira token.

Token se generira kao string koji se sastoji od *secret* varijable, usernamea i ID-a korisnika, a zatim se ubacuje u bcrypt.hash funkciju, koristeći i BCRYPT_SALT.

BCRYPT_SALT varijabla se generira u initializeAuth funkciji koja se poziva samo jednom pri pokretanju servera. To znači da će ta varijabla biti ista tijekom cijelog životnog vijeka aplikacije.

Nadalje, u administratorskom tokenu nalazi se i adminId, koji se generira pomoću sljedećih linija koda:

17. linija koda:
const UUID_NAMESPACE = '1b671a64-40d5-491e-99b0-da01ff1f3341';

54. linija koda:
const adminId = uuidv5(ADMIN_NAME, UUID_NAMESPACE);

Funkcija uuidv5 je deterministička — za isti par username i namespace svaki put će generirati isti UUID.

To znači da u generaciji administratorskog tokena (slika 3) od tri varijable — secret, ADMIN_NAME i adminId — poznajemo ADMIN_NAME (“administrator0”) i možemo lokalno rekreirati isti adminId kao onaj koji koristi aplikacija.

Budući da su i secret i BCRYPT_SALT varijable konstante dok aplikacija radi, token administratora uvijek se računa na isti način.

Ključna činjenica zadatka temelji se na ponašanju funkcije:

bcrypt.hash

Naime, bcrypt.hash uzima samo prvih 72 znaka danih kao ulaz i iz njih generira sažetak, dok sve znakove nakon 72. odbacuje. Zato dva unosa s istih prvih 72 znaka daju isti hash, bez obzira na razlike iza 72. znaka.

Pregledom tokenString varijable, koja se ubacuje u bcrypt.hash i generira administratorski token, vidi se njezina duljina.

Varijabla se sastoji od tri stringa: secret, ADMIN_NAME i adminId.

- secret = 22 znaka - ADMIN_NAME = 14 znakova (“administrator0”) - adminId = 36 znakova (UUID)

Zbrajanjem 22 + 14 + 36 dobiva se 72, što je točno broj znakova koje bcrypt.hash uzima u obzir.

—

Sada pogledajmo kako se generira token pri stvaranju novog korisnika, što se događa u “/register” endpointu.

Može se vidjeti da se token za novog korisnika generira na isti način kao i administratorski token.

Koristi se ista secret varijabla i ista BCRYPT_SALT vrijednost kao i kod generiranja administratorskog tokena.

Jedine dvije različite vrijednosti su username i userId.

Na userId nemamo utjecaj, ali username možemo kontrolirati.

Budući da je secret duljine 22, a bcrypt.hash uzima samo prvih 72 znaka, ako unesemo username duljine 50, on će “istisnuti” *userId* iz dijela koji bcrypt.hash koristi. To znači da userId uopće neće ući u generiranje korisničkog tokena.

Na taj način imamo potpunu kontrolu nad 50 znakova (nakon secret), koji će sudjelovati u generiranju tokena.

Pošto su secret i BCRYPT_SALT isti pri generiranju oba tokena (admin i user), ako uspijemo manipulirati tih 50 znakova da budu isti kao kod administratora, dobit ćemo identičan token.

Da bi to bilo moguće, mora vrijediti:

naš_username = admin_username + adminId

Vrijednosti admin_username i adminId su poznate ili se mogu rekonstruirati.

—

Preostaje pokrenuti aplikaciju lokalno kako bismo saznali *adminId* i napravili korisnika s odgovarajućim imenom.

Možemo dodati liniju koda koja će ispisati adminId:

Pokretanjem programa naredbom:

node server.js

vidjet ćemo adminId, koji će biti isti kao i na produkcijskom serveru.

a1653d44-7862-5db2-b60a-afce3f20ed74

Sada znamo sve potrebne informacije za generiranje istog tokena kao administrator.

Analizom token middleware funkcije vidi se kako se koristi token:

Middleware dohvaća token iz kolačića, traži prvog korisnika u bazi s tim tokenom i postavlja sesiju kao tog korisnika.

Pošto se uzima prvi user u bazi, a administrator je uvijek prvi kreirani korisnik, bilo koji kasniji korisnik s istim tokenom automatski postaje administrator.

—

Dakle, rješenje je kreirati novog korisnika s usernameom:

administrator0a1653d44-7862-5db2-b60a-afce3f20ed74

Možemo dodati još nekoliko znakova na kraj (koji ionako neće ući u prvih 72 znaka bcrypt.hash funkcije) da izbjegnemo grešku ako korisničko ime već postoji.

Dakle, svaki korisnik s usernameom oblika:

administrator0a1653d44-7862-5db2-b60a-afce3f20ed74<bilo_koji_znakovi>

imat će isti token kao administrator.

—

Pri pokušaju logina vidi se da postoji ograničenje maksimalnog broja znakova u korisničkom imenu (14 znakova), što bi onemogućilo ovu tehniku.

No to ograničenje nije implementirano na serverskoj strani, nego samo u HTML kodu (klijentskoj strani), pa se lako može zaobići — brisanjem dijela HTML-a prikazanog na slici 11. ili korištenjem *BurpSuite* alata.

Sada se može stvoriti korisnički račun koji će imati isti token kao administrator, što je prikazano na slici 12.