Seriøs sikkerhet: Samba-påloggingsfeilen forårsaket av utdatert krypto

Samba, enkelt sagt, er en supernyttig, megapopulær, åpen kildekode-reimplementering av nettverksprotokollene som brukes i Microsoft Windows, og dens historiske betydning i internettarbeid (kobler to forskjellige typer nettverk sammen) kan ikke undervurderes.

På slutten av 1990-tallet mistet Microsofts nettverk sin ugjennomsiktige, proprietære natur og ble en åpen standard kjent som CIFS, forkortelse for felles internett filsystem.

Men det var ingenting "vanlig" eller "åpent" med det på begynnelsen av 1990-tallet, da den australske akademikeren Andrew Tridgell satte seg fore å rette opp dette ved å implementere et kompatibelt system som ville la ham koble Unix-datamaskinen sin til et Windows-nettverk, og omvendt.

Den gang ble protokollen offisielt referert til som SMB, en forkortelse for server meldingsblokk (et navn som du fremdeles hører mye oftere enn CIFS), så Tridge, som Andrew Tridgell er kjent, kalte forståelig nok prosjektet sitt "SMBserver", fordi det var det det var.

Men et kommersielt produkt med det navnet eksisterte allerede, så en ny moniker var nødvendig.

Det var da prosjektet ble kjent som Samba, et herlig minneverdig navn som ble resultatet av et ordboksøk etter ord i formen S?M?B?.

Faktisk, samba er fortsatt det første ordet ut av porten alfabetisk i dict fil som vanligvis finnes på Unix-datamaskiner, etterfulgt av det ganske dårlige ordet scramble og det totalt upassende scumbag:

Noen feil lager du, men noen feil får du

Gjennom årene har Samba-prosjektet ikke bare introdusert og fikset sine egne unike feil, slik ethvert komplekst programvareprosjekt vanligvis gjør, men også arvet feil og mangler i den underliggende protokollen, gitt at målet alltid har vært å jobbe sømløst med Windows-nettverk.

(Dessverre, såkalt bug kompatibilitet er ofte en uunngåelig del av å bygge et nytt system som fungerer med et eksisterende.)

Sent i 2022 ble en av disse "arvede sårbarhetene" funnet og rapportert til Microsoft, gitt identifikatoren CVE-2022-38023, og oppdatering i november 2022 Patch Tuesday-oppdateringen.

Denne feilen kunne ha tillatt en angriper å endre innholdet i enkelte nettverksdatapakker uten å bli oppdaget, til tross for bruk av kryptografiske MAC-er (meldingsautentiseringskoder) beregnet på å forhindre forfalskning og tukling.

Spesielt ved å manipulere data ved pålogging, kan utspekulerte nettkriminelle utføre et elevation-of-privilege (EoP) angrep.

De kunne i det minste i teorien lure en server til å tro at de hadde bestått "har du administratorlegitimasjon?" test, selv om de ikke hadde denne legitimasjonen og deres falske data burde ha mislyktes i kryptografisk verifisering.

Kryptografisk smidighet

Vi bestemte oss for å skrive om denne ganske esoteriske feilen, ikke fordi vi tror du er veldig sannsynlig å bli utnyttet av den (men når det kommer til cybersikkerhet, tar vi holdningen aldri si aldri), men fordi det er en enda en påminnelse av hvorfor kryptografisk smidighet er viktig.

---

---

Samlet sett, vi trenger både dyktighet og vilje til å legge igjen gamle algoritmer for alltid så snart de viser seg å være defekte, og ikke la dem ligge på ubestemt tid før de blir til noen andres problem. (At "noen andre" kan godt vise seg å være oss, ti år senere.)

Forbløffende nok eksisterte CVE-2022-38023-sårbarheten i utgangspunktet fordi både Windows og Samba fortsatt støttet en stil med integritetsbeskyttelse basert på den lenge utdaterte hashing-algoritmen MD5.

Enkelt sagt, nettverksautentisering ved bruk av Microsofts versjon av Kerberos-protokollen tillot fortsatt data å bli integritetsbeskyttet (eller sjekksummet, for å bruke det tilfeldige, men ikke strengt nøyaktige sjargongbegrepet) ved bruk av feilaktig kryptografi.

