Resna varnost: Napaka pri prijavi v Sambo, ki jo povzroča zastarela šifra

Samba, preprosto povedano, je super uporabna, mega priljubljena, odprtokodna ponovna implementacija omrežnih protokolov, ki se uporabljajo v sistemu Microsoft Windows, in njenega zgodovinskega pomena pri medmrežju (povezovanju dveh različnih vrst omrežij skupaj) ni mogoče podcenjevati.

V poznih devetdesetih letih prejšnjega stoletja je Microsoftovo mreženje izgubilo svojo nepregledno, lastniško naravo in postalo odprt standard, znan kot CIFS, okrajšava za skupni internetni datotečni sistem.

Toda v zgodnjih devetdesetih letih prejšnjega stoletja ni bilo nič »običajnega« ali »odprtega«, ko se je avstralski akademik Andrew Tridgell odločil to popraviti z implementacijo združljivega sistema, ki bi mu omogočil povezavo svojega računalnika Unix z omrežjem Windows in obratno.

Takrat se je protokol uradno imenoval SMB, okrajšava za blok sporočil strežnika (ime, ki ga še vedno slišite veliko pogosteje kot CIFS), je Tridge, kot je znan Andrew Tridgell, svoj projekt razumljivo poimenoval »SMBserver«, ker je to tudi bilo.

Toda komercialni izdelek s tem imenom je že obstajal, zato je bil potreben nov vzdevek.

Takrat je projekt postal znan kot Samba, čudovito nepozabno ime, ki je bilo rezultat iskanja besed v slovarju oblike S?M?B?.

Pravzaprav, samba je še vedno prva beseda iz vrat po abecedi v dict običajno najdemo v računalnikih Unix, ki ji sledi precej neprimerna beseda scramble in popolnoma neprimerno scumbag:

Nekatere hrošče narediš, nekaj pa dobiš

V preteklih letih projekt Samba ni samo uvedel in popravil lastnih edinstvenih napak, kot to počne vsak zapleten programski projekt na splošno, ampak je podedoval tudi napake in pomanjkljivosti v osnovnem protokolu, glede na to, da je bil njegov cilj vedno brezhibno delo z omrežji Windows.

(Žal t.i združljivost hroščev je pogosto neizogiben del izgradnje novega sistema, ki deluje z obstoječim.)

Konec leta 2022 je bila najdena ena od teh "podedovanih ranljivosti" in o njej sporočena Microsoftu glede na identifikator CVE-2022-38023, in popravljen v torkovi posodobitvi popravkov novembra 2022.

Ta napaka bi lahko napadalcu omogočila, da spremeni vsebino nekaterih omrežnih podatkovnih paketov, ne da bi bil odkrit, kljub uporabi kriptografskih MAC (kode za preverjanje pristnosti sporočila), namenjeno preprečevanju ponarejanja in poseganja.

Predvsem z manipulacijo podatkov ob prijavi bi lahko zviti kiberkriminalci izvedli napad z dvigom privilegijev (EoP).

Vsaj teoretično bi lahko strežnik pretentali, da je mislil, da je opravil vprašanje »ali imate poverilnice skrbnika?« test, čeprav teh poverilnic niso imeli in njihovi lažni podatki ne bi morali prestati kriptografskega preverjanja.

Kriptografska agilnost

Odločili smo se pisati o tem precej ezoteričnem hrošč nikoli ne reci nikoli), ampak ker je a še en opomnik zakaj kriptografska agilnost je pomembna.

---

---

Skupaj, potrebujemo tako spretnost kot voljo, da za vedno opustimo stare algoritme takoj, ko se ugotovi, da so pomanjkljivi, in jih ne pustiti ležati v nedogled, dokler se ne spremenijo v problem nekoga drugega. (Ta »nekdo drug« se lahko čez deset let izkaže, da smo mi.)

Presenetljivo je, da je ranljivost CVE-2022-38023 sploh obstajala, ker sta Windows in Samba še vedno podpirala slog zaščite integritete, ki je temeljil na dolgo zastarelem algoritmu zgoščevanja MD5.

Preprosto povedano, omrežna avtentikacija z uporabo Microsoftove različice protokola Kerberos je še vedno omogočala zaščito celovitosti podatkov (oz. kontrolna vsota, če uporabim ležeren, a ne strogo natančen žargonski izraz) z uporabo napačne kriptografije.

MD5 ne bi smeli več uporabljati, ker velja za pokvarjenega: odločen napadalec lahko zlahka pride do dveh različnih vnosov, ki se končata z istim zgoščevanjem MD5.

