S3 Ep100: Browser-in-the-Browser – sådan opdager du et angreb [Lyd + tekst]

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

DOUG.  Deadbolt – den er tilbage!

Patches i massevis!

Og tidszoner... ja, tidszoner.

Alt det, og mere, på Naked Security Podcast.

[MUSIK MODEM]

Velkommen til podcasten alle sammen.

Jeg er Doug Aamoth.

Med mig er som altid Paul Ducklin.

Paul, en meget glad 100. episode til dig, min ven!

---

AND.  Wow, Doug!

Du ved, da jeg startede min mappestruktur til Series 3, brugte jeg dristigt -001 til første afsnit.

---

DOUG.  Jeg gjorde ikke. [griner]

---

AND.  Ikke -1 or -01.

---

DOUG.  smart…

---

AND.  Jeg havde stor tro!

Og når jeg gemmer dagens fil, kommer jeg til at glæde mig over den.

---

DOUG.  Ja, og jeg vil frygte det, fordi det dukker op til toppen.

Nå, jeg bliver nødt til at forholde mig til det senere...

---

AND.  Du kan omdøbe alle de andre ting.

---

DOUG.  Jeg ved, jeg ved det.

[Mumler] Jeg ser ikke frem til det... der går min onsdag.

Uanset hvad, lad os starte showet med noget teknisk historie.

Denne uge, den 12. september 1959, Luna 2, Også kendt som Anden sovjetiske kosmiske raket, blev det første rumfartøj, der nåede Månens overflade, og det første menneskeskabte objekt, der fik kontakt med et andet himmellegeme.

Meget cool.

---

AND.  Hvad var det lange navn?

"Den anden sovjetiske kosmiske raket"?

---

DOUG.  Ja.

---

AND.  Luna to er meget bedre.

---

DOUG.  Ja, meget bedre!

---

AND.  Tilsyneladende, som du kan forestille dig, i betragtning af at det var rumkapløbets æra, var der en vis bekymring for, "Hvordan kan vi vide, at de rent faktisk har gjort det? De kunne bare sige, at de er landet på Månen, og måske finder de på det."

Tilsyneladende udtænkte de en protokol, der ville tillade uafhængig observation.

De forudsagde tidspunktet, hvor det ville ankomme til Månen, for at styrte ind i Månen, og de sendte det nøjagtige tidspunkt, hvor de forventede dette, til en astronom i Storbritannien.

Og han observerede uafhængigt for at se, om det, de sagde, *ville* ske på det tidspunkt * skete.

Så de tænkte endda på, "Hvordan bekræfter man sådan noget?"

---

DOUG.  Nå, hvad angår komplicerede ting, har vi patches fra Microsoft og Apple.

Så hvad er bemærkelsesværdigt her i denne seneste runde?

---

AND.  Det gør vi bestemt – det er patch-tirsdag i denne uge, den anden tirsdag i måneden.

Der er to sårbarheder i Patch Tuesday, der var bemærkelsesværdige for mig.

Den ene er bemærkelsesværdig, fordi den tilsyneladende er i naturen - med andre ord var det en nul-dag.

Og selvom det ikke er fjernudførelse af kode, er det lidt bekymrende, fordi det er en logfilsårbarhed, Doug!

Det er ikke helt som dårlig som Log4J, hvor du ikke kun kunne få loggeren til at opføre sig forkert, du kunne også få den til køre vilkårlig kode til dig.

Men det ser ud til, at hvis du sender en form for misdannede data ind i Windows Common Log File System-driveren, CLFS, så kan du narre systemet til at forfremme dig til systemprivilegier.

Altid dårligt, hvis du er kommet ind som gæstebruger, og du så kan gøre dig selv til en sysadmin...

---

DOUG.  [GLAT] Ja!

---

AND.  Det er CVE-2022-37969.

Og den anden, som jeg fandt interessant...

…heldigvis ikke i naturen, men det er den, du virkelig skal lappe, for jeg vil vædde på, at det er den, som cyberkriminelle vil fokusere på omvendt udvikling:

"Windows TCP/IP fjernudførelse af kodesårbarhed", CVE-2022-34718.

Hvis du husker det Kode Rødog SQL Slammer, og de frække orme fra fortiden, hvor de lige ankom i en netværkspakke, og jammede sig ind i systemet….

Dette er et endnu lavere niveau end det.

Tilsyneladende er fejlen i håndteringen af ​​visse IPv6-pakker.

Så alt, hvor IPv6 lytter, hvilket stort set er enhver Windows-computer, kan være i fare som følge af dette.

Som jeg sagde, den er ikke i naturen, så skurkene har ikke fundet den endnu, men jeg tvivler ikke på, at de vil tage lappen og forsøge at finde ud af, om de kan omvendt udvikle en udnyttelse fra den, at fange folk, der ikke har lappet endnu.

For hvis noget siger: "Wow! Hvad hvis nogen skrev en orm, der brugte dette?”... det er den, jeg ville være bekymret over.

---

DOUG.  OK.

Og så til Apple...

---

AND.  Vi har skrevet to historier om Apple-patches for nylig, hvor der ud af det blå pludselig var patches til iPhones og iPads og Macs mod to i-det-vilde nul-dage.

Den ene var en browserfejl eller en browserrelateret fejl, så du kunne vandre ind på et uskyldigt udseende websted, og malware kunne lande på din computer, plus en anden, der gav dig kontrol på kerneniveau...

…hvilket, som jeg sagde i sidste podcast, lugter af spyware for mig – noget som en spyware-leverandør eller en virkelig seriøs "overvågnings-cyberskurk" ville være interesseret i.

Så var der en anden opdatering, til vores overraskelse, til iOS 12, som vi alle troede var blevet forladt for længst.

Der fik en af ​​disse fejl (den browserrelaterede, der tillod skurke at bryde ind) en patch.

Og så, lige da jeg ventede iOS 16, begyndte alle disse e-mails pludselig at lande i min indbakke - lige efter jeg havde tjekket, "Er iOS 16 ude endnu? Kan jeg opdatere til det?"

Det var der ikke, men så fik jeg alle disse e-mails, der sagde: "Vi har lige opdateret iOS 15 og macOS Monterey og Big Sur og iPadOS 15"...

… og det viste sig, at der var en hel masse opdateringer, plus en helt ny kerne zero-day denne gang også.

Og det fascinerende er, at efter jeg fik notifikationerne, tænkte jeg: "Nå, lad mig tjekke igen..."

(Så du kan huske, det er Indstillinger > Generelt > softwareopdatering på din iPhone eller iPad.)

Se, jeg blev tilbudt en opdatering til iOS 15, som jeg allerede havde, *eller* jeg kunne springe hele vejen til iOS 16.

Og iOS 16 havde også denne nul-dages rettelse i sig (selvom iOS 16 teoretisk set ikke var ude endnu), så jeg gætter på, at fejlen også fandtes i betaen.

Det var ikke opført som officielt en nul-dag i Apples bulletin til iOS 16, men vi kan ikke sige, om det er fordi den udnyttelse, Apple så ikke helt fungerede ordentligt på iOS 16, eller om den ikke betragtes som en nul- dag, fordi iOS 16 først lige var på vej.

---

DOUG.  Ja, jeg havde tænkt mig at sige: ingen har det endnu. [LATTER]

---

AND.  Det var den store nyhed fra Apple.

Og det vigtige er, at når du går til din telefon, og du siger, "Åh, iOS 16 er tilgængelig"... hvis du ikke er interesseret i iOS 16 endnu, skal du stadig sikre dig, at du har den iOS 15 opdatering på grund af kernen zero-day.

Kernel nul dage er altid et problem, fordi det betyder, at nogen derude ved, hvordan man omgår de meget roste sikkerhedsindstillinger på din iPhone.

Fejlen gælder også for macOS Monterey og macOS Big Sur – det er den tidligere version, macOS 11.