Du bør ikke bruke MD5 lenger fordi den anses som ødelagt: en målbevisst angriper kan lett komme opp med to forskjellige innganger som ender opp med samme MD5-hash.

Som du sikkert allerede vet, er imidlertid et av kravene til enhver hash som hevder kryptografisk kvalitet at dette rett og slett ikke burde være mulig.

I sjargongen er to innganger som har samme hash kjent som en kollisjon, og det er ikke ment å være noen programmatiske triks eller snarveier for å hjelpe deg med å finne en raskt.

Det bør ikke være noen måte å finne en kollisjon som er bedre enn lykke til – prøv igjen og igjen med stadig skiftende inndatafiler til du treffer jackpotten.

Den sanne kostnaden for en kollisjon

Forutsatt en pålitelig algoritme, uten utnyttbare svakheter, forventer du at en hash med X bits utdata vil trenge ca. 2^X-1 prøver å finne en annen inngang som kolliderte med hashen til en eksisterende fil.

Selv om alt du ønsket å gjøre var å finne to inndata (to vilkårlige innganger, uavhengig av innhold, størrelse eller struktur) som tilfeldigvis hadde samme hash, ville du forvente å trenge litt mer enn 2^{X / 2} prøver før du treffer en kollisjon.

Enhver hashing-algoritme som pålitelig kan "knekkes" raskere enn det, er ikke kryptografisk sikker, fordi du har vist at dens interne prosess for å makulere-hakke-og røre opp dataene som mates inn i den, ikke produserer en virkelig pseudorandom resultat i det hele tatt.

Legg merke til at enhver cracking-prosedyre som er bedre enn sjansen, selv om den bare øker hastigheten på kollisjonsgenereringsprosessen litt og derfor ikke for øyeblikket vil være en utnyttbar risiko i det virkelige liv, ødelegger troen på den underliggende kryptografiske algoritmen ved å undergrave dens påstander om kryptografisk korrekthet .

Hvis det er 2^X forskjellige mulige hash-utganger, håper du å treffe en 50:50 sjanse for å finne en inngang med en spesifikk, forhåndsbestemt hash etter omtrent halvparten så mange forsøk, og 2^X/ 2 = 2^X-1. Det er lettere å finne to filer som kolliderer, fordi hver gang du prøver en ny inngang, vinner du hvis den nye hasjen din kolliderer med noen av de tidligere inngangene du allerede har prøvd, fordi alle inngangspar er tillatt. For en kollisjon av typen «hvilken som helst to filer i denne gigantiske bøtten vil duge», treffer du 50:50 sjansen for å lykkes med bare litt mer enn kvadratroten av antall mulige hashes, og √2^X = 2^{X / 2}. Så, for en 128-bits hash som MD5, forventer du i gjennomsnitt å hash omtrent 2¹²⁷ blokker for å matche en spesifikk utgangsverdi, og 2⁶⁴ blokkerer for å finne et par kolliderende innganger.

Raske MD5-kollisjoner gjort enkelt

Som det skjer, kan du ikke enkelt generere to helt forskjellige, urelaterte, pseudotilfeldige innganger som har samme MD5-hash.

Og du kan ikke enkelt gå bakover fra en MD5-hash for å avdekke noe om den spesifikke inngangen som produserte den, som er et annet kryptografisk løfte som en pålitelig hash må holde.

Men hvis du starter med to identiske innganger og forsiktig setter inn et bevisst beregnet par "kollisjonsbyggende" biter på samme punkt i hver inngangsstrøm, kan du pålitelig lage MD5-kollisjoner på sekunder, selv på en beskjeden bærbar datamaskin.

For eksempel, her er et Lua-program vi skrev som enkelt kan kuttes i tre forskjellige seksjoner, hver 128 byte lang.

Det er et kodeprefiks som slutter med en tekstlinje som starter en Lua-kommentar (strengen som starter --[== i linje 8), så er det 128 byte med kommentartekst som kan erstattes med alt vi liker, fordi den ignoreres når filen kjøres (linje 9 til 11), og det er et kodesuffiks på 128 byte som lukker kommentaren (den streng starter --]== i linje 12) og avslutter programmet.

