Sisällysluettelo[Piilottaa][Näytä]
Internet-haavoittuvuus Log4Shell vaikutti äskettäin miljooniin koneisiin. Log4j, hämärä mutta lähes kaikkialla oleva ohjelmisto, aiheuttaa sen.
Log4j:tä käytetään kirjaamaan kaikki toiminnot, jotka tapahtuvat kulissien takana useissa tietokonejärjestelmissä.
Se perustuu avoimen lähdekoodin lokikirjastoon, jota yritykset ja jopa valtion organisaatiot käyttävät useimmissa sovelluksissa.
Koska se on yksi pahimmista koskaan paljastetuista kyberturva-aukoista, on tärkeää suojata järjestelmäsi tältä haavoittuvuudella. Mutta miten?
Tutkitaan Log4j-haavoittuvuutta yksityiskohtaisesti ja kaikkia mahdollisia korjausratkaisuja siihen.
Mikä on Log4j?
Log4j on avoimen lähdekoodin kirjauskehys, jonka avulla ohjelmistokehittäjät voivat tallentaa erilaisia tietoja sovelluksissaan. Se on osa Apache Logging Services -projektia, jota ylläpitää Apache-ohjelmistosäätiö.
Sadat verkkosivustot ja sovellukset käyttävät Log4j:tä kriittisten toimintojen suorittamiseen, kuten tietojen kirjaamiseen virheenkorjausta ja muita käyttötarkoituksia varten.
Kun syötät tai napsautat huonoa online-linkkiä ja saat 404-virheilmoituksen, tämä on yleinen esimerkki Log4j:stä työssä. Web-palvelin, joka käyttää verkkolinkin toimialuetta, jota yritit käyttää, ilmoittaa, että tällaista verkkosivua ei ole olemassa. Se myös kirjaa tapahtuman lokiin Log4j:ssä palvelimen järjestelmänvalvojille.
Kaikissa ohjelmistoissa käytetään samanlaisia diagnostisia signaaleja. Esimerkiksi online-pelissä Minecraft palvelin käyttää Log4j:tä kirjaamaan toimintaan, kuten käytetyn RAM-muistin kokonaismäärän ja konsoliin lähetetyt käyttäjäohjeet.
Miten haavoittuvuus ilmenee?
Haut ovat Log4j 2.0:ssa käyttöön otettu uusi ominaisuus, joka auttaa sisällyttämään lisätietoa lokimerkintöihin. Yksi näistä hauista on JNDI (Java Naming and Directory Interface) -haku, joka on Java API hakemistopalvelun kanssa viestimiseen.
Tätä lähestymistapaa käyttämällä sisäiset käyttäjätunnukset voidaan yhdistää todellisiin käyttäjänimiin. Tämä kysely paljastaa äskettäin löydetyn RCE-haavoittuvuuden, koska yksi LDAP-palvelimen toimittamista tietotyypeistä on Java-luokkaan osoittava URI, joka sitten ladataan muistiin ja jota Log4j-ilmentymä suorittaa.
Log4j-kirjaston syötteen tarkistuksen heikkouden vuoksi on mahdollista syöttää mielivaltainen LDAP-palvelin epäluotettavasta lähteestä. Koska kehittäjät olettavat, että lokeihin lähetettyjä tietoja käsitellään pelkkänä tekstinä, ylimääräistä syötteen validointia ei suoriteta ja vaarallinen käyttäjän syöte tulee lokeihin.
Lokilausunto voi näyttää tältä:
Haitallinen käyttäjä lisäisi nyt URL-parametriin JNDI-haun, joka viittaa LDAP-palvelimeen. JNDI-haku olisi seuraava:
Log4j-kirjasto keskustelee sitten tämän LDAP-palvelimen kanssa osoitteessa attacker.com saadakseen hakemistotiedot, mukaan lukien Java Factoryn ja Java Codebasen arvot.
Nämä kaksi arvoa sisältävät hyökkääjän Java-luokan, joka sitten ladataan muistiin ja suorittaa Log4j-ilmentymän, jolloin koodin suorittaminen on valmis.
Kuka on vaarassa?
Log4j-haavoittuvuus on uskomattoman laaja, ja se vaikuttaa yrityssovelluksiin, sulautettuihin laitteisiin ja niiden alijärjestelmiin. Sovelluksia, joita tämä koskee, ovat Cisco Webex, Minecraft ja FileZilla FTP.
Tämä ei kuitenkaan suinkaan ole koko lista. Vika vaikuttaa jopa Ingenuity Mars 2020 -chopper-tehtävään, joka käyttää Apache Log4j:tä tapahtumien tallentamiseen.
Turvallisuusyhteisö on koonnut a luettelo haavoittuvista järjestelmistä. On erittäin tärkeää huomata, että näitä luetteloita päivitetään jatkuvasti, joten jos tiettyä ohjelmaa tai järjestelmää ei esitetä, älä oleta, ettei se vaikuta siihen.
Altistuminen tälle haavoittuvuudelle on melko todennäköistä, vaikkakin tiettyä tech-pino ei käytä Javaa, tietoturvajohtajien tulee odottaa kriittisten toimittajajärjestelmien, SaaS-toimittajien, pilvipalveluntarjoajien ja verkkopalvelintarjoajien tekevän niin.
Kuinka tarkistaa Log4j-haavoittuvuus?
Ensimmäinen askel on selvittää, onko hyökkäys jo tapahtunut. Voit tehdä sen tarkistamalla järjestelmän lokeista RCE-hyötykuorman fragmenttien varalta.
Jos haku termeillä, kuten "jndi", "ldap" tai "$::" tuottaa lokeja, tietoturvatutkijoiden tulee tutkia tarkemmin, onko kyseessä laillinen hyökkäys vai pelkkä sormenjälkien otto.
Luonnossa havaittiin monia hyökkäyksiä, jotka eivät tuottaneet haitallisia hyötykuormia. Siitä huolimatta tietoturvaasiantuntijat suorittivat ne selvittääkseen, kuinka monta sovellusta alttiina tälle hyökkäykselle.
Seuraava askel on käyttää Log4j-kirjastoa kaikkien projektien tunnistamiseen. Jos käytetään versioita 2.0-beta9 ja 2.14.1 välillä, projekti voi olla altis.
Koska tämän haavoittuvuuden määrittäminen on vaikeaa, voi olla parempi olettaa, että projekti on herkkä ja että kirjaston päivittäminen on paras tapa poistaa koodin suorittamisen vaara.
Projekti ei ole haavoittuvainen, jos käytetty versio on pienempi kuin 2.0-beta 9, vaikka Log4j-kirjasto pitäisi silti päivittää, koska 1.x-alueen versiot ovat vanhoja eivätkä enää saa päivityksiä.
Jos herkkä projekti havaitaan, on suositeltavaa tarkistaa, sisältääkö Log4j:n avulla kirjatut tiedot tietoja, joita käyttäjä voi muuttaa. URL-osoitteet, pyyntöparametrit, otsikot ja evästeet ovat esimerkkejä näistä tiedoista. Jos jokin näistä kirjataan, projekti on vaarassa.
Nämä tiedot voivat auttaa sinua syventymään järjestelmän lokeihin ja määrittämään, onko verkkosovellukseesi jo hyökätty.
On olemassa ilmaisia verkkotyökaluja, jotka voivat havaita, onko verkkosovellus haavoittuvainen. Yksi näistä ohjelmista on Log4Shell metsästäjä. Se on avoimen lähdekoodin ja saatavilla GitHub.
Jos verkkosovelluksessa havaitaan haavoittuva koodialue, paljastetun työkalun tuottamaa hyötykuormaa voidaan käyttää syöttämään se verkkosovellukseen. Testaustyökalu paljastaisi verkkosovelluksesi ja heidän LDAP-palvelimensa väliset yhteydet, jos haavoittuvuutta hyödynnetään.
Ratkaisuja Log4j-haavoittuvuuden korjaamiseen
Ensimmäinen askel on päivittää Log4j, jonka voit tehdä käyttämällä normaaleja paketinhallintaohjelmia tai lataamalla sen suoraan tästä sivulla.
On myös mahdollista vähentää haavoittuvuuden hyödynnettävyyttä asettamalla ympäristömuuttujan FORMAT MSG NO LOOKUPS arvoksi tosi. Tämä vastatoimenpide koskee kuitenkin vain Log4j-versioita, jotka ovat suurempia tai yhtä suuria kuin 2.10.
Mietitään nyt vaihtoehtoisia vaihtoehtoja.
1. Ratkaisut Log4j-versiolle 2.17.0
On ehdottomasti suositeltavaa käyttää Log4j:n versiota 2.15.0 suojautumaan Log4Shellia vastaan, mutta jos tämä ei ole mahdollista, muita ratkaisuja on saatavilla.
Log2.7.0j:n versiot 4 ja uudemmat: Kaikilta hyökkäyksiltä voidaan suojautua muuttamalla kirjattavien tapahtumien muotoa käyttämällä käyttäjän toimittamien tietojen prosentuaalista m nolookups -syntaksia. Tämä päivitys edellyttää Log4j-määritystiedoston muokkaamista uuden version luomiseksi ohjelmasta. Tämän seurauksena tekniset ja toiminnalliset validointivaiheet on toistettava ennen tämän uuden version käyttöönottoa.
Log4j-versiot 2.10.0 ja uudemmat: On myös mahdollista suojautua kaikilta hyökkäyksiltä asettamalla log4j2.formatMsgNoLookups-määritysparametrin arvoksi tosi, esimerkiksi käynnistettäessä Java-virtuaalikonetta -Dlog4j2-vaihtoehdolla." formatMsgNoLookups = true, Toinen vaihtoehto on poistaa JndiLookup-luokka luokkapolun argumentista, mikä poistaa päähyökkäysvektorin (tutkijat eivät sulje pois mahdollisuutta toiselle hyökkäysvektorille).
Amazon Web Services tarjoaa hotpatchin, jota "pitäisi käyttää omalla vastuullasi". Muita "tekniikoita", kuten Logout4Shell, joka "käyttää tätä haavoittuvuutta itseään vastaan", on julkaistu. Tietoturvaasiantuntija kyseenalaistaa tämän liikkeen laillisuuden, mikä tarkoittaa "koneen hakkerointia sen korjaamiseksi".
2. Ongelma on ratkaistu Log4j v2.17.0:ssa.
Versiot, jotka ovat uudemmat kuin 2.10: Log4j2.formatMsgNoLookups-arvon tulee olla tosi.
Versiot 2.0–2.10.0: Suorita seuraava komento poistaaksesi LDAP-luokan Log4j:stä.
Log4j2.formatMsgNoLookups-arvoksi tulee asettaa tosi järjestelmäasetuksissa.
Lievennys JVM:ssä
Lieventäminen JVM-parametreilla ei ole enää vaihtoehto. Muut lieventämiskeinot ovat edelleen menestyksekkäitä. Päivitä Log4j-versioon 2.17.0, jos mahdollista. Log4j v1:lle on saatavana siirto-opas.
Jos päivitys ei ole mahdollista, varmista, että asiakas- ja palvelinpuolen komponenteilla on -Dlog4j2.formatMsgNoLookups = true system -ominaisuusjoukko.
Huomaa, että Log4j v1 on saavuttanut käyttöikänsä lopun (EOL), eikä se enää saa virheenkorjauksia. Muut RCE-vektorit ovat myös herkkiä Log4j v1:lle. Siksi kehotamme sinua päivittämään Log4j 2.17.0:aan mahdollisimman pian.
3. Lieventämistoimenpiteet
Nykyiset hyväksikäytöt eivät voi toimia, vaikka Log4j olisi joissain tapauksissa altis, esimerkiksi jos isäntäkoneessa on Java-versio, joka on uudempi kuin 6u212, 7u202, 8u192 tai 11.0.2.
Tämä johtuu paremmasta Java Naming and Directory Interface (JNDI) -etäluokan lataussuojauksesta nykyisissä versioissa, mikä on välttämätöntä hyökkäyksen toiminnan kannalta.
Lisäksi Log4j-versioissa, jotka ovat suurempia kuin 2.10, ongelma voidaan välttää asettamalla formatMsgNoLookups-järjestelmäarvoksi tosi, antamalla JVM-argumentti -Dlog4j2.formatMsgNoLookups = true tai poistamalla JndiLookup-luokka luokkapolusta.
Sillä välin, kunnes haavoittuvat esiintymät on korjattu, haavoittuvuus voidaan korjata alla olevilla tekniikoilla:
- Aseta järjestelmäominaisuuden log4j2.formatMsgNoLookups arvoksi tosi arvolle >=2.10.
- Aseta ympäristöasetukseksi LOG4J FORMAT MSG NO LOOKUPS tosi arvoon >=2.10.
- Poista JndiLookup.class luokkapolusta 2.0-beta9 - 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Yksi suositeltu paras käytäntö on rajoittaa Internet-lähtöliikenne vain asianmukaisiin portteihin.
Vaikka useimmat kenttähyökkäykset toimitetaan HTTP:n kautta, haavoittuvuutta voidaan hyödyntää minkä tahansa protokollan kautta, joka kirjaa käyttäjän syöttämät tiedot Log4j:n avulla.
Päivitys log4j 2.17.0:aan on kuitenkin paras ratkaisu, koska joku voi löytää lisälähestymistavan ongelmaan. Lisäksi monet julkaisijat ja valmistajat ovat ilmoittaneet parannuksista palveluihinsa tai sovelluksiinsa.
4. Log4Shell-haavoittuvuuskorjaus
Log4j on kaikkialla läsnä, varsinkin nyt, kun haavoittuvuutta hyödynnetään. Yhteenvetona totean, että sinun tarvitsee vain sisällyttää seuraavat merkit Log4j:n tarkastamiin lokeihin.
Ja tämä lataa ja suorittaa URL-osoitteen lopussa olevan Java-tiedoston. Se on yhtä suoraviivaista kuin dramaattista.
Kuten tiedät, on tärkeää päivittää log4j versioon >= 2.17.0 tämän Log4Shell-haavoittuvuuden (CVE-2021-44228) korjaamiseksi.
Jos tämä ei ole mahdollista:
Sovelluksissa, jotka käyttävät Log4j-kirjaston versiota 2.10.0 tai uudempia, on myös mahdollista suojautua kaikilta hyökkäyksiltä asettamalla määritysparametri log4j2.formatMsgNoLookups arvoon tosi, esimerkiksi kun Java-virtuaalikone käynnistetään komennolla -Dlog4j2.formatMsgNoLookups = true vaihtoehto.
Toinen vaihtoehto on poistaa JndiLookup-luokka classpath-argumentista, mikä poistaa ensisijaisen hyökkäysvektorin (tutkijat eivät sulje pois toisen hyökkäysvektorin olemassaoloa).
Huomautuksia
Organisaatioiden, jotka epäröivät tai eivät halua tehdä muutoksia herkkiin järjestelmiin (tai jotka haluavat, mutta haluavat asentaa ylimääräisiä suojatoimia), tulisi miettiä seuraavia asioita:
- Varmista, että kaikki liikenne ohjataan iSensorin/WAF/IPS. Tämä voi estää hyökkäystä pääsemästä järjestelmään.
- Herkän järjestelmän tavoittavan liikenteen rajoittaminen Jos järjestelmän ei tarvitse olla yhteydessä Internetiin, rajoita pääsy vain välttämättömiin ja luotettaviin IPS-järjestelmiin ja -alueisiin.
- Isännän valtuutetun lähtevän liikenteen vähentäminen. Koska tämä hyökkäys toimii muodostamalla yhteyden roistopalvelimeen, kaikki tarpeettomat IP-osoitteet ja portit tulee estää palomuurista.
- Jos palvelua ei enää tarvita, se tulee poistaa käytöstä, kunnes korjaus on valmis.
Yhteenveto
Log4j-virheet järkyttivät yhteisöämme ja muistuttivat meitä kaikkia siitä, kuinka riippuvaisia avoimen lähdekoodin ohjelmistoista olemme.
Log4j on ainutlaatuinen. Se ei ole käyttöjärjestelmä, selain eikä ohjelmisto. Pikemminkin se on se, mitä ohjelmoijat kutsuvat kirjastoksi, paketiksi tai koodimoduuliksi. Se palvelee vain yhtä tarkoitusta, eli pitää kirjaa siitä, mitä palvelimella tapahtuu.
Koodia kirjoittavat ihmiset keskittyvät mieluummin siihen, mikä tekee heidän ohjelmistostaan erottuvan. He eivät ole kiinnostuneita pyörän keksimisestä uudelleen. Tämän seurauksena ne luottavat lukuisiin olemassa oleviin koodikirjastoihin, kuten Log4j.
Log4j-moduuli on johdettu Apachesta, laajimmin käytetystä verkkopalvelinohjelmistosta. Siksi se voidaan löytää miljoonilta palvelimilta. Tämä lisää turvallisuusuhkia.
Toivon, että yllä olevat ratkaisut auttavat sinua pitämään laitteesi turvassa.
Pysy kuulolla HashDorkista saadaksesi lisää hyödyllistä tietoa teknologiamaailmasta.
Jätä vastaus