Faktisk, for ikke at blive overgået, har Big Sur faktisk *to* kernel zero-day bugs i naturen.

Ingen nyheder om iOS 12, hvilket er noget af det, jeg forventede, og intet indtil videre for macOS Catalina.

Catalina er macOS 10, den tidligere version, og endnu en gang ved vi ikke, om den opdatering kommer senere, eller om den er faldet uden for verdens kant og alligevel ikke får opdateringer.

Desværre siger Apple det ikke, så vi ved det ikke.

Nu vil de fleste Apple-brugere have automatiske opdateringer slået til, men som vi altid siger, gå og tjek (om du har en Mac eller en iPhone eller en iPad), for det værste er bare at antage, at din automatiske opdateringer virkede og holdt dig sikker...

…når der faktisk gik noget galt.

---

DOUG.  Okay, meget godt.

Nu er noget, jeg har glædet mig til, og bevæger mig med det samme: "Hvad har tidszoner med it-sikkerhed at gøre?"

---

AND.  Tja, en hel del, viser det sig, Doug.

---

DOUG.  [GRNER] Yessir!

---

AND.  Tidszoner er meget enkle i konceptet.

De er meget praktiske til at styre vores liv, så vores ure nogenlunde matcher, hvad der sker på himlen – så det er mørkt om natten og lyst om dagen. (Lad os ignorere sommertid, og lad os bare antage, at vi kun har en times tidszoner rundt om i verden, så alt er virkelig enkelt.)

Problemet kommer, når du rent faktisk fører systemlogfiler i en organisation, hvor nogle af dine servere, nogle af dine brugere, nogle dele af dit netværk, nogle af dine kunder, er i andre dele af verden.

Når du skriver til logfilen, skriver du så tiden med tidszonen indregnet?

Når du skriver din log, Doug, trækker du de 5 timer (eller 4 timer i øjeblikket), du har brug for, fordi du er i Boston, hvorimod jeg tilføjer en time, fordi jeg er på London-tid, men det er sommer ?

Skriver jeg det i loggen, så det giver mening for *mig*, når jeg læser loggen tilbage?

Eller skriver jeg en mere kanonisk, utvetydig tid ved at bruge den samme tidszone for *alle*, så når jeg sammenligner logfiler, der kommer fra forskellige computere, forskellige brugere, forskellige dele af verden på mit netværk, kan jeg faktisk stille begivenheder på linje?

Det er virkelig vigtigt at opstille begivenheder, Doug, især hvis du reagerer på trusler i et cyberangreb.

Du skal virkelig vide, hvad der kom først.

Og hvis du siger, "Åh, det skete ikke før kl. 3", hjælper det mig ikke, hvis jeg er i Sydney, for min kl. 3 skete i går sammenlignet med jeres kl. 3.

Så jeg skrev en artikel på Naked Security om nogle måder, du kan håndtere dette problem når du logger data.

Min personlige anbefaling er at bruge et forenklet tidsstempelformat kaldet RFC 3339, hvor du sætter et firecifret årstal, bindestreg [bindestreg, ASCII 0x2D], tocifret måned, bindestreg, tocifret dag og så videre, så dine tidsstempler faktisk sorterer alfabetisk pænt.

Og at du optager alle dine tidszoner som en tme-zone kendt som Z (zed eller zee), forkortelse for Zulu tid.

Det betyder grundlæggende UTC eller Coordinated Universal Time.

Det er næsten-men-ikke-helt Greenwich Mean Time, og det er det tidspunkt, som næsten enhver computers eller telefons ur faktisk er indstillet til internt i disse dage.

Forsøg ikke at kompensere for tidszoner, når du skriver til loggen, for så bliver nogen nødt til at dekompensere, når de forsøger at bringe din log op på linje med alle andres – og der er mange en smutter, der drejer koppen og læben, Doug.

Hold det simpelt.

