Klik en sleep op de onderstaande geluidsgolven om naar een willekeurig punt te gaan. Je kan ook luister direct op Soundcloud.

DOUG.  Twitter-zwendel, Patch Tuesday en criminelen die criminelen hacken.

Dat alles en meer op de Naked Security-podcast.

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug.

Hij is Paul Ducklin.

Paul, hoe gaat het vandaag?

EEND.  Heel goed, Doug.

We hebben de maansverduistering hier in Engeland niet gehad, maar ik kreeg wel een korte glimp van de *volle* volle maan door een kleine opening in de wolken die tevoorschijn kwam als het enige gat in de hele wolkenlaag op het moment dat ik naar buiten ging om even kijken!

Maar we hadden niet die oranje maan zoals jullie in Massachusetts.

DOUG.  Laten we de show beginnen met Deze week in de technische geschiedenis… dit gaat ver terug.

Deze week, op 08 november 1895, stuitte de Duitse natuurkundeprofessor Wilhelm Röntgen op een nog onontdekte vorm van straling die hem ertoe bracht deze straling eenvoudigweg "X" te noemen.

Zoals bij röntgenfoto's.

Hoe zit dat... de toevallige ontdekking van röntgenstralen?

EEND.  Best geweldig.

Ik herinner me dat mijn moeder me vertelde: in de jaren vijftig (moet hetzelfde zijn geweest in de Verenigde Staten), blijkbaar in schoenenwinkels...

DOUG.  [WEET WAT ER KOMT] Ja! [LACHT]

EEND.  Mensen namen hun kinderen mee naar binnen... je zou in deze machine gaan staan, de schoenen aandoen en in plaats van alleen maar te zeggen: "Loop rond, zijn ze krap? Knijpen ze?", stond je in een röntgenapparaat, dat je in feite in röntgenstraling baadde en een live foto nam en zei: "Oh ja, ze hebben de juiste maat."

DOUG.  Ja, eenvoudiger tijden. Een beetje gevaarlijk, maar...

EEND.  EEN WEINIG GEVAARLIJK?

Kun je je de mensen voorstellen die in de schoenenwinkels werkten?

Ze moeten de hele tijd in röntgenstralen hebben gebaad.

DOUG.  Absoluut... nou, we zijn een beetje veiliger vandaag.

En wat betreft veiligheid: de eerste dinsdag van de maand is Microsoft's Patch Tuesday.

So wat hebben we geleerd? deze Patch Tuesday hier in november 2022?

Exchange 0-dagen vast (eindelijk) - plus 4 gloednieuwe Patch Tuesday 0-dagen!

EEND.  Welnu, het superspannende, Doug, is dat technisch gezien Patch Tuesday niet één, niet twee, niet drie… maar *vier* zero-days repareerde.

Maar eigenlijk hebben de patches die je dinsdag voor Microsoft-producten kon krijgen, *zes* zero-days vastgesteld.

Denk aan die Exchange zero-days die notoir niet gepatcht waren afgelopen Patch Tuesday: CVE-2002-41040 en CVE-2022-41082, wat bekend werd als ProxyNiet Shell?

S3 Ep102.5: "ProxyNotShell" Exchange-bugs - een expert spreekt [Audio + Tekst]

Welnu, die zijn opgelost, maar in wezen een aparte "nevenlijn" van Patch Tuesday: de Exchange november 2022 SU of Software-update, die alleen maar zegt:

De Exchange-software-updates van november 2022 bevatten oplossingen voor de zero-day-kwetsbaarheden die op 29 september 2022 openbaar werden gemeld.

Het enige wat u hoeft te doen is Exchange upgraden.

Goh, bedankt Microsoft... Ik denk dat we wisten dat we dat moesten doen als de patches eindelijk uitkwamen!

Dus ze *zijn* uit en er zijn twee zero-days vastgesteld, maar het zijn geen nieuwe, en technisch gezien zitten ze niet in het "Patch Tuesday"-gedeelte.

Daar hebben we nog vier andere zero-days.

