S3 Ep112: Datainnbrudd kan hjemsøke deg mer enn én gang! [Lyd + tekst]

Klikk og dra på lydbølgene nedenfor for å hoppe til et hvilket som helst punkt. Du kan også lytte direkte på Soundcloud.

DOUG.  SIM-bytte, null dager, den [dramatiske stemmen] Ping of DEATH, og LastPass … igjen.

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

[MUSIKK MODEM]

Velkommen til podcasten alle sammen.

Jeg er Doug Aamoth.

Med meg er som alltid Paul Ducklin.

Paul, hvordan har du det?

---

AND.  Veldig bra, Doug.

Jeg er glad for å se at du legger litt høydramatisk lyd inn i den introen!

---

DOUG.  Vel, hvordan sier du «Ping of Death» uten å si [doom metal growl] «Ping of DEATH»?

Du kan ikke bare si [mild stemme] "Ping of Death".

Du må slå den litt...

---

AND.  Jeg antar det.

Det er annerledes å skrive – hva har du?

Fet og kursiv.

Jeg gikk bare med vanlig tekst, men jeg brukte store bokstaver, noe som hjelper.

---

DOUG.  Ja, jeg tror jeg ville fet og kursivt ordet «død», så [doom metal igjen] «The Ping of DEATH».

---

AND.  Og bruk flere farger!

Jeg skal gjøre det neste gang, Doug.

---

DOUG.  Bryt ut det gamle tag i HTML, få det til å blinke litt? [LETER]

---

AND.  Doug, et øyeblikk var jeg bekymret for at du skulle bruke ordet [LETER] .

---

DOUG.  [LAUGGER] Vi elsker gamle ting her!

Og det passer fint med vår Denne uken i teknisk historie segment – ​​jeg er spent på denne fordi jeg ikke hadde hørt om den, men snublet over den.

Denne uken, den 04. desember 2001, ransaket Goner-ormen internett i et tempo som er nest etter Love Bug-viruset.

Goner spredte seg via Microsoft Outlook, og lovet intetanende ofre en morsom skjermsparer når den ble henrettet.

---

AND.  Goner...

Jeg tror den fikk det navnet fordi det var en popup på slutten, ikke sant, som nevnte Pentagon?

Men det var ment å være et ordspill – det var «Penta/Gone».

Det var absolutt ormen som minnet folk om at Windows-skjermsparere faktisk bare er kjørbare programmer.

Så hvis du ser spesielt etter .EXE filer, vel, de kan pakkes inn .SCR (skjermsparer) filer også.

Hvis du bare stolte på filnavn, kunne du lett bli lurt.

Og mange mennesker var det, dessverre.

---

DOUG.  Ok, vi går fra den gamle skolen til den nye skolen.

Vi snakker om LastPass: det var et brudd; bruddet i seg selv var ikke forferdelig; men det bruddet har nå ført til et nytt brudd.

Eller kanskje dette bare er en fortsettelse av det opprinnelige bruddet?

LastPass innrømmer kundedatabrudd forårsaket av tidligere brudd

---

AND.  Ja, LastPass har egentlig skrevet om det som en oppfølging av det forrige bruddet, som jeg tror var august 2022, ikke sant?

Og som vi sa den gangen, var det et veldig pinlig utseende for LastPass.

Men som brudd går, var det sannsynligvis verre for deres PR, markedsføring og (antar jeg) for deres åndsverksavdelinger, fordi det ser ut til at det viktigste skurkene gjorde unna var kildekoden fra utviklingssystemet deres.

Og LastPass var raskt ute med å berolige folk...

For det første antydet undersøkelsene deres at mens de var der inne, var skurkene ikke i stand til å gjøre noen uautoriserte endringer som senere kan trenge inn i den virkelige koden.

For det andre gir tilgang til utviklingssystemet deg ikke tilgang til produksjonssystemet, hvor selve koden er bygget.

Og for det tredje kunne de si at det så ut til at ingen krypterte passordhvelv ble stjålet, så skylagringen til de krypterte passordene dine ble ikke åpnet.

