S3 Ep105: WONTFIX! De MS Office-cryptofout die "geen beveiligingsfout is" [Audio + Tekst]

Klik en sleep op de onderstaande geluidsgolven om naar een willekeurig punt te gaan. Je kan ook luister direct op Soundcloud.

DOUG.  Adembenemende inbreuken, decodeerbare codering en patches in overvloed.

Dat alles meer op de Naked Security-podcast.

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug Aamoth; hij is Paul Ducklin.

Paul, hoe gaat het vandaag, meneer?

---

EEND.  Doug... ik weet het, want je hebt me van tevoren verteld wat er binnenkomt? Deze week in de technische geschiedenis, en het is GEWELDIG!

---

DOUG.  OK!

Deze week, op 18 oktober 1958, werden een oscilloscoop en een computer, gebouwd om windweerstand te simuleren, gecombineerd met aangepaste aluminium controllers, en het spel Tennis voor twee was geboren.

Tennis for Two, dat werd getoond tijdens een driedaagse tentoonstelling in het Brookhaven National Laboratory, bleek enorm populair te zijn, vooral bij middelbare scholieren.

Als je hiernaar luistert, moet je naar Wikipedia gaan en "Tennis for Two" opzoeken.

Er is daar een video van iets dat in 1958 is gebouwd...

…Ik denk dat je het met me eens zult zijn, Paul, het was behoorlijk ongelooflijk.

---

EEND.  Ik zou *graag* het vandaag willen spelen!

En, zoals Asteroids en Battle Zone, en die speciaal herinnerde games uit de jaren 1980...

...omdat het een oscilloscoop is: vectorafbeeldingen!

Geen pixelvorming, geen verschillen afhankelijk van of een lijn 90 graden, 30 graden of 45 graden is.

En de geluidsfeedback van de relais in de controllers... geweldig!

Het is niet te geloven dat dit 1958 was.

Teruggrijpen op een vorige Deze week in de technische geschiedenis, het was aan de vooravond van de transistorrevolutie.

Blijkbaar was de rekenhelft een mengsel van thermionische kleppen (vacuümbuizen) en relais.

En de weergavecircuits waren allemaal op transistors gebaseerd, Doug

Het was dus precies de mix van alle technologieën: relais, kleppen en transistors, allemaal in één baanbrekende videogame.

---

DOUG.  Heel cool.

Check het op Wikipedia: Tennis voor twee.

Laten we nu verder gaan met ons eerste verhaal.

Paul, ik weet dat je erg bedreven bent in het schrijven van een geweldig gedicht...

... Ik heb een heel kort gedicht geschreven om dit eerste verhaal in te leiden, als je me wilt verwennen.

---

EEND.  Dus dat zijn dan twee regels, nietwaar? [LACHT]

---

DOUG.  Het gaat een beetje zo.

Zoom voor Mac/Niet krijgen gekaapt.

[HEEL LANGE STILTE]

Einde gedicht.

---

EEND.  Oh sorry!

Ik dacht dat dat de titel was, en dat je nu het gedicht zou gaan maken.

---

DOUG.  Zo, dat is het gedicht.

---

EEND.  OK.

[ZONDER EMOTIE] Lief, Doug.

---

DOUG.  [IRONIC] Dank je.

---

EEND.  Het rijm was spectaculair!

Maar niet alle gedichten hoeven te rijmen….

---

DOUG.  Dat is waar.

---

EEND.  We zullen het gewoon gratis vers noemen, zullen we?

---

DOUG.  OK ALSJEBLIEFT.

---

EEND.  Helaas was dit een gratis achterdeur naar Zoom voor Mac.

[SCHULDIG GEVOEL] Sorry, dat was niet zo'n goed vervolg, Doug.

[LACHT] Je betreedt het terrein van iemand anders, je komt vaak te kort...

---

DOUG.  Nee het is goed!

Ik was deze week gedichten aan het uitproberen; je probeert segues uit.

We moeten af ​​en toe uit onze comfortzone komen.

---

EEND.  Ik neem aan dat dit code was die bedoeld was om te worden gecompileerd toen de laatste build was voltooid, maar die er per ongeluk in bleef zitten.

