Allvarlig säkerhet: Samba-inloggningsfelet orsakat av föråldrad krypto

Samba, enkelt uttryckt, är en superanvändbar, megapopulär återimplementering av öppen källkod av nätverksprotokollen som används i Microsoft Windows, och dess historiska betydelse för internetarbete (att koppla ihop två olika typer av nätverk) kan inte underskattas.

I slutet av 1990-talet avskaffade Microsofts nätverk sin ogenomskinliga, proprietära karaktär och blev en öppen standard känd som CIFS, förkortning för vanligt internet filsystem.

Men det var inget "vanligt" eller "öppet" med det i början av 1990-talet, när den australiensiske akademikern Andrew Tridgell ville rätta till det genom att implementera ett kompatibelt system som skulle låta honom ansluta sin Unix-dator till ett Windows-nätverk, och vice versa.

Då kallades protokollet officiellt SMB, förkortning för server meddelande block (ett namn som du fortfarande hör mycket oftare än CIFS), så Tridge, som Andrew Tridgell är känd, kallade förståeligt sitt projekt "SMBserver", för det var vad det var.

Men en kommersiell produkt med det namnet fanns redan, så en ny moniker behövdes.

Det var då projektet blev känt som Samba, ett förtjusande minnesvärt namn som är resultatet av en ordbokssökning efter ord i formen S?M?B?.

I själva verket, samba är fortfarande det första ordet ut ur porten alfabetiskt i dict fil som vanligtvis finns på Unix-datorer, följt av det ganska illa passande ordet scramble och det totalt olämpliga scumbag:

Vissa buggar gör man, men vissa buggar får man

Genom åren har Samba-projektet inte bara introducerat och fixat sina egna unika buggar, som alla komplexa programvaruprojekt i allmänhet gör, utan också ärvt buggar och brister i det underliggande protokollet, med tanke på att dess mål alltid har varit att fungera sömlöst med Windows-nätverk.

(Tråkigt nog så kallade buggkompatibilitet är ofta en oundviklig del av att bygga ett nytt system som fungerar med ett befintligt.)

I slutet av 2022 hittades en av dessa "ärvda sårbarheter" och rapporterades till Microsoft, givet identifieraren CVE-2022-38023, och korrigerad i november 2022 Patch Tuesday-uppdateringen.

Denna bugg kunde ha tillåtit en angripare att ändra innehållet i vissa nätverksdatapaket utan att bli upptäckt, trots användningen av kryptografiska MAC:er (meddelandeautentiseringskoder) avsedd att förhindra spoofing och manipulering.

Särskilt, genom att manipulera data vid inloggningstidpunkten, kan listiga cyberbrottslingar genomföra en elevation-of-privilege (EoP) attack.

De kunde åtminstone i teorin lura en server att tro att de hade klarat "har du administratörsuppgifter?" testa, även om de inte hade dessa referenser och deras falska data borde ha misslyckats med dess kryptografiska verifiering.

Kryptografisk smidighet

Vi bestämde oss för att skriva om denna ganska esoteriska bugg, inte för att vi tror att du är fruktansvärt sannolikt att bli utnyttjad av den (men när det kommer till cybersäkerhet tar vi attityden Säg aldrig aldrig), men för att det är en ännu en påminnelse av varför kryptografisk smidighet är viktig.

---

---

Kollektivt, vi behöver både skickligheten och viljan att lämna kvar gamla algoritmer för gott så snart de upptäcks vara felaktiga, och att inte låta dem ligga kvar på obestämd tid tills de förvandlas till någon annans problem. (Denna "någon annan" kan mycket väl visa sig vara vi, tio år senare.)

Förvånande nog existerade CVE-2022-38023-sårbarheten i första hand eftersom både Windows och Samba fortfarande stödde en stil av integritetsskydd baserad på den sedan länge föråldrade hashalgoritmen MD5.

