Jak útok fungoval: SQL injection přes funkci automatického doplňování

Prvotním vektorem přístupu byla zranitelnost SQL injection ve veřejně přístupné Java aplikaci běžící na Apache Tomcat . Funkce automatického doplňování vyhledávání v aplikaci nedostatečně ověřovala uživatelský vstup, což útočníkům umožnilo injektovat SQL příkazy přes JDBC připojení k Oracle databázi . Jak uvedli výzkumníci z Huntress, nešlo o novou třídu zranitelností – SQL injection útoky existují již desítky let a jsou obvykle výsledkem nesprávného zpracování uživatelských vstupů směřujících k SQL serveru . Selhání aplikace při čištění jednoduchého vyhledávacího pole stačilo k zahájení celého řetězce kompromitace.

Sada nástrojů Khunt: Život uvnitř databáze jako Java objekty

Místo nasazení tradičních malwarových souborů na kompromitovaném serveru použili útočníci vestavěný Java Virtual Machine (JVM) v Oracle a příkaz CREATE JAVA SOURCE k zkompilování a uložení celého post-exploitačního nástroje jako Java schéma objektů uvnitř Oracle databáze . Tento přístup učinil nástroj neviditelným pro standardní obrany na úrovni OS, protože nástroje EDR a antiviry se zaměřují na procesy, binární soubory a soubory v operačním systému – obecně nekontrolují Java třídy a PL/SQL obálky uložené v Oracle .

Sada nástrojů Khunt zahrnovala tyto komponenty, každá uložená jako databázový objekt:

Získání plné kontroly nad systémem: Z databáze na Windows OS

Útočníci se nezastavili u přístupu na úrovni databáze. Použili sadu nástrojů Khunt k přesunu z databázové vrstvy na podkladový Windows operační systém ve vícestupňovém procesu:

1. Spuštění OS příkazů přes KhuntCmd: Pomocí modulu KhuntCmd spustili cmd.exe /c whoami, což potvrdilo, že běží s oprávněními SYSTEM na Windows serveru, čímž získali vzdálené spouštění kódu (RCE) z databáze na OS .
2. Krádež přihlašovacích údajů: Pomocí PowerShellu vyvolali reg.exe a zkopírovali registry hives SECURITY a SYSTEM, které uložili jako khuntSECURITY.hiv a khuntSYSTEM.hiv do F:\Oracle\ .
3. Průzkum služeb: Spustili tasklist /svc a výstup uložili jako khunttasks.txt .
4. Extrahování dalších hiveů: Pomocí esentutl.exe zkopírovali SAM a druhou kopii SECURITY hive, uložené jako khuntSAM.hiv a khunt_SECURITY.hiv .

Exfiltrované registry hives bylo možné použít offline k extrahování a dekódování hashů hesel pro všechny místní účty v systému .

Slepá místa obrany: Klíčová zjištění Huntress

Vyšetřování Huntress odhalilo několik kritických slepých míst, která umožnila tomuto útoku uspět a vyhnout se detekci:

• Posun databáze jako předmostí: Databáze byla přeměněna z pasivního úložiště dat na aktivní útočnou platformu, přičemž škodlivá sada nástrojů žila uvnitř databáze, nikoli na disku nebo v paměti .
• Obcházení EDR/AV: Tradiční nástroje EDR a antiviry obecně nekontrolují Java třídy a PL/SQL obálky uložené v Oracle, což činí sadu nástrojů neviditelnou pro standardní obrany na úrovni OS .
• Klasická zranitelnost, nový způsob doručení: Počáteční SQL injection byla dobře známá třída chyb. Nebylo potřeba žádné zero-day zranitelnosti. Funkce automatického doplňování stačila k dosažení PL/SQL a poté OS, což ukazuje, že základní selhání při ověřování vstupu může vést k hluboké kompromitaci, pokud má databázový engine schopnosti na úrovni OS .
• Předimenzovaná oprávnění databázových účtů: I po úspěšném SQL injection je škoda omezena, pokud databázový uživatelský účet nemá oprávnění k vytváření Java zdrojů nebo spouštění uložených procedur. Organizace často databázovým účtům přidělují příliš mnoho oprávnění, což útočníkům poskytuje dodatečná oprávnění potřebná k nasazení Khuntu .

Doporučená opatření podle Huntress

Na základě tohoto útoku doporučila společnost Huntress následující opatření :

• Řádná sanitace vstupů a parametrizace dotazů pro všechny webové vstupy
• Omezení oprávnění databázových uživatelů tak, aby ani injektované dotazy nemohly vytvářet Java zdroje nebo spouštět libovolné uložené procedury
• Rozšíření monitorovacího rozsahu na databázové objekty (Java třídy, PL/SQL obálky) namísto pouze artefaktů na úrovni OS

Tento útok slouží jako ostrá připomínka, že databázové enginy s vestavěnými programovacími prostředími (jako je Oracle JVM) se mohou stát nenápadnými útočnými platformami, když jsou kombinovány byť jen s jediným neověřeným vstupním polem. Bezpečnostní týmy musí rozšířit své monitorování za hranice operačního systému na vrstvu databázových objektů.