Het is alleen voor de Zoom voor Mac-versie en het is gepatcht, dus zorg ervoor dat je up-to-date bent.

Kortom, onder bepaalde omstandigheden, wanneer een videostream zou starten of de camera werd geactiveerd door de app zelf, zou het per ongeluk denken dat u het programma misschien wilt debuggen.

Want hé, misschien was je een ontwikkelaar! [LACHT]

Dat hoort natuurlijk niet te gebeuren in release-builds.

En dat betekende dat er een TCP-foutopsporingspoort open was gelaten op de lokale netwerkinterface.

Dat betekende dat iedereen die pakketten naar die poort kon sturen, wat vermoedelijk elke andere lokaal verbonden gebruiker zou kunnen zijn, dus het zou geen beheerder of zelfs jij moeten zijn... zelfs een gastgebruiker, dat zou genoeg zijn.

Dus een aanvaller die een soort proxy-malware op uw computer had die pakketten van buitenaf kon ontvangen en deze in de lokale interface kon injecteren, zou in feite opdrachten kunnen geven aan de ingewanden van het programma.

En de typische dingen die foutopsporingsinterfaces toestaan, zijn onder meer: ​​wat geheugen dumpen; geheimen extraheren; het gedrag van het programma veranderen; configuratie-instellingen aanpassen zonder de gebruikelijke interface te doorlopen, zodat de gebruiker het niet kan zien; alle audio opnemen zonder het iemand te vertellen, zonder de opnamewaarschuwing te laten verschijnen; al dat soort dingen.

Het goede nieuws is dat Zoom het zelf heeft gevonden en dat ze het vrij snel hebben gepatcht.

Maar het is een geweldige herinnering dat, zoals we zo vaak zeggen, [LACHT] "Er is veel misstap tussen de beker en de lip."

---

DOUG.  Goed, heel goed.

Laten we aan boord van de patchtrein blijven en naar het volgende station rijden.

En dit verhaal... misschien wel het meest interessante deel van dit verhaal van de meest recente Patch Tuesday was wat Microsoft *niet* heeft opgenomen?

---

EEND.  Helaas waren de patches die iedereen waarschijnlijk verwachtte - en we speculeerden in een recente podcast: "Nou, het lijkt erop dat Microsoft ons nog een week zal laten wachten tot Patch Tuesday, en geen out-of-band "early release ” zijn die twee Exchange-nuldagen van recent geheugen.

Wat bekend werd als E00F, of Dubbele zero-day fout inruilen in mijn terminologie, of ProxyNiet Shell zoals het misschien enigszins verwarrend bekend is in de Twittersfeer.

Dat was dus het grote verhaal in de Patch Tuesday van deze maand: die twee bugs werden op spectaculaire wijze niet verholpen.

En dus weten we niet wanneer dat gaat gebeuren.

U moet ervoor zorgen dat u eventuele beperkende maatregelen hebt toegepast.

Zoals ik denk dat we al eerder hebben gezegd, bleef Microsoft ontdekken dat de eerdere oplossingen die ze voorstelden... nou ja, misschien waren ze niet helemaal goed genoeg, en ze bleven hun deuntje veranderen en het verhaal aanpassen.

Dus als je twijfelt, kun je teruggaan naar nakedsecurity.sophos.com, zoeken naar de zin ProxyNiet Shell (allemaal één woord), en ga dan lezen wat we te zeggen hebben.

En u kunt ook een koppeling maken naar de nieuwste versie van Microsoft's herstel ...

...omdat, van alle dingen in Patch Tuesday, dat het interessantst was, zoals je zegt: omdat het er niet was.

---

DOUG.  OK, laten we nu overschakelen naar a heel frustrerend verhaal.

Dit is een klap op de pols voor een groot bedrijf wiens cyberbeveiliging zo slecht is dat ze niet eens merkten dat ze waren geschonden!

---

EEND.  Ja, dit is een merk dat de meeste mensen waarschijnlijk zullen kennen als SHEIN ("she-in"), geschreven als één woord, allemaal in hoofdletters. (Op het moment van de inbreuk stond het bedrijf bekend als Zoetop.)

