Incipit

L’articolo tratta la terza e ultima parte della CTF Necromancer, tenuta come lezione all’Università di Perugia in occasione dell’evento CyberChallenge.

Prima Parte:  https://www.ictsecuritymagazine.com/articoli/a-case-history-ctf-necromancer-parte-1/.
Seconda Parte:  https://www.ictsecuritymagazine.com/articoli/a-case-history-ctf-necromancer-parte-2/

Nella tetra penombra della grotta, con il nostro talismano al collo ed uno sciame di pipistrelli, ormai riverso e orrendamente mutilato sul freddo pavimento, avevamo volto lo sguardo verso il soffitto della grotta, scorgendo la scritta impressa col sangue: thenecromancerwillabsorbyoursoul/.

FLAG – 06.

Probabilmente si trattava di un’altra pagina URL, come ne avevo già trovate in precedenza. Un altro percorso all’interno dell’URL.

Quindi, aprii il mio browser ed inserii il percorso nella barra degli indirizzi, per rivelare la FLAG 06:

192.168.178.37/thenecromancerwillabsorbyoursoul/

Figura 36

FLAG – 07.

Ancora una porta: u161 . La “u”, come già era accaduto, identificava lo User Datagram Protocol (UDP), che avevamo trovato per la prima volta durante la FLAG 02, nella prima parte del Necromancer.

Una delle caratteristiche delle porte di rete è che convenzionalmente indentificano una particolare connessione attiva sulla macchina. Così, ad esempio, la porta 25 viene utilizzata per i servizi di posta SMTP, la porta 80 per l’http, 22 l’ SSH , la 21 per l’FTP e così via.

La nostra porta 161 / UDP, viene utilizzata per il protocollo noto come Simple Network Management Protocol (SNMP). Si tratta di un protocollo studiato per la gestione elementare di un determinato dispositivo di rete, come ad esempio un telefono, una stampante, un router, un PC, etc.

L’architettura del SNMP è basata su un modello client-server: i server vengono chiamati manager; gli altri dispositivi o componenti che si possono interfacciare con la rete, sono gli agent.

L’ SNMP utilizza un modello “ad albero” per lo scambio di dati: i “rami” dell’ “albero” sono delle tabelle che prendono il nome di Management Information Bases (MIB). All’interno di ogni MIB si trovano le “foglie”, chiamate nodi, che rappresentano i dispositivi o i componenti connessi alla rete.

Per identificare univocamente un nodo e quindi un dispositivo connesso, si utilizza un Object Identifier (OID).

L’OID è composto da: il numero (o la stringa) che identifica il MIB + un numero (o una stringa) che identifica un dato device (ad esempio: 1.3.6.1.4.234.2.4.1.2.1.1.1.3.1234.3).

Gli agent che ricevono la richiesta di fornire informazioni, prima di rispondere, si assicurano che il richiedente abbia i permessi per effettuare tale richiesta. Nelle versioni SNMP 1 e 2, la prassi è che il manager si presenta all’agent, specificando un “nome della comunità”, ovvero il “community name”.

Ciò che mi mancava era proprio il community name, il mio tesserino d’identificazione per presentarmi via SNMP al mio agent e dirgli: “Eccomi! Sono autorizzato a ricevere o inviare informazioni!”

Accantonai quindi per un attimo la mia porta 161 e tornai a dedicarmi alla pagina web che stavo esplorando. La scritta “necromancer!”, così sottolineata [Figura 36], era un chiaro richiamo. Quindi, decisi di cliccarla. Apparve una finestra che mi chiedeva di scaricare un file d’archivio denominato: “necromancer”. [Figura 37].

Figura 37

Utilizzai il comando tar per estrarre l’archivio:

Figura 38

• tar: comando
• x : per estrarre i file da un archivio
• j : compressione attraverso bzip2
• v  : verbose (per aggiungere più informazioni all’output del comando, mostrando l’elaborazione)
• f :nome del file archivio
• necromancer : il nome d’archivio da cui volevamo procedere all’estrazione

