Mese: novembre 2021

hacking

Playing with TOR

Rocco Sicilia

Durante la preparazione di alcuni laboratori per un workshop sulle simulazioni di attacco ho approfondito alcuni aspetti del funzionamento della rete ToR, quei dettagli che capita di leggere ma più raramente di toccare con mano fino a quando non se ne ha l’occasione. Mi piaceva l’idea di riassumere in un post le sessioni di gioco con la rete Tor ed un paio di utilizzi che penso possano essere utili nello svolgimento di attività offensive, ovviamente in contesti autorizzati.

installazione ed avvio del servizio Tor

Nota ovvia: il contenuto del post ha finalità divulgative al fine di condividere alcuni aspetti del funzionamento della rete Tor così da acquisire una maggiore consapevolezza dello strumento che, come tutti gli strumenti, può essere utilizzato anche per fini illeciti e proprio a tal proposito è bene saper riconoscere eventuali attività sospette eseguite attraverso questa rete.

Non è un how-to, per chi ha bisogno di una infarinatura ci sono moltissimi articoli che potete prendere in considerazione:

Lab setup

Un minimo di infrastruttura per utilizzare il servizio. Per praticità utilizzo la mia kali box, ma potete ovviamente utilizzare quello che vi pare. L’installazione è semplicissima (vedi screenshot ad inizio post) ed una volta avviato il demone il servizio sarà immediatamente disponibile sulla local port 9050.

Per fare un po’ di esperimenti assicurarsi di disporre anche dei seguenti software:

  • apache2 + php
  • wget / curl
  • ssh-ping
  • tor-browser

Oltre alla kali locale ho utilizzato un web server remoto per eseguire alcune prove, nel mio caso si tratta di un semplicissimo LAMP basato su Ubuntu (LTS) con esposto il servizio http ed ssh su porte non standard.

Onion Site

Obiettivo del test era osservare log e traffico di un nodo Tor su cui è attivo un Onion Site, la prima cosa da fare è quindi configurare un il sito cipolla.

Premessa: i domain name .onion funzionano in modo diverso rispetto ai domain name che popolano la rete internet: un onion name corrisponde all’identità (univoca) di uno specifico nodo (vedi rfc 7686). In parole povere un onion name si riferisce specificatamente all’host su cui risiede il servizio in qualità di nodo della rete Tor.

Per configurare un “sito cipolla” è sufficiente accedere al file di configurazione di Tor in /etc/tor/torrc e definire la configurazione del servizio dichiarando il path per i file di configurazione. Viene inoltre dichiarata la porta del servizio da non interpretare come un sistema di pubblicazione: il servizio Tor si limiterà ad eseguire l’inoltro dei pacchetto in ingresso sulla porta 80 (visto che voglio intercettare il traffico http) vero il web server attivo sul sistema (apache2) precedentemente installato durante il setup del laboratorio.

configurazione base per un “sito cipolla”

Il mio apache non ha nessuna specifica configurazione, anzi è praticamente in configurazione di default ed il contenuto pubblicato è molto semplice, si tratta infatti di un PHP file che esegue la print dell’IP del client che accede al contenuto:

Nel mio caso la macchina è una guest con un IP dietro un primo NAT per accedere alla rete locale tramite l’host (la mia workstation) e dietro un secondo NAT per accedere alla rete internet tramite la mia connettività. Il server non esegue quindi nessun tipo di pubblicazione di servizi verso la rete internet mentre è raggiungibile dalla mia LAN tramite il NAT del software di virtualizzazione. Per chiarire riporto uno schema di sintesi:

labz

Accedendo quindi al contenuto direttamente dalla guest o dalla mia workstation il sistema potrà registrare nei log l’IP del client che ha eseguito l’accesso al web server nel solito file /var/log/apache2/access.log.

Avviando il servizio Tor sulla VM hidden-server verrà generato l’indirizzo del sito .onion ed il demone si occuperà di intercettare le richieste verso la porta 80 in arrivo dalla rete Tor verso la porta 80 del servizio di pubblicazione HTTP.

Per simulare il comportamento di un utente che, attraverso la rete Tor, invii una richiesta GET ai contenuti del sito cipolla è sufficiente predisporre un ToR browser sulla workstation (o su un altro sistema esterno) così da ottenere il comportamento di un qualsiasi Tor user che voglia accedere al contenuto appena pubblicato. L’indirizzo del sito cipolla è disponibile all’interno del file /var/lib/tor/hidden_service/hostname, nel mio caso:

Per capire meglio cose sta accadendo sul sistema che ospita l’onion site ho verificato come prima cosa lo status delle connessione della macchina. Con i servizi apache e Tor attivi lo status delle connessione presentava poche e ben definite sessioni.

