S3 Ep146: Povestește-ne despre acea încălcare! (Dacă doriți să.)

Nu există player audio mai jos? Asculta direct pe Soundcloud.

---

DOUG.  Actualizări Firefox, alta Bug cu un nume impresionant, iar SEC cere dezvăluirea.

Toate acestea și multe altele pe podcastul Naked Security.

[MODEM MUZICAL]

Bine ați venit la podcast, toată lumea.

Eu sunt Doug Aamoth; el este Paul Ducklin.

Paul, sper că vei fi mândru de mine... Știu că ești un pasionat de ciclism.

Am mers ieri pe bicicletă pentru 10 mile americane, ceea ce cred că este de aproximativ 16 km, totul în timp ce trăgeam un copil mic, dar nu negreu, în spatele bicicletei, într-un cărucior cu două roți.

Și încă sunt în viață să spun povestea.

Este un drum lung să mergi pe bicicletă, Paul?

---

RAȚĂ.  [RÂDE] Depinde cât de departe trebuia să mergi.

De exemplu, dacă ar fi fost de fapt 1200 de metri pe care ai trebuit să mergi și te-ai rătăcit... [Râsete]

Entuziasmul meu pentru ciclism este foarte mare, dar asta nu înseamnă că merg în mod deliberat mai departe decât trebuie, pentru că este modul meu principal de a mă deplasa.

Dar 10 mile este OK.

Știați că milele americane și milele britanice sunt, de fapt, identice?

---

DOUG.  E bine de stiut!

---

RAȚĂ.  Și au fost din 1959, când o grămadă de țări, inclusiv, cred, Canada, Africa de Sud, Australia, Statele Unite și Marea Britanie s-au unit și au convenit să standardizeze un „inch internațional”.

Cred că inchul imperial s-a micșorat foarte, foarte puțin, iar inchul american a devenit foarte, foarte puțin mai lung, astfel încât inch (și, prin urmare, curtea, și piciorul și mila)...

... toate sunt definite în termeni de metru.

Un inch este exact 25.4 mm

Trei cifre semnificative este tot ce ai nevoie.

---

DOUG.  Fascinant!

Ei bine, vorbind despre fascinant, este timpul pentru noi Săptămâna aceasta în istoria tehnologiei segment.

Săptămâna aceasta, la 01 august 1981, Music Television, cunoscută și sub numele de MTV, a fost difuzată în direct ca parte a pachetelor americane de televiziune prin cablu și prin satelit și a prezentat publicului videoclipuri muzicale.

Primul a jucat [SINGS, RATHER BINE DE FACT] „Video Killed the Radio Star” de The Buggles.

Se potrivește la acea vreme, deși ironic în zilele noastre, deoarece MTV mai redă rar videoclipuri muzicale și nu redă niciun videoclip nou, Paul.

---

RAȚĂ.  Da, este ironic, nu-i așa, că televiziunea prin cablu (cu alte cuvinte, unde aveai fire care trec sub pământ în casa ta) a ucis steaua radioului (sau wireless), iar acum pare că televiziunea prin cablu, MTV... ăsta s-a stins pentru că toată lumea are rețele mobile care funcționează fără fir.

Ceea ce se întâmplă, vine în jur, Douglas.

---

DOUG.  Bine, hai să vorbim despre aceste actualizări pentru Firefox.

Primim o doză dublă de actualizări pentru Firefox luna aceasta, deoarece acestea sunt pe un ciclu de 28 de zile:

Firefox remediază o serie de defecte în prima dintre cele două versiuni din această lună

Fără zile zero în această primă rundă, ci câteva momente de învățat.

Am enumerat poate jumătate dintre acestea în articolul tău, iar unul care m-a remarcat cu adevărat a fost: Solicitarea de permisiuni potențiale ocolite prin clickjacking.

---

RAȚĂ.  Da, clickjacking vechi din nou.

Îmi place acest termen pentru că descrie destul de mult ce este.

Faceți clic undeva, crezând că faceți clic pe un buton sau pe un link nevinovat, dar autorizați din neatenție să se întâmple ceva care nu este evident din ceea ce arată ecranul sub cursorul mouse-ului.

Problema aici pare să fie că, în anumite circumstanțe, când un dialog de permisiuni era pe cale să apară din Firefox, de exemplu, spuneți: „Sunteți cu adevărat sigur că doriți să lăsați acest site să vă folosească camera? ai acces la locația ta? folosești microfonul?”…

