OTW – The grinch

adaugat in assembly, C, ctf, linux, python, reversing pe 30/12/2018

Parte din OverTheWire Advent Bonanza 2018

The grinch este un executabil linux care contine o vulnerabilitate care trebuie exploatata pentru a obtine un shell.

Dupa ce l-am dezasamblat si l-am analizat un timp am reconstruit codul sursa (probabil):

Am observat o vulnerabilitate in functia:

Cand fprintf() este apelat cu username, stack-ul arata asa:

La parametrul 5 se afla frame pointerul functiei append_formatted_to_log()
La parametrul 20 se afla adresa pentru password
Am construit urmatorul format string:

Dupa ce am obtinut controlul asupra EIP-ului am construit o secventa ROP care apeleaza mprotect() pentru a crea o zona read+write+execute, read() pentru a citi un shellcode din STDIN in acea zona, si un gadget din binar (add esp, 8 ; pop ebx ; ret) pentru a incrementa ESP-ul ca sa pot sari peste parametrii functiilor:

Rezultatul a fost un shell si deci flagul:

OTW – Elvish art

adaugat in assembly, ctf, linux, python, reversing pe 30/12/2018

Parte din OverTheWire Advent Bonanza 2018

In Elvish art am primit un executabil linux care citeste un string de 0x100000 caractere din STDIN si verifica daca fiecare caracter citit se afla in stringul:

Daca toate caracterele citite sunt acceptate atunci stringul citit este executat. In momentul executiei, EAX contine adresa stringului.

Challenge-ul este sa construiesc un shellcode doar cu caractere din acel string.

Intai am extras toate caracterele acceptate:

Am inceput apoi sa fac o lista cu toate instructiunile pe care le puteam construi cu aceste caractere si cum as putea sa le folosesc pentru a scrie un decoder care sa construiasca un shellcode arbitrar pe care sa-l execute.

Decoderul pe care l-am scris este destul de simplu:

1. intai tot shellcode-ul este umplut cu o instructiune NOP care nu afecteaza executia, am ales 0x4F ('O'), DEC EDI
2. EAX este incrementat astfel incat sa trimita undeva spre sfarsitul shellcode-ul, nu conteaza exact unde atata timp cat mai raman 30-40 de caractere pentru shellcode-ul decodat inainte de sfarsit
3. CH este setat la 1
4. pentru fiecare octet din shellcode-ul decodat se executa instructiunea 0x2828, SUB BYTE PTR [eax],ch de cate ori este nevoie pentru a ajunde de la 0x4F la valoarea din shellcode, dupa ce a ajuns la valoarea necesara se executa 0x40 INC EAX pentru a trece la octetul urmator
5. dupa ce tot shellcode-ul este decodat, executia aluneca pe NOP-uri pana la el

La inceputul executiei EAX contine adresa stringului si am observat/presupus ca AL si CH sunt 0. Shellcode-ul pe care l-am scris arata cam asa:

Bineinteles ca am scris un script care construieste shellcode-ul ca sa nu o fac eu manual:

Desi shellcode-ul nu functioneaza mereu e suficient de stabil ca din cateva incercari sa obtin flagul (banuiesc ca datorita ASLR-ului, ah, al sau ch au valori neasteptate si produc un segfault):

OTW – Cryptocow

adaugat in ctf, encryption, linux, python pe 30/12/2018

Parte din OverTheWire Advent Bonanza 2018

Mi-a placut Cryptocow pentru ca a implicat ceva criptografie si atacul “length extension” pentru SHA1 pe care nu il mai folosisem.

La http://18.205.93.120:1216 este un serviciu web care primeste un mesaj si il transforma in ASCII art:

Dupa ce am cautat putin pe google (“cow says ascii art”) am gasit aplicatia linux cowsay care primeste un text si il transforma in ASCII art-ul de pe site. Fiind un CTF am fost aproape sigur ca serviciul ia inputul din formular, il trece prin cowsay si apoi il afiseaza.

Cand formularul era trimis catre serviciu, acesta genera un URL continand doua parti hexazecimale:

Am inceput sa modific diverse parti ale URL-ului si am facut cateva observatii:

• prima parte hexa are 32 de caractere deci decodat are 16 octeti
• a doua parte hexa are 40 de caractere deci decodat are 20 octeti
• daca prima parte era “aaa” atunci serviciul afisa: “Invalid Encoding”
• daca prima parte era “aaaa” afisa: “Error while decrypting cipher text”
• daca modificam orice octet din prima parte afisa: “Invalid Padding”
• daca modificam a doua parte atunci afisa: “Message Authentication Code does not match plain text”
• pentru fiecare 16 caractere suplimentare in textul original, prima parte se marea cu inca 32 de caractere
• daca textul original era 32 de “a”-uri atunci prima parte hexa avea 3 blocuri de 32 de caractere, primele doua fiind identice
• fie ca textul era 16 “a”-uri sau 16 “b”-uri aparea un bloc suplimentar in prima parte hexa care era identic pentru ambele texte initiale

Dupa aceste observatii am tras cateva concluzii si am facut cateva predictii:

• mesajul este criptat in prima parte hexa a URL-ului
• pentru ca fiecare 16 caractere sunt criptate tot in 16, algoritmul de criptare este probabil AES 128
• pentru ca acelasi bloc de 16 caractere produce acelasi bloc criptat indiferent de pozitie, modul de criptare este ECB
• textul original era pad-uit inainte de criptare
• ultimul bloc, identic pentru texte originale de 16 caractere diferite, sugera ca paddingul era PKCS#7, blocul suplimentar fiind criptarea blocului de padding de 16 “\x10”-uri
• a doua parte a URL-ului este un MAC care protejeaza textul criptat
• pentru ca MAC-ul are 20 de octeti (40 hexa) algoritmul este probabil SHA1

