S3 Ep95: Slack Leak, napad na Github in postkvantni kripto [zvok + besedilo]

Kliknite in povlecite spodnje zvočne valove, da preskočite na katero koli točko. Lahko tudi poslušaj neposredno na Soundcloudu.

DOUG.  Puščanje podatkov, poredna koda GitHub in postkvantna kriptografija.

Vse to in še veliko več v podcastu Naked Security.

[GLASBENI MODEM]

Dobrodošli v podcastu, vsi.

Jaz sem Doug Aamoth.

Z mano je, kot vedno, Paul Ducklin.

Paul, kako si danes?

---

RACA.  Super-duper, kot ponavadi, Doug!

---

DOUG.  Zelo sem navdušena, da pridem na ta teden tehnična zgodovina segment, ker…

… bil si tam, človek!

Ta teden, 11. avgusta…

---

RACA.  O ne!

Mislim, da je peni pravkar padel ...

---

DOUG.  Sploh mi ni treba reči letnice!

11. avgust 2003 – svet je opazil črva Blaster, ki je prizadel sisteme Windows 2000 in Windows XP.

Blaster, znan tudi kot Lovesan in MsBlast, je izkoristil prekoračitev medpomnilnika in je morda najbolj znan po sporočilu, »Billy Gates, zakaj to omogočaš? Nehaj služiti denar in popravi svojo programsko opremo.«

Kaj se je zgodilo, Paul?

---

RACA.  No, morda je bilo prej, ko smo varnost jemali tako resno.

In na srečo bi bilo takšno napako v teh dneh veliko, veliko težje izkoristiti: šlo je za prelivanje medpomnilnika na podlagi sklada.

In če se prav spomnim, so se strežniške različice sistema Windows že gradile s tem, kar se imenuje zaščita sklada.

Z drugimi besedami, če prepolnite sklad znotraj funkcije, potem preden se funkcija vrne in naredi škodo s poškodovanim skladom, bo zaznala, da se je zgodilo nekaj slabega.

Torej mora zapreti program, ki povzroča napake, vendar se zlonamerna programska oprema ne zažene.

Toda te zaščite takrat ni bilo v odjemalskih različicah sistema Windows.

In kolikor se spomnim, je bila to ena tistih zgodnjih zlonamernih programov, ki so morali uganiti, katero različico operacijskega sistema imate.

Ste na 2000? Ste na NT? Ali imaš XP?

In če bi se zmotil, bi se pomemben del sistema zrušil in prejeli bi opozorilo »Vaš sistem se bo kmalu zaustavil«.

---

DOUG.  Ha, teh se spomnim!

---

RACA.  Torej je nastala stranska škoda, ki je bila za mnoge ljudi znak, da vas pestijo okužbe ...

... kar je lahko od zunaj, na primer, če bi bili le domači uporabnik in doma ne bi imeli usmerjevalnika ali požarnega zidu.

Če pa ste bili znotraj podjetja, bi najverjetneje napad izpeljal nekdo drug znotraj podjetja, ki bi v vaše omrežje pošiljal pakete.

Torej, zelo podobno napadu CodeRed, o katerem smo govorili nekaj let pred tem, v nedavnem podcastu, je bil v resnici problem sam obseg, obseg in hitrost te stvari.

---

DOUG.  V redu, no, to je bilo pred približno 20 leti.

In če zavrtimo uro nazaj pet let nazaj, takrat Slack je začel puščati zgoščena gesla. [SMEH]

---

RACA.  Da, Slack, priljubljeno orodje za sodelovanje ...

… ima funkcijo, s katero lahko drugim ljudem pošljete povezavo s povabilom, da se pridružijo vašemu delovnemu prostoru.

In predstavljate si: kliknete gumb z napisom »Ustvari povezavo« in ustvari se nekakšen omrežni paket, ki verjetno vsebuje nekaj JSON.

Če ste kdaj prejeli povabilo na sestanek Zoom, boste vedeli, da ima datum in uro, osebo, ki vas vabi, in URL, ki ga lahko uporabite za sestanek, in geslo, in vse to stvari – notri ima precej podatkov.