En ze zijn wat 'fast fashion' wordt genoemd.

Weet je, ze stapelen het hoog op en verkopen het goedkoop, en niet zonder controverse over waar ze hun ontwerpen vandaan halen.

En als online retailer zou je misschien verwachten dat ze de cyberbeveiligingsdetails van online retailing onder de knie hadden.

Maar zoals je zegt, dat deden ze niet!

En het kantoor van de procureur-generaal van de staat New York in de VS besloot dat het niet blij was met de manier waarop de inwoners van New York waren behandeld die tot de slachtoffers van deze inbreuk behoorden.

Dus namen ze juridische stappen tegen dit bedrijf ... en het was een absolute litanie van blunders, fouten en uiteindelijk doofpotaffaires - in één woord, Douglas, oneerlijkheid.

Ze hadden een inbreuk die ze niet opmerkten.

Dit was, althans in het verleden, teleurstellend gebruikelijk: bedrijven zouden niet beseffen dat ze waren geschonden totdat een creditcardbehandelaar of een bank contact met hen zou opnemen en zeggen: "Weet je, we hebben ontzettend veel klachten over fraude van klanten deze maand.”

“En toen we terugkeken naar wat ze de CPP noemen, gemeenschappelijk verkooppunt, de enige echte handelaar waar elk slachtoffer iets van lijkt te hebben gekocht, ben jij. We denken dat het lek van jou kwam.'

En in dit geval was het nog erger.

Blijkbaar kwam er een andere betalingsverwerker langs en zei: "O, trouwens, we hebben een hele reeks creditcardnummers te koop gevonden, aangeboden als gestolen van jullie."

Ze hadden dus duidelijk bewijs dat er ofwel een grote inbreuk was geweest, ofwel een beetje bij beetje.

---

DOUG.  Dus toen dit bedrijf hiervan op de hoogte werd gebracht, hebben ze zeker snel gehandeld om de situatie recht te zetten, toch?

---

EEND.  Nou, dat hangt ervan af hoe je... [LACHEND] Ik moet niet lachen, Doug, zoals altijd.

Dat hangt ervan af wat je bedoelt met "rectificeren".

---

DOUG.  [LACHEND] Oh, god!

---

EEND.  Dus het lijkt erop dat ze * het probleem hebben opgelost ... inderdaad, er waren delen ervan die ze heel goed verdoezelden.

Blijkbaar.

Het lijkt erop dat ze plotseling besloten: "Oeps, we kunnen maar beter PCI DSS-compatibel worden".

Dat waren ze duidelijk niet, want ze hadden blijkbaar foutopsporingslogboeken bijgehouden met creditcardgegevens van mislukte transacties... alles wat je niet naar schijf mag schrijven, waren ze aan het schrijven.

En toen realiseerden ze zich dat dat was gebeurd, maar ze konden niet vinden waar ze die gegevens in hun eigen netwerk hadden achtergelaten!

Dus ze wisten duidelijk dat ze niet PCI DSS-compatibel waren.

Ze begonnen zichzelf PCI DSS-compatibel te maken, blijkbaar, iets dat ze tegen 2019 hebben bereikt (De inbreuk vond plaats in 2018.)

Maar toen ze te horen kregen dat ze zich moesten onderwerpen aan een audit, een forensisch onderzoek...

…volgens de procureur-generaal van New York stonden ze de onderzoeker heel bewust in de weg.

Ze lieten de onderzoekers het systeem zien zoals het was * nadat * ze het hadden gerepareerd, gelast en gepolijst, en ze zeiden: "Oh nee, je kunt de back-ups niet zien", wat nogal ondeugend voor mij klinkt .

---

DOUG.  Uh Huh.

---

EEND.  En ook de manier waarop ze de inbreuk aan hun klanten bekendmaakten, wekte grote woede bij de staat New York.

Het lijkt er vooral op dat het vrij duidelijk was dat er op de een of andere manier met de gegevens van 39,000,000 gebruikers was geknoeid, waaronder zeer zwak gehashte wachtwoorden: een tweecijferige salt en een ronde MD5.

