Haavatavuste skaneerimine ja turvaline arendus. Osa 1

Professionaalse tegevuse käigus seisavad arendajad, pentesterid ja turvamehed silmitsi selliste protsessidega nagu haavatavuste haldamine (VM) ja (turvaline) SDLC.
Nende fraaside taga peituvad erinevad praktika- ja tööriistakogumid, mis on omavahel seotud, kuigi nende kasutajad on erinevad.

Tehniline edusamm ei ole veel jõudnud sinnamaani, et üks tööriist suudaks asendada inimest infrastruktuuri ja tarkvara turvalisuse analüüsimisel.
On huvitav mõista, miks see nii on ja milliste probleemidega silmitsi seistakse.

Protsessid

Haavatavuste haldamise protsess (Vulnerability Management) on ette nähtud infrastruktuuri turvalisuse pidevaks jälgimiseks ja patch-haldamiseks.
Secure SDLC protsess (turvaline arendustsükkel) on mõeldud rakenduse turvalisuse toetamiseks arenduse ja kasutuse ajal.

Selle protsessi sarnane osa on haavatavuste hindamise protsess, mis hõlmab haavatavuste skaneerimist.
Peamine erinevus VM ja SDLC skaneerimise vahel on see, et esimeses juhtumis on eesmärgiks tuvastada teadaolevaid haavatavusi kolmandate osapoolte tarkvaras või konfiguratsioonis. Näiteks vananenud Windowsi versioon või SNMP vaikeparool.
Teises juhtumis on eesmärgiks avastada haavatavusi mitte ainult kolmandate osapoolte komponentides (sõltuvustes), vaid eelkõige uue toote koodis.

See tekitab erinevusi tööriistades ja lähenemistes. Minu arvates on uute haavatavuste leidmise ülesanne rakenduses oluliselt huvitavam, kuna see ei piira end versioonide sõrmeenamiste, bannerite kogumise, paroolide proovima ja nii edasi.
Kvaliteetsete automatiseeritud rakenduste haavatavuste skaneerimise jaoks on vajalikud algoritmid, mis arvestavad rakenduse semantikat, selle otstarvet ja spetsiifilisi ohte.

Infrastruktuuri skannerit on sageli võimalik asendada ajastiga, nagu väljendas avleonov.. MÕTE on selles, et statistiliselt võite arvestada oma infrastruktuuri haavatavaks, kui te ei ole seda uuendanud näiteks kuu aega.

Tööriistad

Skaneerimist, nagu ka turvalisuse analüüsi, saab teostada nii musta kasti kui ka valge kasti meetodil.

Black Box

Blackbox skaneerimise puhul peab tööriist suudma suhelda teenusega läbi samade liideste, mida kasutavad kasutajad.

Infrastruktuuri skannerid (nt Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose jne) otsivad avatud võrguporte, koguvad "bännereid", määravad paigaldatud tarkvara versioonid ja otsivad oma teadmistebaasist teavet nende versioonide haavatavuste kohta. Samuti püüavad nad avastada konfiguratsiooni vigu, nagu vaikeparoolid või avatud juurdepääs andmetele, nõrgad SSL-krüptod jne.

Veebirakenduste skannerid (nt Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP jne) oskavad samuti tuvastada tuntud komponente ja nende versioone (nt CMS, raamistikud, JS-raamatukogud). Skanneri peamised sammud on kraulimine ja fuzzing.
Kraulimise käigus kogub skanner teavet olemasolevate rakenduse liideste ja HTTP-parameetrite kohta. Fuzzingu käigus sisestatakse kõikidesse avastatud parameetritesse muudetud või genereeritud andmed, et provotseerida viga ja avastada haavatavus.

Sellised rakenduste skannerid kuuluvad DAST ja IAST klassidesse — vastavalt dünaamiline ja interaktiivne rakenduste turvatestimine.

Valge kasti

Valge kasti skannimisega on rohkem erinevusi.
VM protsessi raames antakse skanneritele (nt Vulners, Incsecurity Couch, Vuls, Tenable Nessus jne) sageli juurdepääs süsteemidele, tehes autentitud skanni. Nii saab skanner laadida paigaldatud paketid ja konfiguratsiooni parameetrid otse süsteemist, mitte ei arva neid võrgu teenuste bännereilt.
Skannimine on täpsem ja täielikum.

Kui rääkida valge kasti skannimisest (nt CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs jne) rakenduste puhul, siis räägitakse tavaliselt koodi staatilisest analüüsist ja vastavate SAST klassi tööriistade kasutamisest — staatiline rakenduste turvatestimine.

Probleemid

Skannimisega seondub palju probleeme! Enamikuga neist puutun ma isiklikult kokku teenuse osutamise raames skannimise ja turvalise arendamise protsesside loomisel ning turvaanalüüsi teostamisel.

