Attacco Khunt: quando un database Oracle diventa una piattaforma di attacco invisibile

Il toolkit Khunt: vivere all'interno del database come oggetti Java

Invece di distribuire file malware tradizionali sul server compromesso, gli aggressori hanno utilizzato la Java Virtual Machine (JVM) integrata di Oracle e l'istruzione CREATE JAVA SOURCE per compilare e memorizzare l'intero toolkit post-exploitation come oggetti schema Java all'interno del database Oracle . Questo approccio ha reso il toolkit invisibile alle difese standard a livello di sistema operativo, perché gli strumenti EDR e antivirus si concentrano su processi, binari e file del sistema operativo e non ispezionano generalmente le classi Java e i wrapper PL/SQL memorizzati all'interno di Oracle .

Il toolkit khunt includeva questi componenti, ciascuno memorizzato come oggetto del database:

Ottenere il controllo completo del sistema: dal database al sistema operativo Windows

Gli aggressori non si sono fermati all'accesso a livello di database. Hanno utilizzato il toolkit khunt per passare dal livello del database al sistema operativo Windows sottostante in un processo a più fasi:

1. Esecuzione di comandi del sistema operativo tramite KhuntCmd: Hanno utilizzato il modulo KhuntCmd per eseguire cmd.exe /c whoami, che ha confermato che stavano operando con privilegi di livello SYSTEM sul server Windows, stabilendo l'esecuzione di codice remoto (RCE) dal database al sistema operativo .
2. Furto di credenziali: Hanno utilizzato PowerShell per invocare reg.exe e copiare i file del registro SECURITY e SYSTEM, salvandoli come khuntSECURITY.hiv e khuntSYSTEM.hiv in F:\Oracle\ .
3. Enumerazione dei servizi: Hanno eseguito tasklist /svc e salvato l'output come khunttasks.txt .
4. Estrazione aggiuntiva di file del registro: Hanno utilizzato esentutl.exe per copiare il file SAM e una seconda copia del file SECURITY, salvandoli come khuntSAM.hiv e khunt_SECURITY.hiv .

I file del registro esfiltrati potevano essere utilizzati offline per estrarre e decodificare gli hash delle password di tutti gli account locali sul sistema .

Punti ciechi della difesa: le scoperte chiave di Huntress

L'indagine di Huntress ha rivelato diversi punti ciechi critici che hanno permesso a questo attacco di avere successo e di eludere il rilevamento:

• Il database come testa di ponte: Il database è stato trasformato da archivio dati passivo in piattaforma di attacco attiva, con il toolkit dannoso che viveva all'interno del database anziché su disco o in memoria .
• Elusione di EDR/AV: Gli strumenti tradizionali di rilevamento e risposta sugli endpoint (EDR) e gli antivirus non ispezionano generalmente le classi Java e i wrapper PL/SQL memorizzati all'interno di Oracle, rendendo il toolkit invisibile alle difese standard a livello di sistema operativo .
• Vulnerabilità classica, consegna innovativa: L'SQL injection iniziale era una classe di bug ben nota. Non era necessaria alcuna vulnerabilità zero-day. La funzione di ricerca autocomplete è stata sufficiente per raggiungere PL/SQL e poi il sistema operativo, dimostrando che i fallimenti di base nella convalida degli input possono portare a una compromissione profonda quando il motore del database ha capacità a livello di sistema operativo .
• Account di database con privilegi eccessivi: Anche dopo che un SQL injection ha successo, il danno è limitato se l'account utente del database non ha i privilegi per creare origini Java o eseguire procedure memorizzate. Le organizzazioni spesso forniscono agli account di database privilegi eccessivi, dando agli aggressori le autorizzazioni extra necessarie per distribuire khunt .

Mitigazioni raccomandate da Huntress

Sulla base di questo attacco, Huntress ha raccomandato diverse misure di mitigazione :

• Sanificazione corretta degli input e parameterizzazione delle query per tutti gli input web
• Limitazione dei privilegi degli utenti del database in modo che anche le query iniettate non possano creare origini Java o eseguire procedure memorizzate arbitrarie
• Espansione del perimetro di monitoraggio per includere gli oggetti del database (classi Java, wrapper PL/SQL) anziché solo gli artefatti a livello di sistema operativo

Questo attacco serve come un duro promemoria del fatto che i motori di database con ambienti di programmazione integrati (come la JVM di Oracle) possono diventare piattaforme di attacco furtive se combinati anche con un singolo campo di input non convalidato. I team di sicurezza devono estendere il loro monitoraggio oltre il sistema operativo per includere il livello degli oggetti del database.