Kot verjetno že veste, pa je ena od zahtev vsakega zgoščevanja, ki zahteva kriptografsko kakovost, ta, da to preprosto ne bi smelo biti mogoče.

V žargonu sta dva vhoda, ki imata enako zgoščeno vrednost, znana kot a trčenje, in naj ne bi bilo programskih trikov ali bližnjic, ki bi vam pomagale hitro najti enega.

Ne bi smelo biti načina, da bi našli kolizijo, ki bi bila boljša od preproste sreče – poskušati znova in znova z nenehno spreminjajočimi se vhodnimi datotekami, dokler ne zadenete glavnega dobitka.

Prava cena trka

Ob predpostavki zanesljivega algoritma brez slabosti, ki bi jih bilo mogoče izkoristiti, bi pričakovali, da bi zgoščena vrednost z X bitov izhoda potrebovala približno 2^X-1 poskuša najti drugi vnos, ki je naletel na zgoščeno vrednost obstoječe datoteke.

Tudi če bi bilo vse, kar bi želeli storiti, to, da bi našli katera koli dva vnosa (dva poljubna vnosa, ne glede na vsebino, velikost ali strukturo), ki bi slučajno imela enako zgoščeno vrednost, bi pričakovali, da boste potrebovali nekaj več kot 2^{X / 2} poskusi, preden naletite na trčenje.

Vsak algoritem zgoščevanja, ki ga je mogoče zanesljivo "razbiti" hitreje kot ta, ni kriptografsko varen, ker ste pokazali, da njegov notranji proces za drobljenje-sekanje-in-mešanje podatkov, ki so vanj vneseni, ne ustvari sploh resnično psevdonaključni rezultat.

Upoštevajte, da kakršen koli postopek vdora, ki je boljši od naključja, tudi če le nekoliko pospeši proces generiranja trka in zato trenutno ne bi predstavljal tveganja, ki bi ga bilo mogoče izkoristiti v resničnem življenju, uniči vero v osnovni kriptografski algoritem, tako da spodkopava njegove trditve o kriptografski pravilnosti .

Če sta 2^X različnih možnih izhodnih vrednosti zgoščevanja, bi upali, da boste dosegli možnost 50:50, da boste našli vnos s specifičnim, vnaprej določenim zgoščevanjem po približno polovici manj poskusov in 2^X/ 2 = 2^X-1. Iskanje katerih koli dveh datotek, ki trčita, je lažje, saj vsakič, ko poskusite z novim vnosom, zmagate, če vaš novi hash trči z kaj prejšnjih vnosov, ki ste jih že poskusili, ker je dovoljen kateri koli par vnosov. Za kolizijo vrste »kateri koli dve datoteki v tem velikanskem vedru bosta zadostni« dosežete možnost uspeha 50:50 le malo več kot kvadratni koren števila možnih zgoščenih vrednosti in √2^X = 2^{X / 2}. Torej bi za 128-bitno zgoščevanje, kot je MD5, pričakovali, da bo v povprečju zgoščeno približno 2¹²⁷ bloki za ujemanje z določeno izhodno vrednostjo in 2⁶⁴ blokov za iskanje katerega koli para trkajočih se vhodov.

Hitri trki MD5 so preprosti

Kot se zgodi, ne morete enostavno ustvariti dveh popolnoma različnih, nepovezanih, psevdonaključnih vnosov, ki imata isto zgoščeno vrednost MD5.

In ne morete se preprosto vrniti nazaj od zgoščene vrednosti MD5, da bi odkrili karkoli o specifičnem vnosu, ki ga je proizvedel, kar je še ena kriptografska obljuba, ki jo mora vzdržati zanesljiva zgoščena vrednost.

Toda če začnete z dvema enakima vhodoma in skrbno vstavite namerno izračunan par kosov za ustvarjanje trkov na isti točki v vsakem vhodnem toku, lahko zanesljivo ustvarite trke MD5 v nekaj sekundah, tudi na skromnem prenosniku.

Na primer, tukaj je program Lua, ki smo ga napisali in ga je mogoče priročno razdeliti na tri ločene dele, od katerih je vsak dolg 128 bajtov.

Obstaja predpona kode, ki se konča z vrstico besedila, ki začne komentar Lua (niz, ki se začne --[== v vrstici 8), potem je 128 bajtov besedila komentarja, ki ga je mogoče zamenjati s poljubnim, ker je prezrto, ko se datoteka izvaja (vrstice 9 do 11), in obstaja kodna pripona 128 bajtov, ki zapre komentar ( začetek niza --]== v vrstici 12) in zaključi program.

