S3 Ep100: Browser-in-the-Browser – hoe een aanval te herkennen [Audio + Text]

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

DOUG.  Nachtschoot - het is terug!

Patches in overvloed!

En tijdzones... ja, tijdzones.

Dat alles en meer in de Naked Security Podcast.

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug Aamoth.

Bij mij, zoals altijd, is Paul Ducklin.

Paul, een heel gelukkige 100ste aflevering voor jou, mijn vriend!

---

EEND.  Wauw, Doug!

Weet je, toen ik mijn directorystructuur voor Series 3 begon, gebruikte ik stoutmoedig -001 voor de eerste aflevering.

---

DOUG.  Ik heb niet. [LACHT]

---

EEND.  Niet -1 or -01.

---

DOUG.  Slim…

---

EEND.  Ik had een groot vertrouwen!

En als ik het bestand van vandaag bewaar, zal ik me er in verheugen.

---

DOUG.  Ja, en ik zal er bang voor zijn omdat het naar de top zal opduiken.

Nou, daar ga ik later mee aan de slag...

---

EEND.  [LACHT] Je zou alle andere dingen kunnen hernoemen.

---

DOUG.  Ik weet het.

[MOMMEL] Daar kijk ik niet naar uit... daar gaat mijn woensdag.

Hoe dan ook, laten we de show beginnen met wat technische geschiedenis.

Deze week, op 12 september 1959, Luna xnumx, Ook bekend als Tweede Sovjet Kosmische Raket, werd het eerste ruimtevaartuig dat het oppervlak van de maan bereikte en het eerste door mensen gemaakte object dat contact maakte met een ander hemellichaam.

Heel cool.

---

EEND.  Wat was die lange naam?

“De Tweede Sovjet Kosmische Raket”?

---

DOUG.  Ja.

---

EEND.  Luna Twee is veel beter.

---

DOUG.  Ja veel beter!

---

EEND.  Blijkbaar, zoals je je kunt voorstellen, was er, aangezien het het tijdperk van de ruimterace was, enige bezorgdheid van: "Hoe weten we dat ze het echt hebben gedaan? Ze kunnen gewoon zeggen dat ze op de maan zijn geland, en misschien verzinnen ze het wel.”

Blijkbaar hebben ze een protocol bedacht dat onafhankelijke observatie mogelijk zou maken.

Ze voorspelden de tijd dat het op de maan zou aankomen om op de maan te crashen, en ze stuurden de exacte tijd waarop ze dit verwachtten naar een astronoom in het VK.

En hij observeerde onafhankelijk, om te zien of wat ze zeiden * zou * gebeuren op dat moment * gebeurde.

Dus ze dachten zelfs over: "Hoe verifieer je zoiets?"

---

DOUG.  Welnu, wat gecompliceerde zaken betreft, we hebben patches van Microsoft en Apple.

Dus wat valt hier op in deze laatste ronde?

---

EEND.  Dat doen we zeker - het is patch dinsdag deze week, de tweede dinsdag van de maand.

Er zijn twee kwetsbaarheden in Patch Tuesday die mij opvielen.

Een daarvan is opmerkelijk omdat het blijkbaar in het wild is - met andere woorden, het was een zero-day.

En hoewel het geen externe code-uitvoering is, is het een beetje verontrustend omdat het een [COUGHS APOLOGETICALLY] logbestand-kwetsbaarheid is, Doug!

Het is niet helemaal zoals slecht als Log4J, waar je de logger niet alleen kon laten misdragen, maar ook kon krijgen willekeurige code uitvoeren voor jou

Maar het lijkt erop dat als je een of andere vorm van misvormde gegevens naar het Windows Common Log File System-stuurprogramma, de CLFS, stuurt, je het systeem kunt misleiden om je te promoveren naar systeemprivileges.

Altijd slecht als je als gastgebruiker bent binnengekomen, en je dan in staat bent om jezelf in een systeembeheerder te veranderen…

---

DOUG.  [LACHT] Ja!

---

EEND.  Dat CVE-2022-37969.

En de andere die ik interessant vond...

…gelukkig niet in het wild, maar dit is degene die je echt moet patchen, want ik wed dat cybercriminelen zich zullen concentreren op reverse engineering:

