Glossario di base

I tempi delle indagini preliminari al penetration test sono ormai un lontano ricordo.

Se è vero che nelle prime puntate di questa serie abbiamo esaminato “senza toccare” la nostra “palestra per pentester” [figura 1] costruita mediante ricorso alla virtualizzazione (vedi il box “Configurazione dell’ambiente di test”), nell’ultimo articolo ci siamo lanciati all’attacco delle vulnerabilità presenti in uno dei servizi in esecuzione sul web server della rete. Privi di ogni preoccupazione in merito alle possibili conseguenze legali delle nostre azioni (vedi al riguardo il box “Tre anni di galera”), visto che siamo noi stessi i proprietari della nostra “palestra” virtuale, abbiamo individuato gravi vulnerabilità che affliggono il servizio FTP offerto dal server web, e che ci hanno consentito di ottenere un accesso di root sulla suddetta macchina.

Come tuttavia abbiamo già avuto modo di chiarire, un tale risultato, per quanto particolarmente prezioso (e ricco di soddisfazioni!), non esaurisce il nostro compito: come penetration tester siamo tenuti a (cercare di) individuare tutte le vulnerabilità presenti nella rete bersaglio, sempre rimanendo all’interno di quei vincoli e quelle modalità individuate dal proprietario della rete stessa, e formalizzate all’interno di un documento scritto denominato “manleva”.

Grazie al protocollo SSH possiamo superare l’equazione “amministrazione del server = presenza fisica dinanzi al rack

PENETRATION TEST

L’attacco al servizio SSH

Iniziamo con il protocollo SSH (Secure Shell, vedi il box omonimo), utilizzato nei sistemi della famiglia Unix per consentire l’amministrazione da remoto dei server. Grazie a SSH è possibile superare l’equazione “amministrazione del server = presenza fisica dinanzi al rack”: è sufficiente infatti che l’amministratore si connetta alla porta 22 del server mediante l’apposito client (chiamato, non a caso, proprio “ssh”), inserisca le proprie credenziali e la shell di root si materializzerà dinanzi ai suoi occhi. Si tratta di uno strumento molto potente, che non a caso va usato con tutte le cautele possibili. In particolare, l’accesso alla porta 22 dovrebbe essere possibile agli amministratori solo da una sotto-rete distinta da quella ove fluisce il traffico utente, ovvero non dovrebbe essere possibile “vedere” la porta SSH (22/TCP) aperta utilizzando il medesimo canale adottato per consultare, ad esempio, le pagine ospitate sul server web.

Tale segmentazione può essere ottenuta progettando in maniera opportuna la rete interna, oppure adottando idonee contromisure (mediante dispositivi di protezione perimetrale o quantomeno posti sulla stessa macchina da proteggere) per impedire al traffico proveniente dall’esterno della rete  di aprire una connessione SSH con il server. Sappiamo dalle nostre scansioni che la porta 22 della VM “Server Web” risulta aperta, e quindi raggiungibile, dall’esterno. Nulla sappiamo, tuttavia, in merito all’eventuale esistenza di un meccanismo che impedisca il login tramite SSH da indirizzi IP provenienti dall’esterno della rete: non ci resta che provare a connetterci. Aperta una shell sulla VM “Pentester”, digitiamo il comando:

# ssh user@webserver.labpentest.hj

ed inseriamo la password carpita nelle puntate precedenti (password che coincide con lo stesso nome utente, ovvero con la parola “user”). A questo punto si avvierà dinanzi a noi la shell dell’utente user

[figura 2].

In qualità di penetration tester, questo può essere giudicato già un risultato rilevante, degno di menzione nel nostro report finale: abbiamo carpito le credenziali di un utente legittimo del sistema e le abbiamo utilizzate per ottenere l’accesso, sebbene come utente non privilegiato, su uno dei server della rete. Quello che ci manca, come ciliegina sulla torta, è ottenere i privilegi di root.

