Serieuze beveiliging: de Samba-aanmeldingsbug veroorzaakt door verouderde cryptovaluta

Samba, simpel gezegd, is een superhandige, megapopulaire, open-source herimplementatie van de netwerkprotocollen die worden gebruikt in Microsoft Windows, en het historische belang ervan bij internetwerken (twee verschillende soorten netwerken met elkaar verbinden) kan niet worden onderschat.

Aan het einde van de jaren negentig verloor Microsoft-netwerken zijn ondoorzichtige, eigendomsrechtelijk karakter en werd het een open standaard die bekend staat als CIFS, een afkorting van gemeenschappelijk internet bestandssysteem.

Maar begin jaren negentig was er niets 'gewoon' of 'open' aan, toen de Australische academicus Andrew Tridgell dat probeerde te corrigeren door een compatibel systeem te implementeren waarmee hij zijn Unix-computer kon verbinden met een Windows-netwerk, en vice versa.

Destijds heette het protocol officieel SMB, een afkorting van server bericht blok (een naam die je nog steeds veel vaker hoort dan CIFS), dus noemde Tridge, zoals Andrew Tridgell bekend staat, begrijpelijkerwijs zijn project "SMBserver", want dat was het ook.

Maar er bestond al een commercieel product met die naam, dus een nieuwe naam was nodig.

Toen werd het project bekend als Samba, een heerlijk gedenkwaardige naam die het resultaat was van een woordenboekzoekopdracht naar woorden van de vorm S?M?B?.

Eigenlijk, samba is nog steeds het eerste woord uit de poort alfabetisch in de dict bestand dat vaak wordt aangetroffen op Unix-computers, gevolgd door het nogal slecht passende woord scramble en het totaal ongepast scumbag:

Sommige bugs die je maakt, maar sommige bugs die je krijgt

In de loop der jaren heeft het Samba-project niet alleen zijn eigen unieke bugs geïntroduceerd en verholpen, zoals elk complex softwareproject in het algemeen doet, maar ook bugs en tekortkomingen geërfd in het onderliggende protocol, aangezien het altijd de bedoeling was om naadloos samen te werken met Windows-netwerken.

(Helaas, zogenaamd compatibiliteit met bugs is vaak een onvermijdelijk onderdeel van het bouwen van een nieuw systeem dat werkt met een bestaand systeem.)

Eind 2022 werd een van die "overgeërfde kwetsbaarheden" gevonden en gerapporteerd aan Microsoft, gezien de identifier CVE-2022-38023, en gepatcht in de Patch Tuesday-update van november 2022.

Deze bug had een aanvaller in staat kunnen stellen de inhoud van sommige netwerkdatapakketten te wijzigen zonder gedetecteerd te worden, ondanks het gebruik van cryptografische MAC's (verificatiecodes van berichten) bedoeld om spoofing en sabotage te voorkomen.

Met name door gegevens tijdens het inloggen te manipuleren, kunnen sluwe cybercriminelen een EoP-aanval (elevance-of-privilege) uitvoeren.

Ze zouden, in ieder geval in theorie, een server kunnen misleiden door te denken dat ze geslaagd waren voor de "heeft u beheerdersreferenties?" test, hoewel ze die inloggegevens niet hadden en hun nepgegevens de cryptografische verificatie hadden moeten doorstaan.

Cryptografische behendigheid

We hebben besloten om over deze nogal esoterische bug te schrijven, niet omdat we denken dat de kans erg groot is dat je erdoor wordt uitgebuit (hoewel we, als het op cyberbeveiliging aankomt, de houding aannemen zeg nooit nooit), maar omdat het een nog een herinnering van waarom? cryptografische flexibiliteit is belangrijk.

---

---

gezamenlijk we hebben zowel de vaardigheid als de wil nodig om oude algoritmen voorgoed achter ons te laten zodra ze gebrekkig blijken te zijn, en ze niet voor onbepaalde tijd te laten rondslingeren totdat ze het probleem van iemand anders worden. (Die 'iemand anders' zou wel eens ons kunnen blijken te zijn, tien jaar later.)

Verbazingwekkend genoeg bestond de CVE-2022-38023-kwetsbaarheid in de eerste plaats omdat zowel Windows als Samba nog steeds een stijl van integriteitsbescherming ondersteunden die was gebaseerd op het lang geleden verouderde hashing-algoritme MD5.

