S3 Ep105: WONTFIX! MS Office-krypteringsfilen som "inte är ett säkerhetsbrist" [Ljud + text]

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

DOUG.  Hisnande intrång, dekrypteringsbar kryptering och massor av patchar.

Allt det där mer på podcasten Naked Security.

[MUSIKALT MODEM]

Välkommen till podden, alla.

Jag är Doug Aamoth; han är Paul Ducklin.

Paul, hur mår du idag, sir?

---

ANKA.  Doug...jag vet, för du berättade för mig i förväg vad som kommer in Denna vecka i teknisk historia, och det är BRA!

---

DOUG.  OK!

Den här veckan, den 18 oktober 1958, parades ett oscilloskop och en dator byggd för att simulera vindmotstånd med anpassade aluminiumkontroller och spelet Tennis för två föddes.

Tennis for Two visades upp på en tredagarsutställning på Brookhaven National Laboratory och visade sig vara extremt populär, särskilt bland gymnasieelever.

Om du lyssnar på detta måste du gå till Wikipedia och slå upp "Tennis för två".

Det finns en video där för något som byggdes 1958...

…Jag tror att du håller med mig, Paul, det var ganska otroligt.

---

ANKA.  Jag skulle *älska* spela det idag!

Och, som Asteroids och Battle Zone, och de där speciellt ihågkomna spelen från 1980-talet...

…för att det är ett oscilloskop: vektorgrafik!

Ingen pixelering, inga skillnader beroende på om en linje är vid 90 grader, eller 30 grader eller 45 grader.

Och ljudåterkopplingen från reläerna i kontrollerna... det är fantastiskt!

Det är otroligt att detta var 1958.

Går tillbaka till en tidigare Denna vecka i teknisk historia, det var vid gränsen till transistorrevolutionen.

Tydligen var beräkningshalvan en blandning av termionventiler (vakuumrör) och reläer.

Och alla bildskärmskretsar var transistorbaserade, Doug

Så det var precis vid blandningen av all teknik: reläer, ventiler och transistorer, allt i ett banbrytande videospel.

---

DOUG.  Väldigt coolt.

Kolla in det på Wikipedia: Tennis för två.

Låt oss nu gå vidare till vår första berättelse.

Paul, jag vet att du är väldigt skicklig på att skriva en fantastisk dikt...

…Jag har skrivit en mycket kort dikt för att introducera den här första berättelsen, om du vill unna mig.

---

ANKA.  Så det blir två rader då, eller hur? [SKratt]

---

DOUG.  Det går lite så här.

Zooma för Mac/Få inte kapad.

[MYCKET LÅNG TYSTHET]

Slutdikt.

---

ANKA.  Åh, ledsen!

Jag trodde att det var titeln, och att du skulle göra dikten nu.

---

DOUG.  Så, det är dikten.

---

ANKA.  OK.

[UTAN KÄNSLA] Härligt, Doug.

---

DOUG.  [IRONISK] Tack.

---

ANKA.  Rimmen var spektakulär!

Men alla dikter behöver inte rimma...

---

DOUG.  Det är sant.

---

ANKA.  Vi kallar det bara fri vers, eller hur?

---

DOUG.  Ok tack.

---

ANKA.  Tyvärr var detta en gratis bakdörr till Zoom för Mac.

[KÄNNER SKYLDIG] Ursäkta, det var inte en särskilt bra uppgörelse, Doug.

[skrattar] Du trampar på någon annans gräsmatta, du kommer ofta till korta...

---

DOUG.  Nej, det är bra!

Jag provade dikter den här veckan; du provar segues.

Vi måste ta oss ur våra komfortzoner då och då.

---

ANKA.  Jag antar att detta var kod som var tänkt att kompileras ut när den slutliga konstruktionen var klar, men som av misstag lämnades in.

Det är bara för Zoom för Mac-versionen, och det har korrigerats, så se till att du är uppdaterad.

I grund och botten, under vissa omständigheter, när en videoström skulle starta eller kameran aktiverades av själva appen, skulle den oavsiktligt tro att du kanske vill felsöka programmet.

För, hej, du kanske var en utvecklare! [SKratt]

Det är uppenbarligen inte tänkt att hända i utgåvor.