"Kwetsbaarheid van de uitvoering van externe code in Windows TCP/IP", CVE-2022-34718.

Als je je herinnert Code rood en SQL Slammer, en die ondeugende wormen uit het verleden, waar ze net binnenkwamen in een netwerkpakket en zich een weg baanden in het systeem….

Dit is een nog lager niveau dan dat.

Blijkbaar zit de bug in de afhandeling van bepaalde IPv6-pakketten.

Dus alles waar IPv6 naar luistert, wat vrijwel elke Windows-computer is, kan hierdoor gevaar lopen.

Zoals ik al zei, die is niet in het wild, dus de boeven hebben hem nog niet gevonden, maar ik twijfel er niet aan dat ze de patch zullen nemen en proberen uit te zoeken of ze er een exploit van kunnen reverse-engineeren, om mensen te vangen die nog niet hebben gepatcht.

Want als er iets zegt: "Wauw! Wat als iemand een worm zou schrijven die dit gebruikt?”… daar zou ik me zorgen over maken.

---

DOUG.  OK.

En dan naar Appel...

---

EEND.  We hebben onlangs twee verhalen geschreven over Apple-patches, waar, uit het niets, plotseling patches voor iPhones en iPads en Macs waren tegen twee in-the-wild zero-days.

Een daarvan was een browserbug, of een browsergerelateerde bug, zodat je naar een onschuldig ogende website kon dwalen en malware op je computer kon landen, plus een andere die je controle op kernelniveau gaf...

... wat, zoals ik in de vorige podcast zei, voor mij naar spyware ruikt - iets waar een spywareverkoper of een echt serieuze "surveillance-cybercrimineel" in geïnteresseerd zou zijn.

Toen was er een tweede update, tot onze verbazing, voor iOS 12, waarvan we allemaal dachten dat ze al lang verlaten waren.

Daar kreeg een van die bugs (de browsergerelateerde bug waardoor oplichters konden inbreken) een patch.

En toen, net toen ik iOS 16 verwachtte, kwamen al deze e-mails plotseling in mijn inbox terecht - direct nadat ik had gecontroleerd: "Is iOS 16 al uit? Kan ik het updaten?”

Het was er niet, maar toen kreeg ik al deze e-mails waarin stond: "We hebben zojuist iOS 15 en macOS Monterey en Big Sur en iPadOS 15 bijgewerkt" ...

... en het bleek dat er een hele reeks updates waren, plus deze keer ook een gloednieuwe kernel zero-day.

En het fascinerende is dat ik, nadat ik de meldingen had ontvangen, dacht: "Nou, laat me het nog eens controleren ..."

(Dus je kunt het onthouden, het is Instellingen > Algemeen > software bijwerken op uw iPhone of iPad.)

Kijk, ik kreeg een update aangeboden voor iOS 15, die ik al had, *of* ik zou helemaal naar iOS 16 kunnen springen.

En iOS 16 had ook deze zero-day-fix (hoewel iOS 16 theoretisch nog niet uit was), dus ik denk dat de bug ook in de bèta bestond.

In Apple's bulletin voor iOS 16 werd het niet als officieel een zero-day vermeld, maar we kunnen niet zeggen of dat komt omdat de exploit die Apple zag niet helemaal goed werkte op iOS 16, of dat het niet als een zero-day wordt beschouwd. dag omdat iOS 16 nog maar net uitkwam.

---

DOUG.  Ja, ik wilde zeggen: niemand heeft het nog. [GELACH]

---

EEND.  Dat was het grote nieuws van Apple.

En het belangrijkste is dat wanneer je naar je telefoon gaat en je zegt: "Oh, iOS 16 is beschikbaar" ... als je nog niet geïnteresseerd bent in iOS 16, je er nog steeds voor moet zorgen dat je die iOS 15 hebt update, vanwege de kernel zero-day.

Kernel zero-days zijn altijd een probleem, omdat het betekent dat iemand weet hoe de veelgeroemde beveiligingsinstellingen op je iPhone te omzeilen.

De bug is ook van toepassing op macOS Monterey en macOS Big Sur - dat is de vorige versie, macOS 11.

Om niet achter te blijven, heeft Big Sur zelfs *twee* kernel zero-day bugs in het wild.

Geen nieuws over iOS 12, wat ik ongeveer had verwacht, en tot nu toe niets voor macOS Catalina.

