Komoly biztonság: Az elavult titkosítás okozta Samba bejelentkezési hiba

SambaEgyszerűen fogalmazva, a Microsoft Windows rendszerben használt hálózati protokollok rendkívül hasznos, rendkívül népszerű, nyílt forráskódú újraimplementációja, és történelmi jelentőségét az internetezésben (két különböző típusú hálózat összekapcsolása) nem lehet alábecsülni.

Az 1990-es évek végén a Microsoft hálózatkezelése levetkőztette átláthatatlan, szabadalmaztatott természetét, és nyílt szabvánnyá vált, CIFS néven, rövidítésként. közös internetes fájlrendszer.

De nem volt ebben semmi „közös” vagy „nyitott” az 1990-es évek elején, amikor Andrew Tridgell ausztrál akadémikus megpróbálta kijavítani ezt egy olyan kompatibilis rendszer bevezetésével, amely lehetővé tette számára, hogy Unix számítógépét egy Windows hálózathoz csatlakoztassa, és fordítva.

Akkoriban a protokollt hivatalosan SMB-nek nevezték, röviden szerver üzenetblokk (ez a név még mindig sokkal gyakrabban hallható, mint a CIFS), így Tridge, ahogy Andrew Tridgell ismert, érthető módon „SMBserver”-nek nevezte projektjét, mert ez volt az.

De egy ilyen nevű kereskedelmi termék már létezett, ezért új becenévre volt szükség.

Ekkor vált ismertté a projekt Samba, egy elragadóan emlékezetes név, amely a szótárban végzett keresés eredményeként jött létre az ilyen alakú szavakra S?M?B?.

Tény, samba még mindig az első szó a kapun kívül ábécé sorrendben a dict A Unix számítógépeken gyakran megtalálható fájl, amelyet a meglehetősen rosszul illeszkedő szó követ scramble és a teljesen alkalmatlan scumbag:

Néhány hibát elkövet, de néhány hibát kap

Az évek során a Samba projekt nemcsak saját egyedi hibáit vezette be és javította ki, mint általában minden összetett szoftverprojekt, hanem örökölte a mögöttes protokoll hibáit és hiányosságait is, tekintettel arra, hogy célja mindig is az volt, hogy zökkenőmentesen működjön együtt a Windows hálózatokkal.

(Sajnos ún hiba kompatibilitás gyakran elkerülhetetlen része egy új rendszer felépítésének, amely együttműködik egy meglévővel.)

2022 végén az „öröklött sebezhetőségek” egyikét megtalálták, és az azonosító alapján jelentették a Microsoftnak. CVE-2022 38023-, és a 2022. novemberi javítási keddi frissítésben javítva.

Ez a hiba lehetővé tehette a támadó számára, hogy anélkül módosítsa egyes hálózati adatcsomagok tartalmát, hogy észlelték volna, a kriptográfiai MAC-ok használata ellenére (üzenet hitelesítési kódok) célja a hamisítás és manipuláció megakadályozása.

Nevezetesen, ha bejelentkezéskor manipulálják az adatokat, a ravasz kiberbûnözõk privilégium-emelési (EoP) támadást hajthatnak végre.

Elméletileg legalábbis rávehetik a szervert, hogy azt gondolják, hogy átadták a „van rendszergazdai hitelesítő adataid?” tesztet, még akkor is, ha nem rendelkeztek ezekkel a hitelesítő adatokkal, és hamis adataiknak meg kellett volna bukniuk a kriptográfiai ellenőrzésen.

Kriptográfiai mozgékonyság

Nem azért döntöttünk úgy, hogy erről a meglehetősen ezoterikus hibáról írunk, mert úgy gondoljuk, hogy nagy valószínűséggel kihasználják (bár ha a kiberbiztonságról van szó, mi ezt a hozzáállást alkalmazzuk soha ne mond hogy soha), hanem azért, mert ez a még egy emlékeztető hogy miért fontos a kriptográfiai mozgékonyság.