Tudi če niste programer, lahko verjetno vidite, da se aktivna koda bere v vsebini [vrstica 14] same datoteke izvorne kode (v Lua je vrednost arg[0] v vrstici 5 je ime skriptne datoteke, ki jo trenutno izvajate), nato pa jo natisne kot šestnajstiški izpis [vrstica 15], ki mu sledi zgoščena vrednost MD5 [vrstica 17]:

Izvajanje datoteke je v bistvu samoopisno in naredi tri 128-bajtne bloke očitne:

Uporaba MD5 raziskovalno orodje se imenuje md5_fastcoll, ki ga je prvotno ustvaril matematik Marc Stevens kot del njegovega magistrskega študija iz kriptografije leta 2007 smo na hitro izdelali dva 128-bajtna kosa »MD5 collision-building«, ki smo ju uporabili za zamenjavo besedila komentarja, prikazanega v zgornji datoteki.

S tem sta bili ustvarjeni dve datoteki, ki obe še vedno delujeta kot prej, ker so spremembe omejene na komentar, ki ne vpliva na izvedljivo kodo v nobeni datoteki.

Vendar se vidno razlikujejo v več bajtih in bi zato morale imeti popolnoma različne zgoščene vrednosti, saj naslednja koda diff (žargon za izpis zaznanih razlik) razkriva.

Zaradi jasnosti smo 128-bajtne dele, ki povzročajo trke in nimajo smisla kot natisljivo besedilo, pretvorili v šestnajstiško:

Zagon obeh pa jasno pokaže, da predstavljata kolizijo zgoščevanja, ker se izkaže, da imata enak izhod MD5:

Raziskana kompleksnost trka

MD5 je 128-bitno zgoščevanje, kot je razvidno iz zgornjih izhodnih nizov.

Torej, kot smo že omenili, pričakujemo, da bomo potrebovali približno 2^128/2Ali 2⁶⁴ poskuša v povprečju povzročiti kolizijo MD5 kakršne koli vrste.

To pomeni obdelavo najmanj približno 18 kvintiljonov zgoščenih blokov MD5, ker 2⁶⁴ = 18,446,744,073,709,551,616.

Pri ocenjeni najvišji stopnji zgoščevanja MD5 približno 50,000,000 blokov/sekundo na našem prenosnem računalniku to pomeni, da bi morali čakati več kot 10,000 let, in čeprav bi dobro financirani napadalci zlahka šli 10,000 do 100,000-krat hitreje od tega, bi tudi oni čakati tedne ali mesece samo na en sam naključni (in ne nujno uporaben) trk.

Vendar pa smo za pripravo zgornjega para dvostranskih datotek Lua, ki imata popolnoma enako zgoščeno vrednost MD5, čeprav očitno nista enaki, potrebovali le nekaj sekund.

Dejansko nam je generiranje 10 različnih kolizij za 10 datotek z uporabo 10 različnih začetnih predpon, ki smo jih izbrali sami, vzelo: 14.9 sekunde, 4.7 sekunde, 2.6 sekunde, 2.1 sekunde, 10.5 sekunde, 2.4 sekunde, 2.0 sekunde, 0.14 sekunde, 8.4 sekunde, in 0.43sek.

Jasno je, da kriptografska obljuba MD5 zagotavlja tisto, kar je znano kot odpornost proti trkom je v osnovi pokvarjen...

... očitno s faktorjem najmanj 25 milijard, na podlagi deljenja povprečnega časa, za katerega bi pričakovali, da bomo čakali, da najdemo trk (na tisoče let, kot je ocenjeno zgoraj), z najslabšim časom, ki smo ga dejansko izmerili (14.9 sekunde) med ustvarjanjem deset različnih trkov samo za ta članek.

Pojasnjena napaka pri preverjanju pristnosti

Kaj pa nevarna uporaba MD5 v CVE-2022-38023?

V psevdokodi v slogu Lua je bila okvarjena koda za preverjanje pristnosti sporočila, uporabljena med prijavami izračunano takole:

Za razlago: kodo za preverjanje pristnosti, ki se uporablja, izračuna hmac.md5() klic funkcije v vrstici 15 z uporabo tako imenovanega a s ključem hash, v tem primeru HMAC-MD5.

Ime HMAC je okrajšava za kriptografska konstrukcija za generiranje kod za preverjanje pristnosti sporočil na podlagi zgoščenosti, pripona -MD5 pa označuje algoritem zgoščevanja, ki ga interno uporablja.