En als je gelooft in het prioriteren van patches, dan zijn dat natuurlijk degenen waar je het eerst mee om wilt gaan, omdat iemand al weet hoe hij er slechte dingen mee kan doen.

Die variëren van een beveiligingsbypass tot twee verhogingen van bevoegdheden en het uitvoeren van één externe code.

Maar er zijn meer dan 60 pleisters in totaal, en als je kijkt naar de algemene lijst met getroffen producten en Windows-componenten, is er zoals gewoonlijk een enorme lijst met alle Windows-componenten/producten waarvan je hebt gehoord, en veel waarschijnlijk ook niet.

Microsoft patcht 62 kwetsbaarheden, waaronder Kerberos en Mark of the Web en Exchange... een soort van

Dus zoals altijd: Stel niet uit / doe het vandaag nog, Douglas!

DOUG.  Heel goed.

Laten we het nu hebben over een behoorlijke vertraging...

Je hebt een heel interessant verhaal over de Drugsmarkt Silk Road, en een herinnering dat criminelen die stelen van criminelen nog steeds een misdaad is, ook al is het zo'n tien jaar later dat je er echt voor gepakt wordt.

Hacker van drugsmarkt Silk Road pleit schuldig en riskeert 20 jaar cel

EEND.  Ja, zelfs mensen die helemaal nieuw zijn op het gebied van cyberbeveiliging of online gaan, zullen waarschijnlijk hebben gehoord van "Silk Road", misschien wel de eerste bekende, grote, wijdverbreide, veelgebruikte dark web-marktplaats waar eigenlijk alles mogelijk is.

Dus dat ging allemaal in vlammen op in 2013.

Omdat de oprichter, oorspronkelijk alleen bekend als Gevreesde Piraat Roberts, maar uiteindelijk bleek te zijn Ross Ulbricht… zijn slechte operationele veiligheid was voldoende om de activiteiten aan hem te binden.

Silk Road-oprichter Ross Ulbricht krijgt levenslang zonder voorwaardelijke vrijlating

Niet alleen was zijn operationele veiligheid niet erg goed, het lijkt erop dat ze eind 2012 (kun je het geloven, Doug?) een blunder bij het verwerken van cryptocurrency-betalingen hadden...

DOUG.  [HANGT IN MOCK HORROR]

EEND.  ...van het type dat we sindsdien vele malen hebben herhaald, dat niet helemaal de juiste dubbele boekhouding deed, waarbij voor elke debet een bijbehorend krediet is en vice versa.

En deze aanvaller ontdekte, als je wat geld op je rekening zette en het dan heel snel uitbetaalde aan andere rekeningen, dat je eigenlijk vijf keer (of zelfs meer) dezelfde bitcoins kon uitbetalen voordat het systeem besefte dat de eerste afschrijving was verdwenen door.

Dus je zou eigenlijk wat geld kunnen inleggen en het dan steeds weer opnieuw opnemen, en een grotere voorraad krijgen...

... en dan zou je terug kunnen gaan naar wat je een "cryptocurrency milking loop" zou kunnen noemen.

En het wordt geschat... de onderzoekers waren er niet zeker van dat hij begon met tussen de 200 en 2000 bitcoins van zichzelf (of hij ze kocht of de mijne, we weten het niet), en hij veranderde ze heel, heel snel in, wacht erop, Doug: 50,0000 bitcoins!

DOUG.  Wow!

EEND.  Meer dan 50,000 bitcoins, zomaar.

En toen, duidelijk in de veronderstelling dat iemand het zou opmerken, rende hij weg terwijl hij voorop liep met 50,000 bitcoins ...

... elk een verbazingwekkende $ 12 waard, vergeleken met fracties van een cent slechts een paar jaar eerder. [LACHT]

Dus hij ging er zomaar vandoor met $600,000, Doug.

[DRAMATISCHE PAUZE]

Negen jaar later…

[GELACH]

...bijna *precies* negen jaar later, toen hij werd gepakt en zijn huis werd binnengevallen onder een bevelschrift, gingen de politie op zoek en vonden een stapel dekens in zijn kast, waaronder een popcornblik verborgen was.