Catalina is macOS 10, de vorige vorige versie, en nogmaals, we weten niet of die update later zal komen, of dat hij van de rand van de wereld is gevallen en toch geen updates zal krijgen.

Helaas zegt Apple dat niet, dus we weten het niet.

Nu zullen de meeste Apple-gebruikers automatische updates hebben ingeschakeld, maar zoals we altijd zeggen, ga eens kijken (of je een Mac of een iPhone of een iPad hebt), want het ergste is gewoon aan te nemen dat je automatische updates werkten en hielden je veilig ...

… terwijl er in feite iets mis ging.

---

DOUG.  Oke, heel goed.

Nu, iets waar ik naar uitkeek, en meteen doorging, is: "Wat hebben tijdzones te maken met IT-beveiliging?"

---

EEND.  Nou, heel veel, zo blijkt, Doug.

---

DOUG.  [LACHEND] Jazeker!

---

EEND.  Tijdzones zijn heel eenvoudig van opzet.

Ze zijn erg handig om ons leven te leiden, zodat onze klokken ongeveer overeenkomen met wat er in de lucht gebeurt - dus het is 's nachts donker en overdag licht. (Laten we de zomertijd buiten beschouwing laten, en laten we aannemen dat we over de hele wereld slechts tijdzones van één uur hebben, zodat alles heel eenvoudig is.)

Het probleem ontstaat wanneer u systeemlogboeken bijhoudt in een organisatie waar sommige van uw servers, sommige van uw gebruikers, sommige delen van uw netwerk, sommige van uw klanten zich in andere delen van de wereld bevinden.

Wanneer u naar het logbestand schrijft, schrijft u dan de tijd met de tijdzone mee?

Als je je logboek schrijft, Doug, trek je dan de 5 uur (of op dit moment 4 uur) af die je nodig hebt omdat je in Boston bent, terwijl ik er een uur bij optel omdat ik Londense tijd heb, maar het is zomer ?

Schrijf ik dat in het logboek zodat het voor *mij* logisch is als ik het logboek teruglees?

Of schrijf ik een meer canonieke, ondubbelzinnige tijd met dezelfde tijdzone voor *iedereen*, dus als ik logboeken vergelijk die afkomstig zijn van verschillende computers, verschillende gebruikers, verschillende delen van de wereld op mijn netwerk, kan ik gebeurtenissen op een rij zetten?

Het is erg belangrijk om gebeurtenissen op een rij te zetten, Doug, vooral als je reageert op bedreigingen bij een cyberaanval.

Je moet echt weten wat er eerst was.

En als je zegt: "Oh, het is pas om 3:3 uur gebeurd", dan helpt dat me niet als ik in Sydney ben, omdat mijn 3:XNUMX gisteren was in vergelijking met jouw XNUMX:XNUMX.

Dus ik schreef een artikel op Naked Security over enkele manieren waarop u dat kunt omgaan met dit probleem wanneer u gegevens logt.

Mijn persoonlijke aanbeveling is om een ​​vereenvoudigd tijdstempelformaat te gebruiken genaamd RFC 3339, waar u een viercijferig jaar, streepje [koppelteken, ASCII 0x2D], tweecijferige maand, streepje, tweecijferige dag, enzovoort plaatst, zodat uw tijdstempels eigenlijk alfabetisch netjes sorteren.

En dat u al uw tijdzones opneemt als een tijdzone die bekend staat als Z (zed of zee), afkorting van Zulu tijd.

Dat betekent in feite UTC of Coordinated Universal Time.

Dat is bijna, maar niet helemaal Greenwich Mean Time, en het is de tijd waarop de klok van bijna elke computer of telefoon tegenwoordig intern is ingesteld.

Probeer geen tijdzones te compenseren wanneer u naar het logboek schrijft, want dan zal iemand moeten decompenseren wanneer ze uw logboek proberen uit te lijnen met dat van anderen - en er is veel misstap tussen de beker en de lip, Doug.

Houd het simpel.

Gebruik een canoniek, eenvoudig tekstformaat dat precies de datum en tijd afbakent, tot op de seconde - of tegenwoordig kunnen tijdstempels tegenwoordig zelfs tot op de nanoseconde gaan als je wilt.

En verwijder tijdzones uit uw logs; verwijder de zomertijd uit uw logs; en leg alles gewoon vast, naar mijn mening, in Coordinated Universal Time...

...verwarrend afgekort UTC, omdat de naam in het Engels is, maar de afkorting in het Frans - enigszins ironisch.

---

DOUG.  Ja.

---

EEND.  
Ik kom in de verleiding om te zeggen: "Niet dat ik er weer een sterk gevoel bij heb", zoals ik gewoonlijk doe, lachend...

…maar het is echt belangrijk om de zaken in de juiste volgorde te krijgen, vooral wanneer u cybercriminelen probeert op te sporen.

---

DOUG.  Oké, dat is goed – goed advies.

En als we het over cybercriminelen hebben, je hebt vast wel eens gehoord van Manipulator-in-the-Middle-aanvallen; je hebt gehoord van Manipulator-in-the-Browser-aanvallen...

.. bereid u nu voor op Browser-in-the-Browser-aanvallen.

---

EEND.  Ja, dit is een nieuwe term die we zien.

Ik wilde dit opschrijven omdat onderzoekers van een dreigingsinformatiebedrijf genaamd Group-IB hier onlangs een artikel over schreven, en de media begonnen te praten over: "Hé, Browser-in-the-Browser-aanvallen, wees erg bang", of wat dan ook …

Je denkt: "Nou, ik vraag me af hoeveel mensen eigenlijk weten wat wordt bedoeld met een Browser-in-the-Browser-aanval?"

En het vervelende van deze aanvallen, Doug, is dat ze technologisch verschrikkelijk eenvoudig zijn.

Het is zo'n simpel idee.

---

DOUG.  Ze zijn bijna artistiek.

---

EEND.  Ja!

Het is niet echt wetenschap en technologie, het is kunst en design, toch?

Kortom, als je ooit JavaScript-programmering hebt gedaan (ten goede of ten kwade), weet je dat een van de dingen die je op een webpagina plakt, is dat het bedoeld is om tot die webpagina te worden beperkt.

Dus als je een gloednieuw venster opent, zou je verwachten dat het een geheel nieuwe browsercontext krijgt.

En als het zijn pagina laadt vanaf een gloednieuwe site, bijvoorbeeld een phishingsite, dan heeft het geen toegang tot alle JavaScript-variabelen, context, cookies en alles wat het hoofdvenster had.

Dus als je een apart venster opent, beperk je je hackmogelijkheden als je een oplichter bent.

Maar als je iets opent in het huidige venster, dan ben je aanzienlijk beperkt in hoe opwindend en "systeemachtig" je het eruit kunt laten zien, nietwaar?

Omdat je de adresbalk niet kunt overschrijven... dat is zo ontworpen.

Je kunt niets buiten het browservenster schrijven, dus je kunt niet stiekem een ​​venster op het bureaublad plaatsen dat eruitziet als een achtergrond, alsof het er altijd al is geweest.

Met andere woorden, je wordt binnengedrongen in het browservenster waarmee je bent begonnen.

Dus het idee van een Browser-in-the-Browser-aanval is dat je begint met een gewone website, en dan maak je, in het browservenster dat je al hebt, een webpagina die er precies uitziet als een browservenster van een besturingssysteem .

Kortom, je laat iemand een *foto* van het echte werk zien en overtuigt hen dat het *echt* is.

Zo simpel is het, Doug!

Maar het probleem is dat met een beetje zorgvuldig werk, vooral als je goede CSS-vaardigheden hebt, je *kunt* iets dat zich in een bestaand browservenster bevindt, eruitziet als een eigen browservenster.

En met een beetje JavaScript kun je het zelfs zo maken dat het van grootte kan veranderen, en zodat het over het scherm kan bewegen, en je kunt het vullen met HTML die je ophaalt van een website van een derde partij.

Nu vraag je je misschien af ​​... als de boeven het goed hebben, hoe kun je dat dan ooit weten?

En het goede nieuws is dat je iets heel eenvoudigs kunt doen.

Als je iets ziet dat lijkt op een besturingssysteemvenster en je bent er op de een of andere manier achterdochtig (het lijkt in wezen op je browservenster te verschijnen, omdat het erin moet staan)...

...probeer het *uit het echte browservenster* te verplaatsen, en als het "opgesloten" zit in de browser, weet je dat het niet de echte deal is!

Het interessante aan het rapport van de Group-IB-onderzoekers is dat toen ze dit tegenkwamen, de boeven het eigenlijk gebruikten tegen spelers van Steam-spellen.

En natuurlijk wil het dat je inlogt op je Steam-account ...

... en als je door de eerste pagina voor de gek werd gehouden, zou het zelfs volgen met Steam's tweefactorauthenticatieverificatie.

En de truc was dat als die echt *afzonderlijke* vensters waren, je ze naar een kant van je hoofdbrowservenster had kunnen slepen, maar dat waren ze niet.

In dit geval hadden de koks hun CSS gelukkig niet zo goed gedaan.

Hun kunstwerken waren slordig.

Maar, zoals jij en ik al vaak hebben besproken in de podcast, Doug, zijn er soms boeven die zich inspannen om de dingen er pixel-perfect uit te laten zien.

Met CSS kun je letterlijk individuele pixels positioneren, nietwaar?

---

DOUG.  CSS is interessant.

Het is Cascading Style Sheets… een taal die u gebruikt om HTML-documenten op te maken, en het is heel gemakkelijk te leren en nog moeilijker te beheersen.

---

EEND.  [LACHT] Klinkt zeker als HET.

---

DOUG.  [LACHT] Ja, het is zoals met veel dingen!

Maar het is een van de eerste dingen die je leert als je eenmaal HTML hebt geleerd.

Als je denkt: "Ik wil deze webpagina er beter uit laten zien", leer je CSS.

Dus, kijkend naar enkele van deze voorbeelden van het brondocument waarnaar je in het artikel linkt, kun je zien dat het heel moeilijk zal zijn om een ​​echt goede nep te maken, tenzij je echt goed bent in CSS.

Maar als je het goed doet, wordt het heel moeilijk om erachter te komen dat het een nepdocument is...

... tenzij je doet wat je zegt: probeer het uit een raam te trekken en over je bureaublad te verplaatsen, dat soort dingen.

Dat leidt tot je tweede punt hier: onderzoek verdachte ramen zorgvuldig.

Veel van hen zullen waarschijnlijk de oogtest niet doorstaan, maar als ze dat wel doen, zal het heel moeilijk zijn om ze te herkennen.

Dat brengt ons bij het derde ding...

"In geval van twijfel / geef het niet uit."

Als het er gewoon niet helemaal goed uitziet, en je bent niet in staat om definitief te zeggen dat er iets vreemds aan de hand is, volg dan gewoon het rijm!

---

EEND.  En het is de moeite waard om wantrouwend te staan ​​tegenover onbekende websites, websites die je nog niet eerder hebt gebruikt, die plotseling zeggen: "Oké, we gaan je vragen om in te loggen met je Google-account in een Google-venster, of Facebook in een Facebook-venster. ”

Of Steam in een Steam-venster.

---

DOUG.  Ja.

Ik haat het om hier het B-woord te gebruiken, maar dit is bijna briljant in zijn eenvoud.

Maar nogmaals, het zal heel moeilijk zijn om een ​​perfecte pixelmatch te maken met CSS en dat soort dingen.

---

EEND.  Ik denk dat het belangrijk is om te onthouden dat, omdat een deel van de simulatie het "chrome" [jargon voor de gebruikersinterfacecomponenten van de browser] van de browser is, de adresbalk er goed uitziet.

Het ziet er misschien zelfs perfect uit.

Maar het punt is, het is geen adresbalk...

…het is een *afbeelding* van een adresbalk.

---

DOUG.  Precies!

Oké, voorzichtig daarbuiten, iedereen!

En nu we het toch over dingen hebben die niet zijn wat ze lijken, ik lees over DEADBOLT-ransomware en QNAP NAS-apparaten, en het voelt voor mij alsof we dit exacte verhaal nog niet zo lang geleden hebben besproken.

---

EEND.  Ja, we hebben hierover geschreven helaas dit jaar meerdere keren op Naked Security tot nu toe.

Het is een van die gevallen waarin wat ooit voor de boeven werkte, twee keer, drie keer, vier keer, vijf keer blijkt te hebben gewerkt.