Običajno se ne poglobite v neobdelane podatke, da bi videli, kaj je tam – stranka samo reče: »Hej, tukaj je sestanek, tukaj so podrobnosti. Ali želite sprejeti / morda / zavrniti?«

Izkazalo se je, da ko ste to počeli s Slackom, kot pravite, več kot pet let, so bili v tem povabilu zapakirani tuji podatki, ki niso strogo pomembni za samo povabilo.

Torej, ne URL, ne ime, ne datum, ne čas ...

...ampak *geslo vabljivega uporabnika* [SMEH]

---

DOUG.  Hmmmmm.

---

RACA.  Otrok te ne!

---

DOUG.  To se slabo sliši ...

---

RACA.  Ja, res je, kajne?

Slaba novica je, kako za vraga je to prišlo noter?

In ko je bil tam notri, kako za vraga se je pet let in tri mesece izogibal pozornosti?

Pravzaprav, če obiščete članek o goli varnosti in pogledate polni URL članka, boste opazili, da na koncu piše, blahblahblah-for-three-months.

Ker, ko sem prvič prebral poročilo, ga nisem hotel videti kot leto 2017! [SMEH]

Bilo je od 17. aprila do 17. julija, zato je bilo notri veliko "17".

In moje misli so izpraznile leto 2017 kot začetno leto – napačno sem ga prebrala kot »od aprila do julija *tega leta*« [2022].

Pomislil sem: "Vau, *trije meseci* in niso opazili."

In potem je bil prvi komentar na članek, »Ahem [KAŠELJ]. Pravzaprav je bil 17. april *2017*.«

Wow!

Toda nekdo je to ugotovil 17. julija [2022] in Slack je, po njihovi zaslugi, to popravil še isti dan.

Na primer, "Oh, hudiča, kaj smo mislili?!"

To je torej slaba novica.

Dobra novica je, da so bila vsaj *zgoščena* gesla.

In niso bili le zgoščeni, ampak so bili *zasoljeni*, kjer z geslom pomešate edinstveno izbrane naključne podatke za vsakega uporabnika.

Ideja tega je dvojna.

Prvič, če dve osebi izbereta isto geslo, ne dobita iste zgoščene vrednosti, tako da ne morete narediti nobenih sklepov s pregledovanjem baze podatkov o zgoščeni vrednosti.

In drugič, ne morete vnaprej izračunati slovarja znanih zgoščenih vrednosti za znane vnose, ker morate ustvariti ločen slovar za vsako geslo *za vsako sol*.

Razbijanje zgoščenih gesel torej ni nepomembna naloga.

Glede na to je celotna ideja ta, da ne bi smeli biti javna evidenca.

Zdrobljene in nasoljene so *v primeru* puščanja, ne pa zato, da lahko* puščajo.

Torej, jajce na Slackov obraz!

Slack pravi, da je bil prizadet približno eden od 200 uporabnikov ali 0.5 %.

Toda če ste uporabnik Slacka, predvidevam, da če se pet let niso zavedali, da razkrivajo zgoščena gesla, morda tudi niso popolnoma našteli seznama prizadetih ljudi.

Torej, vseeno pojdite in spremenite svoje geslo ... morda tudi vi.

---

DOUG.  V redu, pravimo tudi: če ne uporabljate upravitelja gesel, ga razmislite o nakupu; in vklopi 2FA, če lahko.

---

RACA.  Mislil sem, da ti bo to všeč, Doug.

---

DOUG.  Da, razumem!

In potem, če ste Slack ali podjetje, ki mu je všeč, izberite a ugleden algoritem za razprševanje in raztezanje ko sami ravnate z gesli.

---

RACA.  Da.

Velika stvar v Slackovem odgovoru in stvar, za katero sem mislil, da manjka, je, da so samo rekli: "Ne skrbite, ne samo, da smo zgostili gesla, ampak smo jih tudi zasolili."

Moj nasvet je, da če ste ujeti pri takšni kršitvi, morate biti pripravljeni prijaviti algoritem ali postopek, ki ste ga uporabili za soljenje in zgoščevanje, in v idealnem primeru tudi tisto, kar se imenuje raztezanje, kjer zaoljenega gesla ne zgostite samo enkrat, ampak ga morda zgostite 100,000-krat, da upočasnite kakršne koli napade s slovarjem ali surovo silo.

