S3 Ep95: Slack läcka, Github-angrepp och post-kvantkrypto [Ljud + Text]

Klicka och dra på ljudvågorna nedan för att hoppa till valfri punkt. Du kan också lyssna direkt på Soundcloud.

DOUG.  Slaka läckor, stygg GitHub-kod och postkvantkryptering.

Allt det, och mycket mer, på podden Naked Security.

[MUSIKALT MODEM]

Välkommen till podden, alla.

Jag är Doug Aamoth.

Med mig är som alltid Paul Ducklin.

Paul, hur mår du idag?

---

ANKA.  Superduper, som vanligt, Doug!

---

DOUG.  Jag är superduper exalterad över att komma till denna veckas Teknisk historia segment, eftersom...

…du var där, man!

Denna vecka, den 11 augusti...

---

ANKA.  Å nej!

Jag tror att slanten bara har tappats...

---

DOUG.  Jag behöver inte ens säga årtalet!

11 augusti 2003 – världen lade märke till Blaster-masken, som påverkar Windows 2000- och Windows XP-system.

Blaster, även känd som Lovesan och MsBlast, utnyttjade ett buffertspill och är kanske mest känd för meddelandet, "Billy Gates, varför gör du det här möjligt? Sluta tjäna pengar och fixa din programvara."

Vad hände, Paul?

---

ANKA.  Tja, det var eran innan, kanske, vi tog säkerheten på så stort allvar.

Och lyckligtvis skulle den typen av bugg vara mycket, mycket svårare att utnyttja nuförtiden: det var ett stackbaserat buffertspill.

Och om jag minns rätt så byggdes serverversionerna av Windows redan med vad som kallas stackskydd.

Med andra ord, om du svämmar över stacken inuti en funktion, kommer den, innan funktionen återvänder och gör skadan med den skadade stacken, att upptäcka att något dåligt har hänt.

Så det måste stänga av det felande programmet, men skadlig programvara kan inte köras.

Men det skyddet fanns inte i klientversionerna av Windows vid den tiden.

Och som jag minns var det en av dessa tidiga skadliga program som var tvungna att gissa vilken version av operativsystemet du hade.

Är du på 2000? Är du på NT? Är du på XP?

Och om det blev fel, skulle en viktig del av systemet krascha, och du skulle få varningen "Ditt system är på väg att stängas av".

---

DOUG.  Ha, jag kommer ihåg de!

---

ANKA.  Så, det var den där sidoskadan som för många människor var tecknet på att du blev slagen av infektioner ...

…som kan vara utifrån, som om du bara var en hemanvändare och du inte hade en router eller brandvägg hemma.

Men om du var inne i ett företag, skulle den mest sannolika attacken komma från någon annan inom företaget, som spydde ut paket på ditt nätverk.

Så, väldigt likt CodeRed-attacken vi pratade om, som var ett par år innan dess, i en nyligen publicerad podcast, var det verkligen omfattningen, volymen och hastigheten på den här saken som var problemet.

---

DOUG.  Okej, det var ungefär 20 år sedan.

Och om vi vrider tillbaka klockan till fem år sedan, det är då Slack började läcka hashade lösenord. [SKRATT]

---

ANKA.  Ja, Slack, det populära samarbetsverktyget...

…den har en funktion där du kan skicka en inbjudningslänk till andra personer att gå med i din arbetsyta.

Och du föreställer dig: du klickar på en knapp som säger "Generera en länk", och det kommer att skapa något slags nätverkspaket som förmodligen har någon JSON inuti.

Om du någonsin har haft en Zoom-mötesinbjudan kommer du att veta att den har ett datum och en tid, och personen som bjuder in dig och en URL som du kan använda för mötet, och ett lösenord och allt det där saker – den har ganska mycket data där.

Normalt gräver du inte i rådata för att se vad som finns där – kunden säger bara: "Hej, här är ett möte, här är detaljerna. Vill du acceptera / kanske / avböja?”

Det visade sig att när du gjorde det här med Slack, som du säger, i mer än fem år, förpackat i den inbjudan var ovidkommande data som inte var strikt relevanta för själva inbjudan.

Så, inte en URL, inte ett namn, inte ett datum, inte en tid...

…men den *inbjudande användarens lösenord hash* [SKRATT]

---

DOUG.  Hmmmmmm.

---

ANKA.  Jag skämtar inte!

---

DOUG.  Det låter illa...

---

ANKA.  Ja, det gör det verkligen, eller hur?

De dåliga nyheterna är, hur i hela friden hamnade det där?

Och när den väl var där inne, hur i hela friden undvek den varsel i fem år och tre månader?

