Storia di un'indagine e sviluppo in 3 parti. Parte 1 — ricerca.
Ci sono molte lettere — e ancora più vantaggi.
Definizione del compito
Durante le penetrazioni e le campagne RedTeam, non sempre è possibile utilizzare i mezzi standard del Cliente, come VPN, RDP, Citrix, ecc., per entrare nella rete interna. A volte la VPN standard funziona con MFA e come secondo fattore utilizza un token hardware, altre volte è monitorata rigidamente e il nostro accesso via VPN diventa immediatamente visibile, come si suol dire — con tutte le conseguenze del caso, e in altri casi tali mezzi semplicemente non esistono.
In tali situazioni è necessario creare costantemente quelli che si chiamano «tunnel inversi» — connessioni dalla rete interna a una risorsa esterna o a un server da noi controllato. All'interno di tale tunnel possiamo già lavorare con le risorse interne del Cliente.
Esistono diverse varietà di tali tunnel inversi. Il più conosciuto è sicuramente Meterpreter. Anche i tunnel SSH con port forwarding inverso godono di grande popolarità tra gli hacker. Ci sono molti mezzi per realizzare il tunneling inverso e molti di essi sono ben studiati e descritto.
Naturalmente, i sviluppatori di soluzioni di sicurezza non restano a guardare e rilevano attivamente tali azioni.
Ad esempio, le sessioni MSF vengono rilevate con successo dagli IPS moderni di Cisco o Positive Tech, e un tunnel SSH inverso può essere rilevato praticamente da qualsiasi firewall di qualità.
Pertanto, per rimanere inosservati in una buona campagna RedTeam, è necessario costruire tunnel inversi con mezzi non standard e adattarsi il più possibile al reale funzionamento della rete.
Proviamo a trovare o inventare qualcosa di simile.
Prima di inventare qualcosa, è necessario capire quale risultato vogliamo raggiungere e quali funzioni deve svolgere il nostro sviluppo. Quali saranno i requisiti per il tunnel affinché possiamo lavorare nella massima segretezza?
È chiaro che, a seconda del caso, tali requisiti possono differire notevolmente, ma dall'esperienza di lavoro si possono evidenziare i principali:
- funzionamento su sistemi operativi Windows 7-10. Poiché nella maggior parte delle reti aziendali viene utilizzato proprio Windows;
- Il client si connette al server tramite SSL per escludere l'ascolto passivo tramite sistemi IPS;
- Durante la connessione, il client deve supportare il funzionamento tramite un server proxy con autenticazione, poiché in molte aziende l'accesso a Internet avviene attraverso un proxy. In effetti, il computer client potrebbe non saperne nulla, e il proxy è utilizzato in modalità trasparente. Tuttavia, questa funzionalità deve essere implementata;
- La parte client deve essere concisa e portabile;
È chiaro che per lavorare all'interno della rete del Cliente, sul computer client è possibile installare OpenVPN e stabilire un vero e proprio tunnel verso il proprio server (fortuna che i client OpenVPN possono funzionare tramite proxy). Ma, da un lato, non sempre sarà possibile, poiché potremmo non essere amministratori locali, e dall'altro, genererà così tanto rumore che un SIEM o un HIPS rispettabile ci segnalerà immediatamente. Idealmente, il nostro client dovrebbe essere una cosiddetta 'inline command', come ad esempio molti shell bash, e partire tramite la riga di comando, ad esempio, eseguendo comandi da un macro di Word. - Il nostro tunnel deve essere multithreading e supportare molte connessioni simultaneamente;
- La connessione client-server deve avere qualche forma di autenticazione, in modo che il tunnel venga stabilito solo per il nostro cliente, e non per chiunque arrivi al nostro server all'indirizzo e porta specificati. Idealmente, per gli 'utenti esterni' dovrebbe aprirsi una pagina di atterraggio con gattini o un tema professionale correlato al dominio di origine.
Ad esempio, se il Cliente è un'organizzazione medica, per l'amministratore della sicurezza informatica, che decide di controllare la risorsa a cui si è rivolto un dipendente della clinica, dovrebbe aprirsi una pagina con prodotti farmaceutici, una pagina di Wikipedia con la descrizione della diagnosi, o un blog del dottor Komarovsky, ecc.
Analisi degli strumenti esistenti
Prima di inventare la propria bicicletta, è necessario analizzare le biciclette esistenti e capire se abbiamo davvero bisogno di essa e, probabilmente, non siamo stati gli unici a riflettere sulla necessità di una bicicletta funzionale di questo tipo.
Una ricerca su internet (sembra che stiamo facendo bene) e una ricerca su GitHub con le parole chiave «reverse socks» non ha dato molti risultati significativi. Fondamentalmente, tutto si riduce all'implementazione di tunneling SSH con port forwarding inverso e tutto ciò che è collegato. Oltre ai tunneling SSH, si può evidenziare qualche soluzione:
Una vecchia implementazione di tunnel inverso da parte dei ragazzi del Laboratorio Kaspersky. Dal nome è chiaro a cosa serve questo script. Realizzato in Python 2.7, il tunnel funziona in modalità cleartext (come si dice oggi — saluti al RKN).
Un'altra implementazione in Python, sempre in cleartext, ma con più funzionalità. Scritto come modulo, e c'è un'API per integrare la soluzione nei propri progetti.
Il primo link è la versione originale dell'implementazione di reverse socks in Go (non supportata dallo sviluppatore).
Il secondo link è la nostra modifica con funzionalità aggiuntive, sempre in Go. Nella nostra versione abbiamo implementato SSL, lavorato tramite proxy con autorizzazione NTLM, autenticazione client, una landing page in caso di password errata (più precisamente — redirect alla landing page), modalità multithread (cioè diverse persone possono utilizzare il tunnel simultaneamente), un sistema di ping del client per verificare se è vivo o meno.
Implementazione di reverse socks dai nostri 'amici cinesi' in Python. Qui si trova anche un binario (exe) già pronto e creato dai cinesi, pronto per l'uso. Solo il dio cinese sa cosa ci sia in questo binario oltre alle funzionalità principali, quindi usatelo a vostro rischio e pericolo.
Un progetto piuttosto interessante in C++ per implementare reverse socks e altro. Oltre al tunnel inverso, può fare port forwarding, creare un shell per i comandi, ecc.
MSF meterpreter
Qui come si suol dire, senza commenti. Tutti gli hacker minimamente istruiti conoscono bene questa cosa e capiscono quanto sia facile da rilevare da parte degli strumenti di sicurezza.
Tutti gli strumenti sopra descritti funzionano con una tecnologia simile: un modulo binario eseguibile precompilato viene avviato su una macchina all'interno della rete, che stabilisce una connessione con un server esterno. Sul server viene avviato un server SOCKS4/5 che accetta le connessioni e le instrada al client.
Lo svantaggio di tutti gli strumenti sopra menzionati è che è necessario avere Python o Golang installati sulla macchina client (quante volte hai trovato Python installato su macchine come quelle di un direttore aziendale o di impiegati?), oppure è necessario portare su quella macchina un binario precompilato (praticamente Python e lo script in un colpo solo) e avviare quel binario. Inoltre, scaricare un exe e avviarlo è una chiara firma per l'antivirus locale o HIPS.
In generale, la conclusione è ovvia: abbiamo bisogno di una soluzione in PowerShell. Adesso ci verranno tirati pomodori — si dirà che PowerShell è già obsoleto, viene monitorato, bloccato, ecc. In realtà, non ovunque. Lo dichiariamo con responsabilità. A proposito, ci sono molti modi per aggirare i blocchi (di nuovo la frase alla moda è benvenuto a RKN 🙂), che vanno dalla semplice rinominazione di powershell.exe in cmdd.exe fino a powerdll e così via.
Iniziamo a ideare
È chiaro che prima daremo un'occhiata a Google e... non troveremo assolutamente nulla su questo argomento (se qualcuno ha trovato qualcosa, inviate i link nei commenti). Esiste solo Socks5 in PowerShell, ma si tratta di un normale socks 'diretto' che ha diversi svantaggi (di cui parleremo più tardi). Certamente, è possibile trasformarlo in uno inverso con un semplice movimento, ma sarà solo un socks a thread singolo, che per noi non è esattamente quello di cui abbiamo bisogno.
Quindi, non abbiamo trovato nulla di pronto, quindi dovremo inventare la nostra bicicletta. Prenderemo come base la nostra di un socks inverso in Golang, e realizzeremo il client per esso in PowerShell.
RSocksTun
Quindi, come funziona rsockstun?
Alla base del funzionamento di RsocksTun (d'ora in poi rs) ci sono due componenti software - Yamux e un server Socks5. Il server Socks5 è un normale socks5 locale, viene avviato sul client. E il multiplexing delle connessioni ad esso (ricordate la multithreading?) è garantito da yamux (). Questo schema consente di avviare più server socks5 client e di distribuire le connessioni esterne a essi, inoltrandole tramite una singola connessione TCP (quasi come in meterpreter) dal client al server, realizzando così una modalità multi-threaded, senza la quale non possiamo lavorare adeguatamente all'interno della rete interna.
Il principio di funzionamento di yamux consiste nell'introdurre un ulteriore livello di rete per gli stream, implementandolo come intestazione di 12 byte per ogni pacchetto. (Qui usiamo deliberatamente la parola «stream», e non flusso, per non confondere il lettore con il flusso di programma «thread» — questo concetto verrà utilizzato anche in questo articolo). All'interno dell'intestazione yamux sono contenuti il numero dello stream, i flag per l'impostazione/terminazione dello stream, il numero di byte trasmessi e la dimensione della finestra di trasmissione.
Oltre all'impostazione/terminazione dello stream, yamux ha implementato un meccanismo di keepalive che consente di monitorare la funzionalità del canale di comunicazione stabilito. Il funzionamento del meccanismo di messaggi keepalive è configurato al momento della creazione di una sessione Yamux. In effetti, ci sono solo due parametri nelle impostazioni: abilitare/disabilitare e la periodicità dell'invio dei pacchetti in secondi. I messaggi keepalive possono essere inviati sia dal server yamux che dal client yamux. Al ricevimento di un messaggio keepalive, la parte remota è obbligata a rispondere con l'invio esattamente dello stesso identificatore del messaggio (di fatto — un numero) che ha ricevuto. In generale, il keepalive è lo stesso ping, solo per yamux.
Nello specifico, tutta la tecnica di funzionamento del multiplexor: tipi di pacchetti, flag per l'impostazione e la terminazione delle connessioni, meccanismo di trasmissione dei dati, è descritta nella per yamux.
Conclusione della prima parte
Quindi, nella prima parte dell'articolo, ci siamo familiarizzati con alcuni strumenti per organizzare tunnel inversi, abbiamo esaminato i loro vantaggi e svantaggi, studiato il meccanismo di funzionamento del multiplexor Yamux e descritto i requisiti fondamentali per il nuovo modulo powershell che si sta creando. Nella prossima parte ci occuperemo dello sviluppo del modulo stesso, praticamente, da zero. Continua a seguirci 🙂
Fonte: habr.com
