C'era una volta un pentest, ovvero Come rompere tutto con l'aiuto di un urologo e di Roskomnadzor

Questo articolo è stato scritto sulla base di un pentest di grande successo condotto dagli specialisti del Gruppo-IB un paio di anni fa: è accaduta una storia che potrebbe essere adattata per un film a Bollywood. Ora, probabilmente, seguirà la reazione del lettore: "Oh, un altro articolo di pubbliche relazioni, ancora una volta vengono ritratti, quanto sono bravi, non dimenticare di comprare un pentest". Ebbene, da un lato lo è. Tuttavia, ci sono una serie di altri motivi per cui è apparso questo articolo. Volevo mostrare cosa fanno esattamente i pentester, quanto può essere interessante e non banale questo lavoro, quali circostanze divertenti possono sorgere nei progetti e, soprattutto, mostrare materiale dal vivo con esempi reali.

Per ristabilire l’equilibrio della modestia nel mondo, tra poco scriveremo di un pentest che non è andato bene. Mostreremo come processi ben progettati in un'azienda possono proteggere da tutta una serie di attacchi, anche ben preparati, semplicemente perché questi processi esistono e funzionano davvero.

Anche per il cliente in questo articolo tutto è stato generalmente eccellente, almeno migliore del 95% del mercato nella Federazione Russa, secondo i nostri sentimenti, ma c'erano una serie di piccole sfumature che formavano una lunga catena di eventi, che prima ha portato ad una lunga relazione sul lavoro, e poi a questo articolo.

Quindi facciamo scorta di popcorn e benvenuti al romanzo poliziesco. Parola - Pavel Suprunyuk, responsabile tecnico del dipartimento “Audit e Consulenza” di Group-IB.

Parte 1. Dottore Pochkin

2018 C'è un cliente: un'azienda IT ad alta tecnologia, che a sua volta serve molti clienti. Vuole ottenere una risposta alla domanda: è possibile, senza alcuna conoscenza e accesso iniziali, lavorando via Internet, ottenere i diritti di amministratore di dominio Active Directory? Non sono interessato ad alcuna ingegneria sociale (oh, ma invano), non intendono interferire di proposito con il lavoro, ma potrebbero accidentalmente ricaricare un server che funziona in modo strano, ad esempio. Un ulteriore obiettivo è identificare il maggior numero possibile di altri vettori di attacco contro il perimetro esterno. L'azienda conduce regolarmente tali test e ora è arrivata la scadenza per un nuovo test. Le condizioni sono quasi tipiche, adeguate, comprensibili. Iniziamo.

C'è un nome del cliente: lascia che sia "Azienda", con il sito Web principale www.azienda.ru. Certo, il cliente si chiama diversamente, ma in questo articolo tutto sarà impersonale.
Conduco la ricognizione della rete: scopro quali indirizzi e domini sono registrati presso il cliente, disegno un diagramma di rete, come vengono distribuiti i servizi a questi indirizzi. Ottengo il risultato: più di 4000 indirizzi IP live. Guardo i domini di queste reti: fortunatamente la stragrande maggioranza sono reti destinate ai clienti del cliente, e formalmente non ci interessano. Il cliente la pensa allo stesso modo.

Rimane una rete con 256 indirizzi, per la quale a questo punto si comprende già la distribuzione dei domini e sottodomini per indirizzi IP, ci sono informazioni sulle porte scansionate, il che significa che è possibile cercare nei servizi quelli interessanti. Parallelamente, tutti i tipi di scanner vengono lanciati sugli indirizzi IP disponibili e separatamente sui siti web.

Ci sono molti servizi. Di solito questa è gioia per il pentester e l'anticipazione di una rapida vittoria, poiché più servizi ci sono, più ampio è il campo di attacco e più facile è trovare un artefatto. Un rapido sguardo ai siti web mostra che la maggior parte di essi sono interfacce web di prodotti noti di grandi aziende globali, che a quanto pare dicono di non essere i benvenuti. Chiedono nome utente e password, scuotono il campo per inserire il secondo fattore, chiedono un certificato client TLS o lo inviano a Microsoft ADFS. Alcuni sono semplicemente inaccessibili da Internet. Per alcuni è ovviamente necessario avere un cliente speciale a pagamento per tre stipendi o conoscere l'URL esatto da inserire. Tralasciamo un'altra settimana di graduale sconforto nel tentativo di "sfondare" versioni software per vulnerabilità note, cercando contenuti nascosti in percorsi web e account trapelati da servizi di terze parti come LinkedIn, cercando di indovinare anche le password utilizzandoli. come lo scavo di vulnerabilità nei siti Web autoprodotti: tra l'altro, secondo le statistiche, questo è oggi il vettore di attacchi esterni più promettente. Noterò immediatamente la pistola cinematografica che successivamente ha sparato.

