No ievainojamības atraduma līdz pārbaudāmam pierādījumam: profesionāla ziņojuma anatomija

Reproducējamība drošības pētniecībā nenozīmē, ka jebkuram cilvēkam jebkurā laikā jāspēj iegūt identisku rezultātu. Daudzas ievainojamības izpaužas tikai specifiskā konfigurācijā, lietotāja lomā, datu stāvoklī vai darbību secībā. Reproducējams atradums nozīmē, ka ir dokumentēti pietiekami priekšnoteikumi un novērojumi, lai cita pilnvarota persona varētu pārbaudīt apgalvojumu un atšķirt to no vides īpatnības, kļūdaina testa vai nepareizas interpretācijas.

Ja pētnieks ziņo par objektu līmeņa autorizācijas kļūdu, ar frāzi “nomainiet identifikatoru URL” nepietiek. Jābūt saprotamam, kā tika izveidoti testa konti, kurš resurss pieder kuram kontam, ko katrai lomai bija paredzēts atļaut un kura konkrētā pārbaude parādīja pretēju rezultātu. Tikai šādi iespējams izvērtēt, vai konstatēta neatļauta piekļuve, paredzēta koplietošanas funkcija vai testēšanas vides konfigurācijas īpatnība.

Reproducēšanas instrukcijai nav obligāti jābūt publiski izpildāmam uzbrukuma skriptam. Daļā gadījumu drošāka būs dokumentēta, ierobežota pārbaude ar testdatiem, kurā redzama kontroles robežas pārkāpšana, bet netiek vākti sveši dati un netiek palielināta piekļuve. GitHub privātās ievainojamību ziņošanas dokumentācijā pieprasīti kopsavilkums, tehniskās detaļas, demonstrācijas materiāls un ietekmes apraksts; uzturētāji var pielāgot iesniegšanas formu S04. Tā ir konkrētas platformas darba plūsma, nevis visiem ziņojumiem juridiski obligāta forma.

Tehniskā kvalitāte nevar kompensēt neatļautu testēšanu. Pirms ievainojamības reproducēšanas pētniekam jāzina, kuras sistēmas, metodes, konti un darbības atļautas. Publiski pieejama vietne pati par sevi vēl nav vispārēja atļauja pārbaudīt tās drošību ar jebkuriem līdzekļiem. Programmas noteikumi var aizliegt darbības ar citu lietotāju datiem, pakalpojuma pieejamības ietekmēšanu, sociālo inženieriju vai testēšanu ārpus noteiktajiem resursiem. OWASP iesaka nodrošināt, ka testēšana ir likumīga un autorizēta, ievērot citu personu privātumu un sniegt pietiekamus, bet samērīgus pierādījumus S01.

Svarīga ir arī atšķirība starp atklāšanu un turpmāku ietekmes demonstrēšanu. Ja ar vienu kontrolētu pieprasījumu konstatēta sveša objekta metadatu noplūde, pētniekam nav automātiski nepieciešams lejupielādēt visu pieejamo saturu, lai pierādītu problēmu. Pilna datu eksportēšana var palielināt cietušo skaitu un radīt papildu tiesiskus riskus, lai gan ievainojamība jau ir pietiekami apstiprināta. Ziņojumā godīgi jānorāda, ka pārbaudīta ierobežota piekļuve, savukārt plašāka ietekme ir hipotēze, kuru nepieciešams izvērtēt sistēmas īpašniekam.

Vēl viens robežgadījums ir testēšanas laikā atklātais, bet programmā neiekļautais resurss. Ja saite, pāradresācija vai atkarīgais pakalpojums izved ārpus apstiprinātā tvēruma, turpmāka pārbaude nav automātiski atļauta tikai tādēļ, ka sākotnējais ceļš bija likumīgs. Es šādā brīdī fiksētu minimālo novērojumu, pārtrauktu papildu darbības un lūgtu skaidru tvēruma precizējumu. Šāda piesardzība dažkārt samazina demonstrācijas iespaidīgumu, toties saglabā pierādījuma profesionālo un procesuālo vērtību.

