Slik foregikk angrepet: SQL-injeksjon via autocomplete-søk

Inngangsporten var en SQL-injeksjon i en Java-applikasjon som kjørte på Apache Tomcat . Applikasjonens søkefelt for autofullføring validerte ikke brukerinndataene skikkelig. Dette gjorde at hackerne kunne sende ondsinnede SQL-kommandoer via en JDBC-tilkobling til Oracle-databasen . Som Huntress påpeker, var dette ingen ny sårbarhet – SQL-injeksjoner har eksistert i flere tiår, og skyldes nesten alltid dårlig håndtering av brukerinndata . Det var nok at applikasjonen ikke renset et enkelt søkefelt, for at hele angrepskjeden kunne starte.

Khunt-verktøykassen: Bor inne i databasen som Java-objekter

Angriperne brukte Oracles innebygde JVM og CREATE JAVA SOURCE-setningen til å kompilere og lagre verktøykassen som skjemaobjekter i databasen . Dette gjorde verktøyene usynlige for standard OS-sikkerhetsverktøy fordi de ikke etterlot seg spor på disk eller i minnet .

Verktøykassen inneholdt følgende moduler, alle lagret som databaseobjekter:

Full kontroll: Fra database til Windows OS

Hackerne stoppet ikke ved databasetilgang. De brukte khunt-verktøyene til å ta kontroll over det underliggende Windows-operativsystemet:

1. OS-kommandoer via KhuntCmd: De kjørte cmd.exe /c whoami og oppdaget at de allerede hadde SYSTEM-rettigheter på Windows-serveren – det høyeste tilgangsnivået .
2. Tyveri av påloggingsinformasjon: De brukte PowerShell til å kopiere registerdatabasene SECURITY og SYSTEM, og lagret dem som khuntSECURITY.hiv og khuntSYSTEM.hiv i mappen F:\Oracle\ .
3. Tjenesteoversikt: De kjørte tasklist /svc og lagret resultatet som khunttasks.txt .
4. Ekstra hashextraksjon: De brukte esentutl.exe til å kopiere SAM-registerdatabasen og en ekstra kopi av SECURITY, og lagret dem som khuntSAM.hiv og khunt_SECURITY.hiv .

Disse registerdatabasene kunne brukes offline til å hente ut og dekode passordhasher for alle lokale kontoer på systemet .

Forsvarets blindsoner – Huntress' viktigste funn

Huntress' etterforskning avdekket flere kritiske hull i bedrifters sikkerhetsovervåking :

• Databasen ble et angrepsplattform: I stedet for å være en passiv datalager ble databasen omgjort til en aktiv angrepsbase, der det ondsinnede verktøyet bodde inni databasen – ikke på disk eller i minnet .
• EDR/AV-omgåelse: Tradisjonelle EDR- og antivirusverktøy inspiserer ikke Java-klasser og PL/SQL-wrapperer lagret i Oracle, noe som gjorde verktøyene usynlige .
• Klassisk sårbarhet, ny leveringsmetode: Den opprinnelige SQL-injeksjonen var en velkjent feiltype. Det krevdes ingen zero-day-sårbarhet. Autocomplete-søkefeltet var nok til å nå PL/SQL og deretter OS – noe som viser at grunnleggende valideringsfeil kan få alvorlige konsekvenser .
• Overprivilegerte databasekontoer: Selv om en SQL-injeksjon lykkes, er skaden begrenset hvis databasebrukeren mangler rettigheter til å opprette Java-kilder eller kjøre lagrede prosedyrer. Mange organisasjoner gir databasekontoer for mange rettigheter, noe som ga hackerne ekstra tilgang .

Anbefalinger fra Huntress

Huntress anbefaler følgende tiltak for å forhindre lignende angrep :

• Korrekt validering og parameterisering av alle nettbaserte inndata
• Begrensning av databasebrukerrettigheter slik at selv injiserte spørringer ikke kan opprette Java-kilder eller utføre vilkårlige lagrede prosedyrer
• Utvidelse av overvåking til å inkludere databaseobjekter (Java-klasser, PL/SQL-wrapperer) – ikke kun OS-nivå

Dette angrepet er en sterk påminnelse om at databasemotorer med innebygde programmeringsmiljøer (som Oracles JVM) kan bli svært effektive angrepsplattformer dersom de kombineres med bare ett enkelt uvalidert inndatafelt. Sikkerhetsteam må utvide overvåkingen utover operativsystemet til også å omfatte databasens objektlag.

