Sebezhetőségi vizsgálat és biztonságos fejlesztés. 1. rész

A fejlesztőknek, tesztelőknek és biztonsági szakembereknek szakmai tevékenységük részeként olyan folyamatokkal kell foglalkozniuk, mint a Vulnerability Management (VM), (Secure) SDLC.
E kifejezések alatt különböző gyakorlatok és használt eszközök állnak, amelyek összefonódnak, bár a felhasználók eltérőek.

A technikai fejlődés még nem érte el azt a pontot, ahol egyetlen eszköz helyettesítheti az infrastruktúra és a szoftver biztonságának elemzését.
Érdekes megérteni, miért van ez így, és milyen problémákkal kell szembenéznie.

A folyamatok

A Vulnerability Management folyamatot az infrastruktúra biztonságának és a javítások kezelésének folyamatos nyomon követésére tervezték.
A Secure SDLC folyamat („biztonságos fejlesztési ciklus”) az alkalmazások biztonságának fenntartására szolgál a fejlesztés és a működés során.

Ezeknek a folyamatoknak hasonló része a Vulnerability Assessment folyamat – sebezhetőség felmérése, sebezhetőségi vizsgálat.
A fő különbség a VM és az SDLC szkennelés között, hogy az első esetben a harmadik féltől származó szoftverek vagy konfigurációk ismert sebezhetőségeinek észlelése a cél. Például a Windows elavult verziója vagy az SNMP alapértelmezett közösségi karakterlánca.
A második esetben a sebezhetőségek felderítése nem csak a harmadik féltől származó komponensekben (függőségekben), hanem elsősorban az új termék kódjában a cél.

Ez különbségeket teremt az eszközökben és a megközelítésekben. Szerintem sokkal érdekesebb az új sebezhetőségek felkutatása egy alkalmazásban, hiszen ez nem az ujjlenyomat-verziók gyűjtésén, a bannerek gyűjtésén, a brute-forcing jelszavakon stb.
Az alkalmazások sebezhetőségeinek kiváló minőségű automatizált vizsgálatához olyan algoritmusokra van szükség, amelyek figyelembe veszik az alkalmazás szemantikáját, célját és a konkrét fenyegetéseket.

Az infrastrukturális szkennert gyakran időzítővel lehet helyettesíteni, ahogy én fogalmaztam avleonov. A lényeg az, hogy pusztán statisztikailag sérülékenynek tekintheti az infrastruktúráját, ha mondjuk egy hónapja nem frissítette.

Tools

A szkennelés a biztonsági elemzéshez hasonlóan fekete vagy fehér doboz használatával is elvégezhető.

Black Box

Blackbox szkenneléskor az eszköznek képesnek kell lennie a szolgáltatással együttműködni ugyanazokon az interfészeken keresztül, amelyeken keresztül a felhasználók dolgoznak vele.

Az infrastruktúra szkennerek (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose stb.) nyitott hálózati portokat keresnek, „bannereket” gyűjtenek, meghatározzák a telepített szoftverek verzióit, és tudásbázisukban keresnek információkat ezeknek a verzióknak a sebezhetőségeiről. Megpróbálják észlelni a konfigurációs hibákat is, például az alapértelmezett jelszavakat vagy a nyílt adathozzáférést, a gyenge SSL-rejtjeleket stb.

A webalkalmazás-szkennerek (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP stb.) szintén azonosítani tudják az ismert komponenseket és azok verzióit (például CMS, keretrendszerek, JS könyvtárak). A szkenner fő lépései a feltérképezés és a fuzzolás.
A bejárás során a lapolvasó információkat gyűjt a meglévő alkalmazási felületekről és HTTP-paraméterekről. A fuzzing során az összes észlelt paraméterbe mutált vagy generált adatokat illesztenek be, hogy hibát idézzenek elő és sérülékenységet észleljenek.

Az ilyen alkalmazásszkennerek a DAST és az IAST osztályba tartoznak – dinamikus és interaktív alkalmazásbiztonsági tesztelés.

Fehér doboz

Több különbség van a whitebox szkenneléssel kapcsolatban.
A virtuális gép folyamatának részeként a szkennerek (Vulners, Insecurity Couch, Vuls, Tenable Nessus stb.) gyakran hitelesített vizsgálat végrehajtásával kapnak hozzáférést a rendszerekhez. Így a lapolvasó közvetlenül a rendszerből töltheti le a telepített csomagverziókat és konfigurációs paramétereket anélkül, hogy kitalálná azokat a hálózati szolgáltatás szalaghirdetéseiről.
A szkennelés pontosabb és teljesebb.

Ha az alkalmazások whitebox szkenneléséről (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs stb.) beszélünk, akkor általában statikus kódelemzésről és a SAST osztály megfelelő eszközeinek használatáról beszélünk - Static Application Security Testing.

Problémák