Simpel gezegd, netwerkauthenticatie met behulp van de Microsoft-versie van het Kerberos-protocol maakte het nog steeds mogelijk om gegevens te beschermen tegen integriteit (of gecheckt, om de terloopse maar niet strikt nauwkeurige jargonterm te gebruiken) met behulp van gebrekkige cryptografie.

Je zou MD5 niet meer moeten gebruiken omdat het als kapot wordt beschouwd: een vastberaden aanvaller kan gemakkelijk met twee verschillende invoer komen die eindigen met dezelfde MD5-hash.

Zoals je waarschijnlijk al weet, is een van de vereisten van elke hasj die cryptografische kwaliteit claimt, dat dit simpelweg niet mogelijk zou moeten zijn.

In het jargon staan ​​twee ingangen met dezelfde hash bekend als a botsing, en er zouden geen programmatische trucs of snelkoppelingen moeten zijn om u te helpen er snel een te vinden.

Er zou geen manier moeten zijn om een ​​botsing te vinden die beter is dan gewoon veel geluk – keer op keer proberen met steeds veranderende invoerbestanden totdat je de jackpot wint.

De werkelijke kosten van een aanrijding

Uitgaande van een betrouwbaar algoritme, zonder exploiteerbare zwakke punten, zou je verwachten dat een hash met X bits output ongeveer 2 bits nodig zou hebben^X-1 probeert een tweede invoer te vinden die botste met de hash van een bestaand bestand.

Zelfs als alles wat je zou willen doen was om twee willekeurige ingangen te vinden (twee willekeurige ingangen, ongeacht inhoud, grootte of structuur) die toevallig dezelfde hash hebben, zou je verwachten iets meer dan 2 nodig te hebben^{X / 2} probeert voordat je een botsing krijgt.

Elk hash-algoritme dat op betrouwbare wijze sneller kan worden 'gekraakt', is cryptografisch niet veilig, omdat u hebt aangetoond dat het interne proces voor het versnipperen, hakken en roeren van de gegevens die erin worden ingevoerd, geen echt pseudo-willekeurig resultaat.

Merk op dat elke meer dan kansrijke kraakprocedure, zelfs als het het generatieproces van botsingen slechts een beetje versnelt en daarom momenteel geen misbruikbaar risico in het echte leven zou zijn, het vertrouwen in het onderliggende cryptografische algoritme vernietigt door zijn beweringen van cryptografische correctheid te ondermijnen .

Als er 2 . zijn^X verschillende mogelijke hash-outputs, zou je hopen een 50:50 kans te hebben om een ​​input te vinden met een specifieke, vooraf bepaalde hash na ongeveer de helft van het aantal pogingen, en 2^X/2 = 2^X-1. Het vinden van twee bestanden die botsen is gemakkelijker, want elke keer dat u een nieuwe invoer probeert, wint u als uw nieuwe hash botst met elke van de vorige ingangen die je al hebt geprobeerd, omdat elk paar ingangen is toegestaan. Voor een botsing van de sortering "elke twee bestanden in deze gigantische emmer zijn voldoende", bereikt u de 50:50 kans op succes met net iets meer dan de vierkantswortel van het aantal mogelijke hashes, en √2^X = 2^{X / 2}. Dus voor een 128-bits hash zoals MD5 zou je verwachten dat je gemiddeld ongeveer 2¹²⁷ blokken om overeen te komen met een specifieke uitvoerwaarde, en 2⁶⁴ blokken om elk paar botsende ingangen te vinden.

Snelle MD5-botsingen gemakkelijk gemaakt

Het is namelijk niet eenvoudig om twee totaal verschillende, niet-gerelateerde, pseudowillekeurige ingangen te genereren die dezelfde MD5-hash hebben.

En je kunt niet gemakkelijk teruggaan van een MD5-hash om iets te ontdekken over de specifieke input die het heeft geproduceerd, wat een andere cryptografische belofte is die een betrouwbare hash moet nakomen.

Maar als je begint met twee identieke ingangen en zorgvuldig een opzettelijk berekend paar "botsingsvormende" brokken op hetzelfde punt in elke invoerstroom invoegt, kun je op betrouwbare wijze MD5-botsingen binnen enkele seconden creëren, zelfs op een bescheiden laptop.

Hier is bijvoorbeeld een Lua-programma dat we hebben geschreven en dat handig kan worden opgesplitst in drie verschillende secties, elk 128 bytes lang.