Niet goed genoeg in 1998, laat staan ​​2018!

Ze wisten dus dat er een probleem was voor dit grote aantal gebruikers, maar blijkbaar begonnen ze alleen contact op te nemen met de 6,000,000 van die gebruikers die hun accounts daadwerkelijk hadden gebruikt en bestellingen hadden geplaatst.

En toen zeiden ze: "Nou, we hebben in ieder geval al die mensen gecontacteerd."

En *toen* bleek dat ze niet echt alle 6,000,000 miljoen gebruikers hadden gecontacteerd!

Ze hadden net contact opgenomen met de zes miljoen die toevallig in Canada, de Verenigde Staten of Europa woonden.

Dus als je ergens anders in de wereld vandaan komt, pech!

U kunt zich voorstellen dat dat niet in goede aarde viel bij de autoriteiten, bij de toezichthouder.

En ik moet toegeven... tot mijn verbazing, Doug, kregen ze een boete van $ 1.9 miljoen.

Wat voor een bedrijf zo groot...

---

DOUG.  Ja!

---

EEND.  … en zulke grove fouten maken, en dan niet helemaal fatsoenlijk en eerlijk zijn over wat er was gebeurd, en door de procureur-generaal van New York beschuldigd worden van liegen over de breuk, in die woorden?

Ik stelde me een beetje voor dat ze misschien een ernstiger lot hadden ondergaan.

Misschien zelfs met iets dat niet gewoon kon worden afbetaald door met wat geld op de proppen te komen.

Oh, en het andere dat ze deden, was dat toen het duidelijk was dat er gebruikers waren wiens wachtwoorden in gevaar waren ... omdat ze diep te kraken waren vanwege het feit dat het een tweecijferig zout was, wat betekent dat je 100 vooraf berekende woordenboeken kon bouwen …

---

DOUG.  Is dat gebruikelijk?

Slechts een tweecijferig zout lijkt erg laag!

---

EEND.  Nee, normaal gesproken wilt u 128 bits (16 bytes) of zelfs 32 bytes.

Losjes gesproken maakt het sowieso geen significant verschil voor de kraaksnelheid, omdat je (afhankelijk van de blokgrootte van de hash) maar twee extra cijfers aan de mix toevoegt.

Het is dus niet eens alsof het daadwerkelijke berekenen van de hashes langer duurt.

Al in 2016 konden mensen die computers met acht GPU's gebruikten met het 'hashcat'-programma, denk ik, 200 miljard MD5's per seconde maken.

Vroeger! (Dat bedrag is nu ongeveer vijf of tien keer hoger.)

Dus zeer, zeer kraakbaar.

Maar in plaats van daadwerkelijk contact op te nemen met mensen en te zeggen: "Je wachtwoord loopt gevaar omdat we de hash hebben gelekt, en het was niet erg goed, je zou het moeten veranderen", [GELACH] zeiden ze gewoon ...

... het waren erg wispelturige woorden, nietwaar?

---

DOUG.  “Uw wachtwoord heeft een laag beveiligingsniveau en loopt mogelijk risico. Wijzig uw inlogwachtwoord.”

En toen veranderden ze het in: "Uw wachtwoord is al meer dan 365 dagen niet bijgewerkt. Werk het nu voor uw eigen veiligheid bij.”

---

EEND.  Ja, "Uw wachtwoord heeft een laag beveiligingsniveau..."

---

DOUG.  "VANWEGE ONS!"

---

EEND.  Dat is niet alleen betuttelend, toch?

Dat is op of over de grens naar victim blaming, in mijn ogen.

Hoe dan ook, dit leek me geen erg sterke stimulans voor bedrijven die het niet goed willen doen.

---

DOUG.  Oké, zet het geluid uit in de reacties, we horen graag wat je ervan vindt!

Dat artikel heet: Modemerk SHEIN krijgt boete van $ 1.9 miljoen voor liegen over datalek.

En op naar een ander frustrerend verhaal…

