Sebezés és biztonságos fejlesztés. 1. rész

A fejlesztők, pentesterek és biztonsági szakértők szakmai tevékenysége során olyan folyamatokkal találkoznak, mint a Vulnerability Management (VM) és a (Secure) SDLC.
Ezek a kifejezések különböző gyakorlatok és eszközök összességét takarják, amelyek egymással összefonódva, bár eltérő fogyasztókkal rendelkeznek.

A technikai fejlődés még nem jutott el odáig, hogy egyetlen eszköz helyettesítse az embert az infrastruktúra és a szoftver biztonsági elemzésében.
Érdekes megérteni, miért van ez így, és milyen problémákkal kell szembenézni.

Folyamatok

A Vulnerability Management („sebezőségek kezelése”) folyamata folyamatosan figyelemmel kíséri az infrastruktúra védelmét és a javítási menedzsmentet.
A Secure SDLC („biztonságos fejlesztési ciklus”) folyamata pedig a biztonság fennmaradását célozza a fejlesztés és üzemeltetés során.

Ezeknek a folyamatoknak hasonló része a Vulnerability Assessment – a sebezőségek felmérése, sebezőségek vizsgálata.
A VM és az SDLC keretein belüli vizsgálat közötti fő különbség, hogy az előbbi esetében a cél a harmadik fél szoftverében vagy konfigurációjában ismert sebezőségek felfedezése. Például egy elavult Windows verzió vagy az SNMP alapértelmezett közösségi hívószava.
A második esetben a cél nemcsak a harmadik féltől származó komponensek (függőségek) sebezőségeinek felfedezése, hanem elsősorban az új termék kódjának felfedezése.

Ez eltéréseket okoz az eszközök és megközelítések között. Véleményem szerint az új sebezőségek keresése az alkalmazásban sokkal érdekesebb feladat, mivel nem merül ki a verziók ujjlenyomatának meghatározásában, a bannerek gyűjtésében, jelszavak kipróbálásában stb.
A minőségi automatizált alkalmazás sebezőségi vizsgálatához olyan algoritmusokra van szükség, amelyek figyelembe veszik az alkalmazás szemantikáját, célját és a specifikus fenyegetéseket.

Az infrastruktúra-ellenőrző gyakran helyettesíthető egy időzítővel, ahogyan azt avleonov. A lényeg az, hogy statisztikai szempontból úgy tekintheti, hogy az infrastruktúrája sebezhető, ha azt nem frissítette, mondjuk, egy hónapig.

Eszközök

A vizsgálat, akárcsak a biztonsági elemzés, végezhető fekete dobozként és fehér dobozként is.

Fekete doboz

A blackbox scan tool should be able to interact with the service through the same interfaces that users do.

Infrastructure scanners (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) search for open network ports, collect "banners", determine the versions of installed software, and look for information on vulnerabilities in those versions in their knowledge base. They also try to detect configuration errors, such as default passwords or open access to data, weak SSL ciphers, etc.

Web application scanners (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) can also identify known components and their versions (for example, CMS, frameworks, JS libraries). The main steps of the scanner are crawling and fuzzing.
During crawling, the scanner collects information about existing application interfaces and HTTP parameters. During fuzzing, mutated or generated data is fed into all discovered parameters to provoke errors and identify vulnerabilities.

These application scanners fall into the DAST and IAST classes — respectively, Dynamic and Interactive Application Security Testing.

White Box

In whitebox scanning, the differences are greater.
As part of the VM process, scanners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) are often given access to the systems by conducting an authenticated scan. This way, the scanner can extract the installed package versions and configuration parameters directly from the system without guessing them from the banners of network services.
The scan becomes more accurate and complete.

When it comes to whitebox scanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) of applications, it usually involves static code analysis and the use of corresponding SAST tools — Static Application Security Testing.

Problems

Many problems arise during scanning! I encounter most of them personally while providing services in building scanning processes and secure development, as well as during vulnerability analysis work.

I will highlight three main groups of problems that are confirmed by conversations with engineers and heads of information security services in various companies.

Web application scanning issues

