Wapiti — biztonsági ellenőrzés saját hatáskörben

A múltban a Spotify döntéshozatali módszertanáról. Egyre több felhasználó preferálja a zenehallgatást mobilon a streaming szolgáltatásban, de a cégnél túlnyomórészt webprogramozók dolgoznak. A Spotify elemezte ezt a helyzetet, és úgy döntött, hogy több mobilfejlesztőt vesz fel, valamint átnevezi a webes szakembereket új irányba: beszéltünk a Nemesida WAF Free — ingyenes eszköz a weboldalak és API-k védelmére a hekkertámadások ellen, és ebben a cikkben a népszerű sebezhetőségi szkenner áttekintését szerettük volna bemutatni Wapiti.

A weboldal sebezhetőségének vizsgálata szükséges lépés, amely, a forráskód elemzésével együtt, lehetővé teszi annak védelmi szintjének értékelését a kompromittálódás ellen. A webes erőforrások szkennelését szakspecifikus eszközkészlettel végezhetjük.

A Nikto, W3af (Python 2.7-ben íródott, amelynek támogatása megszűnt) vagy az Arachni (februártól már nem támogatott) — a legnépszerűbb megoldások, amelyek a szabad szegmensben elérhetők. Természetesen vannak mások is, például a Wapiti, amellyel mi foglalkozunk.

A Wapiti a következő sebezhetőségi típusokkal dolgozik:

• fájlok nyilvánosságra hozatala (helyi és távoli, fopen, readfile);
• befecskendezések (PHP / JSP / ASP / SQL-injekciók és XPath-befecskendezések);
• XSS (cross-site scripting) (visszaverődő és tartós);
• parancsok felfedezése és végrehajtás (eval (), system (), passtru ());
• CRLF-befecskendezések (HTTP válaszok elválasztása, munkamenet rögzítése);
• XXE (XML külső entitás) behatolás;
• SSRF (szerveroldali kérés hamisítása);
• ismertek potenciálisan veszélyes fájlok használata (Nikto adatbázis által);
• gyenge .htaccess konfigurációk, amelyeket meg lehet kerülni;
• bizalmas információk nyilvánosságra hozatala (forráskód felfedése) biztonsági mentési fájlok jelenléte;
• Shellshock;
• nyitott átirányítások;
• nem szabványos HTTP módszerek, amelyeket engedélyezhetnek (PUT).

Lehetőségek:

• HTTP, HTTPS és SOCKS5 proxy támogatás;
• több módszerrel való hitelesítés: Basic, Digest, Kerberos vagy NTLM;
• lehetőség a szkennelési terület korlátozására (domain, mappa, oldal, URL);
• egyetlen paraméter automatikus eltávolítása az URL-ből;
• több óvintézkedés a végtelen szkennelési ciklusok ellen (példa: ifor, értékek korlátozása a paraméterre);
• lehetőség az URL-címek kutatásának prioritásának beállítására (még ha nem is a szkennelési területen találhatók);
• lehetőség bizonyos URL-címek kizárására a szkennelésből és támadásokból (például: logout URL);
• cookie fájlok importálása (megszerzésük a wapiti-getcookie eszközzel);
• SSL tanúsítványok ellenőrzésének aktiválásának/deaktiválásának lehetősége;
• lehetőség URL-ek kinyerésére JavaScript-ből (nagyon egyszerű JS értelmező);
• HTML5-tel való interakció;
• több lehetőség a crawler viselkedésének és korlátozásainak kezelésére;
• a beolvasási folyamat maximális idejének beállítása;
• bizonyos testreszabható HTTP-fejlécek hozzáadása vagy egyedi User-Agent beállítása.

További lehetőségek:

• biztonsági jelentések létrehozása különböző formátumokban (HTML, XML, JSON, TXT);
• a beolvasás vagy támadás felfüggesztése és folytatása (sessziókezelés SQLite3 adatbázis használatával);
• terminálbeli kiemelés a sebezhetőség kiemelésére;
• különböző naplózási szintek;
• gyors és egyszerű módja a támadó modulok aktiválásának / deaktiválásának.

