IT duomenų saugumas spragos

5 dažniausios IT sistemų saugumo spragos Lietuvoje

Problema

Valstybinėse IT sistemose dažnai kartojasi tos pačios klaidos. Jos leidžia vykdyti neteisėtas operacijas ir vogti duomenis.

Kodėl taip yra?

Kūrėjai sistemas testuoja per siauruose scenarijuose. Saugumo tarnybos rūpinasi tik stabiliu veikimu ir nesigilina į pavienes klaidas.

Kaip spręsti?

Kiekviena valstybinė sistema turėtų praeiti platesnį standartinį testą. Visi piliečiai gali rasti klaidų ir apie jas pranešti.

Kitais metais steigiamas Nacionalinis kibernetinio saugumo centras (NKSC). Jo užduotis – užtikrinti „ypatingos svarbos informacinės infrastruktūros“ veikimą. A.Paulausko įsivaizdavimu, tai „transportas, energetika, kiti ryšiai“.

Vakar nulaužta svetainė eTeismai.lt. Net jei ji būtų valstybinė, tai nėra kritinė infrastruktūra, tad NKSC jos nesaugotų. Dauguma valstybės IT sistemų, kur kaupiami privatūs duomenys ir vykdomos biurokratinės operacijos, valstybei nėra gyvybiškai svarbios.

Kitas niuansas – NKSC ir panašios tarnybos stengiasi užkirsti kelią tų sistemų neveikimui, kad būtų išvengta chaoso. Bet jei kalbame apie e. valdžios sistemas, blogiausia situacija nėra tai, kad jos neveikia. Kur kas blogiau, jei jos veikia neteisingai – kažkas jose falsifikuoja procedūras, vagia privačius kitų asmenų duomenis ir t.t.

Toliau aprašau 2014 metais dažniausiai pastebėtas valstybinių IT sistemų saugumo spragas. Jos leidžia nesutrikdant sistemų darbo vykdyti neteisėtas operacijas ir vogti duomenis. Tos pačios klaidos kartojasi visose valstybinių institucijų sistemose.

Šias spragas gali lengvai rasti bet kas be IT patirties. Jas gali išnaudoti visi be techninio išsilavinimo ir be jokios nelegalios įrangos. Jų išnaudojimas kitiems visuomet sukelia žalą.

Įspėjimas

Jei straipsnio skaitymo metu aprašytos spragos tebeegzistuoja kuriose nors sistemose, praneškite apie tai jų savininkams. Skatinu neišnaudoti pažeidžiamų sistemų ir nekelti grėsmės kitiems.

Straipsnyje tikslingai neminiu techninių detalių. Į visus specifinius klausimus atsakysiu komentaruose.

1. Butaforinis duomenų tikrinimas

Įsijungi formą interneto svetainėje, o ten parašyta, kad reikia įvesti vardą, pavardę ir asmens kodą. Įvedi vardą ir pavardę, prašo kodo. Įvedi ir kodą, esi praleidžiamas ir įvykdoma operacija. O kas, jei įvesi tik asmens kodą?

Tokia spraga buvo viename Registrų centro sistemos modulyje. Norint atlikti operaciją, formoje realiai tereikėjo vieno duomens. Antrame žingsnyje trūkstami duomenys buvo paimami iš duomenų bazės ir atvaizduojami vartotojui. Taip gautus duomenis galime panaudoti tikslais, apie kuriuos formos programuotojai nė nenutuokė.

Šiais laikais toks atmestinas IT sistemų realizavimas atima žadą. Formose prirašoma daug taisyklių, kas privaloma ir t.t. Bet niekas nesivargina pažiūrėti, ar tikrai viskas taip ir suprogramuota.

Duomenų tikrinimo spragas gali rasti ir išnaudoti visi. Pavyzdžiui, kam buhalterei prašyti pilnų naujo darbuotojo duomenų, jei ji nueis į tą formą, įves asmens kodą ir kitus duomenis nusikopijuos. Bus greičiau ir tiksliau, nei spausdinti klaviatūra. Jei tokia praktika tarp buhalterių išpopuliarės, atsiras tuos duomenis išnaudojančių originaliau.

Šią saugumo spragą 2014 metais turėjo ne viena asmens duomenis tvarkanti institucija. Dėl to asmens kodas tapo vieša paslaptimi. Plačiau apie tai rašysiu ateityje.