HMAC za izdelavo kode za preverjanje pristnosti sporočila uporablja skrivni ključ v kombinaciji z dvema klicema osnovne zgoščene vrednosti namesto enega:

Ključ ima nekaj svojih bitov najprej obrnjenih in se doda podanim podatkom, preden se začne prvo zgoščevanje.

To močno zmanjša nadzor, ki ga imajo kriptografski krekerji, ko poskušajo izzvati kolizijo ali drugo nenaključno vedenje v procesu zgoščevanja, nad notranjim stanjem zgoščevalne funkcije, ko so doseženi prvi bajti vhodnih podatkov.

Predvsem skrivni ključ preprečuje napadalcem, da začnejo s predpono sporočila po lastni izbiri, kot smo storili v twohash.lua primer zgoraj.

Potem, ko je izračunana prva zgoščevalna vrednost, se ključ obrne z drugačnim naborom bitov, se doda tej prvi zgoščevalni vrednosti in ti novi vhodni podatki se drugič zgostijo.

To napadalcem preprečuje, da bi manipulirali tudi s končnim delom izračuna HMAC, zlasti jim preprečuje, da bi zadnji stopnji postopka zgoščevanja dodali pripono po lastni izbiri.

Dejansko, čeprav sploh ne bi smeli uporabljati MD5, ne poznamo nobenih trenutnih napadov, ki bi lahko zlomili algoritem, ko se uporablja v obliki HMAC-MD5 z naključno izbranim ključem.

Luknja je na sredini

Luknja, ki jo je mogoče izkoristiti v zgornji psevdokodi, torej ni v nobeni od vrstic, kjer hmac.md5() se uporablja funkcija.

Namesto tega je srce napake vrstica 11, kjer so podatki, ki jih želite preveriti, stisnjeni v niz s fiksno dolžino ...

.. s potiskanjem skozi en sam priklic navadnega starega MD5.

Z drugimi besedami, ne glede na to, katero funkcijo HMAC izberete v vrstici 15, in ne glede na to, kako močan in odporen na trke je ta zadnji korak, imate kljub temu možnost povzročiti kolizijo zgoščevanja v vrstici 11.

Preprosto povedano, če poznate podatke, ki naj bi šli v chksum() funkcijo za preverjanje pristnosti in lahko uporabite generator trkov, da poiščete drug blok podatkov z istim hashom MD5 ...

… vrstica 11 pomeni, da boste končali s popolnoma enako vhodno vrednostjo (spremenljivka signdat v psevdokodi) potisnjen v zadnji korak HMAC tako varno kot vam je všeč.

Torej, čeprav na koncu morda uporabljate funkcijo prebave sporočila z močnim ključem, lahko kljub temu preverjate pristnost zgoščene vrednosti MD5, ki je bila pridobljena iz lažnih podatkov.

Manj bi bilo več

Kot pri Sambi varnostni bilten strnjeno opisuje težavo:

Slabost […] je, da se varna kontrolna vsota izračuna kot HMAC-MD5(MD5(DATA),KEY), kar pomeni, da bi aktivni napadalec, ki pozna podatke v navadnem besedilu, lahko ustvaril drugačno izbrano DATA, z isto kontrolno vsoto MD5, in jo nadomesti v tok podatkov, ne da bi bila zaznana.

Ironično, če izpustimo MD5(DATA) del zgornje formule HMAC, za katero se na prvi pogled zdi, da poveča celoten proces "mešanja", bi izboljšal odpornost proti trkom.

Brez tega stiskanja MD5 na sredini bi morali najti kolizijo v samem HMAC-MD5, kar leta 2023 verjetno ni mogoče, tudi s skoraj neomejenim vladnim financiranjem, vsaj ne v času trajanja omrežne seje, ki ste jo poskušali sklepati kompromise.

Kaj je trajalo tako dolgo?

Verjetno se zdaj sprašujete, tako kot mi, zakaj je ta hrošč tako dolgo ostal neodkrit ali vsaj nepopravljen.

Konec koncev, RFC 6151, ki sega prav v leto 2011 in ima pomenljivo zveneč naslov Posodobljeni varnostni vidiki za algoritme MD5 Message-Digest in HMAC-MD5, svetuje takole (naš poudarek, več kot desetletje pozneje):