Enkelt uttryckt tillät nätverksautentisering med Microsofts version av Kerberos-protokollet fortfarande att data integritetsskyddades (eller kontrollsummas, för att använda den tillfälliga men inte strikt korrekta jargongtermen) med felaktig kryptografi.

Du borde inte använda MD5 längre eftersom den anses trasig: en bestämd angripare kan lätt komma med två olika ingångar som slutar med samma MD5-hash.

Som du säkert redan vet är ett av kraven för alla hash som hävdar kryptografisk kvalitet att detta helt enkelt inte borde vara möjligt.

På jargongen kallas två ingångar som har samma hash som a kollision, och det är inte meningen att det ska finnas några programmatiska knep eller genvägar som hjälper dig att snabbt hitta en.

Det borde inte finnas något sätt att hitta en kollision som är bättre än enkel lycka – försök om och om igen med ständigt föränderliga indatafiler tills du vinner jackpotten.

Den verkliga kostnaden för en kollision

Om du antar en tillförlitlig algoritm, utan exploateringsbara svagheter, skulle du förvänta dig att en hash med X bitar av utdata skulle behöva cirka 2^X-1 försöker hitta en andra ingång som kolliderade med hashen i en befintlig fil.

Även om allt du ville göra var att hitta två valfria ingångar (två godtyckliga ingångar, oavsett innehåll, storlek eller struktur) som bara råkade ha samma hash, skulle du förvänta dig att behöva något mer än 2^{X / 2} försöker innan du träffar på en kollision.

Alla hashalgoritmer som på ett tillförlitligt sätt kan "knäckas" snabbare än så är inte kryptografiskt säkra, eftersom du har visat att dess interna process för att strimla-hacka-och-röra upp data som matas in i den inte producerar en verkligt pseudoslumpmässiga resultat alls.

Observera att varje crackingprocedur som är bättre än chansen, även om den bara snabbar upp kollisionsgenereringsprocessen något och därför för närvarande inte skulle vara en exploaterbar risk i det verkliga livet, förstör tron ​​på den underliggande kryptografiska algoritmen genom att undergräva dess påståenden om kryptografisk korrekthet .

Om det är 2^X olika möjliga hash-utgångar, hoppas du få en 50:50 chans att hitta en ingång med en specifik, förutbestämd hash efter ungefär hälften så många försök, och 2^X/ 2 = 2^X-1. Det är lättare att hitta två filer som kolliderar, för varje gång du provar en ny ingång vinner du om din nya hash kolliderar med vilken som helst av de tidigare ingångarna som du redan har provat, eftersom alla par av ingångar är tillåtna. För en kollision av typen "vilka som helst i denna gigantiska hink kommer du att klara", träffar du 50:50 chansen att lyckas med bara något mer än kvadratroten av antalet möjliga hash, och √2^X = 2^{X / 2}. Så, för en 128-bitars hash som MD5, förväntar du dig i genomsnitt att hasha cirka 2¹²⁷ block för att matcha ett specifikt utdatavärde, och 2⁶⁴ block för att hitta valfritt par av kolliderande ingångar.

Snabba MD5-kollisioner på ett enkelt sätt

Som det händer kan du inte enkelt generera två helt olika, orelaterade, pseudoslumpmässiga ingångar som har samma MD5-hash.

Och du kan inte lätt gå baklänges från en MD5-hash för att avslöja någonting om den specifika indata som producerade den, vilket är ett annat kryptografiskt löfte som en pålitlig hash måste hålla.

Men om du börjar med två identiska ingångar och försiktigt sätter in ett avsiktligt beräknat par "kollisionsbyggande" bitar vid samma punkt i varje ingångsström, kan du tillförlitligt skapa MD5-kollisioner på några sekunder, även på en blygsam bärbar dator.

Till exempel, här är ett Lua-program vi skrev som bekvämt kan delas upp i tre distinkta sektioner, var och en 128 byte lång.