---

---

Együttesen, készségre és akaratra is szükségünk van ahhoz, hogy végleg magunk mögött hagyjuk a régi algoritmusokat mihelyt hibásnak találják őket, és ne hagyd őket a végtelenségig heverni, amíg valaki más problémájává nem válnak. (Lehet, hogy ez a „valaki más” mi vagyunk, tíz év múlva.)

Meglepő módon a CVE-2022-38023 sérülékenység eleve azért létezett, mert mind a Windows, mind a Samba továbbra is támogatta a régóta elavult MD5 kivonatolási algoritmuson alapuló integritásvédelmi stílust.

Egyszerűen fogalmazva, a Kerberos protokoll Microsoft verzióját használó hálózati hitelesítés továbbra is lehetővé tette az adatok integritásvédelmét (vagy ellenőrző összegezve, hogy a hétköznapi, de nem szigorúan pontos szakzsargon kifejezést használjuk) hibás kriptográfia használatával.

Ne használja tovább az MD5-öt, mert töröttnek számít: egy elszánt támadó könnyen előállhat két különböző bemenettel, amelyek végül ugyanazt az MD5-kivonatot kapják.

Amint azonban már valószínűleg tudja, minden olyan hash-nek, amely kriptográfiai minőséget állít, az az egyik követelmény, hogy ez egyszerűen ne legyen lehetséges.

A szakzsargonban két azonos hash-t tartalmazó bemenetet a néven ismerünk ütközés, és állítólag nincsenek olyan programozási trükkök vagy parancsikonok, amelyek segítenének a gyors megtalálásban.

Semmiképpen sem lehet olyan ütközést találni, amely jobb, mint az egyszerű szerencse – újra és újra próbálkozni folyamatosan változó bemeneti fájlokkal, amíg el nem éri a főnyereményt.

Az ütközés valódi ára

Feltételezve egy megbízható algoritmust, kihasználható gyengeségek nélkül, az várható, hogy egy X bites kimenetű hashhez körülbelül 2^X-1 megpróbál találni egy második bemenetet, amely ütközött egy meglévő fájl hash-jével.

Még akkor is, ha csak annyit akart tenni, hogy találjon két olyan bemenetet (két tetszőleges bemenetet, tartalomtól, mérettől vagy szerkezettől függetlenül), amelyeknek véletlenül ugyanaz a hash, akkor is valamivel többre lesz szüksége, mint 2^{X / 2} megpróbálja, mielőtt ütközésbe ütközne.

Bármelyik kivonatolási algoritmus, amely ennél megbízhatóan gyorsabban „feltörhető”, nem kriptográfiailag biztonságos, mert Ön megmutatta, hogy a betáplált adatok aprítására-aprítására-felkeverésére szolgáló belső folyamata nem eredményez valóban pszeudovéletlen eredmény egyáltalán.

Vegye figyelembe, hogy minden esélynél jobb feltörési eljárás, még ha csak kis mértékben gyorsítja is fel az ütközésgenerálási folyamatot, és ezért jelenleg nem jelentene kihasználható kockázatot a való életben, lerombolja a mögöttes kriptográfiai algoritmusba vetett hitet azáltal, hogy aláássa annak kriptográfiai helyességére vonatkozó állításait. .

Ha van 2^X különböző lehetséges hash-kimenetek esetén 50:50-es esélyt szeretne elérni, hogy körülbelül feleannyi próbálkozás után talál egy bemenetet egy adott, előre meghatározott hash-sel, és 2^X/ 2 = 2^X-1. Bármely két ütköző fájl megtalálása egyszerűbb, mert minden alkalommal, amikor új bemenettel próbálkozik, nyer, ha az új hash ütközik bármilyen a korábban már kipróbált bemenetek közül, mert bármely bemenetpár megengedett. A „bármely két fájl ebben az óriási vödörben megfelel” rendezés ütközésekor eléri az 50:50-es siker esélyét a lehetséges kivonatok számának négyzetgyökénél, és √2^X = 2^{X / 2}. Tehát egy 128 bites kivonatnál, mint például az MD5, átlagosan körülbelül 2 kivonat várható.¹²⁷ blokkokat, hogy megfeleljenek egy adott kimeneti értéknek, és 2⁶⁴ blokkokat, hogy megtalálja az ütköző bemenetek párját.