Toon välja 3 peamist probleemigruppi, mida kinnitavad ka vestlused inseneride ja IT-turbeosakondade juhtidega erinevates ettevõtetes.

Veebirakenduste skannimise probleemid

1. Rakendamise keerukus. Skannerid tuleb konfigureerida ja kohandada igas rakenduses, et luua testikeskkond skannimiseks ning integreerida see CI/CD protsessi, et see oleks tõhus. Vastasel juhul on see kasutu formaalne protseduur, mis toob välja vaid valehäireid.
2. Skannimise kestus. Skannerid ei suuda isegi 2019. aastal hästi hallata liideste dedupikatsiooni ja võivad mitu päeva skannida tuhat lehte, millel on 10 parameetrit, pidamata neid erinevateks, hoolimata sellest, et need on ühesuguse koodi all. Samas on toote tootmisfaasi viimise otsus arendusprotsessi käigus vajalik kiiresti teha.
3. Piinlikud soovitused. Skannerid annavad piisavalt üldisi soovitusi, ning arendajal ei pruugi alati kiirelt selguda, kuidas vähendada riski, ja mis veelgi olulisem, kas seda tuleks teha kohe või oodata.
4. Destruktiivne mõju rakendusele. Skannerid võivad põhjustada rakendusele DoS-rünnaku ning võivad genereerida suures koguses entiteete või muuta olemasolevaid (nt luua kümneid tuhandeid blogikommentaare), seetõttu ei tohiks skannimist tootmisfasXin ilma põhjuseta alustada.
5. Madala kvaliteediga haavatavuste avastamine. Skannerid kasutavad tavaliselt fikseeritud kogumit koormusi („payloads“) ning võivad kergesti jätta avastamata haavatavuse, mis ei sobitu nende tuntud rakenduse käitumise stsenaariumisse.
6. Skanneri arusaam rakenduse funktsioonidest. Skannerid ei tea iseenesest, mis on „internetipank“, „makse“, „kommentaar“. Nende jaoks eksisteerivad vaid lingid ja parameetrid, mistõttu palju võimalikke äriloogika haavatavusi jääb täielikult katmata, nad ei suuda tuvastada kahekordset arveldamist, vaadata kellegi andmeid ID kaudu või muuta saldot ümardamise kaudu.
7. Skanneri arusaam lehtede semantikast. Skannerid ei oska lugeda KKK-sid, ei oska tuvastada captchasid, nad ei mõista iseenesest, kuidas registreerida ning et tuleb uuesti sisse logida, et „log outi“ nuppu ei tohi vajutada ning kuidas peaks muutma parameetrite väärtuste allkirjastamist. Tulemuseks võib enamik rakendusest üldse skannimata jääda.

Probleemid lähtekoodi skannimisel.

1. Valehäired. Statiline analüüs on keeruline ülesanne, mille lahendamisel tuleb sageli teha mitmeid kompromisse. Tihti tuleb ohverdada täpsus, ja isegi kallid ettevõtte skannerid esitavad tohutult valehäireid.
2. Rakendamise keerukus. Statilise analüüsi täpsuse ja täielikkuse suurendamiseks on vaja täiustada skaneerimisreegleid, ning nende reeglite kirjutamine võib olla liiga töömahukas. Mõnikord on lihtsam leida kõik kohad koodis, kus on mingi bugi, ja neid parandada, kui kirjutada reegel selle tuvastamiseks.
3. Sõltuvuste toetuse puudumine. Suured projektid sõltuvad suurest hulgast raamatutest ja raamistikest, mis laiendavad programmeerimiskeele võimalusi. Kui skanneri teadmistebaasis pole teavet nende raamistike ohtlike kohtade („sinks“) kohta, muutub see pime koht, ja skanner ei suuda isegi koodi mõista.
4. Skannimise kestus. Haavatavuste leidmine koodist on keeruline ülesanne ka algoritmide mõistes. Seetõttu võib protsess venida ja nõuda samas olulisi arvutusressursse.
5. Madala katvuse probleem. Hoolimata ressursside tarbimisest ja skaneerimise pikkusest peavad SAST-tööriistade arendajad siiski tegema kompromisse ning analüüsima mitte kõiki olekuid, milles programm võib viibida.
6. Leidude korduvuse küsimus. Konkreetse rea ja kutsumise jungli näitamine, mis toob kaasa haavatavuse, on suurepärane, kuid sageli ei anna skanner piisavalt teavet, et kontrollida haavatavuse olemasolu väljastpoolt. Lõppude lõpuks võib puudus olla ka surnud koodis, mis on ründaja jaoks kättesaamatu.

Infrastruktuuri skaneerimise probleemid.