Kvalitatīvam ziņojumam nav jābūt garam dokumentam ar daudzām ilustrācijām. Tam vajadzīga loģiska struktūra, kas palīdz saņēmējam no apraksta pāriet uz pārbaudi un pēc tam — uz novēršanu. Es prasītu vismaz šādas sadaļas: pārbaudāmo apgalvojumu, tvērumu un atļaujas kontekstu, tehnisko vidi, reproducēšanas soļus, faktisko un sagaidāmo rezultātu, sākotnējo pierādījumu, ierobežojumus, ietekmes pamatojumu un atbildīgai saziņai nepieciešamos datus. Katrā konkrētā programmā šo struktūru var pielāgot tās noteikumiem.

Šī matrica ir autora praktisks piedāvājums, nevis ISO standarta normatīvā sadaļu numerācija. NIST SP 800-115 nosaka metodoloģiskas vadlīnijas drošības testēšanas plānošanai, rezultātu analīzei un mazināšanas pasākumu izstrādei S05. Tā kā dokuments publicēts 2008. gadā, to šeit izmantoju metodoloģijas principiem, nevis kā mūsdienu lietotņu konkrētu rīku katalogu.

Ekrānuzņēmumi ir ērti, jo ļauj ātri parādīt redzamu rezultātu. Tomēr tie neatklāj pilnu tehnisko kontekstu. Attēls var neparādīt, kuram kontam pieder resursi, vai rezultāts radies vienas sesijas ietvaros, vai starp darbībām veikta konfigurācijas maiņa. Tas nenozīmē, ka ekrānuzņēmums ir nederīgs. Tas nozīmē, ka vizuāls attēlojums jāsaista ar tā rašanās apstākļiem un, kur iespējams, ar sākotnējo tehnisko notikumu.

HTTP lietotnes pārbaudē noderīgi dokumentēt pieprasījuma metodi, ceļu, atbilstošās galvenes, autorizācijas kontekstu, atbildes statusu un minimālo rezultāta fragmentu. Sensitīviem žetoniem, sesijas sīkdatnēm, personas datiem un komercnoslēpumiem jābūt aizklātiem vai aizstātiem ar kontrolētiem testdatiem. Ja rediģēšana var mainīt pierādījuma interpretāciju, jāpieraksta, kuri lauki aizklāti un kāpēc; pilna neapstrādāta kopija nav jāiekļauj e-pastā vai publiskā platformas komentārā.

Pierādījumu integritātei palīdz kontrolsummas, savākšanas laika fiksēšana un izmaiņu žurnāls, taču tās nedod vienu universālu garantiju. SHA-256 kontrolsumma apliecina, ka konkrētā baitiem identificētā datne nav mainījusies kopš jaucējvērtības aprēķināšanas, ja sākotnējā vērtība ir uzticami saglabāta. Tā nepierāda, ka ieraksts ir patiess, ka sistēmas pulkstenis bijis pareizs vai ka pētniekam bija atļauja iegūt attiecīgos datus. Pierādījuma izcelsme, apstākļi un integritāte ir atsevišķi kvalitātes aspekti.

Tāpēc minimāls pierādījumu reģistrs var ietvert artefakta identifikatoru, savākšanas laiku ar laika joslu, avota sistēmu, atļautā testa identifikatoru, datnes kontrolsummu, datu jutīguma līmeni un informāciju par rediģētu kopiju. Tas nav mēģinājums katru bug bounty ziņojumu pārvērst kriminālistikas lietā. Šāda struktūra kļūst īpaši vērtīga, ja starp pirmo atradumu un izstrādātāja pārbaudi ir pagājušas nedēļas vai arī incidenta izmeklēšanā jāatšķir sākotnējais pierādījums no vēlāk radītiem paskaidrojumiem.

Pētnieki saprotamu iemeslu dēļ koncentrējas uz demonstrāciju, kas izdevusies. Taču viens veiksmīgs novērojums bez salīdzinājuma bieži atstāj neskaidru tā cēloni. Ja parasts lietotājs var iegūt cita konta objektu, jāparāda, kas notiek, pieprasot savu objektu, un kādēļ attiecīgajai lomai nebūtu jāredz svešais. Ja autorizācijas pārkāpums izpaužas tikai pēc noteiktas darbību secības, šie priekšnoteikumi ir daļa no atraduma, nevis nenozīmīgs papildinājums.