A gyors MD5 ütközések egyszerűvé váltak

Előfordul, hogy nem lehet könnyen létrehozni két teljesen különböző, egymástól független, pszeudovéletlen bemenetet, amelyeknek ugyanaz az MD5 hash.

Egy MD5-kivonattól pedig nem lehet könnyen visszamenni, hogy bármit is felfedjen az azt létrehozó konkrét bemenetről, ami egy újabb kriptográfiai ígéret, amelyet egy megbízható hash-nek be kell tartania.

De ha két azonos bemenettel kezdi, és gondosan beilleszt egy szándékosan kiszámított „ütközés-építő” darabpárt minden bemeneti adatfolyam ugyanazon pontjára, akkor megbízhatóan hozhat létre MD5 ütközéseket másodpercek alatt, még egy szerény laptopon is.

Például itt van egy általunk írt Lua program, amely kényelmesen három különálló, 128 bájt hosszúságú részre osztható.

Van egy kódelőtag, amely egy szövegsorral végződik, amely egy Lua megjegyzést kezd (a karakterlánc kezdete --[== a 8. sorban), akkor van 128 bájtnyi megjegyzésszöveg, amit bármire lecserélhetünk, amit szeretünk, mert a rendszer figyelmen kívül hagyja a fájl futtatásakor (9-11. sor), és van egy 128 bájtos kódutótag, amely bezárja a megjegyzést (a húrkezdés --]== a 12. sorban), és befejezi a programot.

Még ha nem is programozó, valószínűleg láthatja, hogy az aktív kód magának a forráskódfájlnak a tartalmában [14. sor] olvasható (Lua-ban az érték arg[0] az 5. sorban az éppen futó szkriptfájl neve), majd kiírja hexadecimális kiíratásként [sor 15] , majd az MD5 hash [sor 17]:

A fájl futtatása lényegében önleíró jellegű, és nyilvánvalóvá teszi a három 128 bájtos blokkot:

MD5 használata kutatási eszköz hívott md5_fastcoll, eredetileg matematikus készítette Marc Stevens a 2007-es kriptográfiai mesterképzés részeként gyorsan elkészítettünk két 128 bájtos „MD5 ütközést építő” darabot, amelyeket a fenti fájlban látható megjegyzésszöveg helyettesítésére használtunk.

Ez két fájlt hozott létre, amelyek továbbra is ugyanúgy működnek, mint korábban, mert a módosítások a megjegyzésre korlátozódnak, ami nincs hatással egyik fájlban a végrehajtható kódra.

De láthatóan különböznek több bájtban, ezért teljesen eltérő hash értékekkel kell rendelkezniük, mint a következő kódkülönbség (zsargon észlelt eltérések kidobása) kiderül.

A 128 bájtos ütközést létrehozó darabokat, amelyeknek nincs értelme nyomtatható szövegként, hexadecimálisra alakítottuk át az érthetőség kedvéért:

Mindkettő futtatása azonban egyértelműen megmutatja, hogy hash ütközést jelentenek, mivel kiderül, hogy ugyanaz az MD5 kimenet:

Az ütközés bonyolultsága feltárva

Az MD5 egy 128 bites hash, amint azt a fenti kimeneti karakterláncok egyértelművé teszik.

Tehát, mint korábban említettük, körülbelül 2-re számítunk^128/2Vagy 2⁶⁴ átlagosan megpróbál bármilyen MD5 ütközést előidézni.

Ez azt jelenti, hogy legalább 18 kvintimillió MD5 hash blokkot kell feldolgozni, mert 2⁶⁴ = 18,446,744,073,709,551,616.

