Storia di ricerca e sviluppo in 3 parti. Parte 1 — la ricerca.
Ci sono molte lettere — e ancora più benefici.
Definizione del compito
Durante i pentest e le campagne RedTeam, non sempre è possibile utilizzare strumenti standard dei Clienti, come VPN, RDP, Citrix, ecc., per stabilire una connessione alla rete interna. In alcune situazioni, il VPN standard funziona attraverso MFA e utilizza un token hardware come secondo fattore, in altri casi viene monitorato rigorosamente e il nostro accesso VPN diventa subito evidente, come si suol dire — con tutte le conseguenze del caso, e in altri casi non ci sono affatto tali strumenti.
In tali casi, bisogna continuamente creare quelli che chiamiamo «tunnel inversi» — connessioni dalla rete interna a una risorsa esterna o a un server che controlliamo. All'interno di questi tunnel, possiamo lavorare con le risorse interne dei Clienti.
Esistono diverse varianti di tunnel inversi. Il più conosciuto è sicuramente Meterpreter. Inoltre, i tunnel SSH con port forwarding inverso sono molto richiesti tra gli hacker. Ci sono molti strumenti per implementare il tunneling inverso, molti dei quali sono ben studiati e documentati.
Naturalmente, i progettisti di soluzioni di sicurezza non rimangono a guardare e monitorano attivamente tali attività.
Ad esempio, le sessioni MSF vengono rilevate con successo dai moderni IPS di Cisco o Positive Tech, mentre un tunnel SSH inverso può essere rilevato da quasi qualsiasi firewall di livello medio.
Pertanto, per rimanere inosservati in una buona campagna RedTeam, dobbiamo costruire tunnel inversi utilizzando strumenti non convenzionali e adattarci al massimo al reale funzionamento della rete.
Proviamo a trovare o inventare qualcosa di simile.
Prima di inventare qualcosa, dobbiamo capire quale risultato vogliamo ottenere e quali funzioni deve svolgere il nostro sviluppo. Quali saranno i requisiti per il tunnel affinché possiamo operare nella massima segretezza?
Chiaramente, i requisiti possono variare notevolmente a seconda del caso, ma dall'esperienza sono evidenti i seguenti principali:
- funzionalità su sistemi operativi Windows 7-10, dato che nella maggior parte delle reti aziendali viene utilizzato proprio Windows;
- il client deve connettersi al server tramite SSL per escludere il semplice ascolto da parte degli IPS;
- nella connessione, il client deve supportare l'uso di un server proxy con autenticazione, poiché in molte aziende l'accesso a Internet avviene tramite proxy. In effetti, la macchina client può anche non saperlo, e il proxy viene utilizzato in modalità trasparente. Ma tale funzionalità deve essere prevista;
- la parte client deve essere concisa e portabile;
È ovvio che per lavorare all'interno della rete del Cliente, si può installare OpenVPN sulla macchina client e stabilire un tunnel completo fino al proprio server (dopotutto i client OpenVPN possono lavorare attraverso il proxy). Tuttavia, da un lato questo non sempre è possibile, dato che potremmo non essere amministratori locali, e dall'altro, potrebbe generare molto rumore, attirando l'attenzione di un SIEM o HIPS in modo che subito ci 'segnalino'. Idealmente, il nostro client dovrebbe essere una cosiddetta inline command, proprio come implementati molti shell bash, e avviarsi tramite la riga di comando, ad esempio, eseguendo comandi da un macro di Word. - il nostro tunnel deve essere multi-threaded e supportare più connessioni contemporaneamente;
- la connessione client-server deve avere qualche forma di autorizzazione, affinché il tunnel possa essere stabilito solo per il nostro cliente e non per chiunque si connetta al nostro server all'indirizzo e porto specificati. Idealmente, per 'utenti esterni' dovrebbe essere aperta una pagina di atterraggio con gattini o un tema professionale attinente al dominio originale.
Ad esempio, se il Cliente è un'organizzazione sanitaria, quando un amministratore della sicurezza informatica 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 il blog del dottor Komarovsky, ecc.
Analisi degli strumenti esistenti
Prima di inventare la propria bicicletta, è necessario analizzare le biciclette esistenti e comprendere se ne abbiamo realmente bisogno e, probabilmente, non siamo gli unici a pensarla in questo modo.
La ricerca su Internet (sembra che lo facciamo abbastanza bene), così come la ricerca su GitHub per parole chiave come «reverse socks», non ha dato molti risultati. Fondamentalmente, tutto si riduce alla creazione di tunnel ssh con port forwarding inverso e tutto ciò che ne consegue. Oltre ai tunnel SSH, possiamo evidenziare alcune soluzioni:
Una vecchia implementazione di tunnel inverso da parte dei ragazzi di Kaspersky Lab. Dal nome è chiaro a cosa serve questo script. Realizzato in Python 2.7, il tunnel funziona in modalità cleartext (come va di moda dire — saluti a RKN)
Un'altra implementazione in Python, anch'essa 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 Golang (non supportata dallo sviluppatore).
Il secondo link è il nostro miglioramento con funzionalità aggiuntive, sempre in Golang. Nella nostra versione abbiamo implementato SSL, funzionamento tramite proxy con autorizzazione NTLM, autorizzazione sul client, una landing page in caso di password errata (o meglio — un reindirizzamento alla landing page), modalità multithreading (cioè, con il tunnel possono lavorare più persone contemporaneamente), un sistema di ping del client per verificare se è attivo o meno.
Implementazione di reverse socks dai nostri 'amici cinesi' in Python. Qui c'è anche un binario già pronto (exe), assemblato dai cinesi e pronto all'uso. Solo un dio cinese sa cosa ci possa essere in questo binario, oltre alla funzionalità principale, quindi usalo a tuo rischio e pericolo.
Un progetto piuttosto interessante in C++ per implementare reverse socks e non solo. Oltre al tunnel inverso, può fare port forwarding, creare una shell di comando, ecc.
MSF meterpreter
Qui, come si suol dire, senza commenti. Tutti gli hacker con una minima istruzione conoscono bene questo strumento e capiscono quanto sia facile da rilevare per le soluzioni di sicurezza.
Tutti gli strumenti sopra descritti funzionano secondo una tecnologia simile: su una macchina all'interno della rete viene eseguito un modulo binario preparato in anticipo, il quale stabilisce una connessione con un server esterno. Sul server viene avviato un server SOCKS4/5 che accetta le connessioni e le trasmette al client.
Lo svantaggio di tutti gli strumenti sopra menzionati è che o sulla macchina client è necessario avere Python o Golang installati (quante volte hai trovato Python installato su macchine, ad esempio, un direttore d'azienda o impiegati?), oppure è necessario portare su quella macchina un binario già assemblato (praticamente Python e script in un'unica soluzione) e avviare quel binario lì. E caricando un exe con successivo avvio — questa è già una firma per l'antivirus locale o HIPS.
In generale, la conclusione è evidente — abbiamo bisogno di una soluzione su PowerShell. Ora ci pioveranno pomodori — dicono che PowerShell è già tutto esaurito, viene monitorato, bloccato, ecc. In realtà — non ovunque. Dichiariamo con responsabilità. A proposito, ci sono molteplici modi per eludere i bloccaggi (ecco di nuovo la frase alla moda su saluti a RKN 🙂), a partire da semplici rinominazioni di powershell.exe -> cmdd.exe e finendo con powerdll, ecc.
Iniziamo a inventare
È chiaro che prima di tutto daremo un'occhiata a Google e... non troveremo esattamente niente su questo tema (se qualcuno ha trovato — lasciate i link nei commenti). Esiste solo Socks5 su PowerShell, ma è un normale «socks» diretto, con una serie di svantaggi (di cui parleremo più avanti). Posso, ovviamente, trasformarlo in un reverse socks con un semplice movimento della mano, ma sarà solo un socks a thread singolo, il che per noi non è proprio ciò di cui abbiamo bisogno.
Quindi, non abbiamo trovato nulla di pronto, quindi dovremo comunque inventare la nostra bicicletta. Prenderemo come base la nostra back sock in golang, and we will implement the client for it in powershell.
RSocksTun
Allora, come funziona rsockstun?
Alla base del funzionamento di RsocksTun (d'ora in poi — rs) ci sono due componenti software — Yamux e il server Socks5. Il server Socks5 è un normale socks5 locale, viene avviato sul client. E la multiplexazione delle connessioni verso di esso (ricordate la multithreading?) è garantita da yamux (). Questo schema consente di avviare più server socks5 client e distribuire le connessioni esterne a essi, instradandole attraverso una singola connessione TCP (quasi come in meterpreter) dal client al server, realizzando così la modalità multithreading, senza la quale non potremmo semplicemente lavorare pienamente in una rete interna.
La funzione di yamux consiste nell'aggiungere un ulteriore livello di rete agli stream, implementandolo come un'intestazione di 12 byte per ogni pacchetto. (Qui utilizziamo intenzionalmente il termine «stream» e non «flusso», per non confondere il lettore con il termine di programmazione «thread» — che useremo anche in questo articolo). All'interno dell'intestazione yamux si trovano il numero dello stream, le flag per l'abilitazione/terminazione dello stream, il numero di byte trasmessi e la dimensione della finestra di trasmissione.
Oltre all'attivazione/terminazione dello stream, yamux implementa un meccanismo di keepalive che consente di monitorare la funzionalità del canale di comunicazione stabilito. Il funzionamento del meccanismo dei messaggi keepalive è configurato durante la creazione della sessione Yamux. Di fatto, ci sono solo due parametri: 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. Alla ricezione di un messaggio keepalive, la parte remota deve rispondere con un pacchetto avente esattamente lo stesso identificatore del messaggio (in effetti — un numero) che ha ricevuto. In generale, il keepalive è come un ping, ma per yamux.
Tutta la tecnica di funzionamento del multiplexer, i tipi di pacchetti, le flag di attivazione e terminazione delle connessioni e il meccanismo di trasmissione dei dati sono descritti in a yamux.
Conclusione della prima parte
Quindi, nella prima parte dell'articolo abbiamo introdotto alcuni strumenti per la creazione di tunnel inversi, esaminato i loro vantaggi e svantaggi, studiato il meccanismo di funzionamento del multiplexer Yamux e descritto i requisiti principali per il nuovo modulo powershell che stiamo creando. Nella prossima parte ci occuperemo dello sviluppo del modulo stesso, praticamente, da zero. Continuate a seguirci 🙂
Fonte: habr.com