La schermata di login tramite SSH ci chiarisce (qualora ci fosse sfuggito dalle scansioni delle puntate precedenti) come il sistema operativo sia Ubuntu GNU/Linux. Questo tipo di distribuzione Linux fa ricorso al comando sudo per consentire l’accesso privilegiato a utenti non privilegiati: solo gli utenti abilitati, tuttavia, possono avvalersi con successo del comando sudo.

Il succo del discorso è proprio qui: l’utilizzo del comando sudo da parte di un utente privo di abilitazione potrebbe generare (a seconda della configurazione del sistema) un avviso di sicurezza per i legittimi amministratori della macchina. È un’eventualità che desideriamo evitare, poiché durante un penetration test è di norma importante mantenere un profilo basso, il meno invasivo possibile. Proviamo quindi a visualizzare dapprima i gruppi cui appartiene l’utente, mediante il

comando:

# groups

che, in questo caso, non ci fornisce grossi risultati (c’è un solo gruppo, il cui nome coincide con l’utente: il tipico caso di un utente locale non privilegiato). Non ci resta che passare al comando sudo, da utilizzare con l’opzione “-v” per evitare eventuali avvisi di sicurezza. Il comando da eseguire è il seguente:

# sudo –v

che, dopo aver inserito nuovamente la password dell’account, ci conferma come l’utente sia non sia abilitato all’uso di sudo

[figura 3].

Reiterando questo procedimento per gli utenti di cui abbiamo carpito le credenziali nella puntata precedente (gli utenti ftp, postgres e service, con password anche in questi casi coincidenti con l’username) otteniamo risultati analoghi. Non c’è da disperare, comunque: nelle nostre indagini sul servizio FTP, abbiamo individuato il nome di un utente che sembrava essere molto promettente (l’utente msfadmin) ma di cui non siamo (al momento!) a conoscenza della password.

A tal proposito, facciamo di nuovo ricorso al tool Hydra, stavolta istruendolo perché attacchi il servizio SSH. Per verificare se anche all’utente msfadmin sia associata una password banale, digitiamo il comando:

# hydra -t 3 -l msfadmin -e nsr

webserver.labpentest.hj ssh

Come nei precedenti tentativi, Hydra si conferma perfettamente efficiente nello scovare la password associata all’account: provate ad indovinare? Si tratta della parola “msfadmin”

[figura4]!

A questo punto, non ci resta che effettuare l’accesso SSH con le credenziali di questo utente, mediante il comando:

# ssh msfadmin@webserver.

labpentest.hj

Come al solito, attraverso il comando groups possiamo conoscere i gruppi a cui appartiene l’utente: questa volta sono numerosi, il che lascia ben presagire per il prosieguo. Non a caso, stavolta, il comando sudo -v ci mostra un output diverso: contrariamente agli altri, l’utente msfadmin risulta infatti abilitato all’utilizzo del comando sudo.

Possiamo averne la riprova eseguendo il comando:

# sudo su

grazie al quale passiamo, d’incanto, ad essere root sul sistema. Di nuovo, possiamo farci i complimenti: dopo il servizio FTP, eccoci ad aver ottenuto i privilegi di root sfruttando, stavolta, il protocollo SSH (e la pessima password policy in vigore sul sistema).

PENETRATION TEST

Protocollo di comunicazione per accesso remoto

Il SSH (Secure Shell) è un protocollo in grado di fornire una shell su un sistema remoto, garantendo al contempo la riservatezza, l’integrità e l’autenticazione dei dati scambiati. Contraddistinto da una logica client/server, il protocollo è comunemente associato con la porta 22/TCP, ove di norma è posto in ascolto il server. La connessione tra client e server è protetta facendo ricorso a tecniche di crittografia simmetrica ed asimmetrica, che forniscono ai sistemisti la garanzia di poter amministrare in piena sicurezza, seppur in remoto, i server di propria competenza: è proprio questo uno dei motivi alla base del successo del protocollo.