Labs salīdzinājums var ietvert pozitīvo kontroli — darbību, kurai atbilstoši lomai būtu jāizdodas, — un negatīvo kontroli, kurai būtu jātiek liegtai. Šāda pieeja ne tikai palīdz uzturētājam atkārtot kļūdu, bet arī samazina risku ziņot par paredzētu funkcionalitāti kā ievainojamību. Vienlaikus jāizvairās no viltus prasības, ka katrai problēmai obligāti vajadzīgi vairāki izpildīti izmēģinājumi. Ja turpmākas pārbaudes varētu pārkāpt noteikumus vai skart trešo personu datus, minimālais drošais novērojums var būt pareizā robeža.

Es ziņojumā skaidri nošķirtu “testu veicu, un rezultāts bija X”, “testu neizpildīju, jo tas pārsniegtu tvērumu” un “pieļauju, ka tādos apstākļos varētu iestāties Y”. Šādi formulējumi ļauj incidentu komandai novērtēt risku, nepārvēršot pieņēmumus par jau apstiprinātiem notikumiem.

Ziņojumi bieži zaudē ticamību tieši ietekmes aprakstā. Pētnieks pierāda piekļuvi vienam testa objektam, bet secinājumu formulē kā “pilnīga datubāzes kompromitēšana”. Iespējams, sistēmā tiešām pastāv plašāka autorizācijas problēma, taču bez papildu informācijas nav zināms, kādā apmērā tai pakļauti citi dati, kuras lomas tā skar un vai pastāv papildu kontroles.

FIRST CVSS v4.0 dokumentācijā uzsvērts, ka bāzes novērtējums raksturo ievainojamības tehnisko smagumu, nevis konkrētas organizācijas kopējo risku. Turklāt publicējamam CVSS vērtējumam pievienojama metrikas vektora virkne, lai vērtējumu varētu pārskatīt S06. Ar vienu augstu skaitli nepietiek, lai izskaidrotu, kā atradums ietekmē konkrētu produkcijas vidi. Draudu un vides metrikas ir atsevišķi apsvērumi, un pētniekam nevajadzētu izdomāt tādas īpašības, kuras nav zināmas.

Tāpēc praktisku ietekmes sadaļu es dalītu divās daļās. Pirmajā būtu apstiprinātais — konkrēta piekļuves robeža, testa lomas un redzētais rezultāts. Otrajā — potenciālās sekas, kuras jāizvērtē organizācijai: vai pieejami citi objekti, vai ir dati ar augstu konfidencialitātes prasību, vai atkārtošana iespējama lielākā mērogā. Šīs iespējas var būt pietiekami nopietnas, lai noteiktu augstu novēršanas prioritāti, nepasludinot tās par faktiski pierādītu kompromitējumu.

Svarīgi arī nepielīdzināt ievainojamības esamību incidentam. Atrast ekspluatējamu kļūdu nav tas pats, kas pierādīt ļaunprātīgas izmantošanas vēsturi. Lai secinātu par faktisku kompromitēšanu, nepieciešami atbilstoši žurnāli, telemetrija vai citi pierādījumi, kurus pētniekam no ārpuses var nebūt iespējams iegūt.

Aplūkosim pilnībā izdomātu testa vidi, kurā ir divi pētnieka kontrolēti konti: A un B. Katram pieder savs neīsts dokuments. Paredzētais piekļuves modelis pieļauj dokumenta apskati tikai tā īpašniekam. Pētnieks ar kontu A mēģina pieprasīt konta B testa dokumentu un saņem tā saturu. Ziņojuma mērķis ir pierādīt tikai šo autorizācijas robežas pārkāpumu, nepieskaroties reāliem klientu datiem.