Pasul urmator a fost sa incerc cateva escapari (‘ ” ` $) dar era clar ca inputul era sanitizat inainte de a fi trimis catre cowsay.

Incercand diverse texte si escapari am observat ca pentru unele caractere era necesar un text mai mic pentru a produce un bloc criptat, de exemplu un text din 16 “a”-uri produce un bloc criptat si blocul de padding gol (16 “\x10”-uri) dar e nevoie doar de 13 “a”-uri si un “$” (14 caractere in total) pentru a produce un bloc criptat si acelasi bloc de padding. Nu conta insa cate caractere speciale erau in textul original (ex: 12 “a”-uri si 2 “$” uri) tot intr-un singur bloc erau criptate. Asta mi-a sugerat ca in cazul in care textul original continea un caracter special, intreg textul era escapat cu un caracter suplimentar la inceput si la sfarsit (‘ sau “) asa textul ajungea la cele 16 caractere care erau criptate intr-un singur bloc.

Am vrut sa aflu care erau caractere speciale care produceau escaparea textului asa ca am scris un mic script care construia un text format din fiecare caracter intre 0x00 si 0xFF si gasea numarul de “a”-uri necesar pentru a forma un bloc de 16 caractere si deci aparitia blocului de padding gol in criptare. Rezultatele au fost urmatoarele:

Pentru caracterele intre 0x80 si 0xFF (neprintabile) escaparea era speciala, fiecare caracter era inlocuit cu doua caractere, si apoi se aplica escaparea obisnuita.

Modul in care am concluzionat ca functiona serviciul era:
text initial -> escapare text -> calcul MAC -> adaugare padding -> criptare -> generare URL
si in sens invers:
URL -> decriptare -> verificare MAC -> rulare cowsay -> afisare rezultat

Am considerat ca plecand de la URL, dupa decriptare, textul nu mai era escapat inca odata inainte de a fi trimis catre cowsay si deci daca as putea pune un text ne-escapat in URL as putea injecta comenzi linux cand este apelat cowsay. Puteam obtine criptarea unui bloc ne-escapat criptand un text mai lung si luand doar blocul necesar:
de exemplu:

Modul de criptare fiind ECB puteam pune pur si simplu blocul criptat in URL dar textul era protejat de MAC deci nu ar fi mers. MAC-ul este un SHA1 al unei chei secrete + text deci fara a sti cheia nu puteam genera un MAC valid.

Mi-am dat seama ca puteam folosi un atac numit “length extension” care se foloseste de o proprietate a functiilor hash pentru a calcula hash-ul mesajului original + mesaj arbitrar pornind doar de la hash-ul mesajului original.

Un hash SHA1 (40 de octeti) este format din cinci numere (de 4 octeti fiecare) reprezentand starea interna a functiei. Aceasta stare este actualizata pentru fiecare bloc de 64 de octeti din textul initial. Textul initial este de asemenea si pad-uit cu un algoritm simplu: la text se adauga 0x80 si apoi cate 0x00 sunt necesare pana ajunge la o lungime multipla de 64 – 8, ultimii 8 octeti fiind lungimea textului in biti. De exemplu pentru textul initial “aaaaa” blocul SHA1 de 64 de octeti cu padding arata asa (hex):

In acest caz atacul permite obtinerea unui MAC valid pentru un text cunoscut fara a sti cheia folosita, trebuie insa cunoscuta lungimea cheii pentru a produce paddingul corect dar mai multe lungimi pot fi testate rapid fiind necesar un singur request pentru fiecare lungime.

Ca exemplu presupun ca lungimea chei MAC este 6. Pot afla de la serviciu MAC-ul pentru textul “aaaaa”. Atunci cand serviciul genereaza MAC-ul, blocul SHA1 arata asa (?? este cheia):

Acum aveam un algoritm pe care il puteam aplica sa gasesc lungimea cheii MAC si sa injectez comenzi arbitrare dar aveam o problema cu obtinerea criptarii pentru blocurile care contineau 0x80. Caracterele mai mari de 0x80 erau escapate cu un caracter suplimentar si apareau si mai lungi in textul decriptat, 0x80 aparea ca:

Am scris un script care testa astfel lungimi ale cheii intre 1 si 32:

si rezultatul a fost:

Avand lungimea cheii puteam injecta orice mesaj ne-escapat si cu `cat flag` am obtinut flagul:

OverTheWire Advent Bonanza 2018

adaugat in ctf pe 29/12/2018

Intre 1 si 26 decembrie am participat la un CTF organizat de overthewire.org. Mi-a placut faptul ca fiind doar un challenge pe zi am avut destul de mult timp la dispozitie sa incerc sa le rezolv si in final am iesit pe locul 9 desi nu am alocat cat timp ar fi trebuit iar pe unele challenge-uri nici nu le-am inceput.

Acum ca s-a terminat o sa scriu cateva writeup-uri pentru challenge-urile care mi-au placut mai mult:

• Cryptocow – Web/crypto (200), 8 solvers
• Elvish art – Pwn (300), 12 solvers
• The grinch – Pwn (350), 7 solvers

Google CTF 2018 Crypto

adaugat in C, encryption, go, linux, python, reversing pe 02/09/2018

Dupa ce am rezolvat problemele de incepatori binenteles ca trebuie sa le fac si pe cele importante. Am inceput cu CRYPTO si le-am pus aici in ordinea punctajului nu in ordinea in care le-am facut.

PERFECT SECRECY
Primim fisierul criptat flag.txt, o cheie publica RSA key_pub.pem si sursa unei aplicatii challenge.py.
Initial am crezut ca pentru decriptarea flagului trebuie extrasa cheia privata factorizand cheia publica asa ca am incercat pe http://factordb.com/ si https://github.com/Ganapati/RsaCtfTool dar nu au functionat asa ca m-am uitat mai atent la sursa aplicatiei. Partea interesanta este:

• daca p este par atunci:
  • p + 0 % 2 = 0
  • p + 1 % 2 = 1
  • p + 2 % 2 = 0
• daca p este impar atunci:
  • p + 0 % 2 = 1
  • p + 1 % 2 = 0
  • p + 2 % 2 = 1

Cu alte cuvinte distributia valorilor de 0 si 1 in cei 100 de c generati este determinata de valoarea lui p: daca majoritatea (66%) sunt 0 atunci p este par si daca majoritatea sunt 1 atunci p este impar.
Cum valoarea lui p este determinata de dice: m0 daca dice este par si m1 daca dice este impar atunci analizand sirul de 1 si 0 generat de aplicatie putem afla daca valoarea decriptata este para sau impara. Nu pare mult dar este suficient pentru a afla intreg textul decriptat folosind un atac numit "least significant bit oracle attack": https://crypto.stackexchange.com/questions/11053/rsa-least-significant-bit-oracle-attack.
Pentru a intelege acest atac este necesara cunoasterea matematicii din spatele algoritmului RSA dar pe scurt este: valoarea textului initial trebuie sa se afle intre 0 si cheia publica (n) dar folosind oracolul de mai sus, intervalul in care se poate afla textul initial este restrans prin decriptari succesive ale valorii criptate ridicata la puteri ale lui 2 pana cand dupa 1024 de tentative se obtine o singura valoare posibila pentru textul decriptat.
Atacul pus in practica:

DM COLLISION
In acest challenge am primit un algoritm similar cu DES si trebuie sa gasim doua tipuri de coliziuni: in prima trebuie gasite doua perechi diferite cheie + text care sa genereze acelasi rezultat si in a doua trebuie gasita o pereche cheie/text astfel incat criptarea sa genereze tot textul initial, DESEncrypt(inp, key) == inp deci Xor(DESEncrypt(inp, key), inp) == 0
Prima coliziune nu a fost foarte dificila. Desi algoritmul nu este chiar DES, este foarte similar avand aceeasi cheie de 56 de biti si primim si indiciul:

A doua coliziune a fost mai dificil de gasit.
Un plaintext care ramane neschimbat de procesul de criptare se numeste "fixed point" si cautand putin despre fixed points in DES am gasit cateva informatii intersante despre chei slabe si fixed-pointurile pe care le produc.
Astfel pentru fiecare din cele patru chei slabe din DES exista 2³² fixed-pointuri, adica 1 din 2³².
Nu am gasit alta metoda sa obtin un fixed point pentru algoritmul dat decat forta bruta asa ca am folosit codul din not_des.py pentru a cripta valori aleatoare in speranta ca voi gasi un fixed point. Din pacate python-ul a fost prea lent pentru asta, facea doar vreo 300 de criptari pe secunda deci 2³² de criptari ar fi durat cam jumatate de an.
Am incercat sa gasesc care sunt diferentele intre algoritmul dat si DES si am observat sa S-Boxurile sunt in alta ordine:

BETTER ZIP
Primim o arhiva parolata flag.zip care contine flag.png si codul care a generat arhiva. Fisierul flag.png este criptat folosind un algoritm bazat pe opt LSFR-uri de 20 de biti. Algoritmul genereaza aleator doua stringuri de 20 de octeti (160 de biti) key_iv si cipher_iv care sunt incluse in arhiva. Fiecare 20 de biti din key_iv, cipher_iv si parola arhivei (key) corespund unuia din cele 8 LSFR-uri (20 * 8 = 160). cipher_iv reprezinta starea initiala a LSFR-ului si key_iv ^ key reprezinta polinomialul care determina modul in care evolueaza LSFR-ul. La fiecare pas, un LSFR va produce cel mai important bit (MSB, bitul de la 2¹⁹) ca output, toata valoarea este shiftata cu un octet catre stanga si polinomialul va determina noul cel mai putin important bit (LSB, bitul de la 2⁰). Cei 8 biti produsi de cele 8 LSFR-uri sunt combinati intr-un octet care este XOR-uit cu plaintextul pentru a genera ciphertextul.
Pentru ca primii 20 de biti care ies dintr-un LSFR sunt determinati doar de cipher_iv, pe care il cunoastem, inseamna ca putem decripta primii 20 de octeti din flag.png:

MITM
Avem un script Python care poate functiona fie in modul server fie in modul client. O instanta care ruleaza ca server poate comunica cu una care ruleaza ca si client, vor folosi curve25519 pentru ca obtine un secret comun si apoi se vor autentifica una fata de cealalta generand un proof bazat pe secretul comun si o parola interna. Odata autentificat, un client poate trimite comenzi catre server. Una dintre comenzi este "getflag" deci este clar ca pentru a obtine flagul trebuie sa ne autentificam la server ca un client real si sa trimitem acea comanda. Procesul de autentificare este urmatorul:

DOGESTORE
Avem o aplicatie cu o parte din codul sursa scris in Rust si un text criptat. Din fericire nu trebuie sa sti Rust ca sa intelegi ce face aplicatia: citeste 112 octeti pe care ii decripteaza cu AES256 in modul CTR. Textul decriptat este interpretat ca perechi [letter, size] unde size + 1 va numarul de aparitii al letter (similar cu RLE). Textul serializat este extins si perechile [letter, size] sunt inlocuite cu letter de size + 1 ori. Rezultatului i se calculeaza hash-ul SHA-3 care este afisat.
Un exemplu de serializare este: