Zephyrnet-logo

S3 Aflevering 116: Laatste druppel voor LastPass? Is crypto gedoemd? [Audio + tekst]

Datum:

LAATSTE STROJE VOOR LASTPASS? IS CRYPTO VERDOEMD?

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

Met Doug Aamoth en Paul Ducklin

Intro en outro muziek door Edith Mudge.

Je kunt naar ons luisteren op Soundcloud, Apple Podcasts, Google Podcasts, Spotify, stikster en overal waar goede podcasts te vinden zijn. Of laat de URL van onze RSS-feed in je favoriete podcatcher.


LEES DE TRANSCRIPT

DOUG.  Nogmaals LastPass, plezier met kwantumcomputing en cyberbeveiligingsvoorspellingen voor 2023.

Dat alles, en meer, op de Naked Security-podcast.

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug Aamoth.

Hij is Paul Ducklin.

Paul, eens kijken of ik me herinner hoe ik dit moet doen...

Het is alweer een paar weken geleden, maar ik hoop dat je een fijne vakantie hebt gehad – en ik heb een cadeau voor na de vakantie!

Zoals je weet staan ​​we graag in de show met een Deze week in de technische geschiedenis segment.


EEND.  Is dit het cadeau?


DOUG.  Dit is het cadeau!

Ik denk dat je hier meer in geïnteresseerd zult zijn dan in zo'n beetje elk ander Deze week in de technische geschiedenis segment…

…deze week, op 04 januari 1972, de HP-35 draagbare wetenschappelijke rekenmachine, een wereldprimeur, was geboren.

Afbeelding uit The Museum of HP Calculators.
Klik op de rekenmachine om de museumexpositie te bezoeken.

De rekenmachine, de HP-35 genoemd, simpelweg omdat hij 35 knoppen had, was een uitdaging van Bill Hewlett van HP om de wetenschappelijke rekenmachine van het bedrijf op desktopformaat 9100A te verkleinen zodat hij in zijn borstzak paste.

De HP-35 viel op omdat hij onderweg trigonometrische en exponentiële functies kon uitvoeren, dingen waarvoor tot dan toe rekenlinialen nodig waren.

Bij de lancering werd het verkocht voor $ 395, bijna $ 2500 in het geld van vandaag.

En Paul, ik weet dat je een fan bent van oude HP rekenmachines...


EEND.  Geen *oude* rekenmachines van HP, maar 'rekenmachines van HP'.


DOUG.  Gewoon in het algemeen? [LACHT]

Ja ok…


EEND.  Blijkbaar was Bill Hewlett er bij de lancering zelf mee aan het pronken.

En denk eraan, dit is een rekenmachine die een bureaurekenmachine/computer vervangt die 20 kg woog...

... blijkbaar liet hij het vallen.

Als je ooit een oude HP-rekenmachine hebt gezien, ze waren prachtig gebouwd - dus hij raapte hem op en hij werkte natuurlijk.

En blijkbaar hebben alle verkopers bij HP dat in hun repliek ingebouwd. [LACHT]

Als ze op pad gingen om demo's te doen, lieten ze per ongeluk (of anderszins) hun rekenmachine vallen, raapten hem op en gingen hoe dan ook door.


DOUG.  Hou ervan! [LACHT]


EEND.  Ze maken ze niet meer zoals vroeger, Doug.


DOUG.  Dat doen ze zeker niet.

Dat waren de dagen - ongelooflijk.

Oké, laten we het hebben over iets dat niet zo cool is.


EEND.  Oh Oh!


DOUG.  LastPass: we zeiden dat we het in de gaten zouden houden, en we *hielden* het in de gaten, en het werd erger!

LastPass geeft eindelijk toe: die boeven die binnenkwamen? Ze hebben tenslotte je wachtwoordkluizen gestolen ...


EEND.  Het blijkt een langlopend verhaal te zijn, waarbij LastPass-het-bedrijf blijkbaar simpelweg niet doorhad wat er was gebeurd.

En elke keer als ze die roestplek op hun auto een klein beetje krabden, werd het gat groter, tot het uiteindelijk allemaal erin viel.

Dus hoe is het begonnen?

Ze zeiden: "Kijk, de boeven kwamen binnen, maar ze waren maar vier dagen binnen en ze zaten alleen in het ontwikkelingsnetwerk. Het is dus ons intellectueel eigendom. Oh jee. Dom wij. Maar maak je geen zorgen, we denken niet dat ze in de klantgegevens zijn gekomen.”

Toen kwamen ze terug en zeiden: "Ze zijn *absoluut* niet in de klantgegevens of de wachtwoordkluizen gekomen, omdat die niet toegankelijk zijn vanuit het ontwikkelingsnetwerk."

Toen zeiden ze: 'Weeeeeel, eigenlijk blijkt dat ze *in staat waren om te doen wat in het jargon bekend staat als' zijwaartse beweging. Op basis van wat ze bij incident één hebben gestolen, was er incident twee, waar ze daadwerkelijk in klantinformatie kwamen.

Dus we dachten allemaal: "Oh jee, dat is erg, maar ze hebben tenminste geen wachtwoordkluizen!"

En toen zeiden ze: “Oh trouwens, toen we 'klantinformatie' zeiden, laten we je vertellen wat we bedoelen. We bedoelen heel veel dingen over jou, zoals: wie je bent; waar je woont; wat uw telefoon- en e-mailcontactgegevens zijn; dat soort dingen. *En* [PAUSE] je wachtwoordkluis.”


DOUG.  [GASP] Oké?!


EEND.  En * toen * zeiden ze: "Oh, toen we 'kluis' zeiden", waar je je waarschijnlijk voorstelde dat een hele grote deur gesloten was, en een groot wiel werd rondgedraaid, en enorme grendels doorkwamen, en alles binnenin op slot ging...

“Nou, in onze kluis was slechts *een deel* van het spul daadwerkelijk beveiligd, en het andere was effectief in platte tekst. Maar maak je geen zorgen, het was in een eigen formaat.”

Dus eigenlijk waren je wachtwoorden gecodeerd, maar de websites en de webservices en een onaangekondigde lijst van andere dingen die je hebt opgeslagen, nou ja, dat was niet gecodeerd.

Het is dus een speciaal soort 'zero-knowledge', een uitdrukking die ze vaak hadden gebruikt.

[LANGE STILTE]

[KUCHT OM AANDACHT] Ik liet daar een dramatische stilte vallen, Doug.

[GELACH]

En *TOEN* bleek dat...

... je weet hoe ze tegen iedereen hebben gezegd: "Maak je geen zorgen, er zijn 100,100 iteraties van HMAC-SHA-256 in PBKDF2"?

Misschien*.


DOUG.  Niet voor iedereen!


EEND.  Als u de software voor het eerst na 2018 had geïnstalleerd, kan dat het geval zijn.


DOUG.  Nou, ik heb de software voor het eerst geïnstalleerd in 2017, dus ik was niet bekend met deze "state-of-the-art" codering.

En ik heb het net gecontroleerd.

Ik heb mijn hoofdwachtwoord gewijzigd, maar het is een instelling - je moet naar je accountinstellingen gaan en daar is een Geavanceerde instellingen knop; je klikt erop en dan mag je het aantal keren kiezen dat je wachtwoord wordt getuimeld ...

... en de mijne was nog steeds ingesteld op 5000.

Tussen dat, en het ontvangen van de e-mail op de vrijdag voor Kerstmis, die ik las; vervolgens doorgeklikt naar de blogpost; lees de blogpost...

…en mijn indruk van mijn reactie is als volgt:

[HEEL LANG MOE ZUCHT]

Alleen een lange zucht.


EEND.  
Maar waarschijnlijk luider dan dat in het echte leven...


DOUG.  Het wordt alleen maar erger.

Dus: ik ben eruit!

Ik denk dat ik klaar ben...


EEND.  Echt waar?

OK.


DOUG.  Dat is genoeg.

Ik was al begonnen met overstappen naar een andere aanbieder, maar ik wil niet eens zeggen dat dit “de laatste druppel” was.

Ik bedoel, er waren zoveel rietjes, en ze bleven maar breken. [GELACH]

Wanneer u een wachtwoordbeheerder kiest, moet u ervan uitgaan dat dit een van de meest geavanceerde technologie is die beschikbaar is, en dat het beter beschermd is dan wat dan ook.

En het lijkt er gewoon niet op dat dit het geval was.


EEND.  [IRONIC] Maar ze hebben tenminste mijn creditcardnummer niet gekregen!

Hoewel ik binnen drie en een kwart dag een nieuwe creditcard had kunnen krijgen, waarschijnlijk sneller dan al mijn wachtwoorden te veranderen, inclusief mijn hoofdwachtwoord en *elke* account daarin.


DOUG.  Absoluut!

Oké, dus als we mensen hebben die LastPass-gebruikers zijn, als ze erover denken om over te stappen, of als ze zich afvragen wat ze kunnen doen om hun account te versterken, dan kan ik ze uit de eerste hand vertellen...

Ga naar uw account; ga naar de algemene instellingen en klik vervolgens op de Geavanceerde instellingen tabblad en kijk wat het aantal iteraties is.

Jij kiest het.

Dus de mijne was ingesteld ... mijn account was zo oud dat deze was ingesteld op 5000.

Ik heb hem op iets veel hoger gezet.

Ze geven je een aanbevolen nummer; Ik zou nog hoger gaan dan dat.

En dan versleutelt het je hele account opnieuw.

Maar zoals we al zeiden, de kat is uit de zak…. als je niet al je wachtwoorden verandert en ze erin slagen je [oude] hoofdwachtwoord te kraken, hebben ze een offline kopie van je account.

Dus gewoon je hoofdwachtwoord wijzigen en alles opnieuw versleutelen, volstaat niet.


EEND.  Precies.

Als je naar binnen gaat en je iteratie-telling nog steeds op 5000 staat, is dat het aantal keren dat ze je wachtwoord hash-hash-hash-and-rehash voordat het wordt gebruikt, om aanvallen op het raden van wachtwoorden te vertragen.

Dat is het aantal gebruikte iteraties *op de kluis die de boeven nu hebben*.

Dus zelfs als je het verandert in 100,100...

…vreemd nummer: Naked Security beveelt 200,000 aan [datum: oktober 2022]; OWASP raadt geloof ik iets van 310,000 aan, dus LastPass zegt: "Oh, nou, we doen echt een soort gung-ho, boven het gemiddelde van 100,100"?

Ernstige beveiliging: hoe u de wachtwoorden van uw gebruikers veilig opslaat

Ik zou dat ergens in het midden van het peloton noemen – niet bepaald spectaculair.

Maar als u dat nu verandert, beschermt u alleen het kraken van uw *huidige* kluis, niet degene die de boeven hebben.


DOUG.  Dus, om af te sluiten.

Gelukkig nieuwjaar allemaal; je hebt je weekendplannen al, dus "graag gedaan".

En ik kan niet geloven dat ik dit weer zeg, maar we houden dit in de gaten.

Oké, we blijven in de cryptografietrein en praten over kwantumcomputing.

Volgens de Verenigde Staten van Amerika is het tijd om voorbereid te zijn, en de beste voorbereiding is...

[DRAMATISCH] …cryptografische behendigheid.

De VS keurt de Quantum Computing Cybersecurity Preparedness Act goed – en waarom niet?


EEND.  Ja!

Dit was een leuk verhaaltje dat ik tussen Kerstmis en Nieuwjaar heb geschreven omdat ik het interessant vond, en blijkbaar vonden heel veel lezers dat ook omdat we daar actieve reacties hebben gehad... kwantumcomputing is het coole, nietwaar?

Het is net als kernfusie, of donkere materie, of supersnaartheorie, of gravitonen, dat soort dingen.

Iedereen heeft een vaag idee waar het over gaat, maar niet veel mensen begrijpen het echt.

De theorie van kwantumcomputing is dus losjes gezegd dat het een manier is om een ​​analoog computerapparaat te bouwen, zo je wilt, dat in staat is om bepaalde soorten berekeningen uit te voeren op zo'n manier dat in wezen alle antwoorden onmiddellijk verschijnen. binnenkant van het apparaat.

En de truc die je hebt is dat als je dit kunt samenvoegen - wat volgens mij een "superpositie" wordt genoemd, gebaseerd op kwantummechanica...

... als je deze superpositie zo kunt samenvouwen dat het antwoord dat je eigenlijk wilt eruit springt, en alle anderen verdwijnen in een wolkje kwantumrook, dan kun je je voorstellen wat dat zou kunnen betekenen voor cryptografie.

Omdat u de tijd die nodig is om cryptografisch kraken uit te voeren mogelijk drastisch kunt verkorten.

En in feite zijn er twee belangrijke soorten algoritmische versnelling die mogelijk zijn, als er krachtig genoeg kwantumcomputers komen.

Een daarvan gaat over het kraken van zaken als versleuteling met symmetrische sleutels, zoals AES, of botsende hashes, zoals SHA-256, waar je, als je een inspanning nodig had in de hoeveelheid X vóór quantum computing, dat misschien zou kunnen doen met een inspanning van alleen de vierkantswortel van X achteraf.

Maar wat nog belangrijker is, voor een andere klasse van cryptografische algoritmen, met name sommige soorten cryptografie met openbare sleutels, zou je de benodigde kraakinspanning van X kunnen verminderen tot de *logaritme* van X.

En om u een idee te geven van hoe ingrijpend die veranderingen kunnen zijn, sprekend in basis 10, laten we zeggen dat u een probleem heeft dat u 1,000,000 moeite zou kosten.

De vierkantswortel van 1,000,000 is 1000 – klinkt veel handelbaarder, nietwaar?

En de logaritme van 1,000,000 [in basis 10] is slechts 6!

De zorg over kwantumcomputing en cryptografie is dus niet alleen dat de cryptografische algoritmen van vandaag op een bepaald moment in de toekomst aan vervanging toe zijn.

Het probleem is eigenlijk dat de dingen die we vandaag versleutelen, in de hoop het veilig te houden, bijvoorbeeld voor een paar jaar, of zelfs voor een paar decennia, * tijdens de levensduur van die gegevens * plotseling bijna in XNUMX keer kunnen worden gekraakt. een ogenblik…

…vooral voor een aanvaller met veel geld.

Met andere woorden, we moeten het algoritme wijzigen *voordat* we denken dat deze kwantumcomputers misschien komen, in plaats van te wachten tot ze voor de eerste keer verschijnen.

Je moet voorop lopen om als het ware gelijk te blijven.

We moeten cryptografisch wendbaar blijven, zodat we ons kunnen aanpassen aan deze veranderingen, en indien nodig proactief kunnen aanpassen, ruim van tevoren.

En *dat* is wat ik denk dat ze bedoelden cryptografische behendigheid.

Cybersecurity is een reis, geen bestemming.

En een deel van die reis is anticiperen op waar je heen gaat, niet wachten tot je daar bent.


DOUG.  Wat een vervolg op ons volgende verhaal!

Als het gaat om voorspellen wat er gaat gebeuren in 2023 moeten we onthouden dat de geschiedenis zich op een grappige manier herhaalt...

Naked Security 33 1/3 – Cybersecurity-voorspellingen voor 2023 en daarna


EEND.  Dat doet het, Doug.

En daarom had ik een nogal merkwaardige kop, waarbij ik dacht: “Hé, zou het niet cool zijn als ik een kop zou kunnen hebben als 'Naked Security 33 1/3'?

Ik kon me niet helemaal herinneren waarom ik dat grappig vond… en toen herinnerde ik me dat het Frank Drebin was… het was 'Naked *Gun* 33 1/3'. [LACHT]

Dat was niet waarom ik het schreef... de 33 1/3 was een beetje een grapje.

Het had eigenlijk "iets meer dan 34" moeten zijn, maar het is iets waar we het al een paar keer eerder over hebben gehad op de podcast.

De Internet-worm, in 1988 [“iets meer dan 34” jaar geleden], vertrouwden op drie belangrijke technieken voor wat je zou kunnen noemen: hacken, kraken en het verspreiden van malware.

Slechte wachtwoordkeuze.

Geheugen wanbeheer (buffer overflows).

En je bestaande software niet goed patchen of beveiligen.

Het wachtwoord raden… het had zijn eigen woordenboek van ongeveer 400 woorden bij zich, en het hoefde niet het wachtwoord van *iedereen* te raden, alleen *het wachtwoord van *iemand* op het systeem.

De bufferoverloop zat in dit geval op de stapel - die zijn tegenwoordig moeilijker te exploiteren, maar slecht geheugenbeheer is nog steeds verantwoordelijk voor een groot aantal bugs die we tegenkomen, waaronder enkele zero-days.

En natuurlijk niet patchen - in dit geval waren het mensen die mailservers hadden geïnstalleerd die waren gecompileerd voor foutopsporing.

Toen ze zich realiseerden dat ze dat niet hadden moeten doen, gingen ze nooit meer terug om het te veranderen.

En dus, als u op zoek bent naar cyberbeveiligingsvoorspellingen voor 2023, zullen er veel bedrijven zijn die u hun fantastische nieuwe visie, hun fantastische nieuwe bedreigingen zullen verkopen...

... en helaas is al het nieuwe spul iets waar je je ook zorgen over moet maken.

Maar de oude dingen zijn niet verdwenen, en als ze niet zijn verdwenen in 33 1/3 jaar, dan is het redelijk om te verwachten, tenzij we er erg krachtig over worden, zoals het Congres suggereert dat we doen met kwantumcomputing, dat we over 16 2/3 jaar nog steeds dezelfde problemen zullen hebben.

Dus als je enkele eenvoudige cyberbeveiligingsvoorspellingen voor 2023 wilt, kun je drie decennia teruggaan...


DOUG.  [LACHT] Ja!


EEND.  …en leren van wat er toen gebeurde.

Omdat, helaas, degenen die zich de geschiedenis niet kunnen herinneren, gedoemd zijn haar te herhalen.


DOUG.  Precies.

Laten we hier bij de toekomst blijven en het hebben over machine learning.

Maar dit gaat niet echt over machine learning, het is gewoon een goede oude supply chain-aanval met een toolkit voor machine learning.

PyTorch: Toolkit voor machinaal leren pwned van Kerstmis tot Nieuwjaar


EEND.  Nu, dit was het PyTorch – het wordt zeer veel gebruikt – en deze aanval was gericht op gebruikers van wat de "nightly build" wordt genoemd.

In veel softwareprojecten krijg je een 'stabiele build', die misschien eens per maand wordt bijgewerkt, en dan krijg je 'nightly builds', de broncode zoals de ontwikkelaars er nu aan werken.

Dus je wilt het waarschijnlijk niet in productie gebruiken, maar als je een ontwikkelaar bent, heb je misschien de nachtelijke build samen met een stabiele build, zodat je kunt zien wat er daarna komt.

Dus wat deze boeven deden is... ze vonden een pakket waarvan PyTorch afhankelijk was (het heet torchtriton), en ze gingen naar PyPI, de Python-pakketindex repository en ze hebben een pakket met die naam gemaakt.

Nu bestond zo'n pakket niet, omdat het normaal gesproken gewoon samen met PyTorch werd gebundeld.

Maar dankzij wat je zou kunnen beschouwen als een beveiligingsprobleem, of zeker als een beveiligingsprobleem, in de hele afhankelijkheidsbevredigende opzet voor Python-pakketbeheer...

... als je de update deed, zou het updateproces gaan: "Oh, torchtriton - dat is ingebouwd in PyTorch. O nee, wacht even! Er is een versie op PyPI, er is een versie op de openbare pakketindex; Ik zou beter die nemen! Dat is waarschijnlijk het echte werk, want het is waarschijnlijk actueler.”


DOUG.  Ohhhhhhh….


EEND.  En het was meer "up-to-date".

Het was niet *PyTorch* die uiteindelijk met malware werd geïnfecteerd, het was gewoon dat tijdens het installatieproces een malwarecomponent in uw systeem werd geïnjecteerd die daar zat en draaide, onafhankelijk van enige machine learning die u zou kunnen doen.

Het was een programma met de naam triton.

En wat het eigenlijk deed was: het las een hele lading van je privégegevens, zoals de hostnaam; de inhoud van verschillende belangrijke systeembestanden, zoals /etc/passwd (die op Linux gelukkig geen wachtwoord-hashes bevat, maar wel een volledige lijst van gebruikers op het systeem); en jouw .gitconfig, wat, als je een ontwikkelaar bent, waarschijnlijk heel veel zegt over projecten waaraan je werkt.

En het ondeugendste van allemaal: de inhoud van je .ssh directory, waar gewoonlijk uw privésleutels worden opgeslagen.

Het bundelde al die gegevens en stuurde het uit, Doug, als een reeks DNS-verzoeken.

Dus dit is Log4J helemaal opnieuw.

Weet je nog dat Log4J-aanvallers dit deden?

Log4Shell uitgelegd - hoe het werkt, waarom u het moet weten en hoe u het kunt oplossen


DOUG.  Ja.


EEND.  Ze zeiden: “Ik ga niet de moeite nemen om LDAP en JNDI te gebruiken, en al die dingen .class bestanden en al die complexiteit. Dat zal opvallen. Ik ga niet proberen code op afstand uit te voeren... Ik ga gewoon een onschuldig ogende DNS-lookup doen, wat de meeste servers toestaan. Ik ben geen bestanden aan het downloaden of iets aan het installeren. Ik zet gewoon een naam om in een IP-nummer. Hoe schadelijk kan dat zijn?”

Welnu, het antwoord is dat als ik de boef ben en ik beheer een domein, ik mag kiezen welke DNS-server u over dat domein vertelt.

Dus als ik tegen mijn domein opkijk, wordt een "server" (ik gebruik air-quotes) genoemd SOMEGREATBIGSECRETWORD stip MYDOMAIN stip EXAMPLE, dan die tekenreeks over de SECRETWORD wordt verzonden in het verzoek.

Het is dus een heel, heel, irritant effectieve manier om te stelen (of om het militaristische jargon te gebruiken waar cybersecurity van houdt, exfiltreren) privégegevens van uw netwerk, op een manier die niet door veel netwerken wordt gefilterd.

En veel erger, Doug: die gegevens waren versleuteld (met 256-bits AES, niet minder), dus de string-die-eigenlijk-geen-servernaam was, maar eigenlijk geheime gegevens waren, zoals je privésleutel...

...dat was gecodeerd, zodat als je alleen maar door je logboeken zou kijken, je geen voor de hand liggende dingen zou zien als: “Hé, wat doen al die gebruikersnamen in mijn logboeken? Dat is vreemd!"

Je zou gewoon gekke, rare tekststrings zien die er niet veel uitzagen.

Je kunt dus niet gaan zoeken naar strings die mogelijk ontsnapt zijn.

Echter: [PAUSE] hardgecodeerde sleutel en initialisatievector, Doug!

Daarom. iedereen op uw netwerkpad die het heeft ingelogd, zou, als ze kwade bedoelingen hadden, die gegevens later kunnen gaan ontsleutelen.

Er was niets met een geheim dat alleen bekend was bij de boeven.

Het wachtwoord dat u gebruikt om de gestolen gegevens te decoderen, waar ter wereld deze zich ook bevinden, is begraven in de malware - het kost vijf minuten om ze te herstellen.

De boeven die dit deden zeggen nu: [MOCK NUMILITY] “Oh nee, het was alleen maar onderzoek. Eerlijk!"

Ja, klopt.

U wilde "bewijzen" (nog grotere luchtquotes dan voorheen) dat aanvallen op de toeleveringsketen een probleem zijn.

Dus je "bewees" (zelfs grotere luchtaanhalingstekens dan degene die ik zojuist gebruikte) door de privésleutels van mensen te stelen.

En je hebt ervoor gekozen om het op zo'n manier te doen dat iedereen die die gegevens in handen heeft gekregen, op een eerlijke manier of door een fout, nu of later, niet eens het hoofdwachtwoord hoeft te kraken, zoals bij LastPass.


DOUG.  Wow.


EEND.  Blijkbaar hebben deze boeven zelfs gezegd: "Oh, maak je geen zorgen, eerlijk gezegd hebben we alle gegevens verwijderd."

Goed…

A) Ik geloof je niet. Waarom zou ik?


DOUG.  [LACH]


EEND.  En B) [KRUIS] OOK. LAAT. MAATJE.


DOUG.  Dus waar staan ​​de dingen nu?

Alles weer normaal?

Wat doe je?


EEND.  Het goede nieuws is dat als geen van je ontwikkelaars deze nachtelijke build heeft geïnstalleerd, eigenlijk tussen Kerstmis en Nieuwjaar 2022 (de exacte tijden staan ​​in het artikel), het goed zou moeten zijn.

Want dat was de enige periode dat dit kwaadaardig was torchtriton pakket was op de PyPI-repository.

Het andere is dat, voor zover we weten, er alleen een Linux-binair bestand werd geleverd.

Dus als je op Windows werkt, dan neem ik aan dat als je het Windows Subsystem for Linux (WSL) niet hebt geïnstalleerd, dit ding gewoon zoveel onschuldige binaire rotzooi voor je zou zijn.

Omdat het een Elf-binair bestand is, geen PE-binair bestand, om de technische termen te gebruiken, dus het zou niet werken.

En er zijn ook een heleboel dingen die je, als je je zorgen maakt, kunt opzoeken in de logboeken.

Als je DNS-logboeken hebt, gebruikten de boeven een specifieke domeinnaam.