Faktum är att om du besöker artikeln om Naked Security och tittar på fullständig URL av artikeln kommer du att märka att det står i slutet, blahblahblah-for-three-months.

För när jag först läste rapporten ville jag inte se det som 2017! [SKRATT]

Det var 17 april till 17 juli, så det fanns massor av "17" där inne.

Och mitt sinne tömde 2017 som startår – jag misstolkade det som "april till juli *i år*" [2022].

Jag tänkte: "Wow, *tre månader* och de märkte det inte."

Och sedan var den första kommentaren till artikeln, "Ahem [HOSTA]. Det var faktiskt den 17 april *2017*.”

Wow!

Men någon kom på det den 17 juli [2022] och Slack fixade det samma dag.

Som, "Åh, golly, vad tänkte vi på?!"

Så det är de dåliga nyheterna.

Den goda nyheten är att det åtminstone var *hashade* lösenord.

Och de var inte bara hashade, de var *saltade*, vilket är där du blandar in unikt utvalda, slumpmässiga data per användare med lösenordet.

Tanken med detta är tvåfaldig.

Ett, om två personer väljer samma lösenord får de inte samma hash, så du kan inte dra några slutsatser genom att titta igenom hashdatabasen.

Och två, du kan inte förberäkna en ordbok med kända hash för kända ingångar, eftersom du måste skapa en separat ordlista för varje lösenord *för varje salt*.

Så det är ingen trivial övning att knäcka hashade lösenord.

Med det sagt är hela idén att de inte är tänkta att vara ett offentligt register.

De hashas och saltas *ifall* de läcker, inte *för att de kan* läcka.

Så, ägg i Slacks ansikte!

Slack säger att ungefär en av 200 användare, eller 0.5 %, drabbades.

Men om du är en Slack-användare skulle jag anta att om de inte insåg att de läckte hashade lösenord i fem år, kanske de inte heller räknade upp listan över personer som drabbats helt.

Så, gå och ändra ditt lösenord ändå... du kan också.

---

DOUG.  OK, vi säger också: om du inte använder en lösenordshanterare, överväg att skaffa en; och slå på 2FA om du kan.

---

ANKA.  Jag trodde att du skulle gilla det, Doug.

---

DOUG.  Ja det gör jag!

Och sedan, om du är Slack eller företag som det, välj en ansedd salt-hash-and-stretch-algoritm när du själv hanterar lösenord.

---

ANKA.  Ja.

Det stora i Slacks svar, och det som jag tyckte saknades, är att de bara sa: "Oroa dig inte, inte bara hashade vi lösenorden, vi saltade dem också."

Mitt råd är att om du hamnar i ett sådant här intrång bör du vara villig att deklarera algoritmen eller processen du använde för saltning och hash, och även helst vad som kallas sträckning, vilket är där du inte bara hash det saltade lösenordet en gång, utan kanske du hash det 100,000 XNUMX gånger för att bromsa någon form av ordbok eller brute force attack.

Och om du anger vilken algoritm du använder och med vilka parametrar.. t.ex. PBKDF2, bcrypt, scrypt, Argon2 – det är de mest kända lösenordsalgoritmerna för "salt-hash-stretch" där ute.

Om du faktiskt anger vilken algoritm du använder, då: [A] du är mer öppen, och [B] du ger potentiella offer för problemet en chans att själva bedöma hur farligt de tror att detta kan ha varit .

Och den typen av öppenhet kan faktiskt hjälpa mycket.

Slack gjorde inte det.

De sa bara, "Åh, de var saltade och hasade."

Men vad vi inte vet är, lade de i två byte salt och hashade dem sedan en gång med SHA-1...

…eller hade de något lite mer motståndskraftigt mot att bli sprickor?

---

DOUG.  Håller vi oss till ämnet dåliga saker, vi märker en trend som utvecklas där människor befinner sig injicera dåliga saker i GitHub, bara för att se vad som händer, exponerar risker...

…vi har ytterligare en av de där berättelserna.

---

ANKA.  Ja, någon som nu påstås ha kommit ut på Twitter och sagt: "Oroa dig inte killar, ingen skada skedd. Det var bara för forskning. Jag ska skriva en rapport, sticka ut från Blue Alert.”

De skapade bokstavligen tusentals falska GitHub-projekt, baserade på att kopiera befintlig legitim kod, medvetet infoga några malware-kommandon där, som "ringa hem för ytterligare instruktioner" och "tolka svaret som bakdörrskod att köra", och så vidare.

Så saker som verkligen kan göra skada om du installerade ett av dessa paket.

