ProHoster > IevainojamÄ«bu skenÄ“Å”ana un droÅ”a izstrāde. 1. daļa

IevainojamÄ«bu skenÄ“Å”ana un droÅ”a izstrāde. 1. daļa

IevainojamÄ«bu skenÄ“Å”ana un droÅ”a izstrāde. 1. daļa

Savas profesionālās darbÄ«bas ietvaros izstrādātājiem, testētājiem un droŔības speciālistiem ir jāsadarbojas ar tādiem procesiem kā ievainojamÄ«bas pārvaldÄ«ba (VM), (droŔā) SDLC.
Zem Ŕīm frāzēm slēpjas dažādas prakses un izmantoto rÄ«ku kopas, kas ir savstarpēji saistÄ«tas, lai gan to lietotāji atŔķiras.

Tehniskais progress vēl nav sasniedzis punktu, kurā viens rÄ«ks var aizstāt cilvēku, lai analizētu infrastruktÅ«ras un programmatÅ«ras droŔību.
Ir interesanti saprast, kāpēc tas tā ir un ar kādām problēmām saskaras.

Procesi

NeaizsargātÄ«bas pārvaldÄ«bas process ir paredzēts nepārtrauktai infrastruktÅ«ras droŔības un ielāpu pārvaldÄ«bas uzraudzÄ«bai.
Secure SDLC process (ā€œdroÅ”s izstrādes ciklsā€) ir paredzēts, lai saglabātu lietojumprogrammu droŔību izstrādes un darbÄ«bas laikā.

LÄ«dzÄ«ga Å”o procesu sastāvdaļa ir Vulnerability Assessment process ā€“ ievainojamÄ«bas novērtējums, ievainojamÄ«bas skenÄ“Å”ana.
Galvenā atŔķirÄ«ba starp VM un SDLC skenÄ“Å”anu ir tāda, ka pirmajā gadÄ«jumā mērÄ·is ir atklāt zināmas treŔās puses programmatÅ«ras vai konfigurācijas ievainojamÄ«bas. Piemēram, novecojusi Windows versija vai noklusējuma kopienas virkne SNMP.
Otrajā gadÄ«jumā mērÄ·is ir atklāt ievainojamÄ«bas ne tikai treÅ”o puÅ”u komponentos (atkarÄ«bās), bet galvenokārt jaunā produkta kodā.

Tas rada atŔķirÄ«bas rÄ«kos un pieejās. Manuprāt, uzdevums atrast jaunas ievainojamÄ«bas lietojumprogrammā ir daudz interesantāks, jo tas neattiecas uz pirkstu nospiedumu versijām, baneru vākÅ”anu, brutālu piespieÅ”anu parolēm utt.
KvalitatÄ«vai automatizētai lietojumprogrammu ievainojamÄ«bu skenÄ“Å”anai ir nepiecieÅ”ami algoritmi, kas ņem vērā lietojumprogrammas semantiku, tās mērÄ·i un specifiskos draudus.

Infrastruktūras skeneri bieži var aizstāt ar taimeri, kā es to izteicu avleonovs. Lieta tāda, ka tīri statistiski jūs varat uzskatīt savu infrastruktūru par neaizsargātu, ja neesat to atjauninājis, teiksim, mēnesi.

Darbarīki

SkenÄ“Å”anu, tāpat kā droŔības analÄ«zi, var veikt, izmantojot melno vai balto kastÄ«ti.

Black Box

Melnās kastes skenÄ“Å”anas laikā rÄ«kam jāspēj strādāt ar pakalpojumu, izmantojot tās paÅ”as saskarnes, ar kurām lietotāji strādā ar to.

InfrastruktÅ«ras skeneri (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose u.c.) meklē atvērtos tÄ«kla portus, vāc "banerus", nosaka instalētās programmatÅ«ras versijas un meklē savā zināŔanu bāzē informāciju par Å”o versiju ievainojamÄ«bām. Viņi arÄ« mēģina atklāt konfigurācijas kļūdas, piemēram, noklusējuma paroles vai atvērto datu piekļuvi, vājus SSL Å”ifrus utt.

TÄ«mekļa lietojumprogrammu skeneri (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP u.c.) var identificēt arÄ« zināmos komponentus un to versijas (piemēram, CMS, ietvarus, JS bibliotēkas). Skenera galvenie soļi ir rāpoÅ”ana un izplÅ«dināŔana.
PārmeklÄ“Å”anas laikā skeneris apkopo informāciju par esoÅ”ajām lietojumprogrammu saskarnēm un HTTP parametriem. IzplÅ«des laikā visos atklātajos parametros tiek ievietoti mutēti vai Ä£enerēti dati, lai izraisÄ«tu kļūdu un atklātu ievainojamÄ«bu.

