>_ LegacyHive - Nightmare Eclipse-dən yeni zero-day

622 - Microsoftun 2026-cı il iyul Patch Tuesdayi bu rəqəmlə yadda qaldı, çünki 622 CVE bir gündə patch olunmuşdu. Adətən bu sayda CVE-dən sonra kibertəhlükəsizlik icması yavaşlayıb, bir neçə gün nəfər alır. Lakin “qəhrəmanımız” Nightmare Eclipse-in dayanmaq kimi niyyəti yoxdur. Patch Tuesday bitən kimi, patchlər hələ soyumamış “LegacyHive” adlı yenir bir zero-day PoC yayımladı. Pis tərəfi isə orasıdır ki, bu patch quraşdırılmış sistemlərdə belə işləyir. Yəni Microsoft “bu ayı da bağladıq” deyib sevindiyi an, yeni bir qapının açıq qaldığını gördü.

Mövzu maraqlıdır, çünki bu dəfə söhbət nə fişinqdən gedir, nə də sosial mühəndislikdən. Söhbət Windowsun on illərdir arxa planda olan, heç kimin fikir vermədiyi bir komponentindən - User Profile Service (profsvc)-dən gedir.

//Zəiflik nədədir?

Hər Windows istifadəçisinin öz reyestr “otağı” var. NTUSER.DAT şəxsi tənzimləmələrin olduğu, UsrClass.dat isə COM qeydiyyatlarını, bundan əlavə sadə dillə desək “hansı proqram hansı faylı açsın” məntiqini saxlayan classes hive-ıdır. Login olan kimi bu faylları live reyestrə isə məhz profsvc mount edir.

LegacyHive-da görünən problem budur ki, profsvc bir hive-ı mount edərkən “bu fayl həqiqətən bu sessiyanın sahibinə məxsusdur?” sualını soruşmur. Tədqiqatçının GitHub README hissəsində qeyd etdiyi kimi, PoC ikin bir standart istifadəçinin credentiallarını verməklə, hədəf istifadəçinin hiveını hücumçunun öz sessiyasının classes rootuna mount etdirməyi bacarır. Sadə dillə desək adi user hesabı, başqa admin hesabının reyestr fayllarını çəkə bilir, halbuki bu mümkün olmalı deyildi.

Məsələ ilə bağlı praktiki nəticələri Tharros-dan Will Dormann yoxlayaraq təqdim edib.

Onun testlərinə əsasən bu mexanizm vasitəsilə classes hiveı manipulyasiya edib admin hesab sistemə login olan kimi avtomatik kod icra etdirmək mümkündür. Dormann-ın public PoC-də göstərdiyi zərərsiz bir nümunədir amma özünün də dediyi kimi “bunu daha maraqlı və istifadəçi müdaxiləsi tələb etməyən bir şeyə çevirmək elə də çətin deyil”.

Post by @[email protected]

View on Mastodon

Məsələnin texniki kökünə ensək iki əsas problemlə qarşılaşırıq. Birincisi profsvc mount zamanı complete mediation aparmır, yəni hiveın sahibliyini bir dəfə yoxlayır daha sonra güvənir və yenidən yoxlama aparmır. İkincisi isə mount əməliyyatı yalnız bir şərt daxilində - ikinci istifadəçinin credentialı vasitəsilə aparılır, halbuki belə bir kritik əməliyyat üçün ən azı iki müstəqil təsdiq tələb olunmalıdır.

//Təhdid modeli

LegacyHive uzaqdan, autentifikasiyasız işləyən bir exploit deyil, Local Privilege Escalationdur. Yəni kənardan sənin kompüterinə daxil olur ssenarisi yox, kimsə sənin kompüterinə daxil olub və indi daha çox səlahiyyət istəyir ssenarisidir. Buna görə real təhdid modeli belə qurulur:

• Burdakı aktiv - Windows endpointi üzərindəki standart istifadəçi və həmin istifadəçi ilə administrator/SYSTEM arasında sərhədin olmağıdır.Bu sərhəd pozulduğu təqdirdə domen credentiallarından tutmuş, lateral movementə qədər düşünə biləcəyimiz hər şey mümkündür.
• Hücumçu profili: Burda iki ssenari ola bilər: birincisi ümumi istifadədə olan kompüterlərdə (məs. ofis workstationu, universitet labı və s.) adi hesabı olan insayder və zərərli istifadəçi. İkincisi fişinq/malware və s. üsullarla standart istifadəçi əldə etmişdi bir xarici hücumçu. Pentest-Tools.com-dan Matei Badenoiu-nun The Registerə dediyi kimi, bu artıq mühitə giriş əldə etmiş hücumçular üçün faydalıdır, amma tək başına sistemi kompromis etmək üçün kifayət deyil.
• İmkanları: Hücumçunun özünə aid aşağı imtiyazlı logini var, ikinci bir standart istifadəçinin credentiallarını əldə edə bilir və eyni maşına adminin gec-tez login olacağını gözləyir.