… toate acele lucruri pe care, da, vrei să fii întrebat.

Aparent, dacă ați putea duce browserul la un punct de performanță (din nou, performanță versus securitate) în care se străduia să țină pasul, ați putea întârzia apariția ferestrei pop-up cu permisiuni.

Dar, având un buton în locul în care ar apărea fereastra pop-up și atrăgând utilizatorul să facă clic pe el, ați putea atrage clicul, dar clicul va fi trimis apoi către dialogul de permisiuni pe care nu ați văzut-o încă.

Un fel de condiție vizuală de cursă, dacă vrei.

---

DOUG.  OK, iar celălalt a fost: Pânza în afara ecranului ar fi putut ocoli restricțiile de origine încrucișată.

Continuați spunând că o pagină web ar putea arunca o privire la imagini afișate în altă pagină de pe un alt site.

---

RAȚĂ.  Asta nu ar trebui să se întâmple, nu-i așa?

---

DOUG.  Nu!

---

RAȚĂ.  Termenul din jargon pentru aceasta este „politica de aceeași origine”.

Dacă rulați site-ul X și îmi trimiteți o mulțime de JavaScript care setează o mulțime de cookie-uri, atunci toate acestea sunt stocate în browser.

Dar numai alte JavaScript de pe site-ul X pot citi aceste date înapoi.

Faptul că navighezi către site-ul X într-o filă și site-ul Y în cealaltă filă nu îi lasă să se uite la ceea ce face celălalt, iar browserul ar trebui să țină toate aceste lucruri deoparte.

Asta e evident destul de important.

Și aici se pare că, din câte am înțeles, dacă ai reda o pagină care nu era încă afișată...

… o pânză în afara ecranului, care este locul în care creați, dacă doriți, o pagină web virtuală și apoi, la un moment dat viitor, spuneți: „În acest moment sunt gata să o afișez” și bingo, pagina apare toată la o singura data.

Problema vine cu încercarea de a vă asigura că lucrurile pe care le redați în mod invizibil nu scurg din greșeală date, chiar dacă în cele din urmă nu sunt afișate utilizatorului.

Au observat asta, sau a fost dezvăluit în mod responsabil și a fost corectat.

Și cele două, cred, au fost incluse în așa-numitele vulnerabilități de nivel „înalt”.

Cele mai multe dintre celelalte au fost „Moderate”, cu excepția tradiționalului Mozilla, „Am găsit o mulțime de erori prin fuzzing și prin tehnici automate; nu i-am sondat pentru a afla dacă ar putea fi exploatate deloc, dar suntem dispuși să presupunem că cineva care a încercat suficient ar putea face acest lucru.”

Este o recunoaștere care ne place atât de mult, Doug, pentru că potențialele bug-uri merită înlăturate, chiar dacă ești sigur în inima ta că nimeni nu va înțelege vreodată cum să le exploateze.

Pentru că în securitatea cibernetică, merită să nu spui niciodată niciodată!

---

DOUG.  Bine, cauți Firefox 116 sau, dacă ai o versiune extinsă, 115.1.

La fel și cu Thunderbird.

Și să trecem la... o, omule!

Paul, e incitant!

Avem un nou BWAIN după un dublu BWAIN săptămâna trecută: un bug cu un nume impresionant.

Acesta se numește Ciocnire+putere:

Performanța și securitatea se ciocnesc din nou în atacul „Collide+Power”.

---

RAȚĂ.  [RÂDE] Da, este intrigant, nu-i așa, că au ales un nume care are semnul plus în el?

---

DOUG.  Da, asta face greu de spus.

---

RAȚĂ.  Nu puteți avea un semn plus în numele domeniului dvs., așa că numele domeniului este collidepower.com.

---

DOUG.  Bine, permiteți-mi să citesc de la cercetătorii înșiși și citez:

Rădăcina problemei este că componentele CPU partajate, cum ar fi sistemul de memorie internă, combină datele atacatorului și datele din orice altă aplicație, rezultând un semnal de scurgere combinat în consumul de energie.

Astfel, cunoscându-și propriile date, atacatorul poate determina exact valorile datelor folosite în alte aplicații.

---

RAȚĂ.  [RÂDE] Da, asta are foarte mult sens dacă știi deja despre ce vorbesc!

Pentru a încerca să explic acest lucru într-o engleză simplă (sper că am înțeles corect)...

