Megjelent a CoSoSys Endpoint Protector 5.6.0.0-ás verziója
2022. október 12.
A virtuális erőművek előnyei és kockázatai
2022. október 17.Megjelent a CoSoSys Endpoint Protector 5.6.0.0-ás verziója
2022. október 12.A virtuális erőművek előnyei és kockázatai
2022. október 17.
Vizsgáljunk meg példaként két gyakori konfigurációs hibát:
• Szűrt („filtered”) port – Valamilyen biztonsági eszköz, például egy tűzfal vagy router, blokkolja és szűri a porton keresztüli kapcsolatot, azaz elnyeli (eldobja) a kapcsolódási kérést és semmilyen választ nem engedélyez vissza
• Zárt port – Nincs alkalmazás vagy szolgáltatás, amely aktívan kapcsolatot vár a porton; egy esetleges kapcsolódási kérésre a zárt állapotról válaszcsomagot küld vissza az operációs rendszer. Egy zárt port azonban bármikor újranyitható egy alkalmazás elindításával A zárt port státusz az üzemeltetőben azt a hamis képet keltheti, hogy onnan nem érheti támadás, mivel ott nem feltételez adatforgalmat. Ez a feltételezés okozza azt is, hogy a zárt port folyamatos ellenőrzését, monitorozását is hanyagolják, ezzel teremtve veszélyforrást, hiszen a port zárt állapota gyakorlatilag bármikor változhat, egy megfelelő jogosultságokkal futtatott program újranyithatja azt, rajta újból adatforgalom mehet keresztül. Más szóval, a támadók a hálózati végpontok aktuálisan zárt portjait - azok újranyitásával - képesek arra használni, hogy kapcsolatot hozzanak létre a saját és a hálózat belső eszközei között és rosszindulatú parancsok végrehajtására használják ezen csatornát. Ezt az eljárást angol szakszóval „bind shell”-nek nevezzük. A kiberbűnözők tehát meg tudják támadni a szervezeti tűzfal által védett eszközeinket a korábbi zárt portokon keresztül. A hackerek egy ’payload’-ot, azaz hasznos adatot, küldenek az eszköznek a 445-ös (SMB) porton, melyet a szervezeti tűzfal átenged. A payload ezután megpróbál kommunikációt létesíteni egy „reverse shell”-t alkalmazva vissza a támadóhoz a 4444-es porton keresztül, azonban ezt már blokkolja a szervezeti tűzfal (lásd az 1. ábrát).
A zárt portok problémája
Gyakori megoldás a szervezeteknél, hogy kizárólag a hálózati tűzfalukra támaszkodnak, és hajlamosak kikapcsolni a helyi/végponti tűzfalukat, megspórolva ezzel annak rendszeres karbantartását. Ez a gondatlanság a portokon keresztül üthet vissza a hálózatra. A különböző szolgáltatások és alkalmazások futtatásához szükséges portokat a szervezeti tűzfalon keresztül tudjuk megnyitni. Időről időre ezek az alkalmazások törlésre kerülhetnek a végpontokról. Ilyen esetekben a törölt alkalmazáshoz tartozó port zárt státuszba kerül, azonban a helyi tűzfalszabály továbbra is engedélyezi kapcsolat létrehozását a zárt porton. Ezt pedig hajlamosak vagyunk figyelmen kívül hagyni. De miért számít konfigurációs hibának, ha egy portot zárt státuszban hagyunk? Tekintsük át a három leggyakoribb port státuszt: • Nyitott port – Az alkalmazás vagy szolgáltatás fut, és kapcsolatot fogad a porton keresztül• Szűrt („filtered”) port – Valamilyen biztonsági eszköz, például egy tűzfal vagy router, blokkolja és szűri a porton keresztüli kapcsolatot, azaz elnyeli (eldobja) a kapcsolódási kérést és semmilyen választ nem engedélyez vissza
• Zárt port – Nincs alkalmazás vagy szolgáltatás, amely aktívan kapcsolatot vár a porton; egy esetleges kapcsolódási kérésre a zárt állapotról válaszcsomagot küld vissza az operációs rendszer. Egy zárt port azonban bármikor újranyitható egy alkalmazás elindításával A zárt port státusz az üzemeltetőben azt a hamis képet keltheti, hogy onnan nem érheti támadás, mivel ott nem feltételez adatforgalmat. Ez a feltételezés okozza azt is, hogy a zárt port folyamatos ellenőrzését, monitorozását is hanyagolják, ezzel teremtve veszélyforrást, hiszen a port zárt állapota gyakorlatilag bármikor változhat, egy megfelelő jogosultságokkal futtatott program újranyithatja azt, rajta újból adatforgalom mehet keresztül. Más szóval, a támadók a hálózati végpontok aktuálisan zárt portjait - azok újranyitásával - képesek arra használni, hogy kapcsolatot hozzanak létre a saját és a hálózat belső eszközei között és rosszindulatú parancsok végrehajtására használják ezen csatornát. Ezt az eljárást angol szakszóval „bind shell”-nek nevezzük. A kiberbűnözők tehát meg tudják támadni a szervezeti tűzfal által védett eszközeinket a korábbi zárt portokon keresztül. A hackerek egy ’payload’-ot, azaz hasznos adatot, küldenek az eszköznek a 445-ös (SMB) porton, melyet a szervezeti tűzfal átenged. A payload ezután megpróbál kommunikációt létesíteni egy „reverse shell”-t alkalmazva vissza a támadóhoz a 4444-es porton keresztül, azonban ezt már blokkolja a szervezeti tűzfal (lásd az 1. ábrát).
1. ábra
A hacker úgy gondolja, sikertelenül járt, mikor észreveszi, hogy a 88-as port zárt státuszban van és nem lett a tűzfal által kiszűrve. Mivel a 88-as port egy alapértelmezett Kerberos port (tehát jó eséllyel engedélyezett a kommunikáció a teljes hálózaton), a hacker úgy dönt, hogy egy „command and control” (C&C) kapcsolatot hoz létre ezen hálózati porton keresztül, és ezzel rosszindulatú parancsokat hajt végre a végponton. Ebben az esetben a payload végrehajtása az áldozat gépén megnyitja a 88-as portot, várja a parancsokat, és a támadás így már sikerrel fog járni (lásd az 2. ábrát).
2. ábra
Ezen a ponton a potenciális károk mértéke a feltört végpont jogosultságaitól függ.
Az LSASS fehérlistázás hitelesítési buktatói
A szolgáltatások és alkalmazások fehérlistázása egy másik gyakori, veszélyes konfigurációs hibalehetőség. A túlzottan megengedő irányelveket a támadók kihasználhatják NTML jelszó „hash”-ek kinyerésére, de akár tartományi vagy helyi felhasználók jelszavait is megszerezhetik az LSASS folyamaton keresztül. A támadó egy kritikus távoli kódfuttatási sebezhetőségen keresztül képes átvenni az ellenőrzést a számítógép felett, előzetes hitelesítés nélkül. Másképpen fogalmazva, a támadó kihasznál egy olyan biztonsági rést, amely lehetővé teszi nem hitelesített felhasználók számára, hogy RCE-t (Remote Code Execution – távoli kódfuttatás) hajtsanak végre a sérülékeny végponton.
3. ábra
A támadó így megszerezheti a SAM-fájlt, hozzáférve az áldozat gépének helyi rendszergazda hitelesítési adatainak kivonatához (NTLM hash) („Host A” a 3. ábrán). A támadó az NTLM hash-t használja a hitelesítéshez és ezzel helyi emelt szintű rendszergazdai jogokat kap, amelyek segítségével további „cleartext” jelszavakat vagy NTLM hash adatokat von ki az LSASS folyamatból. Ha az ’A’ végponton futó „Windows Error Reporting” szolgáltatást korábban hibakeresési célból fehérlistára helyezték, az EDR vagy a vírusirtó nem fog reagálni a támadás ezen veszélyes (MITRE – Credential Access) lépéseire. Tehát, ha a támadó megkísérli a hitelesítő adatok kinyerését a Windows hibajelentő segítségével, bár ez ennek a folyamatnak nem tipikus és elvárt viselkedése, sikerrel fog járni. A támadó az LSASS folyamatból megszerzi egy domain admin NTLM hash adatát, amely további visszaélésekre ad lehetőséget (lásd az 4. ábrát).
4. ábra