1. The complexity of implementation. A szkennereket ki kell terjeszteni, konfigurálni és testre szabni minden egyes alkalmazás számára, tesztkörnyezetet kell létrehozni a szkennelésekhez, és be kell intégrálni a CI/CD folyamatba, hogy hatékonyak legyenek. Ellenkező esetben ez egy fölösleges formális eljárás lesz, amely legfeljebb hamis riasztásokat generál.
2. A szkennelés időtartama. A szkennerek még 2019-ben is gyengén teljesítenek az interfészek deduplikálásában, és napokig képesek szkennelni ezer oldalt 10 paraméterrel mindegyiken, azt gondolva, hogy ezek különböznek, pedig ugyanaz a kód felelős értük. Ezenkívül a termelésbe való telepítési döntést a fejlesztési ciklus keretein belül gyorsan kell meghozni.
3. Szűkös ajánlások. A szkennerek elég általános ajánlásokat adnak, és nem mindig tudja a fejlesztő gyorsan megérteni, hogyan csökkentheti a kockázat szintjét, és ami a legfontosabb, hogy ezt most azonnal meg kell-e tennie, vagy még várhat.
4. Destruktív hatás az alkalmazásra. A szkennerek simán végrehajthatnak DoS támadást az alkalmazás ellen, és nagy mennyiségű entitást hozhatnak létre, vagy meglévőket módosíthatnak (például tucatnyi ezer megjegyzést hozva létre a blogban), így nem szabad gondolkodás nélkül elindítani a szkennelést a termelésben.
5. Alacsony sebezhetőség-felfedezési minőség. A szkennerek általában statikus hasznos terheket ("payloads") használnak, és könnyen elmulaszthatják a sebezhetőséget, ha az nem illeszkedik az általuk ismert alkalmazás viselkedési forgatókönyvekbe.
6. Az alkalmazás funkcióinak félreértése a szkenner által. A szkennerek önállóan nem tudják, mi az az "internetbank", "fizetés", "megjegyzés". Számukra csak linkek és paraméterek léteznek, így a vállalati logika esetleges sebezhetőségeinek hatalmas része teljesen fedezhetetlen marad, nem fogják kitalálni, hogyan kell duplán terhelni, hogyan lehet mások adataihoz hozzáférni ID alapján, vagy hogyan lehet egyenleget növelni kerekítéssel.
7. Az oldalak szemantikájának félreértése a szkenner által. A szkennerek nem tudják olvasni a GYIK-et, nem ismerik fel a CAPTCHA-t, önállóan nem tudják kitalálni, hogyan kell regisztrálni, és hogy ezután újra be kell jelentkezni, nem lehet rákattintani a "kijelentkezés" gombra, és hogy hogyan kell aláírni a kéréseket a paraméterek értékeinek megváltoztatásakor. Ennek következtében az alkalmazás nagy része egyáltalán nem lehet beolvasva.

A forráskód szkennelésének problémái.

1. Hamis riasztások. A statikus elemzés bonyolult feladat, amelynek megoldására sok kompromisszumot kell kötni. Gyakran pontosságot kell áldozni, és még a drága vállalati szkennelők is hatalmas mennyiségű hamis pozitív eredményt generálnak.
2. The complexity of implementation. A statikus elemzés pontosságának és teljességének növeléséhez szükséges a szkennelési szabályok fejlesztése, és ezeknek a szabályoknak a megírása túl fáradságosnak bizonyulhat. Néha egyszerűbb megtalálni az összes helyet egy kódban, ahol hiba van, és javítani azokat, mint szabályt írni az ilyen esetek észlelésére.
3. A függőségek támogatásának hiánya. A nagy projektek nagyszámú könyvtől és keretrendszertől függenek, amelyek kiterjesztik a programozási nyelv lehetőségeit. Ha a szkenner tudásbázisában nincs információ a veszélyes helyekről ("sinks") ezekben a keretrendszerekben, akkor ez vakfoltot jelent, és a szkenner egyszerűen nem érti meg a kódot.
4. A szkennelés időtartama. A kódban lévő sebezhetőségek felkutatása bonyolult feladat algoritmusok szempontjából. Ezért a folyamat elhúzódhat, és jelentős számítási erőforrásokat igényelhet.
5. Alacsony lefedettség. Annak ellenére, hogy a szkennelés erőforrásokat igényel és hosszú ideig tart, a SAST-eszközök fejlesztői mégis kompromisszumokra kényszerülnek, és nem minden állapotot elemeznek, amelyben a program előfordulhat.
6. A találatok reprodukálhatósága. A sebezhetőséghez vezető konkrét sor és hívásverem megjelölése nagyszerű, de a valóságban a szkenner gyakran nem ad elegendő információt a sebezhetőség külső ellenőrzésére. Hiszen a hiba lehet akár egy elavult kódban is, amelyhez a támadó nem férhet hozzá.

Infrastruktúra szkennelési problémák.