Sulla porta 9050 della loopback è ovviamente in ascolto il demone Tor utilizzabile dal mio client come socks host. Già dalla seconda riga la cosa si fa interessante: il mio host contatta dal proprio IP in LAN il sistema 185.243.218.27 che, ricerche alla mano, è un ToR Node che fa riferimento a questo progetto: https://tuxli.ch/. Verificando il comportamento delle sessioni e la descrizione dei servizi offerti da questo nodo, devo dedurne che si tratti del DirNode selezionato dal server per scaricare la lista dei Relay, inoltre il nodo stesso offre servizi di Relay. Ultimo dato utile è nella terza linea con il binding del servizio apache2 sulla porta 80, questo è il servizio che viene contattato, in definitiva, da un client che vuole accede al contenuto che il sito sta pubblicando. In un contesto standard vedremmo quindi una sessione tra il server ed il client in un formato del tipo: 

{LocalIP}:80 <---> {RemoteIP}:{ClientPort}

Avviando il Tor browser su un altro host ed accedendo al sito cipolla già configurato possiamo osservare meglio il comportamento del demone ToR nel consentire l’accesso ai contenuti:

Quello che accade è abbastanza chiaro: il Tor browser non compare tra i client in quanto la richiesta arriva al server all’interno della sessione già attiva con il Relay Node (182.243.218.27) e si presenta come una richiesta interna del sistema (127.0.0.1:46660) verso il servizio http apparentemente binded sulla stessa loopback (127.0.0.1:80). Questa sessione si riferisce in realtà al forward dei pacchetti eseguito dal demone Tor verso apache. Questo spiega anche come mai nell’access.log di apache compare l’IP 127.0.0.1 come client.

Secure ssh access

Qualcosa di simile a quanto fatto con la pubblicazione http è possibile farlo con ssh: in questo caso l’obiettivo molto operativo che volevo ottenere era una modalità di accesso via ssh ad un server all’interno della rete Tor.

Il vattoggio è relativamente chiaro: tenendo attivo il mio server all’intero della rete e configurando opportunamente il demone Tor potrò garantirmi un accesso in ssh alla mia macchina senza esporre il servizio ad internet nascondendo di fatto il sistema. Da questa posizione posso poi raggiungere altri sistemi anche all’esterno della rete Tor ma comunque attraversandola.

Lo scenario di base è identico al precedente con qualche aggiunta, in particolare sul server “nascosto” bisognerà necessariamente installare ed avviare il demone ssh ma, come per http, non sarà necessario eseguire un NAT sulla rete internet in quanto la raggiungibilità del servizio verrà affidata alla rete Tor. Il file di configurazione coinvolto è sempre /etc/tor/torrc in cui, poche righe sotto la configurazione del servizio http, vi sono le configurazioni per gli “altri servizi nascosti”:

Nel caso specifico, con la configurazione riportata nello screenshot, stiamo istruendo Tor ad inoltrare il traffico in arrivo sulla porta tcp\22 verso il servizio in ascolto sulla medesima porta del server. Nel file /var/lib/tor/other_hidden_service/hostname è riportato l’indirizzo .onion per raggiungere il servizio nascosto all’interno della rete. Una volta completata la configurazione potremo collegarci alla macchina in ssh puntando al sito cipolla corrispondente. Ovviamente il sistema da cui si vorrà eseguire la connessione dovrà essere a sua volta connesso alla rete Tor. Il comando è quindi semplicissimo:

torify ssh sheliak@{sitocipolla}.onion

Una volta avviata la connessione è molto probabile riscontrare una carta latenza nella risposta, si tratta di un effetto collaterale inevitabile in quanto i pacchetti che i due sistemi si scambiano stanno attraversando un minimo di tre Tor Node e ad ogni hop corrispondono operazioni di cifratura/decifratura. Tutto ciò introduce latenza nelle comunicazioni. Quanta?

ssh-ping verso il servizio ssh nascosto

Una volta ottenuto l’acceso al sistema, esattamente come visto per http, noteremo che i servizi di destinazione si vedono arrivare richieste di accesso dall’interfaccia di loopback. Quindi se eseguiamo delle verifiche su chi è connesso al sistema con il comando who …

A sinistra la sessione ssh via Tor, a destra una console locale

… l’output mostrerà la sessione locale ed una sessione remota da 127.0.0.1 a testimoniare il nostro accesso “anonimo” quanto meno a livello di IP.

Conclusioni e riflessioni

Il mio interesse specifico in questo laboratorio ruotava attorno all’esigenza di comprende meglio il funzionamento della rete Tor per valutare come sfruttarla in simulazioni di attacco e qualche idea me la sono fatta. Non sono da meno gli spunti a livello di incremento della sicurezza sfruttando i servizi nascosti per amministrare i propri sistemi senza esporli in nessun modo, ne con un NAT ne con una VPN che come ultimamente abbiamo visto è un servizio come gli altri e può avere dei bug.