Og selv om det hadde blitt åpnet, ville bare du vite passordet, fordi dekrypteringen (det du kalte "det tunge løftet" da vi snakket om det på podcasten) faktisk gjøres i minnet på enhetene dine - LastPass ser aldri din passord.

Og så, for det fjerde, sa de, så vidt vi kan se, som et resultat av det bruddet, har noen av tingene som var i utviklingsmiljøet nå gitt enten det samme... eller muligens en helt annen mengde skurker som kjøpte stjålet data fra forrige parti, hvem vet?

Det gjorde det mulig for dem å komme inn i en skytjeneste der et tilsynelatende ukjent sett med kundedata ble stjålet.

Jeg tror ikke de vet helt ennå, fordi det kan ta litt tid å finne ut hva som faktisk ble åpnet etter at et brudd skjedde.

Så jeg tror det er rettferdig å si at dette er en slags B-side av det opprinnelige bruddet.

---

DOUG.  Greit, vi foreslår at hvis du er LastPass-kunde, bør du holde et øye med selskapets sikkerhetshendelsesrapport.

Vi vil holde øye med denne historien ettersom den fortsatt utvikler seg.

Og hvis du, som Paul og jeg, kjemper mot nettkriminalitet for livet, er det noen gode lærdommer å lære av Uber-bruddet.

Så det er en podcast-episode - en "minisode" - med Chester Wisniewski som Paul har innebygd nederst i LastPass-artikkelen:

S3 Ep100.5: Uber-brudd – en ekspert snakker [lyd + tekst]

Mye å lære på den fronten!

---

AND.  Som du sier, det er en flott lytt, fordi det er, tror jeg, det som er kjent i Amerika som "handlingsbare råd", eller "nyheter du kan bruke".

---

DOUG.  [LETER] Fantastisk.

Når vi snakker om nyheter-du-egentlig-ikke-kan-bruke, er Apple generelt ordknappe om sikkerhetsoppdateringene ... og det var en sikkerhetsoppdatering:

Apple sender ut iOS-sikkerhetsoppdateringen som er mer ordknapp enn noen gang

---

AND.  Å, Doug, det er en av de beste... Jeg liker den serien.

---

DOUG.  [LAUGGER] Takk; tusen takk.

---

AND.  Ja, dette overrasket meg.

Jeg tenkte: "Vel, jeg tar oppdateringen fordi det høres seriøst ut."

Og jeg ga meg selv grunnen: "La meg gjøre det for lesere av Naked Security."

For hvis jeg gjør det og det ikke er noen bivirkninger, så kan jeg i det minste si til andre mennesker: "Se, jeg gjorde det blindt og ingen skade kom til meg. Så kanskje du kan gjøre det også.»

Jeg la bare plutselig merke til at det var en iOS 16.1.2-oppdatering tilgjengelig, selv om jeg ikke hadde fått noen sikkerhetsrådgivnings-e-post fra Apple.

Ingen e-post?!

Det er rart.. så jeg dro til HT201222 portalsiden som Apple har for sine sikkerhetsbulletiner, og der var den: iOS 16.1.2.

Og hva står det, Doug, "Detaljer vil følge snart"?

---

DOUG.  Og fulgte de etter snart?

---

AND.  Vel, det var mer enn en uke siden, og de er ikke der ennå.

Så snakker vi "snart" som betyr timer, dager, uker eller måneder?

For øyeblikket ser det ut som uker.

Og, som alltid med Apple, er det ingen indikasjon på noe som har å gjøre med andre operativsystemer.

Har de blitt glemt?

Trenger de ikke oppdateringen?

Trengte de også oppdateringen, men den er bare ikke klar ennå?

Har de mistet støtten?

Men det virket, som jeg sa i overskriften, enda mer ordknapp enn vanlig for Apple, og ikke nødvendigvis det mest nyttige i verden.

---

DOUG.  OK, veldig bra ... fortsatt noen spørsmål, som fører oss til vår neste historie.