Och det innebar att det fanns en TCP-felsökningsport kvar öppen på det lokala nätverksgränssnittet.

Det innebar att vem som helst som kunde skicka paket till den porten, vilket förmodligen kan vara vilken annan lokalt ansluten användare som helst, så det skulle inte behöva vara en administratör eller ens du... ens en gästanvändare, det skulle vara tillräckligt.

Så, en angripare som hade någon form av proxy skadlig kod på din dator som kunde ta emot paket utifrån och injicera dem i det lokala gränssnittet kunde i princip utfärda kommandon till programmets mage.

Och de typiska saker som felsökningsgränssnitt tillåter inkluderar: dumpa lite minne; extrahera hemligheter; ändra programmets beteende; justera konfigurationsinställningar utan att gå igenom det vanliga gränssnittet så att användaren inte kan se det; fånga allt ljud utan att berätta för någon, utan att poppa upp inspelningsvarningen; allt sånt.

Den goda nyheten är att Zoom hittade det själva, och de lappade det ganska snabbt.

Men det är en bra påminnelse om att som vi säger så ofta, [skrattar] "Det finns många smyg 'twixt bägaren och läppen."

---

DOUG.  Okej, mycket bra.

Låt oss stanna ombord på lapptåget och dra in på nästa station.

Och den här historien... kanske den mest intressanta delen av den här historien om den senaste Patch Tuesday var vad Microsoft *inte* inkluderade?

---

ANKA.  Tyvärr, patcharna som alla förmodligen förväntade sig – och vi spekulerade i en podcast nyligen, "Ja, det ser ut som om Microsoft kommer att få oss att vänta ytterligare en vecka till Patch Tuesday, och inte göra en "tidig release utanför bandet" ” är dessa två Exchange noll-dagars senaste minne.

Det som blev känt som E00F, eller Exchange Double Zero-day Flaw i min terminologi, eller ProxyNotShell som det kanske är något förvirrande känt i Twittersphere.

Så det var den stora historien i denna månads Patch Tuesday: dessa två buggar blev spektakulärt nog inte fixade.

Och så vi vet inte när det kommer att hända.

Du måste se till att du har tillämpat eventuella begränsningar.

Som jag tror att vi har sagt tidigare, fann Microsoft hela tiden att de tidigare begränsningarna de föreslog... ja, de kanske inte var tillräckligt bra, och de fortsatte att ändra sin melodi och anpassa historien.

Så om du är osäker kan du gå tillbaka till nakedsecurity.sophos.com och söka efter frasen ProxyNotShell (alla ett ord), och gå sedan och läs på vad vi har att säga.

Och du kan också länka till den senaste versionen av Microsofts sanering...

…för av alla saker i Patch Tuesday, var det det mest intressanta, som du säger: för det var inte där.

---

DOUG.  OK, låt oss nu växla till a mycket frustrerande historia.

Detta är ett slag på handleden för ett stort företag vars cybersäkerhet är så dålig att de inte ens märkte att de hade blivit brutna!

---

ANKA.  Ja, det här är ett varumärke som de flesta förmodligen kommer att känna till som SHEIN (”she-in”), skrivet som ett ord, allt med versaler. (Vid tidpunkten för intrånget var företaget känt som Zoetop.)

Och de är vad som kallas "fast fashion".

Du vet, de staplar det högt och säljer det billigt, och inte utan kontroverser om var de får sin design ifrån.

Och som en onlineåterförsäljare skulle du kanske förvänta dig att de hade cybersäkerhetsdetaljerna på nätet nere.

Men som du säger, det gjorde de inte!

Och kontoret för justitieministern i delstaten New York i USA beslutade att det inte var nöjd med det sätt som New York-bor hade behandlats som var bland offren för detta intrång.

Så de vidtog rättsliga åtgärder mot det här företaget... och det var en absolut litania av misstag, misstag och slutligen mörkläggning – med ett ord, Douglas, oärlighet.

De hade detta brott som de inte märkte.

Detta, åtminstone tidigare, brukade vara en besvikelse vanligt: ​​företag skulle inte inse att de hade blivit kränkta förrän en kreditkortshanterare eller en bank kontaktade dem och sa: "Vet du vad, vi har haft väldigt mycket av klagomål om bedrägerier från kunder denna månad.”