Quindi, abbiamo trovato due siti che si distinguevano tra centinaia di servizi. Questi siti avevano una cosa in comune: se non si intraprende una meticolosa ricognizione della rete per dominio, ma si cercano direttamente le porte aperte o si prende di mira uno scanner di vulnerabilità utilizzando un intervallo IP noto, allora questi siti sfuggiranno alla scansione e semplicemente non saranno visibile senza conoscere il nome DNS. Forse sono stati persi prima, almeno, e i nostri strumenti automatici non hanno riscontrato alcun problema con loro, anche se sono stati inviati direttamente alla risorsa.

A proposito, cosa hanno trovato in generale gli scanner lanciati in precedenza. Lascia che te lo ricordi: per alcune persone “pentest” equivale a “scansione automatizzata”. Ma gli scanner di questo progetto non hanno detto nulla. Bene, il massimo è stato mostrato dalle vulnerabilità medie (3 su 5 in termini di gravità): su alcuni servizi un certificato TLS errato o algoritmi di crittografia obsoleti e sulla maggior parte dei siti Clickjacking. Ma questo non ti porterà al tuo obiettivo. Forse qui gli scanner sarebbero più utili, ma lascia che te lo ricordi: il cliente stesso può acquistare tali programmi e mettersi alla prova con essi e, a giudicare dai pessimi risultati, ha già controllato.

Torniamo ai siti “anomali”. Il primo è qualcosa come un Wiki locale con un indirizzo non standard, ma in questo articolo lasciamo che sia wiki.company[.]ru. Ha anche chiesto immediatamente login e password, ma tramite NTLM nel browser. Per l'utente, sembra una finestra ascetica che chiede di inserire un nome utente e una password. E questa è una cattiva pratica.

Una piccola nota. NTLM nei siti Web perimetrali è dannoso per una serie di motivi. Il primo motivo è che viene rivelato il nome di dominio di Active Directory. Anche nel nostro esempio è risultato essere company.ru, proprio come il nome DNS “esterno”. Sapendo questo, puoi preparare con cura qualcosa di dannoso in modo che venga eseguito solo sul computer del dominio dell'organizzazione e non in qualche sandbox. In secondo luogo, l’autenticazione passa direttamente attraverso il controller di dominio tramite NTLM (sorpresa, vero?), con tutte le funzionalità delle policy di rete “interne”, incluso il blocco degli account affinché non venga superato il numero di tentativi di immissione della password. Se un utente malintenzionato scopre gli accessi, proverà ad inserirne le password. Se sei configurato per impedire agli account di inserire password errate, funzionerà e l'account verrà bloccato. In terzo luogo, è impossibile aggiungere un secondo fattore a tale autenticazione. Se qualcuno dei lettori sa ancora come fare, per favore fatemelo sapere, è davvero interessante. In quarto luogo, la vulnerabilità agli attacchi pass-the-hash. ADFS è stato inventato, tra le altre cose, per proteggersi da tutto questo.

C'è una caratteristica negativa dei prodotti Microsoft: anche se non hai pubblicato specificatamente tale NTLM, verrà installato per impostazione predefinita almeno in OWA e Lync.

A proposito, l'autore di questo articolo una volta ha bloccato accidentalmente circa 1000 conti di dipendenti di una grande banca in una sola ora utilizzando lo stesso metodo e poi è apparso un po' pallido. Anche i servizi IT della banca erano pallidi, ma tutto è finito bene e in modo adeguato, siamo stati anche elogiati per essere stati i primi a individuare questo problema e provocare una soluzione rapida e decisiva.

Il secondo sito aveva l'indirizzo "ovviamente una specie di cognome.azienda.ru". L'ho trovato tramite Google, qualcosa del genere a pagina 10. Il design era dell'inizio della metà degli anni XNUMX e una persona rispettabile lo stava guardando dalla pagina principale, qualcosa del genere:

Qui ho preso un'immagine da “Heart of a Dog”, ma credetemi, era vagamente simile, anche il disegno dei colori aveva toni simili. Lascia che il sito venga chiamato preobrazenskij.company.ru.

Era un sito web personale... per un urologo. Mi chiedevo cosa ci facesse il sito web di un urologo nel sottodominio di un’azienda high-tech. Da una rapida indagine su Google è emerso che questo medico era cofondatore di una delle persone giuridiche di un nostro cliente e apportava addirittura circa 1000 rubli al capitale autorizzato. Il sito è stato probabilmente creato molti anni fa e le risorse del server del cliente sono state utilizzate come hosting. Il sito ha perso da tempo la sua rilevanza, ma per qualche motivo è stato lasciato in funzione per molto tempo.