Er is een codevoorvoegsel dat eindigt met een regel tekst waarmee een Lua-commentaar begint (de tekenreeks die begint --[== in regel 8), dan zijn er 128 bytes commentaartekst die kan worden vervangen door wat we maar willen, omdat het wordt genegeerd wanneer het bestand wordt uitgevoerd (regel 9 tot 11), en er is een codeachtervoegsel van 128 bytes dat het commentaar sluit (de string starten --]== in regel 12) en beëindigt het programma.

Zelfs als je geen programmeur bent, kun je waarschijnlijk zien dat de actieve code de inhoud [regel 14] van het broncodebestand zelf inleest (in Lua is de waarde arg[0] op regel 5 staat de naam van het scriptbestand dat u momenteel uitvoert), drukt u het vervolgens af als een hex-dump [regel 15] , gevolgd door de MD5-hash [regel 17]:

Het uitvoeren van het bestand is in wezen zelfbeschrijvend en maakt de drie blokken van 128 bytes duidelijk:

Een MD5 gebruiken onderzoeksinstrument Dit betekent dat we onszelf en onze geliefden praktisch vergiftigen. md5_fastcoll, oorspronkelijk gemaakt door wiskundige Marc Stevens als onderdeel van zijn masterdiploma in cryptografie in 2007, produceerden we snel twee 128-byte "MD5 collision-building" chunks die we gebruikten om de commentaartekst in het bovenstaande bestand te vervangen.

Hierdoor zijn twee bestanden gemaakt die beide nog steeds werken zoals voorheen, omdat de wijzigingen beperkt blijven tot de opmerking, wat geen invloed heeft op de uitvoerbare code in beide bestanden.

Maar ze zijn zichtbaar verschillend in meerdere bytes en zouden daarom totaal verschillende hash-waarden moeten hebben, zoals de volgende code diff (jargon voor dump van gedetecteerde verschillen) onthult.

We hebben de 128-bytes die botsingen veroorzaken, die niet logisch zijn als afdrukbare tekst, omgezet in hexadecimaal voor de duidelijkheid:

Als je ze allebei uitvoert, blijkt echter duidelijk dat ze een hash-botsing vertegenwoordigen, omdat ze dezelfde MD5-uitvoer blijken te hebben:

Botsingscomplexiteit onderzocht

MD5 is een 128-bits hash, zoals de uitvoerstrings hierboven duidelijk maken.

Dus, zoals eerder vermeld, verwachten we er ongeveer 2 nodig te hebben^128/2Of 2⁶⁴ probeert gemiddeld om een ​​MD5-botsing van welke soort dan ook te veroorzaken.

Dat betekent het verwerken van minimaal ongeveer 18 triljoen MD5-hashblokken, omdat 2⁶⁴ = 18,446,744,073,709,551,616.

Met een geschatte maximale MD5-hashsnelheid van ongeveer 50,000,000 blokken/seconde op onze laptop, betekent dit dat we meer dan 10,000 jaar moeten wachten, en hoewel goed gefinancierde aanvallers gemakkelijk 10,000 tot 100,000 keer sneller kunnen gaan, zouden zelfs zij dat doen. wacht weken of maanden op een enkele willekeurige (en niet noodzakelijkerwijs nuttige) botsing.

Maar het bovenstaande paar Lua-bestanden met twee gezichten, die exact dezelfde MD5-hash hebben ondanks dat ze duidelijk niet identiek zijn, kostte ons slechts een paar seconden om voor te bereiden.

Inderdaad, het genereren van 10 verschillende botsingen voor 10 bestanden, met behulp van 10 verschillende startvoorvoegsels die we zelf hebben gekozen, kostte ons: 14.9 sec, 4.7 sec, 2.6 sec, 2.1 sec, 10.5 sec, 2.4 sec, 2.0 sec, 0.14 sec, 8.4 sec, en 0.43 sec.

Het is duidelijk dat de cryptografische belofte van MD5 om te bieden wat bekend staat als weerstand tegen botsingen is fundamenteel kapot...

…blijkbaar met een factor van minstens 25 miljard, gebaseerd op het delen van de gemiddelde tijd die we verwachten te wachten om een ​​botsing te vinden (duizenden jaren, zoals hierboven geschat) door de slechtste tijd die we daadwerkelijk hebben gemeten (14.9 seconden) tijdens het uitrollen tien verschillende botsingen alleen voor dit artikel.

De authenticatiefout uitgelegd

Maar hoe zit het met het onveilige gebruik van MD5 in CVE-2022-38023?

In pseudocode in Lua-stijl was de defecte berichtauthenticatiecode die tijdens aanmeldingen werd gebruikt zo berekend:

Ter verduidelijking: de gebruikte authenticatiecode wordt berekend door de hmac.md5() functieaanroep in regel 15, met behulp van wat bekend staat als a ingetoetste hasj, in dit geval HMAC-MD5.

De naam HMAC is een afkorting van cryptografische constructie voor het genereren van op hash gebaseerde authenticatiecodes voor berichten, en het achtervoegsel -MD5 geeft het hash-algoritme aan dat intern wordt gebruikt.

HMAC gebruikt een geheime sleutel, gecombineerd met twee aanroepen van de onderliggende hash, in plaats van slechts één, om de berichtauthenticatiecode te produceren:

De sleutel heeft eerst enkele bits omgedraaid en wordt toegevoegd aan de geleverde gegevens voordat de eerste hash begint.

Dit vermindert aanzienlijk de controle die cryptografische crackers hebben, wanneer ze een botsing of ander niet-willekeurig gedrag in het hashproces proberen uit te lokken, over de interne status van de hashfunctie wanneer de eerste bytes van de invoergegevens worden bereikt.

Met name voorkomt de geheime sleutel dat aanvallers beginnen met een berichtvoorvoegsel van hun eigen keuze, zoals we deden in de twohash.lua voorbeeld hierboven.

Zodra de eerste hash is berekend, wordt de sleutel met een andere set bits omgedraaid, wordt deze toegevoegd aan die eerste hash-waarde en worden deze nieuwe invoergegevens een tweede keer gehasht.

Dit voorkomt dat de aanvallers ook het laatste deel van de HMAC-berekening manipuleren, met name voorkomen dat ze een achtervoegsel van hun eigen keuze toevoegen aan de laatste fase van het hashproces.

Hoewel u MD5 helemaal niet zou moeten gebruiken, zijn we niet op de hoogte van huidige aanvallen die het algoritme kunnen breken wanneer het wordt gebruikt in HMAC-MD5-vorm met een willekeurig gekozen sleutel.

Het gat zit in het midden

Het exploiteerbare gat in de bovenstaande pseudocode bevindt zich daarom niet in een van de regels waar de hmac.md5() functie wordt gebruikt.

In plaats daarvan is de kern van de bug regel 11, waar de gegevens die u wilt verifiëren, worden gecomprimeerd tot een reeks met een vaste lengte...

.. door het door een enkele aanroep van gewone oude MD5 te duwen.

Met andere woorden, welke HMAC-functie je ook kiest in regel 15, en hoe sterk en botsbestendig die laatste stap ook is, je hebt toch de kans om een ​​hash-botsing te veroorzaken op regel 11.

Simpel gezegd, als u de gegevens kent die in de chksum() functie die moet worden geverifieerd, en u kunt een botsingsgenerator gebruiken om een ​​ander gegevensblok te vinden met dezelfde MD5-hash...

…regel 11 betekent dat je eindigt met exact dezelfde invoerwaarde (de variabele signdat in de pseudocode) in de zo veilig als u wilt laatste HMAC-stap geduwd worden.

Dus ook al gebruik je aan het einde misschien een sterk versleutelde berichtsamenvattingsfunctie, toch authenticeer je misschien een MD5-hash die is afgeleid van bedriegergegevens.

Minder was meer geweest

Als Samba's beveiligingsbulletin beschrijft het probleem compact:

De zwakte […] is dat de beveiligde controlesom wordt berekend als HMAC-MD5(MD5(DATA),KEY), wat betekent dat een actieve aanvaller die de gegevens in platte tekst kent, een andere keuze kan maken DATA, met dezelfde MD5-controlesom, en vervang deze in de gegevensstroom zonder te worden gedetecteerd.

Ironisch genoeg, het weglaten van de MD5(DATA) een deel van de bovenstaande HMAC-formule, die op het eerste gezicht het algehele "mengproces" lijkt te vergroten, zou de botsingsweerstand verbeteren.

Zonder die MD5-compressie in het midden zou je een botsing in HMAC-MD5 zelf moeten vinden, wat waarschijnlijk niet mogelijk is in 2023, zelfs niet met bijna onbeperkte overheidsfinanciering, althans niet binnen de levensduur van de netwerksessie die je probeerde compromis sluiten.

Waarom duurde het zo lang?

Je vraagt ​​je nu waarschijnlijk net als wij af waarom deze bug zo lang onontdekt of in ieder geval niet gepatcht is.

Immers, RFC 6151, dat dateert uit 2011 en de veelbetekenende titel heeft Bijgewerkte beveiligingsoverwegingen voor de MD5 Message-Digest en de HMAC-MD5-algoritmen, adviseert als volgt (onze nadruk, meer dan een decennium later):