Det finns ett kodprefix som slutar med en textrad som startar en Lua-kommentar (strängen som börjar --[== på rad 8), så finns det 128 byte kommentartext som kan ersättas med vad vi vill, eftersom den ignoreras när filen körs (raderna 9 till 11), och det finns ett kodsuffix på 128 byte som stänger kommentaren (den sträng som börjar --]== på rad 12) och avslutar programmet.

Även om du inte är en programmerare kan du förmodligen se att den aktiva koden läser i innehållet [rad 14] i själva källkodsfilen (i Lua, värdet arg[0] på rad 5 är namnet på skriptfilen som du kör), skrivs den sedan ut som en hex-dump [rad 15] följt av dess MD5-hash [rad 17]:

Att köra filen är i huvudsak självbeskrivande och gör de tre 128-byte blocken uppenbara:

Använder en MD5 forskningsverktyg kallas md5_fastcoll, ursprungligen skapad av matematiker Marc Stevens som en del av hans magisterexamen i kryptografi redan 2007 producerade vi snabbt två 128-byte "MD5 kollisionsbyggande"-bitar som vi använde för att ersätta kommentarstexten som visas i filen ovan.

Detta skapade två filer som båda fortfarande fungerar som de gjorde tidigare, eftersom ändringarna är begränsade till kommentaren, vilket inte påverkar den körbara koden i någon av filerna.

Men de är synligt olika i flera byte, och bör därför ha helt olika hashvärden, eftersom följande koddiff (jargong för dumpning av upptäckta skillnader) avslöjar.

Vi har konverterat de 128-byte kollisionsskapande bitarna, som inte är meningsfulla som utskrivbar text, till hexadecimal för tydlighetens skull:

Att köra dem båda visar dock tydligt att de representerar en hashkollision, eftersom de visar sig ha samma MD5-utgång:

Kollisionskomplexitet undersökt

MD5 är en 128-bitars hash, vilket utgångssträngarna ovan tydliggör.

Så, som nämnts tidigare, förväntar vi oss att behöva cirka 2^128/2Eller 2⁶⁴ försöker i genomsnitt producera en MD5-kollision av något slag.

Det innebär att bearbeta minst cirka 18 kvintiljoner MD5-hashblock, eftersom 2⁶⁴ = 18,446,744,073,709,551,616.

Med en uppskattad maximal MD5-hashhastighet på cirka 50,000,000 10,000 10,000 block/sekund på vår bärbara dator betyder det att vi måste vänta mer än 100,000 XNUMX år, och även om välfinansierade angripare lätt kan gå XNUMX XNUMX till XNUMX XNUMX gånger snabbare än så, skulle till och med de göra det. vänta veckor eller månader bara på att en enda slumpmässig (och inte nödvändigtvis användbar) kollision ska dyka upp.

Ändå tog ovanstående tvåsidiga Lua-filer, som har exakt samma MD5-hash trots att de helt klart inte är identiska, bara några sekunder att förbereda.

Faktum är att generera 10 olika kollisioner för 10 filer, med 10 olika startprefix som vi själva valde, tog oss: 14.9 sek, 4.7 sek, 2.6 sek, 2.1 sek, 10.5 sek, 2.4 sek, 2.0 sek, 0.14, 8.4 sek,, och 0.43 sek.

Tydligen, MD5:s kryptografiska löfte att tillhandahålla vad som kallas kollisionsmotstånd är i grunden trasig...

...uppenbarligen med en faktor på minst 25 miljarder, baserat på att dividera den genomsnittliga tid som vi förväntar oss att vänta på att hitta en kollision (tusentals år, enligt uppskattningen ovan) med den värsta tiden vi faktiskt uppmätt (14.9 sekunder) medan vi körde ut tio olika kollisioner bara för den här artikeln.

Autentiseringsfelet förklaras

Men hur är det med den osäkra användningen av MD5 i CVE-2022-38023?

I Lua-liknande pseudokod var den defekta meddelandeautentiseringskoden som användes vid inloggningar beräknat så här:

För att förklara: autentiseringskoden som används beräknas av hmac.md5() funktionsanrop på rad 15, med vad som kallas en nyckelad hash, i det här fallet HMAC-MD5.