1. Nem kielégítő leltározás. A nagy infrastruktúrákban, különösen a földrajzilag megosztottakban, legnehezebb megérteni, hogy mely hostokat kell szkennelni. Más szavakkal, a szkennelési feladat szorosan kapcsolódik az eszközkezelési feladathoz.
2. Rossz priorizálás. A hálózati szkennerek gyakran sok olyan hibás eredményt adnak, amelyek a gyakorlatban nem kihasználhatóak, de formálisan magas kockázati szinttel rendelkeznek. A fogyasztó olyan jelentést kap, amelyet nehéz értelmezni, és nem világos, hogy mit kell javítani először.
3. Szűkös ajánlások. A tudásbázisban gyakran csak nagyon általános információ található a sebezhetőségről és a javítási módszerekről, így az adminisztrátoroknak el kell látniuk magukat a Google segítségével. A helyzet valamivel jobb a whitebox-ellenőrzőkkel, amelyek konkrét parancsot adhatnak a javításhoz.
4. Manuális munka. Az infrastruktúrákban sok csomópont lehet, így potenciálisan sok hiba is, amelyeket manuálisan kell elemezni a jelentések révén minden iteráció során.
5. Gyenge lefedettség. Az infrastruktúra ellenőrzésének minősége közvetlenül függ a sebezhetőségekről és a szoftververziókról szóló tudásbázis mennyiségétől. Eközben, kiderül,, még a piacon lévő vezetők tudásbázisa sem teljeskörű, és a szabad megoldások adatbázisaiban sok információ található, amely a vezetők adatbázisaiban nem szerepel.
6. Problémák a hibajavítással. Leggyakrabban a sebezhetőségek javítása az infrastruktúrában csomagfrissítést vagy konfigurációs fájl módosítást jelent. Itt a legnagyobb probléma, hogy a rendszer, különösen a régi rendszerek, kiszámíthatatlanul viselkedhetnek a frissítés következtében. Lényegében integrációs teszteket kell végezni a működő infrastruktúrán a termelési környezetben.

Megközelítések

Mit tegyünk?
A következő részekben bővebben mesélek a példákról és arról, hogyan küzdhetünk a felsorolt problémák sokaságával, de addig is itt van néhány fő irányvonal, amelyekben érdemes dolgozni:

1. Különböző ellenőrző eszközök összegyűjtése. A megfelelő használattal több ellenőr jelentős növekedést érhet el a tudásbázis és a detektálás minőségében. Még több sebezhetőséget is találhatunk, mint amit az összes ellenőr egyenként összesen mutat, miközben pontosabb kockázatértékelést végezhetünk, és több ajánlást adhatunk.
2. A SAST és DAST integrációja. Növelhetjük a DAST lefedettségét és a SAST pontosságát azáltal, hogy információt cserélünk köztük. Az eredeti forrásokból információt nyerhetünk a meglévő útvonalakról, míg a DAST segítségével ellenőrizhetjük, hogy a sebezhetőség látható-e kifelé.
3. Machine Learning™. 2015-ben én beszéltem (és még) a statisztika alkalmazásáról, hogy a szkennelőknek hackerek intuíciót biztosítsanak, és felgyorsítsák őket. Ez határozottan tápláló anyag az automatikus biztonsági elemzés fejlődéséhez a jövőben.
4. IAST integráció automatikus tesztekkel és OpenAPI-val. A CI/CD-pipeline keretein belül lehetőség van olyan scanning folyamat létrehozására, amely HTTP-proxiként működő eszközökön és HTTP-n működő funkcionális teszteken alapul. Az OpenAPI/Swagger tesztek és szerződések számos lényeges információt adnak a scannernek az adatfolyamokról, lehetővé téve, hogy különböző állapotokban beolvassuk az alkalmazást.
5. Megfelelő konfigurálás. Minden alkalmazás és infrastruktúra számára megfelelő scanning profilt kell létrehozni, figyelembe véve a felületek számát és jellegét, valamint a használt technológiákat.
6. Scanner testreszabás. Gyakran előfordul, hogy az alkalmazás nem skanálható a scanner utómunkálatai nélkül. Példa erre egy fizetési gateway, ahol minden kérésnek alá kell írva lennie. Anélkül, hogy írunk egy csatlakozót a gateway protokolljához, a scannerek esze nélkül dobálóznak a hibás aláírású kérésekkel. Ezen kívül speciális scannerek írása is szükséges bizonyos típusú hibákhoz, mint például. Insecure Direct Object Reference
7. Kockázatkezelés. Különböző scannerek használata és integráció külső rendszerekkel, mint például az Eszközkezelés és A Fenyegetések Kezelése, lehetővé teszi, hogy a kockázati szint értékeléséhez számos paramétert használjunk, így a vezetőség pontos képet kaphat a fejlesztés vagy az infrastruktúra aktuális biztonsági állapotáról.

Maradjanak velünk, és lássuk, hogyan zavarhatjuk meg az sebezhetőségi szkennelést!

Forrás: habr.com