Îți amintești Heartbleed? Dacă credeți ce se vehiculează astăzi, Shellshock este în acea ligă și cu un nume la fel de grozav, deși lipsit de un logo cool (cineva din departamentul de marketing al acestor vulnerabilități trebuie să se ocupe de asta). Dar, cu toată seriozitatea, are potențialul de a fi ceva important și, așa cum am făcut cu Heartbleed, am vrut să pun laolaltă ceva definitiv, atât pentru mine, pentru a mă familiariza cu situația, cât și pentru alții, pentru a diseca agitația de adevăratul risc subiacent.
Pentru a pregăti terenul, permiteți-mi să vă împărtășesc o parte din conținutul postării de pe blogul lui Robert Graham, care a făcut o analiză excelentă în această privință. Imaginați-vă o solicitare HTTP ca aceasta:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Care, atunci când este emisă împotriva unei serii de adrese IP vulnerabile, are următorul rezultat:
Dispunând pe scurt, Robert tocmai a orchestrat o grămadă de mașini externe pentru a-i face ping pur și simplu prin emiterea unei solicitări atent elaborate pe web. Ceea ce este cu adevărat îngrijorător este faptul că el a determinat efectiv aceste mașini să emită o comandă arbitrară (deși un ping destul de benign) și asta deschide o întreagă lume de posibilități foarte serioase. Dați-mi voie să vă explic.
Ce este Bash și de ce avem nevoie de el?
Săriți peste asta dacă este o știre veche, dar contextul este important pentru cei care nu sunt familiarizați cu Bash, așa că haideți să stabilim o înțelegere de bază. Bash este un shell *nix sau, cu alte cuvinte, un interpretor care vă permite să orchestrați comenzi pe sistemele Unix și Linux, de obicei prin conectarea prin SSH sau Telnet. Poate funcționa, de asemenea, ca un parser pentru scripturi CGI pe un server web, cum ar fi cel pe care îl vedem de obicei rulând pe Apache. Există de la sfârșitul anilor ’80, când a evoluat de la implementările anterioare ale shell-ului (numele derivă de la Bourne shell) și este extrem de popular. Există și alte shell-uri pentru variantele Unix, însă Bash este shell-ul implicit pentru Linux și Mac OS X, care sunt, evident, sisteme de operare extrem de răspândite. Acesta este un factor major în ceea ce privește motivul pentru care acest risc este atât de semnificativ – omniprezența lui Bash – și este descris ca fiind „unul dintre cele mai instalate utilitare pe orice sistem Linux”.
Vă puteți face o idee despre amprenta Bash atunci când vă uitați la cele mai recente statistici Netcraft privind serverele web:
Când jumătate din rețea rulează Apache (care se găsește de obicei pe Linux), aceasta este o dimensiune semnificativă dintr-o plăcintă foarte, foarte mare. Același articol Netcraft raportează că tocmai am depășit și noi pragul de un miliard de site-uri web și, în timp ce o grămadă dintre acestea împart aceleași gazde, asta înseamnă totuși o mulțime de instalații Bash. Oh – și acestea sunt doar serverele web, nu uitați că există o grămadă de alte servere care rulează Linux și vom reveni puțin mai târziu și la alte dispozitive cu Bash.
Bash poate fi folosit pentru o întreagă gamă de funcții administrative tipice, de la configurarea site-urilor web până la controlul software-ului încorporat pe un dispozitiv, cum ar fi o cameră web. Bineînțeles, aceasta nu este o funcționalitate destinată să fie deschisă lumii și, în teorie, vorbim despre utilizatori autentificați care execută comenzi pe care au fost autorizați să le execute. În teorie.
Ce este bug-ul?
Lasă-mă să încep cu CVE-ul din baza de date a vulnerabilităților NIST pentru că dă o idee bună despre gravitate (sublinierea îmi aparține):
GNU Bash prin 4.3 procesează șiruri de caractere de urmărire după definițiile funcțiilor în valorile variabilelor de mediu, ceea ce permite atacatorilor de la distanță să execute cod arbitrar prin intermediul unui mediu modificat, după cum demonstrează vectorii care implică funcția ForceCommand din OpenSSH sshd, modulele mod_cgi și mod_cgid din Apache HTTP Server, scripturi executate de clienți DHCP nespecificați și alte situații în care setarea mediului are loc peste o limită de privilegii față de execuția Bash.
Ei continuă să îi acorde o notă de „10 din 10” pentru gravitate sau, cu alte cuvinte, cât se poate de rău. Acest lucru este agravat de faptul că este ușor de executat atacul (complexitatea accesului este scăzută) și, poate cel mai semnificativ, nu este necesară nicio autentificare atunci când se exploatează Bash prin intermediul scripturilor CGI. Rezumatul de mai sus este totuși un pic alambicat, așa că haideți să ne rezumăm la mecanica bug-ului.
Riscul se concentrează în jurul capacității de a defini în mod arbitrar variabile de mediu în cadrul unui shell Bash care specifică o definiție de funcție. Problemele încep atunci când Bash continuă să proceseze comenzi shell după definiția funcției, rezultând ceea ce am clasifica drept un „atac de injecție de cod”. Să ne uităm din nou la exemplul lui Robert și să luăm doar această linie:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Definirea funcției este () { :; }; iar comanda shell este declarația ping și parametrii subsecvenți. Când acest lucru este procesat în contextul unui shell Bash, comanda arbitrară este executată. Într-un context web, acest lucru ar însemna prin intermediul unui mecanism precum un script CGI și nu neapărat nici ca un antet de cerere. Merită să citiți avizul seclists.org, unde se oferă mai multe detalii, inclusiv faptul că traseul și șirul de interogare ar putea fi vectori potențiali pentru atac.
Desigur, un mijloc de atenuare a acestui vector de atac specific este pur și simplu să dezactivați orice funcționalitate CGI care face apeluri către un shell și, într-adevăr, unii recomandă acest lucru. Cu toate acestea, în multe cazuri, aceasta va fi o schimbare serioasă și, cel puțin, una care va necesita unele teste extinse pentru a se asigura că nu cauzează probleme imediate în site-ul web, ceea ce, în multe cazuri, se va întâmpla.
Proba HTTP de mai sus este una simplă, dar eficientă, deși este doar o implementare pe un protocol comun. Odată ce începeți să aruncați în Telnet și SSH și, aparent, chiar și DHCP, domeniul de aplicare crește dramatic, așa că în niciun caz nu vorbim aici doar despre exploatarea serverelor de aplicații web. (Aparent, riscul este prezent doar în SSH post-auth, dar într-un stadiu atât de timpuriu al dezvăluirii publice vom vedea în mod inevitabil că vor apărea încă și alți vectori de atac.)
Ceea ce trebuie să rețineți, de asemenea, este că domeniul de aplicare a daunelor potențiale se întinde cu mult dincolo de ping-ul unei adrese arbitrare, ca în exemplul lui Robert, aceasta este pur și simplu o mică dovadă clară că ar putea orchestra o mașină pentru a emite o comandă shell. Întrebarea care se pune este următoarea: Ce daune ar putea face un atacator atunci când poate executa o comandă shell aleasă de el pe orice mașină vulnerabilă?
Care sunt ramificațiile potențiale?
Potențialul este enorm – „a obține shell” pe o cutie a fost întotdeauna un câștig major pentru un atacator datorită controlului pe care i-l oferă asupra mediului țintă. Acces la date interne, reconfigurarea mediilor, publicarea propriului cod malițios etc. Este aproape fără limite și, de asemenea, ușor de automatizat. Există deja foarte, foarte multe exemple de exploit-uri care ar putea fi lansate cu ușurință împotriva unui volum mare de mașini.
Din păcate, când vine vorba de executarea arbitrară de cod într-un shell pe până la jumătate din site-urile web de pe internet, potențialul este destul de larg. Una dintre cele mai evidente (și deosebit de urâtă) este descărcarea fișierelor interne pentru a fi preluate de public. Fișierele de parole și fișierele de configurare cu credențiale sunt cele evidente, dar s-ar putea extinde, în mod conceptibil, la orice alte fișiere de pe sistem.
La fel, aceeași abordare ar putea fi aplicată pentru a scrie fișiere în sistem. Acesta este, potențial, cel mai simplu vector de defăimare a unui site web pe care l-am văzut vreodată, ca să nu mai vorbim de o modalitate foarte ușoară de distribuire a programelor malware
Oare ce ziceți de asta: un cuvânt pe care îl tot văd foarte des este „vierme”:
Când vorbim despre vierme în contextul informaticii malițioase, vorbim despre un atac care se autoreplică, în care un actor malițios creează un cod care este capabil să se propage printre ținte. De exemplu, am văzut o implementare foarte eficientă a acestui lucru cu viermele MySpace XSS Worm al lui Samy, unde un JavaScript elaborat cu atenție a reușit să „infecteze” paginile a un milion de victime în mai puțin de o zi.
Îngrijorarea cu Shellshock este că un atac de această natură s-ar putea replica la o rată alarmantă, în special la început, în timp ce majoritatea mașinilor rămân în pericol. În teorie, acest lucru ar putea lua forma unei mașini infectate care scanează alte ținte și propagă atacul către acestea. Acest lucru nu ar fi în niciun caz limitat nici la mașinile orientate spre public; treceți acest lucru în spatele firewall-ului corporativ și cerul este limita.
Oamenii lucrează la exploatarea acestui lucru chiar acum. Aceasta este ceea ce face ca aceste zile de început să fie atât de interesante, pe măsură ce cursa înarmărilor între cei care se grăbesc să aplice patch-uri și cei care se grăbesc să atace se încălzește.
Ce versiuni de Bash sunt afectate?
Titlurile afirmă că totul până la 4.3 sau, cu alte cuvinte, aproximativ 25 de ani de versiuni Bash. Având în vedere că toată lumea continuă să compare acest lucru cu Heartbleed, luați în considerare faptul că versiunile afectate ale OpenSSL s-au întins pe o perioadă de doar doi ani, ceea ce este o picătură în ocean în comparație cu Shellshock. Da, oamenii își actualizează versiunile, dar nu, nu o fac în mod consecvent și, oricum ați tăia-o, amploarea mașinilor cu risc va fi semnificativ mai mare cu Shellshock decât a fost cu Heartbleed.
Dar este foarte posibil ca riscul să se extindă și dincolo de 4.3. Vedem deja rapoarte despre patch-uri care nu sunt în întregime eficiente și, având în vedere viteza cu care sunt lansate, acest lucru nu este atât de surprinzător. Acesta este genul de lucru pe care cei afectați de el vor să îl urmărească îndeaproape, nu doar „patch-uri și uitați”.
Când am aflat prima dată despre el și de cât timp suntem expuși riscului?
Prima mențiune pe care am găsit-o pe undele publice a fost acest rezumat foarte scurt de pe seclists.org, care funcționează la aproximativ 14:00 GMT miercuri (aproximativ la miezul nopții în această dimineață pentru cei dintre noi din partea de est a Australiei). Detaliile au venit în avizul pe care l-am menționat mai devreme, o oră mai târziu, deci ajungând spre mijlocul după-amiezii de miercuri în Europa sau dimineața în SUA. Este încă o știre foarte recentă, cu toate speculațiile obișnuite ale presei și predicțiile lui Chicken Little; este prea devreme pentru a observa o exploatare pe scară largă în sălbăticie, dar acest lucru ar putea, de asemenea, să se întâmple foarte curând dacă riscul se ridică la nivelul potențialului său.
Răsfoiește înapoi dincolo de ceea ce a fost dezvăluit în mod public și se pare că bug-ul a fost descoperit săptămâna trecută de Stéphane Chazelas, un tip din Marea Britanie, „specialist în Unix/Linux, rețele și telecomunicații”. Acestea fiind spuse, în postarea celor de la Akamai cu privire la bug, ei vorbesc despre faptul că acesta a fost prezent pentru „o perioadă extinsă de timp” și, bineînțeles, versiunile vulnerabile de Bash datează de acum două decenii și jumătate. Întrebarea, ca și în cazul Heartbleed, va fi dacă actorii rău intenționați au fost sau nu conștienți de acest lucru înainte de acum și, într-adevăr, dacă l-au exploatat în mod activ.
Sunt afectate „lucrurile” noastre?
Aici devine interesant – avem o mulțime de „lucruri” care pot rula Bash. Bineînțeles că atunci când folosesc acest termen mă refer la „Internetul lucrurilor” (IoT), care reprezintă prevalența din ce în ce mai mare de a băga o adresă IP și un adaptor wireless în orice, de la tacâmurile noastre la încuietorile de la ușă și la globurile de lumină.
Multe dispozitive IoT rulează distribuții Linux încorporate cu Bash. Aceleași dispozitive au demonstrat deja că prezintă vulnerabilități grave de securitate în alte domenii, de exemplu, globurile luminoase LIFX, cu doar câteva luni în urmă, s-a constatat că prezintă scurgeri de credențiale wifi. Deși nu este o vulnerabilitate Bash precum Shellshock, aceasta ne arată că, prin conectarea lucrurilor noastre, intrăm într-o lume cu totul nouă de vulnerabilități în locuri care nu au fost niciodată expuse riscului înainte.
Edit: Câteva persoane s-au referit la prevalența BusyBox care rulează shell-ul Ash pe dispozitivele mobile. Dispozitivele care rulează acest lucru nu par să fie expuse riscului de Shellshock. Dificultatea pentru un consumator este că acesta nu știe ce rulează pe dispozitivele sale, iar acest lucru include și „lucruri” mai tradiționale, cum ar fi routerele. Istoria îndelungată a acestui bug înseamnă că avem mai mult de două decenii de dispozitive care au trecut prin diferite evoluții ale diferitelor sisteme de operare încorporate și avem acum un peisaj foarte divers de mașini și shell-uri care se întind pe o perioadă lungă de timp.
Acest lucru aduce cu sine multe provocări noi; de exemplu, cine se gândește în mod activ că ar trebui să își plaseze regulat patch-uri pe becuri? Luați în considerare, de asemenea, longevitatea dispozitivelor în care apare acest software și dacă acestea sunt de fapt întreținute în mod activ. Într-un caz precum cel al camerelor vulnerabile Trendnet de acum câțiva ani, există, fără îndoială, un număr foarte mare de astfel de camere care încă se află pe web, deoarece, în ceea ce privește aplicarea de patch-uri, acestea sunt destul de mult o propunere de tipul „setați și uitați”. De fapt, în acest caz, există un întreg cont de Twitter dedicat difuzării imaginilor pe care le-a capturat de la proprietarii neștiutori de versiuni vulnerabile. Este o problemă mare, care nu are o rezolvare ușoară și care ne va însoți o perioadă foarte lungă de timp.
Dar shell-urile Bash sunt, de asemenea, prezente în multe dispozitive mai obișnuite, de exemplu în routerele noastre casnice care sunt, în general, orientate spre internet. Vă amintiți când ați corectat ultima dată firmware-ul routerului dumneavoastră? Ok, dacă citiți acest lucru, atunci poate că sunteți genul de persoană tehnică care chiar își patch-uiește routerul, dar puneți-vă în locul consumatorului obișnuit și întrebați-vă din nou acest lucru. Exact.
Toate lucrurile noastre sunt pe stiva Microsoft, suntem în pericol?
Răspunsul scurt „nu”, răspunsul lung „da”. Îl voi aborda mai întâi pe cel mai ușor – Bash nu se găsește în mod nativ pe Windows și, deși există implementări Bash pentru Windows, cu siguranță nu este ceva comun și nu se va găsi pe PC-urile de consum. De asemenea, nu este clar dacă produse precum win-bash sunt de fapt vulnerabile la Shellshock în primul rând.
Răspunsul mai lung este că doar pentru că operați într-un mediu predominant centrat pe Microsoft nu înseamnă că nu aveți Bash rulând pe mașini care deservesc alte scopuri discrete în cadrul acelui mediu. Când am scris despre Heartbleed, am făcut referire la postarea lui Nick Craver despre mutarea Stack Overflow către SSL și m-am referit la această diagramă a infrastructurii lor:
Există componente non-Microsoft așezate în fața stivei lor de aplicații Microsoft, componente prin care traficul trebuie să treacă înainte de a ajunge la serverele web. Acestea sunt, de asemenea, componente care pot avea privilegii ridicate în spatele firewall-ului – care este impactul dacă Shellshock este exploatat pe acestea? Ar putea fi semnificativ și acesta este punctul pe care îl subliniez aici; Shellshock are potențialul de a avea un impact asupra activelor dincolo de doar implementările Bash aflate în pericol, atunci când există într-un ecosistem mai larg de alte mașini.
Sunt administrator de sistem – ce pot face?
În primul rând, este trivial să descoperiți dacă sunteți în pericol, deoarece este un risc atât de ușor de reprodus. Există un test foarte simplu pe care The Register îl sugerează și care constă doar în rularea acestei comenzi în interiorul shell-ului:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Ești „prins” de ecou și ai reușit să exploatezi bug-ul.
Desigur că prioritatea aici va fi corectarea sistemelor cu risc, iar patch-ul se rezumă în esență la asigurarea faptului că niciun cod nu poate fi executat după sfârșitul unei funcții Bash. Distribuțiile Linux, cum ar fi Red Hat, publică îndrumări privind aplicarea de patch-uri la risc, așa că săriți pe ele cu prioritate.
În mod inevitabil vom vedea și definiții pentru sistemele de detectare a intruziunilor și, cu siguranță, vor exista modele comune de căutat aici. Aceasta s-ar putea dovedi o bună implementare imediată pe termen scurt pentru multe organizații, în special în cazul în care pot exista cerințe oneroase de testare înainte de a lansa patch-uri pentru sistemele cu risc. Cei de la Qualys își propun să aibă o definiție care să detecteze atacul destul de repede și, în mod inevitabil, și alți furnizori de IDS lucrează la acest lucru non-stop.
Alte opțiuni mai drastice includ înlocuirea lui Bash cu o implementare shell alternativă sau izolarea sistemelor cu risc, ambele ar putea avea ramificații de anvergură și este puțin probabil să fie decizii luate cu ușurință. Dar probabil că aceasta va fi natura acestui bug pentru mulți oameni – decizii dificile care ar putea avea un impact tangibil asupra afacerii pentru a evita ramificații potențial mult mai semnificative.
O altă problemă care va începe acum să apară foarte des este întrebarea dacă Shellshock a fost deja exploatat într-un mediu. Acest lucru poate fi greu de determinat dacă nu există o logare a vectorilor de atac (de multe ori nu va exista dacă este transmis prin antetul de cerere HTTP sau corpul POST), dar este mai probabil să fie prins decât în cazul Heartbleed, când, în lipsa unor pcaps complete, sarcinile utile ale bătăilor inimii nu ar fi fost în mod normal înregistrate nicăieri. Dar, cu toate acestea, cel mai frecvent răspuns la întrebarea „am fost atacați prin Shellshock” va fi acesta:
din păcate, acesta nu este „Nu, avem dovezi că nu au existat compromisuri”; mai degrabă, „nu avem dovezi care să se întindă pe toată durata de viață a acestei vulnerabilități”. Ne îndoim că mulți oameni au – și acest lucru îi lasă pe proprietarii de sisteme în poziția inconfortabilă de a nu ști ce compromisuri, dacă au existat, ar fi putut avea loc.
Lasă să înceapă speculațiile cu privire la faptul dacă NSA a fost implicată în acest lucru…
Sunt un consumator – ce pot face?
Depinde. Shellshock afectează Mac-urile, așa că, dacă folosiți OS X, în acest stadiu, acesta pare să fie în pericol, ceea ce, pe de o parte, este rău din cauza prevalenței OS X, dar, pe de altă parte, va fi ușor (și, sperăm, rapid) remediat datorită unui mecanism de actualizare destul de bine dovedit (adică Apple poate trimite de la distanță actualizări către mașină).
Dacă sunteți pe un Mac, riscul este ușor de testat, așa cum este descris în acest răspuns de pe Stack Exchange:
Este un test ușor, deși mă îndoiesc că utilizatorul mediu de Mac se va simți confortabil să treacă prin remedierea sugerată, care implică recompilarea Bash.
Cea mai mare îngrijorare o reprezintă dispozitivele care nu au o cale ușoară de aplicare a patch-urilor, de exemplu routerul dumneavoastră. În afară de verificarea pe site-ul web al producătorului pentru firmware actualizat, aceasta va fi o nucă foarte greu de spart. Adesea, routerele furnizate de ISP sunt blocate astfel încât consumatorii să nu schimbe la întâmplare nici configurația, nici firmware-ul și nici nu există întotdeauna o cale de actualizare de la distanță pe care să o poată declanșa. Dacă se combină acest lucru cu gama masivă de dispozitive și vârste care există, acest lucru ar putea fi deosebit de dificil. Desigur, nu este nici genul de lucru pe care consumatorul mediu se va simți confortabil să îl facă singur.
În concluzie, sfatul pentru consumatori este următorul: urmăriți actualizările de securitate, în special pentru OS X. De asemenea, fiți atenți la orice sfat pe care îl puteți primi de la ISP sau de la alți furnizori de dispozitive pe care le aveți și care rulează software încorporat. Fiți prudenți cu privire la e-mailurile care vă solicită informații sau care vă instruiesc să rulați un software – astfel de evenimente sunt adesea urmate de atacuri de phishing care profită de temerile consumatorilor. În prezent, păcălelile îi fac pe oameni să-și pună iPhone-urile în cuptorul cu microunde, așa că nu vă gândiți nicio clipă că nu vor rula o bucată de software trimisă la întâmplare prin e-mail ca „soluție” pentru Shellshock!
Summary
Cu toată probabilitatea, nici măcar nu am început să sondăm amploarea acestei vulnerabilități. Desigur, se fac o mulțime de comparații cu Heartbleed și există o serie de lucruri pe care le-am învățat din acel exercițiu. Unul dintre ele este că a fost nevoie de puțin timp pentru a ne da seama în ce măsură eram dependenți de OpenSSL. Celălalt este că a avut o coadă foarte lungă – la câteva luni după ce a lovit încă mai existau sute de mii de gazde cunoscute care au rămas vulnerabile.
Dar, într-un fel, comparația cu Heartbleed nu este corectă – aceasta este potențial mult mai rea. Heartbleed a permis accesul de la distanță la o cantitate mică de date din memoria mașinilor afectate. Shellshock permite injectarea de cod de la distanță a unor comenzi arbitrare pre-auth, ceea ce este potențial mult mai grav. În această privință, trebuie să fiu de acord cu Robert:
Este încă foarte, foarte devreme – la momentul redactării acestui articol a trecut doar o jumătate de zi de când a apărut pe undele radio – și bănuiesc că până acum nu facem decât să zgâriem suprafața a ceea ce va urma.
Securitate