Kao deo svojih profesionalnih aktivnosti, programeri, pentesteri i stručnjaci za bezbednost moraju da se bave procesima kao što su upravljanje ranjivostima (VM), (bezbedni) SDLC.
Ispod ovih fraza kriju se različiti skupovi praksi i korištenih alata koji su isprepleteni, iako se njihovi korisnici razlikuju.
Tehnički napredak još nije dostigao tačku da jedan alat može zamijeniti osobu za analizu sigurnosti infrastrukture i softvera.
Zanimljivo je razumjeti zašto je to tako i sa kakvim se problemima susrećemo.
Procesi
Proces upravljanja ranjivostima je dizajniran za kontinuirano praćenje sigurnosti infrastrukture i upravljanje zakrpama.
Secure SDLC proces („sigurni razvojni ciklus“) je dizajniran da održi sigurnost aplikacije tokom razvoja i rada.
Sličan dio ovih procesa je i proces procjene ranjivosti – procjena ranjivosti, skeniranje ranjivosti.
Glavna razlika između VM i SDLC skeniranja je u tome što je u prvom slučaju cilj otkrivanje poznatih ranjivosti u softveru ili konfiguraciji treće strane. Na primjer, zastarjela verzija Windows-a ili zadani niz zajednice za SNMP.
U drugom slučaju, cilj je otkrivanje ranjivosti ne samo u komponentama treće strane (zavisnosti), već prvenstveno u kodu novog proizvoda.
Ovo stvara razlike u alatima i pristupima. Po mom mišljenju, zadatak pronalaženja novih ranjivosti u aplikaciji je mnogo interesantniji, jer se ne svodi na verzije otiska prsta, prikupljanje banera, brute-forcing lozinki itd.
Za visokokvalitetno automatsko skeniranje ranjivosti aplikacije potrebni su algoritmi koji uzimaju u obzir semantiku aplikacije, njenu svrhu i specifične prijetnje.
Infrastrukturni skener se često može zamijeniti tajmerom, kako sam ja to rekao . Poenta je da, čisto statistički, svoju infrastrukturu možete smatrati ranjivom ako je niste ažurirali, recimo, mjesec dana.
Alati
Skeniranje, poput sigurnosne analize, može se izvesti pomoću crne ili bijele kutije.
Crna kutija
Prilikom skeniranja crne kutije, alat mora biti u mogućnosti da radi sa uslugom preko istih sučelja preko kojih korisnici rade s njim.
Infrastrukturni skeneri (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, itd.) pretražuju otvorene mrežne portove, prikupljaju „banere“, određuju verzije instaliranog softvera i pretražuju svoju bazu znanja za informacije o ranjivostima u tim verzijama. Također pokušavaju otkriti greške u konfiguraciji 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, okviri, JS biblioteke). Glavni koraci skenera su puzanje i fuzzing.
Tokom indeksiranja, skener prikuplja informacije o postojećim sučeljima aplikacije i HTTP parametrima. Tokom fuzinga, mutirani ili generisani podaci se ubacuju u sve detektovane parametre kako bi se izazvala greška i otkrila ranjivost.
Takvi skeneri aplikacija pripadaju DAST i IAST klasama - dinamičko i interaktivno testiranje sigurnosti aplikacija, respektivno.
Bijela kutija
Više je razlika kod skeniranja bijelog okvira.
Kao dio VM procesa, skenerima (Vulners, Insecurity Couch, Vuls, Tenable Nessus, itd.) se često daje pristup sistemima izvođenjem proverenog skeniranja. Dakle, skener može preuzeti instalirane verzije paketa i konfiguracijske parametre direktno sa sistema, a da ih ne pogađa sa banera mrežnih usluga.
Skeniranje je preciznije i potpunije.
Ako govorimo o whitebox skeniranju (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, itd.) aplikacija, onda je najčešće riječ o statičkoj analizi koda i korištenju odgovarajućih alata SAST klase - Static Application Security Testing.
Problemi
Mnogo je problema sa skeniranjem! S većinom njih se moram lično suočiti u sklopu pružanja usluge za izgradnju procesa skeniranja i sigurnog razvoja, kao i prilikom obavljanja poslova sigurnosne analize.
Istaknuću 3 glavne grupe problema, koje potvrđuju razgovori sa inženjerima i rukovodiocima službi za sigurnost informacija u raznim kompanijama.
Problemi skeniranja web aplikacija
- Poteškoće u implementaciji. Skeneri moraju biti raspoređeni, konfigurirani, prilagođeni za svaku aplikaciju, dodijeljeno testno okruženje za skeniranje i implementirani u CI/CD proces da bi to bilo učinkovito. U suprotnom, to će biti beskorisna formalna procedura koja će proizvesti samo lažne pozitivne rezultate
- Trajanje skeniranja. Skeneri, čak i 2019. godine, loše rade na uklanjanju duplikata interfejsa i mogu provesti dane skenirajući hiljadu stranica sa 10 parametara na svakoj, smatrajući ih različitim, iako je za njih odgovoran isti kod. Istovremeno, odluka o puštanju u proizvodnju u okviru razvojnog ciklusa mora se donijeti brzo
- Loše preporuke. Skeneri daju prilično općenite preporuke, a programer ne može uvijek brzo shvatiti od njih kako smanjiti razinu rizika, i što je najvažnije, treba li to učiniti odmah ili još nije strašno
- Destruktivan uticaj na aplikaciju. Skeneri mogu dobro izvršiti DoS napad na aplikaciju, a mogu i stvoriti veliki broj entiteta ili promijeniti postojeće (na primjer, kreirati desetke hiljada komentara na blogu), tako da ne biste trebali nepromišljeno pokretati skeniranje u proizvodnji
- Nizak kvalitet detekcije ranjivosti. Skeneri obično koriste fiksni niz korisnih opterećenja i lako mogu propustiti ranjivost koja se ne uklapa u poznati scenarij ponašanja aplikacije.
- Skener ne razumije funkcije aplikacije. Sami skeneri ne znaju šta su “Internet bankarstvo”, “plaćanje”, “komentar”. Za njih postoje samo linkovi i parametri, tako da ogroman sloj mogućih propusta poslovne logike ostaje potpuno neotkriven; neće im pasti na pamet duplo otpisati, špijunirati tuđe podatke po ID-u ili povećati bilans kroz zaokruživanje
- Skener ne razumije semantiku stranica. Skeneri ne mogu da čitaju često postavljana pitanja, ne mogu da prepoznaju captcha, i sami neće shvatiti kako da se registruju i ponovo se prijave, da ne možete da kliknete na „odjava“ i kako da potpišete zahteve prilikom promene parametra vrijednosti. Kao rezultat toga, većina aplikacija možda uopće neće biti skenirana.
Problemi sa skeniranjem izvornog koda
- Lažni pozitivni rezultati. Statička analiza je složen zadatak koji uključuje mnoge kompromise. Preciznost se često mora žrtvovati, a čak i skupi poslovni skeneri proizvode ogroman broj lažnih pozitivnih rezultata
- Poteškoće u implementaciji. Da bi se povećala tačnost i potpunost statičke analize, potrebno je precizirati pravila skeniranja, a pisanje ovih pravila može biti previše radno intenzivno. Ponekad je lakše pronaći sva mjesta u kodu sa nekom vrstom greške i popraviti ih nego napisati pravilo za otkrivanje takvih slučajeva
- Nedostatak podrške zavisnosti. Veliki projekti zavise od velikog broja biblioteka i okvira koji proširuju mogućnosti programskog jezika. Ako baza znanja skenera nema informacije o "slivovima" u ovim okvirima, to će postati slijepa točka i skener jednostavno neće razumjeti kod
- Trajanje skeniranja. Pronalaženje ranjivosti u kodu je složen zadatak u smislu algoritama. Stoga proces može potrajati dugo i zahtijevati značajne računarske resurse.
- Niska pokrivenost. Uprkos potrošnji resursa i vremenu skeniranja, programeri SAST alata i dalje moraju praviti kompromise i analizirati ne sva stanja u kojima program može biti
- Reproducibilnost nalaza. Ukazivanje na određenu liniju i stek poziva koji vodi do ranjivosti je odlično, ali u stvarnosti, skener često ne pruža dovoljno informacija da provjeri prisutnost ranjivosti izvana. Na kraju krajeva, mana može biti i u mrtvom kodu, koji je nedostižan za napadača
Problemi sa skeniranjem infrastrukture
- Nedovoljan inventar. U velikim infrastrukturama, posebno geografski odvojenim, često je najteže znati koje hostove skenirati. Drugim riječima, zadatak skeniranja je usko povezan sa zadatkom upravljanja imovinom
- Loše određivanje prioriteta. Mrežni skeneri često daju mnoge rezultate sa nedostacima koji se ne mogu iskoristiti u praksi, ali formalno njihov nivo rizika je visok. Potrošač dobija izvještaj koji je teško protumačiti i nejasno je šta prvo treba ispraviti.
- Loše preporuke. Baza znanja skenera često sadrži samo vrlo općenite informacije o ranjivosti i kako je popraviti, tako da će administratori morati da se naoružaju Google-om. Situacija je malo bolja sa whitebox skenerima, koji mogu izdati određenu naredbu koju treba popraviti
- Handmade. Infrastrukture mogu imati mnogo čvorova, što znači potencijalno mnogo nedostataka, izvještaji o kojima se moraju raščlaniti i analizirati ručno na svakoj iteraciji
- Loša pokrivenost. Kvalitet skeniranja infrastrukture direktno zavisi od veličine baze znanja o ranjivostima i verzijama softvera. pri čemu, , čak ni tržišni lideri nemaju sveobuhvatnu bazu znanja, a baze besplatnih rješenja sadrže mnogo informacija koje lideri nemaju
- Problemi sa krpljenjem. Najčešće, krpanje ranjivosti infrastrukture uključuje ažuriranje paketa ili promjenu konfiguracijske datoteke. Veliki problem ovdje je što se sistem, posebno naslijeđeni, može ponašati nepredvidivo kao rezultat ažuriranja. U suštini, morat ćete provesti integracijske testove na živoj infrastrukturi u proizvodnji.
Prilazi
Kako biti?
Reći ću vam više o primjerima i načinu rješavanja mnogih od navedenih problema u sljedećim dijelovima, ali za sada ću naznačiti glavne smjerove u kojima možete raditi:
- Agregacija raznih alata za skeniranje. Pravilnom upotrebom nekoliko skenera možete postići značajno povećanje baze znanja i kvaliteta detekcije. Možete pronaći čak i više ranjivosti od ukupnog broja svih skenera pokrenutih zasebno, dok možete preciznije procijeniti nivo rizika i dati više preporuka
- Integracija SAST-a i DAST-a. Moguće je povećati pokrivenost DAST-a i tač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 da li je ranjivost vidljiva izvana
- Machine Learning™. 2015. godine I (i ) o korištenju statistike kako bi se skeneri dali hakerskoj intuiciji i ubrzali ih. Ovo je svakako hrana za razvoj automatizovane bezbednosne analize u budućnosti.
- Integracija IAST-a sa autotestovima i OpenAPI. Unutar CI/CD cevovoda, moguće je kreirati proces skeniranja zasnovan na alatima koji rade kao HTTP proxy i funkcionalnim testovima koji rade preko HTTP-a. OpenAPI/Swagger testovi i ugovori će dati skeneru informacije koje nedostaju o tokovima podataka i omogućiti skeniranje aplikacije u različitim stanjima
- Ispravna konfiguracija. Za svaku aplikaciju i infrastrukturu morate kreirati odgovarajući profil skeniranja, uzimajući u obzir broj i prirodu sučelja i tehnologije koje se koriste
- Prilagodba skenera. Često se aplikacija ne može skenirati bez modifikacije skenera. Primjer je platni prolaz u kojem svaki zahtjev mora biti potpisan. Bez upisivanja konektora u protokol gatewaya, skeneri će bezumno bombardirati zahtjevima s pogrešnim potpisom. Također je potrebno pisati specijalizirane skenere za određenu vrstu kvara, kao npr
- Upravljanje rizicima. Upotreba različitih skenera i integracija sa eksternim sistemima kao što su Asset Management i Threat Management omogućit će korištenje mnogih parametara za procjenu nivoa rizika, tako da menadžment može dobiti adekvatnu sliku o trenutnom sigurnosnom stanju razvoja ili infrastrukture.
Pratite nas i poremetimo skeniranje ranjivosti!
izvor: www.habr.com