Namnet HMAC är en förkortning av kryptografisk konstruktion för att generera hash-baserade meddelandeautentiseringskoder, och suffixet -MD5 anger hashalgoritmen som den använder internt.

HMAC använder en hemlig nyckel, kombinerad med två anrop av den underliggande hashen, istället för bara en, för att producera dess meddelandeautentiseringskod:

Nyckeln har några av sina bitar vända först, och läggs på den tillhandahållna datan innan den första hashen startar.

Detta minskar avsevärt kontrollen som kryptografiska crackers har, när de försöker framkalla en kollision eller annat icke-slumpmässigt beteende i hashprocessen, över det interna tillståndet för hashfunktionen när de första byten av indata nås.

Noterbart förhindrar den hemliga nyckeln angripare från att börja med ett meddelandeprefix efter eget val, som vi gjorde i twohash.lua exemplet ovan.

Sedan, när den första hashen har beräknats, har nyckeln en annan uppsättning bitar vänt, vänds in på det första hashvärdet, och denna nya indata hashas en andra gång.

Detta förhindrar angriparna från att manipulera den sista delen av HMAC-beräkningen också, vilket särskilt hindrar dem från att lägga till ett suffix efter eget val till det sista steget av hashprocessen.

Faktum är att även om du inte alls borde använda MD5, är vi inte medvetna om några aktuella attacker som kan bryta algoritmen när den används i HMAC-MD5-form med en slumpmässigt vald nyckel.

Hålet är i mitten

Det exploaterbara hålet i pseudokoden ovan finns därför inte på någon av raderna där hmac.md5() funktionen används.

Istället är hjärtat av buggen rad 11, där data du vill autentisera komprimeras till en sträng med fast längd...

.. genom att driva den genom en enda anrop av vanlig gammal MD5.

Med andra ord, oavsett vilken HMAC-funktion du väljer i linje 15, och hur stark och kollisionsbeständig det sista steget än kan vara, har du ändå en chans att orsaka en hashkollision på linje 11.

Enkelt uttryckt, om du vet vilken data som ska gå in i chksum() funktion för att autentiseras, och du kan använda en kollisionsgenerator för att hitta ett annat datablock med samma MD5-hash...

…rad 11 betyder att du kommer att hamna med exakt samma ingångsvärde (variabeln signdat i pseudokoden) och pressas in i det sista HMAC-steget lika säkert som du gillar.

Därför, även om du kanske använder en starkt nyckelfunktion för meddelandesammanfattning i slutet, kan du ändå autentisera en MD5-hash som härrörde från bedragardata.

Mindre skulle ha varit mer

Som Samba säkerhetsbulletinen beskriver kortfattat problemet:

Svagheten […] är ​​att den säkra kontrollsumman beräknas som HMAC-MD5(MD5(DATA),KEY), vilket betyder att en aktiv angripare som känner till klartextdata kan skapa en annan vald DATA, med samma MD5-kontrollsumma, och ersätt den i dataströmmen utan att detekteras.

Ironiskt nog att utelämna MD5(DATA) en del av HMAC-formeln ovan, som vid första anblicken verkar öka den övergripande "blandningsprocessen", skulle förbättra kollisionsmotståndet.

Utan den där MD5-komprimeringen i mitten skulle du behöva hitta en kollision i själva HMAC-MD5, vilket förmodligen inte är möjligt 2023, även med nästan obegränsad statlig finansiering, åtminstone inte under livslängden för nätverkssessionen du försökte Att kompromissa.

Vad tog så lång tid?

Vid det här laget undrar du förmodligen, precis som vi, varför denna bugg låg oupptäckt, eller åtminstone olappad, så länge.

När allt RFC 6151, som går tillbaka till 2011 och har den betydelsefulla titeln Uppdaterade säkerhetsöverväganden för MD5 Message-Digest och HMAC-MD5-algoritmerna, rekommenderar följande (vår betoning, mer än ett decennium senare):