De aanvallen op HMAC-MD5 lijken niet te duiden op een praktische kwetsbaarheid bij gebruik als berichtauthenticatiecode. Daarom is het misschien niet urgent om HMAC-MD5 uit de bestaande protocollen te verwijderen. Echter, sinds MD5 mag niet worden gebruikt voor digitale handtekeningen, voor een nieuw protocolontwerp, een ciphersuite met HMAC-MD5 mag niet worden opgenomen.

Aangezien de overgrote meerderheid van de recente SMB-serverplatforms HMAC-MD5-authenticatie hebben uitgeschakeld wanneer gebruikers proberen in te loggen, lijkt het er echter op dat SMB-clients die deze onveilige modus nog steeds ondersteunen, deze over het algemeen nooit hebben gebruikt (en hoe dan ook zouden zijn mislukt als ze dat wel hadden gedaan). geprobeerd).

Cliënten leken impliciet “beschermd” en de onveilige code leek zo goed als onschadelijk, omdat de zwakke authenticatie niet nodig was en ook niet gebruikt werd.

Het potentiële probleem kreeg dus gewoon nooit de aandacht die het verdiende.

Helaas faalt dit soort "beveiliging door aanname" volledig als je een server tegenkomt (of wordt gelokt) die deze onveilige situatie wel accepteert chksum() algoritme tijdens het inloggen.

Dit soort "downgrade-probleem" is niet nieuw: in 2015 bedachten onderzoekers de beruchte FREAK en LOGJAM aanvallen, die netwerkclients opzettelijk misleidden om zogenaamde EXPORT-cijfers te gebruiken, de opzettelijk verzwakte coderingsmodi waar de Amerikaanse regering vorige eeuw bizar genoeg op aandrong.

Zoals we toen schreven:

EXPORT-sleutellengtes werden in de jaren negentig gekozen om zo goed als kraakbaar te zijn, maar werden nooit verlengd om gelijke tred te houden met de vooruitgang in processorsnelheid.

Dat komt omdat exportcijfers rond 2000 door de VS werden verlaten.

Ze waren vanaf het begin een dwaas idee: Amerikaanse bedrijven importeerden zojuist cryptografische software zonder exportbeperkingen en schaadden hun eigen software-industrie.

Toen de wetgevers eenmaal toegaven, werden de EXPORT-coderingssuites natuurlijk overbodig, dus stopte iedereen ermee.

Helaas behielden veel cryptografische toolkits, waaronder OpenSSL en Microsoft's SChannel, de code om ze te ondersteunen, dus jij (of, nog zorgwekkender, goed geïnformeerde boeven) werden er niet van weerhouden om ze te gebruiken.

Deze keer lijkt de belangrijkste boosdoener onder de servers die nog steeds dit defecte MD5-plus-HMAC-MD5-proces gebruiken, de NetApp-reeks te zijn, waarin sommige producten blijkbaar blijven (of deden tot voor kort) vertrouwen op dit riskante algoritme.

Daarom kunt u soms nog steeds een kwetsbaar netwerkaanmeldingsproces doorlopen en loopt u risico door CVE-2022-38023, misschien zonder het zelfs maar te beseffen.

Wat te doen?

Deze bug is eindelijk geweest behandeld, althans standaard, in de laatste release van Samba.

Simpel gezegd, Samba-versie 4.17.5 forceert nu de twee opties reject md5 clients = yes en reject md5 servers = yes.

Dit betekent dat alle cryptografische componenten in de verschillende SMB-netwerkprotocollen waarbij het MD5-algoritme is betrokken (zelfs als ze theoretisch veilig zijn, zoals HMAC-MD5), standaard verboden.

Als het echt nodig is, kunt u ze weer inschakelen voor toegang tot specifieke servers in uw netwerk.

Zorg er wel voor dat als u uitzonderingen maakt die internetstandaarden al meer dan tien jaar officieel afraden...

...dat je jezelf een datum hebt opgelegd waarop je die niet-standaardopties eindelijk voor altijd zult beëindigen!

Cryptografische aanvallen worden alleen maar slimmer en sneller, dus vertrouw nooit op verouderde protocollen en algoritmen die simpelweg "niet meer worden gebruikt".

Haal ze helemaal uit je code, want als ze er helemaal niet zijn, KUNT je ze NIET gebruiken, en kun je er niet toe worden verleid ze te gebruiken door iemand die je in onzekerheid probeert te lokken.

---

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/