Selv om du ikke er en programmerer, kan du sannsynligvis se at den aktive koden leser innholdet [linje 14] i selve kildekodefilen (i Lua, verdien arg[0] på linje 5 er navnet på skriptfilen du kjører for øyeblikket), skriver den ut som en hex-dump [linje 15] , etterfulgt av MD5-hash [linje 17]:

Å kjøre filen er i hovedsak selvbeskrivende, og gjør de tre 128-byte blokkene åpenbare:

Bruker en MD5 forskningsverktøy som heter md5_fastcoll, opprinnelig laget av matematiker Marc Stevens som en del av hans mastergrad i kryptografi tilbake i 2007, produserte vi raskt to 128-byte «MD5 kollisjonsbyggende»-biter som vi brukte til å erstatte kommentarteksten vist i filen ovenfor.

Dette skapte to filer som begge fortsatt fungerer som de gjorde før, fordi endringene er begrenset til kommentaren, som ikke påvirker den kjørbare koden i noen av filene.

Men de er synlig forskjellige i flere byte, og bør derfor ha helt forskjellige hash-verdier, da følgende kodediff (sjargong for dump av oppdagede forskjeller) avslører.

Vi har konvertert de 128-byte kollisjonsskapende delene, som ikke gir mening som utskrivbar tekst, til heksadesimal for klarhetens skyld:

Å kjøre dem begge viser imidlertid tydelig at de representerer en hash-kollisjon, fordi de viser seg å ha samme MD5-utgang:

Kollisjonskompleksitet utforsket

MD5 er en 128-bits hash, som utgangsstrengene ovenfor tydeliggjør.

Så, som nevnt før, forventer vi å trenge omtrent 2^128/2, Eller 2⁶⁴ prøver i gjennomsnitt for å produsere en MD5-kollisjon av noe slag.

Det betyr å behandle et minimum på omtrent 18 kvintillioner MD5-hashblokker, fordi 2⁶⁴ = 18,446,744,073,709,551,616.

Med en estimert topp MD5-hash rate på rundt 50,000,000 10,000 10,000 blokker/sekund på den bærbare datamaskinen vår, betyr det at vi må vente i mer enn 100,000 XNUMX år, og selv om velfinansierte angripere lett kan gå XNUMX XNUMX til XNUMX XNUMX ganger raskere enn det, ville selv de vente uker eller måneder bare på at en enkelt tilfeldig (og ikke nødvendigvis nyttig) kollisjon skal dukke opp.

Likevel tok paret ovenfor med tosidige Lua-filer, som har nøyaktig samme MD5-hash til tross for at de helt tydelig ikke er identiske, oss bare noen få sekunder å forberede.

Faktisk, å generere 10 forskjellige kollisjoner for 10 filer, ved å bruke 10 forskjellige startprefikser som vi valgte selv, tok 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, og 0.43 sek.

Det er klart at MD5s kryptografiske lover å gi det som er kjent som kollisjonsmotstand er fundamentalt ødelagt...

…tilsynelatende med en faktor på minst 25 milliarder, basert på å dele den gjennomsnittlige tiden vi forventer å vente på å finne en kollisjon (tusenvis av år, som estimert ovenfor) med den verste tiden vi faktisk målte (14.9 sekunder) mens vi kjørte ut ti forskjellige kollisjoner bare for denne artikkelen.

Autentiseringsfeilen forklart

Men hva med den usikre bruken av MD5 i CVE-2022-38023?

I Lua-stil pseudokode var den defekte meldingsautentiseringskoden som ble brukt under pålogginger regnet slik:

For å forklare: autentiseringskoden som brukes, beregnes av hmac.md5() funksjonsanrop i linje 15, ved å bruke det som er kjent som en tastet hasj, i dette tilfellet HMAC-MD5.

Navnet HMAC er en forkortelse for kryptografisk konstruksjon for å generere hash-baserte meldingsautentiseringskoder, og -MD5-suffikset angir hashing-algoritmen den bruker internt.

