Klicka och dra på ljudvågorna nedan för att hoppa till valfri punkt. Du kan också lyssna direkt på Soundcloud.

DOUG.  Twitter-bedrägerier, Patch Tuesday och brottslingar som hackar brottslingar.

Allt det och mer i podcasten Naked Security.

[MUSIKALT MODEM]

Välkommen till podden, alla.

Jag är Doug.

Han är Paul Ducklin.

Paul, hur mår du idag?

ANKA.  Mycket bra, Doug.

Vi hade inte månförmörkelsen här i England, men jag fick en kort glimt av den *fulla* fullmånen genom en liten lucka i molnen som dök upp som det enda hålet i hela molnlagret när jag gick ut för att ta en titt!

Men vi hade inte den där orangea månen som ni hade i Massachusetts.

DOUG.  Låt oss börja föreställningen med Denna vecka i teknisk historia… det här går långt tillbaka.

Denna vecka, den 08 november 1895, snubblade den tyske fysikprofessorn Wilhelm Röntgen över en ännu oupptäckt form av strålning som fick honom att referera till denna strålning helt enkelt som "X".

Som vid röntgen.

Vad sägs om det... den oavsiktliga upptäckten av röntgenstrålar?

ANKA.  Ganska fantastiskt.

Jag minns att min mamma sa till mig: på 1950-talet (måste ha varit samma sak i USA), tydligen i skoaffärer...

DOUG.  [VET VAD KOMMER] Ja! [skrattar]

ANKA.  Folk skulle ta in sina barn... du skulle stå i den här maskinen, ta på dig skorna och istället för att bara säga: "Gå runt, är de tighta? Nyper de?”, stod du i en röntgenapparat, som helt enkelt badade dig i röntgenstrålning och tog ett livefoto och sa: ”Åh ja, de har rätt storlek.”

DOUG.  Ja, enklare tider. Lite farligt, men...

ANKA.  LITE FARLIGT?

Kan du föreställa dig människorna som arbetade i skoaffärerna?

De måste ha badat i röntgen hela tiden.

DOUG.  Absolut... ja, vi är lite säkrare idag.

Och när det gäller säkerhet är den första tisdagen i månaden Microsofts Patch Tuesday.

So vad lärde vi oss denna patchtisdag här i november 2022?

Byt 0-dagar fast (äntligen) – plus 4 helt nya Patch Tisdag 0-dagar!

ANKA.  Tja, det superspännande, Doug, är att tekniskt sett fixade Patch Tuesday inte en, inte två, inte tre... utan *fyra* nolldagar.

Men de patchar du kunde få för Microsoft-produkter i tisdags fixade faktiskt *sex* nolldagar.

Kom ihåg de Exchange zero-days som notoriskt inte patchades förra patchtisdagen: CVE-2002-41040 och CVE-2022-41082, vad som blev känt som ProxyNotShell?

S3 Ep102.5: "ProxyNotShell" Exchange buggar – en expert talar [Ljud + Text]

Tja, de fixades, men i huvudsak en separat "sidelinje" till Patch Tuesday: Exchange November 2022 SU, eller Software Update, som bara säger:

November 2022 Exchange Software Updates innehåller korrigeringar för nolldagars sårbarheter som rapporterades offentligt den 29 september 2022.

Allt du behöver göra är att uppgradera Exchange.

Jösses, tack Microsoft... Jag tror att vi visste att det var vad vi skulle behöva göra när patcharna äntligen kom ut!

Så, de *är* ute och det är två nolldagar fasta, men de är inte nya, och de är inte tekniskt sett i "Patch Tuesday"-delen.

Där har vi fyra andra nolldagar fasta.

Och om du tror på att prioritera patchar, så är det uppenbarligen de du vill ta itu med först, eftersom någon redan vet hur man gör dåliga saker med dem.

Dessa sträcker sig från en säkerhetsbypass, till två privilegiehöjningar och en fjärrkörning av kod.

Men det finns fler än 60 patchar totalt, och om du tittar på den övergripande listan över produkter och Windows-komponenter som påverkas, finns det en enorm lista, som vanligt, som tar in varje Windows-komponent/produkt du har hört talas om, och många som du förmodligen inte har.

Microsoft korrigerar 62 sårbarheter, inklusive Kerberos och Mark of the Web, och Exchange...

Så som alltid: Dröj inte/gör det idag, Douglas!

DOUG.  Mycket bra.

