Pen Test / Risk
Sérülékenységvizsgálat fontossága
Nem csak akkor kell a vizsgálatot elvégezni amikor:
- Valami külső kényszer miatt szükséges az IT Biztonsági vizsgálatot lefolytatni és a jelenlegi állapotot felmérni. Ez általában törvényi megfelelőséget jelent vagy valamilyen ISO auditot.
- Vagy, ha támadás történik és anyagi kár keletkezik. Ebben az esetben a vállalat megérzi a probléma (jelentős anyagi kár vagy adatvesztés / adatszivárgás következtében) miatt az IT biztonság fontosságát.
Az időbeni kiberbiztonsági felkészüléssel rengeteg időt és energiát spórólhat meg, mintha bekövetkezne egy káresemény, ahol a percek is rettentően fontosak egy tűzoltási reakcióban.
Szakmai képzések
Szükség esetén a felhasználóknak és a rendszergazdáknak is biztosítunk képzéseket a hatékonyabb biztonság elérés érdekében.
Segítségnyújtás
A vizsgálat alatt, ha bármilyen probléma felmerülne, azonnal elér minket és leállítjuk a szkennelést, hogy a felmerülő problémákat javítani lehessen.
sérülékeny verziójú Apache httpd érhető el az országban
blokkolatlan snmp v2
2023 augusztusi adatok alapján
sérülékeny samba verzió
sérülékeny windows
Sérülékenységek és a várható károk
Access Control management
Ebbe a kategóriába tartozik minden olyan sérülékenység, amely valamilyen rosszul beállított hozzáférés problémához vezethető vissza. Például, egy rosszul konfigurált VLAN, amelyben minden felhasználó képes csatlakozni a szerverhez, hálózati eszközhöz. Egy jól beállított hálózaton a szerver és hálózati eszközök menedzselését kizárólag rendszerüzemeltetők végezhetik. Szintén ebbe a kategóriába tartozik például egy nem megfelelő port-security-val ellátott hálózat. Amennyiben illetéktelen eszköz csatlakoztatható egy belső hálózathoz, egy rosszindulatú felhasználó támadásokat hajthat végre
Brute Forcing
Ezen sérülékenység nagyon sok helyen fordulhat elő, és rengeteg támadási forma épülhet a kihasználására. Bármilyen alkalmazásról vagy protokollról legyen szó, közös tulajdonságuk, hogy nagy mennyiségű kérést lehet intézni egy adott szolgáltatásra vonatkozóan anélkül, hogy bármilyen ellenintézkedés történne. Az egyik legkézenfekvőbb és legelterjedtebb sérülékenység a különböző login felületeknél tapasztalható. Több próbálkozás után a rendszer nem lassítja vagy korlátozza a próbálkozások számát. Egy rosszindulatú felhasználó így rengeteg próbálkozással tud így élni. Előbb-utóbb hozzáférést szerezhet a rendszerhez.
Factory defaults
A gyári beállítások önmagukban hordozzák a veszélyeket. Legyen az bármilyen alkalmazás, fizikai eszköz, vagy bármilyen más hardver / szoftver elem, amennyiben gyári beállításokkal kerül üzembe helyezésre, az kritikus kockázatot rejt magában. A gyári beállításokat bárki megnézheti egy adott eszközhöz, vagy szoftverhez, így hozzáférhet a menedzsment felülethez, átkonfigurálva azt. A gyári beállítások problémája nemcsak jelszavakhoz, hanem egyéb más technikai paraméterhez is kapcsolódhat.
Input Validation
Ebbe a kategóriába tartoznak a különböző kód beszúrásos támadások. A bemeneti mezők nem megfelelő ellenőrzése különböző kártékony kódok beillesztését teszik lehetővé. Ide tartoznak többek között az SQL-injection típusú hibák, vagy az XSS típusú támadások is.
Information Disclosure
Minden olyan típusú hiba ide tartozik, amely valamilyen többletinformációt szolgáltat egy támadónak, amelyet felhasználhat egy későbbi támadáshoz. Ha egy támadó a szerver válaszaiból pontosan meg tudja határozni, hogy milyen típusú, illetve verziójú operációs rendszer fut a szerveren, akkor célzottan tud különböző ismert sérülékenységeket kihasználni az operációs rendszer ellen. Információ kitakarás kategóriába tartozik egy webalkalmazás könyvtár struktúrájának listázhatósága is. Amennyiben feltérképezhető, hogy pontosan milyen fájlok, programok találhatóak a szerveren, akkor azokat elemezve, újabb sérülékenységek tárhatók fel. Tehát ha nincsenek kitakarva a verziók, akkor a verzió alapján rá tud keresni a támadó a sérülékenységre és kihasználhatja azt, amennyiben van olyan sérülékenység az adott verzióban, eljuthat akár az adatbázisig és értékes információkat szerezhet meg.
Misconfiguration
Ebbe a kategóriába több dolog tartozhat. Általában minden olyan problémát ide sorolunk, ami valamilyen téves konfiguráción, vagy konfiguráció hiányán alapszik. A gyári beállításoknál említett problémák, egy az egyben itt is alkalmazhatóak. Ide tartoznak továbbá például a rosszul konfigurált NETBIOS megosztások is, amelyek következtében olyan könyvtárak válnak olvashatóvá, írhatóvá, melyek egy átlag felhasználó számára általában nem elérhetőek. Az egyik legalapvetőbb hiba, a rossz SSL tanúsítványok használata is ide sorolható, vagy a rosszul beállított hálózati protokollok titkosítatlan kommunikációja.
Password management
Ebbe a kategóriába tartozik minden olyan típusú sérülékenység, amely jelszókezelési problémákkal hozható összefüggésbe. A jelszavak hosszának és komplexitásának minőségi kritériumai elengedhetetlen a sérülékenység elkerülése érdekében. Például egy 6-8 karakter hosszú, csak betűt tartalmazó jelszó önmagában rejti a veszélyt, így ezek kijavítása nélkülözhetetlen. Idetartoznak továbbá a különböző rossz jelszó lenyomat (hash) készítési és jelszó titkosítási technikák is. Amennyiben egy vizsgálat során valahol elavult lenyomat (hash) készítés algoritmussal találkozunk (pl: MD5, SHA-1), a sérülékenység ebbe a kategóriába lesz besorolva. Minden olyan probléma, ahol a jelszó kezelésén, tárolásán kell változtatni szintén ebbe a kategóriába fog esni.
Phishing
Az ebbe a sérülékenységi faktorba tartozó hibák közös tulajdonsága, hogy felhasználóktól próbálnak adatokat szerezni illetéktelen módon. Ennek egyik jó példája az e-mailen történő adatszerzés, vagy a különböző honlapok utánzásával végrehajtott adatlopás. Az egyik legelterjedtebb példa, hogy rosszindulatú felhasználók lemásolnak pénzintézeti beléptető felületeket, és e-mailben arra kérik az ügyfelet, hogy jelentkezzen be a hamis online felületen, megszerezve így a felhasználók személyes adatait.
Kockázat vállalása
A megrendelő minden esetben tudomásul veszi és vállalja a penetration testből esetlegesen fakadó károk kockázatát és nem terheli sem anyagilag, sem büntető jogilag a felelősséget a penetration test végző megbízottra.
Nem célunk a károkozás, de nagyon sok problémás rendszert láttunk már. Sajnos minden sérülékeny rendszer tesztelése magában hordozza az esetleges összeomlás (katasztrófa) vagy rendszer megállás lehetőségét. Bármennyire is óvatosak vagyunk és igyekszünk vigyázni a rendszerekre, sajnos előfordulhatnak apróbb problémák.
A mindenkori megrendelő ügyfél felelőssége, hogy felmérje, megbecsülje és engedélyezze vagy tiltsa a kockázatos rendszerek tesztelését és biztosítsa maga számára az esetleges összeomlás utáni helyreállás lehetőségét.
Amennyiben nem rendelkezik a szervezet helyreállítási tervekkel, vagy nem minden szakrendszert fed le, esetleg elvault és/vagy sosem tesztelt, akkor tudunk segíteni ezeknek az elkészítésében, felülvizsgálatában is. Ez egy hosszabb folyamatot vesz igénybe és személyes közreműködést is igényel. Ezek az elhárítási tervek biztosíthatják, hogy a szervezet fel van készülve a tesztelés következtében keletkező hibák kezelésére.
Egyes rendszerek esetében, még ha korábban nem is voltak kockázatosak, illetve instabilak, akkor is előfordulhatnak problémák és összeomlások bizonyos sérülékenységek tesztelése során. Amennyiben köztudott egy sérülékenység kihasználásáról, hogy az problémát okozhat a rendszer működését illetően és erről van előzetes tudomásunk, akkor (súlyosabb esetben) vagy automatikusan eltekintünk a tesztelés során történő sérülékenység kihasználásáról, vagy egyeztetünk a megrendelővel (vagy az által kijelölt technikailag kompetens megbízottal) a kockázatról, és csak jóváhagyás esetén folytatjuk a kockázatos sérülékenységek tesztelését.