Slik foregikk angrepet: SQL-injeksjon via autocomplete-søk

Inngangsporten var en SQL-injeksjon i en Java-applikasjon som kjørte på Apache Tomcat . Applikasjonens søkefelt for autofullføring validerte ikke brukerinndataene skikkelig. Dette gjorde at hackerne kunne sende ondsinnede SQL-kommandoer via en JDBC-tilkobling til Oracle-databasen . Som Huntress påpeker, var dette ingen ny sårbarhet – SQL-injeksjoner har eksistert i flere tiår, og skyldes nesten alltid dårlig håndtering av brukerinndata . Det var nok at applikasjonen ikke renset et enkelt søkefelt, for at hele angrepskjeden kunne starte.

Khunt-verktøykassen: Bor inne i databasen som Java-objekter

Angriperne brukte Oracles innebygde JVM og CREATE JAVA SOURCE-setningen til å kompilere og lagre verktøykassen som skjemaobjekter i databasen . Dette gjorde verktøyene usynlige for standard OS-sikkerhetsverktøy fordi de ikke etterlot seg spor på disk eller i minnet .

Verktøykassen inneholdt følgende moduler, alle lagret som databaseobjekter:

Full kontroll: Fra database til Windows OS

Hackerne stoppet ikke ved databasetilgang. De brukte khunt-verktøyene til å ta kontroll over det underliggende Windows-operativsystemet:

1. OS-kommandoer via KhuntCmd: De kjørte cmd.exe /c whoami og oppdaget at de allerede hadde SYSTEM-rettigheter på Windows-serveren – det høyeste tilgangsnivået .
2. Tyveri av påloggingsinformasjon: De brukte PowerShell til å kopiere registerdatabasene SECURITY og SYSTEM, og lagret dem som khuntSECURITY.hiv og khuntSYSTEM.hiv i mappen F:\Oracle\ .
3. Tjenesteoversikt: De kjørte tasklist /svc og lagret resultatet som khunttasks.txt .
4. Ekstra hashextraksjon: De brukte esentutl.exe til å kopiere SAM-registerdatabasen og en ekstra kopi av SECURITY, og lagret dem som khuntSAM.hiv og khunt_SECURITY.hiv .

Disse registerdatabasene kunne brukes offline til å hente ut og dekode passordhasher for alle lokale kontoer på systemet .

Forsvarets blindsoner – Huntress' viktigste funn

Huntress' etterforskning avdekket flere kritiske hull i bedrifters sikkerhetsovervåking :

• Databasen ble et angrepsplattform: I stedet for å være en passiv datalager ble databasen omgjort til en aktiv angrepsbase, der det ondsinnede verktøyet bodde inni databasen – ikke på disk eller i minnet .
• EDR/AV-omgåelse: Tradisjonelle EDR- og antivirusverktøy inspiserer ikke Java-klasser og PL/SQL-wrapperer lagret i Oracle, noe som gjorde verktøyene usynlige .
• Klassisk sårbarhet, ny leveringsmetode: Den opprinnelige SQL-injeksjonen var en velkjent feiltype. Det krevdes ingen zero-day-sårbarhet. Autocomplete-søkefeltet var nok til å nå PL/SQL og deretter OS – noe som viser at grunnleggende valideringsfeil kan få alvorlige konsekvenser .
• Overprivilegerte databasekontoer: Selv om en SQL-injeksjon lykkes, er skaden begrenset hvis databasebrukeren mangler rettigheter til å opprette Java-kilder eller kjøre lagrede prosedyrer. Mange organisasjoner gir databasekontoer for mange rettigheter, noe som ga hackerne ekstra tilgang .

Anbefalinger fra Huntress

Huntress anbefaler følgende tiltak for å forhindre lignende angrep :

• Korrekt validering og parameterisering av alle nettbaserte inndata
• Begrensning av databasebrukerrettigheter slik at selv injiserte spørringer ikke kan opprette Java-kilder eller utføre vilkårlige lagrede prosedyrer
• Utvidelse av overvåking til å inkludere databaseobjekter (Java-klasser, PL/SQL-wrapperer) – ikke kun OS-nivå

Dette angrepet er en sterk påminnelse om at databasemotorer med innebygde programmeringsmiljøer (som Oracles JVM) kan bli svært effektive angrepsplattformer dersom de kombineres med bare ett enkelt uvalidert inndatafelt. Sikkerhetsteam må utvide overvåkingen utover operativsystemet til også å omfatte databasens objektlag.