Ziņojumā jāparāda sākotnējais kontu un dokumentu stāvoklis, testēšanas vides adrese, konta A piekļuves loma, pieprasījuma laiks un rediģēts atbildes fragments, kurā redzama atšķirība starp paredzēto atteikumu un faktiski saņemto saturu. Vēlams pievienot pieprasījuma korelācijas identifikatoru, ja lietotne to nodrošina, lai uzturētājs varētu pārbaudīt atbilstošo servera žurnālu. Prasīt precīzus izpildes datus ir saprātīgi tikai tik tālu, cik tos ļauj programmas noteikumi un informācijas jutīgums.

Ko no šāda testa var secināt? To, ka konkrētajos dokumentētajos apstākļos konta A sesija varēja iegūt konta B testa dokumentu, lai gan definētais piekļuves modelis to nepieļāva. Ko nevar secināt? Ka pieejami visi sistēmas dokumenti, ka reāli klientu dati jau noplūduši vai ka cits uzbrucējs šo kļūdu iepriekš izmantojis. Plašākas sekas organizācija var pārbaudīt savā autorizētajā vidē, izmantojot iekšējos datus un žurnālus.

Šī robeža starp demonstrāciju un hipotēzi var šķist mazāk iespaidīga par skaļu smaguma apzīmējumu. Tomēr uzturētājam tā dod precīzāku sākumpunktu kļūdas novēršanai un palīdz izvairīties no neauglīgas diskusijas par pārspīlētiem apgalvojumiem.

Ziņojums ar statusu “nevar reproducēt” ne vienmēr nozīmē nepatiesu atradumu. Starp sākotnējo testu un atkārtoto pārbaudi var būt mainījusies lietotnes versija, konfigurācija, testkontu stāvoklis vai lietotāja tiesības. Dažkārt konkrētais defekts jau novērsts ar citu izmaiņu. Citreiz sākotnējā demonstrācijā palicis nepamanīts sesijas konteksts, kas faktiski izskaidro rezultātu.

Es šādā gadījumā vispirms salīdzinātu pārbaudes vides faktus, nevis atkārtotu vienu un to pašu pieprasījumu bezgalīgi. Vai pārbaudīta tā pati programmatūras versija? Vai kontiem ir vienādas lomas? Vai sākotnēji dokumentēts resursa īpašnieks? Vai testi veikti tajā pašā funkcionalitātes konfigurācijā? Vai nav mainījusies autentifikācijas sistēma vai piekļuves kontroles politika? Atbildes uz šiem jautājumiem var izskaidrot neatbilstību bez jebkādas vainas piedēvēšanas.

Ja pierādījumu nepietiek, ziņojumu var kvalificēt kā nepilnīgi reproducējamu vai nepietiekami pamatotu. Tas ir precīzāk nekā kategorisks apgalvojums, ka pētnieks kļūdījies. No otras puses, arī pētnieks nevar prasīt ievainojamības beznosacījumu atzīšanu tikai tādēļ, ka viņam šķietami bijis veiksmīgs tests. Pārbaudāmība nozīmē gatavību pieņemt arī rezultātu, ka pašreizējie pierādījumi secinājumu neapstiprina.

Drošības ziņojumi dažkārt satur tik sensitīvu informāciju, ka nepareiza nosūtīšana pati var kļūt par drošības problēmu. Sesiju žetoni, privātas piekļuves saites, personas dati, slepenas konfigurācijas vērtības vai ievainojamības praktiskas izmantošanas detaļas nav piemērotas publiskam jautājumu reģistram. OWASP iesaka ievērot privātumu, nepieciešamības gadījumā aizklāt personas datus un izmantot atbilstošus saziņas kanālus S01.

RFC 9116 definē security.txt formātu, kas palīdz atrast organizācijas ziņošanas kontaktu un politikas informāciju; tas pats par sevi nedod atļauju testēt sistēmu. RFC arī brīdina par novecojušiem vai kompromitētiem kontaktu ierakstiem, tāpēc vajadzības gadījumā kontaktinformācija jāpārbauda neatkarīgi S07. Ja organizācijai ir privāts ziņošanas portāls vai noteikts koordinētas atklāšanas kanāls, priekšroka dodama attiecīgajā politikā paredzētajai kārtībai.

