S3 Ep108: Du gemte TRE BILLIONER dollars i en popcorndåse?

Klik og træk på lydbølgerne nedenfor for at springe til ethvert punkt. Du kan også lytte direkte på Soundcloud.

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

Alt det og mere på Naked Security-podcasten.

[MUSIK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug.

Han er Paul Ducklin.

Paul, hvordan har du det i dag?

---

AND.  Godt, Doug.

Vi havde ikke måneformørkelsen her i England, men jeg fik et kort glimt af den *fulde* fuldmåne gennem et lille hul i skyerne, der dukkede op som det eneste hul i hele skylaget i det øjeblik, jeg gik udenfor for at tag et kig!

Men vi havde ikke den orange måne, som I havde i Massachusetts.

---

DOUG.  Lad os begynde showet med Denne uge i teknisk historie… det her går langt tilbage.

I denne uge, den 08. november 1895, faldt den tyske fysikprofessor Wilhelm Röntgen over en endnu uopdaget form for stråling, som fik ham til blot at henvise til denne stråling som "X".

Som ved røntgen.

Hvad med det... den utilsigtede opdagelse af røntgenstråler?

---

AND.  Helt fantastisk.

Jeg kan huske, at min mor fortalte mig: i 1950'erne (må have været det samme i USA), åbenbart i skobutikker...

---

DOUG.  [VED HVAD DER KOMMER] Ja! [griner]

---

AND.  Folk ville tage deres børn ind... du ville stå i denne maskine, tage skoene på og i stedet for bare at sige: "Gå rundt, er de stramme? Kniber de?”, stod du i en røntgenmaskine, som bare dybest set badede dig i røntgenstråling og tog et levende billede og sagde: “Åh ja, de har den rigtige størrelse.”

---

DOUG.  Ja, lettere tider. Lidt farligt, men...

---

AND.  LIDT FARLIG?

Kan du forestille dig de mennesker, der arbejdede i skobutikkerne?

De må have badet i røntgenbilleder hele tiden.

---

DOUG.  Absolut ... ja, vi er lidt mere sikre i dag.

Og med hensyn til sikkerhed er den første tirsdag i måneden Microsofts Patch Tuesday.

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

Udveksling 0-dage fast (endelig) – plus 4 helt nye Patch Tuesday 0-dage!

---

AND.  Nå, det superspændende, Doug, er, at Patch Tuesday teknisk set ikke fik en, ikke to, ikke tre ... men *fire* nul-dage.

Men faktisk fik de patches, du kunne få til Microsoft-produkter tirsdag, *seks* nul-dage.

Husk de Exchange nul-dage, der notorisk ikke blev rettet sidste Patch Tuesday: CVE-2002-41040 og CVE-2022-41082, hvad der blev kendt som ProxyNotShell?

S3 Ep102.5: "ProxyNotShell" Exchange-fejl – en ekspert taler [Lyd + tekst]

Nå, de blev rettet, men i det væsentlige i en separat "sidelinje" til Patch Tuesday: Exchange November 2022 SU eller Software Update, der bare siger:

November 2022 Exchange-softwareopdateringerne indeholder rettelser til nul-dages sårbarheder, der blev rapporteret offentligt den 29. september 2022.

Alt du skal gøre er at opgradere Exchange.

Ja tak, Microsoft... Jeg tror, ​​vi vidste, at det var det, vi skulle gøre, da patcherne endelig kom ud!

Så de *er* ude, og der er fastlagt to nul-dage, men de er ikke nye, og de er teknisk set ikke i "Patch Tuesday"-delen.

Der har vi fire andre nul-dage fast.

Og hvis du tror på at prioritere patches, så er det selvfølgelig dem, du vil beskæftige dig med først, fordi nogen allerede ved, hvordan man gør dårlige ting med dem.

Disse spænder fra en sikkerhedsbypass, til to elevations-of-privileges og en fjernudførelse af kode.

Men der er flere end 60 patches i alt, og hvis du ser på den overordnede liste over produkter og Windows-komponenter, der er berørt, er der som sædvanlig en enorm liste, der omfatter hver eneste Windows-komponent/-produkt, du har hørt om, og mange, du sandsynligvis ikke har.

Microsoft retter 62 sårbarheder, inklusive Kerberos og Mark of the Web, og Exchange ... en slags

Så som altid: Udsæt ikke/gør det i dag, Douglas!

---

DOUG.  Meget godt.

Lad os nu tale om en temmelig forsinkelse...

Du har en meget interessant historie om Silk Road stofmarked, og en påmindelse om, at kriminelle stjæler fra kriminelle stadig er en forbrydelse, selvom det er omkring ti år senere, at du rent faktisk bliver taget for det.

Silk Road narkotikamarked hacker erkender sig skyldig, står over for 20 år inde

---

AND.  Ja, selv folk, der er ret nye til cybersikkerhed eller til at gå online, vil sandsynligvis have hørt om "Silk Road", måske den første velkendte, store, udbredte, meget brugte dark web-markedsplads, hvor stort set alt går.

Så det hele gik op i flammer i 2013.

Fordi grundlæggeren, oprindeligt kun kendt som Frygtede pirat Roberts, men i sidste ende afsløret at være Ross Ulbricht… hans dårlige driftssikkerhed var nok til at knytte aktiviteterne til ham.

Silk Road-grundlæggeren Ross Ulbricht får livstid uden prøveløsladelse

Ikke alene var hans operationelle sikkerhed ikke særlig god, det ser ud til, at de i slutningen af ​​2012 havde (kan du tro det, Doug?) en cryptocurrency betalingsbehandlingsbommerte...

---

DOUG.  [GISPPER I MOK HROR]

---

AND.  … af den type, som vi har set gentaget mange gange siden, der gik rundt og ikke helt lavede ordentligt dobbelt bogholderi, hvor der for hver debitering er en tilsvarende kredit og omvendt.

Og denne angriber opdagede, hvis du satte nogle penge ind på din konto og derefter meget hurtigt udbetalte dem til andre konti, at du faktisk kunne udbetale fem gange (eller endda mere) de samme bitcoins, før systemet indså, at den første debitering var gået. igennem.

Så du kan dybest set lægge nogle penge ind og så bare hæve dem igen og igen og igen og få et større gemmer...

…og så kunne du gå tilbage til, hvad du kunne kalde en "malkeløkke for kryptovaluta".

Og det anslås… efterforskerne var ikke sikre på, at han startede med mellem 200 og 2000 egne bitcoins (om han købte dem eller mine dem, ved vi ikke), og han omsatte dem meget, meget hurtigt til, vent på det, Doug: 50,0000 bitcoins!

---

DOUG.  Wow!

---

AND.  Mere end 50,000 bitcoins, bare sådan.

Og så, da han åbenbart regnede med, at nogen ville lægge mærke til det, skar han og løb, mens han var foran med 50,000 bitcoins...

…hver værd en fantastisk $12, op fra brøkdele af en cent blot et par år før. [griner]

Så han klarede sig med $600,000, bare sådan, Doug.

[DRAMATISK PAUSE]

Ni år senere…

[LATTER]

...næsten *præcis* ni år senere, da han blev bustet og hans hjem blev overfaldet under en kendelse, gik politiet på jagt og fandt en bunke tæpper i hans skab, hvorunder der var gemt en popcorndåse.

Mærkeligt sted at opbevare dine popcorn.

Indeni som var en slags computerstyret kold pung.

Indeni som var en stor del af de nævnte bitcoins!

På det tidspunkt, hvor han blev slået, var bitcoins noget nord for $65,535 (eller 2¹⁶-1) hver.

De var steget langt over tusind gange i mellemtiden.

Så på det tidspunkt var det den største kryptomøntbuste nogensinde!

Ni år senere, efter at have tilsyneladende ikke været i stand til at disponere over sine dårligt opnåede gevinster, måske bange for, at selvom han prøvede at skubbe dem i en tumbler, ville alle fingre pege tilbage mod ham...

…han har haft alle disse $3 milliarder bitcoins, der har ligget i en popcorndåse i ni år!

---

DOUG.  Du godeste.

---

AND.  Så efter at have siddet på denne skræmmende skat i alle de år og spekuleret på, om han ville blive fanget, undrer han sig nu: "Hvor længe skal jeg i fængsel?"

Og den maksimale straf for den anklage, han står over for?

20 år, Doug.

---

DOUG.  Endnu en interessant historie foregår lige nu. Hvis du har været på Twitter for nylig, vil du vide, at der er meget aktivitet. at sige det diplomatisk...

---

AND.  [LAV-TIL-MIDDELKVALITET BOB DYLAN IMPERSONATION] Nå, tiderne ændrer sig.

---

DOUG.  …herunder på et tidspunkt ideen om at opkræve $20 for en verificeret blå check, hvilket selvfølgelig næsten øjeblikkeligt medførte nogle svindelnumre.

Twitter Blue Badge e-mail-svindel – fald ikke for dem!

---

AND.  Det er bare en påmindelse, Doug, om, at når der er noget, der har tiltrukket sig stor interesse, vil skurkene helt sikkert følge efter.

Og præmissen for dette var: "Hey, hvorfor ikke komme tidligt ind? Hvis du allerede har et blåt mærke, gæt hvad? Du behøver ikke betale $19.99 om måneden, hvis du forhåndstilmelder dig. Vi lader dig beholde den."

Vi ved, at det ikke var Elon Musks idé, som han sagde det, men det er den slags ting, som mange virksomheder gør, ikke?

Masser af virksomheder vil give dig en form for fordel, hvis du bliver hos tjenesten.

Så det er ikke helt utroligt.

Som du siger... hvad gav du den?

B-minus, var det?

---

DOUG.  Jeg giver den indledende e-mail et B-minus... du kunne måske blive narret, hvis du læser den hurtigt, men der er nogle grammatikproblemer; ting føles ikke rigtigt.

Og når du først har klikket videre, vil jeg give landingssiderne C-minus.

Det bliver endnu sværere.

---

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

---

DOUG.  Ja, lad os sige det.

Og vi har nogle råd, så selvom det er en A-plus fidus, vil det ikke være ligegyldigt, fordi du vil være i stand til at forpurre det alligevel!

Starter med min personlige favorit: Brug en adgangskodeadministrator.

En password manager løser en masse problemer, når det kommer til svindel.

---

AND.  Det gør det.

En adgangskodemanager har ikke nogen menneskelignende intelligens, der kan vildledes af, at det smukke billede er rigtigt, eller logoet er perfekt, eller at webformularen er i den helt rigtige position på skærmen med nøjagtig den samme skrifttype , så du genkender det.

Alt det ved er: "Aldrig hørt om dette websted før."

---

DOUG.  Og selvfølgelig, tænd for 2FA, hvis du kan.

Tilføj altid en anden godkendelsesfaktor, hvis det er muligt.

---

AND.  Det beskytter dig selvfølgelig ikke nødvendigvis mod dig selv.

Hvis du går til et falsk websted, og du har besluttet, "Hey, det er pixel-perfekt, det må være den rigtige vare", og du er fast besluttet på at logge ind, og du har allerede indtastet dit brugernavn og din adgangskode, og så beder den dig om at gennemgå 2FA-processen...

… det er sandsynligt, at du gør det.

Det giver dig dog lidt tid til at gøre "Stop. Tænke. Forbinde." ting, og sig til dig selv: "Vent, hvad laver jeg her?"

Så på en måde kan den lille smule forsinkelse, som 2FA introducerer, faktisk ikke kun være meget lidt besvær, men også en måde at forbedre din cybersikkerhedsarbejdsgang på... ved at introducere lige nok af et hastighedsbump, så du er tilbøjelig til at tage cybersikkerhed lidt mere seriøst.

Så jeg kan ikke se, hvad ulempen egentlig er.

---

DOUG.  Og selvfølgelig er en anden strategi, som er svær for mange mennesker at overholde, men som er meget effektiv, at undgå login-links og handlingsknapper i e-mail.

Så hvis du får en e-mail, skal du ikke bare klikke på knappen ... gå til selve webstedet, og du vil ret hurtigt kunne se, om den e-mail var lovlig eller ej.

---

AND.  Dybest set, hvis du ikke helt kan stole på den indledende korrespondance, så kan du ikke stole på nogen detaljer i den, uanset om det er det link, du vil klikke på, det telefonnummer, du vil ringe til, den e-mailadresse, du vil kontakte dem på Instagram-kontoen, du vil sende DM'er til, hvad end det er.

Brug ikke det, der er i e-mailen... find din egen vej dertil, og du vil kortslutte en masse svindel af denne slags.

---

DOUG.  Og endelig, sidst men ikke mindst... det burde være sund fornuft, men det er ikke: Spørg aldrig afsenderen af ​​en usikker besked, om den er legitim.

Svar ikke og sig: "Hey, er du virkelig Twitter?"

---

AND.  Ja, du har helt ret.

Fordi mit tidligere råd, "Lad være med at stole på oplysningerne i e-mailen", såsom ikke at ringe til deres telefonnummer... nogle mennesker er fristet til at gå, "Nå, jeg ringer til telefonnummeret og ser, om det virkelig er er dem. [IRONISK] Fordi selvfølgelig, hvis kokkens svar, vil de give deres rigtige navne."

---

DOUG.  Som vi altid siger: Hvis du er i tvivl/giv det ikke.

Og dette er en god advarselshistorie, denne næste historie: når sikkerhedsscanninger, som er legitime sikkerhedsværktøjer, afsløre mere, end de burde, hvad sker der så?

Offentlige URL-scanningsværktøjer – når sikkerhed fører til usikkerhed

---

AND.  Dette er en velkendt forsker ved navn Fabian Bräunlein i Tyskland ... vi har vist ham et par gange før.

Han er tilbage med en detaljeret rapport med titlen urlscan.io's SOAR spot: chatty sikkerhedsværktøjer, der lækker private data.

Og i dette tilfælde er det urlscan.io, et websted, som du kan bruge gratis (eller som en betalt tjeneste), hvor du kan indsende en URL, eller et domænenavn, eller et IP-nummer, eller hvad det nu er, og du kan slå op, "Hvad ved samfundet om dette?"

Og det vil afsløre den fulde URL, som andre mennesker spurgte om.

Og det er ikke kun ting, som folk kopierer og indsætter efter eget valg.

Nogle gange kan deres e-mail f.eks. gå gennem et tredjepartsfiltreringsværktøj, der selv udtrækker URL'er, ringer hjem til urlscan.io, foretager søgningen, henter resultatet og bruger det til at beslutte, om meddelelsen skal junke, spammes eller sendes igennem.

Og det betyder, at nogle gange, hvis URL'en indeholdt hemmelige eller halvhemmelige data, personligt identificerbare oplysninger, så ville andre personer, der tilfældigvis søgte efter det rigtige domænenavn inden for en kort periode efter, se alle de URL'er, der blev søgt efter, inkl. ting, der kan være i URL'en.

Du ved, sådan blahblah?username=doug&passwordresetcode= efterfulgt af en lang streng hexadecimale tegn, og så videre.

Og Bräunlein kom op med en fascinerende liste over den slags URL'er, især dem, der kan forekomme i e-mails, som rutinemæssigt kan blive sendt til en tredjepart til filtrering og derefter blive indekseret til søgning.

Den slags e-mails, som han regnede med, kunne helt sikkert udnyttes inkluderet, men var ikke begrænset til: links til oprettelse af konto; Amazon gave levering links; API nøgler; DocuSign signeringsanmodninger; dropbox filoverførsler; pakke sporing; nulstilling af adgangskode; PayPal-fakturaer; Google Drev-dokumentdeling; SharePoint-invitationer; og links til afmelding af nyhedsbrev.

Ikke at pege fingre til SharePoint, Google Drive, PayPal osv.

Det var blot eksempler på URL'er, som han stødte på, som potentielt kunne udnyttes på denne måde.

---

DOUG.  Vi har nogle råd i slutningen af ​​den artikel, som koger ned til: læs Bräunleins rapport; Læs urlscan.io's blogindlæg; lav din egen kodegennemgang; hvis du har kode, der foretager online sikkerhedsopslag; lære, hvilke privatlivsfunktioner der findes for onlineindsendelser; og vigtigst af alt, lær hvordan du rapporterer useriøse data til en onlinetjeneste, hvis du ser dem.

Jeg har bemærket, at der er tre... slags limericks?

Meget kreative minidigte i slutningen af ​​denne artikel...

---

AND.  [HORROR] Nej, de er ikke limericks! Limericks har en meget formel fem-line struktur...

---

DOUG.  Jeg er så ked af det. Det er rigtigt!

---

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

Meget struktureret, Doug!

---

DOUG.  Jeg er så ked af det, så sandt. [griner]

---

AND.  Det her er bare doggerel. [LATTER]

Endnu engang: Hvis du er i tvivl/giv det ikke.

Og hvis du indsamler data: Hvis det ikke skulle være i/stik det lige i skraldespanden.

Og hvis du skriver kode, der kalder offentlige API'er, der kan afsløre kundedata: Få aldrig dine brugere til at græde/Ved hvordan du kalder API.

---

DOUG.  [GRNER] Det er en ny for mig, og den kan jeg meget godt lide!

Og sidst, men bestemt ikke mindst på vores liste her, har vi uge efter uge talt om denne OpenSSL sikkerhedsfejl.

Det store spørgsmål er nu, "Hvordan kan du fortælle hvad skal rettes?"

Historien om OpenSSL-sikkerhedsopdatering – hvordan kan du fortælle, hvad der skal rettes?

---

AND.  Ja, Doug, hvordan ved vi, hvilken version af OpenSSL vi har?

Og selvfølgelig åbner du bare en kommandoprompt på Linux og skriver openssl version, og den fortæller dig, hvilken version du har.

Men OpenSSL er et programmeringsbibliotek, og der er ingen regel, der siger, at software ikke kan have sin egen version.

Din distro bruger måske OpenSSL 3.0, og alligevel er der en app, der siger: "Åh, nej, vi har ikke opgraderet til den nye version. Vi foretrækker OpenSSL 1.1.1, fordi det stadig understøttes, og hvis du ikke har det, bringer vi vores egen version."

Og så var du desværre, ligesom i den berygtede Log4Shell-sag, nødt til at lede efter de tre? 12? 154? hvem-ved-hvor mange steder på dit netværk, hvor du måske har et forældet Log4J-program.

Samme for OpenSSL.

I teorien kan XDR- eller EDR-værktøjer måske fortælle dig det, men nogle vil ikke understøtte dette, og mange vil fraråde det: faktisk køre programmet for at finde ud af, hvilken version det er.

For når alt kommer til alt, hvis det er buggyen eller den forkerte, og du faktisk skal køre programmet for at få det til at rapportere sin egen version...

…det føles som at sætte vognen foran hesten, ikke?

Så vi udgav en artikel for de specielle tilfælde, hvor du rent faktisk ønsker at indlæse DLL'en eller det delte bibliotek, og du faktisk ønsker at kalde sin egen TellMeThyVersion() software kode.

Med andre ord, du stoler nok på programmet til at du vil indlæse i hukommelsen, udføre det og køre en komponent af det.

Vi viser dig, hvordan du gør det, så du kan være helt sikker på, at eventuelle afsidesliggende OpenSSL-filer, som du har på dit netværk, er opdaterede.

For selvom dette blev nedgraderet fra KRITISK til HØJ, er det stadig en fejl, som du skal og vil rette!

---

DOUG.  Med hensyn til sværhedsgraden af ​​denne fejl fik vi en interessant spørgsmål fra den nøgen sikkerhedslæser Svet, som til dels skriver:

Hvordan kan det være, at en fejl, der er enormt kompleks til udnyttelse og kun kan bruges til lammelsesangreb, bliver ved med at blive klassificeret som HØJ?

---

AND.  Ja, jeg tror, ​​han sagde noget om, "Åh, har OpenSL-teamet ikke hørt om CVSS?", som er en amerikansk regeringsstandard, hvis du vil, for kodning af risiko- og kompleksitetsniveauet for fejl på en måde, der kan automatisk filtreret af scripts.

Så hvis det har en lav CVSS-score (som er Almindeligt scoringssystem for sårbarheder), hvorfor bliver folk begejstrede for det?

Hvorfor skal den være HØJ?

Og så var mit svar: "Hvorfor *burde* det ikke være HØJT?"

Det er en fejl i en kryptografisk motor; det kunne crashe et program, for eksempel, der forsøger at få en opdatering... så det vil gå ned igen og igen og igen, hvilket er lidt mere end blot et lammelsesangreb, fordi det faktisk forhindrer dig i at gøre din sikkerhed ordentligt.

Der er et element af sikkerhedsbypass.

Og jeg tror, ​​at den anden del af svaret er, når det kommer til sårbarheder, der bliver forvandlet til udnyttelser: "Sig aldrig aldrig!"

Når du har noget som et stackbufferoverløb, hvor du kan manipulere andre variabler på stakken, muligvis inklusive hukommelsesadresser, vil der altid være en chance for, at nogen kan finde ud af en brugbar udnyttelse.

Og problemet, Doug, er, at når de først har fundet ud af det, er det lige meget hvor kompliceret det var at finde ud af det...

…når du ved, hvordan man udnytter det, kan *enhver* gøre det, fordi du kan sælge dem koden til at gøre det.

Jeg tror, ​​du ved, hvad jeg vil sige: "Ikke at jeg føler stærkt for det."

[LATTER]

Det er igen en af ​​de "forbandede, hvis de gør, forbandede, hvis de ikke gør det".

---

DOUG.  Meget godt, mange tak, Svet, fordi du skrev den kommentar og sendte den ind.

Hvis du har en interessant historie, kommentar eller spørgsmål, du gerne vil indsende, vil vi meget gerne læse den 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.  Hold dig sikker!