A laptopunkon a becslések szerint 5 50,000,000 10,000 blokk/másodperc MD10,000-ös hash csúcssebessége azt jelenti, hogy több mint 100,000 XNUMX évet kell várnunk, és bár a jól finanszírozott támadók könnyen XNUMX XNUMX-XNUMX XNUMX-szer gyorsabban haladnának, még ők is megtennék. heteket vagy hónapokat kell várni, hogy csak egyetlen véletlenszerű (és nem feltétlenül hasznos) ütközés forduljon elő.

Ám a fenti kétoldalas Lua fájlpár, amelyek pontosan ugyanazt az MD5 hash-t tartalmazzák, annak ellenére, hogy nyilvánvalóan nem azonosak, mindössze néhány másodpercbe telt, mire felkészültünk.

Valójában 10 különböző ütközést generáltunk 10 fájlhoz, 10 különböző kezdő előtagot használva, amelyeket magunk választottunk: 14.9 mp, 4.7 mp, 2.6 mp, 2.1 mp, 10.5 mp, 2.4 mp, 2.0 mp, 0.14 mp. és 8.4 mp.

Nyilvánvaló, hogy az MD5 kriptográfiai ígérete, hogy az ún ütközésállóság alapjaiban megtört…

…nyilvánvalóan legalább 25 milliárdos szorzóval, annak alapján, hogy elosztjuk azt az átlagos időt, amelyet az ütközés megtalálására várnunk kell (több ezer év, a fenti becslések szerint) a ténylegesen mért legrosszabb idővel (14.9 másodperc) tíz különböző ütközés csak ehhez a cikkhez.

A hitelesítési hiba magyarázatot ad

De mi a helyzet az MD5 nem biztonságos használatával a CVE-2022-38023-ban?

A Lua-stílusú pszeudokódban a bejelentkezés során használt hibás üzenet-hitelesítési kód az volt így számolva:

Magyarázatként: a használt hitelesítési kódot a hmac.md5() függvényhívás a 15. sorban, az úgynevezett a kulcsos hash, jelen esetben a HMAC-MD5.

A HMAC név rövidítése kriptográfiai konstrukció hash alapú üzenet-hitelesítési kódok generálására, az -MD5 utótag pedig a belsőleg használt kivonatolási algoritmust jelöli.

A HMAC egy titkos kulcsot használ az alapul szolgáló hash két meghívásával kombinálva egy helyett az üzenet hitelesítési kódjának előállításához:

A kulcs néhány bitje először átfordul, és az első hash megkezdése előtt hozzáfűződik a megadott adatokhoz.

Ez nagymértékben csökkenti a kriptográfiai feltörők által birtokolt irányítást, amikor ütközést vagy más nem véletlenszerű viselkedést próbálnak kiváltani a kivonatolási folyamatban, a hash függvény belső állapota felett, amikor a bemeneti adatok első bájtjait elérik.

Nevezetesen, a titkos kulcs megakadályozza, hogy a támadók saját maguk által választott üzenet-előtaggal kezdjenek, ahogyan azt a twohash.lua példa fent.

Ezután az első hash kiszámítása után a kulcs egy másik bitkészletet fordít át, az első hash-érték elé kerül, és az új bemeneti adatot másodszor is kivonatolja.

Ez megakadályozza, hogy a támadók manipulálják a HMAC-számítás utolsó részét, és különösen megakadályozzák, hogy saját maguk által választott utótagot fűzzenek a kivonatolási folyamat utolsó szakaszához.

Valójában annak ellenére, hogy egyáltalán nem kellene MD5-öt használnia, nem tudunk olyan jelenlegi támadásokról, amelyek megtörhetik az algoritmust, ha véletlenszerűen kiválasztott kulccsal HMAC-MD5 formában használják.

A lyuk a közepén van

Ezért a fenti pszeudokódban lévő kihasználható lyuk nincs abban a sorban sem, ahol a hmac.md5() funkciót használják.