Šādi aplikāciju skeneri pieder pie DAST un IAST klasēm ā€“ attiecÄ«gi Dynamic un Interactive Application Security Testing.

Baltā kaste

Ar baltās kastes skenÄ“Å”anu ir vairāk atŔķirÄ«bu.
Virtuālās maŔīnas procesa ietvaros skeneriem (Vulners, Insecurity Couch, Vuls, Tenable Nessus utt.) bieži tiek nodroÅ”ināta piekļuve sistēmām, veicot autentificētu skenÄ“Å”anu. Tādējādi skeneris var lejupielādēt instalētās pakotnes versijas un konfigurācijas parametrus tieÅ”i no sistēmas, tos neuzminot no tÄ«kla pakalpojumu baneriem.
SkenÄ“Å”ana ir precÄ«zāka un pilnÄ«gāka.

Ja runājam par lietojumprogrammu baltās kastes skenÄ“Å”anu (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs u.c.), tad parasti runa ir par statiskā koda analÄ«zi un atbilstoÅ”u SAST klases rÄ«ku izmantoÅ”anu - Static Application Security Testing.

Problēmas

Ar skenÄ“Å”anu ir daudz problēmu! Ar lielāko daļu man nākas saskarties personÄ«gi, sniedzot pakalpojumu ēku skenÄ“Å”anai un droÅ”u izstrādes procesu, kā arÄ« veicot droŔības analÄ«zes darbus.

IzcelÅ”u 3 galvenās problēmu grupas, ko apliecina sarunas ar inženieriem un informācijas droŔības dienestu vadÄ«tājiem visdažādākajos uzņēmumos.

TÄ«mekļa lietojumprogrammu skenÄ“Å”anas problēmas

  1. ÄŖstenoÅ”anas grÅ«tÄ«bas. Lai tas bÅ«tu efektÄ«vs, skeneri ir jāizvieto, jākonfigurē, jāpielāgo katrai lietojumprogrammai, tiem ir jāpieŔķir pārbaudes vide skenÄ“Å”anai un jāievieÅ” CI/CD procesā. Pretējā gadÄ«jumā tā bÅ«s bezjēdzÄ«ga formāla procedÅ«ra, kas radÄ«s tikai viltus pozitÄ«vus rezultātus
  2. SkenÄ“Å”anas ilgums. Pat 2019. gadā skeneri slikti veic saskarņu dublikāciju un var pavadÄ«t dienas, skenējot tÅ«kstoÅ” lappuÅ”u ar 10 parametriem katrā, uzskatot, ka tās atŔķiras, lai gan par tiem atbild viens un tas pats kods. Tajā paŔā laikā lēmums par izvērÅ”anu ražoÅ”anā izstrādes cikla ietvaros ir jāpieņem ātri
  3. Slikti ieteikumi. Skeneri sniedz diezgan vispārÄ«gus ieteikumus, un izstrādātājs no tiem ne vienmēr var ātri saprast, kā samazināt riska lÄ«meni un, pats galvenais, vai tas ir jādara tieÅ”i tagad, vai tas vēl nav biedējoÅ”i.
  4. DestruktÄ«va ietekme uz pieteikumu. Skeneri var arÄ« veikt DoS uzbrukumu lietojumprogrammai, kā arÄ« var izveidot lielu skaitu entÄ«tiju vai mainÄ«t esoŔās (piemēram, izveidot desmitiem tÅ«kstoÅ”u komentāru emuārā), tāpēc nevajadzētu neapdomÄ«gi sākt skenÄ“Å”anu ražoÅ”anā.
  5. Zema ievainojamÄ«bas noteikÅ”anas kvalitāte. Skeneri parasti izmanto fiksētu derÄ«go kravu masÄ«vu un var viegli palaist garām ievainojamÄ«bu, kas neietilpst lietojumprogrammas zināmajā darbÄ«bas scenārijā.
  6. Skeneris nesaprot lietojumprogrammas funkcijas. PaÅ”i skeneri nezina, kas ir ā€œinternetbankaā€, ā€œmaksājumsā€, ā€œkomentārsā€. Viņiem ir tikai saites un parametri, tāpēc milzÄ«gs iespējamo biznesa loÄ£ikas ievainojamÄ«bu slānis paliek pilnÄ«bā atklāts; viņi nedomās veikt dubultu norakstÄ«Å”anu, izspiegot kāda cita datus, izmantojot ID, vai palielināt atlikumu, izmantojot noapaļoÅ”anu.
  7. Skeneris nesaprot lapu semantiku. Skeneri nevar lasÄ«t FAQ, nevar atpazÄ«t captchas un paÅ”i neizdomās, kā reÄ£istrēties un pēc tam atkārtoti pieteikties, ka nevar noklikŔķināt uz ā€œatteiktiesā€ un kā parakstÄ«t pieprasÄ«jumus, mainot parametru. vērtÄ«bas. Tā rezultātā lielākā daļa lietojumprogrammu var netikt skenēta vispār.

