Una storia di ricerca e sviluppo in 3 parti. La prima parte è esplorativa.
Ci sono molti faggi: ancora più vantaggi.
Formulazione del problema
Durante i pentest e le campagne RedTeam, non sempre è possibile utilizzare gli strumenti standard del Cliente, come VPN, RDP, Citrix, ecc. come ancoraggio per entrare nella rete interna. In alcuni posti, una VPN standard funziona utilizzando MFA e un token hardware viene utilizzato come secondo fattore, in altri viene brutalmente monitorato e il nostro login VPN diventa immediatamente visibile, come si suol dire, con tutto ciò che comporta, ma in altri ci sono semplicemente nessun mezzo del genere.
In questi casi, dobbiamo costantemente creare i cosiddetti "tunnel inversi": connessioni dalla rete interna a una risorsa esterna o a un server che controlliamo. All’interno di tale tunnel possiamo già lavorare con le risorse interne dei Clienti.
Esistono diverse varietà di questi tunnel di ritorno. Il più famoso di questi è, ovviamente, Meterpreter. Anche i tunnel SSH con reverse port forwarding sono molto richiesti tra le masse degli hacker. Esistono molti mezzi per implementare il tunneling inverso e molti di essi sono ben studiati e descritti.
Naturalmente, da parte loro, gli sviluppatori di soluzioni di sicurezza non si fanno da parte e rilevano attivamente tali azioni.
Ad esempio, le sessioni MSF vengono rilevate con successo dai moderni IPS di Cisco o Positive Tech e un tunnel SSH inverso può essere rilevato da quasi tutti i normali firewall.
Pertanto, per rimanere inosservati in una buona campagna RedTeam, dobbiamo costruire un tunnel inverso utilizzando mezzi non standard e adattarci il più fedelmente possibile alla modalità operativa reale della rete.
Proviamo a trovare o inventare qualcosa di simile.
Prima di inventare qualsiasi cosa, dobbiamo capire quale risultato vogliamo ottenere, quali funzioni dovrebbe svolgere il nostro sviluppo. Quali saranno i requisiti del tunnel per poter lavorare nella massima modalità stealth?
È chiaro che per ciascun caso tali requisiti possono differire notevolmente, ma in base all'esperienza lavorativa è possibile identificare i principali:
- funziona sul sistema operativo Windows-7-10. Poiché la maggior parte delle reti aziendali utilizza Windows;
- il client si connette al server tramite SSL per evitare ascolti stupidi utilizzando ips;
- Durante la connessione, il client deve supportare il lavoro tramite un server proxy con autorizzazione, perché In molte aziende l'accesso a Internet avviene tramite proxy. La macchina client, infatti, potrebbe non saperne nemmeno nulla e il proxy viene utilizzato in modalità trasparente. Ma dobbiamo fornire tale funzionalità;
- la parte client dovrebbe essere concisa e portabile;
È chiaro che per lavorare all'interno della rete del cliente, puoi installare OpenVPN sul computer client e creare un tunnel completo verso il tuo server (fortunatamente i client openvpn possono funzionare tramite un proxy). Ma, in primo luogo, questo non funzionerà sempre, dal momento che potremmo non essere amministratori locali lì, e in secondo luogo, farà così tanto rumore che un SIEM o HIPS decente ci "farà la spia" immediatamente. Idealmente, il nostro client dovrebbe essere un cosiddetto comando inline, poiché ad esempio vengono implementate molte shell bash e avviate tramite la riga di comando, ad esempio quando si eseguono comandi da una macro di parole. - il nostro tunnel deve essere multi-thread e supportare più connessioni contemporaneamente;
- la connessione client-server deve avere una sorta di autorizzazione in modo che il tunnel venga stabilito solo per il nostro client e non per tutti coloro che arrivano al nostro server all'indirizzo e alla porta specificati. Idealmente, una landing page con gatti o argomenti professionali legati al dominio originale dovrebbe aprirsi a “utenti di terze parti”.
Ad esempio, se il cliente è un'organizzazione medica, allora per un amministratore della sicurezza delle informazioni che decide di controllare la risorsa a cui ha avuto accesso il dipendente della clinica, una pagina con prodotti farmaceutici, Wikipedia con una descrizione della diagnosi o il blog del Dr. Komarovsky, ecc. dovrebbe aprirsi.
Analisi degli strumenti esistenti
Prima di reinventare la propria bicicletta è necessario fare un'analisi delle biciclette esistenti e capire se ne abbiamo davvero bisogno e, probabilmente, non siamo gli unici ad aver pensato alla necessità di una bicicletta così funzionale.
Cercando su Google su Internet (ci sembra di farlo normalmente), così come la ricerca su Github utilizzando le parole chiave “calzini invertiti” non hanno dato molti risultati. Fondamentalmente, tutto si riduce alla costruzione di tunnel ssh con port forwarding inverso e tutto ciò che è connesso ad esso. Oltre ai tunnel SSH, esistono diverse soluzioni:
Un'implementazione di lunga data di un tunnel inverso da parte dei ragazzi di Kaspersky Lab. Il nome chiarisce a cosa è destinato questo script. Implementato in Python 2.7, il tunnel funziona in modalità testo in chiaro (come è di moda dire adesso - ciao RKN)
Un'altra implementazione in Python, anch'essa in chiaro, ma con più possibilità. È scritto come un modulo e dispone di un'API per integrare la soluzione nei tuoi progetti.
Il primo collegamento è la versione originale dell'implementazione del reverse sox in Golang (non supportata dallo sviluppatore).
Il secondo collegamento è la nostra revisione con funzionalità aggiuntive, sempre in Golang. Nella nostra versione abbiamo implementato SSL, lavoriamo tramite proxy con autorizzazione NTLM, autorizzazione sul client, una landing page in caso di password errata (o meglio, un reindirizzamento alla landing page), modalità multi-thread (ovvero più persone può lavorare con il tunnel contemporaneamente), un sistema di ping del client per determinare se è vivo o no.
Implementazione del reverse sox dei nostri “amici cinesi” in Python. Lì, per i più pigri e “immortali”, c'è un binario (exe) già pronto, assemblato dai cinesi e pronto per l'uso. Qui, solo il Dio cinese sa cos'altro può contenere questo binario oltre alla funzionalità principale, quindi usalo a tuo rischio e pericolo.
Un progetto piuttosto interessante in C++ per l'implementazione del reverse sox e altro ancora. Oltre al tunnel inverso, può eseguire il port forwarding, creare una shell di comandi, ecc.
Misuratore di MSF
Qui, come si suol dire, nessun commento. Tutti gli hacker, più o meno istruiti, conoscono molto bene questa cosa e capiscono quanto facilmente possa essere rilevato dagli strumenti di sicurezza.
Tutti gli strumenti sopra descritti funzionano utilizzando una tecnologia simile: su una macchina all'interno della rete viene lanciato un modulo binario eseguibile già preparato, che stabilisce una connessione con un server esterno. Il server esegue un server SOCKS4/5 che accetta connessioni e le inoltra al client.
Lo svantaggio di tutti gli strumenti di cui sopra è che Python o Golang devono essere installati sulla macchina client (avete visto spesso Python installato sulle macchine, ad esempio, di un direttore d'azienda o di impiegati?), oppure un software preassemblato binario (in realtà Python) deve essere trascinato su questa macchina e script in una bottiglia) ed eseguire questo binario già lì. E scaricare un exe e poi avviarlo è anche una firma per un antivirus locale o HIPS.
In generale, la conclusione suggerisce se stessa: abbiamo bisogno di una soluzione PowerShell. Ora i pomodori voleranno verso di noi: dicono che PowerShell è già tutto banale, è monitorato, bloccato, ecc. e così via. In effetti, non ovunque. Dichiariamo in modo responsabile. A proposito, ci sono molti modi per aggirare il blocco (anche qui c'è una frase alla moda su ciao RKN 🙂), a partire dalla stupida ridenominazione di powershell.exe -> cmdd.exe e finendo con powerdll, ecc.
Iniziamo a inventare
È chiaro che prima cercheremo su Google e… non troveremo nulla su questo argomento (se qualcuno lo ha trovato, posti i link nei commenti). C'è solo Sox5 su PowerShell, ma questo è un normale sox "diretto", che presenta una serie di svantaggi (ne parleremo più avanti). Ovviamente puoi, con un leggero movimento della mano, trasformarlo in quello opposto, ma questo sarà solo sox a filo singolo, che non è proprio ciò di cui abbiamo bisogno.
Quindi non abbiamo trovato nulla di già pronto, quindi dovremo ancora reinventare la nostra ruota. Prenderemo come base la nostra bicicletta reverse sox in Golang e ne implementiamo un client in PowerShell.
RSocksTun
Allora come funziona rsockstun?
Il funzionamento di RsocksTun (di seguito denominato rs) si basa su due componenti software: Yamux e il server Calze5. Il server Calze5 è un normale calzini5 locale, viene eseguito sul client. E il multiplexing delle connessioni ad esso (ricordate del multithreading?) viene fornito utilizzando yamux (). Questo schema consente di avviare diversi server calzini5 client e distribuire loro connessioni esterne, inoltrandole tramite un'unica connessione TCP (quasi come in meterpreter) da client a server, implementando così una modalità multi-thread, senza la quale semplicemente non saremo in grado di funzionare pienamente nelle reti interne.
L'essenza del funzionamento di Yamux è che introduce un ulteriore livello di rete di flussi, implementandolo sotto forma di un'intestazione di 12 byte per ciascun pacchetto. (Qui usiamo deliberatamente la parola "stream" anziché thread, in modo da non confondere il lettore con il "thread" del flusso di programma - utilizzeremo questo concetto anche in questo articolo). L'intestazione yamux contiene il numero dello stream, i flag per l'installazione/terminazione dello stream, il numero di byte trasferiti e la dimensione della finestra di trasferimento.
Oltre a installare/terminare un flusso, yamux implementa un meccanismo keepalive che consente di monitorare le prestazioni del canale di comunicazione stabilito. Il funzionamento del meccanismo dei messaggi keeplive viene configurato durante la creazione di una sessione Yamux. In realtà, tra le impostazioni ci sono solo due parametri: abilita/disabilita e la frequenza di invio dei pacchetti in secondi. I messaggi keepalive possono essere inviati da un server Yamux o da un client Yamux. Quando riceve un messaggio keepalive, la parte remota deve rispondere inviando esattamente lo stesso identificatore di messaggio (in realtà un numero) che ha ricevuto. In generale, keepalive è lo stesso ping, solo per yamux.
L'intera tecnica operativa del multiplexer: tipi di pacchetti, impostazione della connessione, flag di terminazione e il meccanismo di trasferimento dei dati sono descritti in dettaglio in a Yamux.
Conclusione alla prima parte
Quindi, nella prima parte dell'articolo, abbiamo conosciuto alcuni strumenti per l'organizzazione dei tunnel inversi, esaminato i loro vantaggi e svantaggi, studiato il meccanismo di funzionamento del multiplexer Yamux e descritto i requisiti di base per il modulo PowerShell appena creato. Nella parte successiva svilupperemo il modulo stesso, praticamente da zero. Continua. Non cambiare :)
Fonte: habr.com