Brug et kanonisk, simpelt tekstformat, der afgrænser nøjagtigt datoen og klokkeslættet, helt ned til anden – eller i disse dage kan tidsstempler endda gå ned i disse dage til nanosekund, hvis du vil.

Og slip for tidszoner fra dine logfiler; slippe af med sommertid fra dine logfiler; og bare optag alt, efter min mening, i Coordinated Universal Time...

…til forveksling forkortet UTC, fordi navnet er på engelsk, men forkortelsen er på fransk – noget af en ironi.

---

DOUG.  Ja.

---

AND.  
Jeg er fristet til at sige, "Ikke at jeg føler stærkt for det igen", som jeg plejer, grinende...

…men det er virkelig vigtigt at få tingene i den rigtige rækkefølge, især når du forsøger at opspore cyberkriminelle.

---

DOUG.  Okay, det er godt – godt råd.

Og hvis vi holder os til emnet cyberkriminelle, har du hørt om Manipulator-in-the-Middle-angreb; du har hørt om Manipulator-in-the-Browser-angreb...

..Gør dig nu klar til Browser-in-the-Browser-angreb.

---

AND.  Ja, det er et nyt udtryk, vi ser.

Jeg ville skrive dette op, fordi forskere hos et trusselsefterretningsfirma kaldet Group-IB for nylig skrev en artikel om dette, og medierne begyndte at tale om, "Hey, Browser-in-the-Browser-angreb, vær meget bange", eller hvad nu …

Du tænker, "Nå, jeg spekulerer på, hvor mange mennesker egentlig ved, hvad der menes med et Browser-in-the-Browser-angreb?"

Og det irriterende ved disse angreb, Doug, er, at teknologisk set er de frygtelig enkle.

Det er så simpel en idé.

---

DOUG.  De er næsten kunstneriske.

---

AND.  Ja!

Det er ikke rigtig videnskab og teknologi, det er kunst og design, er det ikke?

Dybest set, hvis du nogensinde har lavet JavaScript-programmering (på godt og ondt), vil du vide, at en af ​​de ting ved ting, du sætter ind på en webside, er, at det er meningen, at det skal være begrænset til den pågældende webside.

Så hvis du popper et helt nyt vindue op, så forventer du, at det får en helt ny browserkontekst.

Og hvis den indlæser sin side fra et helt nyt websted, f.eks. et phishing-websted, så vil det ikke have adgang til alle JavaScript-variabler, kontekst, cookies og alt, hvad hovedvinduet havde.

Så hvis du åbner et separat vindue, begrænser du på en måde dine hacking-evner, hvis du er en skurk.

Men hvis du åbner noget i det aktuelle vindue, så er du markant begrænset med hensyn til, hvor spændende og "systemagtigt" du kan få det til at se ud, er du ikke?

Fordi du ikke kan overskrive adresselinjen... det er designet.

Du kan ikke skrive noget uden for browservinduet, så du kan ikke snigende lægge et vindue, der ligner tapet, på skrivebordet, som om det har været der hele tiden.

Med andre ord, du er inde i browservinduet, som du startede med.

Så ideen med et Browser-in-the-Browser-angreb er, at du starter med et almindeligt websted, og derefter opretter du, inde i det browservindue, du allerede har, en webside, der i sig selv ligner et operativsystems browservindue .

Dybest set viser du nogen et *billede* af den ægte vare og overbeviser dem om, at det *er* den ægte vare.

Så enkelt er det inderst inde, Doug!

Men problemet er, at med lidt omhyggeligt arbejde, især hvis du har gode CSS-færdigheder, *kan* du faktisk få noget, der er inde i et eksisterende browservindue, til at ligne et eget browservindue.

Og med en smule JavaScript kan du endda lave den, så den kan ændre størrelsen, og så den kan flytte rundt på skærmen, og du kan udfylde den med HTML, som du henter fra en tredjeparts hjemmeside.

Nu kan du undre dig... hvis skurkene får det rigtigt, hvordan i alverden kan du så nogensinde vide det?

Og den gode nyhed er, at der er en helt simpel ting, du kan gøre.

