S3 Ep146: Fortell oss om det bruddet! (Hvis du vil.)

Ingen lydspiller under? Lytte direkte på Soundcloud.

---

DOUG.  Firefox-oppdateringer, en annen Feil med et imponerende navn, og SEC krever avsløring.

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

[MUSIKK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug Aamoth; han er Paul Ducklin.

Paul, jeg håper du vil være stolt av meg... jeg vet at du er en sykkelentusiast.

Jeg syklet i går 10 amerikanske miles, som jeg tror er omtrent 16 km, alt mens jeg dro et lite, men ikke tungt barn bak sykkelen i en tohjulsvogn.

Og jeg er fortsatt i live for å fortelle historien.

Er det lang vei å sykle, Paul?

---

AND.  [LAUGGER] Det kommer an på hvor langt du egentlig trengte å gå.

Som, hvis det faktisk var 1200 meter du måtte gå og du gikk deg vill … [LATER]

Entusiasmen min for sykling er veldig høy, men det betyr ikke at jeg bevisst sykler lenger enn jeg trenger, for det er min primære måte å komme meg rundt på.

Men 10 mil er OK.

Visste du at amerikanske miles og britiske miles faktisk er identiske?

---

DOUG.  Det er fint å vite!

---

AND.  Og har vært det siden 1959, da en haug med land, inkludert, tror jeg, Canada, Sør-Afrika, Australia, USA og Storbritannia kom sammen og ble enige om å standardisere på en "internasjonal tomme".

Jeg tror den keiserlige tommen ble veldig, veldig litt mindre og den amerikanske tommen ble veldig, veldig litt lengre, med det resultat at tommen (og derfor gården, og foten og milen)...

…de er alle definert i form av meter.

En tomme er nøyaktig 25.4 mm

Tre betydelige tall er alt du trenger.

---

DOUG.  Fascinerende!

Vel, apropos fascinerende, det er på tide for oss Denne uken i teknisk historie segment.

Denne uken, 01. august 1981, gikk Music Television, også kjent som MTV, live som en del av amerikanske kabel- og satellitt-TV-pakker, og introduserte publikum for musikkvideoer.

Den første spilte [SINGS, RETTHER WELL IN FACT] «Video Killed the Radio Star» av The Buggles.

Passende på den tiden, selv om det er ironisk nå for tiden da MTV sjelden spiller musikkvideoer lenger, og spiller ingen nye musikkvideoer overhodet, Paul.

---

AND.  Ja, det er ironisk, er det ikke, at kabel-TV (med andre ord, der du hadde ledninger som gikk under bakken inn i huset ditt) drepte radiostjernen (eller den trådløse) og nå ser det ut som om kabel-TV, MTV … den slags døde ut fordi alle har mobilnettverk som fungerer trådløst.

Det som skjer rundt kommer rundt, Douglas.

---

DOUG.  Ok, vel, la oss snakke om disse Firefox-oppdateringene.

Vi får en dobbel dose Firefox-oppdateringer denne måneden, fordi de er på en 28-dagers syklus:

Firefox fikser en rekke feil i den første av to utgivelser denne måneden

Ingen null-dager i denne første runden ut av porten, men noen lærerike øyeblikk.

Vi har listet opp kanskje halvparten av disse i artikkelen din, og en som virkelig skilte seg ut for meg var: Potensielle tillatelser ber om omgåelse via clickjacking.

---

AND.  Ja, gode gamle clickjacking igjen.

Jeg liker det begrepet fordi det ganske mye beskriver hva det er.

Du klikker et sted, og tror du klikker på en knapp eller en uskyldig lenke, men du tillater utilsiktet at noe skal skje som ikke er åpenbart fra det skjermen viser under musepekeren.

Problemet her ser ut til å være at under noen omstendigheter, når en tillatelsesdialog var i ferd med å dukke opp fra Firefox, for eksempel, si: "Er du virkelig sikker på at du vil la denne nettsiden bruke kameraet ditt? har du tilgang til posisjonen din? bruke mikrofonen din?"...

…alle de tingene som, ja, du ønsker å bli spurt om.

Tilsynelatende, hvis du kunne få nettleseren til et ytelsespunkt (igjen, ytelse versus sikkerhet) der den slet med å holde tritt, kan du forsinke utseendet til popup-vinduet for tillatelser.

Men ved å ha en knapp på stedet der popup-vinduet dukker opp, og lokke brukeren til å klikke på den, kan du tiltrekke deg klikket, men klikket vil da bli sendt til tillatelsesdialogen som du ikke helt hadde sett ennå.

En slags visuell rasetilstand, hvis du vil.

---

DOUG.  OK, og den andre var: Lerret utenfor skjermen kunne ha omgått restriksjoner for kryssopprinnelse.

Du fortsetter med å si at en nettside kan se på bilder som vises på en annen side fra et annet nettsted.

---

AND.  Det skal vel ikke skje?

---

DOUG.  Nei!

---

AND.  Sjargongbetegnelsen for det er «politikken med samme opprinnelse».

Hvis du kjører nettstedet X og du sender meg en hel haug med JavaScript som setter en hel mengde informasjonskapsler, så lagres alt dette i nettleseren.

Men bare ytterligere JavaScript fra side X kan lese disse dataene tilbake.

Det faktum at du surfer til side X i den ene fanen og side Y i den andre fanen lar dem ikke se på hva den andre gjør, og nettleseren er ment å holde alt dette fra hverandre.

Det er åpenbart ganske viktig.

Og her ser det ut til at, så vidt jeg forstår det, hvis du gjengir en side som ikke ble vist ennå...

…et lerret utenfor skjermen, som er der du oppretter, hvis du vil, en virtuell nettside, og på et eller annet tidspunkt sier du: "Akkurat nå er jeg klar til å vise den," og bingo, siden vises kl. en gang.

Problemet kommer med å prøve å sørge for at tingene du gjengir usynlig ikke utilsiktet lekker data, selv om de til slutt aldri blir vist til brukeren.

De oppdaget det, eller det ble avslørt på en ansvarlig måte, og det ble lappet.

Og disse to, tror jeg, var inkludert i de såkalte "høyt"-nivåsårbarhetene.

De fleste av de andre var "Moderate", med unntak av Mozillas tradisjonelle, "Vi fant en hel masse feil gjennom fuzzing og gjennom automatiserte teknikker; vi undersøkte dem ikke for å finne ut om de kunne utnyttes i det hele tatt, men vi er villige til å anta at noen som prøvde hardt nok kunne gjøre det.»

Det er en innrømmelse som vi begge liker så godt, Doug ... fordi potensielle feil er verdt å stoppe, selv om du føler deg sikker på at ingen noensinne vil finne ut hvordan du kan utnytte dem.

For i cybersikkerhet lønner det seg aldri å si aldri!

---

DOUG.  Greit, du ser etter Firefox 116, eller hvis du har en utvidet utgivelse, 115.1.

Samme med Thunderbird.

Og la oss gå videre til... å, mann!

Paul, dette er spennende!

Vi har en ny BWAIN etter en dobbel BWAIN forrige uke: en feil med et imponerende navn.

Denne heter Kollider + Strøm:

Ytelse og sikkerhet kolliderer igjen i «Collide+Power»-angrepet

---

AND.  [LAUGGER] Ja, det er spennende, er det ikke, at de valgte et navn som har et plusstegn?

---

DOUG.  Ja, det gjør det vanskelig å si.

---

AND.  Du kan ikke ha et plusstegn i domenenavnet ditt, så domenenavnet er det collidepower.com.

---

DOUG.  Ok, la meg lese fra forskerne selv, og jeg siterer:

Roten til problemet er at delte CPU-komponenter, som det interne minnesystemet, kombinerer angriperdata og data fra en hvilken som helst annen applikasjon, noe som resulterer i et kombinert lekkasjesignal i strømforbruket.

Ved å kjenne sine egne data kan angriperen derfor bestemme de eksakte dataverdiene som brukes i andre applikasjoner.

---

AND.  [LETER] Ja, det gir mye mening hvis du allerede vet hva de snakker om!

For å prøve å forklare dette på vanlig engelsk (håper jeg har forstått dette riktig)...

Dette går ned til ytelse-versus-sikkerhetsproblemene som vi har snakket om før, inkludert forrige ukes podcast med det Zenbleed feil (som er langt mer alvorlig, forresten):

Zenbleed: Hvordan søken etter CPU-ytelse kan sette passordene dine i fare

Det er en hel mengde data som blir holdt inne i CPUen («bufret» er den tekniske betegnelsen for det), slik at CPUen ikke trenger å gå og hente den senere.

Så det er en hel masse interne ting som du egentlig ikke får styr på; CPUen passer på den for deg.

Og hjertet av dette angrepet ser ut til å gå noe sånt som dette...

Det angriperen gjør er å få tilgang til forskjellige minneplasseringer på en slik måte at den interne cache-lagringen husker disse minneplasseringene, slik at den ikke trenger å gå og lese dem ut av RAM igjen hvis de raskt blir gjenbrukt.

Så angriperen får på en eller annen måte disse cache-verdiene fylt med kjente mønstre av biter, kjente dataverdier.

Og så, hvis offeret har minne som *de* bruker ofte (for eksempel bytene i en dekrypteringsnøkkel), hvis verdien deres plutselig vurderes av CPU-en til å være mer sannsynlig å bli gjenbrukt enn en av angripernes verdier, det sparker angriperens verdi ut av den interne superraske cache-plasseringen, og legger den nye verdien, offerets verdi, inn der.

Og det disse forskerne oppdaget (og så langt angrepet som i teorien høres ut og er i praksis, dette er en ganske utrolig ting å oppdage)...

Antall biter som er forskjellig mellom den gamle verdien i hurtigbufferen og den nye verdien *endrer mengden kraft som kreves for å utføre hurtigbufferoppdateringsoperasjonen*.

Derfor, hvis du kan måle strømforbruket til CPU-en nøyaktig nok, kan du trekke slutninger om hvilke dataverdier som ble skrevet inn i det interne, skjulte, ellers usynlige cache-minnet inne i CPU-en som CPU-en trodde ikke var din sak.

Ganske spennende, Doug!

---

DOUG.  Fremragende.

OK, det er noen begrensninger.

Den delen starter: "Først av alt, du trenger ikke å bekymre deg," men også nesten alle CPUer er berørt.

---

AND.  Ja, det er interessant, ikke sant?

Det står "først og fremst" (normal tekst) "du" (i kursiv) "trenger ikke å bekymre deg” (med fet skrift). [LETER]

Så i utgangspunktet er det ingen som kommer til å angripe deg med dette, men kanskje CPU-designerne ønsker å tenke på dette i fremtiden hvis det er noen vei rundt det. [LETER]

Jeg syntes det var en interessant måte å si det på.

---

DOUG.  OK, så begrensningen er i utgangspunktet å slå av hyperthreading.

Er det slik det fungerer?

---

AND.  Hyperthreading gjør dette mye verre, så vidt jeg kan se.

Vi vet allerede at hyperthreading er et sikkerhetsproblem fordi det har vært mange sårbarheter som er avhengige av det før.

Det er der en CPU, for eksempel, med åtte kjerner, later til å ha 16 kjerner, men faktisk er de ikke i separate deler av brikken.

De er faktisk par av slags pseudokjerner som deler mer elektronikk, flere transistorer, flere kondensatorer enn det som kanskje er en god idé av sikkerhetsgrunner.

Hvis du kjører gode gamle OpenBSD, tror jeg de bestemte at hyperthreading bare er for vanskelig å sikre med begrensninger; kan like gjerne bare slå den av.

Innen du har fått ytelsestreffene som reduksjonene krever, kan du like gjerne bare ikke ha det.

Så det tror jeg slå av hyperthreading vil i stor grad immunisere deg mot dette angrepet.

Den andre tingen du kan gjøre er, som forfatterne sier med fet skrift: ikke bekymre deg. [LATTER]

---

DOUG.  Det er en stor avbøtende! [LETER]

---

AND.   Det er en god del (jeg må lese dette opp, Doug)...

Det er en stor del der forskerne selv fant ut at for å få noen form for pålitelig informasjon i det hele tatt, fikk de datahastigheter på et sted mellom 10 biter og 100 biter per time ut av systemet.

Jeg tror at i det minste Intel CPUer har en avbøtende effekt som jeg tror vil hjelpe mot dette.

Og dette bringer oss tilbake til MSRs, de modellspesifikke registrene som vi snakket om forrige uke med Zenbleed, hvor det var en magisk bit du kunne slå på som sa: "Ikke gjør de risikable tingene."

Det er en funksjon du kan angi kalt RAPL-filtrering, og RAPL er en forkortelse for løpende gjennomsnittlig effektgrense.

Den brukes av programmer som ønsker å se hvordan en CPU presterer for strømstyringsformål, slik at du ikke trenger å bryte deg inn i serverrommet og sette en strømmonitor på en ledning med en liten sonde på hovedkortet. [LETER]

Du kan faktisk få CPUen til å fortelle deg hvor mye strøm den bruker.

Intel har i det minste denne modusen kalt RAPL-filtrering, som bevisst introduserer jitter eller feil.

Så du vil få resultater som i gjennomsnitt er nøyaktige, men hvor hver enkelt lesing vil være av.

---

DOUG.  La oss nå rette oppmerksomheten mot denne nye SEC-avtalen.

Security and Exchange Commission krever fire dagers avsløringsgrenser for brudd på nettsikkerhet:

SEC krever fire dagers avsløringsgrense for brudd på nettsikkerhet

Men (A) du får bestemme om et angrep er alvorlig nok til å rapportere, og (B) firedagersgrensen starter ikke før du bestemmer deg for at noe er viktig nok å rapportere, Paul.

Så, en god første start, men kanskje ikke så aggressiv som vi ønsker?

---

AND.  Jeg er enig i vurderingen din, Doug.

Det hørtes bra ut da jeg først så på det: "Hei, du har denne fire-dagers avsløringen hvis du har et datainnbrudd eller et cybersikkerhetsproblem."

Men så var det denne biten om "Vel, det må betraktes som et materiell problem," et juridisk begrep som betyr at det faktisk betyr nok til å være verdt å avsløre i utgangspunktet.

Og så kom jeg til den biten (og det er ikke en veldig lang pressemelding fra SEC) som på en måte sa: "Så snart du har bestemt deg for at du virkelig burde rapportere dette, så har du fortsatt fire dager å rapportere det."

Nå ser jeg for meg at det juridisk sett ikke er helt slik det vil fungere. Doug

Kanskje vi er litt harde i artikkelen?

---

DOUG.  Du zoomer inn på løsepengevare-angrep, og sier at det finnes noen forskjellige typer, så la oss snakke om det... det er viktig for å avgjøre om dette er et vesentlig angrep som du må rapportere.

Så hva slags løsepengevare ser vi på?

---

AND.  Ja, bare for å forklare, jeg trodde det var en viktig del av dette.

Ikke for å peke fingre på SEC, men dette er noe som ikke ser ut til å ha kommet ut i vask i mange eller noen land ennå...

...om bare å lide et løsepenge-angrep er uunngåelig nok til å være et vesentlig datainnbrudd.

Dette SEC-dokumentet nevner faktisk ikke "R-ordet" i det hele tatt.

Det er ingen omtale av løsepengevarespesifikke ting.

Og løsepengevare er et problem, er det ikke?

I artikkelen ønsket jeg å gjøre det klart at ordet «ransomware», som vi fortsatt bruker mye, ikke er det rette ordet lenger, er det?

Vi burde nok kalle det "utpressing" eller bare "cyberextortion".

Jeg identifiserer tre hovedtyper ransomware-angrep.

Type A er der skurkene ikke stjeler dataene dine, de kan bare kryptere dataene dine på stedet.

Så de trenger ikke å laste opp en eneste ting.

De krypterer alt på en måte at de kan gi deg dekrypteringsnøkkelen, men du vil ikke se en eneste byte med data som forlater nettverket ditt som et avslørende tegn på at noe dårlig er på gang.

Så er det et type B løsepenge-angrep, hvor skurkene sier: «Vet du hva, vi kommer ikke til å risikere å skrive til alle filene og bli tatt for å gjøre det. Vi kommer bare til å stjele alle dataene, og i stedet for å betale pengene for å få tilbake dataene dine, betaler du for stillheten vår.»

Og så er det selvfølgelig type C løsepengevareangrepet, og det er: "Både A og B."

Det er der skurkene stjeler dataene dine *og* de krypterer dem og de sier: «Hei, hvis det ikke er den ene tingen som vil få deg i trøbbel, så er det den andre.»

Og det ville være fint å vite hvor det jeg tror advokatstanden kaller vesentlighet (med andre ord den juridiske betydningen eller den juridiske relevansen for en bestemt forskrift)...

…hvor det slår inn, i tilfelle løsepengevareangrep.

---

DOUG.  Vel, dette er et godt tidspunkt å bringe inn ukens kommentator, Adam, på denne historien.

Adam gir sine tanker om de ulike typene løsepengevareangrep.

Så starter med Type A, hvor det bare er et enkelt løsepenge-angrep, hvor de låser opp filene og legger igjen en løsepengelapp for å få dem låst opp...

Adam sier:

Hvis et selskap blir rammet av løsepenger, fant ingen bevis for dataeksfiltrering etter en grundig undersøkelse, og gjenopprettet dataene sine uten å betale løsepenger, så ville jeg vært tilbøyelig til å si: «Ingen [avsløring nødvendig].»

---

AND.  Har du gjort nok?

---

DOUG.  Ja.

---

AND.  Du forhindret det ikke helt, men du gjorde det nest beste, så du trenger ikke fortelle investorene dine...

Ironien er, Doug, hvis du hadde gjort det som et selskap, ville du kanskje si til investorene dine: «Hei, gjett hva? Vi hadde et løsepenge-angrep som alle andre, men vi kom oss ut av det uten å betale pengene, uten å engasjere oss med skurkene og uten å miste data. Så selv om vi ikke var perfekte, var vi den nest beste tingen.»

Og det kan faktisk ha mye vekt å avsløre det frivillig, selv om loven sa at du ikke måtte.

---

DOUG.  Og så, for Type B, utpressingsvinkelen, sier Adam:

Det er en vanskelig situasjon.

Teoretisk sett vil jeg si "Ja."

Men det vil sannsynligvis føre til mange avsløringer og skadet forretningsomdømme.

Så hvis du har en haug med selskaper som kommer ut og sier: «Se, vi ble rammet av løsepengevare; vi tror ikke noe vondt skjedde; vi betalte kjeltringene for å holde dem stille; og vi stoler på at de ikke kommer til å søle bønner," for å si det sånn...

…det skaper en vanskelig situasjon, fordi det kan skade et selskaps omdømme, men hadde de ikke avslørt det, ville ingen vite det.

---

AND.  Og jeg ser at Adam følte det på samme måte som både du og jeg gjorde når det gjaldt: "Du har fire dager, og ikke mer enn fire dager... fra det øyeblikket du tror de fire dagene skulle begynne."

Han rumlet det også, gjorde han ikke?

Han sa:

Noen selskaper vil sannsynligvis ta i bruk taktikker for å forsinke å avgjøre om det er en vesentlig påvirkning.

Så vi vet ikke helt hvordan dette vil spille ut, og jeg er sikker på at SEC ikke helt vet det heller.

Det kan ta et par testtilfeller for dem å finne ut hva som er riktig mengde byråkrati for å sikre at vi alle lærer det vi trenger å vite, uten å tvinge selskaper til å avsløre hver eneste liten IT-feil som noen gang skjer og begrave oss alle i en masse papirer.

Som i hovedsak fører til bruddtretthet, ikke sant?

Hvis du har så mange dårlige nyheter som ikke er så veldig viktig, bare skyll over deg...

…på en eller annen måte er det lett å gå glipp av de virkelig viktige tingene som er blant alle "trenger jeg virkelig å høre om det?"

Tiden vil vise, Douglas.

---

DOUG.  Ja, vanskelig!

Og jeg vet at jeg sier dette hele tiden, men vi kommer til å holde et øye med dette, for det skal bli fascinerende å se dette utspille seg.

Så takk, Adam, for at du sendte inn den kommentaren.

---

AND.  Ja absolutt!

---

DOUG.  Hvis du har en interessant historie, kommentar eller spørsmål du vil sende inn, vil vi gjerne lese på podcasten.

Du kan sende en e-post til tips@sophos.com, du kan kommentere en av artiklene våre, eller du kan kontakte oss på sosiale medier: @nakedsecurity.

Det er showet vårt for i dag; tusen takk for at du lyttet.

For Paul Ducklin, jeg er Doug Aamoth, og minner deg på til neste gang om å...

---

BÅDE.  Hold deg trygg.

[MUSIKK MODEM]