Qısacası bu zəiflik “zero-trust” tələb edən, yəni daxildəki istifadəçiyə belə etibar etməyən mühitlər üçün klassik “assume breach” nümunəsidir.

//Təhdid modelinə əsasən kiçik təhlükəsizlik siyasəti

Real şirkət səviyyəli sənəd olmasa da, məntiqi ardıcıllıqla yazılmış təhlükəsizlik siyasəti belə ola bilər:

1. Profil izolyasiyası: Heç bir hesab öz sessiyasında olsa belə başqa istifadəçiyə məxsus hive/profil fayllarını mount edə bilməz. Yalnız profilin sahibi və SYSTEM prosesi bu əməliyyatı yerinə yetirə bilər.
2. Admin login: Administrator hesabları gündəlik istifadə olunan workstationlarda olmamalıdır. Bunun yerinə ayrıca olaraq PAW(Privileged Access Workstation) kimi maşınlarda açılmalıdır ki, adi istifadəçi və admin eyni maşında olduğu ssenari mümkün olmasın.
3. Patch/Mitigation: Public PoC-si yayınlanmış, CVE-siz qalan zəifliklər üçün ilk 48 saat ərzində kompensasiya tədbiri (məs. “log on locally” məhdudlaşdırılması) tətbiq olunmalıdır.
4. Monitorinq: Fərqli istifadəçi ilə baş verən bütün hive load/mount əməliyyatları loglanmalı və anormal görünəndə SOC-a alert getməlidir.

//Qorunma mexanizmləri

Burda təbii ki, həlli sadəcə olaraq Microsoft təqdim edə bilər, amma necə düzəldilməlidir sualına dizayn prinsipləri nöqteyi-nəzərindən baxsaq bəzi məsələləri danışa bilərik.

• Complete mediation: profsvc hər mount cəhdində hive-ın kimin olduğunu, yəni sahibliyini yoxlamalıdır. Bir dəfə yoxlanıb, nəticənin cache-lənməsi və bu cache-ə etibar edilməsi bu prinsipin pozulmasıdır.
• Seperation of Privilege: hive mountu tək bir şərtə yox, ən azı iki müstəqil təsdiqə əsaslanaraq işləməlidir. Həm hazırki sessiyanın açıq icazəsi, həm də hiveın sahibliyi yoxlanılmalıdır.
• Least Privilege: hiveı mount edən komponent bütün sistem üzərində SYSTEM səlahiyyəti daşımaq əvəzinə, sadəcə olaraq oxuyub yükləmək üçün lazım olan minimal imtiyazla işləməlidir.
• Fail-Safe Defaults: hiveın sahibliyi ACL səviyyəsində təsdiqlənə bilmirsə bu zaman cavab müsbət yox, mənfi olmalıdır.
• Least Common Mechanism: bütün profillərin eyni mount path-ini paylaşmağı zəifliyin köküdür, profilərin izolyasiyası artırılmalıdır.
• Economy of Mechanism: düzəliş əlavə bir layer yox, sadə və yoxlanıla bilən bir checkup olmalıdır. Implement ediləcək hər hansı yeni feature özü ilə digər bugları da gətirə bilər.
• Psychological Acceptability: admin hesabının yaradılıb, logininin adi userdən ayrılması prosesi çətinləşdirilməməlidir. Bu zaman işin içində insan faktoru olduğu üçün, İT administrator bir müddətdən sonra bu addımları qulaqardı edəcək.
• Open Design: Sistemin təhlükəsizliyi mövcud problemlərin açıq şəkildə düzəldilməsindən asılıdır. Microsoft isə tədqiqatçıya qarşı hüquqi addım hazrlayaraq bu prinsipin tam əksi istiqamətində hərəkətə keçib.

Patch çıxana qədər real mühit üçün ən praktiki addımlar bunlardır: Kevin Beaumont-un yaydığı MDE üçün KQL hunting query-lərini işə salmaq, "log on locally" hüququnu paylaşılan maşınlarda sərtləşdirmək, Credential Guard/LSA qorumalarını aktiv saxlamaq və gündəlik işdə local admin kimi işləməkdən çəkinmək. Yəni sadəcə Principle of Least Privilege-i özün üçün də tətbiq etmək.

>_ exit

622 CVE-lik bir Patch Tuesday-dən saatlar sonra tam patch olunmuş sistemlərdə işləyən bir LPE PoC-nin çıxması bizə onsuz da bildiyimiz bir şeyi bir daha xatırladır: patch sayının çoxluğu təhlükəsizlik demək deyil, sadəcə "bu ayın siyahısı" deməkdir.

$ khazrisec --analyze legacyhive.poc --target profsvc.dll
[+] Vulnerability class: Local Privilege Escalation (LPE)
[+] Root cause: missing ownership re-verification on hive mount
[+] Violated principles: Complete Mediation, Separation of Privilege
[+] Patch status: None. CVE status: None. Legal threats: Yes.
[+] Status: Exiting terminal.
$ exit --status: Unpatched