Ziņojuma publiskā un privātā daļa nav obligāti identiska. Uzturētājam var būt nepieciešams detalizēts pieprasījums, ko publiskā konsultatīvā paziņojumā vēlāk nevajadzētu izplatīt. Pēc labojuma pieejamā informācija var būt plašāka, taču publiskošanas laiks un saturs jāvērtē atbilstoši koordinētas atklāšanas procesam, līgumam un lietotāju apdraudējumam. ISO/IEC 29147 aptver informācijas atklāšanas kārtību, savukārt ISO/IEC 30111 pievēršas paša apstrādes un novēršanas procesa organizēšanai S02 S03.

Ziņojuma kvalitāte nav tikai pētnieka atbildība. Arī organizācijas saņemšanas un izvērtēšanas procesam jābūt saprotamam. Pētnieks nevar nodrošināt pilnīgu reproducējamību, ja organizācija neatklāj, kurai produkta versijai ziņojums attiecas, nepaziņo par testa vides ierobežojumiem un neatbild uz precizējošiem jautājumiem. Savukārt skaidra saziņas kārtība ļauj novērst situāciju, kurā atsevišķi analītiķi viens no otra neatkarīgi atkārto potenciāli riskantus testus.

Saņēmējam būtu lietderīgi apstiprināt ziņojuma saņemšanu, norādīt lietas identifikatoru un atbildīgo saziņas kanālu, pēc tam precīzi formulēt, kurus priekšnoteikumus izdevies pārbaudīt un kurās vietās nepieciešama papildu informācija. Ja ziņojums neatbilst programmas tvērumam, tas jāpasaka konkrēti, nevis tikai ar automātisku atteikuma frāzi. Ja atradums ir dublikāts, jāpaskaidro, ko iespējams atklāt, nepārkāpjot citas personas vai pētījuma konfidencialitāti.

Svarīgs ir arī pēcpārbaudes rezultāts. Kļūdas novēršana nav tas pats, kas tikai konkrētā demonstrācijas pieprasījuma bloķēšana. Ja problēma sakņojas kopīgā autorizācijas komponentē, labojumam jāaptver attiecīgā drošības īpašība, nevis tikai viens URL vai objekta identifikators. Pārbaudes scenāriji pēc labojuma var ietvert gan sākotnējā atraduma atkārtošanu, gan kaimiņu funkcijas, kurām pastāv tā pati drošības priekšnoteikumu kombinācija.

Faktu un pierādījumu skatījums. Vai katram būtiskam apgalvojumam ir atbilstošs sākotnējais novērojums? Ja ziņojumā rakstīts, ka iegūta piekļuve konta B dokumentam, jāredz pierādījums par tieši šo dokumentu un kontu attiecību. Vispārīgs ekrānuzņēmums vai ārēja skenera secinājums var nepietikt. Tāpat jāatzīst datu integritātes un iegūšanas metodes ierobežojumi.

Tehniskais un terminoloģiskais skatījums. Vai ziņojums atšķir autentifikāciju no autorizācijas, novērotu datu atklāšanu no pilnīgas datubāzes kompromitēšanas un ievainojamības smagumu no organizācijas riska? Ja izmantots CVSS, jānorāda versija, vektors un vērtējumā pieņemtie priekšnoteikumi S06. Vienas kategorijas neprecīzs nosaukums var novirzīt novēršanas komandu uz nepareizu kontroles slāni.

Metodoloģijas skatījums. Vai ir pietiekamas pozitīvās un negatīvās kontroles, lai nošķirtu drošības kļūdu no paredzētas funkcionalitātes? Vai dokumentēti priekšnoteikumi, vai rezultāts var būt saistīts ar kešatmiņu, sesiju vai iepriekš mainītiem datiem? Kādi citi skaidrojumi joprojām iespējami? Testa atkārtojamība nav tikai vairākkārt nospiesta viena poga.

Tiesiskuma un ētikas skatījums. Vai visas darbības bijušas atļautas? Vai pierādījums iegūts, nekaitējot citiem lietotājiem, un vai tajā nav lieku sensitīvu datu? Vai vēlākā publicēšana saskan ar programmas noteikumiem un koordinācijas procesu? Pat ļoti interesants tehnisks atradums neattaisno neatļautu datu eksfiltrāciju.

