LYSSNA NU
Med Doug Aamoth och Paul Ducklin.
Intro och outro musik av Edith Mudge.
Klicka och dra på ljudvågorna nedan för att hoppa till valfri punkt. Du kan också lyssna direkt på Soundcloud.
Du kan lyssna på oss på soundcloud, Apple Podcasts, Google Podcasts, Spotify, häft och överallt där bra poddar finns. Eller bara släpp URL till vårt RSS-flöde till din favoritpodcatcher.
LÄS TRANSKRIPTET
DOUG. Deadbolt – den är tillbaka!
Plåster i massor!
Och tidszoner... ja, tidszoner.
Allt det, och mer, på Naked Security Podcast.
[MUSIKALT MODEM]
Välkommen till podden, alla.
Jag heter Doug Aamoth.
Med mig är som alltid Paul Ducklin.
Paul, ett mycket lyckligt 100:e avsnitt till dig, min vän!
ANKA. Wow, Doug!
Du vet, när jag startade min katalogstruktur för Series 3, använde jag djärvt -001 för första avsnittet.
DOUG. Jag gjorde inte. [SKratt]
ANKA. Inte -1 or -01.
DOUG. smart…
ANKA. Jag hade stor tro!
Och när jag sparar dagens fil kommer jag att glädjas åt det.
DOUG. Ja, och jag kommer att frukta det eftersom det kommer att dyka upp till toppen.
Tja, jag får ta itu med det senare...
ANKA. [SKratt] Du kan byta namn på alla andra grejer.
DOUG. Jag vet jag vet.
[MUMMAR] Ser inte fram emot det... där går min onsdag.
Hur som helst, låt oss börja showen med lite teknisk historia.
Denna vecka, den 12 september 1959, Luna 2, Även känd som Andra sovjetiska kosmiska raketen, blev den första rymdfarkosten som nådde månens yta, och det första människotillverkade föremålet som fick kontakt med en annan himlakropp.
Väldigt coolt.
ANKA. Vad var det långa namnet?
"Den andra sovjetiska kosmiska raketen"?
DOUG. Ja.
ANKA. Luna två Är mycket bättre.
DOUG. Ja, mycket bättre!
ANKA. Uppenbarligen, som du kan föreställa dig, med tanke på att det var rymdkapplöpningens era, fanns det en viss oro för, "Hur ska vi veta att de faktiskt har gjort det? De kan bara säga att de har landat på månen, och kanske hittar de på det."
Tydligen utarbetade de ett protokoll som skulle tillåta oberoende observation.
De förutspådde tiden då den skulle anlända till månen, att krascha in i månen, och de skickade den exakta tiden som de förväntade sig detta till en astronom i Storbritannien.
Och han observerade självständigt för att se om det de sa *skulle* hända vid den tiden *hände*.
Så de tänkte till och med på "Hur verifierar man något sådant här?"
DOUG. Tja, när det gäller komplicerade saker har vi patchar från Microsoft och Apple.
Så vad är anmärkningsvärt här i den här senaste omgången?
ANKA. Det gör vi verkligen – det är patch tisdag den här veckan, den andra tisdagen i månaden.
Det finns två sårbarheter i Patch Tuesday som var anmärkningsvärda för mig.
En är anmärkningsvärd eftersom den uppenbarligen är i naturen – med andra ord, det var en nolldag.
Och även om det inte är fjärrkörning av kod, är det lite oroande eftersom det är en sårbarhet i loggfilen, Doug!
Det är inte riktigt som dålig som Log4J, där du inte bara kunde få loggern att misslyckas, du kan också få den till kör godtycklig kod för dig.
Men det verkar som om du skickar någon form av felaktig data till Windows Common Log File System-drivrutinen, CLFS, så kan du lura systemet att befordra dig till systemprivilegier.
Alltid dåligt om du har kommit in som gästanvändare och sedan kan göra dig själv till en systemadministratör...
DOUG. [SKratt] Ja!
ANKA. Det är CVE-2022-37969.
Och den andra som jag tyckte var intressant...
…lyckligtvis inte i det vilda, men det här är den som du verkligen behöver lappa, för jag slår vad om att det är den som cyberbrottslingar kommer att fokusera på omvänd ingenjörskonst:
"Sårbarhet för körning av fjärrkod för Windows TCP/IP", CVE-2022-34718.
Om du kommer ihåg Kod Rödoch SQL Slammer, och de där stygga maskarna från det förflutna, där de precis anlände i ett nätverkspaket och trängde sig in i systemet...
Det är en ännu lägre nivå än så.
Tydligen är buggen i hanteringen av vissa IPv6-paket.
Så allt där IPv6 lyssnar, vilket är i stort sett vilken Windows-dator som helst, kan vara i fara av detta.
Som jag sa, den är inte i det vilda, så skurkarna har inte hittat den än, men jag tvivlar inte på att de kommer att ta plåstret och försöka ta reda på om de kan omvända en exploit från den, för att fånga upp folk som inte har patchat ännu.
För om något säger: "Wow! Tänk om någon skrev en mask som använde det här?”... det är den jag skulle vara orolig för.
DOUG. OK.
Och sedan till Apple...
ANKA. Vi har skrivit två berättelser om Apples patchar nyligen, där det helt plötsligt fanns patchar för iPhones och iPads och Macs mot två i-the-wild noll-dagar.
Det ena var ett webbläsarfel, eller ett webbläsarrelaterat fel, så att du kunde vandra in på en oskyldigt utseende webbplats och skadlig programvara kunde landa på din dator, plus en annan som gav dig kontroll på kärnnivå...
…som, som jag sa i förra podcasten, luktar spionprogram för mig – något som en spionprogramleverantör eller en riktigt seriös "övervakningscyberskurk" skulle vara intresserad av.
Sedan kom det en andra uppdatering, till vår förvåning, för iOS 12, som vi alla trodde hade varit övergivna länge.
Där fick en av dessa buggar (den webbläsarrelaterade en som tillät skurkar att bryta sig in) en patch.
Och sedan, precis när jag väntade iOS 16, började alla dessa e-postmeddelanden plötsligt landa i min inkorg – direkt efter att jag kollade, "Är iOS 16 ute än? Kan jag uppdatera till det?"
Det fanns inte där, men sedan fick jag alla dessa e-postmeddelanden som sa: "Vi har precis uppdaterat iOS 15 och macOS Monterey och Big Sur och iPadOS 15"...
... och det visade sig att det fanns en hel massa uppdateringar, plus en helt ny kernel zero-day denna gång också.
Och det fascinerande är att, efter att jag fick aviseringarna, tänkte jag, "Tja, låt mig kolla igen ..."
(Så du kan komma ihåg, det är det Inställningar > Allmänt > Programuppdatering på din iPhone eller iPad.)
Se och se, jag erbjöds en uppdatering till iOS 15, som jag redan hade, *eller* kunde jag hoppa hela vägen till iOS 16.
Och iOS 16 hade också den här nolldagsfixen (även om iOS 16 teoretiskt sett inte var ute ännu), så jag antar att buggen också fanns i betaversionen.
Det var inte listat som officiellt en nolldag i Apples bulletin för iOS 16, men vi kan inte avgöra om det beror på att utnyttjandet som Apple såg inte riktigt fungerade korrekt på iOS 16, eller om det inte anses vara en noll- dag eftersom iOS 16 precis skulle komma ut.
DOUG. Ja, jag tänkte säga: ingen har det än. [SKRATT]
ANKA. Det var den stora nyheten från Apple.
Och det viktiga är att när du går till din telefon och säger "Åh, iOS 16 är tillgängligt"... om du inte är intresserad av iOS 16 ännu, måste du fortfarande se till att du har iOS 15 uppdatering, på grund av kärnans zero-day.
Kernel noll dagar är alltid ett problem eftersom det betyder att någon där ute vet hur man kringgår de mycket omtalade säkerhetsinställningarna på din iPhone.
Felet gäller även macOS Monterey och macOS Big Sur – det är den tidigare versionen, macOS 11.
I själva verket, för att inte bli överträffad, har Big Sur faktiskt *två* kärn-nolldagars buggar i det vilda.
Inga nyheter om iOS 12, vilket är ungefär vad jag förväntade mig, och inget hittills för macOS Catalina.
Catalina är macOS 10, den tidigare versionen, och återigen vet vi inte om den uppdateringen kommer senare, eller om den har fallit utanför världens ytterkant och inte kommer att få uppdateringar ändå.
Tyvärr säger inte Apple det, så vi vet inte.
Nu kommer de flesta Apple-användare att ha automatiska uppdateringar aktiverade, men, som vi alltid säger, gå och kolla (oavsett om du har en Mac eller en iPhone eller en iPad), för det värsta är bara att anta att din automatiska uppdateringar fungerade och höll dig säker...
…när det faktiskt gick fel.
DOUG. OK, mycket bra.
Något som jag har sett fram emot, när jag går vidare, är: "Vad har tidszoner med IT-säkerhet att göra?"
ANKA. Tja, ganska mycket, visar det sig, Doug.
DOUG. [SKratt] Yessir!
ANKA. Tidszoner är väldigt enkla i konceptet.
De är väldigt bekväma för att styra våra liv så att våra klockor ungefär matchar vad som händer på himlen – så det är mörkt på natten och ljust på dagen. (Låt oss ignorera sommartid och låt oss bara anta att vi bara har en timmes tidszoner runt om i världen så att allt är väldigt enkelt.)
Problemet kommer när du faktiskt håller systemloggar i en organisation där några av dina servrar, några av dina användare, vissa delar av ditt nätverk, några av dina kunder, finns i andra delar av världen.
När du skriver till loggfilen, skriver du tiden med tidszonen inkluderad?
När du skriver din logg, Doug, subtraherar du de 5 timmar (eller 4 timmar för tillfället) som du behöver eftersom du är i Boston, medan jag lägger till en timme eftersom jag är på London-tid, men det är sommar ?
Skriver jag det i loggen så att det blir vettigt för *mig* när jag läser tillbaka loggen?
Eller skriver jag en mer kanonisk, entydig tid med samma tidszon för *alla*, så när jag jämför loggar som kommer från olika datorer, olika användare, olika delar av världen på mitt nätverk, kan jag faktiskt rada upp händelser?
Det är verkligen viktigt att ordna händelser, Doug, särskilt om du gör hotrespons i en cyberattack.
Du måste verkligen veta vad som kom först.
Och om du säger, "Åh, det hände inte förrän kl. 3", så hjälper det mig inte om jag är i Sydney, för min kl. 3 hände igår jämfört med kl. 3.
Så jag skrev en artikel på Naked Security om några sätt du kan hantera detta problem när du loggar data.
Min personliga rekommendation är att använda ett förenklat tidsstämpelformat som heter RFC 3339, där du sätter ett fyrsiffrigt år, bindestreck [bindestreck, ASCII 0x2D], tvåsiffrig månad, bindestreck, tvåsiffrig dag och så vidare, så att dina tidsstämplar faktiskt sorterar alfabetiskt fint.
Och att du spelar in alla dina tidszoner som en tme-zon som kallas Z (zed eller zee), förkortning för Zulu tid.
Det betyder i princip UTC eller Coordinated Universal Time.
Det är nästan-men-inte-helt Greenwich Mean Time, och det är den tid som nästan varje dators eller telefons klocka faktiskt är inställd på internt nu för tiden.
Försök inte kompensera för tidszoner när du skriver till loggen, för då kommer någon att behöva dekompensera när de försöker ställa in din logg med alla andras – och det finns många smyg som snurrar koppen och läppen, Doug.
Håll det enkelt.
Använd ett kanoniskt, enkelt textformat som avgränsar exakt datum och tid, ända ner till sekunden – eller nuförtiden kan tidsstämplar till och med gå ner till nanosekund om du vill.
Och bli av med tidszoner från dina loggar; bli av med sommartid från dina stockar; och bara spela in allt, enligt min mening, i Coordinated Universal Time...
…förvirrande förkortat UTC, eftersom namnet är på engelska men förkortningen är på franska – något av en ironi.
DOUG. Ja.
ANKA.
Jag är frestad att säga, "Inte för att jag känner starkt för det igen", som jag brukar göra, skrattande...
…men det är verkligen viktigt att få saker i rätt ordning, särskilt när du försöker spåra cyberbrottslingar.
DOUG. Okej, det är bra – bra råd.
Och om vi håller oss till ämnet cyberkriminella, har du hört talas om Manipulator-in-the-Middle-attacker; du har hört talas om Manipulator-in-the-Browser-attacker...
..gör dig nu redo för Browser-in-the-Browser-attacker.
ANKA. Ja, det här är en ny term som vi ser.
Jag ville skriva detta eftersom forskare på ett hotintelligensföretag som heter Group-IB nyligen skrev en artikel om detta, och media började prata om, "Hej, Browser-in-the-Browser-attacker, var väldigt rädd", eller vad som helst. …
Du tänker, "Tja, jag undrar hur många som faktiskt vet vad som menas med en Browser-in-the-Browser-attack?"
Och det irriterande med dessa attacker, Doug, är att de tekniskt sett är fruktansvärt enkla.
Det är en så enkel idé.
DOUG. De är nästan konstnärliga.
ANKA. Ja!
Det är egentligen inte vetenskap och teknik, det är konst och design, eller hur?
I grund och botten, om du någonsin har gjort någon JavaScript-programmering (på gott eller ont), kommer du att veta att en av sakerna med saker som du sätter in på en webbsida är att det är tänkt att begränsas till den webbsidan.
Så om du dyker upp ett helt nytt fönster kan du förvänta dig att det får en helt ny webbläsarkontext.
Och om den laddar sin sida från en helt ny webbplats, säg en nätfiskesida, kommer den inte att ha tillgång till alla JavaScript-variabler, sammanhang, cookies och allt som huvudfönstret hade.
Så, om du öppnar ett separat fönster, begränsar du typ av din hackningsförmåga om du är en skurk.
Men om du öppnar något i det aktuella fönstret, är du avsevärt begränsad till hur spännande och "systemlikt" du kan få det att se ut, eller hur?
Eftersom du inte kan skriva över adressfältet... det är designat.
Du kan inte skriva något utanför webbläsarfönstret, så du kan inte smygt lägga ett fönster som ser ut som en bakgrundsbild på skrivbordet, som om det har funnits där hela tiden.
Med andra ord, du är inne i webbläsarfönstret som du började med.
Så tanken med en Browser-in-the-Browser-attack är att du börjar med en vanlig webbplats, och sedan skapar du, inuti webbläsarfönstret du redan har, en webbsida som i sig ser exakt ut som ett operativsystems webbläsarfönster .
I grund och botten visar du någon en *bild* av den äkta varan och övertygar dem om att det *är* den äkta varan.
Det är så enkelt i hjärtat, Doug!
Men problemet är att med lite noggrant arbete, särskilt om du har goda CSS-kunskaper, *kan* du faktiskt få något som finns i ett befintligt webbläsarfönster att se ut som ett eget webbläsarfönster.
Och med lite JavaScript kan du till och med göra det så att det kan ändra storlek och så att det kan flytta runt på skärmen, och du kan fylla i det med HTML som du hämtar från en tredje parts webbplats.
Nu kanske du undrar... om skurkarna gör rätt, hur i hela friden kan du någonsin veta?
Och den goda nyheten är att det finns en helt enkel sak du kan göra.
Om du ser vad som ser ut som ett operativsystemfönster och du är misstänksam mot det på något sätt (det verkar i princip dyka upp över ditt webbläsarfönster, eftersom det måste vara inuti det)...
…försök att flytta den *från det riktiga webbläsarfönstret*, och om den är "fängslad" i webbläsaren vet du att det inte är den riktiga affären!
Det intressanta med rapporten från Group-IB-forskarna är att när de kom över detta använde skurkarna det faktiskt mot spelare av Steam-spel.
Och naturligtvis vill den att du loggar in på ditt Steam-konto...
...och om du blev lurad av den första sidan, skulle den till och med följa upp med Steams tvåfaktorsautentiseringsverifiering.
Och tricket var att om dessa verkligen *var* separata fönster, kunde du ha dragit dem till ena sidan av ditt huvudwebbläsarfönster, men det var de inte.
I det här fallet hade kockarna lyckligtvis inte gjort sin CSS särskilt bra.
Deras konstverk var fula.
Men som du och jag har talat om många gånger i podden, Doug, ibland finns det skurkar som kommer att anstränga sig för att få saker att se pixelperfekta ut.
Med CSS kan du bokstavligen placera enskilda pixlar, eller hur?
DOUG. CSS är intressant.
Det är Cascading Style Sheets… ett språk du använder för att formatera HTML-dokument, och det är verkligen lätt att lära sig och det är ännu svårare att bemästra.
ANKA. [SKratt] Låter som DET, helt klart.
DOUG. [SKratt] Ja, det är som många saker!
Men det är en av de första sakerna du lär dig när du lär dig HTML.
Om du tänker: "Jag vill få den här webbsidan att se bättre ut", lär du dig CSS.
Så när du tittar på några av dessa exempel på källdokumentet som du länkade till från artikeln, kan du se att det kommer att bli riktigt svårt att göra en riktigt bra fejk, om du inte är riktigt bra på CSS.
Men om du gör det rätt kommer det att bli riktigt svårt att ta reda på att det är ett falskt dokument...
…om du inte gör som du säger: försök dra ut den genom ett fönster och flytta den runt på skrivbordet, sånt där.
Det leder till din andra punkt här: undersök misstänkta fönster noggrant.
Många av dem kommer förmodligen inte att klara ögontestet, men om de gör det kommer det att bli riktigt svårt att upptäcka.
Vilket leder oss till den tredje saken...
"Om du är osäker/ge inte ut det."
Om det bara inte ser riktigt bra ut och du inte definitivt kan säga att något är konstigt är på gång, följ bara rimet!
ANKA. Och det är värt att vara misstänksam mot okända webbplatser, webbplatser du inte har använt tidigare, som plötsligt säger: "OK, vi kommer att be dig logga in med ditt Google-konto i ett Google-fönster, eller Facebook i ett Facebook-fönster. ”
Eller Steam i ett Steam-fönster.
DOUG. Ja.
Jag hatar att använda B-ordet här, men det här är nästan lysande i sin enkelhet.
Men återigen, det kommer att bli riktigt svårt att få fram en perfekt pixelmatchning med CSS och sånt.
ANKA. Jag tror att det viktiga att komma ihåg är att eftersom en del av simuleringen är webbläsarens "chrome" [jargong för webbläsarens användargränssnittskomponenter] kommer adressfältet att se rätt ut.
Det kan till och med se perfekt ut.
Men grejen är att det inte är ett adressfält...
…det är en *bild* av ett adressfält.
DOUG. Exakt!
Okej, var försiktig där ute, allihop!
Och på tal om saker som inte är som de verkar, jag läser om DEADBOLT ransomware och QNAP NAS-enheter, och det känns för mig som att vi precis diskuterade den här historien för inte så länge sedan.
ANKA. Ja, det har vi skrivet om detta flera gånger på Naked Security hittills i år, tyvärr.
Det är ett av de fall där det som fungerade för skurkarna en gång visar sig ha fungerat två gånger, tre gånger, fyra gånger, fem gånger.
Och NAS, eller Nätverksanslutet lagringsutrymme enheter, är, om du vill, black-box-servrar som du kan gå och köpa – de kör vanligtvis någon form av Linux-kärna.
Tanken är att istället för att behöva köpa en Windows-licens eller lära sig Linux, installera Samba, konfigurera det, lär dig hur du gör fildelning på ditt nätverk...
… du bara kopplar in den här enheten och "Bingo", den börjar fungera.
Det är en webbtillgänglig filserver och, tyvärr, om det finns en sårbarhet i filservern och du (av en slump eller design) har gjort den tillgänglig via internet, kan skurkar kanske utnyttja den sårbarheten, om det finns en i den NAS-enheten, på avstånd.
De kanske kan förvränga alla filer på nyckellagringsplatsen för ditt nätverk, oavsett om det är ett hemnätverk eller ett litet företagsnätverk, och i princip hålla dig till lösen utan att någonsin behöva oroa dig för att attackera enskilda andra enheter som bärbara datorer och telefoner på din nätverk.
Så de behöver inte bråka med skadlig programvara som infekterar din bärbara dator, och de behöver inte bryta sig in i ditt nätverk och vandra runt som traditionella ransomware-kriminella.
De förvränger i princip alla dina filer, och sedan – för att presentera lösensumman – ändrar de bara (jag borde inte skratta, Doug)... de ändrar bara inloggningssidan på din NAS-enhet.
Så när du upptäcker att alla dina filer är trassliga och du tänker, "det är roligt", och du hoppar in med din webbläsare och ansluter dit, får du ingen lösenordsuppmaning!
Du får en varning: "Dina filer har låsts av DEADBOLT. Vad hände? Alla dina filer har krypterats."
Och sedan kommer instruktionerna om hur man betalar.
DOUG. Och de har också vänligt erbjudit att QNAP kan lägga upp en furstlig summa för att låsa upp filerna för alla.
ANKA. Skärmbilderna jag har i senaste artikeln på nakedsecurity.sophos.com visar:
1. Individuella dekrypteringar på 0.03 bitcoins, ursprungligen cirka 1200 USD när den här saken först blev utbredd, nu cirka 600 USD.
2. Ett BTC 5.00-alternativ, där QNAP får veta om sårbarheten så att de kan fixa den, som de uppenbarligen inte kommer att betala eftersom de redan vet om sårbarheten. (Det är därför det finns en patch out i det här fallet.)
3. Som du säger, det finns ett BTC 50-alternativ (det är $1m nu; det var $2m när den här första historien först bröts). Tydligen om QNAP betalar $1,000,000 XNUMX XNUMX på uppdrag av någon som kan ha blivit infekterad, kommer skurkarna att tillhandahålla en huvuddekrypteringsnyckel, om du inte har något emot det.
Och om du tittar på deras JavaScript, kontrollerar den faktiskt om lösenordet du anger matchar en av *två* hash.
En är unik för din infektion – skurkarna anpassar den varje gång, så JavaScript har hash i sig och ger inte bort lösenordet.
Och det finns en annan hash som, om du kan knäcka den, ser ut som om den skulle återställa huvudlösenordet för alla i världen...
… Jag tror att det bara var skurkarna som tummade på näsan åt alla.
DOUG. Det är också intressant att $600 bitcoin-lösensumman för varje användare är... Jag vill inte säga "inte upprörande", men om du tittar i kommentarsavsnittet i den här artikeln finns det flera personer som inte bara pratar om att ha betalat lösen…
…men låt oss hoppa vidare till vår läsarfråga här.
Läsaren Michael delar med sig av sin erfarenhet av denna attack, och han är inte ensam – det finns andra personer i det här kommentarsavsnittet som rapporterar liknande saker.
Över ett par kommentarer säger han (jag ska typ göra en uppriktig kommentar av det):
"Jag har varit med om det här och kom ut OK efter att ha betalat lösensumman. Att hitta den specifika returkoden med min dekrypteringsnyckel var den svåraste delen. Lärde mig den mest värdefulla läxan.”
I sin nästa kommentar går han igenom alla steg han behövde ta för att faktiskt få saker att fungera igen.
Och han kliver av med:
"Jag skäms över att säga att jag jobbar inom IT, har varit det i 20+ år och blev biten av detta QNAP uPNP-fel. Glad att vara igenom det."
ANKA. Wow, ja, det är ett ganska uttalande, eller hur?
Nästan som om han säger, "Jag skulle ha backat mig själv mot dessa skurkar, men jag förlorade vadet och det kostade mig $600 och en hel del tid."
Aaargh!
DOUG. Vad menar han med "den specifika returkoden med hans beskrivningsnyckel"?
ANKA. Ah, ja, det är väldigt intressant... väldigt spännande. (Jag försöker att inte säga fantastiskt-slash-briljant här.) [SKRATT]
Jag vill inte använda C-ordet och säga att det är "smart", men det är det typ.
Hur kontaktar du dessa skurkar? Behöver de en e-postadress? Kan det spåras? Behöver de en darkweb-sajt?
Det gör inte dessa skurkar.
För, kom ihåg, det finns en enhet, och skadlig programvara anpassas och paketeras när den attackerar den enheten så att den har en unik Bitcoin-adress.
Och i princip kommunicerar du med dessa skurkar genom att betala den angivna mängden bitcoin i deras plånbok.
Jag antar att det är därför de har hållit beloppet relativt blygsamt...
…Jag vill inte antyda att alla har $600 att slänga iväg mot en lösensumma, men det är inte som att du förhandlar i förväg för att avgöra om du ska betala $100,000 eller $80,000 eller $42,000.
Du betalar dem beloppet ... ingen förhandling, ingen chatt, ingen e-post, inga snabbmeddelanden, inget supportforum.
Du skickar bara pengarna till den angivna bitcoin-adressen, och de kommer uppenbarligen att ha en lista över dessa bitcoin-adresser som de övervakar.
När pengarna kommer, och de ser att de har kommit, vet de att du (och bara du) har betalat, eftersom den plånbokskoden är unik.
Och de gör sedan vad som i praktiken är (jag använder de största luftpriserna i världen) en "återbetalning" på blockkedjan, med hjälp av en bitcoin-transaktion till ett belopp, Doug, noll dollar.
Och det svaret, den transaktionen, innehåller faktiskt en kommentar. (Kom ihåg Hacka Poly Networks? De använde Ethereum blockchain-kommentarer för att försöka säga, "Kära, herr White Hat, kommer du inte att ge oss alla pengarna tillbaka?")
Så du betalar skurkarna och ger alltså meddelandet att du vill engagera dig med dem, och de betalar tillbaka $0 plus en kommentar på 32 hexadecimala tecken...
…som är 16 råa binära byte, vilket är den 128 bitars dekrypteringsnyckel du behöver.
Det är så man pratar med dem.
Och tydligen har de det här nere på ett T – som Michael sa, bluffen fungerar.
Och det enda problemet Michael hade var att han inte var van vid att köpa bitcoins, eller att arbeta med blockchain-data och extrahera den returkoden, vilket i princip är kommentaren i transaktionens "betalning" som han får tillbaka för $0.
Så, de använder teknik på mycket slingrande sätt.
I grund och botten använder de blockkedjan både som ett betalningsmedel och som ett kommunikationsverktyg.
DOUG. Okej, verkligen en väldigt intressant historia.
Vi kommer att hålla ett öga på det.
Och tack så mycket, Michael, för att du skickade in den kommentaren.
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: @NakedSecurity.
Det är vår show för idag – tack så mycket för att du lyssnade.
För Paul Ducklin, jag är Doug Aamoth, påminner dig, tills nästa gång, att...
BÅDE. Håll dig säker.
[MUSIKALT MODEM]
- blockchain
- coingenius
- cryptocurrency plånböcker
- kryptoväxling
- Cybersäkerhet
- cyberbrottslighet
- nätbrottslingar
- Cybersäkerhet
- deadbolt
- säkerhetstjänsten
- digitala plånböcker
- brandvägg
- kaspersky
- malware
- Mcafee
- Naken säkerhet
- Naken säkerhetspodcast
- NexBLOC
- plato
- plato ai
- Platon Data Intelligence
- Platon spel
- PlatonData
- platogaming
- podcast
- Ransomware
- VPN
- webbplats säkerhet
- zephyrnet
- Zero Day
