FRA Pentest Challenge 2013

Här kommmer en genomgång av alla flaggor jag lyckats låsa upp i FRA:s pentest challende 2013. Jag har sett i google-sökningar att det redan ligger lösningar ute för denna ctf, så jag är absolut inte först ute. Tre flaggor lyckades jag inte låsa upp innan jag gav upp (för stunden) och skrev detta inlägg.

Vm-et bootade i min installation av VirtualBox, men det var en massa felloggar, så jag anslöt vmdk-filen som en extra hårddisk till min Kali-installation i stället.

Jag började titta i /root. Där finns en katalog med tolv gpg-krypterade filer, Flag01 till Flag12, och en pdf med instruktioner.

/root/collected är en pcap-fil. Här hittade jag ett sip-samtal som Wireshark kunde spela upp. Detta låser upp Flag08

/root/127.0.0.1.pwdump Denna öppnade jag i johnny och fick reda på att User Dom har lösenord: TORONTOTORONTO Eftersom detta är den svaga LM-hashen vet jag egentligen inte vilken casing det är på bokstäverna och jag vet faktiskt inte om jag kan låsa upp något med lösenordet. Det finns säkert nå’t bra sätt att klura ut lösenordet från hashen, men jag testar att skriva ett litet program som försöker låsa upp alla flaggfiler med alla varianter av casing på lösenordet. Ingen av flaggorna låstes upp med det scriptet.

Dags att testa det på bcrypt-filen i Dom’s hemmakatalog. Genom att testa bcrypt med alla case-varianter av lösenordet lyckades jag låsa upp network_stuff.zip lösenordet var tOroNTotOroNTo

Zippen innehåller nå’n slags nätverkskonfiguration, brandvägg? samt en pcap-fil.

.config-filen innehåller två lösenord en typ 5 och en typ 7 för dessa hittade jag javascript-crackers på nätet 5: https://www.ifm.net.nz/cookbooks/cisco-ios-enable-secret-password-cracker.html 7: https://www.ifm.net.nz/cookbooks/passwordcracker.html Jag antar sålunda att filen är konfiguration till en burk från Cisco.

Sjuan gav ett lösenord som låste upp Flag09, femman orkade jag inte vänta på.

captured.pcap innehöll bla. en ftp-inloggning: ariadne / MyS4meOldPwd ariadnes lösenord decrypterade images.tar.bfe i hennes hemmakatalog. Strings på tar filen innehåll bla VGhlLUhvdXJHMWFTUwo= som jag misstänker är en base64 enkodning. Det blev ett lösenord som låser upp Flag03

I /home/eames finns gesture.key Efter lite googlande tror jag att det är mönstret för att låsa upp en android-telefon och jag hittade lite python-kod som knäcker den: Koden är 647583210, men det låste inte upp någon flagga. Efter lite klurande tänker jag att man ska plussa på ett på alla siffror i koden. Om en människa använder sitt telefonmönster för att komma ihåg siffror börjar hen säker räkna från ett, inte noll. Detta låser upp Flag06

https://github.com/sch3m4/androidpatternlock

I /root/.bash_history hittade jag detta: /bin/rm -f /root/my-secret-password-file-containing-q51wx23-account.txt

Jag försökte använda extundelete för att få fram filen, men det gick inte så jag packade upp en ny vmdk-fil från zip-arkivet och öppnade den i bliss för att söka på q51wx23. Hittade : User: q51wx23 och dess lösenord.

Detta låste upp Flag10

I /root/flags/Readme.pdf finns lite javascript med ett caesar-chiffer. Jag skrev några rader python för att skriva ut klartexten

chs = "abcdefghijklmnopqrstuvwxyz0123456789"
caesar = [ 3, 17, 12, 18, 3, 17, 12, 18, 28, 29, 26, 31 ]
result = ""
for c in caesar:
    result += chs[c]

print(result) 

Detta låste upp Flag01

/home/mal/crackme

Det här blev ett knepigt problem. Strings på filen visade ZKFQKT och thiswaseasy som intressanta strängar, men jag hittade inget uppenbart sätt att xor’a dem för att få fram något som verkade vara det riktiga lösenordet. Jag tog ut assemblykoden och blev egentligen inte mycket klokare. Efter lite meck hittade jag en site på nätet som kunde aproximera c-kod från assemblykoden. Det gav mig i alla fall lite bekräftelse på att det var en xor-operation med ‘thiswaseasy’ som var lösningen på problemet. Lösningen dök upp när jag öppnade binärfilen med binary-ninja och uppmärksammades på att den sträng man jämför med innehåller x00. Detta gjorde asm -> c-konverteraren förvirrad och sade att jämförelsesträngen slutade vid nollan, men i själva verket fortsatte den lite till. ‘ZKFQKT’ var en del av strängen det skulle jämföras mot, så jag var inte helt fel ute.

Hittade lösenordet som låser upp flagga 4.

/home/saito cookie

Tyder på att det finns en web-applikation som heter dreams i systemet. Det visade sig vara en php-applikation i /opt/apache/2.2.22/dreams Källkoden ser ofarlig ut så jag försöker få igång applikationen i en miljö där jag kan debugga och använa en proxy.

Jag körde siten genom ZAP och skrev in cookien som jag hittade på disken, så kom jag in. Väl inne fanns det en länk för att visa den inloggade användarens lösenord. Det lösenordet låser upp flagga 11.

Det finns två rader med krypterat data i user-tabellen i Sqlite-databasen till dream-siten, så jag misstänker att man kan göra något med krypteringsalgon som används för att få ut dem. Det kanske låser uppp en flagga till.

Jag vred och vände på javascriptkoden som skapade nyckeln för att dekryptera värdena i databasen. Först konstaterade jag att ‘challenge’ från servern gick att ignorera helt och hållet, så den satte jag till 15 0x00. På så sätt spelade xor-operationerna ut sin roll. Éfter ytterligare experimenterande och förenklande såg jag att det bara är var fjärde tecken från lösenordet som påverkar nyckeln. Dessutom görs and och or så att det räcker med att de sista fyra bitarna i respektive tecken är 1100 (15 dec). Det gjorde alfabetet tillräckligt litet för att kunna loopa genom alla varianter av lösenordet från 1 till 17 tecken. Jag bekräftade mitt bruteforce-hack med saito och till slut fick jag träff med 16 olika lösenord. Jag hade sålunda kunnat få ner tiden lite till om jag klurat lite, men det hade säkert tagit längre tid än det till sist tog att köra koden. I alter_egos tabellen finns, förutom saito, en användare som heter Dom. Efter några minuters testande fick jag fram lösenordet som låser upp flagga nr 12.

Här är alla flaggor och lösenord jag hittat än så länge: