S3 Ep95: Slakk lekkasje, Github-angrep og post-kvantekrypto [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.  Slakke lekkasjer, slem GitHub-kode og post-kvantekryptografi.

Alt det, og mye mer, på Naked Security-podcasten.

[MUSIKK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug Aamoth.

Med meg er som alltid Paul Ducklin.

Paul, hvordan har du det i dag?

---

AND.  Super-duper, som vanlig, Doug!

---

DOUG.  Jeg er super-duper spent på å komme til denne uken Teknisk historie segment, fordi...

…du var der, mann!

Denne uken, 11. august...

---

AND.  Å nei!

Jeg tror at kronen nettopp har falt...

---

DOUG.  Jeg trenger ikke engang å si årstall!

11. august 2003 – verden la merke til Blaster-ormen, som påvirker Windows 2000- og Windows XP-systemer.

Blaster, også kjent som Lovesan og MsBlast, utnyttet et bufferoverløp og er kanskje mest kjent for meldingen, «Billy Gates, hvorfor gjør du dette mulig? Slutt å tjene penger og fiks programvaren din."

Hva skjedde, Paul?

---

AND.  Vel, det var epoken før, kanskje vi tok sikkerhet ganske så alvorlig.

Og heldigvis ville den typen feil være mye, mye vanskeligere å utnytte i disse dager: det var en stabelbasert bufferoverflyt.

Og hvis jeg husker rett, ble serverversjonene av Windows allerede bygget med det som heter stabelbeskyttelse.

Med andre ord, hvis du flyter over stabelen inne i en funksjon, vil den, før funksjonen kommer tilbake og gjør skaden med den ødelagte stabelen, oppdage at noe dårlig har skjedd.

Så den må stenge det fornærmende programmet, men skadelig programvare kommer ikke til å kjøre.

Men den beskyttelsen var ikke i klientversjonene av Windows på den tiden.

Og som jeg husker, var det en av de tidlige skadelige programmene som måtte gjette hvilken versjon av operativsystemet du hadde.

Er du på 2000? Er du på NT? Er du på XP?

Og hvis det ble feil, ville en viktig del av systemet krasje, og du vil få advarselen "Systemet ditt er i ferd med å slå seg av".

---

DOUG.  Ha, jeg husker de!

---

AND.  Så, det var den andre skaden som for mange mennesker var tegn på at du ble hamret av infeksjoner ...

…som kan være utenfra, som om du bare var en hjemmebruker og ikke hadde en ruter eller brannmur hjemme.

Men hvis du var inne i et selskap, ville det mest sannsynlige angrepet komme fra noen andre i selskapet som spydde ut pakker på nettverket ditt.

Så, veldig likt CodeRed-angrepet vi snakket om, som var et par år før det, i en nylig podcast, var det egentlig omfanget, volumet og hastigheten til denne tingen som var problemet.

---

DOUG.  Ok, vel, det var omtrent 20 år siden.

Og hvis vi skrur tiden tilbake til fem år siden, er det da Slack begynte å lekke hashed passord. [LATTER]

---

AND.  Ja, Slack, det populære samarbeidsverktøyet...

…den har en funksjon der du kan sende en invitasjonslenke til andre for å bli med i arbeidsområdet ditt.

Og du forestiller deg: du klikker på en knapp som sier "Generer en lenke", og den vil lage en slags nettverkspakke som sannsynligvis har noe JSON inni seg.

Hvis du noen gang har hatt en Zoom-møteinvitasjon, vil du vite at den har en dato og et klokkeslett, og personen som inviterer deg, og en URL du kan bruke for møtet, og et passord, og alt det der ting – den har ganske mye data der inne.

Normalt graver du ikke i rådataene for å se hva som er der – klienten sier bare: «Hei, her er et møte, her er detaljene. Vil du godta / kanskje / avslå?"

Det viste seg at når du gjorde dette med Slack, som du sier, i mer enn fem år, pakket inn i den invitasjonen var det uvedkommende data som ikke var strengt relevant for selve invitasjonen.

Så, ikke en URL, ikke et navn, ikke en dato, ikke et tidspunkt ...

…men den *inviterende brukerens passord hash* [LATER]

---

DOUG.  Hmmmmm.

---

AND.  Jeg unner deg ikke!

---

DOUG.  Det høres ille ut...

---

AND.  Ja, det gjør det virkelig, ikke sant?

Den dårlige nyheten er, hvordan i all verden kom det inn der?

Og når den først var der inne, hvordan i all verden unngikk den beskjed i fem år og tre måneder?

Faktisk, hvis du besøker artikkelen om Naked Security og ser på full URL av artikkelen, vil du legge merke til at det står på slutten, blahblahblah-for-three-months.

For når jeg først leste rapporten, ville tankene mine ikke se det som 2017! [LATTER]

Det var 17. april til 17. juli, så det var mange "17"-er der inne.

Og tankene mine tømte 2017 som startår – jeg misforsto det som «april til juli *i år*» [2022].

Jeg tenkte: "Wow, *tre måneder* og de la ikke merke til det."

Og så var den første kommentaren til artikkelen, "Ahem [HOSTE]. Det var faktisk 17. april *2017*.»

Wow!

Men noen skjønte det 17. juli [2022], og Slack, til deres ære, fikset det samme dag.

Som: "Å, herregud, hva tenkte vi på?!"

Så det er den dårlige nyheten.

Den gode nyheten er at det i det minste var *hashed* passord.

Og de ble ikke bare hash, de ble *saltet*, som er der du blander inn unikt utvalgte, tilfeldige data per bruker med passordet.

Tanken om dette er todelt.

Én, hvis to personer velger det samme passordet, får de ikke samme hash, så du kan ikke gjøre noen slutninger ved å se gjennom hash-databasen.

Og to, du kan ikke forhåndsberegne en ordbok med kjente hashes for kjente innganger, fordi du må lage en separat ordbok for hvert passord *for hvert salt*.

Så det er ikke en triviell øvelse å knekke hashed passord.

Når det er sagt, er hele ideen at de ikke skal være et offentlig register.

De hash og saltet *i tilfelle* de lekker, ikke *for at de skal kunne* lekke.

Så, egg i ansiktet til Slack!

Slack sier at omtrent én av 200 brukere, eller 0.5 %, ble berørt.

Men hvis du er en Slack-bruker, vil jeg anta at hvis de ikke skjønte at de lekket hash-passord i fem år, hadde de kanskje ikke helt oppregnet listen over personer som ble berørt fullstendig heller.

Så, gå og endre passordet ditt uansett ... du kan også.

---

DOUG.  OK, vi sier også: hvis du ikke bruker en passordbehandling, bør du vurdere å skaffe deg en; og slå på 2FA hvis du kan.

---

AND.  Jeg trodde du ville like det, Doug.

---

DOUG.  Ja, det gjør jeg!

Og så, hvis du er Slack eller firma som det, velg en anerkjente salt-hash-and-stretch-algoritme når du håndterer passord selv.

---

AND.  Ja.

Den store saken i Slacks svar, og det jeg trodde manglet, er at de bare sa: "Ikke bekymre deg, ikke bare hashte vi passordene, vi saltet dem også."

Mitt råd er at hvis du blir tatt i et brudd som dette, bør du være villig til å deklarere algoritmen eller prosessen du brukte for salting og hashing, og også ideelt sett hva som kalles stretching, som er der du ikke bare hash det saltede passordet én gang, men kanskje hash det 100,000 XNUMX ganger for å bremse ned enhver form for ordbok eller brute force-angrep.

Og hvis du oppgir hvilken algoritme du bruker og med hvilke parametere.. f.eks. PBKDF2, bcrypt, scrypt, Argon2 – det er de mest kjente passord-“salt-hash-stretch”-algoritmene der ute.

Hvis du faktisk oppgir hvilken algoritme du bruker, så: [A] du er mer åpen, og [B] du gir potensielle ofre for problemet en sjanse til å vurdere selv hvor farlig de tror dette kan ha vært .

Og den slags åpenhet kan faktisk hjelpe mye.

Slack gjorde ikke det.

De sa bare: "Å, de ble saltet og hasj."

Men det vi ikke vet er, la de i to byte salt og hash dem en gang med SHA-1 ...

…eller hadde de noe som var litt mer motstandsdyktig mot å bli sprukket?

---

DOUG.  Holder vi oss til emnet dårlige ting, merker vi en trend som utvikler seg der folk er injisere dårlige ting i GitHub, bare for å se hva som skjer, utsette risiko...

…vi har enda en av disse historiene.

---

AND.  Ja, noen som nå angivelig har kommet ut på Twitter og sagt: «Ikke bekymre deg folkens, ingen skade skjedd. Det var bare for forskning. Jeg skal skrive en rapport, skille meg ut fra Blue Alert.»

De opprettet bokstavelig talt tusenvis av falske GitHub-prosjekter, basert på å kopiere eksisterende legitim kode, bevisst sette inn noen malware-kommandoer der, for eksempel "ring hjem for ytterligere instruksjoner", og "tolke selve svaret som bakdørskode for å utføre", og så videre.

Så ting som virkelig kan gjøre skade hvis du installerte en av disse pakkene.

Gi dem legitime navn...

…låner, tilsynelatende, forpliktelseshistorien til et ekte prosjekt, slik at tingen så mye mer legitim ut enn du ellers kunne forvente hvis den bare dukket opp med, "Hei, last ned denne filen. Du vet at du vil!"

Egentlig?! Undersøkelser?? Vi visste ikke dette allerede?!!?

Nå kan du argumentere, "Vel, Microsoft, hvem eier GitHub, hva gjør de som gjør det så enkelt for folk å laste opp denne typen ting?"

Og det er en viss sannhet i det.

Kanskje de kunne gjøre en bedre jobb med å holde skadelig programvare ute i utgangspunktet.

Men det blir litt i overkant å si: "Å, alt er Microsofts feil."

Det er enda verre etter min mening, å si: «Ja, dette er genuin forskning; dette er veldig viktig; vi må minne folk på at dette kan skje.»

Vel, [A] vi vet det allerede, tusen takk, fordi mange mennesker har gjort dette før; vi fikk beskjeden høyt og tydelig.

Og [B] dette *er ikke* forskning.

Dette prøver bevisst å lure folk til å laste ned kode som gir en potensiell angriper fjernkontroll, i retur for muligheten til å skrive en rapport.

Det høres mer ut som en "stor fet unnskyldning" for meg enn en legitim motivator for forskning.

Og så min anbefaling er, hvis du tror dette *er* forskning, og hvis du er fast bestemt på å gjøre noe slikt om igjen, *ikke forvent mye sympati* hvis du blir tatt.

---

DOUG.  Greit – vi kommer tilbake til dette og leseren kommenterer på slutten av showet, så hold deg til.

Men først, la oss snakke om trafikklys, og hva de har med cybersikkerhet å gjøre.

---

AND.  Ahhh, ja! [LATTER]

Vel, det er en ting som heter TLP Trafikklysprotokoll.

Og TLP er det du kan kalle en "human cybersecurity research protocol" som hjelper deg med å merke dokumenter som du sender til andre mennesker, for å gi dem et hint om hva du håper de vil (og enda viktigere, hva du håper de vil * ikke*) gjøre med dataene.

Spesielt, hvor bredt skal de omfordele det?

Er dette noe så viktig at du kan erklære det for verden?

Eller er dette potensielt farlig, eller inkluderer det potensielt noen ting som vi ikke ønsker skal være offentlige ennå... så hold det for deg selv?

Og det startet med: TLP:RED, som betydde, "Hold det for deg selv"; TLP:AMBER, som betydde "Du kan sirkulere det i ditt eget selskap eller til kunder av deg som du tror kan ha behov for å vite dette"; TLP:GREEN, som betydde, "OK, du kan la dette sirkulere bredt innenfor nettsikkerhetssamfunnet."

Og TLP:WHITE, som betydde: "Du kan fortelle hvem som helst."

Veldig nyttig, veldig enkelt: RØD, RAV, GRØNN ... en metafor som fungerer globalt, uten å bekymre deg for hva som er forskjellen mellom "hemmelig" og "konfidensielt" og hva som er forskjellen mellom "konfidensielt" og "klassifisert", alt det kompliserte som trenger en hel masse lover rundt det.

Vel, TLP har nettopp fått noen modifikasjoner.

Så hvis du er interessert i cybersikkerhetsforskning, sørg for at du er klar over disse.

TLP:WHITE har blitt endret til det jeg anser som et mye bedre begrep faktisk, fordi hvit har alle disse unødvendige kulturelle overtonene som vi kan klare oss uten i moderne tid.

Så, TLP:WHITE har nettopp blitt TLP:CLEAR, som etter min mening er et mye bedre ord fordi det sier: "Du er klar til å bruke disse dataene," og den intensjonen er uttalt, ahem, veldig tydelig. (Beklager, jeg kunne ikke motstå ordspillet.)

Og det er et ekstra lag (så det har ødelagt metaforen litt – det er nå et *fem*-farget trafikklys!).

Det er et spesielt nivå som heter TLP:AMBER+STRICT, og hva det betyr er: "Du kan dele dette i bedriften din."

Så du kan bli invitert til et møte, kanskje du jobber for et cybersikkerhetsselskap, og det er helt klart at du må vise dette til programmerere, kanskje til IT-teamet ditt, kanskje til kvalitetssikringsfolkene dine, slik at du kan forske på problemet eller takle å fikse det.

Men TLP:AMBER+STRICT betyr at selv om du kan sirkulere det i organisasjonen din, *vær så snill og ikke fortell det til kundene dine eller kundene dine*, eller til og med personer utenfor selskapet som du tror kan ha behov for å vite.

Hold det innenfor det strammere fellesskapet til å begynne med.

TLP:AMBER, som før, betyr "OK, hvis du føler at du trenger å fortelle kundene dine, kan du det."

Og det kan være viktig, for noen ganger vil du kanskje informere kundene dine: «Hei, vi har løsningen på vei. Du må ta noen forholdsregler før løsningen kommer. Men fordi det er litt sensitivt, kan vi be om at du ikke forteller verden det ennå?»

Noen ganger spiller det mer i hendene på skurkene å fortelle verden for tidlig enn det spiller i hendene på forsvarerne.

Så hvis du svarer på nettsikkerhet, foreslår jeg at du går: https://www.first.org/tlp

---

DOUG.  Og du kan les mer om det på siden vår, nakedsecurity.sophos.com.

Og hvis du leter etter annen lett lesning, glem kvantekryptografi ... vi går videre til post-kvante kryptografi, Paul!

---

AND.  Ja, vi har snakket om dette noen ganger før på podcasten, har vi ikke?

Ideen med en kvantedatamaskin, forutsatt at en kraftig og pålitelig nok en kan bygges, er at visse typer algoritmer kan økes i forhold til den nyeste teknologien i dag, enten med kvadratroten … eller enda verre, *logaritme* av omfanget av problemet i dag.

Med andre ord, i stedet for å ta 2²⁵⁶ prøver å finne en fil med en bestemt hash, kan du kanskje gjøre det på bare (“bare”!) 2¹²⁸ prøver, som er kvadratroten.

Klart mye raskere.

Men det er en hel klasse med problemer som involverer faktorisering av produkter av primtall som teorien sier kan være knekt i *logaritmen* av tiden som de tar i dag, løst sett.

Så i stedet for å ta, si, 2¹²⁸ dager å sprekke [LANGT LENGER ENN UNIVERSETS NÅVÆRENDE ALDER], kan det ta bare 128 dager å sprekke.

Eller du kan erstatte "dager" med "minutter", eller hva som helst.

Og dessverre, den logaritmiske tidsalgoritmen (kalt Shors kvantefaktoriseringsalgoritme)… som i teorien kan brukes på noen av dagens kryptografiske teknikker, spesielt de som brukes til offentlig nøkkelkryptering.

Og bare i tilfelle disse kvantedatabehandlingsenhetene blir gjennomførbare i løpet av de neste årene, bør vi kanskje begynne å forberede oss nå for krypteringsalgoritmer som ikke er sårbare for disse to spesielle angrepsklassene?

Spesielt logaritmen, fordi den fremskynder potensielle angrep så mye at kryptografiske nøkler som vi for øyeblikket tenker, "Vel, ingen vil noen gang finne ut av det," kan bli avslørbare på et senere tidspunkt.

Uansett, NIST, den Nasjonalt institutt for standarder og teknologi i USA, har i flere år kjørt en konkurranse for å prøve å standardisere noen offentlige, upatenterte, godt granskede algoritmer som vil være motstandsdyktige mot disse magiske kvantedatamaskinene, hvis de noen gang dukker opp.

Og nylig valgte de fire algoritmer som de er klare til å standardisere etter nå.

De har kule navn, Doug, så jeg må lese dem opp: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONog SPHINCS+. [LATTER]

Så de har kule navn, om ikke annet.

Men samtidig tenkte NIST: «Vel, det er bare fire algoritmer. Det vi skal gjøre er at vi velger fire til som potensielle sekundærkandidater, og vi får se om noen av disse også bør gå gjennom.»

Så det er fire standardiserte algoritmer nå, og fire algoritmer som kan bli standardiserte i fremtiden.

Eller det *var* fire den 5. juli 2022, og en av dem var det SIKE, kort for supersingular isogeny key innkapsling.

(Vi trenger flere podcaster for å forklare supersingulære isogener, så vi vil ikke bry oss. [LATER])

Men dessverre, denne, som hang der inne med en kjempesjanse for å bli standardisert, ser det ut som om den har blitt uopprettelig ødelagt, til tross for at minst fem år har vært åpen for offentlig gransking allerede.

Så heldigvis, like før det ble eller kunne bli standardisert, fant to belgiske kryptografer ut: «Vet du hva? Vi tror vi har en vei rundt dette ved å bruke beregninger som tar omtrent en time, på en ganske gjennomsnittlig CPU, med bare én kjerne.»

---

DOUG.  Jeg antar at det er bedre å finne ut av det nå enn etter å ha standardisert det og fått det ut i naturen?

---

AND.  Faktisk!

Jeg antar at hvis det hadde vært en av algoritmene som allerede er blitt standardisert, måtte de oppheve standarden og komme opp med en ny?

Det virker rart at dette ikke ble lagt merke til på fem år.

Men jeg antar at det er hele ideen med offentlig gransking: du vet aldri når noen kanskje bare treffer på sprekken som trengs, eller den lille kilen som de kan bruke for å bryte seg inn og bevise at algoritmen ikke er så sterk som man opprinnelig trodde.

En god påminnelse om at hvis du *noen gang* har tenkt på å strikke din egen kryptografi...

---

DOUG.  [LAUGGER] Det har jeg ikke!

---

AND.  ..til tross for at vi har fortalt deg på Naked Security-podcasten N ganger, "Ikke gjør det!"

Dette bør være den ultimate påminnelsen om at selv når ekte eksperter legger ut en algoritme som er gjenstand for offentlig gransking i en global konkurranse i fem år, gir dette fortsatt ikke nødvendigvis nok tid til å avsløre feil som viser seg å være ganske dårlige.

Så det ser absolutt ikke bra ut for dette SIKE algoritme.

Og hvem vet, kanskje den blir trukket tilbake?

---

DOUG.  Det skal vi holde øye med.

Og mens solen sakte går ned på showet vårt for denne uken, er det på tide å høre fra en av våre lesere om GitHub-historien vi diskuterte tidligere.

Rane skriver:

"Det er litt kritt og ost i kommentarene, og jeg hater å si det, men jeg kan virkelig se begge sider av argumentet. Er det farlig, plagsomt, tidssløsende og ressurskrevende? Ja, selvfølgelig er det det. Er det hva kriminelt tenkende typer ville gjort? Ja, ja, det er det. Er det en påminnelse til alle som bruker GitHub, eller et hvilket som helst annet kodelagersystem for den saks skyld, om at trygg reise på internett krever en sunn grad av kynisme og paranoia? Ja. Som sysadmin ønsker en del av meg å applaudere eksponeringen av risikoen for hånden. Som systemadministrator for en haug med utviklere, må jeg nå sørge for at alle nylig har søkt etter tvilsomme oppføringer."

---

AND.  Ja, takk, RobB, for den kommentaren, for jeg antar at det er viktig å se begge sider av argumentet.

Det var kommentatorer som bare sa: «Hva pokker er problemet med dette? Dette er flott!"

En person sa, "Nei, faktisk er denne pennetestingen god og nyttig. Vær glad disse blir avslørt nå i stedet for å reise det stygge hodet fra en faktisk angriper.»

Og mitt svar på det er at "Vel, dette *er* et angrep, faktisk."

Det er bare det at noen nå har kommet ut etterpå og sagt «Å, nei, nei. Ingen skade gjort! Ærlig talt, jeg var ikke slem.»

Jeg tror ikke du er forpliktet til å kjøpe den unnskyldningen!

Men uansett, dette er ikke penetrasjonstesting.

Mitt svar var å si, veldig enkelt: "Ansvarlige penetrasjonstestere handler kun [A] etter å ha mottatt eksplisitt tillatelse, og [B] innenfor atferdsgrenser som er eksplisitt avtalt på forhånd."

Du lager ikke bare dine egne regler, og vi har diskutert dette før.

Så, som en annen kommentator sa, som er, tror jeg, min favorittkommentar... sa Ecurb, «Jeg synes noen burde gå fra hus til hus og knuse vinduer for å vise hvor ineffektive dørlåser egentlig er. Dette er forfalt. Noen hoppe på dette, vær så snill."

Og så, i tilfelle du ikke skjønte at det var satire, folkens, sier han, "Ikke!"

---

AND.  Jeg får ideen om at det er en god påminnelse, og jeg får ideen om at hvis du er en GitHub-bruker, både som produsent og forbruker, er det ting du kan gjøre.

Vi viser dem i kommentarene og i artikkelen.

Sett for eksempel en digital signatur på alle forpliktelsene dine, så det er åpenbart at endringene kom fra deg, og det er en slags sporbarhet.

Og ikke bare blindt konsumere ting fordi du gjorde et søk og det "så ut som" det kan være det rette prosjektet.

Ja, vi kan alle lære av dette, men teller dette faktisk som å lære oss, eller er det bare noe vi bør lære uansett?

Jeg tror dette *ikke* er undervisning.

Det er bare *ikke av høy nok standard* til å regne som forskning.

---

DOUG.  Flott diskusjon rundt denne artikkelen, og takk for at du sendte den inn, Rob.

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 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å, til neste gang, om å...

---

BÅDE.  Hold deg trygg!

[MUSIKK MODEM]