Låt oss nu tala om en ganska lång försening...

Du har en mycket intressant historia om Silk Road drogmarknad, och en påminnelse om att brottslingar som stjäl från kriminella fortfarande är ett brott, även om det är några tio år senare som man faktiskt åker fast för det.

Silk Road drogmarknadshacker erkänner sig skyldig, står inför 20 år inne

ANKA.  Ja, även människor som är ganska nya inom cybersäkerhet eller att gå online kommer förmodligen att ha hört talas om "Silk Road", kanske den första välkända, stora, utbredda, allmänt använda mörka webbmarknadsplatsen där i princip allt går.

Så allt gick upp i lågor 2013.

Eftersom grundaren, ursprungligen bara känd som Fruktansvärda piraten Roberts, men i slutändan visade sig vara Ross Ulbricht… hans dåliga driftsäkerhet räckte för att knyta verksamheten till honom.

Silk Road-grundaren Ross Ulbricht får livstid utan villkorlig frigivning

Inte nog med att hans operativa säkerhet inte var särskilt bra, det verkar som att de i slutet av 2012 hade (kan du tro det, Doug?) en betalningsbearbetningsmiss i kryptovaluta...

DOUG.  [GIFTAR I LÅT SKÄCK]

ANKA.  …av den typ som vi har sett upprepas många gånger sedan, som gick runt och inte riktigt gjorde ordentlig dubbel bokföring, där det för varje debitering finns en motsvarande kredit och vice versa.

Och den här angriparen upptäckte, om du satte in några pengar på ditt konto och sedan mycket snabbt betalade ut dem till andra konton, att du faktiskt kunde betala ut fem gånger (eller till och med mer) samma bitcoins innan systemet insåg att den första debiteringen hade gått genom.

Så du kan i princip lägga in lite pengar och sedan bara ta ut dem om och om och om igen och få ett större lager...

...och sedan kan du gå tillbaka till vad du kan kalla en "mjölkslinga för kryptovaluta".

Och det uppskattas... utredarna var inte säkra på att han började med mellan 200 och 2000 egna bitcoins (om han köpte dem eller bryta dem vet vi inte), och han omvandlade dem mycket, mycket snabbt till, vänta på det, Doug: 50,0000 XNUMX bitcoins!

DOUG.  Wow!

ANKA.  Mer än 50,000 XNUMX bitcoins, bara sådär.

Och sedan, då han uppenbarligen anade att någon skulle lägga märke till, klippte han och sprang medan han var före med 50,000 XNUMX bitcoins...

...var och en värd fantastiska $12, upp från bråkdelar av en cent bara några år tidigare. [skrattar]

Så han klarade sig med $600,000 XNUMX, precis som det, Doug.

[DRAMATISK PAUSE]

Nio år senare...

[SKRATT]

...nästan *exakt* nio år senare, när han blev slagen och hans hem plundrades under en order, gick polisen och letade och hittade en hög med filtar i hans garderob, under vilken det gömde sig en popcornburk.

Konstig plats att förvara dina popcorn.

Inuti som var en slags datoriserad kall plånbok.

Inuti som fanns en stor andel av nämnda bitcoins!

När han togs var bitcoins något norr om $65,535 2 (eller XNUMX¹⁶-1) vardera.

De hade gått upp en bra bit över tusen gånger under tiden.

Så vid den tiden var det den största kryptomyntbysten någonsin!

Nio år senare, efter att ha uppenbarligen inte kunnat göra sig av med sina illa förvärvade vinster, kanske rädd att även om han försökte trycka in dem i en tumlare, skulle alla fingrar peka tillbaka mot honom...

…han har haft alla dessa 3 miljarder dollar i bitcoins som har legat i en popcornburk i nio år!

DOUG.  Herregud.

ANKA.  Så efter att ha suttit på den här läskiga skatten i alla dessa år och undrat om han skulle åka fast, undrar han nu: "Hur länge ska jag sitta i fängelse?"

Och maxstraffet för åtalet som han står inför?

20 år, Doug.

DOUG.  Ännu en intressant historia på gång just nu. Om du har varit på Twitter på sistone kommer du att veta att det är mycket aktivitet. att säga det diplomatiskt...

ANKA.  [LÅG TILL MEDELKVALITET BOB DYLAN IMPERSONATION] Tja, tiderna förändras.

DOUG.  ...inklusive vid ett tillfälle idén att ta ut $20 för en verifierad blå check, vilket naturligtvis nästan omedelbart föranledde några bedrägerier.