In če navedete, kateri algoritem uporabljate in s kakšnimi parametri... npr. PBKDF2, bcrypt, scrypt, Argon2 – to so najbolj znani algoritmi za »raztegovanje soli« za gesla.

Če dejansko navedete, kateri algoritem uporabljate, potem: [A] ste bolj odprti in [B] potencialnim žrtvam težave dajete možnost, da same ocenijo, kako nevarno bi bilo po njihovem mnenju to .

In takšna odprtost lahko dejansko veliko pomaga.

Slack tega ni naredil.

Rekli so samo: "Oh, bili so nasoljeni in zdrobljeni."

Ne vemo pa, ali so dali dva bajta soli in ju nato enkrat zgostili s SHA-1 ...

…ali pa so imeli kaj malo bolj odpornega proti pokanju?

---

DOUG.  Če se držimo teme slabih stvari, opažamo, da se razvija trend, v katerem so ljudje vnašanje slabih stvari v GitHub, samo da vidim, kaj se zgodi, izpostavljanje tveganju ...

… imamo še eno od teh zgodb.

---

RACA.  Da, nekdo, ki se je zdaj domnevno oglasil na Twitterju in rekel: »Ne skrbite, fantje, nič škode. Bilo je samo za raziskavo. Napisal bom poročilo in izstopal iz Modrega alarma.”

Ustvarili so dobesedno na tisoče lažnih projektov GitHub, ki so temeljili na kopiranju obstoječe zakonite kode, vanjo so namerno vstavili nekatere ukaze zlonamerne programske opreme, kot je »pokliči domov za nadaljnja navodila« in »telo odgovora interpretirajo kot stransko kodo za izvedbo« ter tako naprej

Torej, stvari, ki bi resnično lahko škodovale, če bi namestili enega od teh paketov.

Dati jim zakonita imena ...

... očitno izposoja zgodovine objav pristnega projekta, tako da je bila stvar videti veliko bolj zakonita, kot bi sicer pričakovali, če bi se prikazala le z: »Hej, prenesi to datoteko. Veš, da si želiš!”

res?! Raziskovanje?? Tega še nismo vedeli?!!?

Zdaj lahko trdite: "No, Microsoft, ki ima v lasti GitHub, kaj dela, da ljudem tako olajša nalaganje tovrstnih stvari?"

In v tem je nekaj resnice.

Morda bi lahko naredili boljše delo pri preprečevanju zlonamerne programske opreme.

Vendar je malo pretirano reči: "Oh, vsega je kriv Microsoft."

Po mojem mnenju je še huje reči: »Da, to je pristna raziskava; to je res pomembno; ljudi moramo opomniti, da se to lahko zgodi.«

No, [A] to že vemo, najlepša hvala, ker je že ogromno ljudi to storilo; dobili smo jasno in glasno sporočilo.

In [B] to *ni* raziskava.

To namerno poskuša pretentati ljudi, da prenesejo kodo, ki potencialnemu napadalcu omogoča daljinski nadzor, v zameno za možnost pisanja poročila.

To mi zveni bolj kot "velik debel izgovor" kot legitimen motivator za raziskovanje.

In moje priporočilo je, da če mislite, da je to *raziskava*, in če ste odločeni, da boste nekaj takega ponovili znova, *ne pričakujte veliko sočutja*, če vas ujamejo.

---

DOUG.  V redu – k temu in bralčevim komentarjem se bomo vrnili na koncu oddaje, tako da vztrajajte.

Toda najprej se pogovorimo o semafor, in kaj imajo s kibernetsko varnostjo.

---

RACA.  Ahhh, ja! [SMEH]

No, obstaja nekaj, kar se imenuje TLP, Protokol semaforja.

In TLP je tisto, čemur bi lahko rekli "protokol raziskav človeške kibernetske varnosti", ki vam pomaga označiti dokumente, ki jih pošljete drugim ljudem, da jim da namig o tem, za kaj upate, da bodo (in, kar je še pomembneje, za kaj upate, da bodo * ne*) s podatki.

Zlasti, kako široko naj bi ga prerazporedili?

Je to nekaj tako pomembnega, da bi lahko o tem razglasili svetu?

