Összefoglaló
A CVE-2025-50154 egy Windows File Explorer sebezhetőség, amely érzékeny hitelesítési adatokat tehet közzé a hálózaton. A Microsoft a problémát spoofingként osztályozza, az alapjául szolgáló gyengeséget pedig a CWE-200 (érzékeny információk közzététele) kategóriába sorolja .
Az érintett konfigurációkban a Windows Intéző hálózati hitelesítést indíthat el a parancsikonokkal kapcsolatos metaadatok feldolgozása közben. Ha a hivatkozott távoli célpont támadó által ellenőrzött, a támadó elfoghatja az NTLM kihívás-válasz anyagot. Ez a szervezet biztonsági ellenőrzéseitől függően további visszaéléseket tehet lehetővé, például NTLM-relé vagy offline jelszó-kitalálást.
Ebben a blogban az OPSWAT Fellowship Programban részt vevő diplomás hallgatók kutatásai alapján vizsgáljuk a CVE-2025-50154-et, és gyakorlati útmutatást adunk a kényszerített NTLM-hitelesítés kockázatának csökkentésére.
Hatás és kockázat
A CVE-2025-50154 biztonsági rés 2025. augusztus 12-én került nyilvánosságra, és több támogatott Windows kliens- és szerververziót (Windows 10/11 és Windows Server ) érint a javított build szintek előtt. A biztonsági rés CVSS v3.1 6.5 (közepes) besorolást kapott.
Az elsődleges biztonsági következmény a hitelesítő adatok nyilvánosságra kerülése: a támadó megszerezheti az NTLM kihívás-válasz anyagot azáltal, hogy az Explorer-t hitelesíti egy támadó által ellenőrzött végponton. A környezettől függően ez felhasználható a következőkre:
• NTLM-relé (spoofing): más szolgáltatásoknál az áldozatként való hitelesítés, ha a relé védelem hiányzik vagy rosszul van konfigurálva.
• Offline jelszó kitalálás/feltörés: gyenge jelszavak visszaállításának kísérlete a rögzített kihívás-válasz anyagokból.
A megvalósíthatóság nagymértékben függ az olyan vállalati ellenőrzésektől, mint az SMB aláírás, az NTLM korlátozások, a hálózati szegmentálás és a szolgáltatásoldali megerősítés.
Támadási forgatókönyv
A CVE-2025-50154 egy kényszerített hitelesítési probléma. Amikor a Windows Intéző feldolgoz egy távoli SMB/UNC helyre hivatkozó parancsikont, normál renderelés vagy útvonal-ellenőrzés során SMB-kapcsolatot kezdeményezhet. Ennek eredményeként a távoli végpont megkaphatja a munkamenet beállítása során generált NTLM hitelesítési adatokat.
Egy tipikus támadási forgatókönyv a következő:
- Támadó előkészítése: Az ellenfél irányítja az SMB-kiszolgálót, és előkészíti a parancsikon által hivatkozott megosztást.
- Parancsikon elhelyezése: A támadó által ellenőrzött SMB útvonalra mutató .lnk fájl a szokásos csatornákon keresztül kerül az áldozat környezetébe (például adathalász mellékletek, szinkronizált mappák, megosztott fájltárolók vagy egy meglévő támaszpont).
- Explorer által kiváltott hozzáférés: Amikor az áldozat böngészi a parancsikont tartalmazó könyvtárat, a Windows Explorer elemzi a parancsikon metaadatait, és megkísérelheti a távoli célpont feloldását a rutin UI-feldolgozás részeként.
- Implicit authentication: Az SMB munkamenet beállítása során a Windows a felhasználó kontextusa alatt hitelesít (gyakran NTLM-en keresztül). Az áldozatnak nem kell végrehajtania a parancsikon célját ahhoz, hogy a hitelesítési csere megtörténjen.
- A befogás utáni eredmények (környezettől függő): A környezet ellenőrzésétől függően a befogott NTLM-anyag felhasználható NTLM-relé vagy offline jelszófeltöréshez. A gyakorlati megvalósíthatóságot olyan tényezők befolyásolják, mint az SMB-aláírás, az NTLM-korlátozások és a hálózati szegmentálás.
Műszaki háttér
Windows Intéző és parancsikonok megjelenítése
A Windows Explorer (explorer.exe) a Windows shell folyamata, amely felsorolja a könyvtár tartalmát és megjeleníti a File Explorer felhasználói felületét, Shell komponenseket (pl. ikon/overlay/thumbnail kezelőket) hívva meg az ikonok, overlayek és thumbnailek lekéréséhez és megjelenítéséhez.
A Windows parancsikon (.lnk) nem egyszerű szöveges mutató, hanem strukturált metaadatformátum, amely tárolhatja a cél elérési útját (helyi elérési út vagy UNC/SMB elérési út), opcionális argumentumokat és munkakönyvtárat, valamint külön ikonhivatkozást. Normál mappaböngészés során az Explorer elemzi a parancsikon metaadatait, hogy a parancsikont megjelenítse a felhasználói felületen (például az ikon feloldásával és a cél érvényesítésével). A hivatkozott céltól és a kapcsolódó metaadatoktól függően ez a feldolgozás azt eredményezheti, hogy az Explorer a rutin renderelés vagy az elérési út ellenőrzése részeként hálózati hozzáférést próbál meg.
NTLM hitelesítés SMB-n keresztül
A Windows fájlmegosztásban az SMB hitelesítés általában a Kerberos protokollt részesíti előnyben a tartományi környezetekben, de az NTLM protokoll is használható, ha a Kerberos nem elérhető vagy nincs kiválasztva. Az NTLM egy kihívás-válasz protokoll: az ügyfél először közli a képességeit, a szerver visszaküld egy kihívást (nonce), és az ügyfél a kihívásból és a felhasználó titkos kulcsából származtatott hitelesítési üzenettel válaszol, anélkül, hogy elküldené a szöveges jelszót.
NTLM változatok és biztonsági helyzet (NTLMv1 vs NTLMv2)
Az NTLM több változatban létezik. A modern Windows-környezetek általában az NTLMv2-t használják, és lehetőség szerint kerülniük kell a régi LM/NTLMv1-et.
Az NTLMv1 több fontos okból (gyenge titkosítás, alacsony entrópiájú kulcsok, relé sebezhetőség, offline feltörés kockázata stb.) széles körben elismerten bizonytalanná vált.
Ennek javítása érdekében a Microsoft bevezette az NTLMv2-t, amely megerősíti a válasz kiszámítását. A gyakorlatban az NTLMv2 a régebbi DES-stílusú válaszépítést HMAC-MD5-alapú sémával helyettesíti, és további kontextust épít be a válaszba, így az NTLMv1-hez képest jelentősen robusztusabbá válik számos offline helyreállítási technika ellen.
Még az NTLMv2 használata esetén is a szervezeteknek az NTLM-et a Kerberoshoz képest magasabb kockázatú hitelesítési protokollként kell kezelniük, és mélyreható védelmi intézkedéseket (pl. SMB aláírás és szegmentálás) kell alkalmazniuk a kényszerített hitelesítési esetek hatókörének csökkentése érdekében.
Miért marad az NTLM gyakori célpont?
Bár az NTLM egy kihívás-válasz protokoll, a támadók számára továbbra is vonzó, mert a hitelesítési csere közvetlenül használható ellenséges hálózati körülmények között. Az SMB-munkamenet felállítása során a távoli végpont megkapja a hitelesítéshez szükséges metaadatokat és kihívás-válasz értékeket. Ha egy ellenséges szereplő képes működtetni a cél végpontot (pl. egy támadó által ellenőrzött SMB-kiszolgálót), vagy képes elfogni/megszakítani a kapcsolatot átvitel közben, akkor elfoghatja az NTLM-csere anyagát, és a környezet védelmétől függően megkísérelheti az NTLM-relé vagy az offline jelszó-kitaláláshoz hasonló további visszaéléseket.
A Windows az NTLM-et is integrálja az egyszeri bejelentkezés (SSO) funkciójába. A felhasználó titkos adatai alapján létrehozott hitelesítő adatokat az LSASS kezeli, és azok felhasználhatók a hálózati erőforrások (például SMB-megosztások) hitelesítésére anélkül, hogy a felhasználót többször is megkérdeznék. Ez javítja a használhatóságot, de növeli a kényszerített hitelesítési forgatókönyvek támadási felületét: amikor egy .lnk parancsikon távoli SMB-útvonalra hivatkozik, a Windows Intéző a parancsikonok rutin feldolgozása során SMB-kapcsolatot kezdeményezhet, és automatikusan megtárgyalhatja a hitelesítést.
A CVE-2025-50154 kontextusában ez azt jelenti, hogy az NTLM hitelesítési adatcsere anyaga elküldhető egy támadó által ellenőrzött SMB végpontra anélkül, hogy az áldozat végrehajtaná a hivatkozott célt, ami normál mappaböngészés közben csendes hitelesítő adatok kiszivárogtatását eredményezi.
Technikai elemzés
Felfedező ikonok megjelenítése és parancsikonok feldolgozása
Amikor egy mappát megnyitunk a Fájlkezelőben, az Explorer felsorolja a könyvtár tartalmát, és a regisztrált fájl társítások (általában a fájl kiterjesztése alapján) alapján meghatározza az egyes elemek típusát. A Windows ezután a megfelelő shell osztály regisztrációját (például a rendszerleíró adatbázisban található társított CLSID/ProgID leképezések segítségével) használja a megfelelő shell kezelő megtalálásához – ez általában egy COM-komponens, amely az ikonok kivonásáért és megjelenítéséért felelős. Az Explorer a megfelelő interfészeket hívja meg az ikon lekéréséhez és megjelenítéséhez.
A .lnk (Shell Link) fájlok esetében az Explorer alapértelmezés szerint nem jeleníti meg az általános parancsikon ikont. Ehelyett elemezi a parancsikon metaadatait, megpróbálja feloldani a hivatkozott célt (és a kapcsolódó ikoninformációkat), majd megjeleníti a feloldott célhoz tartozó ikont.
Amikor az Explorer egy .lnk fájlt renderel, a CShellLink::GetIconLocation hívásával határozza meg az ikont, amely azonosítja, honnan kell betölteni az ikont (például a cél bináris fájlból, egy explicit ikon útvonalból vagy egy alapértelmezett rendszerikonból). Ennek részeként az Explorer inicializálja az ikon kivonását (_InitExtractIcon), majd végrehajtja a felbontás alapvető logikáját (_GetExtractIcon), amely értékeli az ikon forrását ( a _CheckExtractLocation segítségével).
• Ha a parancsikon helyi ikon helyet jelöl meg (pl. egy futtatható fájl vagy DLL a lemezen), az Explorer közvetlenül abból az erőforrásból tölti be az ikont.
• Ha az ikon helye egy távoli URL, az Explorer letöltheti az ikont a helyi gyorsítótárába (pl. az URLDownloadToCacheFileW parancs segítségével), majd betöltheti az ikont a gyorsítótárból.
• Ha nincs érvényes ikonforrás, az Explorer a rendszerkezelő által biztosított alapértelmezett ikonra vált vissza.
Az ikonokkal kapcsolatos metaadatok feldolgozása után az Explorer a CShellLink::Extract parancsot hajtja végre, amely kezeli a parancsikon célját és befejezi a kivonási munkafolyamatot. Ennek részeként az Explorer a CShellLink::_ShortNetTimeout parancsot hívja meg, hogy rövidebb hálózati időkorlátokat alkalmazzon, ha a parancsikon távoli helyre hivatkozik, ezzel csökkentve a felhasználói felület késleltetését, ha a hálózati cél lassú vagy elérhetetlen.
Ha a cél egy hálózati (UNC) útvonalként van azonosítva, az Explorer aszinkron módon végzi el a cél érvényesítését. Létrehoz egy munkaszálat, amely futtatja a CShellLink::_VerifyPathThreadProc parancsot, amely ellenőrzi, hogy a hivatkozott cél létezik-e.
Ezen rutinon belül az Explorer a PathFileExistsAndAttributesW parancsot hívja meg, hogy lekérdezze a cél létezését és alapvető attribútumait (pl. fájl vagy könyvtár), ami viszont hálózati hozzáférési kísérletet igényel az SMB/UNC célok esetében.
A sebezhetőség alapvető oka
A fent leírt gyorsítótár-megjelenítési folyamat során két kimenő művelet releváns:
• Ikonok lekérése URLDownloadToCacheFileW segítségével (ha a parancsikon ikonjának forrása egy távoli URL).
• Cél érvényesítése a PathFileExistsAndAttributesW segítségével (ha a parancsikon célja UNC/SMB útvonal).
Az URLDownloadToCacheFileW viselkedésének ellenőrzéséhez egy minimális, önálló API próbáltuk ki az API .
A hálózati tevékenység hagyományos HTTP-lekérésből állt, és megfigyeléseink szerint nem tárt fel a sebezhetőséghez kapcsolódó hitelesítő adatokat.
A PathFileExistsAndAttributesW esetében jelentősebb viselkedés akkor fordul elő, ha az értékelt elérési út UNC/SMB cél. A hibakeresés során megfigyeltük, hogy ez az ellenőrzés SMB-munkamenet létrehozását indíthatja el, és a jelenlegi felhasználói kontextusban hitelesítést tárgyalhat.
Mivel az Explorer a .lnk fájl feldolgozása során automatikusan meghívhatja ezt az érvényesítést, a támadó által ellenőrzött SMB végpont NTLM hitelesítési adatokat kaphat anélkül, hogy az áldozat végrehajtaná a hivatkozott fájlt, így a rutin mappaböngészés során csendes hitelesítő adatok kiszivárogtatására alkalmas útvonalat hozva létre.
Koncepció igazolása
Egy elszigetelt laboratóriumban az OPSWAT Fellowship résztvevői egy távoli SMB/UNC útvonalra hivatkozó parancsikon (.lnk) segítségével validálták a CVE-2025-50154-et. Egy sebezhető Windows rendszeren a Windows Intézőben a mappa egyszerű böngészése a normál parancsikon-feldolgozás során SMB-kapcsolatot indított el, ami azt eredményezte, hogy NTLM hitelesítési adatokat küldtek a távoli végpontra – anélkül, hogy az áldozat végrehajtotta volna a parancsikon célját.
Helyreállítás
A szervezeteknek gondoskodniuk kell arról, hogy operációs rendszereik és alkalmazásaik rendszeresen frissüljenek és naprakészek legyenek, hogy enyhítsék az ismert sebezhetőségeket. Ez magában foglalja az összes releváns Microsoft biztonsági frissítés telepítését és annak ellenőrzését, hogy az összes végpont a javított és legújabb Windows-verziót futtatja. Ezzel párhuzamosan a szervezeteknek csökkentenie kell a támadási felületüket azáltal, hogy szigorítják a kimenő SMB-hozzáférést, ahol ez szükséges, és megerősítik az NTLM/SMB-megerősítő ellenőrzéseket a környezetüknek megfelelően.
MetaDefender támogatja ezeket az erőfeszítéseket, és segít azok nagyméretű megvalósításában azáltal, hogy világos képet ad a sebezhetőségekről és a javítások készenlétéről. A több mint 1100 alkalmazást támogató robusztus sebezhetőség- és javításkezelési funkciókkalEndpoint MetaDefender Endpoint azonosítja a javítás nélküli vagy elavult Windows-verziókat futtató végpontokat, valamint a harmadik féltől származó alkalmazásokat, és ajánlott javításokat kínál.
EzenkívülCentral Management My OPSWAT Central Management felügyeleti konzolján keresztül a rendszergazdák központosított, egységes képet kapnak a végpontok biztonsági állapotáról, a sebezhetőségekről és a javítások kezeléséről, mindezt egyetlen platformon belül, amelyen a szervezet egészére vonatkozó biztonsági irányelveket lehet meghatározni és érvényesíteni. A rendszergazdák emellett egyedi szkripteket is létrehozhatnak és telepíthetnekEndpoint MetaDefender Endpoint a végpontokra, hogy automatizálják az SMB-hozzáféréssel és az NTLM használatával kapcsolatos biztonsági intézkedéseket. Ez a megközelítés egyszerűsíti a biztonsági szabályok érvényesítését, miközben egyértelmű visszajelzést ad a végrehajtás eredményeiről, lehetővé téve a rendszergazdák számára, hogy gyorsan azonosítsák azokat a végpontokat, amelyek további vizsgálatot vagy manuális beavatkozást igényelhetnek.
Endpoint MetaDefender Endpoint a biztonsági és IT-csapatok számára, hogy prioritásokat állapítsanak meg a bevezetésekkel kapcsolatban, felgyorsítsák a javításokat, folyamatosan figyelemmel kísérjék a szervezet biztonsági helyzetét, és végső soron csökkentsék a CVE-2025-50154 és hasonló végpontalapú fenyegetésekhez hasonló közös sebezhetőségek és kitettségek (CVE-k) kockázatát.