Redaktora un saņēmēja skatījums. Vai ziņojumu var saprast cilvēks, kurš nav piedalījies sākotnējā testā? Vai pirmajās rindkopās ir skaidrs, ko pārbaudīt, un vai tehniskā informācija ļauj uzsākt novēršanu? Vai ziņojums neveido mākslīgu dramatismu, kur pierādījumi atbalsta daudz šaurāku secinājumu? Pārskatāma dokumentācija ietaupa abu pušu laiku, jo mazāk jautājumu paliek neatbildētu.

Šīs piecas perspektīvas nav universālas sertifikācijas atzīmes. Tās ir veids, kā pirms ziņojuma nosūtīšanas atklāt atšķirīgus kļūdu veidus. Piemēram, tehniski pareizs pārbaudes apraksts joprojām var būt tiesiski problemātisks, bet nevainojami noformēts dokuments — nepietiekami pierādīts.

Visvairāk mani pārliecinātu ziņojums, kuru drošības komanda var izmantot, neveidojot savu minējumu ķēdi. Tā saņēmējs saprot testēšanas tvērumu, zina priekšnoteikumus, var identificēt sākotnējos pierādījumus un skaidri redz, kur pētnieks apstājies. Ja organizācija ziņojumu nevar reproducēt, tajā ir pietiekami daudz konteksta, lai pārbaudītu atšķirības. Ja atradums apstiprinās, tajā ir pietiekami precīza drošības īpašības definīcija, lai novērstu problēmas cēloni.

Ziņojuma garums šeit ir otršķirīgs. Daži atradumi prasa sarežģītu darbību secību un vairākus artefaktus, bet citus iespējams precīzi aprakstīt vienā lapā. Mākslīgi sarežģīts pierādījumu komplekts var būt tikpat nevērtīgs kā pārāk īss apraksts. Vērtību nosaka atbilstība pārbaudāmajam jautājumam, nevis pielikumu daudzums.

Es neuzskatītu par kvalitatīvu arī ziņojumu, kurš satur tikai automatizēta skenera kategoriju un CVSS skaitli. Skeneris var palīdzēt atklāt iespējamu problēmu, bet tam var pietrūkt informācijas par konkrētas lietotnes autorizācijas politiku, biznesa loģiku un faktiskajām sekām. Ja pētnieks nav pārbaudījis konstatēto, tas jādēvē par iespējamu atradumu, kuram vajadzīga papildu validācija.

Profesionālas ievainojamību atklāšanas vērtība veidojas divās pusēs. Pētniekam jāprot sagatavot tehniski precīzu, droši iegūtu un pārbaudāmu aprakstu; organizācijai jāspēj šo informāciju pieņemt, izvērtēt, novērst un pēc labojuma pārbaudīt. ISO/IEC 29147 un ISO/IEC 30111 raksturo šīs sadarbības savstarpēji saistītās procesa daļas, bet OWASP un NIST materiāli palīdz konkretizēt ziņojumu un testēšanas metodoloģiju S01 S02 S03 S05.

Manuprāt, viens no labākajiem ziņojuma kvalitātes rādītājiem ir iespēja atbildēt uz jautājumu: ko mēs zinām tāpēc, ka tas patiešām tika novērots, un ko vēl tikai pieņemam? Ja šī robeža saglabāta, ziņojums kļūst par izmantojamu tehnisku pierādījumu un atbalstu novēršanai. Ja robeža pazūd, pat patiess atradums var iestrēgt strīdā par pierādījumu nepietiekamību vai pārmērīgiem apgalvojumiem.

Neatkarīgam pētniekam nav jākompromitē pēc iespējas vairāk datu, lai viņu uztvertu nopietni. Pietiek drošā, atļautā tvērumā skaidri demonstrēt kontroles kļūdu un precīzi aprakstīt, kādēļ novērotais neatbilst paredzētajai sistēmas uzvedībai. Tas ir profesionālāk, aizsargā lietotājus un dod programmatūras uzturētājam reālu iespēju problēmu novērst.