Twitter Blue Badge e-postbedrägerier – fall inte för dem!

ANKA.  Det är bara en påminnelse, Doug, att när det är något som har väckt stort intresse kommer skurkarna säkert att följa efter.

Och utgångspunkten för detta var: "Hej, varför inte komma in tidigt? Om du redan har ett blått märke, gissa vad? Du behöver inte betala 19.99 USD i månaden om du förregistrerar dig. Vi låter dig behålla den."

Vi vet att det inte var Elon Musks idé, som han sa det, men det är sånt som många företag gör, eller hur?

Många företag kommer att ge dig någon form av fördel om du stannar kvar med tjänsten.

Så det är inte helt otroligt.

Som du säger... vad gav du den?

B-minus, var det?

DOUG.  Jag ger det första e-postmeddelandet ett B-minus... du kan kanske bli lurad om du läser det snabbt, men det finns några grammatikproblem; saker känns inte rätt.

Och sedan när du klickar dig igenom, skulle jag ge målsidorna C-minus.

Det blir ännu svårare.

ANKA.  Det är någonstans mellan 5/10 och 6/10?

DOUG.  Ja, låt oss säga det.

Och vi har några råd, så att även om det är en A-plus-bedrägeri så spelar det ingen roll eftersom du kommer att kunna omintetgöra det ändå!

Börjar med min personliga favorit: Använd en lösenordshanterare.

En lösenordshanterare löser många problem när det kommer till bedrägerier.

ANKA.  Det gör det.

En lösenordshanterare har ingen mänsklig intelligens som kan vilseledas av att den vackra bilden är rätt, eller att logotypen är perfekt eller att webbformuläret är i exakt rätt position på skärmen med exakt samma typsnitt , så du känner igen det.

Allt den vet är: "Aldrig hört talas om den här webbplatsen förut."

DOUG.  Och naturligtvis, slå på 2FA om du kan.

Lägg alltid till en andra autentiseringsfaktor om möjligt.

ANKA.  Naturligtvis skyddar det dig inte nödvändigtvis från dig själv.

Om du går till en falsk sida och du har bestämt dig, "Hej, den är pixel-perfekt, det måste vara den verkliga affären", och du är fast besluten att logga in och du har redan skrivit in ditt användarnamn och ditt lösenord, och sedan ber den dig att gå igenom 2FA-processen...

...det är mycket troligt att du gör det.

Det ger dig dock lite tid att göra "Stopp. Tror. Ansluta." sak och säg till dig själv, "Vänta på, vad gör jag här?"

Så på ett sätt kan den lilla fördröjningen som 2FA introducerar faktiskt inte bara vara väldigt lite krångel, utan också ett sätt att faktiskt förbättra ditt cybersäkerhetsarbetsflöde ... genom att introducera precis tillräckligt mycket fartgupp som du är benägen att ta cybersäkerhet lite mer seriöst.

Så jag ser inte vad nackdelen är egentligen.

DOUG.  Och naturligtvis, en annan strategi som är svår för många människor att följa, men som är mycket effektiv, är att undvik inloggningslänkar och åtgärdsknappar i e-post.

Så om du får ett e-postmeddelande, klicka inte bara på knappen ... gå till själva webbplatsen och du kommer att kunna avgöra ganska snabbt om det e-postmeddelandet var legitimt eller inte.

ANKA.  I grund och botten, om du inte helt kan lita på den första korrespondensen, kan du inte lita på några detaljer i den, oavsett om det är länken du ska klicka på, telefonnumret du ska ringa, e-postadressen du ska klicka på. kommer att kontakta dem på , Instagram-kontot du ska skicka DM till, vad det än är.

Använd inte det som finns i e-postmeddelandet... hitta din egen väg dit, så kommer du att kortsluta många bedrägerier av det här slaget.

DOUG.  Och slutligen, sist men inte minst... det här borde vara sunt förnuft, men det är inte: Fråga aldrig avsändaren av ett osäkert meddelande om det är legitimt.

Svara inte och säg: "Hej, är du verkligen Twitter?"

ANKA.  Ja, du har helt rätt.

Eftersom mitt tidigare råd, "lita inte på informationen i e-postmeddelandet", som att inte ringa deras telefonnummer... vissa människor är frestade att säga, "ja, jag ska ringa telefonnumret och se om det verkligen är är dem. [IRONISK] För, uppenbarligen, om kockens svar kommer de att ge sina riktiga namn.”