En NAS, of Network Attached Storage apparaten, zijn, als je wilt, black-box-servers die je kunt gaan kopen - ze draaien meestal op een soort Linux-kernel.

Het idee is dat je in plaats van een Windows-licentie te kopen of Linux te leren, Samba moet installeren, instellen, leren hoe je bestanden kunt delen op je netwerk...

... je sluit dit apparaat gewoon aan en "Bingo", het begint te werken.

Het is een voor het web toegankelijke bestandsserver en, helaas, als er een kwetsbaarheid in de bestandsserver zit en u hebt deze (per ongeluk of ontwerp) toegankelijk gemaakt via internet, dan kunnen oplichters die kwetsbaarheid mogelijk misbruiken, als er een is in dat NAS-apparaat, op afstand.

Ze kunnen mogelijk alle bestanden op de belangrijkste opslaglocatie voor uw netwerk door elkaar gooien, of het nu een thuisnetwerk of een klein bedrijfsnetwerk is, en u in feite aan losgeld houden zonder zich ooit zorgen te hoeven maken over het aanvallen van individuele andere apparaten zoals laptops en telefoons op uw netwerk.

Ze hoeven dus niet te rommelen met malware die uw laptop infecteert, en ze hoeven niet in uw netwerk in te breken en rond te dwalen als traditionele ransomware-criminelen.

Ze versleutelen in feite al je bestanden, en dan - om het losgeldbriefje te presenteren - veranderen ze gewoon (ik moet niet lachen, Doug)... ze veranderen gewoon de inlogpagina op je NAS-apparaat.

Dus als je merkt dat al je bestanden in de war zijn en je denkt: "Dat is grappig", en je springt in met je webbrowser en maakt daar verbinding, je krijgt geen wachtwoordprompt!

U krijgt een waarschuwing: "Uw bestanden zijn vergrendeld door DEADBOLT. Wat er is gebeurd? Al uw bestanden zijn versleuteld.”

En dan komen de instructies over hoe te betalen.

---

DOUG.  En ze hebben ook vriendelijk aangeboden dat QNAP een vorstelijk bedrag zou kunnen betalen om de bestanden voor iedereen te ontgrendelen.

---

EEND.  De screenshots die ik heb in de laatste artikel op nakedsecurity.sophos.com laten zien:

1. Individuele decoderingen bij 0.03 bitcoins, oorspronkelijk ongeveer US $ 1200 toen dit ding voor het eerst wijdverbreid werd, nu ongeveer US $ 600.

2. Een BTC 5.00-optie, waarbij QNAP wordt geïnformeerd over de kwetsbaarheid zodat ze deze kunnen repareren, waarvoor ze duidelijk niet gaan betalen omdat ze al op de hoogte zijn van de kwetsbaarheid. (Daarom is er in dit specifieke geval een patch uit.)

3. Zoals je zegt, is er een BTC 50-optie (dat is nu $ 1 miljoen; het was $ 2 miljoen toen dit eerste verhaal voor het eerst brak). Als QNAP de $ 1,000,000 betaalt namens iemand die mogelijk is geïnfecteerd, zullen de boeven blijkbaar een hoofddecoderingssleutel verstrekken, als u het niet erg vindt.

En als je naar hun JavaScript kijkt, controleert het daadwerkelijk of het wachtwoord dat je invoert overeenkomt met een van de *twee* hashes.

De ene is uniek voor uw infectie - de oplichters passen deze elke keer aan, zodat JavaScript de hash bevat en het wachtwoord niet weggeeft.

En er is nog een hash die, als je hem kunt kraken, eruitziet alsof hij het hoofdwachtwoord voor iedereen ter wereld zou herstellen...

… Ik denk dat dat gewoon de boeven waren die met hun neus naar iedereen duimen.

---

DOUG.  Het is ook interessant dat het losgeld van $ 600 bitcoin voor elke gebruiker ... Ik wil niet zeggen "niet schandalig", maar als je in de commentarensectie van dit artikel kijkt, zijn er verschillende mensen die niet alleen praten over het betalen van de losgeld…

... maar laten we doorgaan naar onze lezersvraag hier.

Lezer Michael deelt zijn ervaring met deze aanval, en hij is niet de enige - er zijn andere mensen in deze commentaarsectie die soortgelijke dingen melden.