Et veldig interessant spørsmål!

Noen ganger, når du registrerer deg for en tjeneste og den håndhever tofaktorautentisering, står det: "Vil du bli varslet via tekstmelding, eller vil du bruke en autentiseringsapp?"

Og denne historien er en advarsel om å ikke bruke telefonen – bruk en autentiseringsapp, selv om den er litt mer tungvint.

Dette er en veldig interessant historie:

SIM-bytter sendt til fengsel for 2FA-kryptovaluta-ran på over 20 millioner dollar

---

AND.  Det er det, Doug!

Hvis du noen gang har mistet en mobiltelefon, eller låst deg ute av SIM-kortet ditt ved å taste inn feil PIN-kode for mange ganger, vet du at du kan gå inn i mobiltelefonbutikken...

... og vanligvis vil de be om ID eller noe, og du sier: "Hei, jeg trenger et nytt SIM-kort."

Og de vil generere en for deg.

Når du legger den inn i telefonen, bingo!... den har det gamle nummeret ditt på.

Så hva det betyr er at hvis en kjeltring kan gå gjennom den samme øvelsen som du ville for å overbevise mobilselskapet om at de har "mistet" eller "ødelagt" SIM-kortet sitt (dvs. *SIM-kortet ditt*), og de kan få det kortet enten gitt til, sendt til, eller gitt til dem på en eller annen måte...

…så, når de kobler den til telefonen sin, begynner de å få SMS-tofaktorautentiseringskodene dine, *og* telefonen din slutter å fungere.

Det er de dårlige nyhetene.

Den gode nyheten i denne artikkelen er at dette var et tilfelle av en fyr som ble slått for det.

Han har blitt sendt til fengsel i USA i 18 måneder.

Han, med en haug med medskyldige – eller, med justisdepartementets ord, den Deltakere i ordningen… [LATER]

...de kom seg unna med ett bestemt offers kryptovaluta, tilsynelatende til en verdi av 20 millioner dollar, hvis du ikke har noe imot det.

---

DOUG.  Uff!

---

AND.  Så han gikk med på å erkjenne straffskyld, ta en fengselsstraff og umiddelbart tape ... beløpet var [les nøye] $983,010.72 XNUMX ... bare for å miste det med en gang.

Så antagelig hadde han det liggende.

Og han har tilsynelatende også en slags juridisk forpliktelse til å refundere over 20 millioner dollar.

---

DOUG.  Lykke til med det, alle sammen! Lykke til.

Hans andre [vokalkursiv] Deltakere i ordningen kan forårsake noen problemer der! [LETER]

---

AND.  Ja, jeg vet ikke hva som skjer hvis de nekter å samarbeide også.

Som, hvis de bare henger ham ut til tørk, hva skjer?

Men vi har noen tips og noen råd om hvordan du kan øke sikkerheten (på flere måter enn bare 2FA du bruker) i artikkelen.

Så gå og les det ... hver liten bit hjelper.

---

DOUG.  OK, når vi snakker om "småbiter"...

…dette var nok en fascinerende historie, hvordan den ydmyke ping kan brukes til å utløse ekstern kjøring av kode:

Ping av død! FreeBSD fikser crashtastic bug i nettverksverktøyet

---

AND.  [Liker segue igjen] Jeg tror du har forbedret deg selv, Doug!

---

DOUG.  [LAUGGER] Jeg er på rulle i dag...

---

AND.  Fra Apple til [svake forsøk på doom-vokal] Ping of DEATH!

Ja, dette var en spennende feil.

Jeg tror ikke det virkelig vil forårsake mange mennesker mye skade, og det *er* lappet, så det er enkelt å fikse det.

Men det er en flott oppskrift i FreeBSD sikkerhetsrådgivende...

…og det gir en underholdende, og, om jeg skal si det selv, en veldig informativ historie for den nåværende generasjonen av programmerere som kan ha stolt på,” Tredjepartsbiblioteker vil bare gjøre det for meg. Har du å gjøre med nettverkspakker på lavt nivå? Jeg trenger aldri å tenke på det..."