..,nog een dag, nog een waarschuwend verhaal over het verwerken van niet-vertrouwde invoer!

---

EEND.  Aaargh, ik weet wat dat gaat worden, Doug.

Dat is de Apache Commons-tekst fout, niet?

---

DOUG.  Het is!

---

EEND.  Voor alle duidelijkheid, dat is niet de Apache Web Server.

Apache is een softwarestichting die een hele reeks producten en gratis tools heeft... en ze zijn inderdaad erg handig, en ze zijn open source, en ze zijn geweldig.

Maar we hebben in het Java-gedeelte van hun ecosysteem (de Apache Web Server httpd is niet geschreven in Java, dus laten we dat voor nu negeren - verwar Apache niet met Apache Web Server)...

...in het afgelopen jaar hebben we drie soortgelijke problemen gehad in de Java-bibliotheken van Apache.

We hadden de berucht Log4Shell kever in de zogenaamde Log4J (Logging for Java) bibliotheek.

Toen hadden we een soortgelijke bug, wat was het?… Apache Commons-configuratie, een toolkit voor het beheren van allerlei configuratiebestanden, bijvoorbeeld INI-bestanden en XML-bestanden, allemaal op een gestandaardiseerde manier.

En nu in een nog lagere bibliotheek genaamd Apache Commons-tekst.

De bug zit in het ding dat in Java algemeen bekend staat als "stringinterpolatie".

Programmeurs in andere talen ... als je dingen als PowerShell of Bash gebruikt, ken je het als "stringvervanging".

Hier kun je op magische wijze een zin vol karakters omtoveren tot een soort miniprogramma.

Als je ooit de Bash-shell hebt gebruikt, weet je dat als je de opdracht typt echo USER, het zal de tekenreeks echoën of afdrukken USER en je zult zien, op het scherm GEBRUIKER.

Maar als u de opdracht uitvoert echo $USER, dan betekent dat niet de echo van een dollarteken gevolgd door USER.

Wat het betekent is: "Vervang die magische string door de naam van de momenteel ingelogde gebruiker en druk die in plaats daarvan af."

Dus op mijn computer, als je echo USER, Jij krijgt USER, maar als jij echo $USER, je krijgt het woord duck gebruiken.

En sommige van de Java-tekenreeksvervangingen gaan veel, veel, veel verder dan dat ... zoals iedereen die de vreugde heeft ondervonden van Log4Shell repareren met Kerstmis 2021 zal het onthouden!

Er zijn allerlei slimme kleine miniprogramma's die je kunt insluiten in strings die je vervolgens verwerkt met deze stringverwerkingsbibliotheek.

Dus er is een voor de hand liggende: om de gebruikersnaam te lezen, zet je ${env: (voor “lees de omgeving”) user}… je gebruikt kronkelige haakjes.

Het is een dollarteken; kronkelige beugel; een magisch commando; kronkelige beugel dat is het magische deel.

En helaas was er in deze bibliotheek ongecontroleerde standaardbeschikbaarheid van magische commando's zoals: ${url:...}, waarmee je de stringverwerkingsbibliotheek kunt misleiden om contact op te nemen op internet, iets te downloaden en af ​​te drukken wat het terugkrijgt van die webserver in plaats van de string ${url:...}.

Dus hoewel dat niet echt code-injectie is, omdat het gewoon onbewerkte HTML is, betekent het nog steeds dat je allerlei soorten rotzooi en rare en prachtige niet-vertrouwde dingen in de logbestanden van mensen of hun webpagina's kunt plaatsen.

Er is ${dns:...}, wat betekent dat je iemands server kunt misleiden, wat een bedrijfslogica-server binnen het netwerk kan zijn...

... je kunt het misleiden om een ​​DNS-zoekopdracht uit te voeren voor een benoemde server.

En als u als oplichter eigenaar bent van dat domein, dan bezit en beheert u ook de DNS-server die betrekking heeft op dat domein.

Dus, raad eens wanneer de DNS-look-up plaatsvindt?

Dat opzoeken eindigt *op uw server*, en kan u helpen de ingewanden van iemands zakelijke netwerk in kaart te brengen... niet alleen hun webserver, maar dingen dieper in het netwerk.