Over een paar opmerkingen zegt hij (ik ga daar een soort van openhartige opmerking over maken):

'Ik heb dit meegemaakt en kwam er goed uit nadat ik het losgeld had betaald. Het vinden van de specifieke retourcode met mijn decoderingssleutel was het moeilijkste deel. De meest waardevolle les geleerd.”

In zijn volgende opmerking overloopt hij alle stappen die hij moest nemen om de boel weer aan het werk te krijgen.

En hij stapt af met:

“Ik schaam me om te zeggen dat ik in de IT werk, al meer dan 20 jaar, en werd gebeten door deze QNAP uPNP-bug. Blij dat ik er doorheen ben.”

---

EEND.  Wow, ja, dat is nogal een statement, niet?

Bijna alsof hij zegt: "Ik zou mezelf tegen deze boeven hebben gesteund, maar ik verloor de weddenschap en het kostte me $ 600 en een hele hoop tijd."

Aaargh!

---

DOUG.  Wat bedoelt hij met "de specifieke retourcode met zijn beschrijvingssleutel"?

---

EEND.  Ah, ja, dat is een heel interessant... heel intrigerend. (Ik probeer hier niet geweldig-slash-briljant te zeggen.) [GELACH]

Ik wil het C-woord niet gebruiken en zeggen dat het 'slim' is, maar dat is het wel.

Hoe kom je in contact met deze oplichters? Hebben ze een e-mailadres nodig? Zou dat te traceren zijn? Hebben ze een darkweb-site nodig?

Deze boeven niet.

Want onthoud, er is één apparaat en de malware wordt aangepast en verpakt wanneer het dat apparaat aanvalt, zodat er een uniek Bitcoin-adres in zit.

En in feite communiceer je met deze boeven door het gespecificeerde bedrag aan bitcoin in hun portemonnee te betalen.

Ik denk dat ze daarom het bedrag relatief bescheiden hebben gehouden...

... Ik wil niet suggereren dat iedereen $ 600 heeft om losgeld te betalen, maar het is niet zo dat je van tevoren onderhandelt om te beslissen of je $ 100,000 of $ 80,000 of $ 42,000 gaat betalen.

U betaalt ze het bedrag ... geen onderhandeling, geen chat, geen e-mail, geen instant messaging, geen ondersteuningsforum.

U stuurt het geld gewoon naar het aangewezen bitcoin-adres, en ze zullen uiteraard een lijst hebben van die bitcoin-adressen die ze controleren.

Wanneer het geld arriveert en ze zien dat het is aangekomen, weten ze dat jij (en jij alleen) hebt betaald, omdat die portemonnee-code uniek is.

En ze doen dan wat is, effectief (ik gebruik de grootste luchtquotes ter wereld) een "terugbetaling" op de blockchain, met behulp van een bitcoin-transactie voor het bedrag, Doug, van nul dollar.

En dat antwoord, die transactie, bevat eigenlijk een opmerking. (Herinner de Poly Networks-hack? Ze gebruikten Ethereum blockchain-opmerkingen om te zeggen: "Beste, meneer White Hat, wilt u ons niet al het geld teruggeven?")

Dus je betaalt de boeven, waardoor je de boodschap geeft dat je met hen in contact wilt komen, en ze betalen je $ 0 terug plus een opmerking van 32 hexadecimale tekens ...

... wat 16 onbewerkte binaire bytes is, wat de 128-bits decoderingssleutel is die u nodig hebt.

Zo praat je met ze.

En blijkbaar hebben ze dit tot een T - zoals Michael zei, de zwendel werkt.

En het enige probleem dat Michael had, was dat hij niet gewend was om bitcoins te kopen, of om met blockchain-gegevens te werken en die retourcode te extraheren, wat in feite de opmerking is in de transactie "betaling" die hij terugkrijgt voor $ 0.

Ze gebruiken technologie dus op zeer slinkse manieren.

Kortom, ze gebruiken de blockchain zowel als betaalmiddel als als communicatiemiddel.

---

DOUG.  Oké, inderdaad een heel interessant verhaal.

Wij zullen dat in de gaten houden.

En heel erg bedankt, Michael, voor het insturen van die opmerking.

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

U kunt een e-mail sturen naar tips@sophos.com, reageren op een van onze artikelen of u 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.

[MUZIEK MODEM]