"Och när vi tittade tillbaka på vad de kallar CPP, den gemensamt inköpsställe, den enda handlaren som varje enskilt offer verkar ha köpt något av är du. Vi tror att läckan kom från dig."

Och i det här fallet var det ännu värre.

Tydligen kom en annan betalningsbehandlare och sa: "Åh, förresten, vi hittade en hel del av kreditkortsnummer till salu, utbjudna som stulna från er."

Så de hade tydliga bevis för att det antingen hade skett ett intrång i bulk, eller ett intrång bit för bit.

---

DOUG.  Så visst, när det här företaget blev medvetet om detta, gick de snabbt för att rätta till situationen, eller hur?

---

ANKA.  Tja, det beror på hur du... [SKRATTAR] Jag borde inte skratta, Doug, som alltid.

Det beror på vad du menar med "rätta till".

---

DOUG.  [SKratt] Åh, gud!

---

ANKA.  Så det verkar som att de *gjorde* ta itu med problemet ... det fanns faktiskt delar av det som de täckte upp riktigt bra.

Uppenbarligen.

Det verkar som att de plötsligt bestämde sig, "Hoppsan, vi borde bli PCI DSS-kompatibla".

Det var de uppenbarligen inte, för de hade tydligen fört felsökningsloggar som hade kreditkortsuppgifter om misslyckade transaktioner... allt som du inte ska skriva till disken skrev de.

Och sedan insåg de att det hade hänt, men de kunde inte hitta var de lämnade den datan i sitt eget nätverk!

Så uppenbarligen visste de att de inte var PCI DSS-kompatibla.

De satte igång att göra sig själva PCI DSS-kompatibla, uppenbarligen, något som de uppnådde 2019. (Brottet inträffade 2018.)

Men när de fick höra att de var tvungna att underkasta sig en revision, en kriminalteknisk utredning...

… enligt New Yorks justitieminister, kom de helt medvetet i vägen för utredaren.

De tillät i princip utredarna att se systemet som det var *efter* att de fixat det, och svetsade det och polerade det, och de sa, "Åh nej, du kan inte se säkerhetskopiorna", vilket låter ganska styggt för mig .

---

DOUG.  Uh-va.

---

ANKA.  Och även sättet de avslöjade intrånget för sina kunder väckte stor ilska från delstaten New York.

Speciellt verkar det som att det var ganska uppenbart att 39,000,000 5 XNUMX användares uppgifter på något sätt hade gjorts bort med, inklusive mycket svagt hashade lösenord: ett tvåsiffrigt salt och en omgång MDXNUMX.

Inte tillräckligt bra 1998, än mindre 2018!

Så de visste att det fanns ett problem för det här stora antalet användare, men uppenbarligen började de bara kontakta de 6,000,000 XNUMX XNUMX av de användare som faktiskt hade använt deras konton och gjort beställningar.

Och sedan sa de, "Ja, vi har åtminstone kontaktat alla dessa människor."

Och *då* visade det sig att de faktiskt inte riktigt hade kontaktat alla 6,000,000 XNUMX XNUMX miljoner användare!

De hade precis kontaktat de av de sex miljoner som råkade bo i Kanada, USA eller Europa.

Så om du kommer från någon annanstans i världen, otur!

Som ni kan föreställa er det gick inte bra med myndigheterna, hos tillsynsmyndigheten.

Och jag måste erkänna... till min förvåning, Doug, fick de böter på 1.9 miljoner dollar.

Vilket för ett så stort företag...

---

DOUG.  Ja!

---

ANKA.  …och göra så grova misstag, och sedan inte vara helt anständig och ärlig om vad som hade hänt, och bli förbryllad för att ljuga om intrånget, med dessa ord, av åklagaren i New York?

Jag föreställde mig att de kunde ha drabbats av ett allvarligare öde.

Kanske till och med inkludera något som inte bara kunde betalas av genom att komma med lite pengar.

Åh, och det andra de gjorde är att när det var uppenbart att det fanns användare vars lösenord var i fara... eftersom de var djupt knäckbara på grund av det faktum att det var ett tvåsiffrigt salt, vilket betyder att du kan bygga 100 förberäknade ordböcker …

