V rámci profesionálnej činnosti sa vývojári, pentesteri a bezpečnostní experti stretávajú s procesmi ako je správa zraniteľností (VM) a (bezpečný) SDLC.
Pod týmito pojmami sa skrývajú rôzne súbory praktík a nástrojov, ktoré sú navzájom prepojené, hoci ich používatelia sa líšia.
Technický pokrok zatiaľ nedosiahol úroveň, aby mohol jeden nástroj nahradiť človeka pri analýze bezpečnosti infraštruktúry a softvéru.
Zaujímavé je pochopiť, prečo je to tak a s akými problémami sa musíme vyrovnávať.
Procesy
Proces správy zraniteľností (‘vulnerability management’) je určený na nepretržité sledovanie bezpečnosti infraštruktúry a správy opráv.
Proces bezpečného SDLC (‘secure SDLC’) je určený na podporu bezpečnosti aplikácie počas vývoja a prevádzky.
Súvisiacou súčasťou týchto procesov je proces hodnotenia zraniteľností — skenovanie na zraniteľnosti.
Hlavný rozdiel v skenovaní v rámci VM a SDLC spočíva v tom, že v prvom prípade je cieľom odhaliť známe zraniteľnosti v externom softvéri alebo v konfigurácii. Napríklad zastaranú verziu Windows alebo predvolenú komunitnú reťazec pre SNMP.
V druhom prípade je cieľom zistiť zraniteľnosti nielen v externých komponentoch (závislostiach), ale predovšetkým v kóde nového produktu.
To vytvára rozdiely v nástrojoch a prístupoch. Podľa môjho názoru je úloha hľadania nových zraniteľností v aplikácii podstatne zaujímavejšia, pretože sa nezredukuje len na odtlačok verzí, zhromažďovanie bannerov, skúšanie hesiel a podobne.
Na kvalitné automatizované skenovanie zraniteľností aplikácií sú potrebné algoritmy, ktoré zohľadňujú semantiku aplikácie, jej účel a špecifické hrozby.
Infrastrukturálny skener je často možné nahradiť časovačom, ako povedal . Zmyslom je, že čisto štatisticky môžete považovať vašu infraštruktúru za zraniteľnú, ak ste ju neaktualizovali, povedzme, mesiac.
Nástroje
Skenovanie, rovnako ako analýza bezpečnosti, môže byť vykonávané ako čiernou skrinkou, tak aj bielou skrinkou.
Čierna skrinka
Pri blackbox skenovaní musí nástroj vedieť pracovať so službou cez tie isté rozhrania, cez ktoré s ňou pracujú používatelia.
Skenery infraštruktúry (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose atď.) hľadajú otvorené sieťové porty, zbierajú „bannerové“ hlásenia, určujú verzie nainštalovaného softvéru a hľadajú v svojej databáze znalostí informácie o zraniteľnostiach v týchto verziách. Taktiež sa snažia odhaliť chyby konfigurácie, ako sú predvolené heslá alebo otvorený prístup k dátam, slabé SSL šifrovanie atď.
Skenery webových aplikácií (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP atď.) dokážu taktiež určiť známe komponenty a ich verzie (napríklad CMS, frameworky, JS knižnice). Hlavné kroky skenera sú crawl a fuzzing.
Počas crawlingu skener zbiera informácie o existujúcich rozhraniach aplikácie a HTTP parametroch. Počas fuzzingu sú do všetkých zistených parametrov vložené mutované alebo generované dáta s cieľom vyvolať chybu a odhaliť zraniteľnosť.
Takéto skenery aplikácií patrí do tried DAST a IAST — teda Dynamic a Interactive Application Security Testing.
Biely box
Pri whitebox-skenerovaní je rozdielov viac.
V rámci procesu VM skenerom (Vulners, Incsecurity Couch, Vuls, Tenable Nessus atď.) sa často poskytuje prístup k systémom prostredníctvom autentifikovaného skenovania. Takto môže skener načítať nainštalované verzie balíkov a konfiguračné parametre priamo zo systému, bez toho aby ich hádal podľa bannerov sieťových služieb.
Skenovanie je presnejšie a úplnejšie.
Čo sa týka whitebox-skenerovania (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs atď.) aplikácií, spravidla ide o statickú analýzu kódu a využitie príslušných nástrojov triedy SAST — Static Application Security Testing.
Problémy
Vyskytuje sa množstvo problémov so skenovaním! S väčšinou z nich sa stretávam osobne v rámci poskytovania služieb pre budovanie procesov skenovania a bezpečného vývoja, ako aj pri vykonávaní prác na analýze zabezpečenia.
Vypichnem tri hlavné skupiny problémov, ktoré sa potvrdzujú aj v rozhovoroch s inžiniermi a vedúcimi oddelení IT bezpečnosti v rôznych spoločnostiach.
Problémy so skenovaním webových aplikácií
- Náročnosť implementácie. Skenery je potrebné rozložiť, konfigurovať a prispôsobiť každému jednotlivému aplikácií, vyčleniť testovacie prostredie pre skeny a implementovať do procesu CI/CD, aby boli účinné. Inak to bude zbytočná formálna procedúra, ktorá vyprodukuje len falošné poplachy.
- Trvanie skenovania. Skenery sa aj v roku 2019 ťažko vyrovnávajú s deduplikáciou rozhraní a môžu dni skenovať tisíc stránok s desiatimi parametrami na každej, považujúc ich za rôzne, hoci za ne zodpovedá ten istý kód. Rozhodnutie o nasadení na produkciu v rámci vývojového cyklu je potrebné prijať rýchlo.
- Scudné odporúčania. Skenery poskytujú dosť všeobecné odporúčania, a nie vždy môže vývojár rýchlo pochopiť, ako znížiť úroveň rizika, a čo je najdôležitejšie, či to treba robiť práve teraz, alebo to môže počkať.
- Destruktívny dopad na aplikáciu. Skenery môžu vykonať DoS útok na aplikáciu a tiež môžu vytvoriť veľké množstvo entít alebo zmeniť existujúce (napríklad vytvoriť desiatky tisíc komentárov na blogu), takže by ste nemali bezhlavo spúšťať skenovanie v produkcii.
- Nízka kvalita detekcie zraniteľností. Skenery zvyčajne používajú pevný súbor užitočných zaťažení („payloads“) a môžu ľahko vynechať zraniteľnosť, ktorá nezapadá do známeho scenára správania aplikácie.
- Nepochopenie funkcií aplikácie skenerom. Skenery samy o sebe nevedia, čo je to „internetové bankovníctvo“, „platba“, „komentár“. Pre nich existujú iba odkazy a parametre, takže obrovský balík možných zraniteľností obchodnej logiky zostáva úplne nekryté; nebudú vedieť, ako dvakrát zaťažiť alebo nevedia pozrieť cudzí údaje podľa ID, alebo ako nafúknuť zostatok cez zaokrúhľovanie.
- Nepochopenie sémantiky stránok skenerom. Skenery nevedia čítať FAQ, nevedia rozpoznať CAPTCHA, samy o sebe nepochopia, ako sa zaregistrovať, a že je potrebné sa následne prihlásiť znova, že sa nemôže kliknúť na „odhlásiť“ a ako je potrebné podpisovať požiadavky pri zmene hodnôt parametrov. V dôsledku toho môže byť veľká časť aplikácie celkom nezmapovaná.
Problémy so skenovaním zdrojového kódu.
- Falošné poplachy. Statická analýza je zložitá úloha, pri ktorej je potrebné pristúpiť k mnohým kompromisom. Často je nutné obetovať presnosť, a dokonca aj drahé podnikové skenery produkujú obrovské množstvo falošných pozitív.
- Náročnosť implementácie. Na zvýšenie presnosti a úplnosti statickej analýzy je potrebné vypracovať pravidlá skenovania, a písanie týchto pravidiel môže byť príliš pracné. Niekedy je jednoduchšie nájsť všetky miesta v kóde s nejakou chybou a opraviť ich, než napísať pravidlo na detekciu takýchto prípadov.
- Nedostatok podpory závislostí. Veľké projekty závisia od množstva knižníc a rámcov, ktoré rozšírujú možnosti programovacieho jazyka. Ak v databáze znalostí skenera nie je informácia o nebezpečných miestach („sinks“) v týchto rámcoch, stane sa to slepým miestom a skener jednoducho nebude rozumieť kódu.
- Trvanie skenovania. Hľadanie zraniteľností v kóde je zložitá úloha aj z pohľadu algoritmov. Preto sa proces môže predĺžiť a vyžadovať pritom značné výpočtové zdroje.
- Nízka pokrytie. Napriek spotrebe zdrojov a dĺžke skenovania, vývojári SAST nástrojov stále musia pristúpiť k kompromisom a neanalyzujú všetky stavy, v ktorých sa program môže nachádzať.
- Reprodukovateľnosť nálezov. Uvedenie konkrétneho riadku a zásobníka volaní, ktoré vedú k zraniteľnosti, je skvelé, ale v skutočnosti skener často neposkytuje dostatok informácií na overenie prítomnosti zraniteľnosti zvonka. Veď nedostatok môže byť aj v mŕtvom kóde, ktorý nie je pre útočníka prístupný.
Problémy so skenovaním infraštruktúry.
- Nedostatočná inventarizácia. Vo veľkých infraštruktúrach, najmä geograficky rozdelených, je často najťažšie pochopiť, ktoré hostiteľské počítače je potrebné skenovať. Inými slovami, úloha skenovania je úzko spojená s úlohou správy aktív.
- Nedostatočná priorizácia. Sieťové skenery často produkujú veľa výsledkov s nedostatkami, ktoré nie sú v praxi vykonateľné, ale formálne je ich riziková úroveň vysoká. Spotrebiteľ dostáva správu, ktorá je ťažko interpretovateľná, a nie je jasné, čo je potrebné opraviť ako prvé.
- Scudné odporúčania. V databázach znalostí skenerov často existujú iba veľmi všeobecné informácie o zraniteľnosti a spôsoboch jej opravy, takže administrátori sa budú musieť vyzbrojiť Googlom. Situácia je o niečo lepšia s whitebox skenerami, ktoré dokážu poskytnúť konkrétny príkaz na opravu.
- Ručná práca. V infraštruktúrach môže byť veľa uzlov, a teda potenciálne veľa nedostatkov, ktorých správy je potrebné rozoberať a analyzovať ručne pri každej iterácii.
- Zlé pokrytie. Kvalita skenovania infraštruktúry priamo závisí od objemu databázy znalostí o zraniteľnostiach a verziách softvéru. Pri tom, , dokonca aj u lídrov trhu databáza znalostí nie je všadeprítomná, a v databázach bezplatných riešení existuje množstvo informácií, ktoré lídri nemajú.
- Problémy s patchingom. Najčastejšie je patching zraniteľností v infraštruktúre aktualizáciou balíčka alebo zmenou konfiguračného súboru. Veľký problém tu spočíva v tom, že systém, najmä legacy, sa môže pri aktualizácii správať nepredvídateľne. V podstate bude potrebné vykonať integračné testy na živej infraštruktúre v produkcii.
Prístupy.
Čo robiť?
O podrobnostiach príkladov a o tom, ako bojovať s mnohými z uvedených problémov, sa podelím v nasledujúcich častiach, ale zatiaľ uvediem hlavné smery, v ktorých sa dá pracovať:
- Agrégácia rôznych nástrojov na skenovanie. Pri správnom použití viacerých skenerov je možné dosiahnuť významné zvýšenie databázy znalostí a kvality detekcie. Môžete nájsť dokonca viac zraniteľností, než súčet všetkých skenerov, spustených samostatne, pričom môžete presnejšie hodnotiť úroveň rizika a poskytovať viac odporúčaní.
- Integrácia SAST a DAST. Môžete zvýšiť pokrytie DAST a presnosť SAST pomocou výmeny informácií medzi nimi. Z pôvodných zdrojov môžete získať informácie o existujúcich routach, a pomocou DAST môžete overiť, či je zraniteľnosť viditeľná zvonka.
- Strojové učenie™. V roku 2015 som (a ) hovoril o aplikácii štatistiky na to, aby skenerom poskytol intuitívne hľadanie hackerov a urýchlil ich. To určite predstavuje podnet na rozvoj automatizovanej analýzy bezpečnosti v budúcnosti.
- Integrácia IAST s automatizovanými testami a OpenAPI. V rámci CI/CD-pipeline je možné vytvoriť proces skenovania na základe nástrojov, ktoré fungujú ako HTTP proxy, a funkčných testov, ktoré pracujú na HTTP. Testy a zmluvy OpenAPI/Swagger poskytnú skeneru chýbajúce informácie o tokov údajov a umožnia skenovanie aplikácie v rôznych stavoch.
- Správna konfigurácia. Pre každú aplikáciu a infraštruktúru je potrebné vytvoriť vhodný profil skenovania, ktorý zohľadňuje počet a charakter rozhraní, použité technológie.
- Prispôsobenie skenerov. Často nie je možné skenovať aplikáciu bez úprav skeneru. Príklad - platobná brána, kde musí byť každý požiadavok podpísaný. Bez napísania konektora k protokolu brány budú skenery bezmyšlienkovito posielať požiadavky s nesprávnym podpisom. Taktiež je potrebné písať špecializované skenery na konkrétne typy nedostatkov, ako sú
- Rizikový manažment. Použitie rôznych skenerov a integrácia s externými systémami, ako sú správa majetku a správa hrozieb, umožní pri hodnotení úrovne rizika využiť množstvo parametrov, takže vedenie získa adekvátny obraz o aktuálnom stave bezpečnosti vývoja alebo infraštruktúry.
Sledujte nás a poďme rozbiť skenovanie zraniteľností!
Zdroj: habr.com
