A naplózó eszköz fejlesztői radikálisan léptek: egy problémás funkciót kilőttek, egyet pedig alapértelmezésben letiltottak.
Hirdetés
 

A közelmúltban azonosítottak az Apache Log4j naplózó eszköz 2.x verziójában egy kritikus hibát. A sérülékenységet, amely a Microsoft által üzemeltetett Minecraft szervereknél bukott ki Log4Shell vagy LogJam néven emlegetik (hivatalos azonosítója: CVE-2021-44228).

A távoli kódfuttatási sebezhetőség könnyen kihasználható, és ezen keresztül a rendszer teljes irányítását át lehet venni. Ehhez egy speciális kérést kell küldeni a megcélzott rendszernek. A kérés a Log4j segítségével létrehoz egy logot, ami a JNDI (Java Naming and Directory Interface) keresési szolgáltatást felhasználva összekapcsolja a fertőzött rendszert a támadó vezérlőszerverével, és arról rosszindulatú kódokat kér le.

A legnagyobb probléma, hogy a Log4j mindenhol ott van, érinti az Amazont, az Apple-t, a Cloudflare-t, a Google-t, a Microsoftot, a Steamet, a Teslát, a Twittert, a VMWare-t és még hosszan sorolhatnánk. Egyszerűen és univerzálisan használható: DDoS-támadásokhoz, kriptovaluta-bányász algoritmusok telepítéséhez, zsarolóprogramokhoz stb. És természetesen használták is nem csak leleményes kiberbűnözők, hanem államok is. Utóbbiak közül leggyakrabban Kínát és Iránt emlegeti a sajtó, de a Microsoft már azonosított észak-koreai és török támadásokat is.

Újabb hibák sorakoznak

Mint a SecurityWeek írja, a fejlesztők ugyan már december 6-án kiadták a Log4Shellre a javítást, ám azóta kiderült, a javítás bizonyos konfigurációk esetén nem ad teljes megoldást, és további támadásokra ad lehetőséget. A probléma önálló azonosítót is kapott (CVE-2021-45046), és megvan hozzá a javítás is. Ezek is elérhetők az Apache.org fentebb már linkelt oldalán.

A javítások radikálisabbak, mint az előző, december elején kiadott frissítésnél: a fejlesztők eltávolították a frissített verziókból az üzenetkeresés funkciót, és alapértelmezés szerint letiltották a JNDI-hoz való hozzáférést.

Kiderült az is, hogy ugyan a Log4j előző főverziójánál (1.x) kisebb a támadások kockázata, az azt használó rendszerek is sebezhetők, ha használják a JNDI-t. Ahhoz azonban már nem adtak ki javítást, mivel lezárult a verzió támogatási ciklusa. (Az érintettek a CVE-2021-4104-es azonosító alatt találják meg a biztonsági rés leírását.)

A hibák gyors intézkedést kívánnak, mert a Log4j rendkívül elterjedt eszköz. van olyan kutatás, mely szerint tíz IT-környezetből kilencben vannak sebezhető Log4j-könyvtárak. De mint azt Ami Luttwak, a Wiz felhőbiztonsági vállalat társalapítója és technológiai igazgatója mondta a SecurityWeeknek, az igazi veszély abban van, hogy eközben sokan, főleg a fejlesztők, meg vannak győződve arról, hogy nulla a kitettségük a hibának. Aztán jön a keserű felismerés: olyan harmadik féltől származó komponenst használtak a kódjukban, ami Java felhasználásával készült, és azon keresztül rájuk is leselkedik a Log4Shell.

A hibát kihasználni igyekvő támadások érzékelhetően megszaporodtak. A CheckPoint például több mint egymillió támadási kísérletet regisztrált, a vállalati hálózatok 44 százalékánál próbálták a Log4Shellt kihasználni. A támadások közel felét már ismert, azonosított támadó csoportok hajtották végre.

Az eddig felfedezett összes biztonsági réshez készült javítás, illetve módszer a veszélyek csökkentésére. Erről az Apache.org-on lehet olvasni bővebben.

Biztonság

MI buktatja le a tudományos cikkeket író ChatGPT-t

Sárkány ellen sárkányfű - gondolta egy tudóscsapat, és betanított egy algoritmust arra, hogy kiszúrja a generatív mesterséges intelligenciával gyártott kamu tudományos cikkeket.
 
Hirdetés

Sokkolja a magyar cégeket, hogy ilyen támogatás is létezik

Mennyibe kerülhet, hogy a hoszting szolgáltató éjjel-nappal 60 másodpercen belül felvegye nekünk a telefont, és vezető rendszergazdái azonnal foglalkozzanak a problémánkkal? A vshosting~ szerint nem is biztos, hogy annyira sokba.

Valószínűleg soha. A piackutatók szerint a felhő mellett is dinamikusan növekszik a hosting iránti igény.

a melléklet támogatója a vshosting

Létezik egy ortodox irányzat, mely szerint a jelszavak legyenek minél hosszabbak és összetettebbek, valamint cseréljük azokat minél gyakrabban. Valóban ettől lesznek a rendszereink biztonságosabbak? Pfeiffer Szilárd (Balasys) írása.

Miért ne becsüljük le a kisbetűs jelszavakat? 2. rész

Miért ne becsüljük le a kisbetűs jelszavakat? 3. rész

A felmérésekből egyre inkább kiderül, hogy az alkalmazottak megtartása vagy távozása sokszor azon múlik, amit a szervezetük nem csinál, nem pedig azon, amiben egymásra licitál a többi munkáltatóval.

Ezért fontos számszerűsíteni a biztonsági kockázatokat

Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizennegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2023 Bitport.hu Média Kft. Minden jog fenntartva.