2. Duomenų tikrinimas tik vartotojo pusėje

Visgi daugumoje formų duomenys tikrinami. Kažko neįvedęs, gauni erzinantį pranešimą „Privalomas laukelis neužpildytas!“. Užpildai tą laukelį, gauni „Neteisingas tel. nr. formatas!“.

Jei esi eilinis vartotojas, šoki pagal sistemos dūdelę. Bet jei esi programuotojas, Chrome naršyklėje spaudi F12, trini iš svetainės programinio kodo visus tuos JavaScript pranešimus ir patvirtini formą su esamais duomenimis. Nepatikėsi, kaip dažnai valstybinėse IT sistemose serveris tuos nepatikrintus duomenis priima.

Žinoma, kvaila į sistemą neteisingai įvesti savo telefono numerį, nes paskui kas nors neveiks. Bet jei esi kenkėjas ir nebetūnai Tundroj, taip į duomenų bazę gali perduoti daug įdomesnius duomenis ar komandas.

Kritiškiausiu atveju, duomenų bazė įvykdys tavo siųstą komandą, kurią serveris palaikys duomenimis. Tokioje situacijoje kenkėjo galimybės duomenų bazėje absoliučios. Pasekmės sistemos savininkui katastrofiškos.

Švelnesniu atveju įvykdysi standartinę serverio komandą ne savo teisių ribose. Pavyzdžiui, žinodamas, kaip turi būti suformuluota komanda pakeisti įmonės savininkus, duomenų bazėje patapsi konkuruojančios įmonės kontroliuojančiu bendraturčiu. Tokį absurdišką pavyzdį pateikiu su viltimi, kad kiekvienas sau susigalvos po praktiškesnį.

Dar švelnesniu atveju įvykdysi operaciją savo vardu, bet kuri tau apribota. Pavyzdžiui, pasikeisi savo įmonės registracijos adresą, kai tai nėra leidžiama atlikti dėl kokių nors laikinų aplinkybių. Šis variantas įdomus tuo, kad sistemos specifikacijoje operacija savo pobūdžiu yra teisėta ir tau įmanoma, tik ne tuo laiku. Praktiškai ją vykdantys specialistai paskui kraipo galvą ir skambinėja, kaip čia taip nutiko. Bet sistemos administratoriai garantuoja, kad viskas gerai, operacija registre švari ir tvarkinga – reikia vykdyti.

Švelniausiu atveju įvykdysi teisėtą operaciją savo sąlygomis. Pavyzdžiui, formos vartotojui nerodomuose duomenyse į serverį nusiųsi savo paslaugos kainą. Praktiškai tai kur kas įdomiau privačių įmonių sistemose, kur būna visokių akcijų ir žemos kainos neužkliūva. Praeitą dešimtmetį skridę Lufthansa reisu per Atlantą pirma klase už 10€ džiaugsmo patyrė daugiau nei žmogui skirta.

Komercinėse sistemose serverio pusėje tikrinama viskas, kas tikrinama ir vartotojo pusėje. Kiekviena nepatikrinta komanda baigsis pavogta preke, neteisėta nuolaida ar kitokiais nuostoliais.

Valstybinės institucijos konkrečių nuostolių dažniausiai nepatiria, todėl žiūri atsainiau. Tačiau kelios tokios spragos, sujungtos į vieną scenarijų, leidžia perrašyti asmens ar įmonės istoriją, pavogti tapatybę ir t.t. El. valdžios vartus turinčioje valstybėje tai yra daug radikalesnės pasekmės, nei pigiai paskraidęs kenkėjas.

Kad rastum tokias spragas, reikia šiek tiek JavaScript supratimo. O jį supranta daug kas. Greitai ir visi moksleiviai jį mokės taip pat gerai kaip matematiką. Todėl praktiškai tokias spragas gali išnaudoti dauguma namų ūkių. Tai nesutrikdo sistemos darbo ir neužkliūva administratoriams, todėl kasdien tūkstančiai tokių pažeidimų įvykdomi nepastebėti.

3. Neribojamas užklausų skaičius

Jei sistema tikrai prastai apsaugota programos lygyje, rasime anksčiau minėtų spragų. Profesionalūs įsilaužėliai ras kur kas rimtesnių skylių bet kokioje sistemoje. Tuomet pasekmės priklauso nuo to, kokiu mastu leidžiame jas išnaudoti.