Det er noen gode lærdommer å lære her.

De ping verktøyet, som er det eneste nettverksverktøyet som stort sett alle vet om det, har fått navnet sitt fra SONAR.

Du går [lager ubåtstøy fra film] ping, og så kommer ekkoet tilbake fra serveren i den andre enden.

Og dette er en funksjon som er innebygd i Internett-protokollen, IP, ved å bruke en ting som heter ICMP, som er Internet Control Message Protocol.

Det er en spesiell protokoll på lavt nivå, mye lavere enn UDP eller TCP som folk sannsynligvis er vant til, som ganske mye er designet for akkurat denne typen ting: «Er du faktisk i live i den andre enden, før jeg går og bekymrer meg for hvorfor fungerer ikke webserveren din?"

Det er en spesiell type pakke du kan sende ut kalt "ICMP Echo".

Så du sender denne bitte lille pakken med en kort melding i den (meldingen kan være hva du vil), og den sender ganske enkelt den samme meldingen tilbake til deg.

Det er bare en grunnleggende måte å si, "Hvis den meldingen ikke kommer tilbake, er enten nettverket eller hele serveren nede", i stedet for at det er et programvareproblem på datamaskinen.

I analogi med SONAR kalles programmet som sender ut disse ekkoforespørslene … [pause] Jeg skal gjøre lydeffekten, Doug … [falsk ubåtfilmstøy igjen] ping. [LATTER]

Og ideen er, du går, si, ping -c3 (det betyr sjekk tre ganger) nakedsecurity.sophos.com.

Du kan gjøre det akkurat nå, og du bør få tre svar, hver av dem med ett sekunds mellomrom, fra WordPress-serverne som er vert for nettstedet vårt.

Og det sier at siden er i live.

Den forteller deg ikke at webserveren er oppe; det forteller deg ikke at WordPress er oppe; det er ikke å si at Naked Security faktisk er tilgjengelig for lesing.

Men det bekrefter i det minste at du kan se serveren, og serveren kan nå deg.

Og hvem ville trodd at det lille ping-svaret kunne snuble FreeBSD ping programmer på en slik måte at en useriøs server kan sende tilbake en "Ja, jeg er i live"-melding som i teorien (bare i teorien; jeg tror ikke noen har gjort dette i praksis) kan utløse ekstern kjøring av kode på din datamaskin.

---

DOUG.  Ja, det er utrolig; det er den fantastiske delen.

Selv om det er et proof-of-concept, er det en så liten liten ting!

---

AND.  De ping programmet selv får hele IP-pakken tilbake, og det er ment å dele den i to deler.

Normalt vil kjernen håndtere dette for deg, så du vil bare se datadelen.

Men når du har å gjøre med det som kalles rå stikkontakter, det du får tilbake er Internet Protocol-overskriften, som bare sier: "Hei, disse bytene kom fra en slik og en server."

Og så får du en ting som heter "ICMP Echo Reply", som er den andre halvdelen av pakken du får tilbake.

Nå, disse pakkene, er de vanligvis bare 100 byte eller så, og hvis det er IPv4, er de første 20 bytene IP-headeren og resten, uansett hva det er, er Echo Reply.

Det har noen byte å si, "Dette er et ekkosvar", og deretter den opprinnelige meldingen som gikk ut og kom tilbake.

Og så den åpenbare tingen å gjøre, Doug, når du får den, er at du deler den inn i …

…IP-headeren, som er 20 byte lang, og resten.

Gjett hvor problemet ligger?

---

DOUG.  Fortell!

---

AND.  Problemet er at IP-hoder er *nesten alltid* 20 byte lange – faktisk tror jeg aldri jeg har sett en som ikke var det.

Og du kan se at de er 20 byte lange fordi den første byten vil være heksadesimal 0x45.

"4"" betyr IPv4, og "5"... "Å, vi bruker det til å si hvor lang overskriften er."