Il risultato dell’estrazione fu un file Packet Capture (cap file) [Figura 38], denominato necromancer. Uno dei modi in cui è possibile aprire questo tipo di file, è utilizzando Wireshark.

Figura 39

Digitando wireshark necromancer.cap [Figura 39] mi apparve il risultato dello sniffing del traffico Wireless 802.11.

Solitamente, uno dei modi per craccare una rete WiFi protetta con il protocollo WPA/WPA2, è quello di mettersi in “modalità ascolto” attraverso la scheda wireless per individuare la rete bersaglio, quindi il MAC del router e il canale radio utilizzato. A questo punto, si monitora la rete target sino a quando un dispositivo non si connette ad essa ed esegue l’“handshake”. Dopodiché sarà sufficiente salvare il file .cap, convertirlo e craccarlo (utilizzando hashcat, ad esempio).

Il file necromancer.cap trovato, doveva essere il risultato di un’ultima fase di cattura dell’handshake di un’ipotetica rete wireless. Non dovevo far altro che convertirlo nel formato hccapx e successivamente craccarlo.

hccapx è un particolare formato di file sviluppato appositamente per il programma hashcat e utilizzato per hash di tipologia WPA/WPA2. Al fine di generare il file con la data estensione, si utilizza il tool cap2hccapx, scaricabile al seguente indirizzo: https://hashcat.net/wiki/doku.php?id=hashcat_utils

Per la conversione fu sufficiente eseguire il comando:

• cap2hccapx : utility di conversione
• cap  : file .cap da convertire
• hccapx  : risultato della conversione desiderato (nomefile.hccapx)

Non rimaneva altro da fare che trovare la nostra chiave, utilizzando hashcat. Per farlo, bastò procedere come avevo fatto per l’hash trovato alla FLAG02 [Figura 9]. L’unica differenza, era rappresentata dal parametro d’identificazione del hash –m . Poiché non avrei craccato un hash MD5 ma una chiave WPA, il parametro da specificare sarebbe stato –m 2500.

Dato invio, furono sufficienti pochi secondi per decriptare la chiave: death2all

Nota: Un altro modo per estrarre la chiave, sarebbe stato quello di utilizzare: aicrack-ng

• aircrack-ng : comando
• cap  : file .cap da craccare
• -w : parametro per specificare lawordlist
• /usr/share/wordlist/rockyou.txt : wordlist utilizzata

Finalmente, avevo il nostro community name. Ora avrei potuto utilizzare metasploit per l’enumeration e vedere cosa sarebbe accaduto.

La prima cosa che feci fu avviare la metasploit tramite il comando msfconsole:

Selezionai il modulo da lanciare:

• use : comando di selezione del modulo
• auxiliary/scanner/snmp/snmp_enum : percorso del modulo

Per utilizzare il modulo, adattandolo ai miei scopi, avrei dovuto settare esattamente due opzioni prima di lanciarlo:

1. I’IP bersaglio
2. Il Community Name

1° Opzione:

• set : inserisci
• RHOSTS : parametro per specificare l’host remoto (la macchina bersaglio)
• 168.178.37 : IP bersaglio (la macchina Virtuale della CTF Necromancer)

2° Opzione:

• set : inserisci
• COMMUNITY: il parametro per il community name
• death2all : il Community Name che avevo appena trovato.

Infine, lo lanciai: run

Figura 40

C’ero quasi, il community name trovato (death2all) mi aveva permesso di autenticarmi nella procedura prevista dal protocollo SNMP. Ora, dovevo aprire la porta. Ciò che non sapevo era “dove” si trovasse questa porta. Lasciai in standby il terminale di metasploit e ne aprii un altro.

Abbiamo detto che all’interno della struttura SNMP ogni OID è composto da: il numero (o la stringa) che identifica il MIB + un numero (o una stringa) che identifica un dato device. (Ad esempio: 1.3.6.1.4.234.2.4.1.2.1.1.1.3.1234.3). La domanda da porsi era quindi: qual è l’OID della porta di “death2allrw!”?