In termini di vulnerabilità, il sito stesso era sicuro. Guardando al futuro, dirò che si trattava di un insieme di informazioni statiche: semplici pagine HTML con illustrazioni inserite sotto forma di reni e vesciche. È inutile “rompere” un sito del genere.

Ma il server web sottostante era più interessante. A giudicare dall'intestazione HTTP Server, aveva IIS 6.0, il che significa che utilizzava Windows 2003 come sistema operativo. Lo scanner aveva precedentemente identificato che questo particolare sito web dell'urologo, a differenza di altri host virtuali sullo stesso server web, rispondeva al comando PROPFIND, il che significa che stava eseguendo WebDAV. A proposito, lo scanner ha restituito queste informazioni con il segno Info (nel linguaggio dei rapporti dello scanner, questo è il pericolo più basso) - queste cose di solito vengono semplicemente saltate. In combinazione, ciò ha prodotto un effetto interessante, che è stato rivelato solo dopo un'altra indagine su Google: una rara vulnerabilità di buffer overflow associata al set Shadow Brokers, vale a dire CVE-2017-7269, che aveva già un exploit già pronto. In altre parole, ci saranno problemi se hai Windows 2003 e WebDAV è in esecuzione su IIS. Sebbene eseguire Windows 2003 in produzione nel 2018 sia di per sé un problema.

L'exploit è finito su Metasploit ed è stato subito testato con un carico che inviava una richiesta DNS a un servizio controllato: Burp Collaborator viene tradizionalmente utilizzato per intercettare le richieste DNS. Con mia sorpresa, ha funzionato la prima volta: è stato ricevuto un knockout DNS. Successivamente si è tentato di creare una backconnection tramite la porta 80 (ovvero una connessione di rete dal server all'aggressore, con accesso a cmd.exe sull'host della vittima), ma poi si è verificato un fiasco. La connessione non è avvenuta e dopo il terzo tentativo di utilizzo il sito, insieme a tutte le immagini interessanti, è scomparso per sempre.

Di solito questa è seguita da una lettera nello stile di “cliente, svegliati, abbiamo mollato tutto”. Ma ci è stato detto che il sito non ha nulla a che fare con i processi aziendali e funziona lì senza motivo, come l'intero server, e che possiamo utilizzare questa risorsa a nostro piacimento.
Circa un giorno dopo il sito ha iniziato improvvisamente a funzionare da solo. Dopo aver creato un bench da WebDAV su IIS 6.0, ho scoperto che l'impostazione predefinita prevede il riavvio dei processi di lavoro IIS ogni 30 ore. Cioè, quando il controllo usciva dallo shellcode, il processo di lavoro IIS terminava, quindi si riavviava un paio di volte e poi andava in pausa per 30 ore.

Poiché la connessione di ritorno a TCP non è riuscita la prima volta, ho attribuito questo problema a una porta chiusa. Cioè supponeva la presenza di una sorta di firewall che non permettesse il passaggio all'esterno delle connessioni in uscita. Ho iniziato a eseguire shellcode che cercavano attraverso molte porte tcp e udp, senza alcun effetto. I carichi di connessione inversa tramite http(s) da Metasploit non hanno funzionato: meterpreter/reverse_http(s). All'improvviso è stata stabilita una connessione alla stessa porta 80, ma è stata immediatamente interrotta. L'ho attribuito all'azione ancora immaginaria dell'IPS, a cui non piaceva il traffico di meterpreter. Alla luce del fatto che non è avvenuta una connessione TCP pura alla porta 80, ma una connessione http, ho concluso che nel sistema era in qualche modo configurato un proxy http.

Ho anche provato meterpreter tramite DNS (grazie d00kie per i tuoi sforzi, hai salvato molti progetti), ricordando il primissimo successo, ma non ha funzionato nemmeno sullo stand: lo shellcode era troppo voluminoso per questa vulnerabilità.

In realtà, era così: 3-4 tentativi di attacco entro 5 minuti, quindi attesa per 30 ore. E così via per tre settimane di seguito. Ho anche impostato un promemoria per non perdere tempo. Inoltre, c'era una differenza nel comportamento degli ambienti di test e di produzione: per questa vulnerabilità c'erano due exploit simili, uno di Metasploit, il secondo di Internet, convertito dalla versione di Shadow Brokers. Quindi, solo Metasploit è stato testato in combattimento, e solo il secondo è stato testato al banco, il che ha reso il debug ancora più difficile e spaccacervelli.

Alla fine si è rivelato efficace uno shellcode che scaricava un file exe da un determinato server tramite http e lo lanciava sul sistema di destinazione. Lo shellcode era abbastanza piccolo da adattarsi, ma almeno funzionava. Dato che al server non piaceva affatto il traffico TCP e l'http(s) veniva ispezionato per la presenza di meterpreter, ho deciso che il modo più veloce era scaricare un file exe che conteneva DNS-meterpreter attraverso questo shellcode.

