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

Vodafone-t cserélt Yettelre a magyar állam

A 4iG viszont az Antenna Hungárián keresztül immár a Vodafone 70,5 százalékát birtokolja.
 
Hirdetés

Ez gyorsan ment, az Invitech bevezeti a SOAR-t

Az Invitech biztonsági műveleti központjában olyan automatizált megoldást vezetnek be, amellyel akár egy eddig félnapos elemzőmunka is csak negyedórát vehet majd igénybe. Ez a SOAR.

Felderítés nélkül csatába menni – nagyjából ehhez hasonlítható az automatizált rendszereket nélkülöző kibervédelem. A mesterséges intelligencia mindkét oldalon beszállt a küzdelembe.

a melléklet támogatója az Invitech

CIO KUTATÁS

A HAZAI NAGYVÁLLALATOK FELHŐHASZNÁLATÁRÓL

Az Ön véleményére is számítunk Corvinus Egyetem Adatelemzés és Informatika Intézetével és az IPR-Insights szakértőivel közösen összeállított kutatásunkban.
Segítse munkánkat egy 10-15 perces kérdőív megválaszolásával!

LÁSSUNK NEKI!

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.