Sok probléma van a szkenneléssel! Legtöbbjükkel személyesen kell foglalkoznom a szkennelési és biztonságos fejlesztési folyamatok kiépítéséhez szükséges szolgáltatás keretében, valamint biztonsági elemző munkák elvégzése során.

A problémák 3 fő csoportját emelem ki, amelyeket a különböző cégeknél folytatott mérnökökkel és információbiztonsági szolgálatok vezetőivel folytatott beszélgetések is megerősítenek.

Webes alkalmazások szkennelésével kapcsolatos problémák

1. A megvalósítás nehézségei. A szkennereket minden alkalmazáshoz telepíteni, konfigurálni, testre kell szabni, tesztkörnyezetet kell kijelölni a szkenneléshez, és implementálni kell a CI/CD folyamatban ahhoz, hogy ez hatékony legyen. Ellenkező esetben ez egy haszontalan formális eljárás lesz, amely csak hamis pozitív eredményeket produkál
2. Szkennelés időtartama. A szkennerek még 2019-ben is rosszul végzik el az interfészek duplikálásának megszüntetését, és napokig eltölthetnek ezer oldal szkennelésével, mindegyiken 10 paraméterrel, miközben azokat eltérőnek tekintik, bár ugyanaz a kód felelős értük. Ugyanakkor gyorsan meg kell hozni a döntést a fejlesztési cikluson belüli üzembe helyezésről
3. Gyenge ajánlások. A szkennerek meglehetősen általános ajánlásokat adnak, és a fejlesztő nem mindig tudja gyorsan megérteni belőlük, hogyan csökkentheti a kockázati szintet, és ami a legfontosabb, hogy ezt most kell-e megtenni, vagy még nem ijesztő
4. Pusztító hatás az alkalmazásra. A szkennerek DoS támadást hajthatnak végre egy alkalmazáson, és nagyszámú entitást hozhatnak létre, vagy megváltoztathatják a meglévőket (például több tízezer megjegyzést hozhatnak létre egy blogon), így nem szabad meggondolatlanul elindítani egy vizsgálatot éles környezetben.
5. A sebezhetőség észlelésének alacsony minősége. A szkennerek általában rögzített rakománytömböt használnak, és könnyen kihagyhatnak egy olyan biztonsági rést, amely nem illeszkedik az alkalmazás ismert viselkedési forgatókönyvébe.
6. A lapolvasó nem érti az alkalmazás funkcióit. Maguk a szkennerek nem tudják, mi az „internetes bankolás”, „fizetés”, „megjegyzés”. Számukra csak linkek és paraméterek vannak, így a lehetséges üzleti logikai sebezhetőségek hatalmas rétege teljesen feltáratlan marad, eszükbe sem jut kettős leírás, valaki más adatainak azonosítóval való kémkedése, vagy az egyenleg kerekítéssel történő növelése.
7. A lapolvasó nem érti az oldalak szemantikáját. A szkennerek nem tudják elolvasni a GYIK-et, nem ismerik fel a captchákat, és maguktól nem jönnek rá, hogyan kell regisztrálni, majd újra bejelentkezni, hogy nem lehet rákattintani a „kijelentkezésre” és hogyan kell aláírni a kéréseket a paraméter megváltoztatásakor. értékeket. Ennek eredményeként előfordulhat, hogy az alkalmazások nagy részét egyáltalán nem vizsgálják.

Problémák a forráskód beolvasása közben

1. Hamis pozitívumok. A statikus elemzés összetett feladat, amely számos kompromisszumot tartalmaz. A pontosságot gyakran fel kell áldozni, és még a drága vállalati szkennerek is rengeteg hamis pozitív eredményt produkálnak
2. A megvalósítás nehézségei. A statikus elemzés pontosságának és teljességének növelése érdekében a szkennelési szabályok finomítása szükséges, ezek megírása túlságosan munkaigényes lehet. Néha könnyebb megtalálni és kijavítani a kód összes helyét, ahol valamilyen hiba található, mint szabályt írni az ilyen esetek észlelésére
3. A függőségi támogatás hiánya. A nagy projektek nagyszámú könyvtártól és keretrendszertől függenek, amelyek kiterjesztik a programozási nyelv képességeit. Ha a szkenner tudásbázisa nem rendelkezik információval ezekben a keretrendszerekben található „nyelőkről”, akkor vakfolttá válik, és a szkenner egyszerűen nem is érti a kódot.
4. Szkennelés időtartama. A kódban lévő sebezhetőségek felkutatása algoritmusok szempontjából összetett feladat. Ezért a folyamat hosszú ideig tarthat, és jelentős számítási erőforrásokat igényelhet.
5. Alacsony lefedettség. Az erőforrás-felhasználás és a szkennelési idő ellenére a SAST eszköz fejlesztőinek továbbra is kompromisszumokat kell kötniük, és nem minden állapotot kell elemezniük, amelyben a program esetleg található.
6. A leletek reprodukálhatósága. A sérülékenységhez vezető konkrét vonalra és hívási veremre mutatni nagyszerű, de a valóságban a szkenner gyakran nem ad elegendő információt ahhoz, hogy kívülről ellenőrizze a sérülékenység jelenlétét. Végül is a hiba holt kódban is lehet, ami elérhetetlen a támadó számára

