A webalkalmazás betöréstesztek során mind automatikus, mind kézi módszerek alkalmazásával célunk a webalkalmazás sérülékenységeinek lehető legteljesebb körű feltárása. Bár az automatikus vizsgálatok nagymértékben megkönnyítik a vizsgálatot végző szakemberek dolgát, illetve lerövidítik a vizsgálatok idejét, nem helyettesíthetik a szakemberek által kézzel végzett vizsgálatokat. Ennek során az automatikus eszközök által talált sebezhetőségek megerősítése, a hamis pozitívok kiszűrése mellett az automatikusan nem megtalálható hiányosságok (pl. logikai hibák) feltárása érdekében manuálisan is teszteljük a webalkalmazásokat.

A vizsgálatok során alkalmazott lépéseink nagyban építenek az industry standard OWASP (Open Web Application Security Project) -ra. Az OWASP alkalmazásfejlesztéssel és karbantartással kapcsolatos javaslatai széles körben elfogadottak és használtak olyan szabványokban, mint például a Payment Card Industry Data Security Standard (PCI-DSS), aminek betartása minden olyan szervezet számára kötelező, ami bankkártya-adatokat kezel, vagy továbbít.

A vizsgálat célja ügyfeleink kijelölt infrastruktúra elemeinek – kritikus üzleti alkalmazások működési környezete, meghatározott szerverek, munkaállomások, hálózati eszközök, stb – vagy akár ügyfeleink teljes belső hálózatának vagy csak adott hálózati tartományának biztonsági vizsgálata, az infrastruktúra elemek sebezhetőségeinek azonosítás, szisztematikusan megvizsgálva az elérhető szolgáltatásokat, függetlenül attól, hogy ezek hálózati, operációs rendszer, adatbázis-, interfész vagy alkalmazás-komponensekben fordulnak elő.

Hardening vizsgálataink során feltárjuk a nem megfelelő beállításból adódó biztonsági kockázatokat. Ezeknek a felderítése az általunk átadott és a Megbízó által előzetesen bevizsgált scriptek futtatása során keletkezett kimenetek analízisével, vagy a Megbízó által biztosított magas jogosultságok birtokában történhet.

A vizsgálatok eredményes elvégzése érdekében olyan jól bevált módszertanokat és ellenőrzési listákat használunk fel, melyeket multinacionális nagyvállalatok, katonai- valamint kormányszervek is saját vizsgálataik alapjának tekintenek, mint a Center for Internet Security (CIS) és Defense Information Systems Agency (DISA) benchmark és checklist készletei, valamint az adott szolgáltatásra a gyártó által tett ajánlások.

A mobil alkalmazások tesztelése során két kérdésre keressük a választ: biztonságos-e a felhasználó számára (védettek-e az alkalmazás által kezelt adatai), illetve biztonságosan üzemeltethető-e a háttérrendszer.

Ehhez statikus (Static Application Security Testing – SAST) és dinamikus (Dynamic Application Security Testing – DAST) vizsgálati módszereket is használunk. Előbbi esetén az alkalmazást nem futtatjuk, mindössze a kapott telepítőcsomag, illetve az eszközre már feltelepített állományok átnézése, visszafejtése alapján végezzük a vizsgálatot. Ennek része az adott mobil platform által nyújtott biztonságot növelő funkciók megfelelő használatának ellenőrzése is.

Dinamikus tesztelés során az alkalmazást futás közben vizsgáljuk. Ebben a szakaszban a fő tesztelési pontok a háttérrendszerrel történő kommunikáció és a fájlrendszeren történt módosítások, a tárolt adatok biztonságossága. Az esetek túlnyomó részében a háttérrendszer egy webes API, tehát a webalkalmazás tesztelési módszertanunk alkalmazható, de csapatunk felkészült egyedi, akár teljesen zárt megoldások vizsgálatára is.

A vastagkliens alkalmazások tesztelése során két kérdésre keressük a választ: biztonságos-e a felhasználó számára (védettek-e az alkalmazás által kezelt adatai), illetve biztonságosan üzemeltethető-e a háttérrendszer.

Ehhez statikus (Static Application Security Testing – SAST) és dinamikus (Dynamic Application Security Testing – DAST) vizsgálati módszereket is használunk. Előbbi esetén az alkalmazást nem futtatjuk, mindössze a kapott telepítőcsomag, illetve a számítógépre már feltelepített állományok átnézése, visszafejtése alapján végezzük a vizsgálatot.

Dinamikus tesztelés során az alkalmazást futás közben vizsgáljuk. Ebben a szakaszban a fő tesztelési pontok a háttérrendszerrel történő kommunikáció és a futtató eszközön történt módosítások, a tárolt adatok biztonságossága. Amennyiben a háttérrendszerrel egy webes API-n keresztül történik a kommunikáció, a webalkalmazás tesztelési módszertanunkat alkalmazzuk, de csapatunk felkészült egyedi, akár teljesen zárt megoldások vizsgálatára is.

