Kot del svojih poklicnih dejavnosti se morajo razvijalci, pentesterji in varnostni strokovnjaki ukvarjati s procesi, kot je upravljanje ranljivosti (VM), (varni) SDLC.
Pod temi besednimi zvezami so različni sklopi uporabljenih praks in orodij, ki se prepletajo, čeprav se njihovi uporabniki razlikujejo.
Tehnološki napredek še ni dosegel točke, ko bi lahko eno orodje nadomestilo človeka za analizo varnosti infrastrukture in programske opreme.
Zanimivo je razumeti, zakaj je tako in s kakšnimi težavami se mora soočiti.
Procesi
Proces upravljanja ranljivosti je zasnovan za stalno spremljanje varnosti infrastrukture in upravljanje popravkov.
Proces Secure SDLC ("varen razvojni cikel") je zasnovan za vzdrževanje varnosti aplikacije med razvojem in delovanjem.
Podoben del teh procesov je proces Vulnerability Assessment – ocena ranljivosti, skeniranje ranljivosti.
Glavna razlika med skeniranjem znotraj VM in SDLC je, da je v prvem primeru cilj najti znane ranljivosti v programski opremi tretjih oseb ali v konfiguraciji. Na primer zastarela različica sistema Windows ali privzeti niz skupnosti za SNMP.
V drugem primeru je cilj odkriti ranljivosti ne le v komponentah tretjih oseb (odvisnosti), temveč predvsem v kodi novega izdelka.
To povzroča razlike v orodjih in pristopih. Po mojem mnenju je naloga iskanja novih ranljivosti v aplikaciji veliko bolj zanimiva, saj se ne zmanjša na prstni odtis različice, zbiranje pasic, surovo uporabo gesel itd.
Kakovostno samodejno skeniranje ranljivosti aplikacij zahteva algoritme, ki upoštevajo semantiko aplikacije, njen namen in specifične grožnje.
Infrastrukturni skener je pogosto mogoče zamenjati s časovnikom, kot npr . Bistvo je, da čisto statistično lahko svojo infrastrukturo smatrate za ranljivo, če je niste posodobili recimo en mesec.
Orodja
Skeniranje in varnostna analiza se lahko izvajata kot črna ali bela škatla.
Black Box
Pri skeniranju črne škatle mora biti orodje sposobno delati s storitvijo prek istih vmesnikov, prek katerih z njim delajo uporabniki.
Infrastrukturni skenerji (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose itd.) iščejo odprta omrežna vrata, zbirajo "pasice", identificirajo različice nameščene programske opreme in v svoji bazi znanja iščejo informacije o ranljivostih v teh različicah. Prav tako poskušajo odkriti konfiguracijske napake, kot so privzeta gesla ali javni dostop do podatkov, šibke šifre SSL itd.
Skenerji spletnih aplikacij (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP itd.) lahko zaznajo tudi znane komponente in njihove različice (npr. CMS, okviri, knjižnice JS). Glavni koraki pajkanja so plazenje in fuzzing.
Med pajkom pajek zbira informacije o obstoječih aplikacijskih vmesnikih in parametrih HTTP. Med zamegljevanjem se vsi zaznani parametri nadomestijo z mutiranimi ali ustvarjenimi podatki, da se sproži napaka in odkrije ranljivost.
Takšni skenerji aplikacij spadajo v razrede DAST in IAST - Dynamic oziroma Interactive Application Security Testing.
Bela škatla
Pri skeniranju v beli škatli je več razlik.
Kot del procesa VM imajo skenerji (Vulners, Incsecurity Couch, Vuls, Tenable Nessus itd.) pogosto omogočen dostop do sistemov z izvajanjem preverjanja pristnosti. Tako lahko skener prenese nameščene različice paketov in konfiguracijske parametre neposredno iz sistema, ne da bi jih uganil iz pasic omrežnih storitev.
Skeniranje je natančnejše in popolnejše.
Če govorimo o skeniranju aplikacij (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs ipd.), potem običajno govorimo o statični analizi kode in uporabi ustreznih orodij razreda SAST - Static Application Security Testing.
Težave
S skeniranjem je veliko težav! Z večino jih imam osebno opravka v okviru zagotavljanja storitve gradnje skeniranja in varnih razvojnih procesov ter pri izvajanju varnostnih analiz.
Izpostavil bom 3 glavne skupine težav, ki jih potrjujejo tudi pogovori z inženirji in vodji informacijskovarnostnih služb v različnih podjetjih.
Težave s skeniranjem spletnih aplikacij
- Težavnost izvedbe. Da bi bili skenerji učinkoviti, jih je treba namestiti, konfigurirati, prilagoditi za vsako aplikacijo, jim dodeliti preskusno okolje za skeniranje in jih implementirati v proces CI/CD. V nasprotnem primeru bo to neuporaben formalni postopek, ki bo izdajal samo lažne pozitivne rezultate
- Trajanje skeniranja. Skenerji tudi v letu 2019 slabo delajo z deduplikacijo vmesnikov in lahko več dni skenirajo tisoč strani z vsako po 10 parametrov, pri čemer jih imajo za različne, čeprav je zanje odgovorna ista koda. Hkrati je treba odločitev o uvedbi v proizvodnjo znotraj razvojnega cikla sprejeti hitro.
- Slaba priporočila. Skenerji dajejo dokaj splošna priporočila in razvijalec iz njih ne more vedno hitro razumeti, kako zmanjšati stopnjo tveganja, in kar je najpomembneje, ali je to treba storiti takoj ali še ni strašljivo
- Uničujoč vpliv na aplikacijo. Skenerji zlahka izvedejo DoS napad na aplikacijo, lahko pa tudi ustvarijo veliko število entitet ali spremenijo obstoječe (na primer ustvarijo na desettisoče komentarjev na spletnem dnevniku), zato ne smete nepremišljeno izvajati skeniranja v izdelku.
- Slaba kakovost odkrivanja ranljivosti. Skenerji običajno uporabljajo fiksno matriko uporabnih obremenitev in zlahka zgrešijo ranljivost, ki se ne ujema z njihovim znanim vedenjem aplikacije.
- Optični bralnik ne razume funkcij aplikacije. Skenerji sami ne vedo, kaj je "internetna banka", "plačilo", "komentar". Za njih obstajajo le povezave in parametri, tako da ostane ogromna plast možnih ranljivosti poslovne logike popolnoma nepokrita, ne bodo uganili narediti dvojnega odpisa, pokukati v podatke drugih ljudi z ID-jem ali zaključiti stanja z zaokroževanjem
- Optični bralnik napačno razume semantiko strani. Skenerji ne znajo brati pogostih vprašanj, ne morejo prepoznati captcha, ne bodo sami uganili, kako se registrirati in nato znova prijaviti, da ne morete klikniti "odjava" in kako podpisati zahteve pri spreminjanju vrednosti parametrov. Posledično lahko večina aplikacije sploh ostane nepregledana.
Težave s skeniranjem izvorne kode
- Lažni pozitivni rezultati. Statična analiza je zapletena naloga, ki vključuje številne kompromise. Pogosto morate žrtvovati natančnost in celo dragi optični bralniki za podjetja oddajo ogromno lažno pozitivnih rezultatov.
- Težavnost izvedbe. Za povečanje natančnosti in popolnosti statične analize je potrebno izboljšati pravila skeniranja, pisanje teh pravil pa je lahko preveč zamudno. Včasih je lažje poiskati vsa mesta v kodi s kakšno napako in jih popraviti, kot napisati pravilo za odkrivanje takšnih primerov.
- Pomanjkanje podpore odvisnosti. Veliki projekti so odvisni od velikega števila knjižnic in ogrodij, ki razširjajo zmogljivosti programskega jezika. Če v bazi znanja skenerja ni informacij o nevarnih mestih (»ponorih«) v teh okvirih, bo to postalo slepa pega in skener preprosto ne bo niti razumel kode.
- Trajanje skeniranja. Iskanje ranljivosti v kodi je težka naloga tudi z vidika algoritmov. Zato se lahko postopek zavleče in zahteva precejšnje računalniške vire.
- Nizka pokritost. Kljub porabi virov in trajanju skeniranja se morajo razvijalci orodij SAST še vedno zateči k kompromisom in analizirati ne vseh stanj, v katerih je lahko program.
- Iskanje ponovljivosti. Kazanje na določeno linijo in klicni sklad, ki vodi do ranljivosti, je super, vendar v resnici optični bralnik pogosto ne zagotovi dovolj informacij za preverjanje zunanje ranljivosti. Navsezadnje je lahko napaka tudi v mrtvi kodi, ki je za napadalca nedosegljiva.
Težave s skeniranjem infrastrukture
- Nezadostna zaloga. V velikih infrastrukturah, zlasti geografsko ločenih, je pogosto najtežje ugotoviti, katere gostitelje skenirati. Z drugimi besedami, naloga skeniranja je tesno povezana z nalogo upravljanja sredstev.
- Slabo določanje prioritet. Omrežni skenerji pogosto dajejo številne rezultate s pomanjkljivostmi, ki jih v praksi ni mogoče izkoristiti, vendar je formalno njihova stopnja tveganja visoka. Potrošnik prejme poročilo, ki ga je težko interpretirati in ni jasno, kaj je treba najprej popraviti
- Slaba priporočila. Baza znanja optičnega bralnika pogosto vsebuje le zelo splošne informacije o ranljivosti in o tem, kako jo odpraviti, zato se bodo skrbniki morali oborožiti z Googlom. Stanje je nekoliko boljše pri optičnih bralnikih whitebox, ki lahko izdajo poseben ukaz za popravek
- Ročno delo. Infrastrukture imajo lahko veliko vozlišč, kar pomeni, da obstaja potencialno veliko napak, poročila o katerih je treba razčleniti in analizirati ročno ob vsaki ponovitvi
- Slaba pokritost. Kakovost skeniranja infrastrukture je neposredno odvisna od velikosti baze znanja o ranljivostih in različicah programske opreme. pri čemer, , tudi vodilni na trgu nimajo celovite baze znanja, v bazah brezplačnih rešitev pa je veliko informacij, ki jih vodilni nimajo
- Težave s popravki. Najpogosteje je popravljanje ranljivosti infrastrukture posodabljanje paketa ali spreminjanje konfiguracijske datoteke. Velika težava pri tem je, da se lahko sistem, zlasti stari, zaradi posodobitve obnaša nepredvidljivo. Pravzaprav boste morali izvesti integracijske teste na aktivni infrastrukturi v proizvodnji.
Pristopi
Kako je to mogoče?
V naslednjih delih bom šel podrobneje o primerih in o tem, kako se soočiti s številnimi od teh težav, zdaj pa bom navedel glavna področja, na katerih lahko delate:
- Združevanje različnih orodij za skeniranje. S pravilno uporabo več skenerjev je mogoče doseči znatno povečanje baze znanja in kakovosti detekcije. Najdete lahko celo več ranljivosti kot vsota vseh skenerjev, zagnanih posamično, hkrati pa lahko natančneje ocenite stopnjo tveganja in podate več priporočil
- Integracija SAST in DAST. Možno je povečati pokritost DAST in natančnost SAST z izmenjavo informacij med njima. Iz vira lahko dobite informacije o obstoječih poteh, s pomočjo DAST pa lahko preverite, ali je ranljivost vidna od zunaj
- Strojno učenje™. Leta 2015 sem I (in ) o uporabi statističnih podatkov, da bi skenerjem dali hekersko intuicijo in jih pospešili. To je vsekakor hrana za razvoj avtomatizirane varnostne analize v prihodnosti.
- Integracija IAST s samodejnimi testi in OpenAPI. Znotraj cevovoda CI/CD je mogoče ustvariti postopek skeniranja, ki temelji na orodjih, ki delujejo kot posredniki HTTP, in funkcionalnih testih, ki delujejo prek HTTP. Testi in pogodbe OpenAPI/Swagger bodo optičnemu bralniku dale manjkajoče informacije o tokovih podatkov in omogočile skeniranje aplikacije v različnih stanjih
- Pravilna konfiguracija. Za vsako aplikacijo in infrastrukturo morate ustvariti ustrezen profil skeniranja ob upoštevanju števila in narave vmesnikov, uporabljenih tehnologij
- Prilagajanje optičnega bralnika. Pogosto aplikacije ni mogoče skenirati, ne da bi spremenili optični bralnik. Primer je plačilni prehod, kjer mora biti vsaka zahteva podpisana. Brez zapisovanja konektorja v protokol prehoda bodo skenerji brezglavo kljuvali zahteve z napačnim podpisom. Prav tako je treba napisati specializirane skenerje za določeno vrsto napak, kot npr
- Upravljanje s tveganji. Uporaba različnih skenerjev in integracija z zunanjimi sistemi, kot sta Asset Management in Threat Management, bo omogočila uporabo več parametrov za oceno stopnje tveganja, tako da lahko vodstvo dobi ustrezno sliko o trenutnem varnostnem stanju razvoja ali infrastrukture.
Ostanite z nami in prekinimo skeniranje ranljivosti!
Vir: www.habr.com