Ali pa je to potencialno nevarno ali pa potencialno vključuje nekaj stvari, za katere še ne želimo, da so javne ... zato to zadržite zase?

In začelo se je z: TLP:RED, kar je pomenilo: »Zadrži zase«; TLP:AMBER, kar je pomenilo »Lahko ga razpošljete znotraj svojega podjetja ali svojim strankam, za katere mislite, da bi to nujno morale vedeti«; TLP:GREEN, kar je pomenilo: "V redu, lahko pustite, da to široko kroži v skupnosti kibernetske varnosti."

in TLP:WHITE, kar je pomenilo: "Lahko poveš komurkoli."

Zelo uporabno, zelo preprosto: RDEČA, JANTARNA, ZELENA ... metafora, ki deluje globalno, ne da bi vas skrbelo, kakšna je razlika med "tajno" in "zaupno" in kakšna je razlika med "zaupno" in "zaupno", vse tiste zapletene stvari, ki okoli tega potrebuje veliko zakonov.

No, TLP je pravkar dobil nekaj sprememb.

Torej, če se ukvarjate z raziskavami kibernetske varnosti, se prepričajte, da se jih zavedate.

TLP:WHITE je bil spremenjen v izraz, ki se mi zdi dejansko veliko boljši, ker bele ima vse te nepotrebne kulturne prizvoke, brez katerih lahko v moderni dobi.

Torej, TLP:WHITE je pravkar postal TLP:CLEAR, kar je po mojem mnenju veliko boljša beseda, ker pravi: "Jasno je, da lahko uporabite te podatke," in ta namen je izražen, hm, zelo jasno. (Oprostite, nisem se mogel upreti besedni igri.)

Tu je še dodatna plast (zato je nekoliko pokvarila metaforo – zdaj je *pet*barvni semafor!).

Obstaja posebna stopnja, imenovana TLP:AMBER+STRICT, in to pomeni: "To lahko delite v svojem podjetju."

Torej ste morda povabljeni na sestanek, morda delate za podjetje za kibernetsko varnost in povsem jasno je, da boste morali to pokazati programerjem, morda vaši IT ekipi, morda vašim ljudem za zagotavljanje kakovosti, da boste lahko raziskali težavo ali se ukvarjajte z njeno odpravo.

Ampak TLP:AMBER+STRICT pomeni, da čeprav ga lahko razširjate znotraj svoje organizacije, *prosimo, ne povejte svojim strankam ali strankam* ali celo ljudem zunaj podjetja, za katere menite, da bi jih morali vedeti.

Za začetek naj bo znotraj ožje skupnosti.

TLP:AMBER, tako kot prej, pomeni: "V redu, če menite, da morate povedati svojim strankam, lahko."

In to je lahko pomembno, saj boste včasih morda želeli obvestiti svoje stranke: »Hej, prihaja popravek. Preden pride popravek, boste morali sprejeti nekaj previdnostnih ukrepov. Toda ker je nekako občutljivo, vas lahko prosimo, da še ne poveste svetu?«

Včasih prezgodaj povedati svetu dejansko bolj koristi prevarantom kot pa obrambnim strankam.

Torej, če ste odgovoren za kibernetsko varnost, predlagam, da greste: https://www.first.org/tlp

---

DOUG.  In lahko preberi več o tem na naši spletni strani, nakedsecurity.sophos.com.

In če iščete kakšno drugo lahkotno branje, pozabite na kvantno kriptografijo ... gremo naprej postkvantna kriptografija, Paul!

---

RACA.  Da, o tem smo že nekajkrat govorili v podcastu, kajne?

Zamisel o kvantnem računalniku, ob predpostavki, da bi ga lahko zgradili dovolj zmogljivega in zanesljivega, je, da bi lahko nekatere vrste algoritmov pospešili v primerjavi z današnjim stanjem tehnike, bodisi na kvadratni koren … ali še huje, *logaritem* obsega današnjega problema.

Z drugimi besedami, namesto da bi vzeli 2²⁵⁶ poskuša najti datoteko z določeno zgoščeno vrednostjo, boste to morda lahko storili v samo (»le«!) 2¹²⁸ poskusi, kar je kvadratni koren.

Očitno veliko hitreje.