Ge dem legitima namn...

... lånar tydligen historiken för ett genuint projekt så att saken såg mycket mer legitim ut än du annars skulle kunna förvänta dig om den bara dök upp med "Hej, ladda ner den här filen. Du vet att du vill!"

Verkligen?! Forskning?? Vi visste inte detta redan?!!?

Nu kan du argumentera, "Tja, Microsoft, som äger GitHub, vad gör de som gör det så enkelt för människor att ladda upp den här typen av saker?"

Och det ligger en viss sanning i det.

Kanske kunde de göra ett bättre jobb med att hålla skadlig programvara ute i första hand.

Men det blir lite överdrivet att säga, "Åh, allt är Microsofts fel."

Det är ännu värre enligt min mening, att säga: ”Ja, det här är genuin forskning; detta är verkligen viktigt; vi måste påminna folk om att detta kan hända.”

Tja, [A] vi vet redan det, tack så mycket, för massor av människor har gjort det här förut; vi fick meddelandet högt och tydligt.

Och [B] detta *är inte* forskning.

Detta försöker medvetet lura folk att ladda ner kod som ger en potentiell angripare fjärrkontroll, i utbyte mot möjligheten att skriva en rapport.

Det låter mer som en "stor fet ursäkt" för mig än en legitim motivation för forskning.

Och så min rekommendation är, om du tror att det här *är* forskning, och om du är fast besluten att göra något sånt här igen, *förvänta dig inte en massa sympati* om du åker fast.

---

DOUG.  Okej – vi återkommer till detta och läsarna kommenterar i slutet av showen, så håll dig kvar.

Men låt oss först prata om trafikljus, och vad de har med cybersäkerhet att göra.

---

ANKA.  Ahhh, ja! [SKRATT]

Tja, det finns en sak som heter TLP Trafikljusprotokoll.

Och TLP är vad du kan kalla ett "human cybersecurity research protocol" som hjälper dig att märka dokument som du skickar till andra människor, för att ge dem en fingervisning om vad du hoppas att de ska göra (och, ännu viktigare, vad du hoppas att de ska göra * inte*) göra med datan.

I synnerhet, hur brett ska de omfördela det?

Är detta något så viktigt att du kan förklara det för världen?

Eller är det här potentiellt farligt, eller innehåller det eventuellt vissa saker som vi inte vill ska vara offentliga än... så håll det för dig själv?

Och det började med: TLP:RED, vilket betydde, "Håll det för dig själv"; TLP:AMBER, vilket innebar "Du kan cirkulera det inom ditt eget företag eller till dina kunder som du tror kan behöva veta detta akut"; TLP:GREEN, vilket betydde, "OK, du kan låta detta cirkulera brett inom cybersäkerhetsgemenskapen."

Och TLP:WHITE, vilket betydde "Du kan berätta för vem som helst."

Mycket användbart, mycket enkelt: RÖTT, BRANN, GRÖNT... en metafor som fungerar globalt, utan att oroa dig för vad som är skillnaden mellan "hemlig" och "konfidentiell" och vad som är skillnaden mellan "konfidentiell" och "hemligstämplad", allt det där komplicerade som behöver en hel del lagar runt det.

Nåväl, TLP har precis fått några ändringar.

Så om du är intresserad av cybersäkerhetsforskning, se till att du är medveten om dem.

TLP:WHITE har ändrats till vad jag anser vara en mycket bättre term faktiskt, eftersom vit har alla dessa onödiga kulturella övertoner som vi kan klara oss utan i modern tid.

Så, TLP:WHITE har precis blivit TLP:CLEAR, vilket enligt mig är ett mycket bättre ord eftersom det säger "Du är tydlig med att använda den här informationen", och den avsikten anges, ahem, mycket tydligt. (Tyvärr, jag kunde inte motstå ordleken.)

Och det finns ett extra lager (så det har förstört metaforen lite – det är nu ett *fem*-färgat trafikljus!).

Det finns en speciell nivå som heter TLP:AMBER+STRICT, och vad det betyder är "Du kan dela detta inom ditt företag."

Så du kanske blir inbjuden till ett möte, kanske arbetar du för ett cybersäkerhetsföretag, och det är helt klart att du kommer att behöva visa detta för programmerare, kanske för ditt IT-team, kanske för dina kvalitetssäkringspersonal, så att du kan forska om problemet eller ta itu med att åtgärda det.

Men TLP:AMBER+STRICT betyder att även om du kan cirkulera det inom din organisation, *berätta inte för dina kunder eller dina kunder*, eller ens personer utanför företaget som du tror kan behöva känna till.