Hvis du ser, hvad der ligner et operativsystemvindue, og du er mistænksom over for det på nogen måde (det ser i det væsentlige ud til at dukke op over dit browservindue, fordi det skal være inde i det)...

…prøv at flytte den *fra det rigtige browservindue*, og hvis den er "fængslet" inde i browseren, ved du, at det ikke er den rigtige ting!

Det interessante ved rapporten fra Group-IB-forskerne er, at da de stødte på dette, brugte skurkene det faktisk mod spillere af Steam-spil.

Og selvfølgelig vil den have dig til at logge ind på din Steam-konto...

...og hvis du blev narre af den første side, så ville den endda følge op med Steams to-faktor-godkendelsesbekræftelse.

Og tricket var, at hvis disse virkelig *var* separate vinduer, kunne du have trukket dem til den ene side af dit hovedbrowservindue, men det var de ikke.

I dette tilfælde havde kokkene heldigvis ikke gjort deres CSS særlig godt.

Deres kunst var sjusket.

Men som du og jeg har talt om mange gange på podcasten, Doug, er der nogle gange skurke, der vil gøre en indsats for at få tingene til at se pixel-perfekte ud.

Med CSS kan du bogstaveligt talt placere individuelle pixels, ikke?

---

DOUG.  CSS er interessant.

Det er Cascading Style Sheets… et sprog, du bruger til at style HTML-dokumenter, og det er virkelig nemt at lære, og det er endnu sværere at mestre.

---

AND.  [GRNER] Det lyder helt sikkert som DET.

---

DOUG.  [GRNER] Ja, det er ligesom mange ting!

Men det er en af ​​de første ting, du lærer, når du først lærer HTML.

Hvis du tænker, "Jeg vil gerne få denne webside til at se bedre ud", lærer du CSS.

Så ser du på nogle af disse eksempler på kildedokumentet, som du linkede til fra artiklen, kan du se, at det bliver rigtig svært at lave en rigtig god falsk, medmindre du er rigtig god til CSS.

Men hvis du gør det rigtigt, bliver det virkelig svært at finde ud af, at det er et falsk dokument...

…medmindre du gør som du siger: prøv at trække den ud af et vindue og flytte den rundt på dit skrivebord, sådan noget.

Det fører til dit andet punkt her: undersøg mistænkelige vinduer omhyggeligt.

Mange af dem vil sandsynligvis ikke bestå øjentesten, men hvis de gør det, bliver det virkelig svært at få øje på.

Hvilket fører os til den tredje ting...

"Hvis du er i tvivl/giv det ikke."

Hvis det bare ikke ser rigtigt ud, og du ikke er i stand til endeligt at se, at noget er mærkeligt er på vej, skal du bare følge rimet!

---

AND.  Og det er værd at være mistænksom over for ukendte websteder, websteder, du ikke har brugt før, der pludselig siger: "OK, vi vil bede dig om at logge ind med din Google-konto i et Google-vindue eller Facebook i et Facebook-vindue. ”

Eller Steam i et Steam-vindue.

---

DOUG.  Ja.

Jeg hader at bruge B-ordet her, men det er næsten genialt i sin enkelthed.

Men igen, det bliver virkelig svært at få et pixel-perfekt match ved hjælp af CSS og sådan noget.

---

AND.  Jeg tror, ​​det er vigtigt at huske, at fordi en del af simuleringen er "chrome" [jargonen for browserens brugergrænsefladekomponenter] i browseren, vil adresselinjen se rigtig ud.

Det kan endda se perfekt ud.

Men sagen er, at det ikke er en adresselinje...

…det er et *billede* af en adresselinje.

---

DOUG.  Nøjagtig!

Okay, forsigtig derude, alle sammen!

Og når vi taler om ting, der ikke er, som de ser ud, så læser jeg om DEADBOLT ransomware og QNAP NAS-enheder, og det føles for mig, som om vi lige har diskuteret denne nøjagtige historie for ikke længe siden.