Infrastruktúra szkennelési problémák

1. Elégtelen készlet. Nagy infrastruktúrákban, különösen a földrajzilag elválasztottakban, gyakran a legnehezebb tudni, hogy mely gazdagépeket kell vizsgálni. Más szóval, a szkennelési feladat szorosan kapcsolódik az eszközkezelési feladathoz
2. Rossz prioritás. A hálózati szkennerek gyakran számos eredményt produkálnak olyan hibákkal, amelyeket a gyakorlatban nem lehet kihasználni, de formálisan magas a kockázati szintjük. A fogyasztó nehezen értelmezhető bejelentést kap, és nem világos, hogy mit kell először korrigálni.
3. Gyenge ajánlások. A szkenner tudásbázisa gyakran csak nagyon általános információkat tartalmaz a sérülékenységről és annak kijavításáról, így a rendszergazdáknak fel kell vértezniük magukat a Google-lal. Kicsit jobb a helyzet a whitebox szkennerekkel, amelyek egy adott parancsot adhatnak ki a javításra
4. Kézzel készített. Az infrastruktúráknak sok csomópontja lehet, ami potenciálisan sok hibát jelent, amelyek jelentését minden iterációnál manuálisan kell elemezni és elemezni.
5. Gyenge lefedettség. Az infrastruktúra-ellenőrzés minősége közvetlenül függ a sebezhetőségekről és a szoftververziókról szóló tudásbázis méretétől. ahol, kiderül, még a piacvezetők sem rendelkeznek átfogó tudásbázissal, az ingyenes megoldások adatbázisai pedig rengeteg olyan információt tartalmaznak, amivel a vezetők nem rendelkeznek
6. Problémák a foltozással. Az infrastruktúra sebezhetőségeinek javítása leggyakrabban egy csomag frissítését vagy egy konfigurációs fájl módosítását foglalja magában. A nagy probléma itt az, hogy egy rendszer, különösen egy örökölt, egy frissítés hatására kiszámíthatatlanul viselkedhet. Lényegében integrációs teszteket kell végrehajtania az éles infrastruktúrán a termelésben.

Megközelít

Hogy lehet ez?
A következő részekben többet fogok elmondani a példákról és a felsorolt ​​problémák kezelésének módjáról, de most megjelölöm a fő irányokat, amelyekben dolgozhat:

1. Különféle szkennelő eszközök összesítése. Több szkenner helyes használatával jelentősen növelhető a tudásbázis és az észlelés minősége. Még több sebezhetőséget találhat, mint az összes külön elindított szkenner összesen, miközben pontosabban felmérheti a kockázati szintet és több javaslatot tehet
2. A SAST és a DAST integrációja. A DAST lefedettsége és a SAST pontossága növelhető a köztük lévő információcserével. A forrásokból információkat kaphat a meglévő útvonalakról, a DAST segítségével pedig ellenőrizheti, hogy a sérülékenység kívülről látható-e
3. Machine Learning™. 2015-ben I mondta (és több). Ez mindenképpen tápanyag az automatizált biztonsági elemzések jövőbeni fejlesztéséhez.
4. Az IAST integrálása automatikus tesztekkel és OpenAPI-val. A CI/CD folyamaton belül lehetőség van HTTP-proxyként működő eszközökön és HTTP-n keresztül működő funkcionális teszteken alapuló vizsgálati folyamat létrehozására. Az OpenAPI/Swagger tesztek és szerződések megadják a szkennernek a hiányzó információkat az adatfolyamokról, és lehetővé teszik az alkalmazás különböző állapotú vizsgálatát.
5. Helyes konfiguráció. Minden alkalmazáshoz és infrastruktúrához megfelelő szkennelési profilt kell létrehozni, figyelembe véve az interfészek számát és jellegét, valamint a használt technológiákat.
6. Szkenner testreszabása. Egy alkalmazást gyakran nem lehet beolvasni a szkenner módosítása nélkül. Példa erre a fizetési átjáró, amelyben minden kérést alá kell írni. Anélkül, hogy csatlakozót írnának az átjáróprotokollhoz, a szkennerek ész nélkül bombázzák a rossz aláírású kéréseket. Szükséges továbbá speciális szkennerek írása egy adott típusú hiba esetén, mint pl Nem biztonságos közvetlen objektum hivatkozás
7. Kockázat kezelés. A különféle szkennerek használata és a külső rendszerekkel, például az eszközkezeléssel és a veszélykezeléssel való integráció lehetővé teszi számos paraméter használatát a kockázati szint felméréséhez, így a menedzsment megfelelő képet kaphat a fejlesztés vagy az infrastruktúra jelenlegi biztonsági állapotáról.

Maradjon velünk, és szakítsuk meg a sebezhetőségi vizsgálatot!

Forrás: will.com