Vreemde plek om je popcorn te bewaren.

Binnenin zat een soort geautomatiseerde koude portemonnee.

Daarin zat een groot deel van de genoemde bitcoins!

Op het moment dat hij werd opgepakt, waren bitcoins iets ten noorden van $ 65,535 (of 2¹⁶-1 Elk.

Ze waren in de tussentijd meer dan duizendvoudig gestegen.

Dus in die tijd was het de grootste cryptocoin-inval ooit!

Negen jaar later, blijkbaar niet in staat geweest om over zijn onrechtmatig verkregen winsten te beschikken, misschien bang dat zelfs als hij ze in een beker zou proberen te duwen, alle vingers naar hem zouden wijzen...

...hij heeft al deze $ 3 miljard aan bitcoins gehad die al negen jaar in een popcornblik zitten!

DOUG.  Mijn God.

EEND.  Dus, na al die jaren op deze enge schat te hebben gezeten, zich afvragend of hij gepakt zou worden, vraagt ​​hij zich nu af: "Hoe lang zal ik naar de gevangenis gaan?"

En de maximumstraf voor de aanklacht die hem wordt opgelegd?

20 jaar, Doug.

DOUG.  Op dit moment speelt er weer een interessant verhaal. Als je de laatste tijd op Twitter bent geweest, weet je dat er veel activiteit is. om het diplomatiek te zeggen...

EEND.  [LAGE TOT MIDDELGROTE KWALITEIT BOB DYLAN IMPERSONATION] Wel, de tijden veranderen.

DOUG.  ... inclusief op een gegeven moment het idee om $ 20 in rekening te brengen voor een geverifieerde blauwe cheque, wat natuurlijk bijna onmiddellijk leidde tot wat oplichting.

Twitter Blue Badge e-mailzwendel – Trap er niet in!

EEND.  Het is slechts een herinnering, Doug, dat wanneer er iets is dat veel belangstelling heeft gewekt, de boeven zeker zullen volgen.

En het uitgangspunt hiervan was: "Hé, waarom niet vroeg opstaan? Als je al een blauwe markering hebt, raad eens? U hoeft de $ 19.99 per maand niet te betalen als u zich vooraf registreert. We laten je het houden."

We weten dat dat niet het idee van Elon Musk was, zoals hij het zei, maar het is het soort dingen dat veel bedrijven doen, nietwaar?

Veel bedrijven zullen u een soort voordeel geven als u bij de service blijft.

Het is dus niet helemaal ongeloofwaardig.

Zoals je zegt... wat heb je het gegeven?

B-min, toch?

DOUG.  Ik geef de eerste e-mail een B-minus ... je zou misschien in de maling worden genomen als je het snel leest, maar er zijn enkele grammaticale problemen; dingen voelen niet goed.

En als je eenmaal doorklikt, zou ik de bestemmingspagina's C-minus geven.

Dat wordt nog pittiger.

EEND.  Dat is ergens tussen 5/10 en 6/10?

DOUG.  Ja, laten we dat zeggen.

En we hebben wel wat advies, dus zelfs als het een A-plus scam is, maakt het niet uit, want je zult het toch kunnen dwarsbomen!

Te beginnen met mijn persoonlijke favoriet: Gebruik een wachtwoordbeheerder.

Een wachtwoordbeheerder lost veel problemen op als het gaat om oplichting.

EEND.  Het doet.

Een wachtwoordmanager heeft geen menselijke intelligentie die misleid kan worden door het feit dat het mooie plaatje klopt, of het logo perfect is, of het webformulier precies op de goede plek op het scherm staat met exact hetzelfde lettertype , dus je herkent het.

Het enige wat het weet is: "Nooit eerder van deze site gehoord."

DOUG.  En natuurlijk, zet 2FA aan als je kunt.

Voeg indien mogelijk altijd een tweede authenticatiefactor toe.

EEND.  Dat beschermt je natuurlijk niet per se tegen jezelf.

Als je naar een nepsite gaat en je hebt besloten: "Hé, het is perfect, het moet de echte deal zijn", en je bent vastbesloten om in te loggen en je hebt je gebruikersnaam en wachtwoord al ingevoerd, en dan wordt u gevraagd om het 2FA-proces te doorlopen ...

…de kans is groot dat u dat doet.

Het geeft je echter dat beetje tijd om de "Stop. Denken. Aansluiten." en zeg tegen jezelf: "Wacht even, wat doe ik hier?"

Dus in zekere zin kan het kleine beetje vertraging dat 2FA introduceert eigenlijk niet alleen heel weinig gedoe zijn, maar ook een manier om uw cyberbeveiligingsworkflow daadwerkelijk te verbeteren ... door net genoeg van een verkeersdrempel te introduceren die u geneigd bent cyberbeveiliging te nemen dat beetje serieuzer.

Dus ik zie eigenlijk niet wat het nadeel is.

DOUG.  En natuurlijk is een andere strategie die voor veel mensen moeilijk te volgen is, maar zeer effectief is, vermijd inloglinks en actieknoppen in e-mail.

Dus als je een e-mail ontvangt, klik dan niet alleen op de knop... ga naar de site zelf en je zult vrij snel kunnen zien of die e-mail legitiem was of niet.

EEND.  Kortom, als u de eerste correspondentie niet volledig kunt vertrouwen, kunt u niet vertrouwen op de details die erin staan, of dat nu de link is waarop u gaat klikken, het telefoonnummer dat u gaat bellen, het e-mailadres dat u je gaat contact met ze opnemen op , het Instagram-account waarnaar je DM's gaat sturen, wat het ook is.

Gebruik niet wat er in de e-mail staat... zoek je eigen weg daarheen, en je zult veel van dit soort oplichting kortsluiten.

DOUG.  En tot slot, last but not least ... dit zou gezond verstand moeten zijn, maar dat is het niet: Vraag de afzender van een onzeker bericht nooit of het legitiem is.

Reageer niet en zeg niet: "Hé, ben je echt Twitter?"

EEND.  Ja, je hebt helemaal gelijk.

Omdat mijn eerdere advies, "Vertrouw niet op de informatie in de e-mail", zoals bel hun telefoonnummer niet... sommige mensen komen in de verleiding om te zeggen: "Nou, ik bel het telefoonnummer en kijk of het echt zijn zij. [IRONIC] Omdat, natuurlijk, als de kok het antwoord geeft, ze hun echte naam zullen geven.'

DOUG.  Zoals we altijd zeggen: Bij twijfel/Geef het niet uit.

En dit is een goed waarschuwend verhaal, dit volgende verhaal: wanneer beveiligingsscans, die legitieme beveiligingstools zijn, onthullen meer dan ze zouden moeten, Wat gebeurt er dan?

Openbare hulpprogramma's voor het scannen van URL's - wanneer beveiliging leidt tot onveiligheid

EEND.  Dit is een bekende onderzoeker met de naam Fabian Bräunlein in Duitsland... we hebben hem al een paar keer eerder genoemd.

Hij is terug met een gedetailleerd rapport getiteld urlscan.io'S SOAR-spot: spraakzame beveiligingstools die privégegevens lekken.

En in dit geval is het urlscan.io, een website die u gratis (of als betaalde dienst) kunt gebruiken waar u een URL, of een domeinnaam, of een IP-nummer, of wat het ook is, kunt indienen en u kunt opzoeken: "Wat weet de gemeenschap hierover?”

En het zal de volledige URL onthullen waar andere mensen naar hebben gevraagd.

En dit zijn niet alleen dingen die mensen naar eigen keuze kopiëren en plakken.

Soms gaat hun e-mail bijvoorbeeld door een filtertool van derden die zelf URL's extraheert, naar huis belt urlscan.io, voert de zoekopdracht uit, haalt het resultaat op en gebruikt dat om te beslissen of het bericht moet worden ongevraagd, spam geblokkeerd of doorgestuurd.

En dat betekent dat soms, als de URL geheime of semi-geheime gegevens bevat, persoonlijk identificeerbare informatie, andere mensen die toevallig kort daarna naar de juiste domeinnaam zochten, alle URL's zouden zien waarnaar werd gezocht, inclusief dingen die in de URL kunnen staan.

Je weet wel, zoals blahblah?username=doug&passwordresetcode= gevolgd door een lange reeks hexadecimale tekens, enzovoort.

En Bräunlein kwam met een fascinerende lijst van het soort URL's, met name de URL's die in e-mails kunnen voorkomen, die routinematig naar een derde partij kunnen worden gestuurd om te worden gefilterd en vervolgens worden geïndexeerd om te zoeken.

Het soort e-mails waarvan hij dacht dat ze zeker te exploiteren waren, omvatte, maar was niet beperkt tot: koppelingen voor het maken van accounts; Amazon cadeau-bezorglinks; API-sleutels; DocuSign-ondertekeningsverzoeken; dropbox-bestandsoverdrachten; pakket traceren; wachtwoord reset; PayPal-facturen; Google Drive-documenten delen; SharePoint-uitnodigingen; en nieuwsbrief afmeldlinks.

Niet met de vinger wijzen naar SharePoint, Google Drive, PayPal, etc.

Dat waren slechts voorbeelden van URL's die hij tegenkwam die op deze manier mogelijk misbruikt konden worden.

DOUG.  We hebben wat advies aan het einde van dat artikel, wat neerkomt op: lees het rapport van Bräunlein; lezen urlscan.io's blogbericht; doe zelf een code review; als je code hebt die online beveiligingszoekopdrachten uitvoert; leren welke privacyfuncties er zijn voor online inzendingen; en, belangrijker nog, leer hoe u frauduleuze gegevens kunt rapporteren aan een online service als u deze ziet.

Het viel me op dat er drie... soort limericks zijn?

Zeer creatieve mini-gedichten aan het einde van dit artikel…

EEND.  [MOCK HORROR] Nee, het zijn geen limericks! Limericks hebben een zeer formele vijfregelige structuur...

DOUG.  [LACHEND] Het spijt me zo. Dat is waar!

EEND.  ... voor zowel meter als rijm.

Heel gestructureerd, Doug!

DOUG.  Het spijt me zo, zo waar. [LACHT]

EEND.  Dit is gewoon hondsdolheid. [GELACH]

Nogmaals: Bij twijfel/Geef het niet uit.

En als u gegevens verzamelt: Als het niet in de prullenbak zou moeten zitten / Stop het recht in de prullenbak.

En als u code schrijft die openbare API's aanroept die klantgegevens kunnen onthullen: Maak uw gebruikers nooit aan het huilen / Door hoe u de API aanroept.

DOUG.  [LACHT] Dat is een nieuwe voor mij, en die vind ik erg leuk!

En als laatste, maar zeker niet de minste op onze lijst hier, hebben we het week na week over deze OpenSSL-beveiligingsbug gehad.

De grote vraag is nu: “Hoe weet je dat wat moet er gerepareerd worden?”

Het verhaal van de OpenSSL-beveiligingsupdate - hoe weet u wat er moet worden gerepareerd?

EEND.  Inderdaad, Doug, hoe weten we welke versie van OpenSSL we hebben?

En natuurlijk, op Linux, open je gewoon een opdrachtprompt en typ je openssl version, en het vertelt je de versie die je hebt.

Maar OpenSSL is een programmeerbibliotheek en er is geen regel die zegt dat software geen eigen versie kan hebben.

Je distro gebruikt misschien OpenSSL 3.0, en toch is er een app die zegt: "Oh nee, we hebben niet geüpgraded naar de nieuwe versie. We geven de voorkeur aan OpenSSL 1.1.1, omdat dat nog steeds wordt ondersteund, en voor het geval je het niet hebt, brengen we onze eigen versie."

En dus moest je helaas, net als in die beruchte Log4Shell-zaak, op zoek naar de drie? 12? 154? wie-weet-hoeveel plaatsen op uw netwerk waar u mogelijk een verouderd Log4J-programma heeft.

Hetzelfde geldt voor OpenSSL.

In theorie kunnen XDR- of EDR-tools het je misschien vertellen, maar sommige zullen dit niet ondersteunen en velen zullen het ontmoedigen: het programma daadwerkelijk uitvoeren om erachter te komen welke versie het is.

Want tenslotte, als het de buggy is of de verkeerde, en je moet het programma echt uitvoeren om het zijn eigen versie te laten rapporteren...

…dat voelt als de kar voor het paard spannen, nietwaar?

Daarom hebben we een artikel gepubliceerd voor die speciale gevallen waarin u de DLL of de gedeelde bibliotheek daadwerkelijk wilt laden, en u wilt deze eigenlijk zijn eigen TellMeThyVersion() softwarecode.

Met andere woorden, u vertrouwt het programma voldoende om in het geheugen te laden, het uit te voeren en een onderdeel ervan uit te voeren.

We laten u zien hoe u dat kunt doen, zodat u er absoluut zeker van kunt zijn dat alle afgelegen OpenSSL-bestanden die u op uw netwerk hebt up-to-date zijn.

Want hoewel dit is gedegradeerd van CRITICAL naar HIGH, is het nog steeds een bug die je moet en wilt oplossen!

DOUG.  Wat betreft de ernst van deze bug, kregen we een interessante vraag van Naked-beveiligingslezer Svet, die gedeeltelijk schrijft:

Hoe komt het dat een bug die enorm complex is voor uitbuiting en alleen kan worden gebruikt voor denial of service-aanvallen, nog steeds als HOOG wordt geclassificeerd?

EEND.  Ja, ik denk dat hij iets zei over: "Oh, heeft het OpenSL-team niet gehoord van CVSS?", wat een Amerikaanse overheidsstandaard is, als je wilt, voor het coderen van het risico- en complexiteitsniveau van bugs op een manier die kan worden automatisch gefilterd door scripts.

Dus als het een lage CVSS-score heeft (wat de Systeem voor algemene kwetsbaarheidscores), waarom raken mensen er enthousiast over?

Waarom zou het HOOG moeten zijn?

En dus was mijn antwoord: "Waarom * zou niet * het HOOG moeten zijn?"

Het is een bug in een cryptografische engine; het zou een programma kunnen laten crashen, laten we zeggen dat het een update probeert te krijgen... dus het zal keer op keer crashen, wat een beetje meer is dan alleen een denial of service, omdat het je in feite verhindert om je beveiliging goed uit te voeren.

Er is een element van beveiligingsbypass.

En ik denk dat het andere deel van het antwoord is, als het gaat om kwetsbaarheden die worden omgezet in exploits: "Zeg nooit nooit!"

Als je zoiets als een stackbufferoverloop hebt, waar je andere variabelen op de stack kunt manipuleren, mogelijk inclusief geheugenadressen, is er altijd een kans dat iemand een bruikbare exploit ontdekt.

En het probleem, Doug, is dat als ze het eenmaal door hebben, het niet uitmaakt hoe ingewikkeld het was om erachter te komen...

...als je eenmaal weet hoe je het moet exploiteren, kan *iedereen* het doen, omdat je ze de code kunt verkopen om dit te doen.

Ik denk dat je weet wat ik ga zeggen: "Niet dat ik er sterk over denk."

[GELACH]

Het is, nogmaals, een van die "verdomd als ze het doen, verdomd als ze het niet doen" dingen.

DOUG.  Heel goed, heel erg bedankt, Svet, voor het schrijven van die opmerking en het opsturen ervan.

Als je een interessant verhaal, opmerking of vraag hebt die je wilt indienen, lezen we die graag in de podcast.

Je kunt een e-mail sturen naar tips@sophos.com, reageren op een van onze artikelen of je kunt ons bereiken op social: @nakedsecurity.

Dat is onze show voor vandaag; heel erg bedankt voor het luisteren.

Voor Paul Ducklin, ik ben Doug Aamoth, ik herinner je eraan tot de volgende keer om...

BEIDE.  Blijf veilig!