HMAC bruker en hemmelig nøkkel, kombinert med to påkallelser av den underliggende hashen, i stedet for bare én, for å produsere meldingsautentiseringskoden:

Nøkkelen har noen av bitene snudd først, og blir lagt til de leverte dataene før den første hashen starter.

Dette reduserer i stor grad kontrollen som kryptografiske crackere har, når de prøver å provosere frem en kollisjon eller annen ikke-tilfeldig oppførsel i hash-prosessen, over den interne tilstanden til hash-funksjonen når de første bytene av inndataene er nådd.

Spesielt forhindrer den hemmelige nøkkelen angripere fra å starte med et meldingsprefiks etter eget valg, slik vi gjorde i twohash.lua eksempel ovenfor.

Så, når den første hashen er beregnet, har nøkkelen et annet sett med biter snudd, blir satt foran den første hash-verdien, og disse nye inngangsdataene hashes en gang til.

Dette forhindrer angriperne i å manipulere den siste delen av HMAC-beregningen, spesielt forhindrer dem i å legge til et suffiks etter eget valg til den siste fasen av hashing-prosessen.

Faktisk, selv om du ikke burde bruke MD5 i det hele tatt, er vi ikke klar over noen aktuelle angrep som kan bryte algoritmen når den brukes i HMAC-MD5-form med en tilfeldig valgt nøkkel.

Hullet er i midten

Det utnyttbare hullet i pseudokoden ovenfor er derfor ikke i noen av linjene der hmac.md5() funksjonen brukes.

I stedet er hjertet av feilen linje 11, der dataene du vil autentisere komprimeres til en streng med fast lengde ...

.. ved å skyve den gjennom en enkelt påkalling av vanlig gammel MD5.

Med andre ord, uansett hvilken HMAC-funksjon du velger i linje 15, og uansett hvor sterk og kollisjonsbestandig det siste trinnet måtte være, har du likevel en sjanse til å forårsake en hash-kollisjon på linje 11.

Enkelt sagt, hvis du vet dataene som skal gå inn i chksum() funksjon som skal autentiseres, og du kan bruke en kollisjonsgenerator for å finne en annen blokk med data med samme MD5-hash ...

…linje 11 betyr at du ender opp med nøyaktig samme inngangsverdi (variabelen signdat i pseudokoden) blir skjøvet inn i det siste HMAC-trinnet så sikkert som du liker.

Derfor, selv om du kanskje bruker en sterk nøkkelfunksjon for meldingssammendrag på slutten, kan du likevel autentisere en MD5-hash som ble avledet fra bedragerdata.

Mindre ville vært mer

Som Samba sine sikkerhetsbulletin beskriver kompakt problemet:

Svakheten […] er at den sikre sjekksummen beregnes som HMAC-MD5(MD5(DATA),KEY), noe som betyr at en aktiv angriper som kjenner klartekstdataene kan lage en annen valgt DATA, med den samme MD5-sjekksummen, og sett den inn i datastrømmen uten å bli oppdaget.

Ironisk nok, utelate MD5(DATA) en del av HMAC-formelen ovenfor, som ved første øyekast ser ut til å øke den generelle "blandings"-prosessen, vil forbedre kollisjonsmotstanden.

Uten den MD5-komprimeringen i midten, ville du måtte finne en kollisjon i selve HMAC-MD5, noe som sannsynligvis ikke er mulig i 2023, selv med nesten ubegrenset statlig finansiering, i hvert fall ikke innenfor levetiden til nettverksøkten du prøvde på å gå på akkord.

Hva tok så lang tid?

Nå lurer du sikkert på, som vi var, hvorfor denne feilen lå uoppdaget, eller i det minste uopprettet, så lenge.

Tross alt, RFC 6151, som dateres helt tilbake til 2011, og har den betydelig klingende tittelen Oppdaterte sikkerhetshensyn for MD5 Message-Digest og HMAC-MD5-algoritmene, råder som følger (vår vektlegging, mer enn et tiår senere):