Ehelyett a hiba szíve a 11. sor, ahol a hitelesíteni kívánt adatokat egy rögzített hosszúságú karakterláncba tömörítik…

.. a sima régi MD5 egyetlen meghívásával.

Más szóval, függetlenül attól, hogy melyik HMAC funkciót választja a 15. sorban, és bármilyen erős és ütközésálló is legyen az utolsó lépés, ennek ellenére megvan az esélye, hogy hash ütközést okozzon a 11. sorban.

Egyszerűen fogalmazva, ha ismeri az adatokat, amelyeknek be kell kerülniük a chksum() funkciót kell hitelesíteni, és ütközésgenerátorral kereshet egy másik adatblokkot ugyanazzal az MD5-kivonattal…

…a 11. sor azt jelenti, hogy a végén te leszel pontosan ugyanazzal a bemeneti értékkel (a változó signdat a pszeudokódban) az olyan biztonságos, ahogy tetszik utolsó HMAC-lépésbe kerül.

Ezért, bár a végén erős kulcsú üzenetkivonat funkciót használ, előfordulhat, hogy hitelesít egy MD5 hash-t, amely csaló adatokból származott.

A kevesebb több lett volna

Mint Sambáé biztonsági közlemény tömören leírja a problémát:

A gyengeség […] az, hogy a biztonságos ellenőrző összeget a következőképpen számítják ki HMAC-MD5(MD5(DATA),KEY), ami azt jelenti, hogy egy aktív támadó, aki ismeri az egyszerű szöveges adatokat, létrehozhat egy másik kiválasztott DATA, ugyanazzal az MD5 ellenőrzőösszeggel, és helyettesítse be az adatfolyamba anélkül, hogy észlelné.

Ironikus módon, kihagyva a MD5(DATA) A fenti HMAC képlet egy része, amely első pillantásra úgy tűnik, hogy növeli az általános „keverési” folyamatot, javítaná az ütközésállóságot.

A középen lévő MD5-ös tömörítés nélkül ütközést kellene találnia magában a HMAC-MD5-ben, ami valószínűleg nem lehetséges 2023-ban, még csaknem korlátlan állami finanszírozás mellett sem, legalábbis nem a megpróbált hálózati munkamenet élettartamán belül. kompromisszumot kötni.

Mi tartott ilyen sokáig?

Mostanra valószínűleg Ön is azon töpreng, akárcsak mi, vajon miért maradt ez a hiba olyan sokáig felfedezetlenül, vagy legalábbis foltozatlanul.

Végül is, RFC 6151, amely egészen 2011-ig nyúlik vissza, és a jelentőségteljes címet viseli Frissített biztonsági szempontok az MD5 Message-Digest és a HMAC-MD5 algoritmusokhoz, a következőket tanácsolja (kiemelésünk, több mint egy évtizeddel később):

Úgy tűnik, hogy a HMAC-MD5 elleni támadások nem jelentenek gyakorlati sebezhetőséget, ha üzenet-hitelesítési kódként használják őket. Ezért előfordulhat, hogy nem sürgős a HMAC-MD5 eltávolítása a meglévő protokollokból. Mivel azonban az MD5 nem használható digitális aláírásra, egy új protokoll kialakításhoz, a HMAC-MD5 titkosítási csomagot nem szabad beletenni.

Úgy tűnik azonban, hogy mivel a legújabb SMB-kiszolgálóplatformok túlnyomó többségében a HMAC-MD5 hitelesítés ki van kapcsolva, amikor a felhasználók megpróbálnak bejelentkezni, az SMB-kliensek, amelyek továbbra is támogatják ezt a nem biztonságos módot, általában soha nem használták (és egyébként is meghiúsultak volna, ha megpróbálta).

A kliensek implicit módon „védettnek” tűntek, a nem biztonságos kód pedig ártalmatlannak tűnt, mert a gyenge hitelesítésre se szükség, se nem volt szükség.