Du tar det tallet 5 og multipliserer det med 4 (for 32-bits verdier), og du får 20 byte.

…og det er på størrelse med sannsynligvis seks sigmas IP-hoder som du noen gang vil se i hele verden, Doug. [LATTER]

Men de *kan* gå opp til 60 byte.

Hvis du legger 0x4F istedenfor 0x45, som sier at det er 0xF (eller 15 i desimal) × 4 = 60 byte i overskriften.

Og FreeBSD-koden tok ganske enkelt den overskriften og kopierte den inn i en buffer på stabelen som var 20 byte stor.

En enkel, gammeldags stabelbufferoverflyt.

Det er et tilfelle av et ærverdig nettverksfeilsøkingsverktøy med en ærverdig type feil i seg. (Vel, ikke lenger.)

Så når du programmerer og du må forholde deg til ting på lavt nivå som ingen egentlig har tenkt på i evigheter, ikke bare gå med den mottatte visdommen som sier: «Å, det vil alltid være 20 byte; du vil aldri se noe større."

For en dag kan du kanskje.

Og når den dagen kommer, kan den være der med vilje fordi en kjeltring gjorde det med vilje.

Så djevelen, som alltid, er i programmeringsdetaljene, Doug.

---

DOUG.  OK, veldig interessant; flott historie.

Og vi vil holde oss til emnet kode med denne siste historien om Chrome.

Nok en null-dag, som bringer totalen for 2022 til ni ganger:

Nummer ni! Chrome fikser nok en 2022 null-dager, Edge lappet også

---

AND.  [Formell stemme, høres ut som et opptak] "Nummer 9. Nummer 9. Nummer 9, nummer 9," Douglas.

---

DOUG.  [LETER] Er dette Yoko Ono?

---

AND.  Det er Revolution 9 fra Beatles "White Album".

Yoko kan høres riffe bort i den sangen – det lydbilde, tror jeg de kaller det – men tilsynelatende biten i begynnelsen hvor det er noen som sa "Nummer 9, nummer 9" om og om igjen, det var faktisk et testbånd de fant liggende.

---

DOUG.  Ah, veldig kult.

---

AND.  En EMI-ingeniør som sa noe sånt som: "Dette er EMI-testbånd nummer 9" [LATER], og tilsynelatende tror jeg ikke engang noen vet hvem sin stemme det var.

Det har *ingenting* med Chrome å gjøre, Doug.

Men gitt at noen kommenterte på Facebook her om dagen, "Denne Paul-fyren begynner å se ut som en Beatle" ... [quizzical] som jeg syntes var litt rart.

---

DOUG.  [LAUGGER] Ja, hvordan skal du ta det?

---

AND.  …Jeg tenkte at jeg kunne spise ute på "Nummer 9".

Det ser ut til at det er den niende nulldagen i året så langt, Doug.

Og det er en feilretting med én feil, med feilen identifisert som CVE 2022-4282.

Fordi Microsoft Edge bruker Chromium åpen kildekode-kjernen, var den også sårbar, og et par dager senere fulgte Microsoft opp med en oppdatering for Edge.

Så dette er både et Chrome- og et Edge-problem.

Selv om disse nettleserne bør oppdatere seg selv, anbefaler jeg å sjekke uansett – vi viser deg hvordan du gjør det i artikkelen – i tilfelle.

Jeg vil ikke lese opp versjonsnumrene her fordi de er forskjellige for Mac, Linux og Windows på Chrome, og de er annerledes igjen for Edge.

I likhet med Apple er Google litt ordknapp om denne.

Den ble funnet av en av trusseljaktene deres, tror jeg.

Så jeg ser for meg at de fant det mens de undersøkte en hendelse som skjedde i naturen, og derfor ønsker de sannsynligvis å holde den under hatten, selv om Google vanligvis har mye å si om "åpenhet" når det kommer til feilretting.

Du kan se hvorfor du i et tilfelle som dette kanskje vil ha litt tid til å grave litt dypere før du forteller alle nøyaktig hvordan det fungerer.

---