Attackerna på HMAC-MD5 verkar inte indikera en praktisk sårbarhet när de används som autentiseringskod för meddelanden. Därför kanske det inte är brådskande att ta bort HMAC-MD5 från de befintliga protokollen. Men sedan MD5 får inte användas för digitala signaturer, för en ny protokolldesign, en chiffersvit med HMAC-MD5 ska inte inkluderas.

Det verkar dock, eftersom den stora majoriteten av de senaste SMB-serverplattformarna har HMAC-MD5-autentisering avstängd när användare försöker logga in, som att SMB-klienter som fortfarande stöder detta osäkra läge i allmänhet aldrig använde det (och skulle ha misslyckats i alla fall om de hade försökte).

Klienter verkade implicit vara "skyddade", och den osäkra koden verkade vara så gott som ofarlig, eftersom den svaga autentiseringen varken behövdes eller användes.

Så det potentiella problemet fick helt enkelt aldrig den uppmärksamhet det förtjänade.

Tyvärr misslyckas den här typen av "säkerhet genom antagande" helt om du råkar stöta på (eller lockas till) en server som accepterar detta osäkra chksum() algoritm under inloggning.

Den här typen av "nedgraderingsproblem" är inte ny: redan 2015 tänkte forskare på det ökända FREAK och LOGJAM attacker, som medvetet lurade nätverksklienter att använda så kallade EXPORT-chiffer, som var de medvetet försvagade krypteringslägen som den amerikanska regeringen bisarrt nog insisterade på enligt lag förra seklet.

Som vi skrev då:

EXPORT-nyckellängderna valdes för att vara nästan knäckbara på 1990-talet, men förlängdes aldrig för att hålla jämna steg med framstegen i processorhastighet.

Det beror på att exportchiffer övergavs av USA omkring 2000.

De var en dum idé från början: amerikanska företag importerade bara kryptografisk programvara som inte hade några exportrestriktioner och skadade sin egen mjukvaruindustri.

Naturligtvis, när lagstiftarna gav vika, blir EXPORT-chiffersviterna överflödiga, så alla slutade använda dem.

Tyvärr behöll många kryptografiska verktygssatser, inklusive OpenSSL och Microsofts SChannel, koden för att stödja dem, så att ni (eller, mer oroande, välinformerade skurkar) inte stoppades från att använda dem.

Den här gången verkar huvudboven bland servrar som fortfarande använder denna trasiga MD5-plus-HMAC-MD5-process vara NetApp-sortimentet, där vissa produkter uppenbarligen fortsatte (eller gjorde det tills nyligen) att förlita sig på denna riskabla algoritm.

Därför kan du fortfarande ibland gå igenom en sårbar nätverksinloggningsprocess och vara i riskzonen från CVE-2022-38023, kanske utan att ens inse det.

Vad göra?

Denna bugg har äntligen varit handskats med, åtminstone som standard, i den senaste versionen av Samba.

Enkelt uttryckt, Samba version 4.17.5 tvingar nu fram de två alternativen reject md5 clients = yes och reject md5 servers = yes.

Detta innebär att alla kryptografiska komponenter i de olika SMB-nätverksprotokollen som involverar MD5-algoritmen (även om de är teoretiskt säkra, som HMAC-MD5), är förbjudet som standard.

Om du verkligen behöver kan du slå på dem igen för att komma åt specifika servrar i ditt nätverk.

Se bara till att om du skapar undantag som internetstandarder redan officiellt har avrådt från i mer än ett decennium...

…att du bestämmer dig själv ett datum då du äntligen kommer att ta bort dessa icke-standardalternativ för alltid!

Kryptografiska attacker blir bara smartare och snabbare, så lita aldrig på att föråldrade protokoll och algoritmer helt enkelt "inte används längre".

Ta bort dem från din kod helt och hållet, för om de inte finns där alls, KAN du INTE använda dem, och du kan inte luras att använda dem av någon som försöker locka dig in i osäkerhet.

---

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/