Håll det inom det stramare samhället till att börja med.

TLP:AMBER, som tidigare, betyder "OK, om du känner att du behöver berätta för dina kunder så kan du."

Och det kan vara viktigt, för ibland kanske du vill informera dina kunder: "Hej, vi har åtgärden på väg. Du måste vidta några försiktighetsåtgärder innan korrigeringen kommer. Men eftersom det är lite känsligt, får vi be att du inte berättar för världen ännu?”

Ibland spelar det faktiskt mer i händerna på skurkarna att säga till världen för tidigt än det spelar i händerna på försvararna.

Så, om du är en cybersäkerhetssvarare, föreslår jag att du går: https://www.first.org/tlp

---

DOUG.  Och du kan läs mer om det på vår webbplats, nakedsecurity.sophos.com.

Och om du letar efter någon annan lätt läsning, glöm kvantkryptografi ... vi går vidare till post-kvantkryptografi, Paul!

---

ANKA.  Ja, vi har pratat om detta några gånger tidigare i podden, eller hur?

Tanken med en kvantdator, förutsatt att en tillräckligt kraftfull och tillförlitlig sådan skulle kunna byggas, är att vissa typer av algoritmer skulle kunna påskyndas över den senaste tekniken idag, antingen till tonerna av kvadratroten... eller ännu värre, *logaritm* av problemets omfattning idag.

Med andra ord istället för att ta 2²⁵⁶ försöker hitta en fil med en viss hash, kanske du kan göra det på bara (“bara”!) 2¹²⁸ försöker, vilket är kvadratroten.

Helt klart mycket snabbare.

Men det finns en hel klass av problem som involverar faktorisering av produkter av primtal som teorin säger skulle kunna knäckas i *logaritmen* för den tid som de tar idag, löst sett.

Så istället för att ta, säg, 2¹²⁸ dagar att spricka [LÅNGT LÄNGRE ÄN UNIVERSUMS NUVARANDE ÅLDER], kan det ta bara 128 dagar att spricka.

Eller så kan du ersätta "dagar" med "minuter" eller vad som helst.