---

DOUG.  Är det vanligt?

Bara ett tvåsiffrigt salt verkar väldigt lågt!

---

ANKA.  Nej, du skulle vanligtvis vilja ha 128 bitar (16 byte), eller till och med 32 byte.

Löst sett spelar det ingen nämnvärd skillnad på sprickhastigheten ändå, eftersom (beroende på blockstorleken på hashen) lägger du bara till två extra siffror i mixen.

Så det är inte ens som att själva beräkningen av hasharna tar längre tid.

Så långt tillbaka som 2016, tror jag att människor som använder datorer med åtta GPU:er som kör programmet "hashcat" kunde göra 200 miljarder MD5:er i sekunden.

Då! (Det beloppet är ungefär fem eller tio gånger högre nu.)

Så väldigt, väldigt eminent knäckbart.

Men istället för att faktiskt kontakta folk och säga, "Ditt lösenord är i fara eftersom vi läckte hashen, och det var inte särskilt bra, borde du ändra det", [SKRATT] sa de bara...

… det var väl väldigt snåla ord?

---

DOUG.  "Ditt lösenord har en låg säkerhetsnivå och kan vara i fara. Vänligen ändra ditt inloggningslösenord."

Och sedan ändrade de det till "Ditt lösenord har inte uppdaterats på mer än 365 dagar. För ditt skydd, uppdatera den nu."

---

ANKA.  Ja, "Ditt lösenord har en låg säkerhetsnivå..."

---

DOUG.  "PÅ GRUND AV OSS!"

---

ANKA.  Det är inte bara nedlåtande, eller hur?

Det är vid eller över gränsen till att skuldbelägga offer, i mina ögon.

Hur som helst, detta verkade inte vara ett särskilt starkt incitament för företag som inte vill göra rätt.

---

DOUG.  Okej, hör av dig i kommentarerna, vi vill gärna höra vad du tycker!

Den artikeln heter: Modemärket SHEIN bötfälldes med 1.9 miljoner dollar för att ha ljugit om dataintrång.

Och till en annan frustrerande historia...

.., en annan dag, en annan varnande berättelse om att bearbeta otillförlitlig input!

---

ANKA.  Aaargh, jag vet vad det kommer att bli, Doug.

Det är Apache Commons-text bugg, eller hur?

---

DOUG.  Det är!

---

ANKA.  Bara för att vara tydlig, det är inte Apache-webbservern.

Apache är en mjukvarustiftelse som har en hel mängd produkter och gratisverktyg... och de är verkligen mycket användbara, och de är öppen källkod, och de är fantastiska.

Men vi har haft, i Java-delen av deras ekosystem (Apache Web Server httpd är inte skriven i Java, så låt oss ignorera det för tillfället – blanda inte ihop Apache med Apache Web Server)...

…det senaste året har vi haft tre liknande problem i Apaches Java-bibliotek.

Vi hade ökänd Log4Shell bug i det så kallade Log4J-biblioteket (Logging for Java).

Sedan hade vi en liknande bugg, vad var det?... Apache Commons-konfiguration, som är en verktygslåda för att hantera alla typer av konfigurationsfiler, säg INI-filer och XML-filer, allt på ett standardiserat sätt.

Och nu i ett bibliotek på ännu lägre nivå som heter Apache Commons-text.

Buggen i det som i Java är allmänt känt som "stränginterpolation".

Programmerare på andra språk... om du använder saker som PowerShell eller Bash, kommer du att känna det som "strängbyte".

Det är där du magiskt kan få en mening full av karaktärer att förvandlas till ett slags miniprogram.

Om du någonsin har använt Bash-skalet vet du det om du skriver kommandot echo USER, kommer den att eka, eller skriva ut, strängen USER och du kommer att se, på skärmen ANVÄNDARE.

Men om du kör kommandot echo $USER, då betyder det inte att jag upprepar ett dollartecken följt av USER.

Vad det betyder är "Ersätt den magiska strängen med namnet på den för närvarande inloggade användaren och skriv ut den istället."

Så på min dator, om du echo USER, du får USER, men om du echo $USER, du förstår ordet duck istället.

