KAN MAN BLI HACKAD OCH SEDAN ÅTALAS FÖR DET?
kryptovaluta brottsherrar. Säkerhetskorrigeringar för VMware, OpenSSH och OpenSSL. Medicinsk överträdare busted. Är det a bug eller en funktion?
Klicka och dra på ljudvågorna nedan för att hoppa till valfri punkt. Du kan också lyssna direkt på Soundcloud.
Med Doug Aamoth och Paul Ducklin
Intro och outro musik av Edith Mudge.
Du kan lyssna på oss på soundcloud, Apple Podcasts, Google Podcasts, Spotify, häft och överallt där bra poddar finns. Eller bara släpp URL till vårt RSS-flöde till din favoritpodcatcher.
LÄS TRANSKRIPTET
DOUG. Patchar, fixar och brottsherrar – herregud!
Åh, och ännu en lösenordshanterare i nyheterna.
Allt det och mer i podden Naked Security.
[MUSIKALT MODEM]
Välkommen till podden, alla.
Jag är Paul Ducklin; han är Doug Aamoth...
..tror jag fick det bakvänt, Paul: *Jag* är Doug Aamoth; *han* är Paul Ducklin.
Paul, vi gillar att börja föreställningen med en Denna vecka i teknisk historia segmentet.
Och jag skulle vilja skicka in något från den allra senaste historien.
Den här veckan, den 06 februari 2023, vår egen Paul Ducklin...
ANKA. [FÖRLYDAD] Wooooo!
DOUG. .publicerade en intervju med teknikjournalist Andy Greenberg om hans nya bok, "Spår i mörkret – den globala jakten på kryptovalutans brottsherrar."
Låt oss lyssna på ett snabbt klipp...
[MUSIKAL STING]
PAUL DUCKLIN. Det har verkligen funnits en fascination i årtionden att säga, "Vet du vad? Det här med kryptering? Det är faktiskt en riktigt, riktigt dålig idé. Vi behöver bakdörrar. Vi måste kunna bryta det, någon måste tänka på barnen, etc, etc.”
ANDY GREENBERG. Tja, det är intressant att prata om kryptobakdörrar och den juridiska debatten om kryptering som inte ens brottsbekämpande myndigheter kan knäcka.
Jag tror att berättelsen i den här boken på något sätt visar att det ofta inte är nödvändigt.
Jag menar, brottslingarna i den här boken använde traditionell kryptering.
De använde Tor och Dark Web.
Och inget av det var knäckt för att slå dem.
[MUSIKAL STING]
ANKA. Jag vet att jag skulle säga det här, Doug, men jag rekommenderar starkt att du lyssnar på det podcast.
Eller, om du föredrar att läsa, gå och titta igenom utskriften, för...
…som jag sa till Andy i slutet, det var lika fascinerande att prata med honom som att läsa boken från början.
Jag rekommenderar verkligen boken, och han har några fantastiska insikter om saker som kryptografiska bakdörrar som inte bara kommer från åsikter, utan från att titta på hur brottsbekämpande myndigheter har hanterat cyberbrott, uppenbarligen mycket effektivt, utan att behöva trampa på vår integritet kanske som så mycket som vissa tycker är nödvändigt.
Så, några fascinerande insikter där, Doug:
Tracers in the Dark: The Global Hunt for the Crime Lords of Crypto
DOUG. Kolla in det... det står i standarden Podcastflöde för Naked Security.
Om du får vår podcast borde det vara den precis innan detta.
Och låt oss nu gå vidare till en blixtrunda av fixar-och-uppdateringar.
Vi har OpenSSL. vi har VMware och vi har OpenSSH.
Låt oss börja med VMware. Paul:
VMWare-användare? Orolig för "ESXi ransomware"? Kontrollera dina patchar nu!
ANKA. Det här blev en enorm historia, tror jag, på grund av en bulletin som gavs ut av det franska CERT (Computer Emergency Response Team) i fredags förra veckan.
Så. det skulle vara den 03 februari 2023.
De berättade helt enkelt hur det var: "Hej, det finns dessa gamla sårbarheter i VMware ESXi som du kunde ha korrigerat 2000 och 2021, men vissa människor gjorde det inte, och nu missbrukar skurkar dem. Överraskning, överraskning: slutresultatet är lika med ransomware.”
De uttryckte det inte riktigt så... men det var syftet med bulletinen.
Det blev liksom lite av en nyhetsstorm av [STARTLED RÖST], "Åh, nej! Jättebugg i VMware!”
Det verkar som om folk drog slutsatsen, "Åh, nej! Det finns en helt ny nolldag! Det är bäst att jag kastar ut allt och går och tittar!”
Och på vissa sätt är det värre än en noll-dag, för om du riskerar att drabbas av denna speciella boutique-cybergängs attack, som slutar i ransomware...
...du har varit sårbar i två år.
DOUG. En 730-dagars, faktiskt...
ANKA. Exakt!
Så jag skrev artikeln för att förklara vad problemet var.
Jag dekompilerade och analyserade också skadlig programvara som de använde i slutet.
För jag tror att det som många läste in i den här berättelsen är: "Wow, det finns en stor bugg i VMware, och det leder till ransomware. Så om jag är patchad behöver jag inte göra någonting, och ransomwaren kommer inte att hända.”
Och problemen är att dessa hål i huvudsak kan användas för att få root-åtkomst på ESXi-boxar, där skurkarna inte behöver använda ransomware.
De kunde stjäla data, skicka skräppost, nyckelloggning, kryptominering, {infoga minsta favorit cyberbrottslighet här}.
Och ransomware-verktyget som dessa skurkar använder, som är halvautomatiskt men kan användas manuellt, är en fristående filförvrängare som är utformad för att snabbt förvränga riktigt stora filer.
Så de är inte helt krypterade – de har konfigurerat det så att det krypterar en megabyte, hoppar över 99 MB, krypterar en megabyte, hoppar över 99 MB...
…så det kommer att ta sig igenom en multi-gigabyte eller till och med en terabyte VMDK (virtuell maskinbildsfil) riktigt, riktigt snabbt.
Och de har ett skript som kör det här krypteringsverktyget för varje VMware-bild det kan hitta, allt parallellt.
Naturligtvis kan vem som helst distribuera detta särskilda verktyg *utan att bryta sig in genom VMware-sårbarheten*.
Så om du inte är patchad, slutar det inte nödvändigtvis i ransomware.
Och om du är lappad är det inte det enda sättet som skurkarna kan komma in.
Så det är användbart att informera dig själv om riskerna med denna ransomware och hur du kan försvara dig mot den.
DOUG. OK, mycket bra.
Då har vi en stickbar dubbelfri minnesbugg i OpenSSH.
Det är kul att säga...
OpenSSH fixar dubbelfri minnesbugg som går att köpa över nätverket
ANKA. Det är det, Doug.
Och jag tänkte, "Det är ganska roligt att förstå," så jag skrev det på Naked Security som ett sätt att hjälpa dig att förstå en del av den här minnesrelaterade buggargongen.
Det är ett ganska esoteriskt problem (det kommer förmodligen inte att påverka dig om du använder OpenSSH), men jag tycker fortfarande att det är en intressant historia, eftersom [A] eftersom OpenSSH-teamet beslutade att de skulle avslöja det i sina releasenotes, "Det har inget CVE-nummer, men så här fungerar det ändå,” och [B] det är en bra påminnelse om att minneshanteringsbuggar, särskilt när du kodar i C, kan hända även erfarna programmerare.
Detta är en dubbelfri, vilket är ett fall där du avslutar med ett minnesblock, så du lämnar tillbaka det till systemet och säger, "Du kan ge detta till en annan del av mitt program. Jag är klar med det."
Och sedan, senare, istället för att använda samma block igen efter att du har gett upp (vilket uppenbarligen skulle vara dåligt), lämnar du tillbaka minnet igen.
Och det låter ungefär som, "Jaha, vad är skadan? Du ser bara till.”
Det är som att springa tillbaka från parkeringen till din lägenhet och gå upp och kolla: "Stängde jag verkligen av ugnen?"
Det spelar ingen roll om du går tillbaka och det är avstängt; det spelar bara roll om du går tillbaka och du upptäcker att du inte stängde av den.
Så vad är skadan med en dubbelfri?
Problemet är förstås att det kan förvirra det underliggande systemet, och det kan leda till att någon annans minne blir misskött eller missköterligt på ett sätt som skurkar kan utnyttja.
Så om du inte förstår hur allt det där fungerar, så tycker jag att det här är en intressant, kanske till och med viktig, läsning...
… även om buggen är någorlunda esoterisk och, så vitt vi vet, har ingen kommit på ett sätt att utnyttja den ännu.
DOUG. Sist men absolut inte minst finns det en hög stränghet bugg för datastöld i OpenSSL som har åtgärdats.
Och jag skulle uppmana folk, om du är som jag, någorlunda tekniska, men jargongvilliga...
…de officiella anteckningarna är fulla av jargong, men, Paul, du gör ett mästerligt jobb med att översätta jargongen till vanlig engelska.
Inklusive en dynamitförklaring av hur minnesbuggar fungerar, inklusive: NULL-dereferens, ogiltig pekareferens, läsbuffertspill, use-efter-free, double-free (som vi precis pratade om) och mer:
OpenSSL fixar datastöldfel med hög allvarlighetsgrad – korrigera nu!
ANKA. [PAUS] Tja, du har lämnat mig lite mållös där, Doug.
Tack så mycket för dina vänliga ord.
Jag skrev den här för... Jag tänkte säga två skäl, men typ tre skäl.
Den första är att OpenSSH och OpenSSL är två helt olika saker – de är två helt olika projekt med öppen källkod som drivs av olika team – men de används båda extra mycket.
Så, OpenSSL-buggen i synnerhet gäller förmodligen dig någonstans i din IT-anläggning, eftersom någon produkt du har någonstans nästan säkert inkluderar den.
Och om du har en Linux-distro så ger distron förmodligen sin egen version också - min Linux uppdaterades samma dag, så du vill gå och kolla själv.
Så jag ville göra folk medvetna om de nya versionsnumren.
Och, som vi sa, det var denna svindlande mängd jargong som jag tyckte var värd att förklara... varför även små saker spelar roll.
Och det finns en stor bugg. (Jag ska inte förklara typ förvirring här – gå till artikeln om du vill ha några analogier om hur det fungerar.)
Och det här är ett fall där en angripare kanske bara kan utlösa vad som verkar vara helt oskyldiga minnesjämförelser där de bara jämför denna minnesbuffert med den minnesbufferten...
…men de riktar fel på en av buffertarna och se, de kan räkna ut vad som finns i *din* buffert genom att jämföra den med kända saker som de har lagt i *sin*.
I teorin kan du missbruka en sådan bugg på vad du kan kalla ett Heartbleed-sätt.
Jag är säker på att vi alla kommer ihåg att om våra IT-karriärer går tillbaka till 2014 eller tidigare – det OpenSSL Heartbleed bugg, där en klient kunde pinga en server och säga, "Lever du fortfarande?"
"Heartbleed heartache" – ska du VERKLIGEN byta alla dina lösenord direkt?
Och det skulle skicka ett meddelande tillbaka som inkluderade upp till 64 kilobyte extra data som möjligen inkluderade andras hemligheter av misstag.
Och det är problemet med minnesläckage buggar, eller potentiella minnesläckage buggar, i kryptografiska produkter.
De har i allmänhet mycket mer att dölja än traditionella program!
Så, gå och läs det och lappa definitivt så snart du kan.
DOUG. Jag kan inte tro att Heartbleed var 2014.
Det verkar... Jag hade bara ett barn när det kom ut och han var en bebis, och nu har jag två till.
ANKA. Och ändå pratar vi fortfarande om det...
DOUG. Allvarligt!
ANKA. …som en avgörande påminnelse om varför ett enkelt läsbuffertspill kan vara ganska katastrofalt.
Eftersom många människor tenderar att tänka, "Åh, ja, visst är det mycket mindre skadligt än ett *skriv* buffertspill, där jag kan komma att injicera skalkod eller avleda ett programs beteende?"
Visst, om jag bara kan läsa saker, ja, jag kanske får dina hemligheter... det är dåligt, men det låter mig inte få root-åtkomst och ta över ditt nätverk.
Men som många nya dataintrång har visat, kan ibland kunna läsa saker från en server spilla hemligheter som låter dig logga in på en massa andra servrar och göra mycket tråkigare saker!
DOUG. Tja, det är en bra strid om stygga saker och hemligheter.
Vi har en uppdatering till en story från Naken Säkerhet förbi.
Du kanske minns historien från slutet av förra året om någon som bryter mot ett psykoterapiföretag och stjäl en massa utskrifter av terapisessioner och sedan använder den informationen för att utpressa patienterna på detta företag.
Tja, han gick på flykt... och var bara nyligen arresterad i Frankrike:
Finsk misstänkt för utpressning av psykoterapi greps i Frankrike
ANKA. Detta var ett riktigt fult brott.
Han gjorde inte bara intrång i ett företag och stal en mängd data.
Han gjorde intrång i ett *psykoterapi* företag, och dubbelt tråkigt nog hade det företaget varit helt försumligt, verkar det som, i sin datasäkerhet.
Faktum är att deras tidigare VD har problem med myndigheterna på anklagelser som själva kan resultera i ett fängelsestraff, eftersom de helt enkelt hade all denna dynamitinformation som de verkligen var skyldiga sina patienter att skydda, och inte hade det.
De lade den på en molnserver med ett standardlösenord, tydligen, där skurken snubblade över den.
Men det var naturen av hur brottet utvecklades som verkligen var hemskt.
Han utpressade företaget... Jag tror att han sa, "Jag vill ha 450,000 XNUMX € annars kommer jag att spilla all data."
Och givetvis hade företaget hållit tumm på det – det var därför tillsynsmyndigheterna beslutade att också gå efter företaget.
De hade hållit tyst om det i hopp om att ingen någonsin skulle få reda på det, och här kommer den här killen och säger: "Betala oss pengarna, annars."
Tja, de tänkte inte betala honom.
Det var ingen mening: han hade redan fått datumet, och han gjorde redan dåliga saker med det.
Och så, som du säger, bestämde skurkarna, "Tja, om jag inte kan få ut 450,000 200 euro från företaget, varför försöker jag inte slå till varenda person som genomgått psykoterapi för XNUMX euro var?"
Enligt den välkända cybersleuth-journalisten Brian Krebs stod det i hans utpressningssedel: "Du har 24 timmar på dig att betala mig €200. Då ger jag dig 48 timmar att betala 500 €. Och om jag inte har hört från dig efter 72 timmar, kommer jag att berätta för dina vänner och familj och alla som vill veta vad du sa.”
Eftersom uppgifterna inkluderade avskrifter, Doug.
Varför i hela friden lagrade de ens dessa saker som standard från första början?
Det kommer jag aldrig att förstå.
Som du säger, flydde han landet och han arresterades "in absentia" av finnarna; som gjorde det möjligt för dem att utfärda en internationell arresteringsorder.
Hur som helst, nu står han inför musiken i Frankrike, där fransmännen naturligtvis försöker utlämna honom till Finland, och finländarna försöker ställa honom inför rätta.
Tydligen har han form [motsvarighet i USA: tidigare] för detta. Doug.
Han har dömts för cyberbrott tidigare, men då var han minderårig.
Han är nu 25 år gammal, tror jag; då var han 17, så han fick en andra chans.
Han fick villkorlig dom och ett mindre böter.
Men om dessa anklagelser är korrekta, tror jag att många av oss misstänker att han inte kommer att gå så lättvindigt den här gången, om han döms.
DOUG. Så det här är en bra påminnelse om att du kan vara – om du är som det här företaget – både offret *och* den skyldige.
Och ännu en påminnelse om att du måste ha en plan på plats.
Så vi har några råd i slutet av artikeln, som börjar med: Repetera vad du kommer att göra om du själv drabbas av ett brott.
Du måste ha en plan!
ANKA. Absolut.
Du kan inte ta igen det medan du går, för det kommer helt enkelt inte att finnas tid.
DOUG. Och även, om du är en person som påverkas av något i stil med detta: Överväg att göra en anmälan, eftersom det hjälper med utredningen.
ANKA. Det gör det verkligen.
Min uppfattning är att i det här fallet gick många människor som fick dessa utpressningskrav till myndigheterna och sa: "Det här kom helt ur det blå. Det här är som att bli överfallen på gatan! Vad ska du göra åt det?"
Myndigheterna sa, "Bra, låt oss samla in rapporterna", och det betyder att de kan bygga ett bättre ärende och göra starkare argument för något som utlämning.
DOUG. Okej, mycket bra.
Vi kommer att avsluta vår show med: "En annan vecka, ännu en lösenordshanterare på heta stolen."
Den här gången är det KeePass.
Men just denna kerfuffle är inte så enkel, Paul:
Lösenordsstöld "sårbarhet" rapporterad i KeePass - bugg eller funktion?
ANKA. Egentligen, Doug, tror jag att man kan säga att det är väldigt enkelt... och oerhört komplicerat på samma gång. [skrattar]
DOUG. [SKratt] OK, låt oss prata om hur det här faktiskt fungerar.
Funktionen i sig är en slags automatiseringsfunktion, en skripttyp...
ANKA. "Trigger" är termen att söka efter – det är vad de kallar det.
Så när du till exempel sparar [KeePass]-databasfilen (kanske du har uppdaterat ett lösenord eller skapat ett nytt konto och trycker på spara-knappen), vore det inte trevligt om du kunde ringa på ett eget anpassat skript som synkroniserar den datan med någon molnsäkerhetskopiering?
Istället för att försöka skriva kod i KeePass för att hantera alla möjliga molnuppladdningssystem i världen, varför inte tillhandahålla en mekanism där människor kan anpassa den om de vill?
Exakt samma sak när du försöker använda ett lösenord... du säger, "Jag vill kopiera det lösenordet och använda det."
Skulle det inte vara trevligt om du kunde anlita ett skript som får en kopia av klartextlösenordet, så att det kan använda det för att logga in på konton som inte är fullt så enkla som att bara lägga in data i ett webbformulär som finns på din skärm?
Det kan vara något som ditt GitHub-konto, eller ditt konto för kontinuerlig integration, eller vad det nu är.
Så dessa saker kallas "triggers" eftersom de är designade för att trigga när produkten gör vissa saker.
Och några av dessa saker – oundvikligen, eftersom det är en lösenordshanterare – handlar om att hantera dina lösenord.
Nejsägarna känner att "Åh, ja, dessa utlösare, de är för lätta att ställa in, och att lägga till en utlösare skyddas inte av sig själv av ett lösenord för manipuleringsskydd."
Du måste ange ett huvudlösenord för att få tillgång till dina lösenord, men du behöver inte ange huvudlösenordet för att få tillgång till konfigurationsfilen för att få tillgång till lösenorden.
Det är, tror jag, där nejsägarna kommer ifrån.
Och andra människor säger: "Vet du vad? De måste få tillgång till konfigurationsfilen. Om de har det så är du redan i djupa problem!”
DOUG. "Människorna" inkluderar KeePass, som säger, "Det här programmet är inte inrättat för att försvara sig mot någon [skrattar] som sitter i din stol när du redan har loggat in på din maskin och appen."
ANKA. Verkligen.
Och jag tror sanningen ligger någonstans i mitten.
Jag kan se argumentet varför, om du ska ha lösenorden skyddade med huvudlösenordet... varför skyddar du inte konfigurationsfilen också?
Men jag håller också med folk som säger: ”Vet du vad? Om de har loggat in på ditt konto, och de är på din dator, och de redan är du, så kom du typ tvåa i loppet redan.”
Så gör inte det!
DOUG. [SKratt] OK, så om vi zoomar ut lite på den här historien...
...Naked Security-läsaren Richard frågar:
Är en lösenordshanterare, oavsett vilken, ett enda fel? Till sin design är det ett värdefullt mål för en hackare. Och närvaron av en sårbarhet tillåter en angripare att jackpotta varje lösenord på systemet, oavsett dessa lösenords teoretiska styrka.
Jag tror att det är en fråga som många ställer sig just nu.
ANKA. På ett sätt, Doug, är det en slags obesvarbar fråga.
Lite som den här "trigger"-saken i konfigurationsfilen i KeePass.
Är det en bugg, eller är det en funktion, eller måste vi acceptera att det är lite av båda?
Jag tror, som en annan kommentator sa i samma artikel, att det finns ett problem med att säga: "En lösenordshanterare är en enda punkt där det går att misslyckas, så jag tänker inte använda en. Vad jag ska göra är att jag kommer på *ett* riktigt, riktigt, komplicerat lösenord och jag kommer att använda det för alla mina webbplatser.”
Vilket är vad många människor gör om de inte använder en lösenordshanterare... och istället för att vara en *potentiell* enskild felpunkt skapar det något som är exakt, absolut *och redan* en enda felpunkt.
Därför är en lösenordshanterare verkligen det minsta av två onda.
Och jag tror att det ligger mycket sanning i det.
DOUG. Ja, jag skulle säga att jag tror att det *kan* vara en enda punkt av misslyckande, beroende på vilken typ av konton du har.
Men för många tjänster är och bör det inte vara en enda punkt av *totalt* misslyckande.
Till exempel, om mitt banklösenord blir stulet och någon går för att logga in på mitt bankkonto, kommer min bank att se att de loggar in från andra sidan jorden och säga, "Wow! Vänta en sekund! Det här ser konstigt ut."
Och de kommer att ställa en säkerhetsfråga till mig, eller så skickar de mig en sekundär kod som jag måste lägga in, även om jag inte är inställd för 2FA.
De flesta av mina viktiga konton... Jag oroar mig inte så mycket för dessa referenser, eftersom det skulle finnas en automatisk andra faktor som jag skulle behöva hoppa igenom eftersom inloggningen skulle se misstänkt ut.
Och jag hoppas att tekniken blir så lätt att implementera att alla webbplatser som lagrar någon form av data bara har det inbyggda: "Varför loggar den här personen in från Rumänien mitt i natten, när de vanligtvis är i Boston?"
Många av dessa säkerhetsskåp är på plats för stora viktiga saker som du kan ha online, så jag hoppas att det inte behöver vara en enda punkt av misslyckande i den meningen.
ANKA. Det är en bra poäng, Doug, och jag tror att det på ett sätt illustrerar att det finns, om du vill, en brännande fråga bakom frågan, som är: "Varför behöver vi så många lösenord överhuvudtaget?"
Och kanske ett sätt att gå mot en lösenordslös framtid är helt enkelt att tillåta människor att använda webbplatser där de kan välja *inte* att ha den "gigantiska bekvämligheten" att behöva skapa ett konto i första hand.
DOUG. [GLUM LAUGH] När vi diskuterade påverkades jag av LastPass-intrånget, och jag tittade på min gigantiska lista med lösenord och sa: "Åh, herregud, jag måste gå och byta alla dessa lösenord!"
Som det visade sig var jag tvungen att *byta* hälften av dessa lösenord, och värre, jag var tvungen att *avbryta* den andra hälften av dessa konton, eftersom jag hade så många konton där inne...
…bara för vad du sa; "Jag måste skapa ett konto bara för att komma åt något på den här webbplatsen."
Och de är inte alla bara klicka-och-avbryt.
Vissa, du måste ringa.
Vissa, du måste prata med någon via livechatt.
Det var mycket svårare än att bara byta en massa lösenord.
Men jag skulle uppmana folk, oavsett om du använder en lösenordshanterare eller inte, ta en titt på bara det stora antalet konton du har och ta bort de du inte använder längre!
ANKA. Ja.
Med tre ord, "Mindre är mer."
DOUG. Absolut!
Okej, tack så mycket, Richard, för att du skickade in det.
Om du har en intressant berättelse, kommentar eller fråga som du vill skicka in, läser vi det gärna i podden.
Du kan skicka e-post till tips@sophos.com, du kan kommentera någon av våra artiklar, eller så kan du kontakta oss på sociala: @NakedSecurity.
Det är vår show för idag; tack så mycket för att du lyssnade.
För Paul Ducklin, jag heter Doug Aamoth, påminner dig tills nästa gång att...
BÅDE. Håll dig säker!
[MUSIKALT MODEM]
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
- Källa: https://nakedsecurity.sophos.com/2023/02/09/s3-ep121-can-you-get-hacked-and-then-prosecuted-for-it-audio-text/
- 000
- 2014
- 2021
- 2023
- 2FA
- a
- Able
- Om oss
- Om Crypto
- om det
- absolut
- missbruk
- Acceptera
- tillgång
- Konto
- konton
- tvärs
- faktiskt
- rådgivning
- påverka
- Efter
- mot
- Alla
- anklagelser
- tillåter
- redan
- OK
- fantastiska
- och
- Annan
- någon
- var som helst
- Lägenhet
- app
- Apple
- Argumentet
- arrestera
- arresterad
- Artikeln
- artiklar
- attackera
- audio
- Författaren
- Myndigheter
- Automat
- Automation
- Bebis
- tillbaka
- Bakdörrar
- säkerhetskopiering
- Badrum
- Bank
- bankkonto
- därför att
- passande
- innan
- Där vi får lov att vara utan att konstant prestera,
- tro
- nedan
- Bättre
- Stor
- Bit
- Blockera
- Blå
- boken
- boston
- boxar
- varumärke
- Brand New
- brott
- överträdelser
- Ha sönder
- Breaking
- Brian
- buffert
- buffertöverskridning
- Bug
- fel
- SLUTRESULTAT
- byggt
- bulletin
- Bunch
- byst
- Knappen
- Ring
- kallas
- kan inte
- bil
- karriärer
- Vid
- katastrofal
- VD
- vissa
- säkerligen
- Ordförande
- chans
- byta
- byte
- avgifter
- ta
- kontroll
- barn
- Barn
- Välja
- klient
- cloud
- molnserver
- koda
- Kodning
- samla
- COM
- komma
- kommande
- kommentar
- företag
- jämförande
- fullständigt
- komplicerad
- dator
- konfiguration
- kontinuerlig
- kunde
- land
- Naturligtvis
- Domstol
- spricka
- knäckt
- skapa
- skapar
- referenser
- Brott
- brottslingar
- Crooks
- crypto
- kryptovaluta
- kryptografisk
- Kryptomining
- CVE
- cyberbrottslighet
- mörkt
- mörk Web
- datum
- Dataöverträdelser
- datasäkerhet
- Databas
- Datum
- dag
- behandla
- diskussion
- årtionden
- beslutade
- djup
- Standard
- definierande
- definitivt
- förtjust
- krav
- beroende
- distribuera
- Designa
- utformade
- DID
- olika
- Avslöja
- diskuteras
- inte
- gör
- inte
- dubbelfri
- Drop
- varje
- jord
- effektivt
- Annars
- nödsituation
- krypterad
- kryptering
- tillämpning
- Engelska
- lika
- Motsvarande
- väsentligen
- fastigheter
- etc
- Även
- NÅGONSIN
- Varje
- allt
- exakt
- exempel
- erfaren
- Förklara
- Exploit
- utpressning
- extra
- utlämning
- vänd
- Misslyckande
- familj
- fascinerande
- Leverans
- Februari
- figured
- Fil
- Filer
- Arkivering
- hitta
- änden
- slut
- Finland
- Förnamn
- fixerad
- formen
- Tidigare
- tidigare vd
- hittade
- Frankrike
- franska
- Fredag
- vänner
- från
- full
- fullständigt
- kul
- framtida
- allmänhet
- genereras
- skaffa sig
- få
- jätte
- GitHub
- Ge
- ges
- Välgörenhet
- Go
- Bra
- Går
- kommer
- god
- stor
- Guy
- hackad
- Hackaren
- Hälften
- Arbetsmiljö
- hända
- skadliga
- huvud
- hört
- heartbleed
- hjälpa
- hjälper
- här.
- Dölja
- Hög
- historia
- Träffa
- slå
- Hål
- hoppas
- hoppas
- HET
- ÖPPETTIDER
- Hur ser din drömresa ut
- HTTPS
- stor
- SJUK
- Tanken
- bild
- oerhört
- genomföra
- med Esport
- in
- innefattar
- ingår
- innefattar
- Inklusive
- informationen
- insikter
- exempel
- istället
- integrering
- intressant
- Internationell
- Undersökningen
- fråga
- IT
- sig
- Jackpott
- jargong
- Jobb
- journalist
- hoppa
- Ha kvar
- hålla
- Snäll
- Vet
- känd
- Efternamn
- Förra året
- Lastpass
- Sent
- skrattar
- Lag
- brottsbekämpning
- leda
- ledande
- Adress
- mindre
- blixtnedslag
- linux
- Lista
- Lyssna
- liten
- lever
- läsa in
- se
- såg
- du letar
- UTSEENDE
- Lords
- Lot
- älskar
- Maskinen
- göra
- Framställning
- malware
- ledning
- chef
- manuellt
- många
- Master
- Materia
- Betyder Något
- betyder
- mekanism
- medicinsk
- Minne
- meddelande
- Mitten
- kanske
- mindre
- misstag
- pengar
- mer
- flytta
- Musik
- musikal
- Naken säkerhet
- Naken säkerhetspodcast
- Natur
- nödvändigtvis
- nödvändigt för
- Behöver
- behöver
- nät
- Nya
- nyheter
- Nästa
- natt
- normalt
- Anmärkningar
- Fiktiv
- antal
- nummer
- tjänsteman
- Gamla
- ONE
- nätet
- öppet
- öppen källkod
- open source-projekt
- openssl
- Yttrande
- Övriga
- skyldig
- egen
- Parallell
- Park
- del
- särskilt
- särskilt
- Lösenord
- Password Manager
- lösenord
- Lappa
- Plåster
- patienter
- paul
- Betala
- Personer
- människors
- kanske
- personen
- ping
- Plats
- Enkel
- Oformatterad text
- Planen
- plato
- Platon Data Intelligence
- PlatonData
- Massor
- podcast
- Podcasts
- Punkt
- möjlig
- inlägg
- potentiell
- föredra
- Närvaron
- fängelse
- privatpolicy
- förmodligen
- Problem
- problem
- Produkt
- Produkter
- Program
- programmerare
- projekt
- skydda
- skyddad
- visat
- ge
- ger
- psykoterapi
- Syftet
- sätta
- sätta
- fråga
- Snabbt
- snabbt
- Lopp
- Ransomware
- Läsa
- Läsare
- Läsning
- skäl
- mottagna
- senaste
- rekommenderar
- Oavsett
- Tillsynsmyndigheter
- frigöra
- ihåg
- rapport
- Rapporterad
- Rapport
- respons
- resultera
- Richard
- Risk
- risker
- Rumänien
- rot
- Root access
- rund
- rss
- Körning
- rinnande
- Nämnda
- Samma
- Save
- screen
- Sök
- Andra
- sekundär
- säkerhet
- söker
- verkar
- segmentet
- skicka
- känsla
- mening
- Tjänster
- sessioner
- in
- skall
- show
- Visar
- Enkelt
- helt enkelt
- enda
- webbplats
- Områden
- Sittande
- Small
- So
- Social hållbarhet
- några
- någon
- något
- någonstans
- Alldeles strax
- Källa
- skräppost
- Spotify
- fristående
- standard
- starta
- Starta
- bo
- Fortfarande
- stulna
- Storm
- Historia
- okomplicerad
- hållfasthet
- starkare
- starkt
- skicka
- säkert
- överraskning
- suspenderades
- misstänksam
- system
- Ta
- Diskussion
- tala
- Målet
- grupp
- lag
- tech
- Teknisk
- Teknologi
- Smakämnen
- världen
- deras
- sig själva
- terapi
- sak
- saker
- grundligt
- trodde
- tre
- Genom
- tid
- till
- i dag
- alltför
- verktyg
- Tor
- mot
- traditionell
- Avskrift
- utlösa
- problem
- SVÄNG
- vände
- typer
- underliggande
- förstå
- förståelse
- Uppdatering
- uppdaterad
- URL
- us
- användning
- använd-efter-fri
- Användare
- version
- Victim
- Virtuell
- virtuell maskin
- vmware
- Röst
- sårbarheter
- sårbarhet
- Sårbara
- vänta
- ville
- Motivera
- sätt
- webb
- webbsidor
- vecka
- ALLBEKANT
- Vad
- om
- som
- VEM
- kommer
- utan
- ord
- Arbete
- träna
- fungerar
- världen
- orolig
- värt
- skulle
- skriva
- skriva kod
- år
- år
- Din
- själv
- zephyrnet
- zoom