1. Ebapiisav inventuur. Suurtel infrastruktuuridel, eriti geograafiliselt jagatud, on tihti kõige raskem mõista, milliseid hoste tuleb skandeerida. Teisisõnu, skaneerimise ülesanne on tihedalt seotud varade haldamise ülesandega.
2. Halb prioriteetimine. Võrgu skannerid esitavad sageli palju tulemusi puudustega, mis praktikas ei ole ekspluateeritavad, kuid formaalselt on nende riskitase kõrge. Tarbija saab aruande, mida on raske tõlgendada, ja pole selge, mida tuleb kõigepealt parandada.
3. Piinlikud soovitused. Skannimise teadmistebaasis on sageli ainult väga üldine teave haavatavuste ja nende parandamise viiside kohta, seega peavad administraatorid kasutama Google'i. Olukord on veidi parem valgekarvaliste skanneritega, mis võivad anda konkreetse käsu parandamiseks.
4. Käsitöö. Infrastruktuurides võib olla palju sõlmi, mis tähendab potentsiaalselt palju puudujääke, mille aruanded tuleb igas iteratsioonis käsitsi läbi vaadata ja analüüsida.
5. Halb katvus. Infrastruktuuri skannimise kvaliteet sõltub otseselt teadmistest haavatavuste ja tarkvaraversioonide kohta. Siiski, testimine., isegi turuliidritel ei ole teadmistest täielikku ülevaadet ning tasuta lahenduste andmebaasides on palju teavet, mida turuliidritel ei ole.
6. Patchimise probleemid. Kõige sagedamini hõlmab haavatavuste patchimine infrastruktuuris paketi värskendamist või konfiguratsioonifaili muutmist. Suur probleem on see, et süsteem, eriti vanad süsteemid, võivad värskendamise tõttu ettearvamatult käituda. Sisuliselt tuleb teha integraatsiooniteste elavas infrastruktuuris tootmises.

Lähteviisid.

Kuidas siis olla?
Rohkem näiteid ja seda, kuidas paljude nimetatud probleemidega võidelda, selgitan järgmistes osades, aga praegu toon välja peamised suunad, millega saab töötada:

1. Erinevate skannimisvahendite agregatsioon. Korralikult kasutades mitmeid skannere, on võimalik saavutada märkimisväärne teadmisteteabe ja detekteerimise kvaliteedi suurenemine. Võib leida isegi rohkem haavatavusi, kui kogutud kõikides skannerites eraldi, samal ajal saades täpsemalt hinnata riski taset ja anda rohkem soovitusi.
2. SAST ja DAST integreerimine. DAST katvust ja SAST täpsust saab suurendada nende vahelise teabe vahetamise kaudu. Algfailidest saab teavet olemasolevate marsruutide kohta ning DAST abil saab kontrollida, kas haavatavus on väljastpoolt nähtav.
3. Machine Learning™. Aastal 2015 andsin ma sellest, (ja veel) statistika rakendamise kohta, et anda skanneritele häkkeri intuitsioon ja kiirendada nende märkimisprotsesse. See on kindlasti toiduks tulevase automaatse turvaseisu analüüsi arendamiseks.
4. IAST integreerimine automaattestide ja OpenAPI-ga. CI/CD-pipeline'i raames on võimalik luua skaneerimisprotsess, mis põhineb HTTP-proksina töötavatel tööriistadel ja funktsionaalsetel testidel, mis töötavad HTTP-põhiselt. OpenAPI/Swagger testid ja lepingud annavad skaneerijale vajalikku teavet andmevoogude kohta ja võimaldavad skannida rakendust erinevates olekutes.
5. Õige konfigureerimine. Iga rakenduse ja infrastruktuuri jaoks tuleb luua sobiv skaneerimisprofiil, mis arvestab liideste arvu ja iseloomu ning kasutatavaid tehnoloogiaid.
6. Skaneerijate kohandamine. Tihti ei ole rakendust võimalik skaneerida ilma skaneerija täiendava töötlemiseta. Näiteks makse värav, kus iga päring peab olema allkirjastatud. Ilma värava protokolli konnektori kirjutamiseta skaneerijad saadavad vale allkirjaga päringud. Samuti on vajalik kirjutada spetsialiseeritud skaneerijad teatud tüüpi puuduste, näiteks: Ohtlik otseobjekti viide.
7. Riskide juhtimine. Erinevate skaneerijate kasutamine ja väliste süsteemidega, nagu varahalduse ja ähvarduste juhtimise integreerimine, võimaldab kasutada riskitaseme hindamiseks mitmesuguseid parameetreid, nii et juhtkond saab objektiivse ülevaate arenduse või infrastruktuuri turvaseisundist.

Jätkake jälgimist ja häirime haavatavuste skaneerimist!

Allikas: habr.com