Och tyvärr, den logaritmiska tidsalgoritmen (kallad Shor's Quantum Factorization Algorithm)... som i teorin skulle kunna tillämpas på några av dagens kryptografiska tekniker, särskilt de som används för kryptografi med publik nyckel.

Och ifall dessa kvantberäkningsenheter skulle bli möjliga inom de närmaste åren, kanske vi borde börja förbereda oss nu för krypteringsalgoritmer som inte är sårbara för dessa två speciella attackklasser?

Särskilt den logaritmiska, eftersom den påskyndar potentiella attacker så mycket att kryptografiska nycklar som vi för närvarande tror, ​​"Nå, ingen kommer någonsin att ta reda på det," kan bli avslöjade i något senare skede.

Hur som helst, NIST, den National Institute of Standards and Technology i USA, har under flera år genomfört en tävling för att försöka standardisera några offentliga, opatenterade, väl granskade algoritmer som kommer att vara resistenta mot dessa magiska kvantdatorer, om de någonsin dyker upp.

Och nyligen valde de fyra algoritmer som de är beredda att standardisera efter nu.

De har coola namn, Doug, så jag måste läsa upp dem: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONoch SPHINCS+. [SKRATT]

Så de har coola namn, om inte annat.

Men samtidigt tänkte NIST: "Tja, det är bara fyra algoritmer. Vad vi kommer att göra är att vi väljer fyra till som potentiella sekundärkandidater, och vi får se om någon av dem också ska gå igenom."

Så det finns fyra standardiserade algoritmer nu och fyra algoritmer som kan bli standardiserade i framtiden.

Eller det *var* fyra den 5 juli 2022, och en av dem var det SIKE, Förkortning av supersingular isogenyckelinkapsling.

(Vi behöver flera podcasts för att förklara supersingularisogener, så vi kommer inte att bry oss. [SKRATT])

Men tyvärr, den här, som hängde där med en kampchans att bli standardiserad, det ser ut som om den har gått sönder på ett oåterkalleligt sätt, trots minst fem år av att ha varit öppen för offentlig granskning redan.

Så, lyckligtvis, precis innan det blev eller kunde bli standardiserat, kom två belgiska kryptografer på: "Vet du vad? Vi tror att vi har en väg runt detta med beräkningar som tar ungefär en timme, på en ganska genomsnittlig CPU, med bara en kärna.”

---

DOUG.  Jag antar att det är bättre att ta reda på det nu än efter att ha standardiserat det och fått ut det i naturen?

---

ANKA.  Verkligen!

Jag antar att om det hade varit en av algoritmerna som redan blivit standardiserade, skulle de behöva upphäva standarden och komma med en ny?

Det verkar konstigt att detta inte uppmärksammades på fem år.

Men jag antar att det är hela idén med offentlig granskning: man vet aldrig när någon bara slår på sprickan som behövs, eller den lilla kilen som de kan använda för att bryta sig in och bevisa att algoritmen inte är så stark som man ursprungligen trodde.

En bra påminnelse om att om du *någonsin* tänkt på att sticka din egen kryptografi...

---

DOUG.  [SKratt] Det har jag inte!

---

ANKA.  ..trots att vi har sagt till dig i podcasten Naked Security N gånger, "Gör inte det!"

Detta borde vara den ultimata påminnelsen om att även när sanna experter lägger ut en algoritm som är föremål för offentlig granskning i en global tävling i fem år, ger detta fortfarande inte nödvändigtvis tillräckligt med tid för att avslöja brister som visar sig vara ganska dåliga.

Så det ser verkligen inte bra ut för det här SIKE algoritm.

Och vem vet, den kanske dras tillbaka?

---

DOUG.  Vi kommer att hålla ett öga på det.

Och när solen sakta går ner på vår show för den här veckan är det dags att höra från en av våra läsare om GitHub-historien som vi diskuterade tidigare.

Rob skriver:

"Det finns lite krita och ost i kommentarerna, och jag hatar att säga det, men jag kan verkligen se båda sidor av argumentet. Är det farligt, besvärligt, tidsödande och resurskrävande? Ja, självklart är det det. Är det vad kriminellt sinnade typer skulle göra? Ja ja det är det. Är det en påminnelse till alla som använder GitHub, eller något annat kodförrådssystem för den delen, att det kräver en sund grad av cynism och paranoia att säkert resa på internet? Ja. Som sysadmin vill en del av mig applådera exponeringen av risken. Som systemadministratör för ett gäng utvecklare måste jag nu se till att alla nyligen har letat efter tveksamma inlägg.”

---

ANKA.  Ja, tack, RobB, för den kommentaren, för jag antar att det är viktigt att se båda sidor av argumentet.

Det fanns kommentatorer som bara sa: "Vad fan är problemet med det här? Det här är bra!"

En person sa, "Nej, faktiskt, det här penntestet är bra och användbart. Var glad att dessa avslöjas nu istället för att höja sitt fula huvud från en verklig angripare.”

Och mitt svar på det är att "Ja, det här *är* faktiskt en attack."

Det är bara det att någon nu har kommit ut efteråt och sagt "Åh, nej, nej. Ingen skada skedd! Ärligt talat, jag var inte stygg."

Jag tror inte att du är skyldig att köpa den ursäkten!

Men hur som helst, detta är inte penetrationstestning.

Mitt svar var att säga, mycket enkelt: "Ansvarsfulla penetrationstestare agerar endast [A] efter att ha fått uttryckligt tillstånd och [B] inom beteendegränser som uttryckligen överenskommits i förväg."

Man gör inte bara upp sina egna regler, och vi har diskuterat detta tidigare.

Så, som en annan kommentator sa, vilket jag tror är min favoritkommentar... sa Ecurb, "Jag tycker att någon borde gå från hus till hus och krossa fönster för att visa hur ineffektiva dörrlås verkligen är. Detta är förfallit. Någon hoppa på det här, snälla."

Och sedan, ifall ni inte insåg att det var satir, folkens, säger han, "Inte!"

---

ANKA.  Jag får tanken att det är en bra påminnelse, och jag får tanken att om du är en GitHub-användare, både som producent och konsument, så finns det saker du kan göra.

Vi listar dem i kommentarerna och i artikeln.

Sätt till exempel en digital signatur på alla dina commits så att det är uppenbart att ändringarna kom från dig, och det finns någon form av spårbarhet.

Och konsumera inte bara saker blint för att du gjorde en sökning och det "såg ut som" att det kan vara rätt projekt.

Ja, vi kan alla lära oss av detta, men räknas det här faktiskt som att lära oss, eller är det bara något vi borde lära oss ändå?

Jag tror att det här *inte* är undervisning.

Det är bara *inte av tillräckligt hög standard* för att räknas som forskning.

---

DOUG.  Bra diskussion kring den här artikeln, och tack för att du skickade in det, Rob.

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 tips@sophos.com; du kan kommentera någon av våra artiklar; eller så kan du träffa 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 är Doug Aamoth som påminner dig, tills nästa gång, att...

---

BÅDE.  Håll dig säker!

[MUSIKALT MODEM]