DOUG.  Som vi alltid säger: Om du är osäker/Ge inte ut det.

Och det här är en bra varnande berättelse, nästa historia: när säkerhetsskanningar, som är legitima säkerhetsverktyg, avslöja mer än de borde, vad händer då?

Verktyg för genomsökning av offentliga webbadresser – när säkerhet leder till osäkerhet

ANKA.  Det här är en välkänd forskare vid namn Fabian Bräunlein i Tyskland... vi har visat honom ett par gånger tidigare.

Han är tillbaka med en detaljerad rapport med titeln urlscan.ios SOAR-plats: chattiga säkerhetsverktyg som läcker privata data.

Och i det här fallet är det så urlscan.io, en webbplats som du kan använda gratis (eller som en betaltjänst) där du kan skicka in en URL, eller ett domännamn, eller ett IP-nummer, eller vad det nu är, och du kan slå upp, "Vad vet samhället om detta?"

Och det kommer att avslöja hela webbadressen som andra människor frågade om.

Och det här är inte bara saker som folk kopierar och klistrar efter eget val.

Ibland kan deras e-post, till exempel, gå igenom ett filterverktyg från tredje part som själv extraherar webbadresser, ringer hem till urlscan.io, gör sökningen, hämtar resultatet och använder det för att avgöra om meddelandet ska skräpas, spammas eller skickas igenom.

Och det betyder att ibland, om webbadressen inkluderade hemlig eller halvhemlig data, personligt identifierbar information, så skulle andra personer som bara råkade söka efter rätt domännamn inom en kort period efteråt se alla webbadresser som man sökte efter, inklusive saker som kan finnas i URL:en.

Du vet, liksom blahblah?username=doug&passwordresetcode= följt av en lång sträng hexadecimala tecken, och så vidare.

Och Bräunlein kom med en fascinerande lista över den typ av webbadresser, särskilt sådana som kan visas i e-postmeddelanden, som rutinmässigt kan skickas till en tredje part för filtrering och sedan indexeras för sökning.

Den typ av e-postmeddelanden som han ansåg var definitivt exploaterbara inkluderade, men var inte begränsade till: länkar för att skapa konto; Amazon presentleveranslänkar; API-nycklar; DocuSign-signeringsförfrågningar; Dropbox-filöverföringar; paketspårning; lösenordsåterställningar; PayPal-fakturor; Google Drive dokumentdelning; SharePoint-inbjudningar; och länkar för att avsluta prenumerationen för nyhetsbrev.

Att inte peka fingrar där på SharePoint, Google Drive, PayPal, etc.

Det var bara exempel på webbadresser som han stötte på som kunde utnyttjas på detta sätt.

DOUG.  Vi har några råd i slutet av den artikeln, som kokar ner till: läs Bräunleins rapport; läsa urlscan.ios blogginlägg; gör en egen kodgranskning; om du har kod som gör säkerhetssökningar online; lära dig vilka sekretessfunktioner som finns för onlineinlämningar; och, viktigare, lär dig hur du rapporterar oseriösa data till en onlinetjänst om du ser den.

Jag märkte att det finns tre... slags limericks?

Mycket kreativa minidikter i slutet av denna artikel...

ANKA.  Nej, de är inte limericks! Limericks har en mycket formell femradsstruktur...

DOUG.  [SKratt] Jag är så ledsen. Det är sant!

ANKA.  ...för både meter och rim.

Mycket strukturerad, Doug!

DOUG.  Jag är så ledsen, så sant. [skrattar]

ANKA.  Det här är bara doggerel. [SKRATT]

Ännu en gång: Om du är osäker/Ge inte ut det.

Och om du samlar in data: Om den inte skulle vara i/Stick den rakt i soptunnan.

Och om du skriver kod som anropar offentliga API:er som kan avslöja kunddata: Få aldrig dina användare att gråta/av hur du kallar API:et.

DOUG.  [SKratt] Det är en ny för mig, och jag gillar den väldigt mycket!

Och sist, men absolut inte minst på vår lista här, har vi pratat vecka efter vecka om denna OpenSSL-säkerhetsbugg.

Den stora frågan nu är "Hur kan du avgöra vad behöver fixas?"

Berättelsen om OpenSSL-säkerhetsuppdatering – hur kan du berätta vad som behöver åtgärdas?

ANKA.  Ja, Doug, hur vet vi vilken version av OpenSSL vi har?