---

AND.  Ja, det har vi skrevet om dette flere gange på Naked Security indtil videre i år, desværre.

Det er et af de tilfælde, hvor det, der virkede for skurkene én gang, viser sig at have virket to gange, tre gange, fire gange, fem gange.

Og NAS, eller Network Attached Storage enheder, er, hvis du vil, black-box-servere, som du kan gå og købe – de kører typisk en slags Linux-kerne.

Ideen er, at i stedet for at skulle købe en Windows-licens eller lære Linux, skal du installere Samba, sætte det op, lære at dele fil på dit netværk...

… du bare tilslutter denne enhed, og "Bingo", den begynder at virke.

Det er en web-tilgængelig filserver, og hvis der er en sårbarhed i filserveren, og du (ved et uheld eller design) har gjort den tilgængelig via internettet, kan skurke muligvis udnytte denne sårbarhed, hvis der er en i denne NAS-enhed på afstand.

De kan muligvis kryptere alle filerne på nøglelagerpladsen til dit netværk, uanset om det er et hjemmenetværk eller et lille virksomhedsnetværk, og dybest set holde dig til løsesum uden nogensinde at skulle bekymre dig om at angribe individuelle andre enheder som bærbare computere og telefoner på din netværk.

Så de behøver ikke rode rundt med malware, der inficerer din bærbare computer, og de behøver ikke at bryde ind i dit netværk og vandre rundt som traditionelle ransomware-kriminelle.

De forvrider stort set alle dine filer, og så – for at præsentere løsesumsedlen – ændrer de sig bare (jeg burde ikke grine, Doug)... de ændrer bare login-siden på din NAS-enhed.

Så når du opdager, at alle dine filer er rodet, og du tænker, "Det er sjovt", og du hopper ind med din webbrowser og forbinder der, får du ikke en adgangskodeprompt!

Du får en advarsel: "Dine filer er blevet låst af DEADBOLT. Hvad skete der? Alle dine filer er blevet krypteret."

Og så kommer instruktionerne om, hvordan du betaler.

---

DOUG.  Og de har også venligt tilbudt, at QNAP kunne stille en fyrstelig sum op for at låse filerne op for alle.

---

AND.  Skærmbillederne jeg har i nyeste artikel på nakedsecurity.sophos.com viser:

1. Individuelle dekrypteringer på 0.03 bitcoins, oprindeligt omkring US$1200, da denne ting først blev udbredt, nu omkring US$600.

2. En BTC 5.00-mulighed, hvor QNAP får at vide om sårbarheden, så de kan rette den, som de tydeligvis ikke kommer til at betale, fordi de allerede kender til sårbarheden. (Det er derfor, der er en patch ud i dette særlige tilfælde.)

3. Som du siger, er der en BTC 50-mulighed (det er $1 mio nu; det var $2m, da denne første historie brød først). Hvis QNAP tilsyneladende betaler de 1,000,000 $ på vegne af nogen, der kunne være blevet inficeret, vil skurkene give en hoveddekrypteringsnøgle, hvis du ikke har noget imod det.

Og hvis du ser på deres JavaScript, tjekker den faktisk, om den adgangskode, du indtaster, matcher en af ​​*to* hashes.

Den ene er unik for din infektion – skurkene tilpasser den hver gang, så JavaScript'et har hashen i sig og ikke giver adgangskoden væk.

Og der er en anden hash, der, hvis du kan knække den, ser ud som om den ville gendanne hovedadgangskoden for alle i verden...

… Jeg tror, ​​det var bare skurkene, der tumlede på næsen af ​​alle.

---

DOUG.  Det er også interessant, at $600 bitcoin løsesummen for hver bruger er... Jeg vil ikke sige "ikke skandaløst", men hvis du ser i kommentarfeltet i denne artikel, er der flere mennesker, der ikke kun taler om at have betalt løsepenge…

…men lad os springe videre til vores læserspørgsmål her.

