INHOUDSOPGAWE[Versteek][Wys]
Aan die einde van November 2021 het ons 'n groot bedreiging vir kuberveiligheid ontbloot. Hierdie uitbuiting sal moontlik miljoene rekenaarstelsels wêreldwyd raak.
Hierdie is 'n gids oor die Log4j-kwesbaarheid en hoe 'n ontwerpfout wat oor die hoof gesien is, meer as 90% van die wêreld se rekenaardienste oopgelaat het vir aanval.
Apache Log4j is 'n oopbron Java-gebaseerde aantekenprogram wat deur die Apache Software Foundation ontwikkel is. Oorspronklik geskryf deur Ceki Gülcü in 2001, is dit nou deel van Apache Logging Services, 'n projek van die Apache Software Foundation.
Maatskappye regoor die wêreld gebruik die Log4j-biblioteek om aan te meld by hul toepassings moontlik te maak. Trouens, die Java-biblioteek is so alomteenwoordig dat jy dit in toepassings van Amazon, Microsoft, Google en meer kan vind.
Die prominensie van die biblioteek beteken dat enige potensiële fout in die kode miljoene rekenaars oop kan laat vir inbraak. Op 24 November 2021, a wolksekuriteit navorser wat vir Alibaba werk, het 'n verskriklike fout ontdek.
Die Log4j-kwesbaarheid, ook bekend as Log4Shell, bestaan sedert 2013 ongemerk. Die kwesbaarheid het kwaadwillige akteurs toegelaat om kode op geaffekteerde stelsels wat Log4j gebruik, uit te voer. Dit is op 9 Desember 2021 in die openbaar bekend gemaak
Bedryfskenners noem die Log4Shell-fout die grootste kwesbaarheid in onlangse geheue.
In die week ná die publikasie van die kwesbaarheid het kuberveiligheidspanne miljoene aanvalle opgespoor. Sommige navorsers het selfs 'n koers van meer as honderd aanvalle per minuut waargeneem.
Hoe werk dit?
Om te verstaan hoekom Log4Shell so gevaarlik is, moet ons verstaan waartoe dit in staat is.
Die Log4Shell-kwesbaarheid maak voorsiening vir arbitrêre kode-uitvoering, wat basies beteken dat 'n aanvaller enige opdrag of kode op 'n teikenmasjien kan uitvoer.
Hoe bereik dit dit?
Eerstens moet ons verstaan wat die JNDI is.
Die Java Naming and Directory Interface (JNDI) is 'n Java-diens wat Java-programme toelaat om data en hulpbronne via 'n naam te ontdek en op te soek. Hierdie gidsdienste is belangrik omdat dit 'n georganiseerde stel rekords bied vir ontwikkelaars om maklik na te verwys wanneer toepassings geskep word.
Die JNDI kan verskeie protokolle gebruik om toegang tot 'n sekere gids te verkry. Een van hierdie protokolle is die Lightweight Directory Access Protocol, of LDAP.
Wanneer 'n string aanteken, log4j voer stringvervangings uit wanneer hulle uitdrukkings van die vorm teëkom ${prefix:name}
.
Byvoorbeeld, Text: ${java:version}
kan aangeteken word as Teks: Java weergawe 1.8.0_65. Hierdie soort vervangings is alledaags.
Ons kan ook uitdrukkings hê soos Text: ${jndi:ldap://example.com/file}
wat die JNDI-stelsel gebruik om 'n Java-voorwerp vanaf 'n URL deur die LDAP-protokol te laai.
Dit laai effektief die data wat van daardie URL af in die masjien kom. Enige potensiële hacker kan kwaadwillige kode op 'n publieke URL huisves en wag vir masjiene wat Log4j gebruik om dit aan te teken.
Aangesien die inhoud van logboodskappe gebruikersbeheerde data bevat, kan kuberkrakers hul eie JNDI-verwysings invoeg wat verwys na LDAP-bedieners wat hulle beheer. Hierdie LDAP-bedieners kan vol kwaadwillige Java-voorwerpe wees wat die JNDI deur die kwesbaarheid kan uitvoer.
Wat dit erger maak, is dat dit nie saak maak of die toepassing 'n bedienerkant of 'n kliëntkanttoepassing is nie.
Solank daar 'n manier is vir die logger om die aanvaller se kwaadwillige kode te lees, is die toepassing steeds oop vir uitbuiting.
Wie word geraak?
Die kwesbaarheid raak alle stelsels en dienste wat APache Log4j gebruik, met weergawes 2.0 tot en met 2.14.1.
Verskeie sekuriteitskenners beveel aan dat die kwesbaarheid 'n aantal toepassings wat Java gebruik, kan beïnvloed.
Die fout is die eerste keer ontdek in die Minecraft-videospeletjie wat deur Microsoft besit word. Microsoft het hul gebruikers aangemoedig om hul Java-uitgawe Minecraft-sagteware op te gradeer om enige risiko te voorkom.
Jen Easterly, die direkteur van kuberveiligheid en infrastruktuursekuriteitsagentskap (CISA), sê dat verkopers 'n groot verantwoordelikheid om te verhoed dat eindgebruikers kwaadwillige akteurs hierdie kwesbaarheid uitbuit.
"Verkopers moet ook met hul kliënte kommunikeer om te verseker dat eindgebruikers weet dat hul produk hierdie kwesbaarheid bevat en sagteware-opdaterings moet prioritiseer."
Die aanvalle het glo reeds begin. Symantec, 'n maatskappy wat kubersekuriteitsagteware verskaf, het 'n uiteenlopende aantal aanvalversoeke waargeneem.
Hier is 'n paar voorbeelde van die tipe aanvalle wat navorsers opgespoor het:
- botnets
Botnets is 'n netwerk van rekenaars wat onder die beheer van 'n enkele aanvallende party is. Hulle help om DDoS-aanvalle uit te voer, data te steel en ander swendelary. Navorsers het die Muhstik-botnet in dopskrifte waargeneem wat van die Log4j-ontginning afgelaai is.
- XMRig Miner Trojan
XMRig is 'n oopbron-cryptocurrency-mynwerker wat SVE's gebruik om die Monero-token te myn. Kubermisdadigers kan XMRig op mense se toestelle installeer sodat hulle hul verwerkingskrag sonder hul medewete kan gebruik.
- Khonsari Ransomware
Ransomware verwys na 'n vorm van wanware wat ontwerp is om enkripteer lêers op 'n rekenaar. Aanvallers kan dan betaling eis in ruil daarvoor om toegang tot die geënkripteerde lêers terug te gee. Navorsers het die Khonsari-ransomware in Log4Shell-aanvalle ontdek. Hulle teiken Windows-bedieners en maak gebruik van die .NET-raamwerk.
Wat gebeur volgende?
Kenners voorspel dat dit maande of dalk selfs jare kan neem om die chaos wat deur die Log4J-kwesbaarheid veroorsaak word, ten volle reg te stel.
Hierdie proses behels die opdatering van elke geaffekteerde stelsel met 'n reggemaakte weergawe. Selfs al is al hierdie stelsels reggemaak, is daar steeds die dreigende bedreiging van moontlike agterdeure wat kuberkrakers moontlik reeds by die venster gevoeg het dat bedieners oop was vir aanval.
Baie oplossings en versagtings bestaan om te verhoed dat toepassings deur hierdie fout uitgebuit word. Die nuwe Log4j weergawe 2.15.0-rc1 het verskeie instellings verander om hierdie kwesbaarheid te versag.
Alle kenmerke wat JNDI gebruik, sal by verstek gedeaktiveer word en afstandsoektogte is ook beperk. As u die opsoekfunksie op u Log4j-opstelling deaktiveer, sal dit help om die risiko van moontlike misbruik te verminder.
Buite Log4j is daar steeds die behoefte aan 'n breër plan om oopbron-uitbuiting te voorkom.
Vroeër in Mei het die Wit Huis 'n uitvoerende bevel wat daarop gemik was om nasionale kuberveiligheid te verbeter. Dit het 'n voorsiening ingesluit vir 'n sagteware stuk materiaal (SBOM) wat in wese 'n formele dokument was wat 'n lys bevat van elke item wat nodig is om die toepassing te bou.
Dit sluit dele soos die open source pakkette, afhanklikhede en API's wat vir ontwikkeling gebruik word. Alhoewel die idee van SBOM's nuttig is vir deursigtigheid, sal dit werklik die verbruiker help?
Die opgradering van afhanklikhede kan te veel moeite wees. Maatskappye kan net kies om enige boetes te betaal eerder as om ekstra tyd te mors om alternatiewe pakkette te vind. Miskien sal hierdie SBOM's net nuttig wees as hulle omvang is verder beperk.
Gevolgtrekking
Die Log4j-kwessie is meer as net 'n tegniese probleem vir organisasies.
Sakeleiers moet bewus wees van potensiële risiko's wat kan voorkom wanneer hul bedieners, produkte of dienste staatmaak op kode wat hulle self nie onderhou nie.
Om op oopbron- en derdeparty-toepassings te vertrou, hou altyd 'n mate van risiko in. Maatskappye moet dit oorweeg om risikoversagtingstrategieë uit te werk voordat nuwe bedreigings aan die lig kom.
Baie van die web maak staat op oopbronsagteware wat deur duisende vrywilligers wêreldwyd onderhou word.
As ons die web 'n veilige plek wil hou, moet regerings en korporasies belê in die finansiering van oopbronpogings en kuberveiligheidsagentskappe soos CISA.
Lewer Kommentaar