Telepítés

A Wapiti aktuális verzióját 2 módszerrel lehet telepíteni:

• letölteni a forrást a hivatalos oldalról weboldalról és futtatni a telepítő scriptet a Python3 előzetes telepítése után;
• a pip3 install wapiti3 paranccsal.

Ezt követően a Wapiti készen áll a használatra.

Munka az eszközzel

A Wapiti működésének bemutatásához egy külön készített állványt használunk, sites.vulns.pentestit.ru (belső forrás), amely különböző sebezhetőségeket (Injection, XSS, LFI/RFI) és más webalkalmazások hiányosságait tartalmazza.

Az információ kizárólag tájékoztatási célokat szolgál. Ne sértsd meg a törvényeket!

Az alapvető parancs a szkenner indításához:

# wapiti -u <target> <options>

A szkennernek számos részletes dokumentációja van, rengeteg indítási opcióval, például:

—scope — a terjedelem meghatározása
Ha a beolvasandó URL mellett a scope paramétert is megadjuk, szabályozhatjuk a weboldal beolvasási terjedelmét, megadva egyes oldalakat vagy azokat az összes oldalt, amelyet a weboldalon találni lehet.

-s és -x — paraméterek egyes URL-címek hozzáadására vagy eltávolítására. Ezek a paraméterek hasznosak, amikor egy adott URL-címet kell hozzáadni vagy eltávolítani a beolvasási folyamatból.

—skip — a megadott paraméter e kulccsal be lesz olvasva, de nem lesz megtámadva. Hasznos, ha vannak olyan veszélyes paraméterek, amelyeket érdemes kizárni a beolvasás során.

—verify-ssl — a tanúsítvány ellenőrzésének engedélyezése vagy letiltása.
A Wapiti szkenner moduláris. Azonban egyes modulok indításához, amelyek automatikusan csatlakoznak a szkenner futása során, használni kell a -m kapcsolót és felsorolni a szükséges modulokat vesszővel elválasztva. Ha nem használjuk a kapcsolót, akkor alapértelmezés szerint minden modul működni fog. A legegyszerűbb formája így néz ki:

# wapiti -u http://sites.vulns.pentestit.ru/ -m sql,xss,xxe

Ez a használati példa azt jelenti, hogy csak az SQL, XSS és XXE modulokat fogjuk használni a cél szkennelésekor. Ezen kívül a modulok működését is szűrhetjük a kívánt módszer szerint. Például -m “xss: get, blindsql: post, xxe: post”. Ilyen esetben az xss modul az GET módszerrel továbbított lekérdezésekhez lesz alkalmazva, míg a blibdsql modul a POST lekérdezésekhez stb. Egyébként, ha egy modul, amely szerepel a listán, nem volt szükséges a szkennelés során, vagy nagyon sokáig tart, akkor a Ctrl+C kombináció megnyomásával átugorhatjuk a jelenlegi modul használatát, kiválasztva a megfelelő opciót az interaktív menüben.

A Wapiti támogatja a lekérdezések proxy szerveren keresztüli továbbítását a parancsban kulccsal, és a cél weboldalon való hitelesítést az -aparaméter segítségével. Az autentikáció típusát is megadhatjuk: Basiс, Digest, Kerberos és NTLM. Az utolsó kettőhöz további modulok telepítése szükséges lehet. Ezenkívül bármilyen fejlécet (többek között tetszőleges User-Agent) is be lehet illeszteni a lekérdezésekbe, és még sok más.

A hitelesítés használatához használhatjuk az wapiti-getcookieeszközt. Ennek segítségével generáljuk a cookie, amelyet a Wapiti a szkennelés során használni fog. A cookie generálása a következő paranccsal történik:

# wapiti-getcookie -u http://sites.vulns.pentestit.ru/login.php -c cookie.json

Az interaktív módban a kérdésekre válaszolva megadjuk a szükséges információkat, például: felhasználónév, jelszó és egyebek:

A kimenet egy JSON formátumú fájl lesz. Egy másik lehetőség – az összes szükséges információt a -d:

# wapiti-getcookie - http://sites.vulns.pentestit.ru/login.php -c cookie.json -d "username=admin&password=admin&enter=submit"

paraméteren keresztül hozzáadni.

Az eredmény hasonló lesz:

# wapiti --level 1 -u http://sites.vulns.pentestit.ru/ -f html -o /tmp/vulns.html -m all --color -с cookie.json --scope folder --flush-session -A 'Pentestit Scans' -p http://proxy.office.pentestit.ru:3128

A szkenner alapfunkcionalitásának vizsgálatakor a webalkalmazás tesztelésére irányuló végső kérés a következő lett:

-f és -o ahol a többi paraméter mellett:

-m — a jelentés mentésének formátuma és helye;

— az összes modul csatlakoztatása — nem ajánlott, mivel befolyásolja a tesztelési időt és a jelentés méretét; —color

-c — megjelöli a talált sebezhetőségeket azok súlyossága alapján a Wapiti verziója szerint; cookie— a wapiti-getcookie;

—scope fájl használata, amelyet a folder cél kiválasztása az attackáláshoz. Ha a

opciót választjuk, akkor minden URL-t be fogunk szkennelni és támadni a bázisról kezdve. A bázis URL-nek perjellel kell végződnie (fájl név nélkül); —flush-session

-A — lehetővé teszi az újraszkennelést, amely figyelmen kívül hagyja az előző eredményeket; User-Agent;

parancsban — a proxy server address, if needed.

A bit about the report

The scan result is presented in a detailed report format on all identified vulnerabilities in an HTML page, in a clear and understandable manner. The report will specify the categories and number of vulnerabilities found, their description, queries, commands for curl and advice on how to fix them. For easier navigation, a link will be added in the category titles that will allow you to jump to it:

A significant downside of the report is the absence of a map of the web application, without which it will not be clear whether all addresses and parameters have been analyzed. There is also a likelihood of false positives. In our case, the report features 'backup files' and 'potentially dangerous files'. Their count does not reflect reality, as there were no such files on the server:

Potentially, malfunctioning modules may be corrected over time. Another drawback of the report is the lack of color coding for the identified vulnerabilities (depending on their criticality), or at least their classification into categories. The only way we can indirectly understand the criticality of the identified vulnerability is to use the parameter — az összes modul csatlakoztatása — nem ajánlott, mivel befolyásolja a tesztelési időt és a jelentés méretét; during the scan, and then the identified vulnerabilities will be color-coded in various colors:

But in the report itself, such color coding is not provided.

Vulnerabilities

SQLi

The scanner partially succeeded in finding SQLi. When searching for SQL vulnerabilities on pages where authentication is not required, there are no issues:

It was not possible to find vulnerabilities on pages accessible only after authentication, even using valid cookie, as after successful authentication a "session logout" will likely occur and cookie will become invalid. If the deauthorization function were implemented as a separate script responsible for handling this procedure, it could be completely excluded via the -x parameter, thereby preventing its execution. Otherwise, it will not be possible to exclude its processing. This is not a problem of a specific module, but of the tool as a whole, but due to this nuance, multiple injections in the private area of the resource could not be detected.

XSS

A megadott feladattal a szkenner remekül megbirkózott, és megtalálta az összes előkészített sebezhetőséget:

LFI/RFI

A szkenner megtalálta az összes rejtett sebezhetőséget:

Összességében, a hamis riasztások és a sebezhetőségek kihagyása ellenére a Wapiti, mint ingyenes eszköz, meglehetősen jó teljesítményt mutat. Mindenesetre el kell ismerni, hogy a szkenner meglehetősen erős, rugalmas és multifunkcionális, ami a legfontosabb — ingyenes, ezért jogosan használható, segítve az adminisztrátorokat és fejlesztőket az alapvető információk megszerzésében a webalkalmazás biztonsági állapotáról.

Maradjanak egészségesek és védettek!

Forrás: habr.com