A vizsgálatok a vezeték nélküli hálózatok felderítését, az elérhető AP-k, illetve ad-hoc kapcsolatok aircrack-ng programcsomaggal történő feltérképezését foglalják magukban. Ennek során a hálózati forgalom lehallgatásával próbálunk szenzitív információkhoz, hozzáférési adatokhoz jutni. Vizsgáljuk a használt titkosításokat, brute-force módszerekkel megpróbáljuk megszerezni a jelszavakat. WPA2 hálózatok esetén az AP-kliens közötti 4-way handshake elkapásán alapuló támadás helyett/mellett az úgynevezett PMKID feltörésén ala-puló támadással is próbálkozunk.

A fentieken kívül a kliens oldali támadások is részét képezi a teszteknek. Ennek során egy, a Megbízó hálózatának SSID-jával megegyező nevű hálózatot hozunk létre, amivel megpróbáljuk megszerezni a kliensek bejelentkezési információit.

A felhőszolgáltatások egyre szélesebb körű térnyerése indokolja a biztonsági vizsgálatok kiterjesztését a felhőben üzemelő infrastruktúra elemekre is. A vizsgálatok alapjaiban nem térnek el az általános infrastruktúra és hardening vizsgálatoktól, de a felhő jellege miatt eltérő módszereket, eszközöket és ismereteket kívánhatnak meg a vizsgálatot végző szakembertől.

Tűzfal vizsgálataink során egyrészt elvégezzük az általános beállítások felülvizsgálatát a gyártói, illetve egyéb iparági ajánlások alapján. Ennek során feltárásra kerülnek többek között a nem megfelelő felhasználókezelésből, felesleges szolgáltatások engedélyezéséből adódó biztonsági kockázatok. A vizsgálatok második, általában nagyobb terjedelmű része a szabályrendszer vizsgálata. Ennek során feltárjuk a túlságosan megengedő szabályok, nem biztonságos szolgáltatások/adatforgalom engedélyezése, és egyéb logikai, tervezési hibák által okozott kockázatokat.

A vizsgált rendszer forráskód analízisét elsődlegesen mintavételezéssel végezzük. Ennek első lépéseként meghatározzuk a biztonsági szempontból kulcsfontosságú – adatvalidáció, authentikáció / authorizáció, munkamenet-kezelés, érzékeny adatok kezelése, titkosítás, stb. –  kódrészeket, majd a részletes vizsgálatokat ezen kódrészeken végezzük el.  A vizsgálatok mind azt a célt szolgálják, hogy kiderüljön, az alkalmazás megfelelően implementálja-e a fenti listában szereplő funkciókat.

Természetesen a forráskód-vizsgálat nem kizárólag a biztonsági kontrollok megfelelő implementálását hivatott ellenőrizni, része a logikai hibák feltárása, illetve az adott nyelvek, keretrendszerek, használt komponensek által nyújtott biztonsági megoldások, vagy éppen az ezeket érintő gyakori „csapdák” ellenőrzése is.

A hagyományos technológiai vizsgálatokkal szemben, Red Teaming vizsgálataink célja nem egy-egy komponens sebezhetőségeinek minél szélesebb körű azonosítása és esetleges kihasználása, hanem előre meghatározott célpontok kompromittálásához szükséges sérülékenységek feltárása, és tényleges kihasználása.

Amíg az általános sérülékenységvizsgálatok és betöréstesztek célpontjai rendszerint izolált rendszerelemek, a Red Teaming vizsgálatok hatókörébe minden olyan rendszerelem beletartozik, amelyeken keresztül eljuthatunk a kijelölt végső célig, valamint valós képet festenek az adott szervezet infrastruktúrájáról biztonsági szempontból. Bemutatja, hogy a vizsgált infrastruktúrában, vagy szervezetben léteznek-e olyan sérülékenységek, amelyek egy valós támadónak lehetőséget nyújtanak belső erőforrások kompromittálására, ugyanakkor célja annak realizálása is, hogy a szervezet mennyire felkészült az ilyen támadások elleni védekezésre, így a vizsgálatok során azonosításra kerül minden Blue Team – azaz védekező – oldali folyamatbéli és szervezeti sérülékenység is.

A sérülékenységvizsgálat és a betöréstesztelés a biztonsági vizsgálatok két különböző megközelítése. Amíg a sérülékenységvizsgálat egy nem intruzív folyamat, a betöréstesztek során ténylegesen kihasználjuk a vizsgált erőforrásokban található sebezhetőségeket. Habár a betörés tesztek mindig magukban hordoznak egy bizonyos kockázatot (pl. szolgáltatáskiesés), sokkal pontosabb eredményt adnak a tesztelt IT infrastruktúra biztonságára vonatkozólag, illetve egy betöréstesztet minden esetben megelőz egy sérülékenység vizsgálat.

A sérülékenységvizsgálatok lefolytatása során célunk ügyfeleink kijelölt informatikai rendszerelemeiben található ismert sebezhetőségek feltárása biztonsági szoftverek – elsődlegesen Nessus – alkalmazásával, illetve a betörésteszt nélkül azonosítható false-positive találtatok kiszűrésével.

Scroll to Top