Table of Contents[Veşartin][Rêdan]
Log4Shell, qelsiyek înternetê, herî dawî bandor li mîlyon makîneyan kir. Log4j, perçeyek nermalava nezelal lê hema hema berbelav, dibe sedema wê.
Log4j ji bo qeydkirina hemî kiryarên ku li pişt perdeyê di cûrbecûr pergalên komputerê de diqewimin tê bikar anîn.
Ew li ser bingeha pirtûkxaneyek têketinê-çavkaniya vekirî ye ku ji hêla karsazî û tewra rêxistinên hukûmetê ve di pir serlêdanan de tê bikar anîn.
Ji ber ku yek ji xirabtirîn qulên ewlehiya sîberê ye ku heya niha nehatiye vedîtin, girîng e ku hûn pergalên xwe ji vê qelsiyê biparêzin. Lê çawa?
Ka em bi hûrgulî qelsiya Log4j û hemî çareseriyên rastkirina wê yên gengaz bikolin.
Log4j çi ye?
Log4j yek e vekirî çarçoweya têketinê ku rê dide pêşdebirên nermalavê ku daneyên cihêreng di nav sepanên xwe de tomar bikin. Ew hêmanek projeya Karûbarên Logging Apache-yê ye, ku ji hêla ve hatî rêve kirin Foundation Foundation ya Apache.
Bi sedan malper û serîlêdan Log4j bikar tînin da ku karûbarên krîtîk ên wekî daneyên têketinê ji bo debugkirin û karanîna din pêk bînin.
Gava ku hûn li ser girêdanek serhêl a belengaz têxin an bikirtînin û hişyariyek xeletiyek 404 bistînin, ev mînakek pir caran ya Log4j li xebatê ye. Pêşkêşkara malperê ya ku domaina girêdana webê ya ku we hewl da ku hûn bigihîjin dimeşîne, we agahdar dike ku malperek wusa tune. Di heman demê de ew bûyer di Log4j de ji bo rêvebirên pergala serverê jî tomar dike.
Di nav bernameyên nermalavê de, îşaretên tespîtkirinê yên bi heman rengî têne bikar anîn. Mînakî, di lîstika serhêl Minecraft de, server Log4j bikar tîne da ku çalakiya wekî tevahî RAM-a ku hatî bikar anîn û rêwerzên bikarhêner ku di konsolê de têne şandin tê tomar kirin.
Zelalbûn çawa çêdibe?
Lêgerîn taybetmendiyek nû ye ku di Log4j 2.0 de hatî destnîşan kirin, ku ji bo tevlêkirina agahdariya zêde di navnîşên têketinê de dibe alîkar. Yek ji van lêgerînan lêgerîna JNDI (Java Navdêr û Navbera Rêvebir) ye, ku ji bo danûstendina bi karûbarek pelrêça Java API ye.
Bi karanîna vê nêzîkbûnê, nasnameyên bikarhêner ên hundurîn dikarin bi navên bikarhêner ên rastîn ve werin nexşandin. Ev pirs qelsiya RCE ya ku nû hatiye keşif kirin eşkere dike, ji ber ku yek ji celebên daneyê ku ji hêla servera LDAP ve hatî peyda kirin URI ye ku çînek Java-yê destnîşan dike, ku dûv re di bîranînê de tê barkirin û ji hêla mînaka Log4j ve tê meşandin.
Ji ber qelsiyek di pejirandina têketina pirtûkxaneya Log4j de, gengaz e ku meriv serverek LDAP-a keyfî ji çavkaniyek nebawer were derz kirin. Ji ber ku pêşdebiran texmîn dikin ku daneyên ku ji têketin re têne şandin dê wekî nivîsek sade werin desteser kirin, erêkirina têketinê ya zêde nayê kirin, û têketina bikarhênerê xeternak têkeve têketinê.
Daxuyaniyek têketinê dikare bi vî rengî xuya bike:
Bikarhênerek xerab naha dê lêgerînek JNDI-yê ku behsa serverek LDAP-ê ya xapînok di parametreyek URL-ê de bike têxe. Lêgerîna JNDI dê wiha be:
Pirtûkxaneya Log4j dûv re bi vê servera LDAP-ê re li attacker.com diaxive da ku agahdariya pelrêça, tevî nirxan ji bo Fabrîkaya Java û Java Codebase bigire.
Van her du nirxan çîna Java ya êrîşkar vedihewîne, ku dûv re li bîra tê barkirin û ji hêla mînaka Log4j ve tê darve kirin, pêkanîna kodê temam dike.
Kî di bin metirsiyê de ye?
Zehfbûna Log4j pir berfireh e, bandorê li ser sepanên karsaziyê, cîhazên pêvekirî, û bine pergalên wan dike. Serlêdanên bandorkirî Cisco Webex, Minecraft, û FileZilla FTP hene.
Lêbelê, ev bi tu awayî navnîşek tevahî ye. Kêmasî tewra bandorê li mîsyona çopê ya Ingenuity Mars 2020 jî dike, ku Apache Log4j ji bo tomarkirina bûyerê bikar tîne.
Civata asayîşê a berhev kiriye navnîşa pergalên xeternak. Girîng e ku bala xwe bidinê ku ev navnîşan bi domdarî têne nûve kirin, ji ber vê yekê heke bername an pergalek diyar nebe, nehesibînin ku ew bandor nebe.
Ragihandina vê qelsiyê pir muhtemel e, û hetta taybetî be stack tech Java-yê bicîh nayîne, divê rêveberên ewlehiyê li bendê bin ku pergalên dabînkerê krîtîk, peydakiroxên SaaS, pêşkêşkerên mêvandariya ewr, û pêşkêşkerên servera malperê wiya bikin.
Meriv çawa qelsiya Log4j kontrol dike?
Pêngava yekem ev e ku meriv diyar bike ka êrîşek berê qewimiye yan na. Hûn dikarin bi kontrolkirina têketinên pergalê ji bo perçeyên bargiraniya RCE bikin.
Ger lêgerîna peyvên mîna "jndi", "ldap", an "$::" çi têketinê bide, lêkolînerên ewlehiyê divê bêtir lêkolîn bikin da ku bibînin ka ew êrîşek rewa bû an tenê şopa tiliyê ye.
Gelek êrîşên li çolê hatin keşif kirin ku tu barên zirardar nedan. Digel vê yekê, ew ji hêla pisporên ewlehiyê ve hatin kirin da ku diyar bikin ka çend sepan ji vê êrîşê re xeternak in.
Pêngava paşîn ev e ku meriv pirtûkxaneya Log4j bikar bîne da ku hemî projeyan nas bike. Ger guhertoyên di navbera 2.0-beta9 û 2.14.1 de têne bikar anîn, proje dibe ku gumanbar be.
Ji ber dijwariya destnîşankirina cihê ku ev lawazbûn heye, dikare were tercîh kirin ku proje bi guman e û ku nûvekirina pirtûkxaneyê qursa çalakiyê ya çêtirîn e ku xetereya darvekirina kodê ji holê rake.
Ger guhertoya hatî bikar anîn ji 2.0-beta 9 kêmtir be, proje ne xeternak e, her çend pirtûkxaneya Log4j hîn jî were nûve kirin ji ber ku guhertoyên di rêza 1.x de kevn in û êdî nûvekirin nagirin.
Ma projeyek gumanbar were kifş kirin, tê pêşniyar kirin ku ew were kontrol kirin da ku hûn bibînin ka agahdariya ku bi karanîna Log4j hatî tomar kirin agahdariya ku bikarhêner dikare biguhezîne dihewîne. URL, parametreyên daxwaznameyê, sernav û çerezan mînakên vê daneyê ne. Ger yek ji van were qeyd kirin, proje di xetereyê de ye.
Ev zanîn dikare ji we re bibe alîkar ku hûn bêtir di têketinên pergalê de hûr bibin û diyar bikin ka serlêdana weya webê jixwe êrîş hatiye kirin an na.
Amûrên serhêl ên belaş hene ku dikarin tespît bikin ka serîlêdanek webê xedar e. Yek ji van bernameyan e nêçîra Log4Shell. Ew çavkaniya vekirî ye û li ser heye GitHub.
Ger di serîlêdana serhêl de deverek xizan a kodê were kifş kirin, bargiraniya ku ji hêla amûra eşkerekirî ve hatî peyda kirin dikare were bikar anîn da ku wê di serîlêdana webê de derxîne. Ger qelsî were bikar anîn dê amûra ceribandinê girêdanên ku di navbera serîlêdana weya webê û servera wan LDAP de hatine çêkirin eşkere bike.
Çareseriyên ji bo rastkirina qelsiya Log4j
Pêngava yekem nûvekirina Log4j e, ku hûn dikarin bi karanîna rêvebirên pakêtê yên normal an jî rasterast ji vê yekê dakêşin bikin. rûpel.
Di heman demê de gengaz e ku meriv bi karanîna guhêrbara jîngehê FORMAT MSG NO LOOKUPS li rast were danîn, îstîsmarkirina qelsbûnê kêm bike. Lêbelê, ev tedbîr tenê tenê ji bo guhertoyên Log4j ji 2.10-an mezintir an wekhev e.
Ka em niha vebijarkên alternatîf bifikirin.
1. Xebatên ji bo Log4j guhertoya 2.17.0
Bê guman bi tundî tê pêşniyar kirin ku hûn guhertoya Log4j 2.15.0 bikar bînin da ku li dijî Log4Shell biparêzin, lêbelê, heke ev ne mumkin be, çareseriyên din hene.
Guhertoyên 2.7.0 û paşê yên Log4j: Bi guheztina formata bûyerên ku têne tomar kirin bi karanîna hevoksaziya ji sedî m nolookups ji bo daneya ku ji hêla bikarhêner ve hatî peyda kirin ve gengaz e ku meriv li hember her êrîşê were parastin. Ev nûvekirin hewce dike ku pelê veavakirina Log4j biguherîne da ku guhertoyek nû ya bernameyê çêbike. Wekî encamek, berî ku ev guhertoya nû were bicîh kirin, divê qonaxên pejirandina teknîkî û fonksiyonel bêne dubare kirin.
Guhertoyên Log4j 2.10.0 û paşê: Mînakî, dema destpêkirina makîneya virtual Java bi vebijarka -Dlog4j2, bi danîna pîvana veavakirina log4j2.formatMsgNoLookups li ser rastîn jî gengaz e ku ji her êrişek were parastin. formatMsgNoLookups = rast, Vebijarkek din jî rakirina pola JndiLookup ji argumana classpathê ye, ku dê vektora êrîşê ya sereke jê bibe (lêkolîner îhtîmala vektorek din a êrişê red nakin).
Karûbarên Webê yên Amazon pêvekek germî peyda dike ku "divê bi xetereya xwe were bikar anîn." "Teknîkên" din, wek Logout4Shell, ku "vê qelsiyê li dijî xwe bikar tîne", hatine weşandin. Pisporê ewlehiyê qanûnîbûna vê gavê pirs dike, ku tê de "hakkirina makîneyek ji bo sererastkirina wê."
2. Pirsgirêk di Log4j v2.17.0 de çareser bûye.
Ji bo guhertoyên ji 2.10 mezintir: Log4j2.formatMsgNoLookups divê wekî rast were danîn.
Ji bo guhertoyên 2.0 heya 2.10.0: Fermana jêrîn bimeşînin da ku çîna LDAP ji Log4j derxînin.
Log4j2.formatMsgNoLookups divê di mîhengên pergalê de rast were danîn.
Kêmkirina li JVM
Kêmkirina bi parametreyên JVM êdî ne vebijarkek e. Rêbazên din ên kêmkirinê bi serfirazî berdewam dikin. Ger gengaz be, nûve bikin Log4j guhertoya 2.17.0. Ji bo Log4j v1 rêbernameyek koçberiyê heye.
Ger nûvekirin ne mumkin be, pê ewle bin ku pêkhateyên milê xerîdar û server-aliyê -Dlog4j2.formatMsgNoLookups = set taybetmendiya pergalê ya rastîn heye.
Ji kerema xwe not bikin ku Log4j v1 gihîştiye dawiya jiyana xwe (EOL) û êdî dê rastkirinên xeletiyan wernegire. Vektorên RCE yên din jî ji Log4j v1 re têkildar in. Ji ber vê yekê, em daxwaz dikin ku hûn zûtirîn dem li Log4j 2.17.0 nûve bikin.
3. Tedbîrên sivikkirinê
Karûbarên heyî nekarin bixebitin jî heke Log4j di hin mînakan de hesap be, wek mînak ger makîneya mêvandar guhertoyek Java-ya ji 6u212, 7u202, 8u192, an 11.0.2 bilindtir dimeşîne.
Ev ji ber parastina barkirina çîna dûr a çêtir Navdêr Java û Navbera Rêvebirê (JNDI) di guhertoyên heyî de, ku ji bo xebitandina êrîşê pêdivî ye.
Wekî din, digel guhertoyên Log4j ên ji 2.10-an mezintir, pirsgirêk dikare bi danîna nirxa pergalê ya formatMsgNoLookups wekî rast, peydakirina argumana JVM -Dlog4j2.formatMsgNoLookups = rast, an jêbirina çîna JndiLookup ji rêça dersê were jêbirin.
Di vê navberê de, heya ku mînakên xizan neyên rastkirin, xirapbûn dikare bi karanîna teknîkên jêrîn were çareser kirin:
- Taybetmendiya pergalê log4j2.formatMsgNoLookups ji bo >=2.10 rast bike.
- Vebijarka hawirdorê LOG4J FORMAT MSG NO LOOKUPS ji bo >=2.10 rast bike.
- JndiLookup.class ji sinifa 2.0-beta9 berbi 2.10.0 vekin: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Yek pratîka çêtirîn a pêşniyarkirî ev e ku meriv seyrûsefera derketinê ya li ser înternetê tenê bi portên guncan re sînordar bike.
Her çend piraniya êrişên li qadê bi ser HTTP-ê ve têne radest kirin, lê dibe ku qelsî bi her protokolek ku daneyên têketina bikarhêner bi karanîna Log4j tomar dike were bikar anîn.
Lêbelê, nûvekirina log4j 2.17.0 baştirîn çareserî ye ji ber ku kes dikare nêzîkatiyek zêde ji pirsgirêkê re kifş bike. Wekî din, gelek weşanxane û hilberîner çêtirkirinên karûbar an sepanên xwe ragihandine.
4. Pîvana lawazbûna Log4Shell
Log4j li her derê heye, nemaze ku naha ku qelsî tê bikar anîn. Bi kurtasî, ya ku hûn hewce ne bikin ev e ku karakterên jêrîn di têketinên ku ji hêla Log4j ve têne kontrol kirin de bicîh bikin.
Û ev ê pelê Java ya ku di dawiya URL-ê de ye dakêşîne û bicîh bike. Ew çiqas rasterast e, ew jî dramatîk e.
Wekî ku hûn dizanin, girîng e ku hûn log4j-ê nûve bikin guhertoya >= 2.17.0 da ku vê qelsiya Log4Shell (CVE-2021-44228) çareser bikin.
Ger ev ne gengaz be:
Ji bo serîlêdanên ku guhertoyên pirtûkxaneya Log4j 2.10.0 û jortir bikar tînin, di heman demê de gengaz e ku meriv li hember her êrişek were parastin bi danîna pîvana vesazkirinê log4j2.formatMsgNoLookups wekî rast, mînakî, dema ku makîneya virtual Java bi -Dlog4j2.formatMsgNoLookups = rast dest pê dike. dibe.
Vebijarkek din jêbirina çîna JndiLookup ji argumana classpathê ye, ku dê vektora êrîşê ya bingehîn jê bibe (lêkolîner hebûna vektorek din a êrîşê red nakin).
Not
Rêxistinên ku dudil in an nexwazin ku li pergalên xeternak sererastkirinê bikin (an jî yên ku lê dixwazin parêzbendiyên zêde saz bikin) divê li ser bifikirin:
- Piştrast bikin ku hemî seyrûsefer bi iSensor/ê ve tê rêve kirinWAF/IPS. Ev dikare êrîşê ji gihandina pergalê biparêze.
- Sînordarkirina jimareya seyrûsefera ku dikare bigihîje pergala gumanbar Heke pergal ne hewce ye ku bi înternetê ve were girêdan, gihîştina tenê IPS û rêzikên bingehîn û pêbawer sînordar bikin.
- Kêmkirina seyrûsefera derketinê ya destûrdar a mêvandar. Ji ber ku ev êrîş bi girêdana bi serverek xapînok re tevdigere, divê hemî navnîşanên IP-ya zêde û benderan li ser dîwarek agir bêne asteng kirin.
- Ger karûbar êdî hewce nebe, divê heya ku rastiyek amade be ew neçalak bibe.
Xelasî
Kêmasiyên Log4j civaka me şok kir û anî bîra me ku em çiqasî bi nermalava çavkaniya vekirî ve girêdayî ne.
Log4j yekta ye. Ew ne pergalek xebitandinê ye, ne gerokek e û ne jî nermalavê ye. Belê, ew e ya ku bernamenûs wekî pirtûkxane, pakêt, an modulek kodê binav dikin. Ew tenê ji yek armancê re xizmet dike, ango, tomarkirina tiştê ku li ser serverek diqewime digire.
Kesên ku kodê dinivîsin tercîh dikin ku balê bikişînin ser tiştê ku nermalava wan cihêreng dike. Ew ne eleqedar in ji nû ve îcadkirina çerxê. Wekî encamek, ew xwe dispêrin pir pirtûkxaneyên kodê yên heyî, wek Log4j.
Modula Log4j ji Apache, nermalava servera webê ya ku herî berfireh tê bikar anîn, hatî girtin. Ji ber vê yekê ew dikare li ser mîlyon serveran were kifş kirin. Ji ber vê yekê metirsiyên ewlehiyê zêde dibin.
Ez hêvî dikim ku çareseriyên jorîn ji we re bibin alîkar ku hûn amûrên xwe ewle biparêzin.
Ji bo agahdariya bêtir arîkar ji cîhana teknolojiyê li HashDork bimînin.
Leave a Reply