Acest lucru se reduce la problemele de performanță versus securitate despre care am vorbit înainte, inclusiv podcastul de săptămâna trecută cu ce Zenbleed bug (care este mult mai grav, apropo):

Zenbleed: Cum căutarea performanței procesorului v-ar putea pune parolele în pericol

Există o mulțime de date care sunt păstrate în interiorul procesorului („în cache” este termenul tehnic pentru aceasta), astfel încât CPU să nu fie nevoie să le preia mai târziu.

Deci, există o mulțime de lucruri interne pe care nu le poți gestiona cu adevărat; procesorul are grijă de el pentru tine.

Iar inima acestui atac pare să meargă cam așa...

Ceea ce face atacatorul este să acceseze diverse locații de memorie în așa fel încât memoria cache internă să-și amintească acele locații de memorie, astfel încât să nu fie nevoie să le citească din nou din RAM dacă sunt reutilizate rapid.

Deci, atacatorul obține cumva aceste valori cache umplute cu modele cunoscute de biți, valori cunoscute de date.

Și apoi, dacă victima are memorie pe care *ea* o folosește frecvent (de exemplu, octeții dintr-o cheie de decriptare), dacă valoarea lor este brusc judecată de CPU ca fiind mai probabil să fie reutilizată decât una dintre valorile atacatorilor, scoate valoarea atacatorului din acea locație internă de cache super-rapidă și pune acolo noua valoare, valoarea victimei.

Și ceea ce au descoperit acești cercetători (și oricât de exagerat sună atacul în teorie și este în practică, acesta este un lucru uimitor de descoperit)...

Numărul de biți care diferă între vechea valoare din cache și noua valoare *modifică cantitatea de putere necesară pentru a efectua operația de actualizare a cache-ului*.

Prin urmare, dacă puteți măsura consumul de energie al procesorului suficient de precis, puteți face inferențe despre valorile datelor care au fost scrise în memoria cache internă, ascunsă, altfel invizibilă, din interiorul procesorului, despre care CPU-ul credea că nu este treaba dumneavoastră.

Destul de intrigant, Doug!

---

DOUG.  Remarcabil.

OK, există unele atenuări.

În acea secțiune, începe: „În primul rând, nu trebuie să vă faceți griji”, dar, de asemenea, aproape toate procesoarele sunt afectate.

---

RAȚĂ.  Da, e interesant, nu-i așa?

Scrie „în primul rând” (text normal) „tu" (cu caractere inclinate) "nu trebuie să vă faceți griji” (îngroșat). [râde]

Deci, practic, nimeni nu te va ataca cu asta, dar poate că designerii CPU vor să se gândească la asta în viitor, dacă există vreo modalitate de a o evita. [râde]

Mi s-a părut un mod interesant de a spune.

---

DOUG.  OK, deci atenuarea este practic să dezactivezi hyperthreading.

Așa funcționează?

---

RAȚĂ.  Hyperthreading face acest lucru mult mai rău, din câte văd.

Știm deja că hyperthreading-ul este o problemă de securitate, deoarece au existat numeroase vulnerabilități care depind de el înainte.

Este locul în care un procesor, să zicem, cu opt nuclee pretinde că are 16 nuclee, dar de fapt nu sunt în părți separate ale cipului.

Sunt de fapt perechi de pseudo-nuclee care împărtășesc mai multe electronice, mai multe tranzistoare, mai mulți condensatori, decât este poate o idee bună din motive de securitate.

Dacă rulați OpenBSD vechi, cred că au decis că hyperthreading este prea greu de asigurat cu atenuări; ar putea la fel de bine să-l dezactiveze.

Până la momentul în care ați luat hit-urile de performanță pe care le necesită atenuările, ați putea la fel de bine să nu le aveți.

Deci cred că dezactivarea hyperthreading-ului te va imuniza foarte mult împotriva acestui atac.

Al doilea lucru pe care îl puteți face este, așa cum spun autorii cu caractere aldine: Nu iti face griji. [RÂSETE]

---

DOUG.  Este o mare atenuare! [râde]

---

RAȚĂ.   Există ceva grozav (va trebui să citesc asta, Doug)...

Există un lucru grozav în care cercetătorii înșiși au descoperit că pentru a obține orice fel de informații fiabile, ei obțin rate de date de undeva între 10 și 100 de biți pe oră din sistem.

Cred că cel puțin procesoarele Intel au o atenuare care îmi imaginez că ar ajuta împotriva acestui lucru.