Angrepene på HMAC-MD5 ser ikke ut til å indikere en praktisk sårbarhet når de brukes som en meldingsautentiseringskode. Derfor kan det hende det ikke haster å fjerne HMAC-MD5 fra de eksisterende protokollene. Men siden MD5 må ikke brukes til digitale signaturer, for en ny protokolldesign, en chiffersuite med HMAC-MD5 skal ikke inkluderes.

Det ser imidlertid ut til at det store flertallet av nyere SMB-serverplattformer har HMAC-MD5-autentisering slått av når brukere prøver å logge seg på, at SMB-klienter som fortsatt støtter denne usikre modusen, vanligvis aldri har brukt den (og ville ha mislyktes uansett hvis de hadde prøvd).

Klienter så implisitt ut til å være "beskyttet", og den usikre koden så ut til å være så godt som ufarlig, fordi den svake autentiseringen verken var nødvendig eller brukt.

Så det potensielle problemet fikk rett og slett aldri den oppmerksomheten det fortjente.

Dessverre mislykkes denne typen "sikkerhet ved antagelse" fullstendig hvis du tilfeldigvis kommer over (eller blir lokket mot) en server som godtar dette usikre chksum() algoritme under pålogging.

Denne typen "nedgraderingsproblem" er ikke ny: tilbake i 2015 utviklet forskere det beryktede FREAK og LOGGJAM angrep, som bevisst lurte nettverksklienter til å bruke såkalte EKSPORT-chiffer, som var de bevisst svekkede krypteringsmodusene som den amerikanske regjeringen bisarrt nok insisterte på ved lov forrige århundre.

Som vi skrev den gang:

EXPORT-nøkkellengdene ble valgt til å være omtrent knekkebare på 1990-tallet, men ble aldri utvidet for å holde tritt med fremskritt i prosessorhastighet.

Det er fordi eksportchiffer ble forlatt av USA rundt 2000.

De var en dum idé fra starten: amerikanske selskaper importerte nettopp kryptografisk programvare som ikke hadde noen eksportrestriksjoner, og skadet deres egen programvareindustri.

Selvfølgelig, når lovgiverne ga etter, ble EKSPORT-chiffersuitene overflødige, så alle sluttet å bruke dem.

Dessverre beholdt mange kryptografiske verktøysett, inkludert OpenSSL og Microsofts SChannel, koden for å støtte dem, så du (eller, mer bekymringsverdig, velinformerte kjeltringer) ble ikke stoppet fra å bruke dem.

Denne gangen ser det ut til at hovedsynderen blant servere som fortsatt bruker denne ødelagte MD5-pluss-HMAC-MD5-prosessen er NetApp-serien, der noen produkter tilsynelatende fortsette (eller gjorde inntil nylig) å stole på denne risikable algoritmen.

Derfor kan du fortsatt noen ganger gå gjennom en sårbar nettverkspåloggingsprosess, og være i faresonen fra CVE-2022-38023, kanskje uten å være klar over det.

Hva gjør jeg?

Denne feilen har endelig vært tatt hånd om, i det minste som standard, i den siste utgivelsen av Samba.

Enkelt sagt, Samba versjon 4.17.5 fremtvinger nå de to alternativene reject md5 clients = yes og reject md5 servers = yes.

Dette betyr at alle kryptografiske komponenter i de forskjellige SMB-nettverksprotokollene som involverer MD5-algoritmen (selv om de er teoretisk sikre, som HMAC-MD5), er forbudt som standard.

Hvis du virkelig trenger det, kan du slå dem på igjen for å få tilgang til bestemte servere i nettverket ditt.

Bare sørg for at hvis du oppretter unntak som internettstandarder allerede offisielt har frarådet i mer enn et tiår...

…at du setter deg selv en dato da du endelig vil trekke deg tilbake de ikke-standardalternativene for alltid!

Kryptografiske angrep blir bare smartere og raskere, så stol aldri på at utdaterte protokoller og algoritmer rett og slett «ikke blir brukt lenger».

Strip dem helt ut av koden din, for hvis de ikke er der i det hele tatt, KAN du IKKE bruke dem, og du kan ikke bli lurt til å bruke dem av noen som prøver å lokke deg ut i usikkerhet.

---

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/