Problēmas ar pirmkoda skenÄ“Å”anu

  1. Viltus pozitīvi. Statiskā analīze ir sarežģīts uzdevums, kas ietver daudzus kompromisus. Precizitāte bieži ir jāupurē, un pat dārgi uzņēmumu skeneri rada milzīgu skaitu viltus pozitīvu rezultātu
  2. ÄŖstenoÅ”anas grÅ«tÄ«bas. Lai palielinātu statiskās analÄ«zes precizitāti un pilnÄ«gumu, ir jāprecizē skenÄ“Å”anas noteikumi, un Å”o noteikumu rakstÄ«Å”ana var bÅ«t pārāk darbietilpÄ«ga. Dažreiz ir vieglāk atrast visas vietas kodā ar kaut kādu kļūdu un tās novērst, nekā uzrakstÄ«t noteikumu, lai atklātu Ŕādus gadÄ«jumus
  3. AtkarÄ«bas atbalsta trÅ«kums. Lieli projekti ir atkarÄ«gi no liela skaita bibliotēku un ietvaru, kas paplaÅ”ina programmÄ“Å”anas valodas iespējas. Ja skenera zināŔanu bāzē nav informācijas par "izlietnēm" Å”ajos ietvaros, tā kļūs par aklo vietu un skeneris vienkārÅ”i pat nesapratÄ«s kodu.
  4. SkenÄ“Å”anas ilgums. Koda ievainojamÄ«bu atraÅ”ana ir sarežģīts uzdevums algoritmu ziņā. Tāpēc process var aizņemt ilgu laiku un prasÄ«t ievērojamus skaitļoÅ”anas resursus.
  5. Zems pārklājums. Neskatoties uz resursu patēriņu un skenÄ“Å”anas laiku, SAST rÄ«ku izstrādātājiem joprojām ir jāpiekāpjas un jāanalizē ne visi stāvokļi, kuros programma var bÅ«t.
  6. Atklājumu reproducējamÄ«ba. NorādÄ«t uz konkrēto lÄ«niju un zvanu steku, kas noved pie ievainojamÄ«bas, ir lieliski, taču patiesÄ«bā bieži vien skeneris nesniedz pietiekami daudz informācijas, lai pārbaudÄ«tu ievainojamÄ«bas esamÄ«bu no ārpuses. Galu galā, kļūda var bÅ«t arÄ« miruÅ”ajā kodā, kas uzbrucējam nav sasniedzams

InfrastruktÅ«ras skenÄ“Å”anas problēmas

  1. Nepietiekams inventārs. Lielās infrastruktÅ«rās, Ä«paÅ”i Ä£eogrāfiski atdalÄ«tās, bieži vien ir visgrÅ«tāk noteikt, kurus saimniekdatorus skenēt. Citiem vārdiem sakot, skenÄ“Å”anas uzdevums ir cieÅ”i saistÄ«ts ar lÄ«dzekļu pārvaldÄ«bas uzdevumu
  2. Slikta prioritāŔu noteikÅ”ana. TÄ«kla skeneri bieži rada daudzus rezultātus ar trÅ«kumiem, kurus nevar izmantot praksē, taču formāli to riska lÄ«menis ir augsts. Patērētājs saņem ziņojumu, kuru ir grÅ«ti interpretēt, un nav skaidrs, kas vispirms ir jālabo.
  3. Slikti ieteikumi. Skenera zināŔanu bāze bieži satur tikai ļoti vispārÄ«gu informāciju par ievainojamÄ«bu un to, kā to novērst, tāpēc administratoriem bÅ«s jābruņojas ar Google. Situācija ir nedaudz labāka ar baltās kastes skeneriem, kas var izdot Ä«paÅ”u komandu, lai to labotu
  4. Roku darbs. Infrastruktūrām var būt daudz mezglu, kas nozīmē potenciāli daudz trūkumu, par kuriem ziņojumi ir jāanalizē un jāanalizē manuāli katrā iterācijā.
  5. Slikts pārklājums. InfrastruktÅ«ras skenÄ“Å”anas kvalitāte ir tieÅ”i atkarÄ«ga no zināŔanu bāzes apjoma par ievainojamÄ«bām un programmatÅ«ras versijām. kurā, izrādās, pat tirgus lÄ«deriem nav visaptveroÅ”as zināŔanu bāzes, un bezmaksas risinājumu datubāzēs ir daudz informācijas, kuras lÄ«deriem nav
  6. Problēmas ar lāpÄ«Å”anu. Visbiežāk infrastruktÅ«ras ievainojamÄ«bu laboÅ”ana ietver pakotnes atjaunināŔanu vai konfigurācijas faila maiņu. Liela problēma Å”eit ir tā, ka sistēma, Ä«paÅ”i mantota, atjaunināŔanas rezultātā var darboties neparedzami. BÅ«tÄ«bā jums bÅ«s jāveic ražoÅ”anas tieŔās infrastruktÅ«ras integrācijas testi.

