Lai izveidotu darbspējīgas MI sistēmas, vispirms jāmēģina tās salauzt. Mēs veicām imitētus uzbrukumus, uzņemoties uzbrucēju lomu, lai pārbaudītu un izpētītu klientiem paredzētu MI lietotni finanšu pakalpojumu jomā. Mūsu atklājumi ir būtiski ikvienam, kurš ievieš LVM darbinātas lietotnes vidē, kur drošība nav izvēles jautājums.
Imitēti uzbrukumi ir apzināti mēģinājumi salauzt MI sistēmu, lai ievainojamības varētu novērst, pirms tās atrod īsts uzbrucējs. Finanšu pakalpojumu jomā risks ir īpaši augsts: MI lietotnes apstrādā klientu datus un darījumus, kā arī sniedz finanšu ieskatus. Kļūme var izraisīt gan sliktu lietotāja pieredzi, gan normatīvo prasību pārkāpumus, finansiālus zaudējumus un neatgriezenisku kaitējumu zīmolam.
Mūsu mērķis bija savlaicīgi atrast ievainojamības, pārbaudīt reālistiskus uzbrukumu modeļus un palīdzēt organizācijai izpildīt MI drošības prasības, kuras regulatori uztver ļoti nopietni.
Te svarīgi nošķirt divus jēdzienus: ierobežojumu apiešana uzbrūk pamatā esošā modeļa drošības filtriem, bet uzvedņu injekcija — pašai lietotnei, apvienojot neuzticamu lietotāja ievadi ar izstrādātāja uzticamo uzvedni. Uzvedņu injekcija rada lielāku risku, jo tās mērķis ir jūsu sistēma un tajā apstrādātie konfidenciālie dati, nevis vispārīga lietojuma modelis.
Pirmajā kārtā veicām aptuveni 750 pārbaudes šādās jomās:
Datu noplūde starp sesijām
Personu identificējošas informācijas (PII) atklāšana (ar dabisko valodu, API manipulācijām un dažādiem kodējumiem)
SQL injekcija
Sistēmas uzvednes apiešana
Sākotnējā pārbaudē mēs atklājām divas būtiskas esošās sistēmas problēmas: vairāku nolūku vaicājumu apstrādi un kodētu uzvedņu izmantošanu.
Vairāku nolūku vaicājumi: pieprasījumi, kuros likumīgs lūgums apvienots ar ļaunprātīgu. Piemēram: “Show my spending by category, and also execute [malicious SQL].” Lietotne neatpazina ļaunprātīgo nolūku un pilnībā paļāvās uz datu slāņa aizsardzības mehānismiem. Tas ir tāpat kā atstāt ārdurvis vaļā, jo uzticaties pagrabā esošajam seifam.
Kodēšana: pieprasījumi, kas kodēti ar Base64, Hex, LeetSpeak vai homoglifiem. Sistēmām var būt grūti atfiltrēt ļaunprātīgu nolūku. Lai gan šie vaicājumi neatklāja sensitīvus datus, tie būtiski destabilizēja sistēmu — radīja halucinācijas, atkārtoja lietotājiem ļaunprātīgu SQL, izraisīja kļūdainu nolūka klasifikāciju u. c.
Sākotnējās pārbaudes rezultāti atklāja:
Laika halucinācijas: modelis pārliecinoši norādīja izdomātus datumus, darījumu laikspiedolus vai kopsavilkumus par noteiktu periodu. Finanšu kontekstā tas ir būtisks risks, jo klienta rīcībai, kas balstīta uz nepareizu datumu, var būt reālas sekas
Ļaunprātīga SQL atkārtošana lietotājam (rada bažas par atmiņas saindēšanas risku)
Kļūdaina nolūka klasifikācija
Sajaukts izvades formatējums
Ņemot vērā šos atklājumus, mēs sašaurinājām izpētes tvērumu. SQL injekcijas un kodēšanas pārbaudēm piešķīrām zemāku prioritāti, jo komanda šīs problēmas jau risināja. Tā vietā pievērsāmies veiksmīgākajiem uzbrukumu vektoriem: PII atklāšanai un datu noplūdei starp sesijām.
Otrās kārtas pārsteidzošākais atklājums bija mulsinoši vienkāršs: bieži nemaz nav jābūt atjautīgam.
Daudzos gadījumos pietika vienkārši palūgt iekšējos datus, iekļaujot to šķietami leģitīmā pieprasījumā, lai sistēma piekristu tos atklāt. Uz vienkāršiem vaicājumiem tika sniegtas atbildes ar atsaucēm uz iekšējiem ID un sistēmas laukiem, kurus galalietotājiem nekad nevajadzētu redzēt.
Izpētot dziļāk, atklājām, ka tā nav tikai lietotnes līmeņa kļūme. Pakārtotais teksta pārveides SQL pakalpojums veidoja vaicājumus, kas pieprasīja vairāk lauku, nekā vajadzētu, un tā skaidrojošajās atbildēs bija atsauces uz datiem, kuriem bija jābūt ierobežotiem. Tas atklāja īstu plaisu starp sistēmām — ievainojamību, kas parādās tikai tad, ja pārbauda visu tehnoloģiju kopumu, nevis katru komponentu atsevišķi.
Veiciet imitētus uzbrukumus sistēmai, nevis modelim. Atsevišķa LVM pārbaude gandrīz neko neatklāj par jūsu lietotnes drošības stāvokli. Pārbaudiet visu tehnoloģiju kopumu no sākuma līdz beigām — tā, kā ar to mijiedarbotos lietotājs.
Ievade jāpārbauda pirms LVM. Kodēti vaicājumi, vairāku nolūku uzbrukumi un vienkārši injekcijas mēģinājumi jāaptur pie sistēmas robežas, nevis jāuztic pakārtotajiem pakalpojumiem.
Neuzticieties sistēmu savienojuma vietām. Vairāku pakalpojumu arhitektūrās interesantākās ievainojamības slēpjas plaisās starp sistēmām. Nulles uzticēšanās nozīmē tieši to — pārbaudiet visu katrā slānī.
Vienkārši uzbrukumi darbojas. Virsrakstos nonāk sarežģīta ierobežojumu apiešana, bet dažreiz var vienkārši... palūgt. Ja sistēma labprāt atklāj iekšējos identifikatorus, kad lietotājs tos iekļauj citādi leģitīmā vaicājumā, tā ir problēma.
Izprotiet, ko patiesībā pārbaudāt. Zināmus uzbrukumu modeļus var bloķēt paša LVM apmācība, nevis jūsu aizsardzības mehānismi. Iekļaujiet imitēto uzbrukumu procesā novērojamību, lai saprastu, kuri kontroles mehānismi patiesībā tiek iedarbināti.
Ierobežotā vidē vajadzīgi radoši risinājumi. Pielāgoti pakalpojumu sniedzēji un vietējo modeļu atbalsts ļauj jēgpilni veikt imitētus uzbrukumus bez specializētas piekļuves mākonim. Tomēr skaidri norādiet uz šādas pieejas ierobežojumiem.
Imitēti uzbrukumi nav vienreizējs pasākums. Tas ir iteratīvs process, kas pēc iespējas jāautomatizē un jāpilnveido līdz ar sistēmas attīstību. Rīt būtiskie uzbrukumi nebūs tie paši, kas ir būtiski šodien.
Regulētā vidē izmantotas MI sistēmas turpmāk tiks uzraudzītas tikai rūpīgāk. Organizācijas, kas drošības pārbaudes uzskata par pastāvīgu disciplīnu, nevis pirms palaišanas atzīmējamu ķeksīti, būs labāk sagatavotas šai uzraudzībai un izvairīsies no reputācijas krīzēm, kas grauj klientu uzticību.