Jak útok fungoval: SQL injection přes funkci automatického doplňování

Prvotním vektorem přístupu byla zranitelnost SQL injection ve veřejně přístupné Java aplikaci běžící na Apache Tomcat . Funkce automatického doplňování vyhledávání v aplikaci nedostatečně ověřovala uživatelský vstup, což útočníkům umožnilo injektovat SQL příkazy přes JDBC připojení k Oracle databázi . Jak uvedli výzkumníci z Huntress, nešlo o novou třídu zranitelností – SQL injection útoky existují již desítky let a jsou obvykle výsledkem nesprávného zpracování uživatelských vstupů směřujících k SQL serveru . Selhání aplikace při čištění jednoduchého vyhledávacího pole stačilo k zahájení celého řetězce kompromitace.

Sada nástrojů Khunt: Život uvnitř databáze jako Java objekty

Místo nasazení tradičních malwarových souborů na kompromitovaném serveru použili útočníci vestavěný Java Virtual Machine (JVM) v Oracle a příkaz CREATE JAVA SOURCE k zkompilování a uložení celého post-exploitačního nástroje jako Java schéma objektů uvnitř Oracle databáze . Tento přístup učinil nástroj neviditelným pro standardní obrany na úrovni OS, protože nástroje EDR a antiviry se zaměřují na procesy, binární soubory a soubory v operačním systému – obecně nekontrolují Java třídy a PL/SQL obálky uložené v Oracle .

Sada nástrojů Khunt zahrnovala tyto komponenty, každá uložená jako databázový objekt:

Získání plné kontroly nad systémem: Z databáze na Windows OS

Útočníci se nezastavili u přístupu na úrovni databáze. Použili sadu nástrojů Khunt k přesunu z databázové vrstvy na podkladový Windows operační systém ve vícestupňovém procesu:

1. Spuštění OS příkazů přes KhuntCmd: Pomocí modulu KhuntCmd spustili cmd.exe /c whoami, což potvrdilo, že běží s oprávněními SYSTEM na Windows serveru, čímž získali vzdálené spouštění kódu (RCE) z databáze na OS .
2. Krádež přihlašovacích údajů: Pomocí PowerShellu vyvolali reg.exe a zkopírovali registry hives SECURITY a SYSTEM, které uložili jako khuntSECURITY.hiv a khuntSYSTEM.hiv do F:\Oracle\ .
3. Průzkum služeb: Spustili tasklist /svc a výstup uložili jako khunttasks.txt .
4. Extrahování dalších hiveů: Pomocí esentutl.exe zkopírovali SAM a druhou kopii SECURITY hive, uložené jako khuntSAM.hiv a khunt_SECURITY.hiv .

Exfiltrované registry hives bylo možné použít offline k extrahování a dekódování hashů hesel pro všechny místní účty v systému .

Slepá místa obrany: Klíčová zjištění Huntress

Vyšetřování Huntress odhalilo několik kritických slepých míst, která umožnila tomuto útoku uspět a vyhnout se detekci:

• Posun databáze jako předmostí: Databáze byla přeměněna z pasivního úložiště dat na aktivní útočnou platformu, přičemž škodlivá sada nástrojů žila uvnitř databáze, nikoli na disku nebo v paměti .
• Obcházení EDR/AV: Tradiční nástroje EDR a antiviry obecně nekontrolují Java třídy a PL/SQL obálky uložené v Oracle, což činí sadu nástrojů neviditelnou pro standardní obrany na úrovni OS .
• Klasická zranitelnost, nový způsob doručení: Počáteční SQL injection byla dobře známá třída chyb. Nebylo potřeba žádné zero-day zranitelnosti. Funkce automatického doplňování stačila k dosažení PL/SQL a poté OS, což ukazuje, že základní selhání při ověřování vstupu může vést k hluboké kompromitaci, pokud má databázový engine schopnosti na úrovni OS .
• Předimenzovaná oprávnění databázových účtů: I po úspěšném SQL injection je škoda omezena, pokud databázový uživatelský účet nemá oprávnění k vytváření Java zdrojů nebo spouštění uložených procedur. Organizace často databázovým účtům přidělují příliš mnoho oprávnění, což útočníkům poskytuje dodatečná oprávnění potřebná k nasazení Khuntu .

Doporučená opatření podle Huntress

Na základě tohoto útoku doporučila společnost Huntress následující opatření :

• Řádná sanitace vstupů a parametrizace dotazů pro všechny webové vstupy
• Omezení oprávnění databázových uživatelů tak, aby ani injektované dotazy nemohly vytvářet Java zdroje nebo spouštět libovolné uložené procedury
• Rozšíření monitorovacího rozsahu na databázové objekty (Java třídy, PL/SQL obálky) namísto pouze artefaktů na úrovni OS

Tento útok slouží jako ostrá připomínka, že databázové enginy s vestavěnými programovacími prostředími (jako je Oracle JVM) se mohou stát nenápadnými útočnými platformami, když jsou kombinovány byť jen s jediným neověřeným vstupním polem. Bezpečnostní týmy musí rozšířit své monitorování za hranice operačního systému na vrstvu databázových objektů.