Anche in questo caso si è verificato un problema: durante il download di un file exe e, come hanno dimostrato i tentativi, qualunque fosse, il download veniva interrotto. Ancora una volta, ad alcuni dispositivi di sicurezza tra il mio server e l'urologo non piaceva il traffico http con un file exe all'interno. La soluzione "rapida" sembrava essere quella di modificare lo shellcode in modo da offuscare al volo il traffico http, in modo che i dati binari astratti venissero trasferiti invece dell'exe. Alla fine, l’attacco ha avuto successo, il controllo è stato ricevuto attraverso il sottile canale DNS:

È diventato subito chiaro che dispongo dei diritti di base del flusso di lavoro IIS, che mi consentono di non fare nulla. Questo è quello che appariva sulla console Metasploit:

Tutte le metodologie pentest suggeriscono fortemente che è necessario aumentare i diritti quando si ottiene l'accesso. Di solito non lo faccio localmente, poiché il primo accesso è visto semplicemente come un punto di ingresso della rete e compromettere un'altra macchina sulla stessa rete è solitamente più semplice e veloce che aumentare i privilegi su un host esistente. Ma in questo caso non è così, poiché il canale DNS è molto stretto e non consente al traffico di disperdersi.

Supponendo che questo server Windows 2003 non sia stato riparato per la famosa vulnerabilità MS17-010, incanalo il traffico sulla porta 445/TCP attraverso il tunnel DNS meterpreter su localhost (sì, anche questo è possibile) e provo a eseguire l'exe precedentemente scaricato tramite la vulnerabilità. L'attacco funziona, ricevo una seconda connessione, ma con diritti SYSTEM.

È interessante notare che hanno comunque provato a proteggere il server da MS17-010: aveva i servizi di rete vulnerabili disabilitati sull'interfaccia esterna. Ciò protegge dagli attacchi sulla rete, ma l'attacco dall'interno su localhost ha funzionato, poiché non è possibile disattivare rapidamente SMB su localhost.

Successivamente, vengono rivelati nuovi dettagli interessanti:

1. Avendo i diritti SYSTEM, puoi facilmente stabilire una backconnection tramite TCP. Ovviamente, disabilitare il TCP diretto è strettamente un problema per l'utente IIS limitato. Spoiler: il traffico degli utenti IIS è stato in qualche modo incapsulato nel proxy ISA locale in entrambe le direzioni. Come funziona esattamente, non l'ho riprodotto.
2. Sono in una certa "DMZ" (e questo non è un dominio Active Directory, ma un GRUPPO DI LAVORO): sembra logico. Ma invece del previsto indirizzo IP privato (“grigio”), ho un indirizzo IP completamente “bianco”, esattamente lo stesso di quello che ho attaccato in precedenza. Ciò significa che l’azienda è così vecchia nel mondo dell’indirizzamento IPv4 che può permettersi di mantenere una zona DMZ per 128 indirizzi “bianchi” senza NAT secondo lo schema illustrato nei manuali Cisco del 2005.

Poiché il server è vecchio, è garantito che Mimikatz funzioni direttamente dalla memoria:

Ottengo la password dell'amministratore locale, tunnelo il traffico RDP su TCP e accedo a un desktop accogliente. Dato che potevo fare quello che volevo con il server, ho rimosso l'antivirus e ho scoperto che il server era accessibile da Internet solo tramite le porte TCP 80 e 443 e che la 443 non era occupata. Ho configurato un server OpenVPN su 443, aggiungo funzioni NAT per il mio traffico VPN e ottengo l'accesso diretto alla rete DMZ in forma illimitata tramite il mio OpenVPN. È interessante notare che ISA, avendo alcune funzioni IPS non disabilitate, ha bloccato il mio traffico con la scansione delle porte, per cui è stato necessario sostituirlo con un RRAS più semplice e conforme. Quindi i pentester a volte devono ancora amministrare ogni genere di cose.

Un lettore attento chiederà: "E il secondo sito: un wiki con autenticazione NTLM, su cui è stato scritto così tanto?" Ne parleremo più avanti.

Parte 2. Ancora non crittografi? Allora veniamo da te già qui

Quindi, c'è accesso al segmento di rete DMZ. Devi andare dall'amministratore del dominio. La prima cosa che mi viene in mente è verificare automaticamente la sicurezza dei servizi all'interno del segmento DMZ, soprattutto perché molti di essi sono ora aperti alla ricerca. Un quadro tipico durante un penetration test: il perimetro esterno è protetto meglio dei servizi interni e quando si ottiene l'accesso all'interno di una grande infrastruttura, è molto più facile ottenere diritti estesi su un dominio solo perché questo dominio inizia ad essere accessibile agli strumenti e, in secondo luogo, in un'infrastruttura con diverse migliaia di host, ci saranno sempre un paio di problemi critici.