Zdi se, da napadi na HMAC-MD5 ne kažejo na praktično ranljivost, ko se uporablja kot koda za preverjanje pristnosti sporočila. Zato morda ni nujno odstraniti HMAC-MD5 iz obstoječih protokolov. Vendar od MD5 se ne sme uporabljati za digitalne podpise, za novo zasnovo protokola, šifrirna zbirka s HMAC-MD5 ne sme biti vključena.

Ker pa ima velika večina nedavnih strežniških platform za mala in srednja podjetja izklopljeno preverjanje pristnosti HMAC-MD5, ko se uporabniki poskušajo prijaviti, se zdi, da odjemalci malih in srednjih podjetij, ki še podpirajo ta nevaren način, na splošno nikoli niso uporabili (in bi tako ali tako spodletelo, če bi poskusil).

Zdelo se je, da so odjemalci implicitno »zaščiteni«, nevarna koda pa se je zdela tako dobra kot neškodljiva, ker šibka avtentikacija ni bila niti potrebna niti uporabljena.

Torej morebitni problem preprosto nikoli ni dobil pozornosti, ki bi si jo zaslužil.

Na žalost ta vrsta "varnosti na podlagi predpostavke" popolnoma odpove, če slučajno naletite (ali vas premami) strežnik, ki sprejema to nezanesljivo chksum() algoritem med prijavo.

Ta vrsta "problema znižanja" ni nova: že leta 2015 so raziskovalci izdelali razvpiti FREAK in LOG JAM napade, ki so namenoma preslepili omrežne odjemalce, da so uporabili tako imenovane šifre EXPORT, ki so bili namerno oslabljeni načini šifriranja, pri katerih je ameriška vlada nenavadno vztrajala z zakonom v prejšnjem stoletju.

Kot smo že takrat zapisali:

Dolžine ključev EXPORT so bile v devetdesetih letih prejšnjega stoletja izbrane tako, da jih je skoraj mogoče vdreti, vendar nikoli niso bile podaljšane, da bi sledile napredku v hitrosti procesorja.

To je zato, ker so ZDA približno leta 2000 opustile izvozne šifre.

Že od samega začetka so bili neumna ideja: ameriška podjetja so samo uvozila kriptografsko programsko opremo, ki ni imela nobenih izvoznih omejitev, in škodila lastni industriji programske opreme.

Seveda, ko so zakonodajalci popustili, so šifrirne zbirke EXPORT postale odveč, zato so jih vsi prenehali uporabljati.

Na žalost je veliko kompletov kriptografskih orodij, vključno z OpenSSL in Microsoftovim SChannelom, ohranilo kodo za njihovo podporo, tako da vam (ali, kar je še bolj zaskrbljujoče, dobro obveščenim prevarantom) niso preprečili njihove uporabe.

Tokrat se zdi, da je glavni krivec med strežniki, ki še vedno uporabljajo ta pokvarjen proces MD5-plus-HMAC-MD5, obseg NetApp, v katerem nekaj izdelkov očitno še naprej (ali se je do nedavnega) zanašal na ta tvegan algoritem.

Zato morda še vedno greste skozi ranljiv postopek prijave v omrežje in ste ogroženi zaradi CVE-2022-38023, morda ne da bi se tega sploh zavedali.

Kaj storiti?

Ta hrošč je končno izginil obravnavati, vsaj privzeto, v zadnji izdaji Sambe.

Preprosto povedano, Samba različica 4.17.5 zdaj vsiljuje dve možnosti reject md5 clients = yes in reject md5 servers = yes.

To pomeni, da so vse kriptografske komponente v različnih omrežnih protokolih SMB, ki vključujejo algoritem MD5 (tudi če so teoretično varne, kot je HMAC-MD5), privzeto prepovedano.

Če res potrebujete, jih lahko znova vklopite za dostop do določenih strežnikov v vašem omrežju.

Prepričajte se le, če ustvarite izjeme, ki jih internetni standardi že več kot desetletje uradno odsvetujejo ...

... da si določite datum, do katerega boste končno za vedno umaknili te neprivzete možnosti!

Kriptografski napadi postajajo vedno pametnejši in hitrejši, zato se nikoli ne zanašajte na zastarele protokole in algoritme, ki se preprosto »ne uporabljajo več«.

Popolnoma jih odstranite iz svoje kode, kajti če jih sploh ni, jih NE MORETE uporabiti in vas v njihovo uporabo ne more prevarati nekdo, ki vas skuša zvabiti v negotovost.

---

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• Platoblockchain. Web3 Metaverse Intelligence. Razširjeno znanje. Dostopite tukaj.
• vir: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/