Protocollo di comunicazione bidirezionale

Telnet è un protocollo pensato per garantire una comunicazione bidirezionale tra client e server, con quest’ultimo posto di norma in ascolto sulla porta 23/TCP. Sebbene condivida con SSH alcuni degli impieghi, primo tra tutti quello di fornire sessioni di login remoto, si distingue da quest’ultimo per la totale assenza di meccanismi in grado di garantire la riservatezza, l’integrità e l’autenticazione dei dati trasmessi

Guide to Penetration Testing

Alla ricerca di vulnerabilita‘

Non paghi del risultato (nuovamente) ottenuto, passiamo alla verifica del prossimo servizio: il servizio telnet (vedi il box omonimo), in ascolto sulla porta 23/TCP. Dalle nostre scansioni sappiamo già che la porta in questione è aperta sul webserver. Verifichiamo “cosa” sia in ascolto: per farlo, il modo più semplice è quello di connettersi mediante l’utilizzo del client omonimo. In altre parole, dobbiamo eseguire da shell il comando:

# telnet www.labpentest.hj 23

 [figura 5]

Non possono che lasciarci allibiti. Mentre noi eravamo impegnati ad individuare i servizi in esecuzione sulla  macchina, per poi indagare sulle debolezze e sulle vulnerabilità dei servizi FTP e SSH e della password policy in uso sul sistema, la schermata di login alla macchina ci attendeva, placida, sulla porta 23, visualizzando il messaggio “Login with msfadmin/msfadmin to get started”. E pensare che per individuare l’account in questione (msfadmin) e la relativa password abbiamo dovuto sudare non poco passando, di puntata in puntata, attraverso le seguenti fasi:

1. intrusione in un account FTP, di cui sono state carpite le credenziali mediante un attacco a dizionario condotto con Hydra;

2. analisi dei file contenuti nel relativo spazio FTP, con particolare riferimento al file .bash_history, da cui abbiamo appreso la conoscenza dell’account msfadmin;

3. recupero della password mediante un attacco condotto con Hydra sul servizio SSH, e basato sull’osservazione della completa mancanza di una password policy affidabile negli account compromessi. Se invece fossimo partiti direttamente dall’esame della porta 23, avremmo ottenuto direttamente le credenziali dell’utente msfadmin, che come visto si traducono nell’accesso ad una shell non privilegiata, ma immediatamente elevabile mediante il ricorso al comando sudo. Naturalmente, non sempre le cose sono così semplici: gli stessi creatori della distribuzione Metasploitable, su cui è basata la VM “Web Server”, si premurano di avvisarci nella schermata di login di evitare assolutamente la connessione della macchina virtuale ad una rete non fidata, se si vogliono evitare gravissimi rischi alla sicurezza dell’intera infrastruttura.

Protocollo per trasmissi one mail

