S3 Ep108: Du gjemte TRE MILLIARDER dollar i en popcornboks?

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

DOUG.  Twitter-svindel, Patch Tuesday og kriminelle som hacker kriminelle.

Alt det og mer på Naked Security-podcasten.

[MUSIKK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug.

Han er Paul Ducklin.

Paul, hvordan har du det i dag?

---

AND.  Veldig bra, Doug.

Vi hadde ikke måneformørkelsen her i England, men jeg fikk et kort glimt av *full* fullmåne gjennom et lite gap i skyene som dukket opp som det eneste hullet i hele skylaget i det øyeblikket jeg gikk ut for å ta en titt!

Men vi hadde ikke den oransje månen slik dere hadde i Massachusetts.

---

DOUG.  La oss begynne showet med Denne uken i teknisk historie… dette går langt tilbake.

Denne uken, den 08. november 1895, snublet den tyske fysikkprofessor Wilhelm Röntgen over en ennå uoppdaget form for stråling som fikk ham til å referere til nevnte stråling ganske enkelt som "X".

Som på røntgen.

Hva med det... den utilsiktede oppdagelsen av røntgenstråler?

---

AND.  Ganske utrolig.

Jeg husker at mamma sa til meg: på 1950-tallet (må ha vært det samme i USA), tilsynelatende, i skobutikker...

---

DOUG.  [VET HVA KOMMER] Ja! [LETER]

---

AND.  Folk ville ta barna sine inn... du ville stå i denne maskinen, ta på deg skoene og i stedet for bare å si: «Gå rundt, er de trange? Klemmer de?”, sto du i en røntgenmaskin, som bare badet deg i røntgenstråling og tok et levende bilde og sa: “Å ja, de har riktig størrelse.”

---

DOUG.  Ja, enklere tider. Litt farlig, men...

---

AND.  LITT FARLIG?

Kan du forestille deg menneskene som jobbet i skobutikkene?

De må ha badet i røntgen hele tiden.

---

DOUG.  Absolutt … vel, vi er litt tryggere i dag.

Og når det gjelder sikkerhet, er den første tirsdagen i måneden Microsofts Patch Tuesday.

So hva lærte vi denne Patch Tuesday her i november 2022?

Bytt 0-dager fast (endelig) – pluss 4 splitter nye Patch Tuesday 0-dager!

---

AND.  Vel, det superspennende, Doug, er at teknisk sett fikset Patch Tuesday ikke én, ikke to, ikke tre ... men *fire* null-dager.

Men faktisk fikset oppdateringene du kunne få for Microsoft-produkter på tirsdag *seks* null-dager.

Husk de Exchange-nulldagene som notorisk ikke ble oppdatering sist Patch Tuesday: CVE-2002-41040 og CVE-2022-41082, det som ble kjent som ProxyNotShell?

S3 Ep102.5: "ProxyNotShell" Exchange-feil – en ekspert snakker [lyd + tekst]

Vel, de ble fikset, men i hovedsak en egen "sidelinje" til Patch Tuesday: Exchange November 2022 SU, eller Software Update, som bare sier:

November 2022 Exchange-programvareoppdateringene inneholder rettinger for nulldagerssårbarhetene som ble rapportert offentlig 29. september 2022.

Alt du trenger å gjøre er å oppgradere Exchange.

Hei, takk Microsoft... Jeg tror vi visste at det var det vi måtte gjøre når oppdateringene endelig kom ut!

Så, de *er* ute og det er to null-dager faste, men de er ikke nye, og de er teknisk sett ikke i "Patch Tuesday"-delen.

Der har vi fire andre null-dager fast.

Og hvis du tror på å prioritere patcher, så er det åpenbart de du vil forholde deg til først, fordi noen allerede vet hvordan de skal gjøre dårlige ting med dem.

Disse spenner fra en sikkerhetsbypass, til to rettighetsforhøyelser og en ekstern kjøring av kode.

Men det er flere enn 60 lapper totalt, og hvis du ser på den samlede listen over produkter og Windows-komponenter som er berørt, er det en enorm liste, som vanlig, som tar inn alle Windows-komponenter/-produkter du har hørt om, og mange du sannsynligvis ikke har.

Microsoft retter opp 62 sårbarheter, inkludert Kerberos og Mark of the Web, og Exchange ... en slags

Så, som alltid: Ikke utsett/gjør det i dag, Douglas!

---

DOUG.  Veldig bra.

La oss nå snakke om ganske forsinkelser...

Du har en veldig interessant historie om Silk Road narkotikamarked, og en påminnelse om at kriminelle som stjeler fra kriminelle fortsatt er en forbrytelse, selv om det er noen ti år senere du faktisk blir tatt for det.

Silk Road narkotikamarkedet hacker erkjenner straffskyld, står overfor 20 år inne

---

AND.  Ja, selv folk som er ganske ferske innen cybersikkerhet eller til å gå på nett, vil sannsynligvis ha hørt om "Silk Road", kanskje den første velkjente, store, utbredte, mye brukte mørke nettmarkedsplassen der praktisk talt alt går.

Så alt gikk opp i flammer i 2013.

Fordi grunnleggeren, opprinnelig bare kjent som Frykter piraten Roberts, men til slutt avslørt å være Ross Ulbricht… hans dårlige driftssikkerhet var nok til å knytte aktivitetene til ham.

Silk Road-gründer Ross Ulbricht får livstid uten prøveløslatelse

Ikke bare var operasjonssikkerheten hans ikke veldig god, det ser ut til at de i slutten av 2012 hadde (kan du tro det, Doug?) en betalingsbehandlingsfeil i kryptovaluta...

---

DOUG.  [GIPE I HÅNDT SKREKK]

---

AND.  …av den typen vi har sett gjentatt mange ganger siden, som gikk rundt og ikke helt gjorde skikkelig dobbel bokføring, hvor det for hver debet er en tilsvarende kreditt og omvendt.

Og denne angriperen oppdaget, hvis du satte inn noen penger på kontoen din og så raskt betalte dem ut til andre kontoer, at du faktisk kunne betale ut fem ganger (eller enda mer) de samme bitcoinene før systemet innså at den første belastningen var borte gjennom.

Så du kan i utgangspunktet sette inn noen penger og så bare ta dem ut igjen og igjen og igjen, og få en større oppbevaring...

…og så kan du gå tilbake til det du kan kalle en "melkesløyfe for kryptovaluta".

Og det er anslått... etterforskerne var ikke sikre på at han startet med mellom 200 og 2000 egne bitcoins (om han kjøpte dem eller mine dem, vet vi ikke), og han gjorde dem veldig, veldig raskt til, vent på det, Doug: 50,0000 XNUMX bitcoins!

---

DOUG.  Wow!

---

AND.  Mer enn 50,000 XNUMX bitcoins, bare sånn.

Og så, da han tydeligvis fant ut at noen kom til å legge merke til, kuttet han og løp mens han var foran med 50,000 XNUMX bitcoins...

…hver verdt utrolige $12, opp fra brøkdeler av en cent bare noen få år før. [LETER]

Så han slapp med $600,000 XNUMX, akkurat som det, Doug.

[DRAMATISK PAUSE]

Ni år senere...

[LATTER]

…nesten *nøyaktig* ni år senere, da han ble slått og hjemmet hans ble angrepet under en arrestordre, gikk politiet på leting og fant en haug med tepper i skapet hans, hvorunder det var skjult en popcornboks.

Rart sted å oppbevare popcornet ditt.

Inni som var en slags datastyrt kald lommebok.

Inne som var en stor andel av nevnte bitcoins!

På det tidspunktet han ble brutt, var bitcoins noe nord for $65,535 2 (eller XNUMX¹⁶-1) hver.

De hadde gått opp godt over tusen ganger i mellomtiden.

Så på den tiden var det den største kryptomyntbysten noensinne!

Ni år senere, etter å ha tilsynelatende ikke vært i stand til å kvitte seg med sine dårlige gevinster, kanskje redd for at selv om han prøvde å dytte dem i en glass, ville alle fingrene peke tilbake til ham...

…han har hatt alle disse bitcoins verdt 3 milliarder dollar som har ligget i en popcornboks i ni år!

---

DOUG.  Kjære vene.

---

AND.  Så etter å ha sittet på denne skumle skatten i alle disse årene, og lurt på om han kom til å bli tatt, lurer han nå på: "Hvor lenge skal jeg sitte i fengsel?"

Og maksimumsstraffen for siktelsen han står overfor?

20 år, Doug.

---

DOUG.  Nok en interessant historie på gang akkurat nå. Hvis du har vært på Twitter i det siste, vil du vite at det er mye aktivitet. for å si det diplomatisk...

---

AND.  [LAV-TIL-MIDDELS KVALITET BOB DYLAN IMPERSONATION] Vel, tidene er i endring.

---

DOUG.  ...inkludert på et tidspunkt ideen om å belaste $20 for en bekreftet blå sjekk, som selvfølgelig nesten umiddelbart førte til noen svindel.

Twitter Blue Badge e-postsvindel – Ikke fall for dem!

---

AND.  Det er bare en påminnelse, Doug, at når det er noe som har vakt stor interesse, vil skurkene helt sikkert følge etter.

Og premisset for dette var: «Hei, hvorfor ikke komme tidlig? Hvis du allerede har et blått merke, gjett hva? Du trenger ikke å betale $19.99 i måneden hvis du forhåndsregistrerer deg. Vi lar deg beholde den.»

Vi vet at det ikke var Elon Musks idé, som han sa det, men det er den typen ting som mange bedrifter gjør, ikke sant?

Mange selskaper vil gi deg en slags fordel hvis du fortsetter med tjenesten.

Så det er ikke helt utrolig.

Som du sier... hva ga du den?

B-minus, var det?

---

DOUG.  Jeg gir den første e-posten et B-minus... du kan kanskje bli lurt hvis du leser den raskt, men det er noen grammatikkproblemer; ting føles ikke riktig.

Og så når du klikker deg gjennom, vil jeg gi landingssidene C-minus.

Det blir enda vanskeligere.

---

AND.  Det er et sted mellom 5/10 og 6/10?

---

DOUG.  Ja, la oss si det.

Og vi har noen råd, slik at selv om det er en A-pluss-svindel, vil det ikke ha noe å si, for du vil være i stand til å forpurre det uansett!

Starter med min personlige favoritt: Bruk en passordbehandling.

En passordbehandler løser mange problemer når det kommer til svindel.

---

AND.  Det gjør det.

En passordbehandler har ingen menneskelignende intelligens som kan villedes av det faktum at det vakre bildet er riktig, eller logoen er perfekt, eller nettskjemaet er i nøyaktig riktig posisjon på skjermen med nøyaktig samme font , så du kjenner det igjen.

Alt den vet er: "Aldri hørt om denne siden før."

---

DOUG.  Og selvfølgelig, slå på 2FA hvis du kan.

Legg alltid til en annen autentiseringsfaktor, hvis mulig.

---

AND.  Selvfølgelig, det beskytter deg ikke nødvendigvis mot deg selv.

Hvis du går til et falskt nettsted og du har bestemt deg, "Hei, det er piksel-perfekt, det må være den virkelige avtalen", og du er fast bestemt på å logge på, og du har allerede lagt inn brukernavnet og passordet ditt, og så ber den deg om å gå gjennom 2FA-prosessen ...

…det er stor sannsynlighet for at du gjør det.

Det gir deg imidlertid litt tid til å gjøre "Stopp. Synes at. Koble." ting, og si til deg selv: «Vent, hva gjør jeg her?»

Så på en måte kan den lille forsinkelsen som 2FA introduserer faktisk ikke bare være veldig lite bryderi, men også en måte å faktisk forbedre cybersikkerhetsarbeidsflyten din på ... ved å introdusere akkurat nok av en fartsdump til at du er tilbøyelig til å ta cybersikkerhet litt mer seriøst.

Så jeg ser ikke hva ulempen er, egentlig.

---

DOUG.  Og selvfølgelig, en annen strategi som er vanskelig for mange mennesker å følge, men som er veldig effektiv, er å unngå påloggingslenker og handlingsknapper i e-post.

Så hvis du får en e-post, ikke bare klikk på knappen ... gå til selve nettstedet og du vil raskt kunne fortelle om den e-posten var legitim eller ikke.

---

AND.  I utgangspunktet, hvis du ikke helt kan stole på den første korrespondansen, kan du ikke stole på noen detaljer i den, enten det er lenken du skal klikke på, telefonnummeret du skal ringe, e-postadressen du kommer til å kontakte dem på , Instagram-kontoen du skal sende DM-er til, uansett hva det er.

Ikke bruk det som står i e-posten... finn din egen vei dit, og du vil kortslutte mye svindel av denne typen.

---

DOUG.  Og til slutt, sist men ikke minst... dette burde være sunn fornuft, men det er ikke: Spør aldri avsenderen av en usikker melding om de er legitime.

Ikke svar og si: "Hei, er du virkelig Twitter?"

---

AND.  Ja, du har helt rett.

Fordi mitt tidligere råd, "Ikke stol på informasjonen i e-posten", for eksempel ikke ring telefonnummeret deres ... noen mennesker er fristet til å gå, "Vel, jeg skal ringe telefonnummeret og se om det virkelig er dem. [IRONISK] Fordi, åpenbart, hvis kokken svarer, kommer de til å oppgi deres virkelige navn.»

---

DOUG.  Som vi alltid sier: Hvis du er i tvil/Ikke gi det ut.

Og dette er en god advarende historie, denne neste historien: når sikkerhetsskanninger, som er legitime sikkerhetsverktøy, avsløre mer enn de burde, hva skjer da?

Verktøy for offentlig URL-skanning – når sikkerhet fører til usikkerhet

---

AND.  Dette er en velkjent forsker ved navn Fabian Bräunlein i Tyskland ... vi har omtalt ham et par ganger før.

Han er tilbake med en detaljert rapport med tittelen urlscan.io's SOAR spot: chatty sikkerhetsverktøy som lekker private data.

Og i dette tilfellet er det det urlscan.io, et nettsted som du kan bruke gratis (eller som en betalt tjeneste) der du kan sende inn en URL, eller et domenenavn, eller et IP-nummer, eller hva det nå er, og du kan slå opp, «Hva vet fellesskapet om dette?"

Og det vil avsløre hele URL-en som andre spurte om.

Og dette er ikke bare ting som folk kopierer og limer etter eget valg.

Noen ganger kan e-posten deres, for eksempel, gå gjennom et tredjeparts filtreringsverktøy som selv trekker ut URL-er, ringer hjem til urlscan.io, gjør søket, henter resultatet og bruker det til å bestemme om meldingen skal søppelpost, spam-blokkeres eller sendes gjennom.

Og det betyr at noen ganger, hvis nettadressen inkluderte hemmelige eller halvhemmelige data, personlig identifiserbar informasjon, så ville andre personer som tilfeldigvis søkte etter det riktige domenenavnet i løpet av kort tid etterpå se alle nettadressene som ble søkt etter, inkludert ting som kan være i URL-en.

Du vet, liksom blahblah?username=doug&passwordresetcode= etterfulgt av en lang streng heksadesimale tegn, og så videre.

Og Bräunlein kom opp med en fascinerende liste over typen URL-er, spesielt de som kan vises i e-poster, som rutinemessig kan bli sendt til en tredjepart for filtrering og deretter bli indeksert for søk.

Den typen e-poster som han mente var definitivt brukbare inkludert, men var ikke begrenset til: kontoopprettingskoblinger; Amazon gaveleveringskoblinger; API-nøkler; DocuSign signeringsforespørsler; dropbox filoverføringer; pakke sporing; tilbakestilling av passord; PayPal-fakturaer; Google Drive-dokumentdeling; SharePoint-invitasjoner; og avmeldingskoblinger for nyhetsbrev.

Ikke peker fingre der på SharePoint, Google Drive, PayPal, etc.

Dette var bare eksempler på nettadresser han kom over som potensielt kunne utnyttes på denne måten.

---

DOUG.  Vi har noen råd på slutten av den artikkelen, som koker ned til: les Bräunleins rapport; lese urlscan.iosin bloggpost; gjør en egen kodegjennomgang; hvis du har kode som gjør sikkerhetsoppslag på nettet; finne ut hvilke personvernfunksjoner som finnes for innsendinger på nettet; og, viktigere, lære hvordan du rapporterer useriøse data til en nettjeneste hvis du ser det.

Jeg la merke til at det er tre... slags limericker?

Veldig kreative minidikt på slutten av denne artikkelen...

---

AND.  Nei, de er ikke limericker! Limericks har en veldig formell fem-linjers struktur ...

---

DOUG.  [LETER] Jeg er så lei meg. Det er sant!

---

AND.  ...for både meter og rim.

Veldig strukturert, Doug!

---

DOUG.  Jeg er så lei meg, så sant. [LETER]

---

AND.  Dette er bare doggerel. [LATTER]

Igjen: Hvis du er i tvil/Ikke gi det ut.

Og hvis du samler inn data: Hvis den ikke skulle være i/Stick den rett i søppelbøtta.

Og hvis du skriver kode som kaller offentlige APIer som kan avsløre kundedata: Få aldri brukerne til å gråte/ved hvordan du kaller API.

---

DOUG.  [LAUGGER] Det er en ny for meg, og jeg liker den veldig godt!

Og sist, men absolutt ikke minst på listen vår her, har vi snakket uke etter uke om denne OpenSSL-sikkerhetsfeilen.

Det store spørsmålet nå er "Hvordan vet du det hva må fikses?"

Historien om OpenSSL-sikkerhetsoppdatering – hvordan kan du fortelle hva som må fikses?

---

AND.  Ja, Doug, hvordan vet vi hvilken versjon av OpenSSL vi har?

Og åpenbart, på Linux, åpner du bare en ledetekst og skriver openssl version, og den forteller deg hvilken versjon du har.

Men OpenSSL er et programmeringsbibliotek, og det er ingen regel som sier at programvare ikke kan ha sin egen versjon.

Distroen din kan bruke OpenSSL 3.0, og likevel er det en app som sier: "Å, nei, vi har ikke oppgradert til den nye versjonen. Vi foretrekker OpenSSL 1.1.1, fordi det fortsatt støttes, og i tilfelle du ikke har det, tar vi med vår egen versjon."

Og så, dessverre, akkurat som i den beryktede Log4Shell-saken, måtte du lete etter de tre? 12? 154? hvem-vet-hvor mange steder på nettverket ditt hvor du kanskje har et utdatert Log4J-program.

Samme for OpenSSL.

I teorien kan XDR- eller EDR-verktøy kanskje fortelle deg det, men noen vil ikke støtte dette, og mange vil fraråde det: å kjøre programmet for å finne ut hvilken versjon det er.

Fordi, tross alt, hvis det er feilen eller feilen, og du faktisk må kjøre programmet for å få det til å rapportere sin egen versjon...

…det føles som å sette vognen foran hesten, ikke sant?

Så vi publiserte en artikkel for de spesielle tilfellene der du faktisk ønsker å laste DLL-en, eller det delte biblioteket, og du faktisk vil kalle sin egen TellMeThyVersion() programvarekode.

Med andre ord, du stoler på programmet nok til at du laster inn i minnet, kjører det og kjører en del av det.

Vi viser deg hvordan du gjør det slik at du kan være helt sikker på at eventuelle eksterne OpenSSL-filer du har på nettverket ditt er oppdatert.

For selv om dette ble nedgradert fra KRITISK til HØYT, er det fortsatt en feil du må og vil fikse!

---

DOUG.  Når det gjelder alvorlighetsgraden av denne feilen, fikk vi en interessant spørsmål fra naken sikkerhetsleser Svet, som delvis skriver:

Hvordan kan det ha seg at en feil som er enormt kompleks for utnyttelse, og som bare kan brukes til tjenestenektangrep, fortsetter å bli klassifisert som HØY?

---

AND.  Ja, jeg tror han sa noe om "Å, har ikke OpenSL-teamet hørt om CVSS?", som er en amerikansk regjeringsstandard, hvis du vil, for å kode risiko- og kompleksitetsnivået til feil på en måte som kan automatisk filtrert av skript.

Så hvis den har en lav CVSS-poengsum (som er Vanlig scoringssystem for sårbarheter), hvorfor blir folk begeistret for det?

Hvorfor skal den være HØY?

Og så svaret mitt var: "Hvorfor *burde* den ikke være HØY?"

Det er en feil i en kryptografisk motor; det kan krasje et program, for eksempel, som prøver å få en oppdatering... så det vil krasje om og om igjen og om igjen, noe som er litt mer enn bare et tjenestenekt, fordi det faktisk hindrer deg i å gjøre sikkerheten på riktig måte.

Det er et element av sikkerhetsbypass.

Og jeg tror den andre delen av svaret er, når det gjelder sårbarheter som blir omgjort til utnyttelser: "Aldri si aldri!"

Når du har noe sånt som et stackbufferoverflyt, hvor du kan manipulere andre variabler på stabelen, muligens inkludert minneadresser, vil det alltid være sjansen for at noen kan finne ut en brukbar utnyttelse.

Og problemet, Doug, er at når de først har funnet ut av det, spiller det ingen rolle hvor komplisert det var å finne ut av det...

…når du vet hvordan du utnytter det, kan *hvem som helst* gjøre det, fordi du kan selge dem koden for å gjøre det.

Jeg tror du vet hva jeg kommer til å si: "Ikke at jeg føler sterkt for det."

[LATTER]

Det er nok en gang en av de "fordømte hvis de gjør det, fordømte hvis de ikke gjør det".

---

DOUG.  Veldig bra, tusen takk, Svet, for at du skrev den kommentaren og sendte den inn.

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, jeg er Doug Aamoth, og minner deg på til neste gang om å...

---

BÅDE.  Hold deg trygg!