S3 Ep95: Slap lækage, Github-angreb og post-kvantekrypto [lyd + tekst]

Klik og træk på lydbølgerne nedenfor for at springe til ethvert punkt. Du kan også lytte direkte på Soundcloud.

DOUG.  Slaske lækager, fræk GitHub-kode og post-kvantekryptering.

Alt det og meget mere på Naked Security-podcasten.

[MUSIK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug Aamoth.

Med mig er som altid Paul Ducklin.

Paul, hvordan har du det i dag?

---

AND.  Super-duper, som sædvanlig, Doug!

---

DOUG.  Jeg er super-duper spændt på at komme til denne uges Teknisk historie segment, fordi...

…du var der, mand!

I denne uge, den 11. august...

---

AND.  Åh nej!

Jeg tror, ​​at kronen lige er faldet...

---

DOUG.  Jeg behøver ikke engang sige årstal!

11. august 2003 – verden lagde mærke til Blaster-ormen, der påvirker Windows 2000- og Windows XP-systemerne.

Blaster, også kendt som Lovesan og MsBlast, udnyttede et bufferoverløb og er måske bedst kendt for beskeden, "Billy Gates, hvorfor gør du det muligt? Stop med at tjene penge og ret din software."

Hvad skete der, Paul?

---

AND.  Nå, det var måske æraen før, vi tog sikkerhed ret så alvorligt.

Og heldigvis ville den slags fejl være meget, meget sværere at udnytte i disse dage: det var et stakbaseret bufferoverløb.

Og hvis jeg husker rigtigt, blev serverversionerne af Windows allerede bygget med det, der hedder stak beskyttelse.

Med andre ord, hvis du flyder over stakken inde i en funktion, så vil den, før funktionen vender tilbage og gør skaden med den beskadigede stak, opdage, at der er sket noget slemt.

Så det er nødt til at lukke det stødende program ned, men malwaren kommer ikke til at køre.

Men den beskyttelse var ikke i klientversionerne af Windows på det tidspunkt.

Og som jeg husker, var det en af ​​de tidlige malwares, der skulle gætte, hvilken version af operativsystemet du havde.

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

Og hvis det gik galt, ville en vigtig del af systemet gå ned, og du ville få advarslen "Dit system er ved at lukke ned".

---

DOUG.  Ha, dem kan jeg huske!

---

AND.  Så der var den sideskade, der for mange mennesker var tegn på, at du blev ramt af infektioner...

…som kunne være udefra, som hvis du bare var en hjemmebruger, og du ikke havde en router eller firewall derhjemme.

Men hvis du var inde i en virksomhed, ville det mest sandsynlige angreb komme fra en anden inde i virksomheden, der spyede pakker på dit netværk.

Så meget ligesom CodeRed-angrebet, vi talte om, som var et par år før det, i en nylig podcast, var det virkelig omfanget, volumen og hastigheden af ​​denne ting, der var problemet.

---

DOUG.  Okay, det var omkring 20 år siden.

Og hvis vi skruer tiden tilbage til fem år siden, er det når Slack begyndte at lække hashed adgangskoder. [LATTER]

---

AND.  Ja, Slack, det populære samarbejdsværktøj...

…det har en funktion, hvor du kan sende et invitationslink til andre personer til at deltage i dit arbejdsområde.

Og du forestiller dig: du klikker på en knap, der siger "Generer et link", og det vil skabe en slags netværkspakke, der sandsynligvis har noget JSON i sig.

Hvis du nogensinde har haft en Zoom-mødeinvitation, vil du vide, at den har en dato og et klokkeslæt, og den person, der inviterer dig, og en URL, du kan bruge til mødet, og en adgangskode og alt det der ting - den har ret mange data derinde.

Normalt graver du ikke i de rå data for at se, hvad der er derinde – klienten siger bare: "Hej, her er et møde, her er detaljerne. Vil du acceptere/måske/afvise?”

Det viste sig, at når du gjorde dette med Slack, som du siger, i mere end fem år, pakket ind i den invitation, var der uvedkommende data, der ikke var strengt relevante for selve invitationen.

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

…men den *inviterende brugers adgangskode hash* [LATER]

---

DOUG.  Hmmmmmm.

---

AND.  Jeg dræber dig ikke!

---

DOUG.  Det lyder dårligt...

---

AND.  Ja, det gør det virkelig, ikke?

Den dårlige nyhed er, hvordan i alverden kom det derind?

Og når den først var derinde, hvordan i alverden undgik den varsel i fem år og tre måneder?

Faktisk, hvis du besøger artiklen om Naked Security og ser på fuld URL af artiklen, vil du bemærke, at der står i slutningen, blahblahblah-for-three-months.

For da jeg læste rapporten første gang, ville mit sind ikke se det som 2017! [LATTER]

Det var 17. april til 17. juli, og så der var masser af "17" derinde.

Og mit sind slettede 2017 som startår – jeg misforstod det som "april til juli *i år*" [2022].

Jeg tænkte: "Wow, *tre måneder* og de lagde ikke mærke til det."

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

Wow!

Men nogen fandt ud af det den 17. juli [2022], og Slack, til deres ære, rettede det samme dag.

Ligesom, "Åh, golly, hvad tænkte vi på?!"

Så det er den dårlige nyhed.

Den gode nyhed er, at det i det mindste var *hashed* adgangskoder.

Og de var ikke bare hash, de blev *saltet*, hvilket er hvor du blander unikt udvalgte, tilfældige data pr. bruger med adgangskoden.

Tanken om dette er todelt.

Én, hvis to personer vælger den samme adgangskode, får de ikke den samme hash, så du kan ikke foretage nogen slutninger ved at kigge gennem hash-databasen.

Og for det andet, du kan ikke forudberegne en ordbog med kendte hashes for kendte input, fordi du skal oprette en separat ordbog for hver adgangskode *for hvert salt*.

Så det er ikke en triviel øvelse at knække hashed adgangskoder.

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

De hash og saltet *i tilfælde af* de lækker, ikke *for at de kan* lække.

Så æg på Slacks ansigt!

Slack siger, at omkring én ud af 200 brugere, eller 0.5 %, var berørt.

Men hvis du er Slack-bruger, vil jeg antage, at hvis de ikke var klar over, at de lækkede hash-kodeord i fem år, havde de måske heller ikke helt opregnet listen over berørte personer.

Så gå og skift din adgangskode alligevel... du kan lige så godt.

---

DOUG.  OK, vi siger også: Hvis du ikke bruger en adgangskodemanager, så overvej at få en; og tænd for 2FA, hvis du kan.

---

AND.  Det troede jeg, du kunne lide, Doug.

---

DOUG.  Ja jeg gør!

Og så, hvis du er Slack eller firma som det, skal du vælge en velrenommeret salt-hash-og-stræk-algoritme når du selv håndterer adgangskoder.

---

AND.  Ja.

Den store ting i Slacks svar, og det, jeg troede manglede, er, at de bare sagde: "Bare rolig, ikke kun hasherede vi adgangskoderne, vi saltede dem også."

Mit råd er, at hvis du bliver fanget i et brud som dette, så skal du være villig til at erklære den algoritme eller proces, du brugte til saltning og hash, og også ideelt set, hvad der hedder strækker, hvilket er hvor du ikke bare hash det saltede kodeord én gang, men måske hash det 100,000 gange for at bremse enhver form for ordbog eller brute force angreb.

Og hvis du angiver hvilken algoritme du bruger og med hvilke parametre.. f.eks. PBKDF2, bcrypt, scrypt, Argon2 - det er de bedst kendte adgangskode "salt-hash-stretch"-algoritmer derude.

Hvis du rent faktisk angiver, hvilken algoritme du bruger, så: [A] du er mere åben, og [B] du giver potentielle ofre for problemet en chance for selv at vurdere, hvor farligt de tror, ​​det kunne have været .

Og den slags åbenhed kan faktisk hjælpe meget.

Det gjorde Slack ikke.

De sagde bare, "Åh, de blev saltet og hash."

Men hvad vi ikke ved er, har de lagt to bytes salt i og derefter hash dem én gang med SHA-1...

…eller havde de noget, der var lidt mere modstandsdygtigt over for at blive revnet?

---

DOUG.  Holder vi os til emnet dårlige ting, bemærker vi en tendens, der udvikler sig, hvor folk er injicerer dårlige ting i GitHub, bare for at se, hvad der sker, udsætter risiko...

…vi har endnu en af ​​de historier.

---

AND.  Ja, nogen, der nu angiveligt er kommet ud på Twitter og sagde: "Bare rolig gutter, ingen skade sket. Det var kun til forskning. Jeg vil skrive en rapport, skille mig ud fra Blue Alert.”

De skabte bogstaveligt talt tusindvis af falske GitHub-projekter, baseret på kopiering af eksisterende lovlig kode, bevidst indsættelse af nogle malware-kommandoer derinde, såsom "ring hjem for yderligere instruktioner", og "fortolke selve svaret som bagdørskode, der skal udføres", og snart.

Så ting, der virkelig kunne gøre skade, hvis du installerede en af ​​disse pakker.

Giver dem lovlige navne...

…låner tilsyneladende commit-historien for et ægte projekt, så tingen så meget mere legitim ud, end du ellers kunne forvente, hvis den bare dukkede op med: "Hej, download denne fil. Du ved, du vil!"

Virkelig?! Forskning?? Det vidste vi ikke allerede?!!?

Nu kan du argumentere, "Nå, Microsoft, hvem ejer GitHub, hvad gør de, der gør det så nemt for folk at uploade denne slags ting?"

Og der er noget sandhed i det.

Måske kunne de gøre et bedre stykke arbejde med at holde malware ude i første omgang.

Men det bliver en smule overdrevet at sige, "Åh, det er alt sammen Microsofts skyld."

Det er endnu værre efter min mening, at sige: ”Ja, det er ægte forskning; dette er virkelig vigtigt; vi er nødt til at minde folk om, at dette kunne ske."

Nå, [A] vi ved det allerede, mange tak, fordi masser af mennesker har gjort dette før; vi fik beskeden højt og tydeligt.

Og [B] dette *er ikke* forskning.

Dette forsøger bevidst at narre folk til at downloade kode, der giver en potentiel angriber fjernbetjening, til gengæld for evnen til at skrive en rapport.

Det lyder mere som en "stor fed undskyldning" for mig end en legitim motivator for forskning.

Og så min anbefaling er, hvis du tror, ​​at dette *er* forskning, og hvis du er fast besluttet på at gøre noget som dette igen, *forvent ikke en hel masse sympati*, hvis du bliver fanget.

---

DOUG.  Okay – vi vender tilbage til dette og læserens kommentarer i slutningen af ​​showet, så bliv ved.

Men først, lad os tale om trafiklys, og hvad de har med cybersikkerhed at gøre.

---

AND.  Ahhh, ja! [GRINE]

Nå, der er en ting, der hedder TLP Trafiklys protokol.

Og TLP er, hvad du kan kalde en "human cybersecurity research-protokol", der hjælper dig med at mærke dokumenter, som du sender til andre mennesker, for at give dem et hint om, hvad du håber, de vil (og endnu vigtigere, hvad du håber, de vil * ikke*) gøre med dataene.

Især, hvor bredt skal de omfordele det?

Er dette noget så vigtigt, at du kunne erklære det for verden?

Eller er dette potentielt farligt, eller indeholder det potentielt nogle ting, som vi ikke ønsker skal være offentlige endnu... så hold det for dig selv?

Og det startede med: TLP:RED, hvilket betød: "Hold det for dig selv"; TLP:AMBER, hvilket betød "Du kan cirkulere det inde i din egen virksomhed eller til dine kunder, som du tror, ​​der kunne være akut behov for at vide dette"; TLP:GREEN, hvilket betød, "OK, du kan lade dette cirkulere bredt inden for cybersikkerhedssamfundet."

og TLP:WHITE, hvilket betød: "Du kan fortælle det til enhver."

Meget nyttigt, meget simpelt: RØD, RAV, GRØN... en metafor, der fungerer globalt, uden at bekymre sig om, hvad der er forskellen mellem "hemmeligt" og "fortroligt", og hvad der er forskellen mellem "fortroligt" og "klassificeret", alt det komplicerede, der har brug for en hel masse love omkring det.

Nå, TLP har lige fået nogle ændringer.

Så hvis du er til cybersikkerhedsforskning, skal du sørge for at være opmærksom på dem.

TLP:WHITE er blevet ændret til, hvad jeg betragter som et meget bedre udtryk faktisk, fordi hvid har alle disse unødvendige kulturelle overtoner, som vi kan undvære i den moderne tid.

Så, TLP:WHITE er lige blevet TLP:CLEAR, hvilket efter min mening er et meget bedre ord, fordi det siger, "Du er klar til at bruge disse data," og den hensigt er angivet, ahem, meget tydeligt. (Beklager, jeg kunne ikke modstå ordspillet.)

Og der er et ekstra lag (så det har spoleret metaforen lidt – det er nu et *fem*-farvet trafiklys!).

Der hedder et særligt niveau TLP:AMBER+STRICT, og hvad det betyder er: "Du kan dele dette inde i din virksomhed."

Så du bliver måske inviteret til et møde, måske arbejder du for en cybersikkerhedsvirksomhed, og det er helt klart, at du bliver nødt til at vise dette til programmører, måske til dit it-team, måske til dine kvalitetssikringsfolk, så du kan lave research i problemet eller beskæftige sig med at løse det.

Men TLP:AMBER+STRICT betyder, at selvom du kan cirkulere det inden for din organisation, *vær venlig ikke at fortælle det til dine kunder eller dine kunder*, eller endda folk uden for virksomheden, som du mener kunne have behov for at vide.

Hold det i det strammere samfund til at begynde med.

TLP:AMBER, ligesom før, betyder, "OK, hvis du føler, du har brug for at fortælle dine kunder, kan du det."

Og det kan være vigtigt, for nogle gange vil du måske gerne informere dine kunder: "Hej, vi har løsningen på vej. Du skal tage nogle forholdsregler, før rettelsen kommer. Men fordi det er lidt følsomt, må vi så bede dig om ikke at fortælle verden det endnu?”

Nogle gange spiller det faktisk mere i hænderne på skurkene at fortælle verden for tidligt, end det spiller i hænderne på forsvarerne.

Så hvis du er en cybersikkerhedsresponder, foreslår jeg, at du går: https://www.first.org/tlp

---

DOUG.  Og du kan læs mere om det på vores side, nakedsecurity.sophos.com.

Og hvis du leder efter noget andet let læsning, så glem kvantekryptografi... vi går videre til post-kvante kryptografi, Paul!

---

AND.  Ja, vi har talt om det et par gange før på podcasten, ikke?

Ideen med en kvantecomputer, forudsat at en kraftig og pålidelig nok kunne bygges, er, at visse typer af algoritmer kunne fremskyndes i forhold til den nyeste teknologi i dag, enten til tonerne af kvadratroden … eller endnu værre, *logaritme* af problemets omfang i dag.

Med andre ord, i stedet for at tage 2²⁵⁶ forsøger at finde en fil med en bestemt hash, kan du muligvis gøre det på bare (“bare”!) 2¹²⁸ forsøger, som er kvadratroden.

Klart meget hurtigere.

Men der er en hel klasse af problemer, der involverer faktorisering af produkter af primtal, som teorien siger, kunne være knækket i *logaritmen* af den tid, som de tager i dag, løst sagt.

Så i stedet for at tage f.eks. 2¹²⁸ dage at knække [LANGT LÆNGERE END UNIVERSETS NUVÆRENDE ALDER], kan det tage blot 128 dage at knække.

Eller du kan erstatte "dage" med "minutter", eller hvad som helst.

Og desværre er den logaritmiske tidsalgoritme (kaldet Shor's Quantum Factorization Algorithm)… det kunne i teorien anvendes på nogle af nutidens kryptografiske teknikker, især dem der bruges til offentlig nøglekryptering.

Og bare hvis disse kvantecomputerenheder bliver gennemførlige i løbet af de næste par år, burde vi måske begynde at forberede nu til krypteringsalgoritmer, der ikke er sårbare over for disse to særlige angrebsklasser?

Især logaritmen, fordi den fremskynder potentielle angreb så meget, at kryptografiske nøgler, som vi i øjeblikket tænker, "Nå, ingen vil nogensinde finde ud af det," kan blive afsløret på et senere tidspunkt.

Anyway, NIST, den National Institute of Standards and Technology i USA, har i flere år kørt en konkurrence for at prøve at standardisere nogle offentlige, ikke-patenterede, gennemsøgte algoritmer, der vil være modstandsdygtige over for disse magiske kvantecomputere, hvis de nogensinde dukker op.

Og for nylig valgte de fire algoritmer, som de er parate til at standardisere efter nu.

De har fede navne, Doug, så jeg er nødt til at læse dem op: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONog SPHINCS+. [LATTER]

Så de har fede navne, om ikke andet.

Men på samme tid regnede NIST med: "Nå, det er kun fire algoritmer. Det, vi vil gøre, er, at vi vælger fire mere som potentielle sekundære kandidater, og vi vil se, om nogen af ​​dem også skal gå igennem."

Så der er fire standardiserede algoritmer nu, og fire algoritmer, som måske bliver standardiseret i fremtiden.

Eller der *var* fire den 5. juli 2022, og en af ​​dem var SIKE, forkortelse for supersingular isogeni-nøgleindkapsling.

(Vi skal bruge adskillige podcasts for at forklare supersingular isogenier, så vi gider ikke. [LATER])

Men desværre, denne, der hang derinde med en kæmpe chance for at blive standardiseret, det ser ud til, at den er blevet uopretteligt ødelagt, på trods af at den i mindst fem år allerede har været åben for offentlig kontrol.

Så heldigvis, lige før det blev eller kunne blive standardiseret, fandt to belgiske kryptografer ud af: "Ved du hvad? Vi tror, ​​at vi har fundet en vej uden om dette ved at bruge beregninger, der tager omkring en time, på en forholdsvis gennemsnitlig CPU, med kun én kerne."

---

DOUG.  Det er vel bedre at finde ud af det nu end efter at have standardiseret det og fået det ud i naturen?

---

AND.  Ja!

Jeg gætter på, at hvis det havde været en af ​​de algoritmer, der allerede var blevet standardiseret, ville de være nødt til at ophæve standarden og komme med en ny?

Det virker mærkeligt, at dette ikke blev bemærket i fem år.

Men jeg gætter på, at det er hele ideen med offentlig granskning: man ved aldrig, hvornår nogen måske bare rammer den revne, der er nødvendig, eller den lille kile, som de kan bruge til at bryde ind og bevise, at algoritmen ikke er så stærk, som man oprindeligt troede.

En god påmindelse om, at hvis du * nogensinde* har tænkt på at strikke din egen kryptografi...

---

DOUG.  Det har jeg ikke!

---

AND.  ..på trods af, at vi har fortalt dig på Naked Security-podcasten N gange, "Gør det ikke!"

Dette burde være den ultimative påmindelse om, at selv når sande eksperter udgiver en algoritme, der er genstand for offentlig kontrol i en global konkurrence i fem år, giver dette stadig ikke nødvendigvis tid nok til at afsløre fejl, der viser sig at være ret dårlige.

Så det ser bestemt ikke godt ud til dette SIKE algoritme.

Og hvem ved, måske bliver den trukket tilbage?

---

DOUG.  Det vil vi holde øje med.

Og da solen langsomt går ned på vores show i denne uge, er det tid til at høre fra en af ​​vores læsere om GitHub-historien, vi diskuterede tidligere.

Røve skriver:

"Der er noget kridt og ost i kommentarerne, og jeg hader at sige det, men jeg kan virkelig se begge sider af argumentet. Er det farligt, besværligt, tidsspildende og ressourcekrævende? Ja, selvfølgelig er det det. Er det hvad kriminelt indstillede typer ville gøre? Ja, ja, det er det. Er det en påmindelse til enhver, der bruger GitHub, eller ethvert andet kodelagersystem for den sags skyld, om, at sikker rejse på internettet kræver en sund grad af kynisme og paranoia? Ja. Som sysadmin ønsker en del af mig at bifalde eksponeringen af ​​den aktuelle risiko. Som en sysadmin for en flok udviklere skal jeg nu sikre mig, at alle for nylig har gennemsøgt eventuelle træk for tvivlsomme poster."

---

AND.  Ja tak, RobB, for den kommentar, for det er vel vigtigt at se begge sider af argumentet.

Der var kommentatorer, der bare sagde: "Hvad pokker er problemet med det her? Dette er godt!"

En person sagde, "Nej, faktisk er denne pentest god og nyttig. Vær glad for, at de bliver afsløret nu i stedet for at rejse deres grimme hoved fra en egentlig angriber."

Og mit svar på det er, at "Jamen, dette *er* faktisk et angreb."

Det er bare, at nogen nu er kommet ud bagefter og har sagt "Åh, nej, nej. Ingen skade sket! Helt ærligt, jeg var ikke fræk.”

Jeg tror ikke, du er forpligtet til at købe den undskyldning!

Men i hvert fald er dette ikke penetrationstest.

Mit svar var at sige meget enkelt: "Ansvarlige penetrationstestere handler kun [A] efter at have modtaget eksplicit tilladelse og [B] inden for adfærdsmæssige grænser, der er eksplicit aftalt på forhånd."

Man laver ikke bare sine egne regler, og det har vi diskuteret før.

Så, som en anden kommentator sagde, hvilket jeg tror, ​​er min yndlingskommentar... sagde Ecurb, "Jeg synes, nogen burde gå fra hus til hus og smadre vinduer for at vise, hvor ineffektive dørlåse virkelig er. Dette er forfaldent. Nogen hoppe på det her, tak."

Og så, bare hvis du ikke var klar over, at det var satire, folkens, siger han, "Ikke!"

---

AND.  Jeg får den tanke, at det er en god påmindelse, og jeg får den idé, at hvis du er GitHub-bruger, både som producent og forbruger, er der ting, du kan gøre.

Vi lister dem i kommentarerne og i artiklen.

Sæt for eksempel en digital signatur på alle dine commits, så det er tydeligt, at ændringerne kom fra dig, og der er en form for sporbarhed.

Og du skal ikke bare blindt forbruge ting, fordi du søgte, og det "så ud til", at det kunne være det rigtige projekt.

Ja, vi kan alle lære af dette, men tæller dette faktisk som at lære os, eller er det bare noget, vi bør lære alligevel?

Jeg tror, ​​at dette *ikke* er undervisning.

Det er bare *ikke af en høj nok standard* til at tælle som forskning.

---

DOUG.  Fantastisk diskussion omkring denne artikel, og tak for at sende det ind, Rob.

Hvis du har en interessant historie, kommentar eller spørgsmål, du gerne vil indsende, vil vi meget gerne læse den på podcasten.

Du kan e-maile tips@sophos.com; du kan kommentere på enhver af vores artikler; eller du kan slå os på socialt: @NakedSecurity.

Det er vores show for i dag – mange tak fordi du lyttede.

For Paul Ducklin, jeg er Doug Aamoth, der minder dig om, indtil næste gang, at...

---

BEGGE.  Hold dig sikker!

[MUSIK MODEM]