SMTP (Simple Mail Transfer Protocol) è un protocollo testuale per la trasmissione delle email. I server SMTP, generalmente posti in ascolto sulla porta 25/TCP, sono interrogabili mediante un semplice client testuale come netcat o telnet. Il protocollo supporta un set di comandi abbastanza esteso, ben descritto nei documenti RFC (Request For Comment) che ne definiscono le specifiche, primo su tutti il Request For Comment 821 (scaricabile, per chi fosse interessato, all’URL https://tools.ietf.org/rfc/index ).

Enumerazione con protocollo SMTP

FTP, SSH e lo stesso Telnet si sono rivelate delle prede in fin dei conti abbastanza semplici. Il mondo reale, tuttavia, non sempre offre una tale varietà di servizi vulnerabili, in grado peraltro di rivelare un numero consistente di utenti su cui concentrarsi (per giunta con una password debolissima associata!). In questi contesti, risulta particolarmente preziosa l’attività di enumerazione: attività a cui si presta, in maniera particolare, il protocollo SMTP (vedi box omonimo).

Acronimo di “Simple Mail Transport Protocol”, si tratta di un protocollo pensato per il solo invio di mail, secondo una logica prettamente client-server: il client si connette al server (per la precisione, alla porta 25/TCP del server), presenta la propria identità, quindi procede all’invio di una o più mail, provvedendo ad individuarne i rispettivi mittenti e destinatari. In aggiunta a tali operazioni, che costituiscono il suo “core business”, il protocollo SMTP offre alcune funzionalità molto interessanti per un pentester in cerca di account utenti da enumerare: funzionalità che, pensate in un’epoca in cui Internet era un luogo molto più aperto ed amichevole, sono di norma disabilitate sui server più recenti.

Naturalmente, non ci faremo certo scoraggiare da un semplice “di norma”: il quadro che abbiamo sin qui delineato ci lascia il legittimo dubbio che anche la configurazione del servizio SMTP possa essere poco attenta alla sicurezza. Per verificare se i nostri dubbi siano fondati connettiamoci al server mediante il comando:

# telnet webserver.labpentest.

hj 25

Dopo qualche secondo di attesa, il server ci confermerà l’avvenuta connessione con il messaggio “220 metasploitable.localdomain ESMTP Postfix (Ubuntu)” .

A questo punto, il server rimane in attesa della nostra identificazione, che tuttavia può essere del tutto arbitraria. Digitiamo il comando

HELO hj

quindi, dopo la conferma positiva del server, proviamo a vedere se il comando VRFY sia abilitato o meno. A tal fine è sufficiente digitare il comando

VRFY user

con cui chiediamo al server SMTP di confermarci l’esistenza di un utente denominato user (utente che noi sappiamo già esistere dalle nostre precedenti indagini sul protocollo FTP). La risposta del server, “252

2.0.0 user” è un ottimo indizio: il comando non sembra essere stato disabilitato, ed inoltre il server ci conferma quanto già sappiamo in merito all’utente user. Ci manca la prova del nove: cosa succede se utilizziamo il comando VRFY con un utente (presumibilmente) non esistente? Ad esempio, se digitiamo

VRFY ImperoInformatico

notiamo una risposta differente:

“550 5.1.1 <ImperoInformatico>:

Recipient address rejected”.

Automatizziamo la nostra enumerazione!

Abbiamo ciò che serve per distinguere un account esistente da uno non presente nel sistema. Non solo: abbiamo appreso come la distribuzione Kali utilizzata per il penetration test disponga di un’accurata lista (disponibile al percorso /usr/share/wordlists/ metasploit) di oltre 100 nomi di utenti comunemente definiti in un sistema GNU/Linux. A questo punto non ci resta che assemblare questi ingredienti e scrivere un tool in grado di automatizzare (e, di conseguenza, velocizzare) la nostra ricerca.

Restate in onda su Impero Informatico (testeremo un tool a prova di bomba e lo condivideremo con voi)

Tre anni di galera

Chiunque abusivamente si introduce in un sistema informatico protetto da misure di sicurezza ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo, è punito con la reclusione fino a 3 anni.

Cosa significa questa frase, vista nell’ottica di un penetration tester? La risposta è semplice: per quanto buone possano essere le vostre intenzioni, mai eseguire un penetration test (o anche solo una parte di esso) su sistemi che non siano di vostra proprietà, a meno che non disponiate di un apposito permesso scritto da parte di tutti i proprietari dell’infrastruttura da testare.

Ovviamente, per “permesso scritto” non stiamo parlando certo di una semplice mail (soluzione che qualcuno potrebbe proporvi), ma piuttosto di un documento formale (la cosiddetta manleva) in cui si stabilisce, tra l’altro, quali siano i sistemi da testare, che tipo di test effettuare e i vincoli a cui dovete attenervi. È questo documento (e il rispetto dei  relativi termini) che differenzia un penetration tester (ovvero un professionista) da un volgare pirata informatico.

LEGGI ANCHE: Il motore pirata