Și asta ne readuce la MSR-uri, acele registre specifice modelului despre care am vorbit săptămâna trecută cu Zenbleed, unde a fost un pic magic pe care îl puteai activa și care spunea „Nu face lucrurile riscante”.

Există o funcție pe care o puteți seta numită filtrare RAPL, iar RAPL este prescurtarea pentru limită medie de funcționare a puterii.

Este folosit de programele care doresc să vadă cum funcționează un procesor în scopuri de gestionare a energiei, astfel încât nu trebuie să intri în camera serverului și să pui un monitor de putere pe un fir cu o mică sondă pe placa de bază. [râde]

De fapt, puteți determina procesorul să vă spună câtă putere folosește.

Intel cel puțin are acest mod numit filtrare RAPL, care introduce în mod deliberat jitter sau eroare.

Astfel, veți obține rezultate care, în medie, sunt precise, dar în care fiecare citire individuală va fi oprită.

---

DOUG.  Să ne îndreptăm acum atenția asupra acestui nou acord SEC.

Comisia de Securitate și Schimb cere limite de patru zile de dezvăluire a încălcărilor securității cibernetice:

SEC cere o limită de divulgare de patru zile pentru încălcările securității cibernetice

Dar (A) poți decide dacă un atac este suficient de grav pentru a fi raportat și (B) limita de patru zile nu începe până când nu decizi că ceva este suficient de important pentru a raporta, Paul.

Deci, un prim început bun, dar poate nu atât de agresiv pe cât ne-am dori?

---

RAȚĂ.  Sunt de acord cu evaluarea ta acolo, Doug.

Suna grozav când m-am uitat prima oară: „Hei, aveți această dezvăluire de patru zile dacă aveți o încălcare a datelor sau o problemă de securitate cibernetică.”

Dar apoi a fost vorba despre „Ei bine, trebuie considerată o problemă materială”, un termen legal care înseamnă că de fapt contează suficient pentru a merita dezvăluit în primul rând.

Și apoi am ajuns la acel fragment (și nu este un comunicat de presă foarte lung al SEC) care spunea: „De îndată ce ai decis că ar trebui să raportezi asta, mai ai patru zile. să-l raportezi.”

Acum, îmi imaginez că, din punct de vedere legal, nu așa va funcționa. Doug

Poate că suntem puțin aspri în articol?

---

DOUG.  Măriți atacurile ransomware, spunând că există câteva tipuri diferite, așa că să vorbim despre asta... este important pentru a determina dacă acesta este un atac material pe care trebuie să îl raportați.

Deci, la ce fel de ransomware ne uităm?

---

RAȚĂ.  Da, doar ca să explic, am crezut că asta este o parte importantă a asta.

Nu ca să arăt cu degetul spre SEC, dar acesta este ceva care nu pare să fi ieșit încă la spălat în multe sau în orice țări...

… dacă doar suferind un atac ransomware este inevitabil suficient pentru a fi o încălcare materială a datelor.

Acest document SEC nu menționează deloc „cuvântul R”.

Nu se menționează chestii specifice ransomware-ului.

Și ransomware-ul este o problemă, nu-i așa?

În articol, am vrut să precizez că cuvântul „ransomware”, pe care încă îl folosim pe scară largă, nu mai este chiar cuvântul potrivit, nu-i așa?

Probabil că ar trebui să-i spunem „software de șantaj” sau pur și simplu „extorcare cibernetică”.

Identific trei tipuri principale de atac ransomware.

Tipul A este locul în care escrocii nu vă fură datele, ci doar să vă amestece datele in situ.

Deci nu trebuie să încarce un singur lucru.

Ei amestecă totul într-un mod în care vă pot oferi cheia de decriptare, dar nu veți vedea un singur octet de date care părăsește rețeaua dvs. ca un semn indicator că ceva rău se întâmplă.

Apoi, există un atac ransomware de tip B, în care escrocii spun: „Știi ce, nu vom risca să scriem în toate fișierele, să fim prinși făcând asta. Pur și simplu vom fura toate datele și, în loc să plătim banii pentru a vă recupera datele, plătiți pentru tăcerea noastră.”

Și apoi, desigur, există atacul ransomware de tip C, și anume: „Atât A, cât și B”.

Acolo îți fură escrocii datele *și* le amestecă și spun: „Hei, dacă nu este un lucru care te va pune în probleme, este celălalt.”

Și ar fi bine să știm unde ceea ce cred că profesia de avocat numește materialitate (cu alte cuvinte, semnificația juridică sau relevanța juridică pentru o anumită reglementare)...