De reden dat het ding plotseling een non-issue werd (ik denk dat het op 30 december 2022 was) is dat PyTorch het juiste deed...

…Ik stel me voor dat ze in combinatie met de Python Package Index het frauduleuze pakket eruit hebben gegooid en het in wezen hebben vervangen door een "blindganger" torchtriton pakket dat niets doet.

Het bestaat gewoon om te zeggen: “Dit is niet echt torchtriton pakket", en het vertelt je waar je de echte kunt krijgen, die van PyTorch zelf is.

En dit betekent dat als je dit ding downloadt, je niets krijgt, laat staan ​​malware.

We hebben enkele indicatoren van compromissen [IoC's] in het artikel over naakte beveiliging.

We hebben een analyse van het cryptografische deel van de malware, zodat u kunt begrijpen wat er mogelijk is gestolen.

En helaas, Doug, als je twijfelt, of als je denkt dat je geraakt bent, dan zou het een goed idee zijn, hoe pijnlijk het ook zal zijn... je weet wat ik ga zeggen.

Het is precies wat je moest doen met al je LastPass-dingen.

Ga en regenereer nieuwe privésleutels of sleutelparen voor uw SSH-aanmeldingen.

Omdat het probleem is dat wat veel ontwikkelaars doen ... in plaats van inloggen op basis van een wachtwoord, ze inloggen met een openbaar/privé sleutelpaar.

Je genereert een sleutelpaar, je zet de publieke sleutel op de server waarmee je verbinding wilt maken en je houdt zelf de private sleutel.

En dan, wanneer u wilt inloggen, in plaats van een wachtwoord in te voeren dat over het netwerk moet reizen (ook al is het onderweg misschien versleuteld), decodeert u uw privésleutel lokaal in het geheugen en gebruikt u deze om te ondertekenen een bericht om te bewijzen dat u de overeenkomende privésleutel voor de server hebt ... en u wordt binnengelaten.

Het probleem is dat als je een ontwikkelaar bent, je vaak wilt dat je programma's en je scripts die op een privésleutel gebaseerde login kunnen doen, dus veel ontwikkelaars zullen privésleutels hebben die niet-versleuteld zijn opgeslagen.


DOUG.  OK.

Nou, ik aarzel om dit te zeggen, maar we houden dit in de gaten!

En we hebben een interessant commentaar van een anonieme lezer op dit verhaal die gedeeltelijk vraagt:

“Zou het mogelijk zijn om de datacache van de boeven te vergiftigen met nutteloze gegevens, SSH-sleutels en uitvoerbare bestanden die ze blootleggen of infecteren als ze dom genoeg zijn om ze uit te voeren? Kortom, om de echte geëxfiltreerde gegevens te begraven achter een hoop rotzooi waar ze doorheen moeten filteren?


EEND.  Honeypots, of valse databases, *zijn* echt.

Ze zijn een erg handig hulpmiddel, zowel bij onderzoek naar cyberbeveiliging... om de boeven te laten denken dat ze op een echte site zitten, zodat ze niet zomaar zeggen: “Oh, dat is een cyberbeveiligingsbedrijf; Ik geef het op”, en probeer niet echt de trucs die je wilt dat ze je onthullen.

En natuurlijk ook handig voor wetshandhaving.

Het probleem is dat als je het zelf wilt doen, je er gewoon voor moet zorgen dat je niet verder gaat dan wat wettelijk toegestaan ​​is voor jou.

Wetshandhavers kunnen mogelijk een bevel krijgen om terug te hacken...

... maar waar de commentator zei: "Hé, waarom probeer ik ze niet gewoon in ruil daarvoor te infecteren?"

Het probleem is dat als je dat doet... nou ja, je zou veel sympathie kunnen krijgen, maar in de meeste landen zou je toch vrijwel zeker de wet overtreden.

Zorg er dus voor dat uw reactie proportioneel, nuttig en vooral legaal is.

Omdat het geen zin heeft om alleen maar met de boeven te rotzooien en zelf in heet water terecht te komen.

Dat zou een ironie zijn waar je best zonder zou kunnen!


DOUG.  Oké, heel goed.

Heel erg bedankt voor het insturen, beste anonieme lezer.

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 die je eraan herinnert, tot de volgende keer, om...


BEIDE.  Blijf veilig!

[MUZIEK MODEM]


spot_img

Laatste intelligentie

spot_img