En tot slot, en het meest verontrustende, in ieder geval met oudere versies van Java, was er... [LACHT] je weet wat er gaat komen, Doug!

Het bevel ${script:...}.

"Hé, laat me je wat JavaScript geven en dat vriendelijk voor me uitvoeren."

En je denkt waarschijnlijk: "Wat?! Wacht even, dit is een bug in Java. Wat heeft JavaScript ermee te maken?”

Nou, tot relatief recent... en onthoud dat veel bedrijven nog steeds oudere, nog steeds ondersteunde versies van de Java Development Kit gebruiken.

Tot voor kort, Java... [LACHT] (nogmaals, ik moet niet lachen)... de Java Development Kit bevatte in zichzelf een volledig werkende JavaScript-engine, geschreven in Java.

Nu is er geen relatie tussen Java en JavaScript, behalve de vier letters "Java", maar je zou kunnen zeggen: ${script:javascript:...}en voer de code van uw keuze uit.

En, vervelend genoeg, een van de dingen die je kunt doen in de JavaScript-engine binnen de Java-runtime is de JavaScript-engine vertellen: "Hé, ik wil dit ding via Java uitvoeren."

U kunt Java dus *in* JavaScript laten aanroepen, en JavaScript in wezen om *out* in Java aan te roepen.

En dan kun je vanuit Java gaan: "Hé, voer deze systeemopdracht uit."

En als je naar het artikel Naked Security gaat, zul je zien dat ik een verdacht commando gebruik om [COUGHS APOLOGETICALLY] een berekening te maken, Doug!

Een HP RPN-rekenmachine natuurlijk, want ik doe de rekenmachine knallen ...

---

DOUG.  Het moet zo zijn, ja!

---

EEND.  ...deze is een HP-10.

Dus hoewel het risico niet zo is: geweldig als Log4Shell, je kunt het niet echt uitsluiten als je deze bibliotheek gebruikt.

We hebben enkele instructies in het artikel Naked Security om erachter te komen of je de Commons Text-bibliotheek hebt...

En we hebben daar ook wat voorbeeldcode die u kunt gebruiken om te testen of eventuele maatregelen die u hebt ingevoerd, hebben gewerkt.

---

DOUG.  Oké, ga naar Naked Security.

Dat artikel heet: Gevaarlijk gat in Apache Commons Text - zoals Log4Shell helemaal opnieuw.

En we sluiten af ​​met een vraag: "Wat gebeurt er als versleutelde berichten slechts een beetje versleuteld zijn?"

---

EEND.  Ah, je verwijst naar wat, denk ik, een officieel bugrapport was dat onlangs werd ingediend door cyberbeveiligingsonderzoekers bij het Finse bedrijf WithSecure...

…over de ingebouwde codering die wordt aangeboden in Microsoft Office, of beter gezegd, een functie genaamd Office 365 Message Encryption of OME.

Het is best handig om zo'n kleine functie in de app te hebben ingebouwd.

---

DOUG.  Ja, het klinkt eenvoudig en handig!

---

EEND.  Ja, behalve... oh, schat!

Het lijkt erop dat de reden hiervoor allemaal te maken heeft met achterwaartse compatibiliteit, Doug ...

... dat Microsoft wil dat deze functie helemaal terug werkt naar mensen die nog steeds Office 2010 gebruiken, waarin nogal ouderwetse decoderingscapaciteiten zijn ingebouwd.

Kortom, het lijkt erop dat dit OME-proces voor het versleutelen van het bestand AES gebruikt, het nieuwste en beste NIST-gestandaardiseerde coderingsalgoritme.

Maar het gebruikt AES in de verkeerde zogenaamde encryptiemodus.

Het maakt gebruik van wat bekend staat als ECB, of elektronisch codeboek modus.

En dat is gewoon de manier waarop u naar onbewerkte AES verwijst.

AES versleutelt 16 bytes per keer... tussen haakjes, het versleutelt 16 bytes, of je nu AES-128, AES-192 of AES-256 gebruikt.