DOUG.  Utmerket ... og vi har et leserspørsmål som sannsynligvis er et spørsmål mange tenker på.

Cassandra spør: «Er feilsøkerne bare heldige når de finner feil? Eller har de truffet en "søm" full av insekter? Eller utsteder Chromium ny kode som er mer buggy enn normalt? Eller er det noe annet som skjer?"

---

AND.  Ja, det er et flott spørsmål, faktisk, og jeg er redd for at jeg bare kunne svare på det på en litt fasett måte, Doug.

Fordi Cassandra hadde gitt valgene A), B) og C), sa jeg: "Vel, kanskje det er det D) Alt ovenfor."

Vi vet at når en feil av en bestemt type dukker opp i kode, så er det rimelig å anta at den samme programmereren kan ha laget lignende feil andre steder i programvaren.

Eller andre programmerere ved samme selskap kan ha brukt det som ble ansett som mottatt visdom eller standard praksis på den tiden, og kan ha fulgt etter.

Og et godt eksempel er, hvis du ser tilbake på Log4J ... det var en løsning for å korrigere problemet.

Og så, da de gikk på jakt, "Å, faktisk, det er andre steder der lignende feil har blitt gjort."

Så det var en fiks for reparasjonen, og så var det en reparasjon for reparasjonen, hvis jeg husker.

Det er selvfølgelig også problemet at når du legger til ny kode, kan du få feil som er unike for den nye koden og oppstår på grunn av å legge til funksjoner.

Og det er grunnen til at mange nettlesere, inkludert Chrome, har en "litt eldre" versjon som du kan holde deg til.

Og ideen er at de "eldre" utgivelsene... de har ingen av de nye funksjonene, men alle relevante sikkerhetsrettinger.

Så hvis du vil være konservativ når det gjelder nye funksjoner, kan du være det.

Men vi vet absolutt at noen ganger, når du skyver nye funksjoner inn i et produkt, kommer nye feil med de nye funksjonene.

Og du kan fortelle det, for eksempel når det er en oppdatering, for eksempel, for din iPhone, og du får oppdateringer, for eksempel, for iOS 15 og iOS 16.

Så, når du ser på feillistene, er det få feil som bare gjelder iOS 16.

Og du tenker: "Hei, det må være feil i koden som ikke var der før."

Så, ja, det er en mulighet.

Og jeg tror de andre tingene som foregår kan anses som gode.

Den første er at jeg tror at, spesielt for ting som nettlesere, blir nettleserprodusentene mye bedre til å presse ut fullstendige ombygginger veldig, veldig raskt.

---

DOUG.  Interessant.

---

AND.  Og jeg tror den andre tingen som har endret seg, er at man tidligere kunne argumentere for at for mange leverandører... var det ganske vanskelig å få folk til å bruke oppdateringer i det hele tatt, selv når de bare kom ut på en månedlig plan, og selv om de hadde flere null-dagers rettelser i seg.

Jeg tror kanskje det også er et svar på det faktum at flere og flere av oss er mer og mer sannsynlige ikke bare å akseptere, men faktisk *forvente* automatisk oppdatering som virkelig er rask.

Så jeg tror du kan lese noen gode ting i dette.

Det faktum ikke bare at Google kan presse ut en enkelt null-dagers løsning nesten umiddelbart, men også at folk er villige til å akseptere det og til og med kreve det.

Så jeg liker å se problemet med, "Wow, ni null-dager i året løst individuelt!"...

…Jeg liker å tenke på det mer som "glass halvt fylles og fylles opp" enn "glasset halvt tomt og renner gjennom et lite hull i bunnen". [LATTER]

Det er min mening.

---

DOUG.  Greit, veldig bra.

Takk for spørsmålet, Cassandra.

Hvis du har en interessant historie, kommentar eller spørsmål du vil sende inn, vil vi gjerne lese den 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 er jeg Doug Aamoth, og minner deg på: Til neste gang …

---

BÅDE.  Hold deg trygg!

[MUSIKK MODEM]