Viešos valstybinių institucijų IT sistemos skirtos piliečiams susitvarkyti kokį nors savo asmeninį biurokratinį reikalą. Pavyzdžiui, atsispausdinti rinkėjo kortelę.

Klausimas: kiek rinkėjo kortelių man gali reikti atsispausdinti? Normaliai, vieną. Na, gal dar žmonai ir močiutei.

Bet valstybinės sistemos to neriboja. Galiu vykdyti nors ir po kelis tūkstančius operacijų per valandą. Akivaizdu, tūkstančius operacijų gali vykdyti nebent tas, kuris rado kažkokią spragą ir iš tų operacijų turi naudos.

Dabar limitas yra tik toks, kad jei siunčiam dešimtis tūkstančių užklausų per valandą, tai sukelia sistemas aptarnaujančių serverių apkrovą. Tai pastebėję administratoriai užblokuoja piktnaudžiaujančio siuntėjo IP adresą ugniasienėje. Bet kol serveris nelūžinėja, keli tūkstančiai užklausų per valandą iš vieno IP jiems atrodo „visiškai normalu“.

Vadinasi, per parą vienu kompiuteriu be jokių problemų įvykdome beveik 100 tūkst. piliečiams skirtų operacijų. Įsivaizduokime, kad norime įvykdyti po operaciją kiekvienam Lietuvos piliečiui. Nepastebėti tą įvykdysime per 1 mėnesį. Jei sistema veikia galinguose serveriuose ir nenulūš, pasijungsime 30 kompiuterių ir rezultatą turėsime jau rytoj.

Jei bet kokia sistemoje rasta spraga leidžia turėti naudos ar pakenkti kitiems, sistemos užklausų limitas kenkėjų laimikį sumažintų dešimtis tūkstančių kartų.

Užklausų limito netaikymas yra didžiausia bet kokios sistemos spraga. Ji leidžia bet kokiam mėgėjui iš savo asmeninio kompiuterio išnaudoti bet kokias rastas spragas didžiuliu mastu.

Tokio limito apėjimas reikalauja specialios infrastruktūros ir programinės įrangos. Vadinasi, uždėjus limitą atkris rizikos iš mėgėjų. Potencialiais įsilaužėliais liks tik profesionalai. Plius, registruojant visas užklausas, vėliau bus galima reguliariai jas analizuoti bei pastebėti ir mažo masto anomalijas.

4. Neblokuojamos tinklo tarnybos

Tęsiant pirmąją temą, įsivaizduokime, kad toks limitas visgi yra – 100 užklausų per parą iš vieno IP adreso. Kaip tai apeiti?

Paprasčiausia – naudoti debesų kompiuterijos serverius. Pavyzdžiui, kas valandą pasijungiame naujus serverius „šviežiais“ IP adresais. Kad per parą įvykdytume tą patį 100 tūkst. operacijų, per valandą jų vykdysime po 4167. Jei limitas 100 užklausų iš 1 IP adreso, reikės 42 naujų serverių kas valandą.

Pirmas įspūdis – oho, čia jau tikrų hakerių darbas. Reikia tūkstančių IP adresų. Reikia suvaldyti tūkstančius serverių vienu metu. Galiausiai, reikia maišo pinigų.

Deja, ne viskas taip sudėtinga. Su šiandieninėmis debesų kompiuterijos platformomis tą gali atlikti bet kas, kas sugeba pasijungti turinio valdymo sistemą kaip WordPress. Kaštai irgi juokingi – Amazon Web Services platformoje pigiausio serverio valanda kainuoja $0.013. Vadinasi, 1008 serveriai po vieną valandą iš viso kainuos 13.10$. Ar ši suma tikrai atgraso įvykdyti 100 tūkst. naudingų operacijų per parą?

Ką matys atakuojamos IT sistemos administratoriai? Per parą įvykdyta po 100 užklausų iš 1008 IP adresų kas pusė minutės.

Žmogiškoji gynyba čia bejėgė. Net jei automatiškai blokuosime tokius serverius pagal IP adresus jau po keliasdešimt ar keliolikos užklausų, pasijungs nauji serveriai naujais IP adresais ir atakuos toliau. Jei puolanti pusė užklausas generuos protingiau, nei besiginanti jas filtruos, dalis užklausų nuolat prasibraus pro bet kokias apsaugas.

Situacija atrodo beviltiška. Tai kur čia ta lengvai užlopoma spraga?

Yra vienas bendras atakuojančių serverių bruožas. Jie visi priklauso didiesiems debesų kompiuterijos duomenų centrams AWS, Azure, Google ir t.t. Maži paslaugų teikėjai paprasčiausiai nepateiks tūkstančių naujų serverių skirtingais IP adresais kas valandą. O net ir mažesniems kiekiams jie neturi programinės įrangos, kad klientas pats galėtų suvaldyti taip greitai kintančias serverių fermas.

Vadinasi, galime užblokuoti visus IP adresus, kurie priklauso tų duomenų centrų operatoriams. Negi Lietuvos pilietis ateis atsispausdinti rinkėjo kortelę iš Google duomenų centrui priklausančio IP adreso?

5. Rankinis ugniasienių blokavimas

Lengva nustatyti, kaip veikia Lietuvos institucijų serverių administravimas. Paleidžiame didelį užklausų srautą į kokią nors sudėtingesnę operaciją vykdantį serverį iš vieno IP adreso penktadienį 18:00. Tas serveris akivaizdžiai sulėtėja, užklausos vykdymo laikas pašoka keliais šimtais procentų. Ir situacija tokia pasilieka.

Tuomet išaušta pirmadienis. Į darbą ateina sistemos administratorius, pasidaro kavos ir pasitikrina el. paštą. 8:56 mūsų IP adresas užblokuojamas.

Jei palauksime ilgojo savaitgalio, turėsime 86 valandas netrukdomo darbo. Atsižvelgiant į Lietuvoje egzistuojančių vienetų skaičių, tiek laiko pakanka įvykdyti daugelį operacijų visos populiacijos mastu.

Įsivaizduokime, kad oro uostuose nėra metalo detektorių. Apskritai nėra jokio fizinio patikrinimo. Apsaugos viršininkas prieš išeidamas iš biuro 17:00 tik palieka sąrašą su pravardėmis, kam šįvakar draudžiama įeiti į oro uosto teritoriją. Tuomet pro oro uosto vartus nešinas kažkokia įranga įeina nematytas pilietis. Apsauga jį įleidžia, nes jo pravardės nėra juodajame sąraše.

Jis įlipa į skristi pasirengusį lėktuvą. Prikala prie jo grindų kažkokią metalinę kapsulę. Nusišypsodamas įžnybia skrydžio palydovei ir užsidegęs cigarą palieka lėktuvą. Sėda į artimiausią kuro užpildymo automobilį ir išvažiuoja namo. Oro uosto apsaugos darbuotojai stebi, bet nieko nedaro. Juk tas asmuo prisistatė tokia pravarde, kurios nėra juodajame sąraše.

Budintys apsaugos darbuotojai laukia, kol ryte apsaugos viršininkas peržiūrės filmuotą medžiagą ir įtrauks šio piliečio pravardę į juodąjį sąrašą. Kitą vakarą jis tokia pravarde nebebus įleidžiamas. Bet bus įleidžiami visi kiti, apie kuriuos dar negirdėjome. Ir tie, kurie pasikeitė pravardę. Ir tie, kurie atėjo su 100 tokių pačių savo draugų. Žodžiu, visi, kurie telpa pro vartus nenugriaudami oro uosto, jei tik jų pravardžių nėra juodajame sąraše.

Kaip saugiai jaustumeis įsilaipinęs į lėktuvą tokiame oro uoste?

Būtent tokiu apsaugos principu veikia mūsų valdžios IT sistemų ugniasienės. Jos turi jėgą pilnai apsaugoti sistemas, bet joms neleidžiama mąstyti ir priimti situacijai adekvačių sprendimų.

Koks didžiulis ir akivaizdus pavojus staiga beiškiltų, šiandien ugniasienė apsaugo tik nuo vakarykščių grėsmių, kurias jau pastebėjo ir detaliai apibūdino administratorius. Nuo šiandienos grėsmių ji apsaugos rytoj. Ko verta tokia apsauga?

Protingam ugniasienės naudojimui yra būtinas automatinis srauto filtravimas. Algoritmiškai pastebėjus anomalijas, naujos taisyklės ir ribojimai kuriami automatiškai. Pavyzdžiui:

Gavom patvirtintus formos duomenis iš IP, kuris neapsilankė pirmose trijose duomenų suformavimui skirtuose žingsniuose? Blokuojam, ryte administratorius patikrins.

Gavom 20 užklausų kas 1 sekundę iš vieno IP? Blokuojam, ryte administratorius patikrins.

Gavom identiškai suformuluotą užklausą kaip ką tik užblokuota, tik iš kito IP adreso? Blokuojam, ryte administratorius patikrins.

Principą supratai. Automatinis operacijų registravimas ir konteksto jose analizavimas padės užblokuoti atakas iš IP adresų, kurie dar neįvykdė nė vienos operacijos.

Net 24/7 dirbantis administratorius negali užkirsti kelio pirmam pažeidimui. Jis blokuoja tik tuomet, kai jau yra įvykdyta bent keletas įtartinų operacijų. Kiekviena tokia operacija yra sistemos pažeidimas, kuriam būtina užkirsti kelią iki įvykdymo.

Tai yra pats sudėtingiausias saugumo sprendimas iš visų 5 čia aprašytų. Pašalinus visas kitas spragas, galima gyventi ir be duomenų srauto filtravimo. Tačiau jį įsidiegus, atkris daug rizikų dėl galbūt nepastebėtų saugumo spragų ir su sistema žaidžiančių kenkėjų.

Pirmyn į saugesnius 2015

Pirmos 4 spragos tėra žioplos klaidos arba neapsižiūrėjimai. Šias spragas galima pašalinti tą pačią dieną be jokių papildomų išlaidų. Kad jų išvengtume ateityje, tereikia platesnio suvokimo ir pamąstymo apie specifinius scenarijus testuojant sistemas.

Aš esu LR pilietis ir mano bei mano įmonių duomenys yra saugomos tose pažeidžiamose sistemose. Jei lietuviškai skaitai šį straipsnį, tu tikriausiai toks pat – ir tavo duomenys yra prieinami visiems. Svarbiausia – tavo vardu gali būti atliekamos operacijos valstybinėse IT sistemose.

Kasdien kiekvienas rizikuojame būti išnaudoti nepilietiškų kaimynų. Kaip tauta rizikuojame dideliais mūsų privačių duomenų nutekėjimais į kitas valstybes. Tai gali būti panaudota ne tik prieš konkretų asmenį, bet prieš mus kaip visuomenę.

Sistemų kūrėjus skatinu sukurti standartinį testą, kurį privalėtų praeiti visos valstybinėse IT sistemose įdiegtos funkcijos. Tuomet siūlau registruoti visus vartotojų veiksmus ir reguliariai juos analizuoti ieškant anomalių veiksmų. Galiausiai, operatyviai ir dėkingai reaguoti į vartotojų praneštas spragas – jie atlieka mūsų darbą.

Kiekvieną eilinį vartotoją skatinu ieškoti saugumo spragų visose IT sistemose, kuriomis naudojiesi. Pastebėjęs, pranešk apie jas IT sistemų savininkams. Jei nesi dėl kažko tikras, paklausk komentaruose.

Raskime ir užlopykime skyles anksčiau, nei jas kas nors išnaudojo. Mūsų saugumas – mūsų valdžios ir jai IT sistemas programuojančių įmonių rankose. Padėkime jiems.

Prašau pasidalinti šiais saugumo patarimais su pažįstamais. Saugūs esame tuomet, kai saugumas yra kiekvieno iš mūsų pareiga.

Autoriaus interesų atskleidimas

Mano vadovaujama UAB „Virtuali erdvė“ valstybinėms institucijoms pardavinėja ir padeda įsidiegti perduodamų duomenų saugumą užtikrinančius SSL sertifikatus. Lietuvos įmones konsultuoju duomenų saugumo tinkle ir kitais interneto aplikacijų saugumo klausimais.

Autorių teisės

Creative Commons licencija Straipsnis „5 dažniausios IT sistemų saugumo spragos Lietuvoje“, kurio autorius Pakamore pasilieka ir saugo visas savo autoriaus teises, yra licencijuotas publikavimui pagal Creative Commons Priskyrimas + Jokių išvestinių darbų (BY-ND) 4.0 tarptautinę licenciją.