Pieejas

Kā tad tā?
SÄ«kāk par piemēriem un to, kā risināt daudzas no uzskaitÄ«tajām problēmām, pastāstÄ«Å”u turpmākajās daļās, bet pagaidām norādÄ«Å”u galvenos virzienus, kuros vari strādāt:

  1. Dažādu skenÄ“Å”anas rÄ«ku apkopoÅ”ana. Pareizi izmantojot vairākus skenerus, jÅ«s varat ievērojami palielināt zināŔanu bāzi un noteikÅ”anas kvalitāti. JÅ«s varat atrast pat vairāk ievainojamÄ«bu nekā visi atseviŔķi palaisti skeneri kopā, savukārt jÅ«s varat precÄ«zāk novērtēt riska lÄ«meni un sniegt vairāk ieteikumu
  2. SAST un DAST integrācija. Ir iespējams palielināt DAST pārklājumu un SAST precizitāti, apmainoties ar informāciju. No avotiem varat iegÅ«t informāciju par esoÅ”ajiem marÅ”rutiem, un, izmantojot DAST, varat pārbaudÄ«t, vai ievainojamÄ«ba ir redzama no ārpuses
  3. MaŔīnmācÄ«baā„¢. 2015. gadā I stāstÄ«ja (un vairāk) par statistikas izmantoÅ”anu, lai sniegtu skeneriem hakeru intuÄ«ciju un paātrinātu to darbÄ«bu. Tas noteikti ir lopbarÄ«ba automatizētas droŔības analÄ«zes attÄ«stÄ«bai nākotnē.
  4. IAST integrācija ar automātiskajiem testiem un OpenAPI. CI/CD konveijerā ir iespējams izveidot skenÄ“Å”anas procesu, kura pamatā ir rÄ«ki, kas darbojas kā HTTP starpniekserveris, un funkcionālie testi, kas darbojas, izmantojot HTTP. OpenAPI/Swagger testi un lÄ«gumi sniegs skenerim trÅ«kstoÅ”o informāciju par datu plÅ«smām un ļaus skenēt lietojumprogrammu dažādos stāvokļos
  5. Pareiza konfigurācija. Katrai lietojumprogrammai un infrastruktÅ«rai ir jāizveido piemērots skenÄ“Å”anas profils, ņemot vērā saskarņu skaitu un raksturu un izmantotās tehnoloÄ£ijas.
  6. Skenera pielāgoÅ”ana. Bieži vien lietojumprogrammu nevar skenēt, nepārveidojot skeneri. Piemērs ir maksājumu vārteja, kurā jāparaksta katrs pieprasÄ«jums. Neierakstot savienotāju vārtejas protokolā, skeneri bez prāta bombardēs pieprasÄ«jumus ar nepareizu parakstu. Tāpat ir jāraksta specializēti skeneri konkrētam defekta veidam, piemēram NedroÅ”a tieŔā objekta atsauce
  7. Riska vadÄ«ba. Dažādu skeneru izmantoÅ”ana un integrācija ar ārējām sistēmām, piemēram, Asset Management un Threat Management, ļaus izmantot daudzus parametrus riska lÄ«meņa novērtÄ“Å”anai, lai vadÄ«ba varētu iegÅ«t adekvātu priekÅ”statu par attÄ«stÄ«bas vai infrastruktÅ«ras paÅ”reizējo droŔības stāvokli.

Sekojiet līdzi jaunumiem un izjauksim ievainojamības skenēŔanu!

Avots: www.habr.com

Pievieno komentāru