Læseren Michael deler sin erfaring med dette angreb, og han er ikke alene – der er andre personer i denne kommentarsektion, der rapporterer lignende ting.

På tværs af et par kommentarer siger han (jeg har tænkt mig at komme med en åbenhjertig kommentar ud af det):

"Jeg har været igennem det her, og kom ud OK efter at have betalt løsesummen. At finde den specifikke returkode med min dekrypteringsnøgle var den sværeste del. Har lært den mest værdifulde lektie."

I sin næste kommentar gennemgår han alle de trin, han skulle tage for rent faktisk at få tingene til at fungere igen.

Og han stiger af med:

“Jeg er flov over at sige, at jeg arbejder i IT, har været det i 20+ år og blev bidt af denne QNAP uPNP-fejl. Glad for at være igennem det."

---

AND.  Wow, ja, det er noget af et statement, ikke?

Næsten som om han siger: "Jeg ville have støttet mig selv mod disse skurke, men jeg tabte væddemålet, og det kostede mig $600 og en hel masse tid."

Aaargh!

---

DOUG.  Hvad mener han med "den specifikke returkode med hans beskrivelsesnøgle"?

---

AND.  Åh, ja, det er meget interessant... meget spændende. (Jeg prøver ikke at sige fantastisk-skråstreg-strålende her.) [LATER]

Jeg vil ikke bruge C-ordet og sige, at det er "klogt", men det er det sådan set.

Hvordan kontakter du disse skurke? Har de brug for en e-mailadresse? Kan det spores? Har de brug for et darkweb-site?

Det gør disse skurke ikke.

For husk, der er én enhed, og malwaren tilpasses og pakkes, når den angriber den enhed, så den har en unik Bitcoin-adresse.

Og dybest set kommunikerer du med disse skurke ved at betale den angivne mængde bitcoin ind i deres tegnebog.

Jeg gætter på, at det er derfor, de har holdt beløbet forholdsvis beskedent...

…Jeg vil ikke antyde, at alle har $600 at smide væk som løsesum, men det er ikke sådan, at du forhandler på forhånd for at afgøre, om du skal betale $100,000 eller $80,000 eller $42,000.

Du betaler dem beløbet ... ingen forhandling, ingen chat, ingen e-mail, ingen instant messaging, ingen supportforum.

Du sender bare pengene til den angivne bitcoin-adresse, og de vil naturligvis have en liste over de bitcoin-adresser, de overvåger.

Når pengene kommer, og de ser, at de er ankommet, ved de, at du (og du alene) har betalt, for den pungkode er unik.

Og så gør de, hvad der i virkeligheden er (jeg bruger de største luftpriser i verden) en "refusion" på blockchainen, ved at bruge en bitcoin-transaktion til et beløb, Doug, på nul dollars.

Og det svar, den transaktion, indeholder faktisk en kommentar. (Husk Poly Networks hack? De brugte Ethereum blockchain-kommentarer til at prøve at sige, "Kære, hr. White Hat, vil du ikke give os alle pengene tilbage?")

Så du betaler skurkene og giver dermed beskeden om, at du vil engagere dig med dem, og de betaler dig $0 tilbage plus en kommentar på 32 hexadecimale tegn...

…som er 16 rå binære bytes, som er den 128 bit dekrypteringsnøgle, du har brug for.

Sådan taler man til dem.

Og tilsyneladende har de det ned til et T – som Michael sagde, så virker fidusen.

Og det eneste problem, Michael havde, var, at han ikke var vant til at købe bitcoins eller arbejde med blockchain-data og udtrække den returkode, hvilket i bund og grund er kommentaren i transaktionens "betaling", som han får tilbage for $0.

Så de bruger teknologien på meget snedige måder.

Dybest set bruger de blockchain både som betalingsmiddel og som kommunikationsværktøj.

---

DOUG.  Okay, en meget interessant historie.

Det vil vi holde øje med.

Og mange tak, Michael, for at sende den kommentar.

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, at...

---

BEGGE.  Bliv sikker.

[MUSIK MODEM]