Carico gli scanner tramite DMZ tramite un tunnel OpenVPN e aspetto. Apro il rapporto: anche in questo caso niente di grave, a quanto pare qualcuno ha seguito lo stesso metodo prima di me. Il passaggio successivo consiste nell'esaminare il modo in cui comunicano gli host all'interno della rete DMZ. Per fare ciò, avvia prima il solito Wireshark e ascolta le richieste di trasmissione, principalmente ARP. I pacchetti ARP venivano raccolti durante tutta la giornata. Risulta che in questo segmento vengono utilizzati diversi gateway. Questo tornerà utile più tardi. Combinando i dati sulle richieste e risposte ARP e i dati di scansione delle porte, ho trovato i punti di uscita del traffico degli utenti dall'interno della rete locale oltre a quei servizi precedentemente noti, come web e posta.

Poiché al momento non avevo accesso ad altri sistemi e non avevo un unico account per i servizi aziendali, si è deciso di ripescare almeno qualche account dal traffico utilizzando ARP Spoofing.

Cain&Abel è stato lanciato sul server dell'urologo. Tenendo conto dei flussi di traffico identificati, sono state selezionate le coppie più promettenti per l'attacco man-in-the-middle, quindi una parte del traffico di rete è stata ricevuta tramite lancio a breve termine per 5-10 minuti, con un timer per riavviare il server in caso di congelamento. Come nello scherzo, le novità erano due:

1. Bene: sono state catturate molte credenziali e l'attacco nel suo insieme ha funzionato.
2. Il cattivo: tutte le credenziali provenivano dai clienti del cliente. Durante la fornitura dei servizi di supporto, gli specialisti dei clienti si collegavano ai servizi dei clienti che non sempre avevano configurato la crittografia del traffico.

Di conseguenza, ho acquisito molte credenziali inutili nel contesto del progetto, ma sicuramente interessanti come dimostrazione della pericolosità dell'attacco. Router di confine di grandi aziende con telnet, porte http di debug inoltrate al CRM interno con tutti i dati, accesso diretto a RDP da Windows XP sulla rete locale e altri oscurantismi. È andata così Compromesso della Supply Chain secondo la matrice MITRE.

Ho anche trovato un'occasione divertente per raccogliere lettere dal traffico, qualcosa del genere. Questo è un esempio di una lettera già pronta che è andata dal nostro cliente alla porta SMTP del suo cliente, ancora una volta, senza crittografia. Un certo Andrey chiede al suo omonimo di inviare nuovamente la documentazione e questa viene caricata su un disco cloud con login, password e collegamento in una lettera di risposta:

Questo è un altro promemoria per crittografare tutti i servizi. Non è noto chi e quando leggerà e utilizzerà specificamente i tuoi dati: il provider, l'amministratore di sistema di un'altra azienda o un simile pentester. Taccio sul fatto che molte persone possono semplicemente intercettare il traffico non crittografato.

Nonostante l'apparente successo, questo non ci ha avvicinato all'obiettivo. Ovviamente era possibile sedersi a lungo e ripescare informazioni preziose, ma non è un dato di fatto che appaiano lì e l'attacco stesso è molto rischioso in termini di integrità della rete.

Dopo un'altra indagine sui servizi, mi è venuta in mente un'idea interessante. Esiste un'utilità chiamata Responder (è facile trovare esempi di utilizzo con questo nome) che, "avvelenando" le richieste di trasmissione, provoca connessioni tramite una varietà di protocolli come SMB, HTTP, LDAP, ecc. in modi diversi, chiede poi a chiunque si connetta di autenticarsi e fa in modo che l'autenticazione avvenga tramite NTLM e in modalità trasparente per la vittima. Molto spesso, un utente malintenzionato raccoglie gli handshake NetNTLMv2 in questo modo e da essi, utilizzando un dizionario, recupera rapidamente le password del dominio utente. Qui volevo qualcosa di simile, ma gli utenti sedevano “dietro un muro”, o meglio, erano separati da un firewall, e accedevano al WEB tramite il cluster proxy Blue Coat.