Och några av Java-strängbytena går mycket, mycket, mycket längre än så... som alla som led glädjen av fixar Log4Shell över jul 2021 kommer att minnas!

Det finns alla möjliga smarta små miniprogram som du kan bädda in i strängar som du sedan bearbetar med detta strängbehandlingsbibliotek.

Så det finns det uppenbara: att läsa användarnamnet, sätter du ${env: (för "läs miljön") user}… du använder snirkliga parenteser.

Det är ett dollartecken; snirkligt fäste; något magiskt kommando; snirklig fäste som är den magiska delen.

Och tyvärr, i det här biblioteket, fanns det okontrollerad standardtillgänglighet av magiska kommandon som: ${url:...}, som låter dig lura strängbehandlingsbiblioteket att nå ut på internet, ladda ner något och skriva ut vad det får tillbaka från den webbservern istället för strängen ${url:...}.

Så även om det inte är helt kodinjektion, eftersom det bara är rå HTML, betyder det fortfarande att du kan lägga alla möjliga skräp och konstiga och underbara opålitliga saker i människors loggfiler eller deras webbsidor.

Det finns ${dns:...}, vilket innebär att du kan lura någons server, som kan vara en affärslogikserver i nätverket...

…du kan lura den att göra en DNS-sökning för en namngiven server.

Och om du äger den domänen, som en skurk, äger och driver du också DNS-servern som är relaterad till den domänen.

Så, gissa vad när DNS-sökningen händer?

Den uppslagningen avslutas *på din server* och kan hjälpa dig att kartlägga insidan av någons affärsnätverk ... inte bara deras webbserver, utan saker djupare i nätverket.

Och slutligen, och det mest oroande, åtminstone med äldre versioner av Java, fanns det... [SKratt] du vet vad som kommer här, Doug!

Kommandot ${script:...}.

"Hej, låt mig förse dig med lite JavaScript och kör det åt mig."

Och du tänker förmodligen, "Vad?! Vänta, det här är en bugg i Java. Vad har JavaScript med det att göra?”

Tja, tills relativt nyligen ... och kom ihåg, många företag använder fortfarande äldre versioner av Java Development Kit som fortfarande stöds.

Tills nyligen innehöll Java… [skrattar] (igen, jag borde inte skratta)… Java Development Kit innehöll, i sig själv, en fullständig fungerande JavaScript-motor, skriven i Java.

Nu finns det inget samband mellan Java och JavaScript förutom de fyra bokstäverna "Java", men du kan lägga ${script:javascript:...}och kör valfri kod.

Och, irriterande nog, en av de saker som du kan göra i JavaScript-motorn i Java-runtime är att säga till JavaScript-motorn, "Hej, jag vill köra den här saken via Java."

Så du kan få Java att anropa *in i* JavaScript, och JavaScript i huvudsak att anropa *ut* i Java.

Och sedan, från Java, kan du säga "Hej, kör det här systemkommandot."

Och om du går till artikeln om Naked Security, kommer du att se mig använda ett misstänkt kommando för att [HOSTA URSKYTTANDE] slänga iväg, Doug!

En HP RPN-kalkylator, naturligtvis, eftersom det är jag som gör att räknaren poppar...

---

DOUG.  Det måste det vara, ja!

---

ANKA.  …den här är en HP-10.

Så även om risken inte är som bra som Log4Shell, du kan inte utesluta det om du använder det här biblioteket.

Vi har några instruktioner i artikeln Naked Security om hur du tar reda på om du har Commons Text-biblioteket ... och du kanske har det, som många människor gjorde med Log4J, utan att inse det, eftersom det kan ha kommit tillsammans med en app.

Och vi har också lite exempelkod där som du kan använda för att testa om eventuella begränsningar som du har infört har fungerat.

---

DOUG.  Okej, gå över till Naked Security.

Den artikeln heter: Farligt hål i Apache Commons Text – som Log4Shell igen.

Och vi avslutar med en fråga: "Vad händer när krypterade meddelanden bara är typ krypterade?"

---

ANKA.  Ah, du syftar på det som, antar jag, var en officiell felrapport som nyligen lämnades in av cybersäkerhetsforskare på det finska företaget WithSecure...