Och självklart, på Linux, öppnar du bara en kommandotolk och skriver openssl version, och den berättar vilken version du har.

Men OpenSSL är ett programmeringsbibliotek, och det finns ingen regel som säger att programvara inte kan ha sin egen version.

Din distro kanske använder OpenSSL 3.0, och ändå finns det en app som säger: "Åh, nej, vi har inte uppgraderat till den nya versionen. Vi föredrar OpenSSL 1.1.1, eftersom det fortfarande stöds, och om du inte har det, tar vi med vår egen version."

Och så, tyvärr, precis som i det där ökända Log4Shell-fallet, var du tvungen att leta efter de tre? 12? 154? vem-vet-hur-många ställen i ditt nätverk där du kanske har ett föråldrat Log4J-program.

Samma sak för OpenSSL.

I teorin kanske XDR- eller EDR-verktyg kan berätta för dig, men vissa kommer inte att stödja detta och många kommer att avråda från det: att faktiskt köra programmet för att ta reda på vilken version det är.

För trots allt, om det är buggy eller fel, och du faktiskt måste köra programmet för att få det att rapportera sin egen version...

…det känns som att sätta vagnen framför hästen, eller hur?

Så vi publicerade en artikel för de speciella fall där du faktiskt vill ladda DLL eller det delade biblioteket och du faktiskt vill anropa sitt eget TellMeThyVersion() mjukvarukod.

Med andra ord, du litar tillräckligt på programmet för att du ska ladda in i minnet, köra det och köra någon komponent av det.

Vi visar dig hur du gör det så att du kan vara helt säker på att eventuella externa OpenSSL-filer som du har på ditt nätverk är uppdaterade.

För även om detta nedgraderades från KRITISKT till HÖGT så är det fortfarande en bugg som du måste och vill fixa!

DOUG.  När det gäller svårighetsgraden av denna bugg fick vi en intressant fråga från den nakna säkerhetsläsaren Svet, som delvis skriver:

Hur kommer det sig att en bugg som är enormt komplex för exploatering, och som bara kan användas för överbelastningsattacker, fortsätter att klassas som HÖG?

ANKA.  Ja, jag tror att han sa något om "Åh, har inte OpenSL-teamet hört talas om CVSS?", som är en amerikansk regeringsstandard, om du vill, för att koda risk- och komplexitetsnivån för buggar på ett sätt som kan vara filtreras automatiskt av skript.

Så om det har ett lågt CVSS-poäng (vilket är Gemensamma poängsystem för sårbarhet), varför blir folk upphetsade över det?

Varför ska det vara HÖGT?

Och så mitt svar var: "Varför *ska* det inte vara HÖGT?"

Det är en bugg i en kryptografisk motor; det kan krascha ett program, säg, som försöker få en uppdatering... så det kommer att krascha om och om och om igen, vilket är lite mer än bara ett överbelastningsskydd, eftersom det faktiskt hindrar dig från att göra din säkerhet ordentligt.

Det finns ett element av säkerhetsbypass.

Och jag tror att den andra delen av svaret är, när det kommer till att sårbarheter förvandlas till utnyttjande: "Säg aldrig aldrig!"

När du har något som ett stackbuffertspill, där du kan manipulera andra variabler på stacken, eventuellt inklusive minnesadresser, kommer det alltid att finnas en chans att någon kan komma på en fungerande exploatering.

Och problemet, Doug, är att när de väl har listat ut det spelar det ingen roll hur komplicerat det var att ta reda på det...

…när du vet hur man utnyttjar det kan *vem som helst* göra det, eftersom du kan sälja dem koden för att göra det.

Jag tror att du vet vad jag kommer att säga: "Inte för att jag känner starkt för det."

[SKRATT]

Det är återigen en av dessa "förbannade om de gör det, förbannade om de inte gör det".

DOUG.  Mycket bra, tack så mycket, Svet, för att du skrev den kommentaren och skickade in den.

Om du har en intressant berättelse, kommentar eller fråga som du vill skicka in, läser vi det gärna i podden.

Du kan skicka e-post till tips@sophos.com, du kan kommentera någon av våra artiklar, eller så kan du kontakta oss på sociala medier: @nakedsecurity.

Det är vår show för idag; tack så mycket för att du lyssnade.

För Paul Ducklin, jag heter Doug Aamoth, påminner dig tills nästa gång att...

BÅDE.  Håll dig säker!