Ricorda, ho specificato che il nome del dominio Active Directory coincideva con il dominio "esterno", cioè era company.ru? Quindi, Windows, più precisamente Internet Explorer (e Edge e Chrome), consentono all'utente di autenticarsi in modo trasparente in HTTP tramite NTLM se considera che il sito si trova in una qualche “Zona Intranet”. Uno dei segni di una “Intranet” è l'accesso ad un indirizzo IP “grigio” o ad un nome DNS breve, cioè senza punti. Poiché avevano un server con un IP "bianco" e un nome DNS preobrazhensky.company.ru e le macchine del dominio di solito ricevono il suffisso del dominio Active Directory tramite DHCP per l'immissione semplificata del nome, dovevano solo scrivere l'URL nella barra degli indirizzi Preobrazenskij, affinché trovino la strada giusta verso il server dell’urologo compromesso, senza dimenticare che questo ora si chiama “Intranet”. Cioè, fornendomi allo stesso tempo l'handshake NTLM dell'utente a sua insaputa. Non resta che forzare i browser client a pensare all'urgente necessità di contattare questo server.

La meravigliosa utility Intercepter-NG è venuta in soccorso (grazie intercettare). Ti consentiva di modificare il traffico al volo e funzionava benissimo su Windows 2003. Aveva anche funzionalità separate per modificare solo i file JavaScript nel flusso di traffico. Era prevista una sorta di Cross-Site Scripting massiccio.

I proxy Blue Coat, attraverso i quali gli utenti accedevano al WEB globale, memorizzavano periodicamente nella cache il contenuto statico. Intercettando il traffico, era chiaro che lavoravano XNUMX ore su XNUMX, richiedendo incessantemente informazioni statiche utilizzate di frequente per accelerare la visualizzazione dei contenuti durante le ore di punta. Inoltre, BlueCoat disponeva di uno User-Agent specifico, che lo distingueva chiaramente da un utente reale.

È stato preparato Javascript che, utilizzando Intercepter-NG, è stato implementato per un'ora di notte per ogni risposta con file JS per Blue Coat. Lo script ha fatto quanto segue:

• Determinato il browser corrente da User-Agent. Se fosse Internet Explorer, Edge o Chrome, continuava a funzionare.
• Ho aspettato fino alla formazione del DOM della pagina.
• Inserita un'immagine invisibile nel DOM con un attributo src del modulo Preobrazenskij:8080/NNNNNNN.png, dove NNN sono numeri arbitrari in modo che BlueCoat non lo memorizzi nella cache.
• Imposta una variabile flag globale per indicare che l'iniezione è stata completata e non è più necessario inserire immagini.

Il browser ha provato a caricare questa immagine; sulla porta 8080 del server compromesso, un tunnel TCP la attendeva verso il mio portatile, dove era in esecuzione lo stesso Responder, che richiedeva al browser di accedere tramite NTLM.

A giudicare dai registri di Responder, le persone sono arrivate al lavoro la mattina, hanno acceso le loro postazioni di lavoro, quindi in massa e inosservate hanno iniziato a visitare il server dell'urologo, senza dimenticare di "drenare" gli handshake NTLM. Sono piovute strette di mano tutto il giorno e si è evidentemente accumulato materiale per un attacco evidentemente riuscito per recuperare le password. Ecco come apparivano i log del risponditore:

Visite segrete di massa al server dell'urologo da parte degli utenti

Probabilmente hai già notato che l'intera storia è costruita sul principio "tutto andava bene, ma poi c'è stata una delusione, poi c'è stato un superamento e poi tutto è arrivato al successo". Quindi, c'è stato un peccato qui. Delle cinquanta strette di mano uniche, non ne è stata rivelata nemmeno una. E questo tiene conto del fatto che anche su un laptop con un processore guasto, questi handshake NTLMv2 vengono elaborati a una velocità di diverse centinaia di milioni di tentativi al secondo.

Ho dovuto armarmi di tecniche di mutazione della password, di una scheda video, di un dizionario più spesso e aspettare. Dopo molto tempo, sono stati rivelati diversi account con password nella forma "Q11111111....1111111q", il che suggerisce che tutti gli utenti una volta erano costretti a inventare una password molto lunga con caratteri diversi, che avrebbe dovuto anche essere complesso. Ma non puoi ingannare un utente esperto, ed è così che è riuscito a ricordarlo più facilmente. In totale, sono stati compromessi circa 5 account e solo uno di essi aveva diritti preziosi sui servizi.

Parte 3. Roskomnadzor risponde al contrattacco

Quindi sono stati ricevuti i primi account di dominio. Se a questo punto non ti sei addormentato dopo una lunga lettura, probabilmente ricorderai che ho menzionato un servizio che non richiedeva un secondo fattore di autenticazione: è un wiki con autenticazione NTLM. Naturalmente la prima cosa da fare era entrare lì. L'analisi della base di conoscenza interna ha portato rapidamente risultati:

• L'azienda dispone di una rete WiFi con autenticazione tramite account di dominio con accesso alla rete locale. Con l'attuale set di dati, questo è già un vettore di attacco funzionante, ma è necessario andare in ufficio con i piedi e trovarsi da qualche parte nel territorio dell'ufficio del cliente.
• Ho trovato un'istruzione secondo la quale esisteva un servizio che consentiva... di registrare autonomamente un dispositivo di autenticazione del “secondo fattore” se l'utente si trova all'interno di una rete locale e ricorda con sicurezza il login e la password del dominio. In questo caso, “dentro” e “fuori” erano determinati dall'accessibilità del porto di questo servizio all'utente. La porta non era accessibile da Internet, ma era abbastanza accessibile tramite la DMZ.

Naturalmente all’account compromesso è stato immediatamente aggiunto un “secondo fattore” sotto forma di applicazione sul mio telefono. Esisteva un programma che poteva inviare ad alta voce una richiesta push al telefono con i pulsanti "approva"/"disapprovare" per l'azione, oppure mostrare silenziosamente il codice OTP sullo schermo per un'ulteriore immissione indipendente. Inoltre, il primo metodo avrebbe dovuto essere l'unico corretto secondo le istruzioni, ma non ha funzionato, a differenza del metodo OTP.

Con il "secondo fattore" interrotto, sono riuscito ad accedere alla posta di Outlook Web Access e all'accesso remoto in Citrix Netscaler Gateway. C'era una sorpresa nella posta in Outlook:

In questo raro scatto puoi vedere come Roskomnadzor aiuta i pentester

Erano i primi mesi dopo il famoso blocco “fan” di Telegram, quando intere reti con migliaia di indirizzi sparivano inesorabilmente dall'accesso. È diventato chiaro perché il push non ha funzionato subito e perché la mia “vittima” non ha suonato l’allarme perché ha iniziato a utilizzare il suo account durante gli orari di apertura.

Chi ha familiarità con Citrix Netscaler immagina che di solito sia implementato in modo tale da poter trasmettere all'utente solo un'interfaccia grafica, cercando di non fornirgli gli strumenti per avviare applicazioni di terze parti e trasferire dati, limitando in ogni modo le azioni attraverso shell di controllo standard. La mia “vittima”, a causa della sua occupazione, ha ricevuto solo 1C:

Dopo aver esplorato un po' l'interfaccia 1C, ho scoperto che lì sono presenti moduli di elaborazione esterni. Possono essere caricati dall'interfaccia e verranno eseguiti sul client o sul server, a seconda dei diritti e delle impostazioni.

Ho chiesto ai miei amici programmatori 1C di creare un'elaborazione che accettasse una stringa e la eseguisse. Nel linguaggio 1C, l'avvio di un processo assomiglia a questo (preso da Internet). Sei d'accordo sul fatto che la sintassi della lingua 1C stupisca i russofoni con la sua spontaneità?

L'elaborazione è stata eseguita perfettamente, si è rivelata quella che i pentester chiamano "shell": Internet Explorer è stato lanciato attraverso di essa.

In precedenza, nella posta veniva trovato l'indirizzo del sistema che consente di ordinare abbonamenti al territorio. Ho ordinato un pass nel caso dovessi utilizzare un vettore di attacco WiFi.

Si dice su Internet che c'era ancora un delizioso catering gratuito presso la sede del cliente, ma ho comunque preferito sviluppare l'attacco da remoto, è più tranquillo.

AppLocker è stato attivato sul server delle applicazioni che esegue Citrix, ma è stato ignorato. Lo stesso Meterpreter è stato caricato e avviato tramite DNS, poiché le versioni http(s) non volevano connettersi e in quel momento non conoscevo l'indirizzo proxy interno. A proposito, da questo momento in poi, il pentest esterno si è sostanzialmente completamente trasformato in interno.

Parte 4. I diritti di amministratore per gli utenti sono negativi, ok?

Il primo compito di un pentester quando ottiene il controllo di una sessione utente di dominio è raccogliere tutte le informazioni sui diritti nel dominio. Esiste un'utilità BloodHound che consente automaticamente di scaricare informazioni su utenti, computer, gruppi di sicurezza tramite il protocollo LDAP da un controller di dominio e tramite SMB - informazioni su quale utente ha effettuato l'accesso di recente, dove e chi è l'amministratore locale.

Una tecnica tipica per impossessarsi dei diritti di amministratore di dominio sembra semplificata come un ciclo di azioni monotone:

