Khunt-aanval: Hoe hackers een Oracle database ombouwden tot een post-exploitatieplatform

Hoe de aanval werkte: SQL-injectie via een automatische aanvulzoekopdracht

Het eerste toegangspunt was een SQL-injectiekwetsbaarheid in een openbare Java-applicatie die op Apache Tomcat draaide . De automatische aanvulfunctie van de applicatie controleerde gebruikersinvoer niet goed, waardoor aanvallers SQL-commando's konden injecteren via een JDBC-verbinding met de Oracle-database . Zoals Huntress-onderzoekers opmerkten, was dit geen nieuw type kwetsbaarheid – SQL-injectie-aanvallen bestaan al tientallen jaren en zijn meestal het gevolg van het niet correct afhandelen van gebruikersinvoer naar de SQL-server . Het feit dat de applicatie een simpel zoekveld niet controleerde, was voldoende om de hele keten van compromittering in gang te zetten.

De Khunt-toolkit: levend in de database als Java-objecten

In plaats van traditionele malwarebestanden op de gecompromitteerde server te plaatsen, gebruikten de aanvallers Oracle's ingebouwde Java Virtual Machine (JVM) en de CREATE JAVA SOURCE-instructie om de volledige post-exploitatie-toolkit te compileren en op te slaan als Java-schema-objecten in de Oracle-database . Deze aanpak maakte de toolkit onzichtbaar voor standaard OS-beveiliging, omdat EDR- en antivirusprogramma's zich richten op processen, binaire bestanden en bestanden op het besturingssysteem – ze inspecteren over het algemeen geen Java-klassen en PL/SQL-wrappers die in Oracle zijn opgeslagen .

De khunt-toolkit bevatte de volgende componenten, elk opgeslagen als een databaseobject:

Volledige systeemcontrole bereiken: van database naar Windows-besturingssysteem

De aanvallers bleven niet steken op databaseniveau. Ze gebruikten de khunt-toolkit om in een meerstappenproces van de databaselaag naar het onderliggende Windows-besturingssysteem te gaan:

1. OS-commando-uitvoering via KhuntCmd: Ze gebruikten de KhuntCmd-module om cmd.exe /c whoami uit te voeren, waarmee werd bevestigd dat ze met SYSTEM-rechten op de Windows-server draaiden. Dit gaf hen externe code-uitvoering (RCE) van de database naar het OS .
2. Diefstal van inloggegevens: Ze gebruikten PowerShell om reg.exe aan te roepen en de SECURITY- en SYSTEM-register-hives te kopiëren, opgeslagen als khuntSECURITY.hiv en khuntSYSTEM.hiv in F:\Oracle\ .
3. Service-inventarisatie: Ze voerden tasklist /svc uit en sloegen de uitvoer op als khunttasks.txt .
4. Extra hive-extractie: Ze gebruikten esentutl.exe om de SAM en een tweede kopie van de SECURITY-hives te kopiëren, opgeslagen als khuntSAM.hiv en khunt_SECURITY.hiv .

De geëxfiltreerde register-hives konden offline worden gebruikt om wachtwoordhashes voor alle lokale accounts op het systeem te extraheren en te decoderen .

Blinde vlekken in de verdediging: belangrijkste bevindingen van Huntress

Het onderzoek van Huntress bracht verschillende kritieke blinde vlekken aan het licht die deze aanval mogelijk maakten:

• Database als bruggenhoofd: De database werd omgevormd van een passieve gegevensopslag naar een actief aanvalsplatform, waarbij de kwaadaardige toolkit in de database leefde in plaats van op de schijf of in het geheugen .
• EDR/AV-ontwijking: Traditionele EDR- en antivirusprogramma's inspecteren over het algemeen geen Java-klassen en PL/SQL-wrappers die in Oracle zijn opgeslagen, waardoor de toolkit onzichtbaar was voor standaard OS-beveiliging .
• Klassiek lek, nieuwe aanpak: De eerste SQL-injectie was een bekende fout. Er was geen zero-day voor nodig. Het automatische aanvulveld was genoeg om PL/SQL en vervolgens het OS te bereiken, wat laat zien dat basisinvoervalidatiefouten kunnen leiden tot diepgaande compromittering als de database-engine OS-mogelijkheden heeft .
• Overbemande database-accounts: Zelfs na een succesvolle SQL-injectie is de schade beperkt als het database-account geen rechten heeft om Java-bronnen te schrijven of opgeslagen procedures uit te voeren. Organisaties kennen database-accounts vaak te veel rechten toe, waardoor aanvallers de extra machtigingen krijgen die nodig zijn om khunt te implementeren .

Maatregelen aanbevolen door Huntress

Op basis van deze aanval beval Huntress de volgende maatregelen aan :

• Grondige invoervalidatie en parameterisatie van query's voor alle webinvoer
• Beperken van database-accountrechten, zodat zelfs geïnjecteerde query's geen Java-bronnen kunnen maken of willekeurige opgeslagen procedures kunnen uitvoeren
• Uitbreiden van de bewakingsscope naar database-objecten (Java-klassen, PL/SQL-wrappers) in plaats van alleen OS-niveau-artefacten

Deze aanval dient als een duidelijke herinnering dat database-engines met ingebouwde programmeeromgevingen (zoals Oracle's JVM) stille aanvalsplatforms kunnen worden wanneer ze worden gecombineerd met slechts één ongevalideerd invoerveld. Beveiligingsteams moeten hun bewaking uitbreiden tot voorbij het besturingssysteem en ook de databaselaag in de gaten houden.