SOLUZIONE Hacking Contest Spring Break Seeweb

 

black resurrection

Siamo lieti di presentarvi la nostra soluzione della seconda edizione dell’hacking contest di Seeweb. Purtroppo a causa dell’apertura del nostro ufficio non abbiamo avuto modo di partecipare in modo costante, ma abbiamo deciso di rendervi partecipi dei nostri passaggi.

A differenza della precedente edizione questa volta era richiesta una registrazione per ricevere un indirizzo IP da cui iniziare le analisi.

Siamo quindi partiti con una scansione di tutte le porte TCP e dei servizi utilizzando Nmap.

La porta 65533 ha da subito colpito la nostra attenzione, anche per l’assenza di credenziali in nostro possesso per collegarci via ssh.

Provando a collegarsi via Telnet veniva mostrato un menu che sembrava permettere lo svolgimento di diverse azioni.

telnet 212.25.162.134 65533

telnet

La quasi totalità delle opzioni non permettevano di fare nulla, abbiamo quindi pensato di provare a fare un po’ di fuzzing, il quale ci ha generato un (crediamo) finto Buffer Overflow, facendo crashare il programma e portandoci a una nuova schermata.

Questa nuova schermata ci proponeva nuovamente diverse opzioni, la maggior parte delle quali inutilizzabili, una delle quali raccoglieva i log dei tentativi d’accesso al server via SSH e nel caso fossero tentativi falliti registrava lo username. Uno di questi tentavi aveva registrato un’immissione erronea dell’utente kermit della password come username.

SSH login credential

A questo punto non rimaneva che collegarsi con le credenziali ottenute via SSH.

ssh kermit@212.25.162.134 -p 65534   FTcc..sb1

SSH connection

 

Nella home dell’utente kermit si potevano trovare 3 file:

  • msg: contente un messaggio cifrato
  • map: contenente la mappa di cifratura del messaggio
  • next_target.zip: file zip protetto da password

Per decifrare il messaggio era necessario utilizzare i numeri come coordinate della mappa, così da trovare le lettere corrispondenti. La particolarità della cifratura risiedeva nel fatto che i numeri erano da considerare a coppie solo ed esclusivamente se il primo dei due numeri fosse stato un 5 o un 8.

Il messaggio decriptato per intero ci proponeva la password del file zip e quest’ultimo conteneva il secondo target.

Dopo esserci collegati via SSH al secondo server come utente public abbiamo visto il file antigene_sbc nella cartella home di monday, ma non avevamo i permessi di lettura, serviva quindi una privilege escalation.

Cercando gli eseguibili SUID abbiamo notato gmanager in /usr/bin, il quale poteva essere eseguito da public, ma girava come root. Analizzando il binario con strace si poteva notare che se lanciato con il flag s provava ad aprire il file ./lastlog dopo aver controllato i permessi di lettura dell’utente che aveva avviato gmanager e effettuato una pausa di 2 secondi.

Riassumendo:

  1. Controllo permessi di lettura del file ./lastlog  da parte di public (se symlink controllava i permessi sul file destinatario del symlink)
  2. Pausa 2 secondi
  3. Apertura del file ./lastlog come root e scrittura a schermo del suo contenuto

Questa procedura risultava exploitabile sostituendo il file ./lastlog nei due secondi di pausa con un semplice script come questo.

Dove lastlog era un symlink a /home/monday/antigene_sbc, lastlog1 un file di passaggio e lastlog2 un file leggibile da public. In questo modo i file venivano ruotati in modo costante, sostituendo di fatto il file leggibile con il symlink e permettendone la visualizzazione a schermo.

Collegandoci via SSH al terzo server si poteva notare che il file da leggere era di proprietà dell’utente proxy, quindi serviva nuovamente una privilege escalation.

Una cosa che da subito colpiva era la presenza di una cartella /develop contenente diverse sottocartelle con alcuni file sorgenti, una delle quali aveva una data di creazione diversa dalle altre: context_switch.

Purtroppo come anticipato non abbiamo avuto abbastanza tempo per poter completare questo ultimo step, ma siamo lieti di lasciarvi alcuni link a soluzioni di altri partecipanti:

Speriamo di ricevere le vostre soluzioni così da poterci confrontare!

Ringraziamo Seeweb per l’ottimo contest e facciamo i nostri complimenti ai 3 finalisti che verranno annunciati sulla pagina di Facebook di Seeweb.

Abdel Adim Oisfi

Sono Abdel Adim Oisfi, conosciuto nella rete come "smaury". Lavoro: Co-CEO, Security Researcher, Web Developer, Penetration Tester presso Shielder Srl. Passioni: Hacking, Autostop, Tuffi e Ginocchia Sbucciate.