Pastaba: žemiau išdėstytos mintys yra mano asmeninės ir niekaip neatspindi mano darbdavio nuomonės ar pozicijos.
Paprastai rašau mintis angliškai ir paprastai į valstybines nesąmones daug dėmesio nekreipiu, bet šį kartą perskaitęs straipsnius delfi.lt ir critical.lt apie mūsų e-valdžios portalo savybes – negaliu susilaikyti, nes tokių nesąmonių jau senokai nesu matęs. Susidaro įspūdis, kad grupelė mėgėjų susirinko ir padarė kažką …
Pradžiai – ačiū critical.lt žmonėms, už jų skirtą laiką ir pastangas, nes priešingu atveju šitas reikalas galėjo baigtis kur kas blogiau, o IVPK teiginiai, kad “norint pasinaudoti šia spraga būtina aukšta kompetencija” neatitinka tikrovės, nes paleisti fiddler ar kokią kitą priemonę tikrai nereikia didelių sugebėjimų.
Toliau tiesiog noriu surašyti keletą savo pastebėjimų, kurie mane stebina tiek, kad nesuprantu kaip į Lietuvą atėjo Barclays, taigi – apie viską iš eilės. Savo pastebėjimus paremsiu tik viešai prieinama informacija, kuriai peržiūrėti skyriau 15-20 minučių, o potencialios rizikos vertinimą – “Defense in Depth” principais ir STRIDE (Spoofing, Tampering, Repudiation, Denial of Service, Elevation of Privilege) klasifikavimu.
- Pačių išduotas sertifikatas duomenų autentiškumui nustatyti
Pasižiūrime į nuorodą esančią šalia “VAIISIS sertifikatas perduodamų autentifikavimo duomenų parašo tikrinimui” ir kaip teisingai pastebėjo critical.lt komentatorius – ten yra įdėtas sertifikatas (viešas raktas), pagal kurį autentifikavimo paslaugos naudotojai turėtų tikrinti ar duomenys autentiški (VAIISIS). Jeigu atkreipti dėmesį į jo turinį, buvo nueita kvailiausiu pigiausiu keliu. Tiekėjas pats sugeneravo sertifikatą (privataus viešo rakto porą) ir viskas, tačiau neįdėjo jokių priemonių kaip apsisaugoti nuo to atvejo, jei privatus raktas turėtų būti paskelbtas negaliojantis (tapo viešas, buvo pavogtas, ir t.t.). Be to, 1K raktas šiais laikais artėja prie ribos, o galiojimas – penkiems metams.
Normaliu atveju, PKI (viešo rakto infrastruktūra) aplinkoje CA (sertifikavimo tarnyba) ne tik išduoda sertifikatą, bet ir užtikrina papildomas paslaugas, bent jau CRL (sertifikatų atšaukimo sąrašų) publikavimą (dar gali būti OCSP – Online Certificate Status Protocol realizacija). Negaliu komentuoti dėl Java ar kitų bibliotekų/platformų, bet bent jau .Net Framework/Windows platformos atveju sertifikato galiojimas yra “auto-magiškai”
tikrinamas pagal jame (CRL distribution points papildyme) įrašytą informaciją.
Dabar gi, paslaugos tiekėjas turės matyt telefonu informuoti visus autentifikavimo paslaugos naudotojus, kad pateiktas viešas raktas nebūtų naudojamas tikrinimui, tačiau tai nebus užtikrinama techninėmis priemonėmis. O ten jau kaip gausis – programuotojas pakeis arba ne.
Prielaida
Įtariu, kad privatus raktas tiesiog “padėtas” failinėje sistemoje ar panašiai – apsaugant slaptažodžiais ir programinėmis priemonėmis (kaip buvo kūrimo metu, taip ir liko), o tai jau rimta problema, nes šis raktas autentifikavimo/pasitikėjimo procese yra kritinis, o minėtos priemonės tikrai nėra pakankamos.
Tokio sprendimo pasekmė – ypatingai didelė spoofing, repudiation, information disclosure, tampering, elevation of privilege rizika.
- (Ne)standartai prieš suderinamumą
Skaitome išorinio komponento prijungimo prie VAISIS rekomendacijas ir randame štai tokį parašymą: “Metodų gražinamų pranešimų formate turi atsirasti vieningi laukai, skirti klaidų informacijai gražinti (laukų pavadinimai: error_code, error_id, error_message);”, nors dar prieš tai parašyta, kad viskas turi atitikti WS-I, bei SOAP 1.1. Gaunasi, kad jei aš noriu prijungti savo paslaugas prie VAIISIS – tai dėl kažkieno sugalvoto pseudo-standarto aš esu priverstas keisti savo paslaugų logiką? Nors truputį daugiau susidūrę su web servisais žmonės žino, kad SOAP turi numatytą mechanizmą klaidų informacijos perdavimui – SOAP fault, kuriame tokie dalykai kaip faultcode, faultactor, details, faultstring. Tai kam reikėjo “išradinėti” tuos error…? Nejaugi universitete žmonių nemokė apie esybių/logikos/etc. atskyrimą? Mano nuomone – pasiūlytas sprendimas yra blogiau nei studento lygyje. Gerai, kad čia tik rekomendacija ir kaip taisyklė – jų galima nesilaikyti
Tame pačiame dokumente minimas ir WS-S arba WS-Security ir šioje vietoje iškart užkliūva tai, jog anksčiau critical.lt minėtas autentifikavimo mechanizmas pagal aprašymą yra visiškai nestandartinis sprendimas. IT industrijoje jau kuris laikas taikomi standartai būtent šiems paskirstyto autentifikavimo scenarijams:
- WS-Federation
- WS-Trust
- SAML ir netgi specialiai valstybiniam scenarijui taikomas eGov profilis
WS-Federation, bei WS-Trust protokolai paremti tuo pačiu WS-Security. Tuo pat metu tiek komercinės programinės įrangos gamintojai tokie kaip Microsoft (ADFS v2), BEA/Oracle, IBM, ir t.t., tiek nemokamos programinės įrangos kūrėjai (pvz.: Shibboleth) kuria programinę įrangą palaikančią minėtus standartus. Savo ruožtu tai reiškia šiokį-tokį tarpusavio suderinamumą ir galimybę integruoti įvairias sistemas ir aplinkas tarpusavyje atliekant konfigūracijos pakeitimus.
Duotu atveju tiekėjo pasirinkto sprendimo rezultatai akivaizdūs:
- Dokumente numatytas tik vienas autentifikavimo scenarijus, tačiau visiškai nenumatytas išsijungimo scenarijus, nekalbant apie scenarijus, kai klientas naudojasi ne web programa.
- Kiekvienai organizacijai reikės realizuoti nestandartinį sprendimą arba plėsti atitinkamų produktų galimybes. Na, tam tikra prasme man tai patinka – be darbo neliksiu, tačiau iš įmonių ir organizacijų pozicijos – tai jau vertimas realizuoti skirtingus sprendimus tam pačiam poreikiui patenkinti.
- Na ir pabaigai – priemonės apsaugo nuo elementarių programavimo (susijusio su saugumu) klaidų. WS-Security pagal nutylėjimą įtraukia time stamp’ą į pranešimą (pastebėjimas – tai vyksta WS-S protokolo lygyje), nustatant autentifikavimą sertifikatu – pranešimas bus tinkamai pasirašomas atitinkamai ir bent jau kai kurių produktų/paketų atveju reikalaujama, kad pasirašymui naudojamas sertifikatas turėtų įrašytą CRL nuorodą. Kitaip tariant šiuo atveju tiekėjas bandė išrasti dviratį ir išrado jį labai blogai.
Reikia pabrėžti, kad standartinių produktų/bibliotekų naudojimas neapsaugo nuo saugumo klaidų arba potencialių problemų (žr. pavyzdį toliau), tačiau bent jau neleistų daryti visiškų nesąmonių.
- “Vidiniai niuansėliai”
Žiūrime į architektūros dokumento 31-ą puslapį ir matome autentifikavimo faktų lentelės aprašymą. Iš pirmo žvilgsnio gali pasirodyti, kad viskas gerai – yra duomenų bazėje lentelė, kurioje įrašoma audito informacija, tačiau yra viena nedidelė problema: lentelėje akivaizdžiai nėra jokios apsaugos nuo Tampering ir Repudiation. Kitaip tariant, gavus prieigą prie minėtos DB lentelės (pasinaudojant programinės įrangos, OS arba DB klaidomis, socialine inžinerija ir t.t.) galima pridėti arba panaikinti reikiamus įrašus praktiškai nepaliekant jokios galimybės tai aptikti. Aišku, aš labai tikiuosi, kad bent jau “SQL injection” skylių ten nėra ir teisės į lenteles sudėtos atitinkamai, kas sumažina riziką, tačiau kaip tokiam valstybiniam sprendimui – nepakanka.
Kaip minėjau – aš informacijos peržiūrai skyriau 15 minučių, o straipsnio parašymui – truputį daugiau . Įdomu, kiek dar niuansų galima būtų rasti sprendime atlikus paprastą rizikų modeliavimą.
Apibendrinant galima pasakyti tiek – paskirstytas autentifikavimas, valstybės paslaugų portalai yra ne juokas ir “studentiškai”/“ant snarglių” neturėtų būti daromi. Reikia suprasti ir probleminę sritį, jos niuansus, galimus scenarijus, pasauliniu mastu taikomus sprendimus ir tik tada kurti pagrįstą sprendimą.
Kad išvengti komentarų šiukšlių dienoraštyje – jų lauksiu elektroniniu paštu: vardas et karštas paštas taškas kom. Rimtus komentarus (jei tokių bus) planuoju apibendrinti ir įdėti atskiroje žinutėje.