Haal de blokgrootte en de sleutelgrootte niet door elkaar - de blokgrootte, het aantal bytes dat wordt gekarnd en versleuteld elke keer dat u de hendel van de cryptografische engine draait, is altijd 128 bis of 16 bytes.

Hoe dan ook, in elektronische codeboekmodus neem je gewoon 16 bytes aan invoer, draai je de slinger één keer rond onder een bepaalde coderingssleutel en neem je de uitvoer, onbewerkt en niet opnieuw verwerkt.

En het probleem daarmee is dat elke keer dat u dezelfde invoer krijgt in een document dat is uitgelijnd op dezelfde 16-byte grens...

... je krijgt precies dezelfde gegevens in de uitvoer.

Dus patronen in de invoer worden onthuld in de uitvoer, net zoals ze zijn in a Caesar cijfer of a Vigenere cijfer:

Dit betekent niet dat je het cijfer kunt kraken, omdat je nog steeds te maken hebt met chunks die 128 bits breed zijn.

Het probleem met de elektronische codeboekmodus ontstaat juist omdat het patronen uit de leesbare tekst in de cijfertekst lekt.

Bekende aanvallen in platte tekst zijn mogelijk wanneer u weet dat een bepaalde invoerreeks op een bepaalde manier codeert, en voor herhaalde tekst in een document (zoals een koptekst of een bedrijfsnaam), worden die patronen weerspiegeld.

En hoewel dit aan Microsoft werd gemeld als een bug, heeft het bedrijf blijkbaar besloten het niet te repareren omdat het "niet voldoet aan de lat" voor een beveiligingsoplossing.

En het lijkt erop dat de reden is: "Nou, we zouden een slechte dienst bewijzen aan mensen die nog steeds Office 2010 gebruiken."

---

DOUG.  Oef!

---

EEND.  Ja!

---

DOUG.  En wat dat betreft hebben we een lezerscommentaar voor deze week op dit verhaal.

Naked Security Reader Bill opmerkingen, gedeeltelijk:

Dit doet me denken aan de 'cribs' die de Bletchley Park codebrekers gebruikten tijdens de Tweede Wereldoorlog. De nazi's eindigden berichten vaak met dezelfde slotzin, en dus konden de codebrekers terugwerken op deze afsluitende reeks gecodeerde karakters, wetende wat ze waarschijnlijk vertegenwoordigden. Het is teleurstellend dat we 80 jaar later dezelfde fouten lijken te maken.

---

EEND.  80 jaar!

Ja, het is inderdaad teleurstellend.

Ik heb begrepen dat andere kribben die geallieerde codebrekers konden gebruiken, met name voor nazi-gecodeerde teksten, ook het *begin* van het document behandelden.

Ik geloof dat dit iets was voor Duitse weerberichten... er was een religieus format dat ze volgden om er zeker van te zijn dat ze de weerberichten precies gaven.

En weerberichten, zoals je je kunt voorstellen, tijdens een oorlog waarbij 's nachts luchtbombardementen plaatsvinden, waren echt belangrijke dingen!

Het lijkt erop dat die een heel, heel strikt patroon volgden dat soms zou kunnen worden gebruikt als wat je een beetje een cryptografische "losser" zou kunnen noemen, of een wig die je zou kunnen gebruiken om in de eerste plaats in te breken.

En dat, zoals Bill aangeeft... dat is precies de reden waarom AES, of welke codering dan ook, in elektronische codeboekmodus niet voldoet voor het versleutelen van volledige documenten!

---

DOUG.  Oké, bedankt voor het insturen, Bill.

Als je een interessant verhaal, opmerking of vraag hebt die je wilt indienen, lezen we die graag in de podcast.

Je kunt een e-mail sturen naar tips@sophos.com, reageren op een van onze artikelen of je kunt ons bereiken op social: @nakedsecurity.

Dat is onze show voor vandaag; heel erg bedankt voor het luisteren.

Voor Paul Ducklin, ik ben Doug Aamoth, ik herinner je eraan tot de volgende keer om...

---

BEIDE.  Blijf veilig!