Így a lehetséges probléma egyszerűen soha nem kapta meg a megérdemelt figyelmet.

Sajnos ez a fajta „feltevés szerinti biztonság” teljesen meghiúsul, ha véletlenül olyan szerverrel találkozik (vagy elcsábítja), amely elfogadja ezt a nem biztonságos chksum() algoritmus bejelentkezéskor.

Ez a fajta „leminősítési probléma” nem új keletű: még 2015-ben a kutatók kitalálták a hírhedt FREAK és a SZÁLFATORLÓDÁS FOLYÓN támadások, amelyek szándékosan rávetették a hálózati klienseket az úgynevezett EXPORT titkosítások használatára, amelyek azok a szándékosan meggyengített titkosítási módok, amelyekhez az Egyesült Államok kormánya a múlt században a törvényben bizarr módon ragaszkodott.

Ahogy akkor írtuk:

Az EXPORT kulcshosszakat úgy választották ki, hogy az 1990-es években feltörhetőek legyenek, de soha nem hosszabbították meg, hogy lépést tartsanak a processzor sebességének fejlődésével.

Ennek az az oka, hogy az Egyesült Államok körülbelül 2000-ben felhagyott az exportrejtjelekkel.

Kezdettől fogva ostoba ötlet volt: az amerikai cégek csak olyan kriptográfiai szoftvereket importáltak, amelyekre nem vonatkoztak exportkorlátozások, és kárt tettek a saját szoftveriparukban.

Természetesen, miután a törvényhozók megadták magukat, az EXPORT titkosítási csomagok feleslegessé váltak, így mindenki felhagyott velük.

Sajnos sok kriptográfiai eszközkészlet, köztük az OpenSSL és a Microsoft SChannel, megtartotta a kódot, hogy támogassa őket, így Önt (vagy ami még aggasztóbb, jól tájékozott csalókat) nem akadályozták meg a használatukban.

Ezúttal úgy tűnik, a fő bűnös azon szerverek között, amelyek még mindig ezt a törött MD5-plus-HMAC-MD5 folyamatot használják, a NetApp tartomány, amelyben egyes termékek láthatóan továbbra is (vagy egészen a közelmúltig) erre a kockázatos algoritmusra hagyatkozik.

Ezért előfordulhat, hogy néha még mindig egy sérülékeny hálózati bejelentkezési folyamaton megy keresztül, és veszélybe kerülhet a CVE-2022-38023 miatt, talán anélkül, hogy észrevenné.

Mit kell tenni?

Ez a hiba végre megjelent foglalkoztak, legalábbis alapértelmezés szerint a Samba legújabb kiadásában.

Egyszerűen fogalmazva, Samba 4.17.5 verzió most kikényszeríti a két lehetőséget reject md5 clients = yes és a reject md5 servers = yes.

Ez azt jelenti, hogy a különböző SMB hálózati protokollok minden kriptográfiai összetevője, amely magában foglalja az MD5 algoritmust (még akkor is, ha elméletileg biztonságos, mint például a HMAC-MD5), alapértelmezés szerint tiltva.

Ha valóban szüksége van rá, újra bekapcsolhatja őket, hogy elérjék a hálózat adott szervereit.

Csak győződjön meg róla, ha olyan kivételeket hoz létre, amelyeket az internetes szabványok már több mint egy évtizede hivatalosan elleneztek…

…hogy kitűzz magadnak egy dátumot, amikorra végleg visszavonod ezeket a nem alapértelmezett opciókat!

A kriptográfiai támadások csak egyre intelligensebbek és gyorsabbak, ezért soha ne hagyatkozz az elavult protokollokra és algoritmusokra, amelyeket egyszerűen „nem használnak többé”.

Teljesen töröld ki őket a kódodból, mert ha egyáltalán nincsenek ott, akkor NEM HASZNÁLHATJA őket, és nem csalhat meg valaki, aki bizonytalanságba akar csalni.

---

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. Hozzáférés itt.
• Forrás: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/