… unde intervine asta, în cazul atacurilor ransomware.

---

DOUG.  Ei bine, acesta este un moment bun pentru a aduce comentariul nostru al săptămânii, Adam, la această poveste.

Adam își spune gândurile despre diferitele tipuri de atacuri ransomware.

Deci, începând cu Tipul A, unde este doar un atac ransomware simplu, în care blochează fișierele și lasă o notă de răscumpărare pentru a le debloca...

Adam spune:

Dacă o companie este lovită de un ransomware, nu a găsit nicio dovadă de exfiltrare a datelor după o investigație amănunțită și și-a recuperat datele fără a plăti răscumpărarea, atunci aș fi înclinat să spun: „Nu [este necesară dezvăluirea]”.

---

RAȚĂ.  Ai făcut destule?

---

DOUG.  Da.

---

RAȚĂ.  Nu ați prevenit, dar ați făcut cel mai bun lucru, așa că nu trebuie să le spuneți investitorilor...

Ironia este, Doug, dacă ai fi făcut asta ca companie, ai putea dori să le spui investitorilor tăi: „Hei, ghici ce? Am avut un atac de ransomware ca toți ceilalți, dar am ieșit din el fără să plătim banii, fără să ne angajăm cu escrocii și fără să pierdem date. Deci, deși nu am fost perfecți, am fost următorul lucru cel mai bun.”

Și, de fapt, ar putea avea o mare greutate să dezvălui asta în mod voluntar, chiar dacă legea spunea că nu trebuie.

---

DOUG.  Și apoi, pentru Tipul B, unghiul șantajului, Adam spune:

Este o situație dificilă.

Teoretic, aș spune „Da”.

Dar asta va duce probabil la o mulțime de dezvăluiri și la deteriorarea reputației afacerilor.

Deci, dacă aveți o grămadă de companii care ies și spun: „Uite, am fost loviti de ransomware; nu credem că s-a întâmplat ceva rău; i-am plătit pe escroci să-i tăcem; și avem încredere că nu vor vărsa boabele”, ca să spunem așa…

… asta creează o situație dificilă, deoarece asta ar putea afecta reputația unei companii, dar dacă nu ar fi dezvăluit-o, nimeni nu ar ști.

---

RAȚĂ.  Și văd că Adam a simțit același lucru în care am simțit amândoi și eu în ceea ce privește afacerea: „Aveți patru zile și nu mai mult de patru zile... din momentul în care credeți că cele patru zile ar trebui să înceapă”.

A bubuit și asta, nu-i așa?

El a spus:

Unele companii vor adopta probabil tactici pentru a întârzia foarte mult să decidă dacă există un impact material.

Deci, nu prea știm cum se va desfășura asta și sunt sigur că nici SEC nu știe prea bine.

Poate fi nevoie de câteva cazuri de testare pentru ca ei să descopere care este cantitatea potrivită de birocrație pentru a se asigura că învățăm cu toții ceea ce trebuie să știm, fără a forța companiile să dezvăluie fiecare mică eroare IT care se întâmplă vreodată și să ne îngroape pe toți într-un încărcătură de hârtii.

Ceea ce duce în esență la oboseală încălcată, nu-i așa?

Dacă ai atât de multe vești proaste, care nu sunt foarte importante, doar să te răspund...

… cumva, este ușor să ratezi lucrurile cu adevărat importante care se află printre toate „trebuia să aud despre asta?”

Timpul va spune, Douglas.

---

DOUG.  Da, complicat!

Și știu că spun asta tot timpul, dar vom fi cu ochii pe asta, pentru că va fi fascinant să urmărești acest lucru.

Deci, mulțumesc, Adam, pentru că ai trimis acest comentariu.

---

RAȚĂ.  Da, întradevăr!

---

DOUG.  Dacă aveți o poveste, un comentariu sau o întrebare interesantă pe care doriți să o trimiteți, ne-ar plăcea să o citim pe podcast.

Puteți trimite un e-mail la tips@sophos.com, puteți comenta oricare dintre articolele noastre sau ne puteți contacta pe social: @nakedsecurity.

Acesta este spectacolul nostru de astăzi; multumesc mult pentru ascultare.

Pentru Paul Ducklin, sunt Doug Aamoth și vă reamintesc până data viitoare să...

---

AMBII.  Rămâi în siguranță.

[MODEM MUZICAL]