Khunt-angrebet: Sådan blev en Oracle-database til en skjult hacker-platform

Sådan fungerede angrebet: SQL-injektion gennem en autocomplete-søgning

Det indledende indbrud skete via en SQL-injektionssårbarhed i en offentligt tilgængelig Java-applikation, der kørte på Apache Tomcat . Applikationens autocomplete-søgefunktion validerede ikke brugerinput korrekt, hvilket gjorde det muligt for angriberne at injicere SQL-kommandoer gennem en JDBC-forbindelse til Oracle-databasen . Som Huntress' forskere påpegede, er dette ikke en ny sårbarhedstype – SQL-injektionsangreb har eksisteret i årtier og skyldes typisk, at brugerinput ikke håndteres korrekt, før det sendes til SQL-serveren . Applikationens manglende evne til at rense et simpelt søgefelt var nok til at starte en kæde af kompromittering.

Khunt-værktøjskassen: Lever inde i databasen som Java-objekter

I stedet for at implementere traditionel malware på den kompromitterede server brugte angriberne Oracles indbyggede JVM og CREATE JAVA SOURCE-erklæringen til at kompilere og gemme hele post-eksploiteringsværktøjskassen som Java-schemaobjekter inde i Oracle-databasen . Denne tilgang gjorde værktøjskassen usynlig for standard OS-niveau-forsvar, fordi EDR- og antivirusværktøjer fokuserer på processer, binære filer og filer på operativsystemet – de inspicerer generelt ikke Java-klasser og PL/SQL-indpakninger gemt inde i Oracle .

Khunt-værktøjskassen indeholdt følgende komponenter, hver gemt som et databaseobjekt:

Fuld systemkontrol: Fra database til Windows OS

Angriberne stoppede ikke ved database-niveau-adgang. De brugte khunt-værktøjskassen til at bevæge sig fra databaselaget til det underliggende Windows-operativsystem i en flertrinsproces:

1. OS-kommandoeksekvering via KhuntCmd: De brugte KhuntCmd-modulet til at køre cmd.exe /c whoami, hvilket bekræftede, at de kørte med SYSTEM-rettigheder på Windows-serveren, hvilket etablerede fjernkodekørsel (RCE) fra databasen til operativsystemet .
2. Tyveri af legitimationsoplysninger: De brugte PowerShell til at kalde reg.exe og kopiere SECURITY- og SYSTEM-registreringsdatabasenøglerne, som de gemte som khuntSECURITY.hiv og khuntSYSTEM.hiv i F:\Oracle\ .
3. Tjenesteopregning: De kørte tasklist /svc og gemte output som khunttasks.txt .
4. Yderligere nøgleudtrækning: De brugte esentutl.exe til at kopiere SAM- og en ekstra kopi af SECURITY-nøglerne, gemt som khuntSAM.hiv og khunt_SECURITY.hiv .

De eksfiltrerede registreringsdatabasenøgler kunne bruges offline til at udtrække og dekode adgangskodehashes for alle lokale konti på systemet .

Forsvarsmæssige blinde vinkler: Huntress' vigtigste fund

Huntress' undersøgelse afslørede flere kritiske blinde vinkler, der gjorde dette angreb muligt og svært at opdage:

• Database som angrebsplatform: Databasen blev forvandlet fra en passiv datalager til en aktiv angrebsplatform, hvor den ondsindede værktøjskasse levede inde i databasen i stedet for på disken eller i hukommelsen .
• EDR/AV-omgåelse: Traditionelle EDR- og antivirusværktøjer inspicerer generelt ikke Java-klasser og PL/SQL-indpakninger gemt i Oracle, hvilket gjorde værktøjskassen usynlig for standardforsvar på OS-niveau .
• Klassisk sårbarhed, ny leveringsmetode: Den indledende SQL-injektion var en velkendt fejltype. Der var ikke brug for en zero-day-sårbarhed. Autocomplete-søgefunktionen var nok til at nå PL/SQL og derefter operativsystemet, hvilket viser, at grundlæggende valideringsfejl kan føre til dyb kompromittering, når database-motoren har OS-niveau-kapaciteter .
• Overprivilegerede databasekonti: Selv efter en vellykket SQL-injektion er skaden begrænset, hvis databasebrugerkontoen mangler rettigheder til at oprette Java-kilder eller udføre lagrede procedurer. Organisationer giver ofte databasekonti for mange rettigheder, hvilket giver angribere de ekstra tilladelser, der er nødvendige for at implementere khunt .

Anbefalede foranstaltninger

Baseret på dette angreb anbefalede Huntress følgende foranstaltninger :

• Korrekt input-sanering og forespørgselsparametrisering for alle webinput
• Begrænsning af databasebrugerrettigheder, så selv injicerede forespørgsler ikke kan oprette Java-kilder eller udføre vilkårlige lagrede procedurer
• Udvidelse af overvågningsomfanget til at omfatte databaseobjekter (Java-klasser, PL/SQL-indpakninger) i stedet for kun OS-niveau-artefakter

Dette angreb er en skarp påmindelse om, at database-motorer med indbyggede programmeringsmiljøer (som Oracles JVM) kan blive snigende angrebsplatforme, når de kombineres med blot ét uvalideret inputfelt. Sikkerhedsteams skal udvide deres overvågning ud over operativsystemet til også at omfatte databaseobjektlaget.