Il tool snmpwalk faceva al caso mio. Esso, infatti, permette di enumerare tutti i device SNMP.

• snmpwalk : comando
• -c : opzioni per specificare la Community String
• death2allrw : il nome della community string che avevo trovato [Figura 40]
• -v : opzione per specificare la versione del SNMP in uso
• 1 : versione in uso
• 168.178.37 : IP della VM Necromante
• | : operatore pipe
• grep: estrai solo…
• death2all : la riga che contiene

Avevo così ottenuto il mio OID: iso.3.6.1.2.1.1.6.0. Ed il valore della stringa era: STRING: “Locked – death2allrw!”

Adesso, non dovevo far altro che aprire la porta. Per farlo, mi servii di un altro tool: snmpset

• snmpset : comando utilizzato per modificare le informazioni nell’host remoto
• -v : opzione per specificare la versione del SNMP in uso
• 2c : versione SNMP in uso
• -c : community string
• death2allrw : la mia community string
• 168.178.37 : IP della VM Necromante
• 3.6.1.2.1.1.6.0 : Primo Valore dell’OID, più…
• string: opzione per specificare la stringa
• “Unlocked – death2allrw!”: …il nuovo valore della stringa da sostituire al vecchio

Questa volta, quando tornai sul terminale di metasploit e rilanciai il modulo di snmp_enum, il risultato fu la FLAG07! [Figura 41]

Figura 41

Craccai l’hash, come fatto sino ad ora, e il risultato fu: demonslayer

FLAG – 08.

Come accaduto in precedenza, assieme all’hash della flag ottenni anche un altro indizio: t22 [Figura 41]. La porta 22 è “celebre” per il suo protocollo di Secure SHell (SSH) che permette di stabilire una sessione remota, cifrata, con un altro host.

Provai quindi a connettermi al Necromante via ssh, utilizzando il risultato dell’hash craccato (della FLAG07) come username:

Il primo impulso fu quello di provare a inserire come password “Necromancer”, ma fu tentativo a vuoto. Dovevo brut-forzare il protocollo ssh. Decisi quindi di utilizzare hydra, un tool che permette di effettuare attacchi brute-force a vari servizi, come: ftp, ssh, MY-SQL, etc…

Figura 42

• hydra : comando utilizzato per richiamare il tool
• -s : porta
• 22 : il numero della porta ssh
• -l : username con il quale si tenta il login
• demonslayer : il mio username, ottenuto dall’hash della FLAG07
• -P : parametro per specificare la wordlist
• /usr/share/wordlists/rockyou.txt : percorso della mia wordlist “rockyou.txt”
• 168.178.37: l’host target (l’indirizzo IP del Necromancer)
• “ssh”: il protocollo da attaccare

Ci vollero circa dieci secondi prima che hydra trovasse la password: 12345678. [Figura 42]

Nota: sarebbe stato possibile eseguire lo stesso attacco utilizzando metasploit:
auxiliary/scanner/ssh/ssh_login

Ora, non mi rimaneva che addentrami nel covo del Necromante per fronteggiarlo.

• ssh : richiesta di connessione al protocollo
• demonslayer : nome utente
• @192.168.178.37 : connessione verso l’indirizzo IP della macchina

Alla richiesta della password per l’utente demonslayer, digitai quella che avevo appena trovato: 12345678. [Figura 42]

Ero dentro! Mi trovavo sulla directory home dell’utente demonslayer. Diedi subito un’occhiata, listando il contenuto della folder con il comando ls. Apparve un file di testo: flag8.txt . Il comando cat mi rivelò il contenuto:

Eravamo giunti alla resa dei conti.
Un’altra porta UDP, la 777. Questa volta non sarebbe servito l’IP della macchina remota, poiché eravamo già connessi tramite SSH alla macchina target. Il parametro fu localhost ed il numero della porta.

 L’ultima frase suonava come un indovinello: “Where do the Black Robes practice magic of the Greater Path?”. Ottenni la riposta da Google: “Kelewan”. E con essa, la flag numero 8.

