A múlt hét során vált ismertté a Microsoft Exchange levelező szerverek két súlyos nulladik napi hibája, amelyek már meg is kapták a becenevet: ProxyNotShell – utalván a tavalyi ProxyShellként hivatkozott hasonló sérülékenységekre.
Egy kódfutattási sérülékenység mindig kiemelt figyelmet követel, különösen ha az a Microsoft népszerű Exchnage levelező szervertermékét érinti. Amellett, hogy a szervezet belső levelezése egy támadás során kompromittálódhat ─ ami már önmagában is óriási probléma ─ a támadók ugródeszkaként használhatják további rendszerek megfertőzésére. És jellemzően használják is, ha módjuk van rá, ugyanis a ProxyShell szerepel az amerikai állami kiberügynökség által vezetett rutinszerűen kihasznált sérülékenységi toplistán is. A kiberbiztonsági szakma ezért kiemelt figyelemmel követi az ilyen sebezhetőségeket, nincs ez másként a ProxyNotShellel sem, amivel kapcsolatban már egy kicsivel bővebb információ érhető el.
Jó hír, hogy egyrészt a Microsoft szerint Exchange Online felhasználók nem érintettek a sérülékenységben, csupán azok a rendszerek, amik helyi (vagy hibrid!) üzemeltetésűek, illetve ─ ellentétben a ProxyShellel ─ a ProxyNotShell csak akkor használhatóak ki, ha a támadó már valamiféle hozzáféréssel rendelkezik a szerverhez, például sikerül megszereznie egy Exchange felhasználó jelszavát.
Mielőtt azonban az üzemeltetők hátradőlnének, szögezzük le, hogy a sebezhetőség így is igazán veszélyes, mert a támadónak elég egy átlagos jogosultságú fiókhoz hozzáférnie, azaz a védelem jelentős részben a jelszavak erősségére támaszkodik, ami a tapasztalatok szerint nem igazán megnyugtató. Hivatalos hibajavítás pedig még nem érkezett, bár a gyártó azt ígérte ezt gyorsított eljárásban igyekszik orvosolni.
Van mitigáció, de nem elégséges
A Microsoft kiadott ugyan megkerülő megoldást, ami a PowerShell parancsok futásának korlátozásával igyekszik csökkenteni a támadó lehetőségeit, azonban már több kiberbiztonsági kutató is rámutatott, hogy ez a mitigáció megkerülhető, és a gyártói javaslatban szereplő URL blokkolási szabály túl specifikus, helyette érdemes legalább az alábbi, általánosabb tiltást alkalmazni:
.*autodiscover\.json.*Powershell.*A Microsoft emellett javasolja még az alábbi PowerShell portok tiltását:
- HTTP: 5985
- HTTPS: 5986
Valamint a PowerShell parancsok futtatásának teljes tiltását a nem admin fiókokon, amiről itt található bővebb gyártói útmutató.
A ProxyNotShell sérülékenységről az NBSZ NKI műlt héten riasztást is adott ki.