…om den inbyggda krypteringen som erbjuds i Microsoft Office, eller mer exakt, en funktion som kallas Office 365 Message Encryption eller OME.

Det är ganska praktiskt att ha en sådan liten funktion inbyggd i appen.

---

DOUG.  Ja, det låter enkelt och bekvämt!

---

ANKA.  Ja, förutom... åh, kära du!

Det verkar som att orsaken till detta beror på bakåtkompatibilitet, Doug...

...att Microsoft vill att den här funktionen ska fungera ända tillbaka till personer som fortfarande använder Office 2010, som har ganska gammaldags dekrypteringsförmåga inbyggd.

I grund och botten verkar det som att denna OME-process för att kryptera filen använder AES, som är den senaste och bästa NIST-standardiserade krypteringsalgoritmen.

Men den använder AES i fel så kallat krypteringsläge.

Den använder vad som kallas ECB, eller elektronisk kodbok läge.

Och det är helt enkelt så du refererar till rå AES.

AES krypterar 16 byte åt gången... förresten, den krypterar 16 byte oavsett om du använder AES-128, AES-192 eller AES-256.

Blanda inte ihop blockstorleken och nyckelstorleken – blockstorleken, antalet byte som krypteras och krypteras varje gång du vrider på vevhandtaget på den kryptografiska motorn, är alltid 128 bis eller 16 byte.

Hur som helst, i elektronisk kodboksläge tar du helt enkelt 16 byte indata, vrider på vevhandtaget en gång under en given krypteringsnyckel och tar utdata, rå och obearbetad.

Och problemet med det är att varje gång du får samma indata i ett dokument justerat på samma 16-byte-gräns...

...du får exakt samma data i utdata.

Så mönster i ingången avslöjas i utgången, precis som de är i en Caesar chiffer eller a Vigenère chiffer:

Nu betyder det inte att du kan knäcka chiffret, eftersom du fortfarande har att göra med bitar som är 128 bitar breda åt gången.

Problemet med elektroniskt kodboksläge uppstår just för att det läcker mönster från klartexten till chiffertexten.

Kända klartextattacker är möjliga när du vet att en viss indatasträng krypterar på ett visst sätt, och för upprepad text i ett dokument (som en rubrik eller ett företagsnamn), återspeglas dessa mönster.

Och även om detta rapporterades som en bugg till Microsoft, uppenbarligen har företaget beslutat att det inte kommer att fixa det eftersom det "inte uppfyller kraven" för en säkerhetsfix.

Och det verkar som att anledningen är: "Tja, vi skulle göra en otjänst för människor som fortfarande använder Office 2010."

---

DOUG.  Oj!

---

ANKA.  Ja!

---

DOUG.  Och på den noten har vi en läsarkommentar för denna vecka på den här historien.

Naked Security Reader Bill kommenterar, delvis:

Detta påminner mig om "sängarna" som Bletchley Parks kodbrytare använde under andra världskriget. Nazisterna avslutade ofta meddelanden med samma avslutande fras, och på så sätt kunde kodbrytarna arbeta tillbaka från denna avslutande uppsättning krypterade tecken, och veta vad de troligen representerade. Det är en besvikelse att vi 80 år senare verkar upprepa samma misstag.

---

ANKA.  80 år!

Ja, det är verkligen en besvikelse.

Min uppfattning är att andra spjälsängar som allierade kodbrytare kunde använda, särskilt för nazi-krypterade texter, också handlade om *början* av dokumentet.

Jag tror att detta var en sak för tyska väderrapporter... det fanns ett religiöst format som de följde för att se till att de gav väderrapporterna exakt.

Och väderrapporter, som ni kan föreställa er, under ett krig som involverar flygbombningar på natten, var verkligen viktiga saker!

Det verkar som om de följde ett mycket, väldigt strikt mönster som ibland kunde användas som vad man kan kalla lite av en kryptografisk "lossare", eller en kil som man kunde använda för att bryta in i första hand.

Och det, som Bill påpekar... det är just därför AES, eller vilket chiffer som helst, i elektronisk kodboksläge inte är tillfredsställande för att kryptera hela dokument!

---

DOUG.  Okej, tack för att du skickade in det, Bill.

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 medier: @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!