S3 Ep146: Fortæl os om det brud! (Hvis du vil.)

Ingen lydafspiller nedenfor? Hør efter direkte på Soundcloud.

---

DOUG.  Firefox-opdateringer, en anden Bug med et imponerende navn, og SEC kræver offentliggørelse.

Alt det, og mere, på Naked Security-podcasten.

[MUSIK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug Aamoth; han er Paul Ducklin.

Paul, jeg håber, du vil være stolt af mig... jeg ved, du er en cykelentusiast.

Jeg kørte på cykel i går 10 amerikanske miles, hvilket jeg tror er omkring 16 km, alt imens jeg trak et lille, men ikke uheldigt barn bag cyklen i en tohjulet vogn.

Og jeg er stadig i live for at fortælle historien.

Er det lang vej at cykle, Paul?

---

AND.  Det kommer an på, hvor langt du virkelig skulle gå.

Som, hvis det faktisk var 1200 meter, du skulle gå, og du gik vild... [LATER]

Min entusiasme for at cykle er meget stor, men det betyder ikke, at jeg bevidst kører længere, end jeg skal, for det er min primære måde at komme rundt på.

Men 10 km er OK.

Vidste du, at amerikanske miles og britiske miles i virkeligheden er identiske?

---

DOUG.  Det er godt at vide!

---

AND.  Og har været det siden 1959, hvor en flok lande inklusive, tror jeg, Canada, Sydafrika, Australien, USA og Storbritannien fandt sammen og blev enige om at standardisere på en "international tomme".

Jeg tror, ​​at den kejserlige tomme blev meget, meget lidt mindre, og den amerikanske tomme blev meget, meget lidt længere, med det resultat, at tommen (og derfor gården, og foden og milen)...

…de er alle defineret i forhold til meter.

En tomme er præcis 25.4 mm

Tre væsentlige tal er alt hvad du behøver.

---

DOUG.  Spændende!

Nå, apropos fascinerende, så er det tid til vores Denne uge i teknisk historie segment.

Denne uge, den 01. august 1981, gik Music Television, også kendt som MTV, live som en del af amerikanske kabel- og satellit-tv-pakker og introducerede offentligheden for musikvideoer.

Den første spillede [SINGS, RETTHER WELL IN FACT] "Video Killed the Radio Star" af The Buggles.

Passende på det tidspunkt, selvom det er ironisk nu om dage, da MTV sjældent afspiller musikvideoer mere og ikke spiller nogen som helst nye musikvideoer, Paul.

---

AND.  Ja, det er ironisk, er det ikke, at kabel-tv (med andre ord, hvor du havde ledninger, der løber under jorden ind i dit hus) dræbte radio- (eller den trådløse) stjerne, og nu ser det ud som om kabel-tv, MTV … den slags døde ud, fordi alle har mobilnetværk, der fungerer trådløst.

Det, der foregår, kommer rundt, Douglas.

---

DOUG.  Okay, lad os tale om disse Firefox-opdateringer.

Vi får en dobbelt dosis af Firefox-opdateringer denne måned, fordi de er på en 28-dages cyklus:

Firefox retter en byge af fejl i den første af to udgivelser i denne måned

Ingen nul-dage i denne første runde ud af porten, men nogle lærerige øjeblikke.

Vi har angivet måske halvdelen af ​​disse i din artikel, og en der virkelig skilte sig ud for mig var: Potentielle tilladelser anmoder om omgåelse via clickjacking.

---

AND.  Ja, gode gamle clickjacking igen.

Jeg kan godt lide det udtryk, fordi det stort set beskriver, hvad det er.

Du klikker et sted, og tror, ​​du klikker på en knap eller et uskyldigt link, men du tillader uforvarende, at der sker noget, som ikke er indlysende ud fra, hvad skærmen viser under din musemarkør.

Problemet her ser ud til at være, at under nogle omstændigheder, når en tilladelsesdialog var ved at dukke op fra Firefox, for eksempel, sig: "Er du virkelig sikker på, at du vil lade denne hjemmeside bruge dit kamera? har du adgang til din placering? bruge din mikrofon?”...

… alle de ting, som, ja, du gerne vil blive spurgt om.

Tilsyneladende, hvis du kunne få browseren til et præstationspunkt (igen, ydeevne versus sikkerhed), hvor den kæmpede for at følge med, kunne du forsinke fremkomsten af ​​tilladelses-pop-op-vinduet.

Men ved at have en knap på det sted, hvor pop op-vinduet ville dukke op, og lokke brugeren til at klikke på den, kunne du tiltrække klikket, men klikket ville så blive sendt til tilladelsesdialogen, som du ikke helt havde set endnu.

En slags visuel racetilstand, hvis du vil.

---

DOUG.  OK, og den anden var: Kanvas uden for skærmen kunne have omgået restriktioner på tværs af oprindelse.

Du fortsætter med at sige, at en webside kunne kigge på billeder, der vises på en anden side fra et andet websted.

---

AND.  Det skal ikke ske, vel?

---

DOUG.  Nej!

---

AND.  Fagsproget for det er "same-origin policy".

Hvis du kører website X, og du sender mig en hel masse JavaScript, der sætter en hel belastning af cookies, så er alt det gemt i browseren.

Men kun yderligere JavaScript fra site X kan læse disse data tilbage.

Det faktum, at du browser til site X i den ene fane og site Y på den anden fane, lader dem ikke kigge på, hvad den anden laver, og browseren formodes at holde alle disse ting adskilt.

Det er åbenbart ret vigtigt.

Og her ser det ud til, at så vidt jeg forstår det, hvis du gengiver en side, der ikke blev vist endnu...

…et lærred uden for skærmen, det er der, du opretter, hvis du vil, en virtuel webside, og så på et eller andet tidspunkt siger du: "Lige nu er jeg klar til at vise den," og bingo, siden vises kl. enkelt gang.

Problemet kommer med at forsøge at sikre, at de ting, du renderer usynligt, ikke utilsigtet lækker data, selvom det aldrig i sidste ende bliver vist for brugeren.

De opdagede det, eller det blev ansvarligt afsløret, og det blev rettet.

Og de to, tror jeg, var inkluderet i de såkaldte "højt"-niveau sårbarheder.

De fleste af de andre var "Moderate", med undtagelse af Mozillas traditionelle, "Vi fandt en hel masse fejl gennem fuzzing og gennem automatiserede teknikker; vi undersøgte dem ikke for at finde ud af, om de overhovedet kunne udnyttes, men vi er villige til at antage, at nogen, der prøvede hårdt nok, kunne gøre det."

Det er en indrømmelse, som vi begge holder så meget af, Doug ... fordi potentielle fejl er værd at afskaffe, selvom du føler dig sikker i dit hjerte på, at ingen nogensinde vil finde ud af at udnytte dem.

For i cybersikkerhed betaler det sig aldrig at sige aldrig!

---

DOUG.  Okay, du leder efter Firefox 116, eller hvis du er på en udvidet udgivelse, 115.1.

Det samme med Thunderbird.

Og lad os gå videre til... åh, mand!

Paul, det er spændende!

Vi har en ny BWAIN efter en dobbelt-BWAIN i sidste uge: en fejl med et imponerende navn.

Denne hedder Collide+Power:

Ydeevne og sikkerhed støder igen sammen i "Collide+Power"-angreb

---

AND.  Ja, det er spændende, er det ikke, at de har valgt et navn, der har et plustegn?

---

DOUG.  Ja, det gør det svært at sige.

---

AND.  Du kan ikke have et plustegn i dit domænenavn, så domænenavnet er det collidepower.com.

---

DOUG.  Okay, lad mig læse fra forskerne selv, og jeg citerer:

Roden til problemet er, at delte CPU-komponenter, som det interne hukommelsessystem, kombinerer hackerdata og data fra enhver anden applikation, hvilket resulterer i et kombineret lækagesignal i strømforbruget.

Ved at kende sine egne data kan angriberen således bestemme de nøjagtige dataværdier, der bruges i andre applikationer.

---

AND.  Ja, det giver meget mening, hvis du allerede ved, hvad de taler om!

For at prøve at forklare dette på almindeligt engelsk (håber jeg har forstået det korrekt)...

Dette går ned til de præstation-versus-sikkerhedsproblemer, som vi har talt om før, herunder sidste uges podcast med det Zenbleed fejl (som i øvrigt er langt mere alvorlig):

Zenbleed: Hvordan søgen efter CPU-ydeevne kan bringe dine adgangskoder i fare

Der er en hel belastning af data, der bliver opbevaret inde i CPU'en ("cachelagret" er den tekniske betegnelse for det), så CPU'en ikke behøver at gå og hente det senere.

Så der er en hel masse interne ting, som du ikke rigtig får styr på; CPU'en passer på det for dig.

Og hjertet af dette angreb ser ud til at gå nogenlunde sådan her…

Hvad angriberen gør er at få adgang til forskellige hukommelsesplaceringer på en sådan måde, at den interne cache-lagring husker disse hukommelsesplaceringer, så den ikke behøver at gå og læse dem ud af RAM igen, hvis de bliver genbrugt hurtigt.

Så angriberen får på en eller anden måde disse cacheværdier fyldt med kendte mønstre af bits, kendte dataværdier.

Og så, hvis offeret har hukommelse, som *de* bruger ofte (f.eks. bytes i en dekrypteringsnøgle), hvis deres værdi pludselig vurderes af CPU'en til at være mere tilbøjelig til at blive genbrugt end en af ​​angriberens værdier, det sparker angriberens værdi ud af den interne superhurtige cache-placering og sætter den nye værdi, offerets værdi, derind.

Og hvad disse forskere opdagede (og så vidt angrebet lyder i teorien og er i praksis, det er en ganske fantastisk ting at opdage)...

Antallet af bit, der er forskelligt mellem den gamle værdi i cachen og den nye værdi *ændrer mængden af ​​strøm, der kræves for at udføre cacheopdateringsoperationen*.

Hvis du derfor kan måle CPU'ens strømforbrug præcist nok, kan du drage slutninger om, hvilke dataværdier der blev skrevet ind i den interne, skjulte, ellers usynlige cachehukommelse inde i CPU'en, som CPU'en troede ikke var din sag.

Ganske spændende, Doug!

---

DOUG.  Fremragende.

OK, der er nogle begrænsninger.

Den sektion starter: "Først og fremmest behøver du ikke bekymre dig," men også næsten alle CPU'er er berørt.

---

AND.  Ja, det er interessant, ikke?

Der står "først og fremmest" (normal tekst) "dig" (i kursiv) "behøver ikke bekymre dig" (med fed skrift). [griner]

Så dybest set er der ingen, der vil angribe dig med dette, men måske vil CPU-designerne tænke over dette i fremtiden, hvis der er nogen vej udenom. [griner]

Jeg syntes, det var en interessant måde at udtrykke det på.

---

DOUG.  OK, så afhjælpningen er dybest set at slå hyperthreading fra.

Er det sådan, det fungerer?

---

AND.  Hyperthreading gør dette meget værre, så vidt jeg kan se.

Vi ved allerede, at hyperthreading er et sikkerhedsproblem, fordi der før har været adskillige sårbarheder, der afhænger af det.

Det er her en CPU, f.eks. med otte kerner, foregiver at have 16 kerner, men faktisk er de ikke i separate dele af chippen.

De er faktisk par af slags pseudo-kerner, der deler mere elektronik, flere transistorer, flere kondensatorer, end det måske er en god idé af sikkerhedsmæssige årsager.

Hvis du kører den gode gamle OpenBSD, tror jeg, at de besluttede, at hyperthreading bare er for svært at sikre med begrænsninger; kan lige så godt bare slå den fra.

På det tidspunkt, hvor du har fået de præstationshits, som begrænsningerne kræver, kan du lige så godt bare ikke have det.

Så det tror jeg slå hyperthreading fra vil i høj grad immunisere dig mod dette angreb.

Den anden ting du kan gøre er, som forfatterne siger med fed skrift: Vær ikke urolig. [LATTER]

---

DOUG.  Det er en stor afbødning! [griner]

---

AND.   Der er en god smule (jeg bliver nødt til at læse dette op, Doug)...

Der er en stor del, hvor forskerne selv fandt ud af, at for overhovedet at få nogen form for pålidelig information, fik de datahastigheder på et sted mellem 10 bits og 100 bits i timen ud af systemet.

Jeg tror, ​​at i det mindste Intel-CPU'er har en afbødning, som jeg forestiller mig ville hjælpe mod dette.

Og dette bringer os tilbage til MSR'er, de modelspecifikke registre, som vi talte om i sidste uge med Zenbleed, hvor der var en magisk smule, som du kunne tænde for, der sagde: "Lad være med at gøre de risikable ting."

Der er en funktion, du kan indstille kaldet RAPL-filtrering, og RAPL er en forkortelse for kørende gennemsnitseffektgrænse.

Det bruges af programmer, der ønsker at se, hvordan en CPU klarer sig til strømstyringsformål, så du ikke behøver at bryde ind i serverrummet og sætte en strømmonitor på en ledning med en lille sonde på bundkortet. [griner]

Du kan faktisk få CPU'en til at fortælle dig, hvor meget strøm den bruger.

Intel har i det mindste denne tilstand kaldet RAPL-filtrering, som bevidst introducerer jitter eller fejl.

Så du får resultater, der i gennemsnit er nøjagtige, men hvor hver enkelt læsning vil være slukket.

---

DOUG.  Lad os nu vende vores opmærksomhed mod denne nye SEC-aftale.

Sikkerheds- og udvekslingskommissionen kræver fire dages afsløringsgrænser for brud på cybersikkerhed:

SEC kræver fire dages oplysningsgrænse for cybersikkerhedsbrud

Men (A) du bestemmer, om et angreb er alvorligt nok til at rapportere, og (B) grænsen på fire dage starter ikke, før du beslutter, at noget er vigtigt nok at rapportere, Paul.

Så en god første start, men måske ikke så aggressiv, som vi gerne ville?

---

AND.  Jeg er enig i din vurdering, Doug.

Det lød godt, da jeg først så på det: "Hey, du har denne fire-dages afsløring, hvis du har et databrud eller et cybersikkerhedsproblem."

Men så var der lidt om, "Jamen, det må betragtes som et materielt problem," et juridisk udtryk, der betyder, at det faktisk betyder nok til at være værd at afsløre i første omgang.

Og så kom jeg til den del (og det er ikke en særlig lang pressemeddelelse fra SEC), der på en måde sagde: "Så snart du har besluttet, at du virkelig burde rapportere dette, så har du stadig fire dage at anmelde det."

Nu forestiller jeg mig, at det juridisk set ikke er helt sådan, det vil fungere. Doug

Måske er vi lidt hårde i artiklen?

---

DOUG.  Du zoomer ind på ransomware-angreb og siger, at der er et par forskellige typer, så lad os tale om det... det er vigtigt for at afgøre, om dette er et materielt angreb, som du skal rapportere.

Så hvilken slags ransomware kigger vi på?

---

AND.  Ja, bare for at forklare, jeg troede, at det var en vigtig del af det her.

Ikke for at pege fingre af SEC, men dette er noget, der ikke ser ud til at være kommet ud i vask i mange eller nogen lande endnu...

...om blot det at lide et ransomware-angreb er uundgåeligt nok til at være et væsentligt databrud.

Dette SEC-dokument nævner faktisk slet ikke "R-ordet".

Der er ingen omtale af ransomware-specifikke ting.

Og ransomware er et problem, er det ikke?

I artiklen ville jeg gøre det klart, at ordet "ransomware", som vi stadig bruger meget, ikke er det helt rigtige ord længere, vel?

Vi skal nok kalde det "blackmailware" eller blot "cyberafpresning".

Jeg identificerer tre hovedtyper af ransomware-angreb.

Type A er, hvor skurkene ikke stjæler dine data, de kommer bare til at kryptere dine data in situ.

Så de behøver ikke at uploade en eneste ting.

De forvrider det hele på en måde, så de kan give dig dekrypteringsnøglen, men du vil ikke se en eneste byte af data, der forlader dit netværk, som et tegn på, at noget slemt er i gang.

Så er der et Type B ransomware-angreb, hvor skurkene siger: "Ved du hvad, vi vil ikke risikere at skrive til alle filerne og blive fanget i at gøre det. Vi kommer bare til at stjæle al data, og i stedet for at betale pengene for at få dine data tilbage, betaler du for vores tavshed.”

Og så er der selvfølgelig Type C ransomware-angrebet, og det er: "Både A og B."

Det er der, skurkene stjæler dine data *og* de forvrider dem, og de siger: "Hey, hvis det ikke er den ene ting, der får dig i problemer, så er det den anden."

Og det ville være rart at vide, hvor det, jeg mener, advokatbranchen kalder væsentlighed (med andre ord den juridiske betydning eller den juridiske relevans for en bestemt regulering)...

…hvor det slår ind, i tilfælde af ransomware-angreb.

---

DOUG.  Nå, det er et godt tidspunkt at bringe vores Ugens kommentator, Adam, ind på denne historie.

Adam giver sine tanker om de forskellige typer af ransomware-angreb.

Så startende med Type A, hvor det bare er et ligetil ransomware-angreb, hvor de låser filerne og efterlader en løsesumseddel for at få dem låst op...

Adam siger:

Hvis en virksomhed bliver ramt af ransomware, fandt intet bevis for dataeksfiltrering efter en grundig undersøgelse og genfandt deres data uden at betale løsesummen, så ville jeg være tilbøjelig til at sige: "Ingen [oplysning nødvendig]."

---

AND.  Har du gjort nok?

---

DOUG.  Ja.

---

AND.  Du forhindrede det ikke helt, men du gjorde det næstbedste, så du behøver ikke fortælle det til dine investorer...

Det ironiske er, Doug, hvis du havde gjort det som virksomhed, ville du måske fortælle dine investorer: "Hey, gæt hvad? Vi havde et ransomware-angreb som alle andre, men vi kom ud af det uden at betale pengene, uden at engagere os i skurkene og uden at miste nogen data. Så selvom vi ikke var perfekte, var vi de næstbedste.”

Og det kan faktisk veje tungt at afsløre det frivilligt, selvom loven sagde, at du ikke behøvede det.

---

DOUG.  Og så, for Type B, afpresningsvinklen, siger Adam:

Det er en vanskelig situation.

Teoretisk ville jeg sige "Ja."

Men det vil sandsynligvis føre til en masse afsløringer og skadet forretningsomdømme.

Så hvis du har en flok virksomheder, der kommer ud og siger: "Se, vi blev ramt af ransomware; vi tror ikke, der er sket noget slemt; vi betalte skurkene for at holde dem stille; og vi stoler på, at de ikke kommer til at spilde bønnerne," så at sige...

…det skaber en vanskelig situation, fordi det kan skade en virksomheds omdømme, men havde de ikke afsløret det, ville ingen vide det.

---

AND.  Og jeg kan se, at Adam havde det på samme måde, som både du og jeg gjorde med hensyn til: "Du har fire dage, og ikke mere end fire dage... fra det øjeblik, du tror, ​​de fire dage skulle begynde."

Det buldrede han også, gjorde han ikke?

Han sagde:

Nogle virksomheder vil sandsynligvis vedtage taktikker for i høj grad at forsinke beslutningen om, hvorvidt der er en væsentlig indvirkning.

Så vi ved ikke helt, hvordan det vil forløbe, og jeg er sikker på, at SEC heller ikke helt ved det.

Det kan tage et par testsager for dem at finde ud af, hvad der er den rigtige mængde bureaukrati for at sikre, at vi alle lærer det, vi har brug for at vide, uden at tvinge virksomheder til at afsløre hver eneste lille it-fejl, der nogensinde sker, og begrave os alle i en belastning af papirarbejde.

Hvilket i det væsentlige fører til brudtræthed, ikke?

Hvis du har så mange dårlige nyheder, som ikke er særlig vigtige, skyller du bare over dig...

…på en eller anden måde er det nemt at gå glip af de virkelig vigtige ting, der er i blandt alt det "behøvede jeg virkelig at høre om det?"

Det må tiden vise, Douglas.

---

DOUG.  Ja, tricky!

Og jeg ved, at jeg siger det hele tiden, men vi vil holde øje med det her, for det bliver fascinerende at se det udvikle sig.

Så tak, Adam, for at sende den kommentar.

---

AND.  Ja bestemt!

---

DOUG.  Hvis du har en interessant historie, kommentar eller spørgsmål, du gerne vil indsende, vil vi meget gerne læse på podcasten.

Du kan sende en e-mail til tips@sophos.com, du kan kommentere på en af ​​vores artikler, eller du kan kontakte os på socialt: @nakedsecurity.

Det er vores show for i dag; mange tak fordi du lyttede.

For Paul Ducklin er jeg Doug Aamoth, og minder dig om, indtil næste gang...

---

BEGGE.  Bliv sikker.

[MUSIK MODEM]