Capito meglio il funzionamento mi è ben chiaro come si è potuta sfruttare la rete anche per fini illeciti come la creazione di botnet utilizzate per attacchi ad enti ed aziende. Ci sono degli aspetti che mi segno di approfondire in un prossimo lab come la possibilità di eseguire ricerche automatizzate in rete internet attraverso la rete Tor e la possibilità di scambiarsi informazioni e messaggi peer-to-peer.

cyber security, hacking

Vulnerabilità, calcolo del rischio e gestione delle priorità

Rocco Sicilia

In più occasioni mi trovo a discutere della differenza nella sostanza tra lo score di una vulnerabilità, rappresentato dal parametro CVSS, ed il rischio ad essa correlata che deve tener conto di diversi elementi del contesto.

L’output standard dei tools di scansione delle vulnerabilità potrebbe facilmente portare a considerare lo score della vulnerabilità come il parametro che determina il rischio. Potrebbe sembrare logico: se la vulnerabilità ha uno score alto significa che è particolarmente grave quindi rischio di più. Come accennavo in questo post è necessario considerare anche l’impatto sul business dell’asset o del servizio su cui è individuata una vulnerabilità: a parità di score una vulnerabilità che affligge un sistema di posta elettronica, per fare un esempio, è ben più impattante di una vulnerabilità che affligge una SmartTV.

Fette le dovute premesse al post passiamo all’operatività partendo dagli strumenti che tipicamente vengono adoperati per eseguire la verifica delle vulneralità, ovvero i tools di scansione. Ne esistono molti, con più o meno funzioni e per tutte le tasche. La funzionalità base comune a tutti i software di scansione è relativa alla generazione di un report che riporti l’elenco degli asset interessati dalla scansione e le vulnerabilità rilevate. Il report porta all’attenzione diversi dati tra cui lo score delle vulnerabilità (CVSS) accompagnato da altri parametri a supporto della comprensione della stessa.

Ultimamente ho avuto modo di operare su due piattaforme molto diverse tra loro: Nessus e Qualys. Al fine di automatizzare parte del processo di rilevamento delle vulnerabilità e calcolo del rischio ho condotto qualche prova di estrazione dei dati per agevolare il processo di creazione del remediation plan secondo una logica “rischio centrica”.

Test API

Entrambi i software, come molti altri, consentono di utilizzare le API per accedere ai report delle scansioni permettendo così di creare semplici script di estrazione ed elaborazione dei dati. Dovendo potenzialmente calcolare il fattore di rischio per decine se non centinaia di vulnerabilità automatizzare almeno una parte del processo è cosa saggia.

La ricetta, come abbiamo visto, è relativamente semplice e si basa su un minimo di due dati oggettivi (CVSS dato dalla scansione e Business Impact dato dall’asset inventory) e un dato analitico che personalmente mi piace aggiungere per avvicinare l’analisi al mondo vero e che potremmo pragmaticamente chiamare appetibilità.

Alcuni tools, come Qualys, consentono di censire dati anche per l’asset oggetto di analisi. In questo caso parametri come il Business Impact possono far parte dei dati base del report e possono essere utilizzati per calcolare un fattore di rischio. Altri tools, come Nessus, riportano i dati relativi alle vulnerabilità che dovranno poi essere analizzati tenendo in considerazione i dati gestiti dal sistema di asset manager.

p-o-c

Ovviamente mettere in relazione i dati provenienti da una scansione con i dati di un tool di asset management non è banale in quanto entrambi i sistemi devono poter mettere a disposizione le informazioni tramite una API. Personalmente credo sia anche il metodo più strutturato per gestire un piano di rimedio in quanto transita per la creazione di un processo di gestione degli asset e relativi strumenti IT.

Dall’altro lato sfruttando opportunamente le funzionalità di tools più ricchi è possibile arrivare ad ottenere, già nel report, un parametro che aiuti a qualificare il rischio. In questo caso il parametro da utilizzare per comporre il remediation plan potrebbe essere presente già nel report ed una volta raccolti i dati si potrà ottenere un elenco per priorità semplicemente “riordinando la lista” partendo dalla coppia host/vulnerabilità che riporta il rischio più alto.

Un ultimo step potrebbe essere quello di generare una notifica per il team IT dove riportare solo le vulnerabilità che risultano avere un fattore di rischio meritevole di considerazione secondo la policy scelta dall’organizzazione per la gestione delle vulnerabilità.

Nella p-o-c ho riportato qualche esempio di accesso alle API di Qualys e Nessus relative ai dati dei report: https://github.com/roccosicilia/sToolz/tree/master/GetVulnReport