Obstaja pa cel razred problemov, ki vključujejo faktoriziranje produktov praštevil, za katere teorija pravi, da bi jih lahko razdelali v *logaritem* časa, ki je potreben danes, ohlapno rečeno.

Torej, namesto da vzamete, recimo, 2¹²⁸ dni za razbijanje [VELIKO DALJ OD TRENUTNE STAROSTI VESOLJA], lahko traja le 128 dni, da razbije.

Lahko pa zamenjate »dneve« z »minute« ali kar koli drugega.

In na žalost ta logaritemski časovni algoritem (imenovan Shorov algoritem kvantne faktorizacije)… ki bi se teoretično lahko uporabil za nekatere današnje kriptografske tehnike, predvsem tiste, ki se uporabljajo za kriptografijo z javnimi ključi.

In samo v primeru, da te kvantne računalniške naprave postanejo izvedljive v naslednjih nekaj letih, bi se morda morali zdaj začeti pripravljati na algoritme šifriranja, ki niso ranljivi za ta dva posebna razreda napadov?

Še posebej logaritemskega, ker tako močno pospeši morebitne napade, da lahko kriptografski ključi, za katere trenutno mislimo: »No, tega ne bo nikoli nihče ugotovil,« postanejo razkriti v neki kasnejši fazi.

Kakorkoli, NIST, Nacionalni inštitut za standarde in tehnologijo v ZDA že več let izvaja tekmovanje za poskus standardizacije nekaterih javnih, nepatentiranih, dobro pregledanih algoritmov, ki bodo odporni na te čarobne kvantne računalnike, če se sploh kdaj pojavijo.

In pred kratkim so izbrali štiri algoritme, ki so jih pripravljeni standardizirati zdaj.

Imajo kul imena, Doug, zato jih moram prebrati: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONin SPHINCS+. [SMEH]

Torej imajo kul imena, če nič drugega.

Toda hkrati je NIST ugotovil: »No, to so samo štirje algoritmi. Naredili bomo to, da bomo izbrali še štiri kot potencialne sekundarne kandidate in videli bomo, ali bo kateri od teh tudi šel skozi.«

Tako zdaj obstajajo štirje standardizirani algoritmi in štirje algoritmi, ki bodo morda standardizirani v prihodnosti.

Ali pa so 5. julija 2022 *bili* štirje in eden od njih je bil SIKE, kratek za supersingularna inkapsulacija izogenskega ključa.

(Za razlago supersingularnih izogenij bomo potrebovali več podcastov, zato se ne bomo trudili. [SMEH])

Toda na žalost je videti, da je ta, ki je visel tam z bojnimi možnostmi za standardizacijo, nepopravljivo pokvarjen, čeprav je bil že vsaj pet let odprt za javni nadzor.

Tako sta na srečo dva belgijska kriptografa, tik preden je bil ali bi lahko bil standardiziran, ugotovila: »Veš kaj? Mislimo, da smo se temu izognili z izračuni, ki trajajo približno eno uro, na dokaj povprečnem procesorju z uporabo samo enega jedra.«

---

DOUG.  Predvidevam, da je bolje, da to ugotovimo zdaj, kot potem, ko smo to standardizirali in dali v naravo?

---

RACA.  Prav zares!

Predvidevam, da če bi bil eden od algoritmov, ki so že standardizirani, bi morali standard razveljaviti in pripraviti novega?

Zdi se čudno, da tega pet let niso opazili.

Ampak mislim, da je to celotna zamisel javnega nadzora: nikoli ne veš, kdaj lahko nekdo le zadene potrebno razpoko ali majhen klin, s katerim lahko vdre in dokaže, da algoritem ni tako močan, kot se je sprva mislilo.

Dober opomnik, da če ste *kdaj* razmišljali o pletenju lastne kriptografije ...

---

DOUG.  [SMEH] Nisem!

---

RACA.  ..kljub temu, da smo vam v podcastu Naked Security N-krat rekli: "Ne počni tega!"

To bi moral biti zadnji opomin, da tudi ko pravi strokovnjaki objavijo algoritem, ki je pet let predmet javnega nadzora v globalni konkurenci, to še vedno ne zagotavlja dovolj časa za razkritje napak, ki se izkažejo za precej slabe.

