Kao dio svojih profesionalnih aktivnosti, programeri, pentesteri i stručnjaci za sigurnost moraju se baviti procesima kao što su Vulnerability Management (VM), (Secure) SDLC.
Ispod ovih fraza leže različiti skupovi praksi i korištenih alata koji su međusobno isprepleteni, iako se njihovi korisnici razlikuju.
Tehnički napredak još nije došao do točke u kojoj jedan alat može zamijeniti osobu koja analizira sigurnost infrastrukture i softvera.
Zanimljivo je razumjeti zašto je to tako i s kakvim se problemima čovjek susreće.
procesi
Proces upravljanja ranjivostima dizajniran je za kontinuirani nadzor sigurnosti infrastrukture i upravljanje zakrpama.
Secure SDLC proces ("sigurni razvojni ciklus") osmišljen je za održavanje sigurnosti aplikacije tijekom razvoja i rada.
Sličan dio ovih procesa je Vulnerability Assessment proces – procjena ranjivosti, skeniranje ranjivosti.
Glavna razlika između VM i SDLC skeniranja je u tome što je u prvom slučaju cilj otkriti poznate ranjivosti u softveru ili konfiguraciji treće strane. Na primjer, zastarjela verzija sustava Windows ili zadani niz zajednice za SNMP.
U drugom slučaju, cilj je otkriti ranjivosti ne samo u komponentama trećih strana (ovisnosti), već prvenstveno u kodu novog proizvoda.
To stvara razlike u alatima i pristupima. Po mom mišljenju, zadatak pronalaženja novih ranjivosti u aplikaciji mnogo je zanimljiviji, budući da se ne svodi na verzije otisaka prstiju, prikupljanje bannera, grubo forsiranje lozinki itd.
Za visokokvalitetno automatizirano skeniranje ranjivosti aplikacije potrebni su algoritmi koji uzimaju u obzir semantiku aplikacije, njenu svrhu i specifične prijetnje.
Infrastrukturni skener često se može zamijeniti mjeračem vremena, kako sam rekao . Poanta je da, čisto statistički, svoju infrastrukturu možete smatrati ranjivom ako je niste ažurirali, recimo, mjesec dana.
Alat
Skeniranje, kao i sigurnosna analiza, može se izvesti pomoću crne ili bijele kutije.
Crna kutija
Prilikom skeniranja crne kutije, alat mora moći raditi s uslugom kroz ista sučelja putem kojih korisnici rade s njom.
Infrastrukturni skeneri (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, itd.) traže otvorene mrežne priključke, prikupljaju "bannere", određuju verzije instaliranog softvera i pretražuju svoju bazu znanja za informacije o ranjivostima u tim verzijama. Također pokušavaju otkriti konfiguracijske pogreške kao što su zadane lozinke ili otvoreni pristup podacima, slabe SSL šifre itd.
Skeneri web aplikacija (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, itd.) također mogu identificirati poznate komponente i njihove verzije (na primjer, CMS, frameworks, JS biblioteke). Glavni koraci skenera su puzanje i nejasnoće.
Tijekom indeksiranja, skener prikuplja informacije o postojećim sučeljima aplikacija i HTTP parametrima. Tijekom fuzzinga, mutirani ili generirani podaci umeću se u sve otkrivene parametre kako bi se izazvala pogreška i otkrila ranjivost.
Takvi aplikacijski skeneri pripadaju DAST i IAST klasama - Dynamic i Interactive Application Security Testing, redom.
Bijeli okvir
Postoji više razlika kod skeniranja bijele kutije.
Kao dio VM procesa, skeneri (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, itd.) često dobivaju pristup sustavima izvođenjem provjere autentičnosti skeniranja. Stoga skener može preuzeti instalirane verzije paketa i konfiguracijske parametre izravno iz sustava, bez da ih pogađa iz bannera mrežnih usluga.
Skeniranje je preciznije i potpunije.
Ako govorimo o whitebox skeniranju (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs i dr.) aplikacija, onda obično govorimo o statičkoj analizi koda i korištenju odgovarajućih alata klase SAST - Static Application Security Testing.
Problemi
Mnogo je problema sa skeniranjem! S većinom njih se moram osobno susresti u sklopu pružanja usluge skeniranja izgradnje i sigurnih razvojnih procesa, kao i prilikom provođenja sigurnosnih analiza.
Istaknut ću 3 glavne skupine problema, koje potvrđuju razgovori s inženjerima i voditeljima službi za informacijsku sigurnost u raznim tvrtkama.
Problemi sa skeniranjem web aplikacije
- Poteškoće u provedbi. Skenere je potrebno postaviti, konfigurirati, prilagoditi za svaku aplikaciju, dodijeliti testno okruženje za skeniranje i implementirati u CI/CD proces kako bi ovo bilo učinkovito. U suprotnom, to će biti beskoristan formalni postupak koji će proizvesti samo lažno pozitivne rezultate
- Trajanje skeniranja. Čak i u 2019. skeneri rade loš posao dedupliciranja sučelja i mogu provesti dane skenirajući tisuću stranica s 10 parametara na svakoj, smatrajući ih različitima, iako je za njih odgovoran isti kod. Istodobno, odluka o uvođenju u proizvodnju unutar razvojnog ciklusa mora se donijeti brzo
- Loše preporuke. Skeneri daju prilično općenite preporuke, a programer od njih ne može uvijek brzo shvatiti kako smanjiti razinu rizika, i što je najvažnije, treba li to učiniti odmah ili još nije zastrašujuće
- Destruktivan utjecaj na aplikaciju. Skeneri mogu izvesti DoS napad na aplikaciju, a također mogu stvoriti veliki broj entiteta ili promijeniti postojeće (na primjer, stvoriti desetke tisuća komentara na blogu), tako da ne biste trebali nepromišljeno pokretati skeniranje u produkciji
- Niska kvaliteta otkrivanja ranjivosti. Skeneri obično koriste fiksni niz korisnih podataka i mogu lako propustiti ranjivost koja se ne uklapa u poznati scenarij ponašanja aplikacije.
- Skener ne razumije funkcije aplikacije. Ni sami skeneri ne znaju što je “internet bankarstvo”, “plaćanje”, “komentar”. Za njih postoje samo poveznice i parametri, tako da ogroman sloj mogućih ranjivosti poslovne logike ostaje potpuno nepokriven, neće im pasti na pamet napraviti dvostruki otpis, špijunirati tuđe podatke putem ID-a ili povećati stanje zaokruživanjem
- Skener ne razumije semantiku stranica. Skeneri ne mogu čitati FAQ, ne mogu prepoznati captcha i sami neće shvatiti kako se registrirati i zatim ponovno prijaviti, da ne možete kliknuti “odjava” i kako potpisati zahtjeve pri promjeni parametra vrijednosti. Kao rezultat toga, većina aplikacije možda uopće neće biti skenirana.
Problemi sa skeniranjem izvornog koda
- Lažno pozitivni. Statička analiza je složen zadatak koji uključuje mnoge kompromise. Točnost se često mora žrtvovati, pa čak i skupi poslovni skeneri proizvode ogroman broj lažno pozitivnih rezultata
- Poteškoće u provedbi. Kako bi se povećala točnost i potpunost statičke analize, potrebno je doraditi pravila skeniranja, a pisanje tih pravila može biti previše naporno. Ponekad je lakše pronaći sva mjesta u kodu s nekom vrstom greške i popraviti ih nego napisati pravilo za otkrivanje takvih slučajeva
- Nedostatak podrške ovisnosti. Veliki projekti ovise o velikom broju knjižnica i okvira koji proširuju mogućnosti programskog jezika. Ako baza znanja skenera nema informacije o "potonućima" u tim okvirima, postat će slijepa točka i skener jednostavno neće ni razumjeti kod
- Trajanje skeniranja. Pronalaženje ranjivosti u kodu složen je zadatak u smislu algoritama. Stoga proces može trajati dugo i zahtijevati značajne računalne resurse.
- Niska pokrivenost. Unatoč potrošnji resursa i vremenu skeniranja, razvijači SAST alata i dalje moraju raditi kompromise i analizirati ne sva stanja u kojima bi se program mogao nalaziti
- Ponovljivost nalaza. Ukazivanje na određenu liniju i pozivni skup koji vodi do ranjivosti je sjajno, ali u stvarnosti, skener često ne pruža dovoljno informacija za provjeru prisutnosti ranjivosti izvana. Uostalom, greška može biti i u mrtvom kodu, koji je napadaču nedostupan
Problemi sa skeniranjem infrastrukture
- Nedovoljan inventar. U velikim infrastrukturama, posebno onim geografski odvojenim, često je najteže znati koje hostove skenirati. Drugim riječima, zadatak skeniranja usko je povezan sa zadatkom upravljanja imovinom
- Loše određivanje prioriteta. Mrežni skeneri često daju mnoge rezultate s nedostacima koji se ne mogu iskoristiti u praksi, ali formalno je njihova razina rizika visoka. Potrošač dobiva izvješće koje je teško protumačiti, a nejasno je što prvo treba ispraviti.
- Loše preporuke. Baza znanja skenera često sadrži samo vrlo općenite informacije o ranjivosti i kako je popraviti, pa će se administratori morati naoružati Googleom. Situacija je malo bolja sa whitebox skenerima, koji mogu izdati određenu naredbu za popravak
- Ručni rad. Infrastrukture mogu imati mnogo čvorova, što znači potencijalno mnogo nedostataka, izvješća o kojima se moraju raščlaniti i analizirati ručno pri svakoj iteraciji
- Loša pokrivenost. Kvaliteta skeniranja infrastrukture izravno ovisi o veličini baze znanja o ranjivostima i verzijama softvera. pri čemu, , čak ni vodeći na tržištu nemaju sveobuhvatnu bazu znanja, a baze besplatnih rješenja sadrže mnogo informacija koje vodeći nemaju
- Problemi s krpanjem. Najčešće, krpanje ranjivosti infrastrukture uključuje ažuriranje paketa ili promjenu konfiguracijske datoteke. Veliki je problem u tome što se sustav, osobito naslijeđeni, može ponašati nepredvidivo kao rezultat ažuriranja. U biti ćete morati provesti integracijske testove na živoj infrastrukturi u proizvodnji.
Pristupi
Kako je to moguće?
Reći ću vam više o primjerima i kako se nositi s mnogim od navedenih problema u sljedećim dijelovima, ali za sada ću naznačiti glavne smjerove u kojima možete raditi:
- Skupljanje različitih alata za skeniranje. Ispravnom upotrebom nekoliko skenera možete postići značajno povećanje baze znanja i kvalitete detekcije. Možete pronaći čak i više ranjivosti od ukupnog broja svih zasebno pokrenutih skenera, dok možete točnije procijeniti razinu rizika i dati više preporuka
- Integracija SAST i DAST. Moguće je povećati pokrivenost DAST-a i točnost SAST-a razmjenom informacija između njih. Iz izvora možete dobiti informacije o postojećim rutama, a pomoću DAST-a možete provjeriti je li ranjivost vidljiva izvana
- Strojno učenje™. Godine 2015. I (i ) o korištenju statistike kako bi skenerima dali hakersku intuiciju i ubrzali ih. Ovo je definitivno temelj za razvoj automatizirane sigurnosne analize u budućnosti.
- Integracija IAST-a s autotestovima i OpenAPI-jem. Unutar CI/CD cjevovoda moguće je kreirati proces skeniranja temeljen na alatima koji rade kao HTTP proxy i funkcionalnim testovima koji rade preko HTTP-a. OpenAPI/Swagger testovi i ugovori dat će skeneru informacije koje nedostaju o protoku podataka i omogućiti skeniranje aplikacije u različitim stanjima
- Ispravna konfiguracija. Za svaku aplikaciju i infrastrukturu trebate izraditi odgovarajući profil skeniranja, uzimajući u obzir broj i prirodu sučelja i korištenih tehnologija
- Prilagodba skenera. Često se aplikacija ne može skenirati bez izmjene skenera. Primjer je pristupnik plaćanja u kojem svaki zahtjev mora biti potpisan. Bez upisivanja konektora na gateway protokol, skeneri će bezumno bombardirati zahtjevima s pogrešnim potpisom. Također je potrebno napisati specijalizirane skenere za određenu vrstu defekta, kao npr
- Upravljanje rizicima. Korištenje raznih skenera i integracija s vanjskim sustavima kao što su upravljanje imovinom i upravljanje prijetnjama omogućit će korištenje mnogih parametara za procjenu razine rizika, tako da menadžment može dobiti odgovarajuću sliku trenutnog sigurnosnog stanja razvoja ili infrastrukture.
Pratite nas i prekinimo skeniranje ranjivosti!
Izvor: www.habr.com