• Andiamo ai computer del dominio in cui sono presenti diritti di amministratore locale, in base agli account di dominio già acquisiti.
• Lanciamo Mimikatz e otteniamo password memorizzate nella cache, ticket Kerberos e hash NTLM degli account di dominio che hanno recentemente effettuato l'accesso a questo sistema. Oppure rimuoviamo l'immagine della memoria del processo lsass.exe e facciamo lo stesso dalla nostra parte. Funziona bene con Windows precedenti a 2012R2/Windows 8.1 con impostazioni predefinite.
• Determiniamo dove gli account compromessi hanno i diritti di amministratore locale. Ripetiamo il primo punto. Ad un certo punto otteniamo i diritti di amministratore per l'intero dominio.

“Fine del ciclo;”, come scriverebbero qui i programmatori 1C.

Quindi, il nostro utente si è rivelato essere un amministratore locale su un solo host con Windows 7, il cui nome includeva la parola "VDI" o "Virtual Desktop Infrastructure", macchine virtuali personali. Probabilmente, il progettista del servizio VDI intendeva che, poiché VDI è il sistema operativo personale dell'utente, anche se l'utente modifica l'ambiente software a suo piacimento, l'host può comunque essere “ricaricato”. Ho anche pensato che in generale l'idea fosse buona, sono andato da questo host VDI personale e ho fatto un nido lì:

• Lì ho installato un client OpenVPN, che ha creato un tunnel attraverso Internet fino al mio server. Il cliente ha dovuto essere costretto a passare attraverso lo stesso Blue Coat con l'autenticazione del dominio, ma OpenVPN lo ha fatto, come si suol dire, "fuori dagli schemi".
• OpenSSH installato su VDI. Bene, davvero, cos'è Windows 7 senza SSH?

Questo è quello che sembrava dal vivo. Lascia che ti ricordi che tutto questo deve essere fatto tramite Citrix e 1C:

Una tecnica per promuovere l'accesso ai computer vicini consiste nel verificare la corrispondenza delle password dell'amministratore locale. Qui la fortuna è subito arrivata: l'hash NTLM dell'amministratore locale predefinito (che improvvisamente è stato chiamato Administrator) è stato attaccato tramite un attacco pass-the-hash agli host VDI vicini, di cui ce n'erano diverse centinaia. Naturalmente, l'attacco li ha colpiti immediatamente.

È qui che gli amministratori VDI si sono dati la zappa sui piedi due volte:

• La prima volta è stata quando le macchine VDI non sono state portate sotto LAPS, mantenendo essenzialmente la stessa password di amministratore locale dell'immagine distribuita in modo massiccio su VDI.
• L'amministratore predefinito è l'unico account locale vulnerabile agli attacchi pass-the-hash. Anche con la stessa password sarebbe possibile evitare compromissioni di massa creando un secondo account amministratore locale con una password casuale complessa e bloccando quella predefinita.

Perché c'è un servizio SSH su quel Windows? Molto semplice: ora il server OpenSSH non solo fornisce una comoda shell di comandi interattiva senza interferire con il lavoro dell'utente, ma anche un proxy calzini5 su VDI. Attraverso questi calzini, mi sono connesso tramite SMB e ho raccolto gli account memorizzati nella cache da tutte queste centinaia di macchine VDI, quindi ho cercato il percorso dell'amministratore del dominio utilizzandoli nei grafici di BloodHound. Con centinaia di host a mia disposizione, ho trovato questa soluzione abbastanza rapidamente. Sono stati ottenuti i diritti di amministratore di dominio.

Ecco un'immagine da Internet che mostra una ricerca simile. Le connessioni mostrano chi si trova dove si trova l'amministratore e chi ha effettuato l'accesso e dove.

A proposito, ricorda la condizione fin dall'inizio del progetto: "non utilizzare l'ingegneria sociale". Quindi, propongo di pensare a quanto verrebbe tagliata tutta questa Bollywood con effetti speciali se fosse ancora possibile utilizzare il banale phishing. Ma personalmente è stato molto interessante per me fare tutto questo. Spero che ti sia piaciuto leggere questo. Naturalmente, non tutti i progetti sembrano così intriganti, ma il lavoro nel suo insieme è molto impegnativo e non gli consente di ristagnare.

Probabilmente qualcuno avrà una domanda: come proteggersi? Anche questo articolo descrive molte tecniche, molte delle quali gli amministratori di Windows non conoscono nemmeno. Tuttavia, propongo di esaminarli dal punto di vista dei principi banali e delle misure di sicurezza delle informazioni:

• non utilizzare software obsoleti (ricordate Windows 2003 all'inizio?)
• non tenere accesi sistemi non necessari (perché esisteva il sito di un urologo?)
• controlla tu stesso le password degli utenti per forza (altrimenti i soldati... pentesters lo faranno)
• non avere le stesse password per account diversi (compromissione VDI)
• e un altro

Naturalmente, questo è molto difficile da implementare, ma nel prossimo articolo mostreremo in pratica che è del tutto possibile.

Fonte: habr.com