S3 Ep100: Nettleser-i-nettleseren – hvordan oppdage et angrep [lyd + tekst]

Klikk og dra på lydbølgene nedenfor for å hoppe til et hvilket som helst punkt. Du kan også lytte direkte på Soundcloud.

DOUG.  Deadbolt – den er tilbake!

Lapper i massevis!

Og tidssoner... ja, tidssoner.

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

[MUSIKK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug Aamoth.

Med meg er som alltid Paul Ducklin.

Paul, en veldig glad episode nummer 100 til deg, min venn!

---

AND.  Wow, Doug!

Du vet, da jeg startet katalogstrukturen min for Series 3, brukte jeg dristig -001 for første episode.

---

DOUG.  Jeg gjorde ikke. [LETER]

---

AND.  Non -1 or -01.

---

DOUG.  Smart…

---

AND.  Jeg hadde stor tro!

Og når jeg lagrer dagens fil, kommer jeg til å glede meg over den.

---

DOUG.  Ja, og jeg kommer til å grue meg fordi den dukker opp til toppen.

Vel, jeg må forholde meg til det senere...

---

AND.  [LAUGGER] Du kan gi nytt navn til alle de andre tingene.

---

DOUG.  Jeg vet jeg vet.

[MUMLING] Gleder meg ikke til det … der går onsdagen min.

Uansett, la oss starte showet med litt teknisk historie.

Denne uken, 12. september 1959, Luna 2, Også kjent som Den andre sovjetiske kosmiske raketten, ble det første romfartøyet som nådde Månens overflate, og det første menneskeskapte objektet som tok kontakt med et annet himmellegeme.

Veldig kult.

---

AND.  Hva var det lange navnet?

"Den andre sovjetiske kosmiske raketten"?

---

DOUG.  Ja.

---

AND.  Luna to er mye bedre.

---

DOUG.  Ja, mye bedre!

---

AND.  Tilsynelatende, som du kan forestille deg, gitt at det var romkappløpstiden, var det en viss bekymring for: «Hvordan skal vi vite at de faktisk har gjort det? De kan bare si at de har landet på månen, og kanskje de finner på det.»

Tilsynelatende utviklet de en protokoll som ville tillate uavhengig observasjon.

De spådde tidspunktet da det ville komme til Månen, for å krasje inn i Månen, og de sendte den nøyaktige tiden de forventet dette til en astronom i Storbritannia.

Og han observerte uavhengig for å se om det de sa *ville* skje på den tiden *hendte*.

Så de tenkte til og med på: "Hvordan bekrefter du noe slikt?"

---

DOUG.  Vel, når det gjelder kompliserte ting, har vi oppdateringer fra Microsoft og Apple.

Så hva er bemerkelsesverdig her i denne siste runden?

---

AND.  Det gjør vi absolutt – det er patch tirsdag denne uken, den andre tirsdagen i måneden.

Det er to sårbarheter i Patch Tuesday som var bemerkelsesverdige for meg.

En er bemerkelsesverdig fordi den tilsynelatende er i naturen - med andre ord, det var en null-dag.

Og selv om det ikke er ekstern kjøring av kode, er det litt bekymringsfullt fordi det er et [HOSTER UNSKYLDIGT] loggfilsårbarhet, Doug!

Det er ikke helt som dårlig som Log4J, hvor du ikke bare kunne få loggeren til å oppføre seg feil, du kan også få den til kjøre vilkårlig kode for deg.

Men det ser ut til at hvis du sender en slags misformet data inn i Windows Common Log File System-driveren, CLFS, så kan du lure systemet til å promotere deg til systemprivilegier.

Alltid dårlig hvis du har kommet inn som gjestebruker, og du kan gjøre deg om til en systemadministrator...

---

DOUG.  [LATER] Ja!

---

AND.  Det er CVE-2022-37969.

Og den andre som jeg fant interessant...

...heldigvis ikke i naturen, men dette er den du virkelig trenger å lappe, fordi jeg vedder på at det er den nettkriminelle vil fokusere på omvendt utvikling:

"Sårbarhet for ekstern kjøring av Windows TCP/IP-kode", CVE-2022-34718.

Hvis du husker Kode Rødog SQL Slammer, og de slemme ormene fra fortiden, der de nettopp ankom i en nettverkspakke, og kjørte seg inn i systemet...

Dette er et enda lavere nivå enn det.

Tilsynelatende er feilen i håndteringen av visse IPv6-pakker.

Så alt der IPv6 lytter, som er stort sett alle Windows-datamaskiner, kan være utsatt for dette.

Som jeg sa, den er ikke i naturen, så skurkene har ikke funnet den ennå, men jeg tviler ikke på at de vil ta lappen og prøve å finne ut om de kan reversere en utnyttelse fra den, for å fange ut folk som ikke har lappet ennå.

For hvis noe sier: «Wow! Hva om noen skrev en orm som brukte dette?” … det er den jeg ville vært bekymret for.

---

DOUG.  OK.

Og så til Apple...

---

AND.  Vi har nylig skrevet to historier om Apple-patcher, der det helt ut av det blå plutselig var patcher for iPhone og iPad og Mac mot to i-the-ville null-dager.

En var en nettleserfeil, eller en nettleserrelatert feil, slik at du kunne vandre inn på et uskyldig utseende nettsted og skadevare kunne lande på datamaskinen din, pluss en annen som ga deg kontroll på kjernenivå...

…som, som jeg sa i den siste podcasten, lukter spyware for meg – noe som en spionvareleverandør eller en virkelig seriøs "overvåkingscyberskurk" ville være interessert i.

Så kom det en ny oppdatering, til vår overraskelse, for iOS 12, som vi alle trodde hadde vært forlatt for lenge siden.

Der fikk en av disse feilene (den nettleserrelaterte en som tillot skurker å bryte seg inn) en oppdatering.

Og så, akkurat da jeg ventet iOS 16, begynte alle disse e-postene plutselig å havne i innboksen min – rett etter at jeg sjekket: «Er iOS 16 ute ennå? Kan jeg oppdatere til det?"

Det var ikke der, men så fikk jeg alle disse e-postene som sa: "Vi har nettopp oppdatert iOS 15 og macOS Monterey og Big Sur og iPadOS 15"...

… og det viste seg at det var en hel haug med oppdateringer, pluss en helt ny kjerne zero-day denne gangen også.

Og det fascinerende er at etter at jeg fikk varslene, tenkte jeg: "Vel, la meg sjekke igjen ..."

(Så du kan huske, det er det innstillinger > general > programvare~~POS=TRUNC på iPhone eller iPad.)

Se, jeg ble tilbudt en oppdatering til iOS 15, som jeg allerede hadde, *eller* jeg kunne hoppe helt til iOS 16.

Og iOS 16 hadde også denne nulldagers-fiksen i seg (selv om iOS 16 teoretisk sett ikke var ute ennå), så jeg antar at feilen også fantes i betaversjonen.

Det ble ikke oppført som offisielt en null-dag i Apples bulletin for iOS 16, men vi kan ikke si om det er fordi utnyttelsen Apple så ikke helt fungerte ordentlig på iOS 16, eller om den ikke regnes som en null- dag fordi iOS 16 nettopp kom ut.

---

DOUG.  Ja, jeg hadde tenkt å si: ingen har det ennå. [LATTER]

---

AND.  Det var den store nyheten fra Apple.

Og det viktige er at når du går til telefonen din, og du sier: «Å, iOS 16 er tilgjengelig»... hvis du ikke er interessert i iOS 16 ennå, må du fortsatt sørge for at du har iOS 15 oppdatering, på grunn av kjernen zero-day.

Kjernen null dager er alltid et problem fordi det betyr at noen der ute vet hvordan de kan omgå de mye hyllede sikkerhetsinnstillingene på iPhone.

Feilen gjelder også for macOS Monterey og macOS Big Sur – det er den forrige versjonen, macOS 11.

Faktisk, for ikke å bli overgått, har Big Sur faktisk *to* kjernenulldagsfeil i naturen.

Ingen nyheter om iOS 12, som er omtrent det jeg forventet, og ingenting så langt for macOS Catalina.

Catalina er macOS 10, den tidligere versjonen, og nok en gang vet vi ikke om den oppdateringen kommer senere, eller om den har falt utenfor verdenskanten og ikke får oppdateringer uansett.

Dessverre sier ikke Apple det, så vi vet ikke.

Nå vil de fleste Apple-brukere ha automatiske oppdateringer slått på, men som vi alltid sier, gå og sjekk (enten du har en Mac eller en iPhone eller en iPad), for det verste er bare å anta at din automatiske oppdateringer fungerte og holdt deg trygg ...

…når det faktisk gikk galt.

---

DOUG.  Ok veldig bra.

Nå, noe jeg har gledet meg til, etter å ha gått videre, er: "Hva har tidssoner med IT-sikkerhet å gjøre?"

---

AND.  Vel, ganske mye, viser det seg, Doug.

---

DOUG.  [LETER] Yessir!

---

AND.  Tidssoner er veldig enkle i konseptet.

De er veldig praktiske for å styre livene våre slik at klokkene våre omtrent stemmer overens med det som skjer på himmelen – så det er mørkt om natten og lyst om dagen. (La oss ignorere sommertid, og la oss bare anta at vi bare har én times tidssoner over hele verden, slik at alt er veldig enkelt.)

Problemet kommer når du faktisk fører systemlogger i en organisasjon der noen av serverne dine, noen av brukerne dine, noen deler av nettverket ditt, noen av kundene dine, er i andre deler av verden.

Når du skriver til loggfilen, skriver du tiden med tidssonen innregnet?

Når du skriver loggen din, Doug, trekker du fra de 5 timene (eller 4 timene for øyeblikket) du trenger fordi du er i Boston, mens jeg legger til én time fordi jeg er på London-tid, men det er sommer ?

Skriver jeg det i loggen slik at det gir mening for *meg* når jeg leser loggen tilbake?

Eller skriver jeg en mer kanonisk, entydig tid ved å bruke samme tidssone for *alle*, så når jeg sammenligner logger som kommer fra forskjellige datamaskiner, forskjellige brukere, forskjellige deler av verden på nettverket mitt, kan jeg faktisk sette opp hendelser?

Det er veldig viktig å sette opp hendelser, Doug, spesielt hvis du utfører trusselrespons i et nettangrep.

Du må virkelig vite hva som kom først.

Og hvis du sier: "Å, det skjedde ikke før kl. 3", hjelper det meg ikke hvis jeg er i Sydney, fordi kl. 3 skjedde i går sammenlignet med kl. 3.

Så jeg Skrev en artikkel på Naked Security om noen måter du kan håndtere dette problemet når du logger data.

Min personlige anbefaling er å bruke et forenklet tidsstempelformat kalt RFC 3339, hvor du setter inn et firesifret årstall, bindestrek [bindestrek, ASCII 0x2D], tosifret måned, bindestrek, tosifret dag, og så videre, slik at tidsstemplene dine faktisk sorterer alfabetisk fint.

Og at du registrerer alle tidssonene dine som en tme-sone kjent som Z (zed eller zee), forkortelse for Zulu tid.

Det betyr i utgangspunktet UTC eller Coordinated Universal Time.

Det er nesten-men-ikke-helt Greenwich Mean Time, og det er tiden som nesten hver datamaskins eller telefons klokke er stilt inn på internt i disse dager.

Ikke prøv å kompensere for tidssoner når du skriver til loggen, for da vil noen måtte dekompensere når de prøver å stille opp loggen din med alle andres – og det er mange glipper som snur koppen og leppen, Doug.

Hold det enkelt.

Bruk et kanonisk, enkelt tekstformat som avgrenser nøyaktig dato og klokkeslett, helt ned til sekundet – eller i disse dager kan tidsstempler til og med gå ned i disse dager til nanosekund hvis du vil.

Og bli kvitt tidssoner fra loggene dine; bli kvitt sommertid fra loggene dine; og bare ta opp alt, etter min mening, i Coordinated Universal Time...

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

---

DOUG.  Ja.

---

AND.  
Jeg er fristet til å si: "Ikke det at jeg føler sterkt for det igjen", som jeg pleier å ler...

…men det er virkelig viktig å få ting i riktig rekkefølge, spesielt når du prøver å spore opp cyberkriminelle.

---

DOUG.  Greit, det er bra – gode råd.

Og hvis vi holder oss til temaet nettkriminelle, har du hørt om Manipulator-in-the-Middle-angrep; du har hørt om Manipulator-in-the-Browser-angrep ...

..nå gjør deg klar for nettleser-i-nettleser-angrep.

---

AND.  Ja, dette er et nytt begrep vi ser.

Jeg ønsket å skrive dette fordi forskere ved et trusseletterretningsselskap kalt Group-IB nylig skrev en artikkel om dette, og media begynte å snakke om "Hei, nettleser-angrep, vær veldig redd", eller hva det måtte være. …

Du tenker: "Vel, jeg lurer på hvor mange som faktisk vet hva som menes med et nettleser-i-nettleser-angrep?"

Og det irriterende med disse angrepene, Doug, er at teknologisk sett er de fryktelig enkle.

Det er en så enkel idé.

---

DOUG.  De er nesten kunstneriske.

---

AND.  Ja!

Det er egentlig ikke vitenskap og teknologi, det er kunst og design, er det ikke?

I utgangspunktet, hvis du noen gang har gjort JavaScript-programmering (på godt eller ondt), vil du vite at en av tingene med ting du legger inn på en nettside, er at det er ment å være begrenset til den nettsiden.

Så hvis du dukker opp et helt nytt vindu, forventer du at det får en helt ny nettleserkontekst.

Og hvis den laster inn siden fra et helt nytt nettsted, for eksempel et phishing-nettsted, vil det ikke ha tilgang til alle JavaScript-variablene, konteksten, informasjonskapslene og alt som hovedvinduet hadde.

Så hvis du åpner et eget vindu, begrenser du på en måte hacking-evnene dine hvis du er en kjeltring.

Men hvis du åpner noe i det gjeldende vinduet, er du betydelig begrenset til hvor spennende og "systemaktig" du kan få det til å se ut, er du ikke?

Fordi du ikke kan overskrive adressefeltet ... det er ved design.

Du kan ikke skrive noe utenfor nettleservinduet, så du kan ikke snikt sette et vindu som ser ut som bakgrunnsbilde på skrivebordet, som om det har vært der hele tiden.

Med andre ord, du er inne i nettleservinduet du startet med.

Så ideen med et nettleser-i-nettleser-angrep er at du starter med et vanlig nettsted, og deretter oppretter du, inne i nettleservinduet du allerede har, en nettside som i seg selv ser nøyaktig ut som et nettleservindu i operativsystemet. .

I utgangspunktet viser du noen et *bilde* av den virkelige tingen, og overbeviser dem om at den *er* den ekte varen.

Så enkelt er det i hjertet, Doug!

Men problemet er at med litt forsiktig arbeid, spesielt hvis du har gode CSS-ferdigheter, *kan* du faktisk få noe som er inne i et eksisterende nettleservindu til å se ut som et eget nettleservindu.

Og med litt JavaScript kan du til og med gjøre det slik at det kan endre størrelse, og slik at det kan flytte rundt på skjermen, og du kan fylle det med HTML som du henter fra en tredjeparts nettside.

Nå lurer du kanskje på... hvis kjeltringene får det til rett, hvordan i all verden kan du vite det?

Og den gode nyheten er at det er en helt enkel ting du kan gjøre.

Hvis du ser det som ser ut som et operativsystemvindu og du er mistenksom overfor det på noen måte (det ser ut til å dukke opp over nettleservinduet ditt, fordi det må være inne i det)...

...prøv å flytte den *fra det virkelige nettleservinduet*, og hvis den er "fengslet" inne i nettleseren, vet du at det ikke er den virkelige saken!

Det interessante med rapporten fra Group-IB-forskerne er at da de kom over dette, brukte skurkene det faktisk mot spillere av Steam-spill.

Og selvfølgelig vil den at du skal logge på Steam-kontoen din ...

...og hvis du ble lurt av den første siden, ville den til og med følge opp med Steams tofaktorautentiseringsverifisering.

Og trikset var at hvis disse virkelig *var* separate vinduer, kunne du ha dratt dem til den ene siden av hovednettleservinduet, men det var de ikke.

I dette tilfellet hadde kokkene heldigvis ikke gjort sin CSS særlig bra.

Kunstverket deres var lurt.

Men, som du og jeg har snakket om mange ganger på podcasten, Doug, noen ganger er det skurker som vil anstrenge seg for å få ting til å se pikselperfekte ut.

Med CSS kan du bokstavelig talt plassere individuelle piksler, kan du ikke?

---

DOUG.  CSS er interessant.

det er Cascading Style Sheets… et språk du bruker til å style HTML-dokumenter, og det er veldig enkelt å lære og det er enda vanskeligere å mestre.

---

AND.  [LAUGGER] Høres ut som DET, helt klart.

---

DOUG.  [LAUGGER] Ja, det er som mange ting!

Men det er noe av det første du lærer når du først har lært HTML.

Hvis du tenker «jeg vil få denne nettsiden til å se bedre ut», lærer du CSS.

Så når du ser på noen av disse eksemplene på kildedokumentet du lenket til fra artikkelen, kan du se at det kommer til å bli veldig vanskelig å gjøre en virkelig god falsk, med mindre du er veldig god på CSS.

Men hvis du gjør det riktig, vil det være veldig vanskelig å finne ut at det er et falskt dokument...

… med mindre du gjør som du sier: prøv å trekke den ut av et vindu og flytte den rundt på skrivebordet, sånne ting.

Det leder til ditt andre poeng her: undersøk mistenkte vinduer nøye.

Mange av dem kommer sannsynligvis ikke til å bestå øyetesten, men hvis de gjør det, vil det være veldig vanskelig å få øye på.

Som leder oss til den tredje tingen...

"Hvis du er i tvil/ikke gi det ut."

Hvis det bare ikke ser helt riktig ut, og du ikke er i stand til definitivt å si at noe er rart er på gang, bare følg rimet!

---

AND.  Og det er verdt å være mistenksom overfor ukjente nettsider, nettsteder du ikke har brukt før, som plutselig sier: «OK, vi kommer til å be deg om å logge på med Google-kontoen din i et Google-vindu, eller Facebook i et Facebook-vindu. ”

Eller Steam i et Steam-vindu.

---

DOUG.  Ja.

Jeg hater å bruke B-ordet her, men dette er nesten genialt i sin enkelhet.

Men igjen, det kommer til å være veldig vanskelig å få en piksel perfekt match ved å bruke CSS og slike ting.

---

AND.  Jeg tror det viktige å huske på er at fordi en del av simuleringen er "chrome" [sjargongen for nettleserens brukergrensesnittkomponenter] i nettleseren, vil adresselinjen se riktig ut.

Det kan til og med se perfekt ut.

Men saken er at det ikke er en adresselinje...

…det er et *bilde* av en adresselinje.

---

DOUG.  Nøyaktig!

Ok, forsiktig der ute, alle sammen!

Og når vi snakker om ting som ikke er som de ser ut, så leser jeg om DEADBOLT løsepengevare og QNAP NAS-enheter, og det føles for meg som om vi nettopp diskuterte akkurat denne historien for ikke lenge siden.

---

AND.  Ja, det har vi skrevet om dette flere ganger på Naked Security så langt i år, dessverre.

Det er et av de tilfellene der det som fungerte for skurkene en gang viser seg å ha fungert to ganger, tre ganger, fire ganger, fem ganger.

Og NAS, eller Nettverks Festet Lagring enheter, er, hvis du vil, black-box-servere som du kan gå og kjøpe – de kjører vanligvis en slags Linux-kjerne.

Tanken er at i stedet for å måtte kjøpe en Windows-lisens eller lære Linux, installer Samba, sett den opp, lær hvordan du deler fil på nettverket ditt...

...du bare kobler til denne enheten og "Bingo", den begynner å fungere.

Det er en netttilgjengelig filserver, og hvis det er en sårbarhet i filserveren og du (ved et uhell eller design) har gjort den tilgjengelig over internett, kan skurker kanskje utnytte denne sårbarheten, hvis det er en i den NAS-enheten, på avstand.

De kan kanskje kryptere alle filene på nøkkellagringsstedet for nettverket ditt, enten det er et hjemmenettverk eller nettverk for små bedrifter, og i utgangspunktet holde deg til løsepenger uten å måtte bekymre deg for å angripe individuelle andre enheter som bærbare datamaskiner og telefoner på Nettverk.

Så de trenger ikke rote rundt med skadelig programvare som infiserer den bærbare datamaskinen din, og de trenger ikke å bryte seg inn i nettverket ditt og vandre rundt som tradisjonelle løsepenge-kriminelle.

De forvrider i utgangspunktet alle filene dine, og så – for å presentere løsepengene – endrer de bare (jeg burde ikke le, Doug)... de endrer bare påloggingssiden på NAS-enheten din.

Så når du oppdager at alle filene dine er rotete og du tenker "Det er morsomt", og du hopper inn med nettleseren din og kobler til der, får du ikke en passordforespørsel!

Du får en advarsel: «Filene dine har blitt låst av DEADBOLT. Hva skjedde? Alle filene dine er kryptert."

Og så kommer instruksjonene om hvordan du betaler.

---

DOUG.  Og de har også vennlig tilbudt at QNAP kunne sette opp en fyrstelig sum for å låse opp filene for alle.

---

AND.  Skjermbildene jeg har i siste artikkel på nakedsecurity.sophos.com viser:

1. Individuelle dekrypteringer på 0.03 bitcoins, opprinnelig rundt 1200 dollar da denne tingen først ble utbredt, nå ca 600 dollar.

2. Et BTC 5.00-alternativ, der QNAP får beskjed om sårbarheten slik at de kan fikse den, som de tydeligvis ikke kommer til å betale fordi de allerede vet om sårbarheten. (Det er derfor det er en oppdatering i dette spesielle tilfellet.)

3. Som du sier, det er et BTC 50-alternativ (det er $1m nå; det var $2m da denne første historien brøt). Hvis QNAP tilsynelatende betaler $1,000,000 XNUMX XNUMX på vegne av noen som kan ha blitt infisert, vil skurkene gi en hoveddekrypteringsnøkkel, hvis du ikke har noe imot det.

Og hvis du ser på JavaScript-en deres, sjekker den faktisk om passordet du legger inn samsvarer med en av *to* hashes.

Den ene er unik for infeksjonen din - skurkene tilpasser den hver gang, så JavaScript har hashen i seg og gir ikke bort passordet.

Og det er en annen hash som, hvis du kan knekke den, ser ut som om den ville gjenopprette hovedpassordet for alle i verden...

… jeg tror det bare var skurkene som tomlet nesen mot alle.

---

DOUG.  Det er også interessant at $600 bitcoin løsepenger for hver bruker er... Jeg vil ikke si "ikke opprørende", men hvis du ser i kommentarfeltet til denne artikkelen, er det flere personer som ikke bare snakker om å ha betalt løsepenger…

…men la oss hoppe videre til leserspørsmålet vårt her.

Leseren Michael deler sin erfaring med dette angrepet, og han er ikke alene – det er andre personer i denne kommentarseksjonen som rapporterer lignende ting.

På tvers av et par kommentarer sier han (jeg skal på en måte komme med en åpenhjertig kommentar ut av det):

«Jeg har vært gjennom dette, og kom ut OK etter å ha betalt løsepenger. Å finne den spesifikke returkoden med min dekrypteringsnøkkel var den vanskeligste delen. Lærte den mest verdifulle leksjonen."

I sin neste kommentar går han gjennom alle trinnene han måtte ta for å faktisk få ting til å fungere igjen.

Og han stiger av med:

«Jeg er flau over å si at jeg jobber i IT, har vært det i 20+ år, og ble bitt av denne QNAP uPNP-feilen. Glad for å være gjennom det."

---

AND.  Wow, ja, det er litt av en uttalelse, er det ikke?

Nesten som om han sier: "Jeg ville ha støttet meg mot disse skurkene, men jeg tapte veddemålet og det kostet meg $600 og mye tid."

Aaargh!

---

DOUG.  Hva mener han med "den spesifikke returkoden med beskrivelsesnøkkelen"?

---

AND.  Ah, ja, det er veldig interessant... veldig spennende. (Jeg prøver å ikke si utrolig-skråstrek-strålende her.) [LATER]

Jeg vil ikke bruke C-ordet og si at det er "smart", men sånn er det.

Hvordan kontakter du disse skurkene? Trenger de en e-postadresse? Kan det spores? Trenger de en darkwebside?

Det gjør ikke disse skurkene.

Fordi, husk, det er én enhet, og skadelig programvare tilpasses og pakkes når den angriper enheten slik at den har en unik Bitcoin-adresse.

Og i utgangspunktet kommuniserer du med disse skurkene ved å betale den angitte mengden bitcoin inn i lommeboken deres.

Jeg antar at det er derfor de har holdt beløpet relativt beskjedent ...

…Jeg vil ikke antyde at alle har $600 å kaste bort på løsepenger, men det er ikke slik at du forhandler på forhånd for å avgjøre om du skal betale $100,000 eller $80,000 eller $42,000.

Du betaler dem beløpet ... ingen forhandlinger, ingen chat, ingen e-post, ingen direktemeldinger, ingen støtteforum.

Du sender bare pengene til den angitte bitcoin-adressen, og de vil åpenbart ha en liste over disse bitcoin-adressene de overvåker.

Når pengene kommer, og de ser at de er kommet, vet de at du (og du alene) har betalt, fordi den lommebokkoden er unik.

Og så gjør de det som faktisk er (jeg bruker de største luftnoteringene i verden) en "refusjon" på blokkjeden, ved å bruke en bitcoin-transaksjon til et beløp, Doug, på null dollar.

Og det svaret, den transaksjonen, inkluderer faktisk en kommentar. (Husk Poly Networks hack? De brukte Ethereum blockchain-kommentarer for å prøve å si: "Kjære, Mr. White Hat, vil du ikke gi oss alle pengene tilbake?")

Så du betaler skurkene, og gir dermed beskjeden om at du vil engasjere deg med dem, og de betaler deg tilbake $0 pluss en kommentar på 32 heksadesimale tegn...

…som er 16 rå binære byte, som er 128-biters dekrypteringsnøkkelen du trenger.

Det er slik du snakker til dem.

Og tilsynelatende har de dette ned til en T – som Michael sa, svindelen fungerer.

Og det eneste problemet Michael hadde var at han ikke var vant til å kjøpe bitcoins, eller å jobbe med blokkjededata og trekke ut den returkoden, som i utgangspunktet er kommentaren i transaksjonen "betalingen" som han får tilbake for $0.

Så de bruker teknologi på svært utspekulerte måter.

I utgangspunktet bruker de blokkjeden både som betalingsmiddel og som et kommunikasjonsverktøy.

---

DOUG.  Ok, en veldig interessant historie.

Det skal vi holde øye med.

Og tusen takk, Michael, for at du sendte inn den kommentaren.

Hvis du har en interessant historie, kommentar eller spørsmål du vil sende inn, vil vi gjerne lese den på podcasten.

Du kan sende en e-post til tips@sophos.com, du kan kommentere en av artiklene våre, eller du kan kontakte oss på sosiale medier: @NakedSecurity.

Det er showet vårt for i dag – tusen takk for at du lyttet.

For Paul Ducklin, jeg er Doug Aamoth, og minner deg på, inntil neste gang, om å...

---

BÅDE.  Hold deg trygg.

[MUSIKK MODEM]