Përmbajtje[Fshih][Shfaqje]
Log4Shell, një dobësi e internetit, së fundmi preku miliona makina. Log4j, një softuer i panjohur por pothuajse i kudondodhur, e shkakton atë.
Log4j përdoret për të regjistruar të gjitha veprimet që ndodhin prapa skenave në një sërë sistemesh kompjuterike.
Ai bazohet në një bibliotekë regjistrimi me burim të hapur që përdoret nga bizneset dhe madje edhe organizatat qeveritare në shumicën e aplikacioneve.
Duke qenë një nga vrimat më të këqija të sigurisë kibernetike të zbuluar ndonjëherë, është thelbësore të mbroni sistemet tuaja nga kjo dobësi. Por, si?
Le të eksplorojmë dobësinë e Log4j në detaje dhe të gjitha zgjidhjet e mundshme të rregullimit për të.
Çfarë është Log4j?
Log4j është një burim të hapur kornizë logging që u mundëson zhvilluesve të softuerit të regjistrojnë të dhëna të ndryshme brenda aplikacioneve të tyre. Është një komponent i projektit Apache Logging Services, i cili drejtohet nga Apache Software Foundation.
Qindra faqe interneti dhe aplikacione përdorin Log4j për të kryer operacione kritike si regjistrimi i të dhënave për korrigjimin e gabimeve dhe përdorime të tjera.
Kur futni ose klikoni në një lidhje të dobët në internet dhe merrni një njoftim për gabimin 404, ky është një shembull i shpeshtë i Log4j në punë. Serveri i uebit që drejton domenin e lidhjes së uebit ku u përpoqët të hyni, ju informon se një faqe e tillë ueb nuk ekziston. Ai gjithashtu regjistron ngjarjen në Log4j për administratorët e sistemit të serverit.
Gjatë gjithë programeve softuerike, përdoren sinjale të ngjashme diagnostike. Në lojën online Minecraft, për shembull, serveri përdor Log4j për të regjistruar aktivitetin, si RAM-i total i përdorur dhe udhëzimet e përdoruesit të dërguara në tastierë.
Si ndodh cenueshmëria?
Kërkimet janë një veçori e re e prezantuar në Log4j 2.0, e cila ndihmon për të inkorporuar informacione shtesë në hyrjet e regjistrit. Një nga këto kërkime është kërkimi i JNDI (Java Naming and Directory Interface), i cili është një API Java për komunikimin me një shërbim drejtorie.
Duke përdorur këtë qasje, ID-të e brendshme të përdoruesve mund të krahasohen me emrat aktualë të përdoruesve. Ky pyetje ekspozon cenueshmërinë RCE të sapo zbuluar, pasi një nga llojet e të dhënave të ofruara nga serveri LDAP është një URI që tregon një klasë Java, e cila më pas ngarkohet në memorie dhe ekzekutohet nga shembulli Log4j.
Për shkak të një dobësie në vlefshmërinë e hyrjes së bibliotekës Log4j, është e mundur të injektohet një server arbitrar LDAP nga një burim i pabesueshëm. Për shkak se zhvilluesit supozojnë se të dhënat e dërguara në regjistrat do të trajtohen si tekst i thjeshtë, nuk kryhet asnjë verifikim shtesë i hyrjes dhe hyrja e rrezikshme e përdoruesit hyn në regjistra.
Një deklaratë e regjistrit mund të duket si kjo:
Një përdorues me qëllim të keq do të fuste tani një kërkim JNDI duke iu referuar një serveri mashtrues LDAP në një parametër URL. Kërkimi i JNDI do të ishte si më poshtë:
Biblioteka Log4j më pas bisedon me këtë server LDAP në sulmer.com për të marrë informacione direktorie, duke përfshirë vlerat për Java Factory dhe Java Codebase.
Këto dy vlera përfshijnë klasën Java të sulmuesit, e cila më pas ngarkohet në memorie dhe ekzekutohet nga shembulli Log4j, duke përfunduar ekzekutimin e kodit.
Kush është në rrezik?
Dobësia Log4j është tepër e gjerë, duke prekur aplikacionet e biznesit, pajisjet e integruara dhe nënsistemet e tyre. Aplikacionet e prekura përfshijnë Cisco Webex, Minecraft dhe FileZilla FTP.
Sidoqoftë, kjo nuk është aspak një listë e tërë. E meta madje ndikon në misionin e helikopterit Ingenuity Mars 2020, i cili përdor Apache Log4j për regjistrimin e ngjarjeve.
Komuniteti i sigurisë ka përpiluar një lista e sistemeve të cenueshme. Është thelbësore të theksohet se këto lista po përditësohen vazhdimisht, kështu që nëse një program ose sistem i caktuar nuk shfaqet, mos supozoni se nuk është prekur.
Ekspozimi ndaj kësaj cenueshmërie është mjaft i mundshëm, madje edhe nëse është specifik pirg teknologjie nuk aplikon Java, drejtuesit e sigurisë duhet të presin që sistemet kritike të furnizuesve, furnizuesit e SaaS, ofruesit e pritjes në renë kompjuterike dhe ofruesit e serverëve të uebit ta bëjnë këtë.
Si të kontrolloni për dobësinë Log4j?
Hapi i parë është të përcaktohet nëse një sulm ka ndodhur tashmë. Ju mund ta bëni këtë duke kontrolluar regjistrat e sistemit për fragmente të ngarkesës RCE.
Nëse një kërkim për terma si "jndi", "ldap" ose "$::" jep ndonjë regjistër, studiuesit e sigurisë duhet të eksplorojnë më tej për të parë nëse ishte një sulm legjitim apo thjesht marrje e gjurmëve të gishtave.
U zbuluan shumë sulme në natyrë që nuk sollën asnjë ngarkesë të dëmshme. Sidoqoftë, ato u kryen nga ekspertë të sigurisë për të përcaktuar se sa aplikacione ishin të cenueshme ndaj këtij sulmi.
Hapi tjetër është përdorimi i bibliotekës Log4j për të identifikuar të gjitha projektet. Nëse përdoren versionet midis 2.0-beta9 dhe 2.14.1, projekti mund të jetë i ndjeshëm.
Duke pasur parasysh vështirësinë në përcaktimin se ku ekziston kjo dobësi, mund të preferohet të supozohet se projekti është i ndjeshëm dhe se përditësimi i bibliotekës është veprimi më i mirë për të hequr rrezikun e ekzekutimit të kodit.
Projekti nuk është i cenueshëm nëse versioni i përdorur është më i vogël se 2.0-beta 9, megjithëse biblioteka Log4j duhet ende të përmirësohet sepse versionet në rangun 1.x janë të vjetra dhe nuk marrin më përditësime.
Nëse zbulohet një projekt i ndjeshëm, këshillohet që të kontrollohet për të parë nëse ndonjë informacion i regjistruar duke përdorur Log4j përmban informacion që përdoruesi mund të ndryshojë. URL-të, parametrat e kërkesës, titujt dhe kukit janë shembuj të këtyre të dhënave. Nëse një nga këto regjistrohet, projekti është në rrezik.
Kjo njohuri mund t'ju ndihmojë të hulumtoni më tej në regjistrat e sistemit dhe të përcaktoni nëse aplikacioni juaj në internet është sulmuar tashmë.
Ka mjete online falas që mund të zbulojnë nëse një aplikacion ueb është i cenueshëm. Një nga këto programe është Gjuetarja Log4Shell. Është me burim të hapur dhe i disponueshëm në GitHub.
Nëse zbulohet një zonë e cenueshme e kodit në aplikacionin online, ngarkesa e dhënë nga mjeti i zbuluar mund të përdoret për ta injektuar atë në aplikacionin në internet. Mjeti i testimit do të zbulonte lidhjet e bëra midis aplikacionit tuaj të internetit dhe serverit të tyre LDAP nëse do të shfrytëzohej dobësia.
Zgjidhje për të rregulluar cenueshmërinë Log4j
Hapi i parë është të përditësoni Log4j, gjë që mund ta bëni duke përdorur menaxherët normalë të paketave ose duke e shkarkuar atë direkt nga kjo faqe.
Është gjithashtu e mundur të zvogëlohet shfrytëzimi i cenueshmërisë duke vendosur variablin e mjedisit FORMAT MSG NO LOOKUPS në true. Megjithatë, kjo kundërmasë është e zbatueshme vetëm për versionet Log4j më të mëdha se ose të barabarta me 2.10.
Le të shqyrtojmë tani opsionet alternative.
1. Zgjidhjet për versionin 4 të Log2.17.0j
Padyshim që këshillohet fuqimisht përdorimi i versionit 4 të Log2.15.0j për t'u mbrojtur kundër Log4Shell, megjithatë, nëse kjo nuk është e mundur, ekzistojnë zgjidhje të tjera.
Versionet 2.7.0 dhe më vonë të Log4j: Është e mundur të mbroheni nga çdo sulm duke ndryshuar formatin e ngjarjeve që do të regjistrohen duke përdorur sintaksën e përqindjes m nolookups për të dhënat e ofruara nga përdoruesi. Ky përditësim kërkon redaktimin e skedarit të konfigurimit Log4j për të gjeneruar një version të ri të programit. Si rezultat, përpara se të vendoset ky version i ri, duhet të përsëriten fazat e verifikimit teknik dhe funksional.
Versionet Log4j 2.10.0 dhe më vonë: Është gjithashtu e mundur të mbroheni nga çdo sulm duke vendosur parametrin e konfigurimit log4j2.formatMsgNoLookups në true, për shembull, kur filloni makinën virtuale Java me opsionin -Dlog4j2." formatMsgNoLookups = true, Një opsion tjetër është heqja e klasës JndiLookup nga argumenti classpath, i cili do të heqë vektorin kryesor të sulmit (kërkuesit nuk përjashtojnë mundësinë e një vektori tjetër sulmi).
Shërbimet në internet të Amazon ofrojnë një "hotpatch" që "duhet të përdoret me rrezikun tuaj". "Teknika" të tjera, si Logout4Shell, e cila "e përdor këtë dobësi kundër vetvetes", janë publikuar. Eksperti i sigurisë vë në dyshim ligjshmërinë e kësaj lëvizjeje, e cila përfshin "hakimin e një makinerie për ta rregulluar atë".
2. Problemi është zgjidhur në Log4j v2.17.0.
Për versionet më të mëdha se 2.10: Log4j2.formatMsgNoLookups duhet të vendoset në true.
Për versionet 2.0 deri në 2.10.0: Ekzekutoni komandën e mëposhtme për të hequr klasën LDAP nga Log4j.
Log4j2.formatMsgNoLookups duhet të vendoset në true në cilësimet e sistemit.
Zbutja në JVM
Zbutja me parametrat JVM nuk është më një opsion. Metodat e tjera zbutëse vazhdojnë të jenë të suksesshme. Përmirësojeni në versionin Log4j 2.17.0 nëse është e mundur. Ekziston një udhëzues migrimi i disponueshëm për Log4j v1.
Nëse një përditësim nuk është i mundur, sigurohuni që komponentët nga ana e klientit dhe nga ana e serverit të kenë -Dlog4j2.formatMsgNoLookups = grupin e vetive të sistemit të vërtetë.
Ju lutemi vini re se Log4j v1 ka arritur në fund të jetës së tij (EOL) dhe nuk do të marrë më rregullime të defekteve në kod. Vektorë të tjerë RCE janë gjithashtu të ndjeshëm ndaj Log4j v1. Prandaj, ne ju bëjmë thirrje që të përmirësoni në Log4j 2.17.0 sa më shpejt të jetë e mundur.
3. Masat zbutëse
Shfrytëzimi aktual nuk mund të funksionojë edhe nëse Log4j është i ndjeshëm në disa raste, si p.sh. nëse makina pritës po ekzekuton një version Java më të lartë se 6u212, 7u202, 8u192 ose 11.0.2.
Kjo është për shkak të mbrojtjes më të mirë të Java Emërtimit dhe Ndërfaqes së Drejtorisë (JNDI) nga ngarkimi i klasës në distancë në versionet aktuale, e cila është e nevojshme për funksionimin e sulmit.
Për më tepër, me versionet Log4j më të mëdha se 2.10, problemi mund të shmanget duke vendosur vlerën e sistemit formatMsgNoLookups në true, duke ofruar argumentin JVM -Dlog4j2.formatMsgNoLookups = true, ose duke fshirë klasën JndiLookup nga rruga e klasës.
Ndërkohë, derisa të rregullohen rastet e cenueshme, cenueshmëria mund të adresohet duke përdorur teknikat e mëposhtme:
- Cakto vetinë e sistemit log4j2.formatMsgNoLookups në true për >=2.10.
- Cakto opsionin e mjedisit LOG4J FORMAT MSG NO LOOKUPS në true për >=2.10.
- Hiq JndiLookup.class nga classpath për 2.0-beta9 në 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Një praktikë më e mirë e rekomanduar është të kufizoni trafikun e daljes në internet vetëm në portet e duhura.
Megjithëse shumica e sulmeve në terren dorëzohen përmes HTTP, dobësia mund të shfrytëzohet nëpërmjet çdo protokolli që regjistron të dhënat e hyrjes së përdoruesit duke përdorur Log4j.
Megjithatë, përditësimi në log4j 2.17.0 është zgjidhja më e mirë sepse dikush mund të zbulojë një qasje shtesë për këtë çështje. Për më tepër, shumë botues dhe prodhues kanë njoftuar përmirësime në shërbimet ose aplikacionet e tyre.
4. Arnimi i dobësisë Log4Shell
Log4j është i gjithëpranishëm, veçanërisht tani që cenueshmëria po shfrytëzohet. Për ta përmbledhur, gjithçka që duhet të bëni është të përfshini karakteret e mëposhtme në regjistrat e inspektuar nga Log4j.
Dhe kjo do të shkarkojë dhe ekzekutojë skedarin Java që ndodhet në fund të URL-së. Është sa e drejtpërdrejtë aq edhe dramatike.
Siç e dini, është thelbësore të përmirësoni log4j në versionin >= 2.17.0 për të korrigjuar këtë dobësi të Log4Shell (CVE-2021-44228).
Nëse kjo nuk është e mundur:
Për aplikacionet që përdorin versionet e bibliotekës Log4j 2.10.0 dhe më vonë, është gjithashtu e mundur të mbroheni nga çdo sulm duke vendosur parametrin e konfigurimit log4j2.formatMsgNoLookups në true, për shembull, ndërsa filloni makinën virtuale Java me -Dlog4j2.formatMsgNoLookups = true opsion.
Një opsion tjetër është fshirja e klasës JndiLookup nga argumenti classpath, i cili do të heqë vektorin primar të sulmit (kërkuesit nuk përjashtojnë ekzistencën e një vektori tjetër sulmi).
shënim
Organizatat që hezitojnë ose nuk dëshirojnë të bëjnë rregullime në sistemet e ndjeshme (ose që dëshirojnë të instalojnë masa mbrojtëse shtesë) duhet të mendojnë për:
- Sigurohuni që i gjithë trafiku të drejtohet përmes një iSensor/WAF/IPS. Kjo mund të parandalojë që sulmi të ketë akses në sistem.
- Kufizimi i sasisë së trafikut që mund të arrijë në sistemin e prekshëm Nëse sistemi nuk ka nevojë të lidhet me internetin, kufizoni aksesin në IPS dhe vargjet thjesht thelbësore dhe të besueshme.
- Reduktimi i trafikut të autorizuar dalës të hostit. Për shkak se ky sulm funksionon duke u lidhur me një server mashtrues, të gjitha adresat IP dhe portat e tepërta duhet të bllokohen në një mur zjarri.
- Nëse shërbimi nuk kërkohet më, ai duhet të çaktivizohet derisa të jetë gati një rregullim.
Përfundim
Të metat e Log4j tronditën komunitetin tonë dhe na kujtuan të gjithëve se sa të varur jemi në softuerin me burim të hapur.
Log4j është unik. Nuk është as një sistem operativ, as një shfletues, as një softuer. Përkundrazi, është ajo që programuesit i referohen si një bibliotekë, një paketë ose një modul kodi. Ai i shërben vetëm një qëllimi, që është, mbajtja e një regjistrimi të asaj që ndodh në një server.
Njerëzit që shkruajnë kod preferojnë të përqendrohen në atë që e bën softuerin e tyre të veçantë. Ata nuk janë të interesuar të rishpikin timonin. Si rezultat, ata mbështeten në një bollëk të bibliotekave ekzistuese të kodeve, të tilla si Log4j.
Moduli Log4j rrjedh nga Apache, softueri më i përdorur i serverit në ueb. Kjo është arsyeja pse ai mund të zbulohet në miliona serverë. Prandaj, rritja e kërcënimeve të sigurisë.
Shpresoj që zgjidhjet e mësipërme t'ju ndihmojnë t'i mbani pajisjet tuaja të sigurta.
Qëndroni të sintonizuar me HashDork për më shumë informacione të dobishme nga bota e teknologjisë.
Lini një Përgjigju