A BlueKeep egy számítógépes biztonsági rés a Microsoft Remote Desktop Protocol megvalósításában, amely lehetővé teszi a távoli kódfuttatást . A BlueKeep a Windows összes nem frissített verzióját érinti a Windows NT termékcsaládban , a Windows 2000 -től a Windows Server 2008 R2 -ig és a Windows 7 -ig . 2019 szeptemberében a BlueKeep exploitot nyilvánosan elérhetővé tették a Metasploit projekt [1] részeként .
Az NSA és a Microsoft szerint a BlueKeep kiaknázható számítógépes férgek által , a Microsoft becslése szerint 1 millió sebezhető eszközre alapozva egy ilyen támadás olyan mértékű lehet, mint az EternalBlue támadások, például a NotPetya és a WannaCry. [2] [3] [2] [3] [ 4] .
A sérülékenységet a CVE -ID CVE-2019-0708 [5] emelte ki .
A BlueKeep biztonsági rést az RDP protokoll megvalósítása során fedezték fel a Windows operációs rendszer egyes verzióiban 2019 májusában. Az RDP egy védett protokoll, amely távoli hozzáférést biztosít a Windows rendszert futtató számítógépekhez. A BlueKeepnek semmi köze magának a protokollnak a mechanizmusához, és csak a végrehajtását érinti. A sérülékenység különösen a kódnak az úgynevezett virtuális csatornák kezeléséért felelős részét érinti . Az RDP különböző virtuális áramköröket használ a különböző típusú adatok szállítására. Például az "rdpsnd" csatorna hangot hordoz, míg a "cliprdr" csatorna a vágólap tartalmának továbbítására szolgál . További virtuális áramkörök használhatók az RDP-protokoll bővítésére a felhasználói alkalmazások szintjén. A Windows 2000 rendszerben csak 32 statikus virtuális csatorna állt rendelkezésre, ezért e korlátozás megkerülésére javasolták a dinamikus virtuális csatornák mechanizmusát, amely lehetővé teszi több dinamikus csatorna átvitelét egy statikus csatornán. A statikus csatornák az RDP-munkamenet létrehozásakor jönnek létre, és a bezárásig léteznek, míg a dinamikus csatornák az ügyfél kérésére hozhatók létre és törölhetők. Ezenkívül a statikus csatornákkal ellentétben, amelyek 0 és 31 közötti egész számmal vannak számozva, a dinamikus csatornákat a karakterlánc nevük alapján azonosítják. A Windows a dinamikus csatornaneveket statikus csatornaszámokhoz köti a termdd.sys [6] illesztőprogramban található _IcaBindVirtualChannels és _IcaRebindVirtualChannels függvényekben .
Alapértelmezés szerint az RDP a 31-es számot egy belső, nem felhasználó által irányított „MS_T120” nevű virtuális áramkör számára tartja fenn. Az illesztőprogram azonban nem ellenőrzi, hogy létezik-e azonos nevű egyéni virtuális csatorna. Így a támadó létrehozhat egy másik dinamikus csatornát „MS_T120” néven, és egy másik számú statikus csatornához kötheti. Ebben az esetben az "MS_T120" dinamikus csatorna már meglévő példányára mutató mutató társítva lesz az új számhoz. A támadó által létrehozott csatorna bezárásakor a memória felszabadul , majd a 31-es számhoz tartozó „MS_T120” csatornára mutató lógó mutató a rendszerben marad, ami memóriaelérési hibákhoz vezethet [6] . A helyzetet súlyosbítja, hogy a dinamikus virtuális csatornák létrehozása még a felhasználói hitelesítési szakasz előtt megtörténhet , ami lehetővé teszi a BlueKeep használatát a számítógépes férgek számára . Ezt a problémát részben megoldja a Network Level Authentication (NLA) használata, amely a Windows Vista rendszerben jelent meg , az RDP protokoll egyik opciója, amely a kapcsolat létrehozása előtt felhasználói hitelesítést igényel [7] .
A Microsoft 2019. május 14-én biztonsági frissítést adott ki (többek között a Windows több olyan verziójára, amelyek támogatási időszaka lejárt, különösen a Windows XP esetében) [4] . A termdd.sys illesztőprogram javított verziója nem teszi lehetővé a 31-től eltérő számok hozzárendelését az "MS_T120" nevű csatornához.
A "BlueKeep" nevet ennek a biztonsági résnek Kevin Beaumont számítógépes biztonsági szakértő adta Twitter - bejegyzésében .
A BlueKeep-et először az Egyesült Királyság Nemzeti Kiberbiztonsági Központja említette [8] , a Microsoft jelentése 2019. május 14-én jelent meg a biztonsági rést javító biztonsági frissítéssel együtt. Később, 2019. június 4-én az NSA kiadta biztonsági tanácsát [3] .
Ugyanazon a napon, amikor az NSA-tanácsot közzétették, a CERT elszámolóház kutatócsoportja egy másik, az RDP -protokollhoz kapcsolódó sebezhetőséget jelentett a Windows 10 May 2019 Update és a Windows Server 2019 rendszerben . A kutatók különösen azt a tényt figyelték meg, hogy a hálózati szintű hitelesítés hitelesítő adatai gyorsítótárban vannak az ügyfélrendszeren, és a felhasználó automatikusan újra hozzáférhet RDP-kapcsolatához, ha az megszakad. A Microsoft elvetette ezt a biztonsági rést, mint szándékos viselkedést, azzal érvelve, hogy a csoportházirend- mechanizmussal letiltható [9] .
2019 júniusa óta számos működő PoC -t küldtek be a biztonsági rés kihasználására. Különösen a McAfee [6] és a Sophos [10] [11] mutatta be verzióit . 2019. július 22-én a BlueKeepről további információkat ismertetett a konferencián egy kínai információbiztonsági cég előadója [12] . 2019. július 25-én a szakértők kijelentették, hogy a kizsákmányolás kereskedelmi változata akkoriban elérhető lehetett [13] .
2019. augusztus 13 -án jelentették a DejaBlue -t, a BlueKeephez kapcsolódó sebezhetőségek új csoportját. A Windows régebbi verziói mellett a DejaBlue-t a Windows 10 -ig terjedő újabb operációs rendszerek is érintették [14] .
2019. szeptember 6-án a BlueKeep sebezhetőségének kihasználása a Metasploit [1] részeként megjelent a nyilvánosság számára . Az exploit kezdeti verziója azonban rendkívül megbízhatatlannak bizonyult a gyakori BSoD -hiba miatt . Később elérhetővé vált egy átdolgozott változat [15] .
2019. november 2-án jelentették az első hatalmas BlueKeep hackertámadást a Monero kriptovalutával [ 16] [17] kapcsolatban . 2019. november 8-án a Microsoft megerősítette a támadást, és felszólította a felhasználókat, hogy a lehető leghamarabb frissítsék Windows - verzióikat [18] .
A BlueKeep sebezhetőség kihasználásának legegyszerűbb módja egy DoS támadás végrehajtása az alapján. Amikor egy kliens csatlakozik, a szerveren automatikusan létrejön egy „MS_T120” csatorna a statikus számhoz 31. Az MCS Connect Initial PDU és a GCC Conference Create Request RDP kérés használatával a kliens tetszés szerint további dinamikus csatornákat hozhat létre, míg a szerver visszaadja a társított statikus csatornák számát az RDP válaszüzenetben. Mivel ez a kérés a felhasználó- hitelesítési lépés előtt történik , a támadónak nem kell fiókkal rendelkeznie a rendszerben a támadás sikeres végrehajtásához. Ha a kliens az „MS_T120” értéket adja meg a csatornák listájában, a szerver az _IcaBindVirtualChannels függvény újbóli meghívásával a csatornastruktúra meglévő példányát 31-től eltérő számhoz köti. A munkamenet végén a szerver először felszabadítja a lefoglalt memóriát a támadó által létrehozott csatorna bezárásakor, majd megpróbálja ugyanazt a memóriát felszabadítani, amikor megpróbálja bezárni a 31-es számú csatornát. Így a termdd.sys illesztőprogramon belül kettős memóriafelszabadítás történik . Mivel a hiba a kerneltérben történik , összeomlik az operációs rendszer egy BSoD -ben [19] [20] .
Sokkal veszélyesebb a BlueKeep használata távoli kódvégrehajtáshoz (RCE) . A dinamikus csatornákra vonatkozó információkat tartalmazó adatstruktúrák a nem lapozható készletben tárolódnak . A csatornasorban tárolt üzenetek memóriája szintén a lapozatlan készletben van lefoglalva. Az adott üzenethez lefoglalt memória csak akkor szabadul fel, ha azt a csatornából kiolvassák, vagyis ha a csatorna nem kerül beolvasásra, akkor a memória csak a kapcsolat lezárásakor szabadul fel [21] .
Az RCE végrehajtásához a támadónak újra le kell foglalnia és felül kell írnia a memóriát azon a címen, ahol az „MS_T120” csatorna szerkezete a memória felszabadítása előtt volt. A rosszindulatú kód végrehajtásához elegendő a virtuális metódustáblára mutató mutató értékét ebben a struktúrában a kívánt értékre módosítani. Ezt a feladatot nagyban megkönnyíti, hogy a Windows 7 előtti Windows -verziókban nincs adatvégrehajtás-megelőzési (DEP) mechanizmus a lapozatlan készletben . Ez azt jelenti, hogy a rosszindulatú kód ugyanarra a címre helyezhető el, mint a hamis virtuális metódustábla. Mind a mutató megváltoztatása, mind a rosszindulatú kód közvetlen elhelyezése elvégezhető a fent említett mechanizmuson keresztül, amely üzeneteket küldhet egy olyan csatornán, amely nem olvasható a [21]-ből .