FLAG – 09, 10

Le FLAG 09 e 10, richiesero anch’esse svariati minuti di ricerca attraverso Google. Ma, alla fine, ottenni le risposte alle due domande [Figura 43]:

“Who did Johann Faust VIII make a deal with?” “Mephistopheles”

“Who is tricked into passing the Ninth Gate?”  “Hedge”

Figura 43

FLAG – 11

Non appena ottenni la FLAG10 [Figura 43], rispondendo all’ultima delle tre domande, apparve il seguito:

Diedi qualche invio e il cursore tornò a lampeggiare sullo schermo. Decisi di cercare la “piccola fiala sul terreno”, come riportava l’indizio. Utilizzai il comando ls –ll per listare a video tutti i file, ma il risultato fu analogo a quello già ottenuto: mi apparve il file flag8.txt.

La fiala doveva essere proprio lì sotto i miei occhi, ma nascosta. Provai con ls –al e questa volta la vidi!

La chiave era il parametro del comando –a. Convenzionalmente, quando si lista il contenuto di una directory, i file e le directory che iniziano con “.” non vengono mostrati, a meno che non si utilizzi il parametro –a .

• ls : lista il contenuto
• -a : visualizza anche i file o le directory che iniziano con “.”
• l : visualizzazione come elenco, indicando anche altri parametri (permessi, gruppi, proprietario, etc…)

“Raccolsi” quindi la fiala, utilizzando il comando cat.

Quale privilegio più alto, se non quello di avere permessi sudo?

Utilizzando sudo –l listai i privilegi che avevo come utente. Ergo, verificai dove avevo i permessi “sudo”.

I permessi “sudo”, e quindi di livello più alto (solitamente appartenenti all’utente “root”), mi erano concessi solamente sul comando “cat” al fine di listare il contenuto dell’ultima flag11.txt, locata al percorso /root/flag11.txt .

Così, “trattenni il fiato”, utilizzai il comando sudo per l’ultima “invocazione”: sudo cat /root/flag11.txt

 Lascio a voi il cracking della FLAG11…

Colgo l’occasione per ringraziare i Proff. Stefano Bistarelli e Francesco Santini dell’Università di Perugia, per aver organizzato e reso possibile questa giornata, lo sponsor DiGiOne per la disponibilità e aver fornito gli strumenti necessari e naturalmente tutto il mio team di Cyber Division per la collaborazione e il supporto.

Articolo a cura di Vincenzo Digilio

Ha lavorato come Network System Administrator, Security Auditor, System Integrator, Penetration Tester per importanti client, enti governativi ed agenzie spaziali. Seguendo progetti come calcolo distribuito, security resource implementation in aree nuclearizzate, adeguamenti di security policy e Security Engineering per la selezione d’importanti fornitori al fine d’implementare sistemi di sicurezza per diverse Multinazionali. Ha tenuto corsi di tecniche Hacking, studiando in contemporanea per il corso di Laurea in Sicurezza delle reti Informatiche. È attualmente impiegato in progetti classificitati in ambito spaziale di Cyber Sicurezza; nella ricerca di vulnerabilità, sviluppo di exploit e whitebox / black box Penetration Testing. Coordina, inoltre il RedTeam della società’ Cyber Division di cui e’ uno dei fondatori. È consulente in materia di Global Security Policy Statement, Risk management e Data Breach Investigation. È intervenuto in diversi casi di compromissione dati, analisi forensi, system breach e attacchi hacking al fine di mitigare la situazione. Crede nella libertà d’informazione e nel diritto alla privacy.

https://cyberdivision.net/

https://www.linkedin.com/in/vincenzo-digilio/

https://www.ictsecuritymagazine.com/articoli/a-case-history-ctf-necromancer-parte-3/