Torej, zagotovo ne izgleda dobro za to SIKE algoritem.

In kdo ve, morda bo umaknjen?

---

DOUG.  Na to bomo pazili.

In ko sonce počasi zahaja za našo oddajo za ta teden, je čas, da slišimo enega od naših bralcev o zgodbi GitHub, o kateri smo razpravljali prej.

Rob piše:

»V komentarjih je nekaj krede in sira in ne želim to reči, a resnično vidim obe strani argumenta. Ali je nevarno, težavno, zapravlja čas in vire? Ja, seveda je. Ali bi to storili kriminalno usmerjeni tipi? Da, da, res je. Ali je to opomnik za vsakogar, ki uporablja GitHub ali kateri koli drug sistem skladišča kod, da varno potovanje po internetu zahteva zdravo mero cinizma in paranoje? ja Del mene kot sistemskega skrbnika želi pozdraviti izpostavljenost tveganju. Kot sistemski skrbnik skupine razvijalcev se moram zdaj prepričati, ali so vsi pred kratkim preiskali vleke za vprašljive vnose.«

---

RACA.  Da, hvala, RobB, za ta komentar, ker mislim, da je pomembno videti obe strani argumenta.

Bili so komentatorji, ki so samo govorili: »Kaj za vraga je s tem problem? To je odlično!"

Ena oseba je rekla, »Ne, pravzaprav je to testiranje peresa dobro in koristno. Bodite veseli, da so zdaj razkriti, namesto da dvignejo svojo grdo glavo pred dejanskim napadalcem.«

In moj odgovor na to je: "No, to je pravzaprav napad."

Samo, da je nekdo zdaj prišel ven in rekel: "Oh, ne, ne. Ni narejene škode! Iskreno povedano, nisem bil poreden.”

Mislim, da nisi dolžan sprejeti tega izgovora!

Kakorkoli že, to ni penetracijski test.

Moj odgovor je bil zelo preprost: "Odgovorni preizkuševalci penetracije ukrepajo šele [A] po prejemu izrecnega dovoljenja in [B] v okviru vedenjskih omejitev, ki so izrecno dogovorjene vnaprej."

Pravil si ne izmislite kar sami in o tem smo že razpravljali.

Torej, kot je rekel drug komentator, kar je po mojem mnenju moj najljubši komentar ... je rekel Ecurb, »Mislim, da bi moral nekdo hoditi od hiše do hiše in razbijati okna, da bi pokazal, kako neučinkovite so v resnici ključavnice. To je zapadlo. Naj nekdo skoči na to, prosim.”

In potem, samo če niste ugotovili, da je to satira, ljudje, pravi, "Ne!"

---

RACA.  Dobim idejo, da je to dober opomnik, in dobim idejo, da če ste uporabnik GitHub, tako kot proizvajalec kot potrošnik, obstajajo stvari, ki jih lahko naredite.

Navajamo jih v komentarjih in v članku.

Na primer, dajte digitalni podpis na vse vaše objave, tako da bo očitno, da ste spremembe prišli od vas, in obstaja nekakšna sledljivost.

In ne samo slepo uživajte stvari, ker ste izvedli iskanje in "izgledalo je, da" bi lahko bil pravi projekt.

Da, vsi se lahko naučimo iz tega, toda ali se to dejansko šteje kot učenje ali je to le nekaj, kar bi se vseeno morali naučiti?

Mislim, da to *ni* poučevanje.

Samo *ni dovolj visokega standarda*, da bi ga šteli kot raziskavo.

---

DOUG.  Odlična razprava o tem članku in hvala, da si ga poslal, Rob.

Če imate zanimivo zgodbo, komentar ali vprašanje, ki bi ga radi poslali, ga bomo z veseljem prebrali v podcastu.

Lahko pošljete e-pošto tips@sophos.com; komentirate lahko katerega koli od naših člankov; lahko pa nas kontaktirate na socialnem omrežju: @NakedSecurity.

To je naša današnja oddaja – najlepša hvala za poslušanje.

Za Paula Ducklina, jaz sem Doug Aamoth in vas do naslednjič opominjam, da…

---

OBOJE.  Bodite varni!

[GLASBENI MODEM]