Veel kord paroolidest

Paroolidega on meil kõigil keerulised suhted. Läbi infosüsteemide on see olnud pidev võitlus kahe poole vahel – süsteemide administraatorid, kes üritavad kasutajatele turvalisemate paroolide kasutamist peale suruda; ning kasutajad, kes üritavad nendes reeglite rägastikus endale meeldejäävaid paroole tekitada.

Pole ime, et uudised sellest, kuidas paroolid tuleks juba ammu ajalukku saata ja kohe-kohe on lõpuks saabumas tehnoloogia, mis seda just teebki, leiavad laia kõlapinda. Praktikas pole asi muidugi nii lihtne.

Kasutajate poolelt on probleem eelkõige selles, et parool on oma ideelt väga lihtne asi – enamvähem kõik saavad selle toimimisest aru ja kõik oskavad seda kasutada. Teine probleem on tehniline, kuid olulisemgi – iga autentimismeetod sisaldab alati ka parooli komponenti ning parool on ainuke, mida saab kasutada iseseisvalt. Seose mitmeastmelise autentimisega tuleb kindlasti tuttav ette, et autentimisvahendid saab jagada kolmeks:

  • See, mida sa tead (parool)

  • See, mis sul on (telefon, krüptovõti, id-kaart)

  • See, mis sa oled (sõrmejälg, nägu, iiris jt biomeetrilised meetodid)

Kõige parem kaitse saavutatakse loomulikult siis, kui kasutusel on kõik kolm – juba ühe puudumisel süsteemi sisse logida ei saa. Selle, mis sul on, saab sult lihtsalt ära varastada või ka ainult korraks “laenata” ning selleks, et autentimisvahend kohe sellisena kasutatav poleks, kasutatakse pea alati ka parooli komponenti (nt Eesti ID-kaardil PIN-koodid). Biomeetriaga on lood veel keerulisemad – lisaks eelnevale (ka biomeetrilised andmed on varastatavad ja/või kopeeritavad) on neil ka vahetamise probleem. Kui telefoni ja krüptovõtme saame varguse korral välja vahetada, siis kuidas vahetada sõrmejälgi? Parool on seega asi, mida me niikuinii kasutame peame ning paljude süsteemide turvatase võimaldab seda endiselt kasutada ka iseseisvalt.

Liiga lihtne: selles paroolis puuduvad ilmselgelt suur- ja väiketäht ning number, lisaks on pikkust vaid 7 märki ja tegemist kunstiteosega (see parool võib esineda popkultuuri-sõnabaasis). Foto: Matthew Brodeur

Turvalisim viis on lasta paroolid genereerida arvutil ning hoida neid krüpteerituna paroolihalduris ning sellest olen ma juba mõni aeg tagasi siinsamas blogis kirjutanud. Kuigi turvalised, on paroolihaldurid endiselt suhteliselt vähe levinud ja inimesed eelistavad oma paari parooli paremal juhul meeles pidada, halvemal juhul lihtsalt paberile üles kirjutada. Aga vaatame siis asja teisest küljest – mida saavad teha infosüsteemide omanikud, et kasutajad käiksid paroolidega turvalisemalt ümber? Kas me oleme seni teinud oma parima, et kasutajad saaksid turvalise(ma)lt käituda?

2016 aastal avaldas NIST (National Institute of Standards and Technology) dokumendi koodiga 800-63B, mis sisaldab uusi USA riigiasutustele (teoreetiliselt) kohustuslikke reegleid infosüsteemide autentimise haldamiseks ning mis tekitas turvamaailmas kerge maavärina. Kuigi uudisekünnis sai vähemalt hetkeks ületatud, polnud selle sisus tegelikult midagi uut – see muutis lihtsalt väga ametlikuks selle, millest mõned turvaeksperdid juba aastaid olid rääkinud. Lühidalt võib dokumendi sisu võtta kokku nelja punkti.

  • Paroolide regulaarse vahetamise nõue on minevik. Mitmed tehtud uuringud on üheselt näidanud, et see mitte ei suurenda vaid hoopis vähendab paroolide turvalisust. Paroole peab vahetama ainult siis, kui on kahtlus, et parool on lekkinud.

Kasutajad leiavad parooli vahetamise nõudele rahuldamiseks kõige efektiivsema lahenduse.
  • Samamoodi on minevik paroolide keerukuse nõuded (peab sisaldama suur- ja väiketähti, numbreid ja erimärke). Täpselt samuti nagu paroolide regulaarne vahetamine, on seegi nõue tegelikult turvalisust hoopis vähendanud.

  • Paroolide kunstliku keerukuse asemel väärtustatakse paroolide pikkust – minimaalne lubatud pikkus peab olema vähemalt 8 sümbolit, maksimaalne lubatud pikkus vähemalt 64 sümbolit. Ning selleks, et kasutaja saaks enda jaoks mõistlikke, kuid ründaja jaoks keerulisi paroole kasutada, ei tohi olla olla ebamõistlikke piiranguid sümbolitele paroolis. Jah, ka tühikud ja isegi Unicode võiks olla OK.

  • Kohustus veenduda, et kasutajad ei kasutaks levinud ja ebaturvalisi paroole, lasub infosüsteemide omanikel. Eelkõige peab infosüsteem veenduma, et parooliks poleks üksikud sõnad sõnastikust (minimaalse lisaga, nt üks number), neid poleks lekkinud paroolide baasides ning parool ei sisaldaks kasutajanime ega korduvaid mustreid.

Populaarsed salasõnad, kultuurilised viited ja mugavad klahvijärjestused on esimesed, mida sissetungijad kasutada proovivad.

Kui nüüd natuke järele mõelda, ei ole selles midagi tervele mõistusele vastu käivat, kuid formaalselt on tegemist päris korraliku pöördega.

Esiteks ei toetuta paroolireeglite loomisel ainult loogikale ja kõhutundele vaid need toetuvad reaalsetele uuringutulemustele. Me võime küll arvata, et mingi reegel muudab me süsteemid turvalisemaks, aga kuidas on lood tegelikult?

Teiseks liigutab dokument olulise osa paroolidega seotud vastutusest kasutajalt infosüsteemide omanikele. Kuigi reaalsus on alati kompromiss turvalisuse ja kasutusmugavuse vahel, ei tähenda see seda, et me ei peaks kasutama võimalusi neid teineteisele lähemale toomiseks. Parool Karuvanaema tagumik on pärast 3. siilile istumist väga valus, on nii mugavam kasutajal meelde jätta kui ka turvalisem kui gT7ylak.0p – win-win situatsioon.

Samuti on väga oluline nihe panna seal, kus see tehniliselt võimalik on, paroolide turvalisuse eest vastutama infosüsteemide omanikud. Võrreldes seni domineerinud “kõik oleks turvaline, kui kasutajad käituks nii” suhtumisega on see suur muutus. Kui mingi probleemi lahendamiseks on tehnilised meetmed olemas, ei ole nende mitte rakendamiseks ning vastutuse kasutajatele lükkamiseks mitte mingit vabandust.

Kui nüüd kellelgi tekib (õigustatud) küsimus, et mis siis vahepeal muutunud on, et reeglid sellise pöörde tegid, on õige vastus – mitte midagi. Mees, tänu kellele me paroolide regulaarse vahetamise ja keerukusnõuete reegli all kannatanud oleme, tunnistas eelmisel aastal intervjuus, et see oli viga isegi 15 aastat tagasi.

Ka Zone vaatas eelmisel aastal kõige selle valguses paroolidele kehtestatud reeglid üle. Paroolide regulaarset vahetamist pole me küll kunagi nõudnud, kuid suur- ja väiketähtede jms reeglid on meie nõuetest kadunud ning pikad paroolid igasuguste sümbolitega lubatud. Seda kõikvõimalike sümbolite lubatavust ei maksa muidugi uisapäisa kasutama tormata. Näiteks klienditarkvara ei pruugi olla nii liberaalne kui Zone ning võib tema jaoks kahtlaseid sümboleid paroolis lihtsalt ignoreerida.

Samuti ei luba me parooli vahetades uues paroolis kasutada levinud paroolimustreid ja kasutajanime. Neist viimane halb harjumus tekitab reaalseid probleeme ka Zone kasutajatele ning Ardi on kirjutanud sellest ka meie blogis.

Vaatamata sellele, et info on avalik olnud juba mõnda aega, leiab ka Eestis suurel hulgal infosüsteeme, kus paroolid peavad endiselt olema nt 8-16 sümboliga, neil on keerulised keerukusnõueded ning neid tuleb iga kuu aja tagant vahetada. Sarnaseid nõudeid leiab endiselt turvapoliitikastest ja koolitusmaterjalidest ning sellest räägivad turvaeksperdid ajakirjanduses.

Kui ka sinu töökoha või kooli infosüsteemis endiselt sellised nõuded kehtivad, anna selle haldajale märku – viita sellele artiklile või palu guugeldada “NIST passwords 2016”. Aitame selle turvateatri lõpetada ning meie infosüsteeme ka tegelikult turvalisemaks muuta.

Meltdown ja Spectre ehk kuidas bittidega spekuleerida ja võõras mälus sobrada

Saabunud aasta algas IT-inimestele korraliku üllatusega – 3. jaanuaril jõudis avalikkus ette info, et protsessoritest on avastatud turvaprobleemid, mis võimaldavad sõltumata kasutatavast opsüsteemist pahatahtlikel tegelastel saada ligipääs andmetele, millele nad kuidagi ligi saada ei tohiks.

Kuigi alguses oli jutt peamiselt Inteli protsessoritest, sai peagi selgeks, et ka teiste tootjate protsessorid on probleemist mõjutatud, kuigi oluliselt vähem kui Inteli toodetud.

Üldise meeleolu illustreerimiseks sobib kenasti video terasetehasest. Meie püüame olla need tegelased lõpukaadritest, kes paanikasse ei satu, toimuvat dokumenteerivad ja rahulikult tagajärgedega tegelemiseks valmistuvad 🙂

Nagu tänapäeval tavaline, said turvaprobleemid oma tavapärastele CVE numbritele lisaks nime, veebilehe jpms. Peamiselt ainult Intelit puudutav probleem sai nimeks Meltdown (CVE-2017-5754) ja kaasaegsete protsessorite enamust puudutav probleem on Spectre, millel on kaks variatsiooni (CVE-2017-5753 ja CVE-2017-5715).

Kui üritada seda ühe lausega öelda, siis mõlema näol on tegemist on nõrkustega, mis võimaldavad pahatahtlikel rakendustel spekulatiivselt koodi käivitatavate protsessorite disainiprobleeme ära kasutades lugeda seadmetes külgkanalründe abil mälu, millele nad tegelikult ligi pääseda ei tohiks. Kuidas saab protsessoris üldse selliseid vigu olla ning millega täpsemalt tegemist, on jäänud paljudele arusaamatuks.

Sõnad “külgkanalrünne protsessori spekulatiivse käivitusse realisatsioonide vastu” ei tee enamusele asja oluliselt selgemaks, kuid neile, kes huvi tunnevad, on postituse lõpus lihtsustatud kokkuvõte probleemi olemusest. Kõik, kel jõud ja mõistus üle käib, peaksid kindlasti läbi lugema probleemid avastanud teadlaste originaalartiklid.

Mida siis nende probleemide tõttu tegelikult teha saab?

Praktiliselt ainult Inteli protsessoreid puudutav Meltdown on kahest probleemist tõsisem – kui pahatahtlik rakendus saab seadmes ennast käivitada, siis sellest piisab, et kogu operatsioonisüsteemi tuuma kasutuses olevat mälu maha lugeda. Lugemine ei toimu küll eriti kiiresti, kuid piisavalt, et sellest edasiseks ründeks ära kasutatavaid andmeid (paroolid, krüptovõtmed jms) leida. Probleemi on võimalik vältida tarkvaraliste vahenditega ja tänase päeva (15.01.2018) seisuga on kõik peamised operatsioonisüsteemid (Windows, MacOSX, iOS, Linux, Android) ka turvapaigad väljastanud.

Spectre võimaldab pahatahtlikul rakendusel lugeda nii operatsioonisüsteemi tuuma kui ka teiste rakenduste mälu, kuid selle ära kasutamine on oluliselt keerulisem. Selleks ei piisa lihtsalt koodi käivitamisest – see eeldab ka konkreetsete ära kasutatavate koodimustrite olemasolu operatsioonisüsteemi tuumas või teistes rakendustes. Keerukam on ka Spectre mõjude kõrvaldamine ning see võtab veel aega. Üks Spectre variatsioonidest on ilmselt suhteliselt lihtsalt lahendatav operatsioonisüsteemi tuuma tasemel, kuid teise vastaste meetmete otsing veel käib. Praegu olemas olevad lahendused on väga kulukad – kas kannatab jõudlus väga palju või peaks kõik seadmetes olevad rakendused uue kompilaatoriga ringi kompileerima.

Arusaadaval põhjusel on eelkõige ohustatud keskkonnad, kus kasutajad saavad vabalt koodi käivitada – eelkõige jagatud serverid ning virtuaalmasinate keskkonnad. Virtuaalmasinate puhul võimaldavad need nõrkused kasutajal ka ennast virtuaalmasinast välja murda – lugeda hüperviisori ja teiste virtuaalmasinate mälu. Kuid ohus on ka kõik tavalised tööjaamad – probleeme uurinud eksperdid on tõestanud, et rünnak toimib ka JavaScripti kaudu. Praeguseks on kõik suuremad brauserid rakendanud meetmed, et veebi kaudu probleemide ära kasutamine oleks vähemalt hästi keeruline.

Suhteliselt pessimistliku kirjelduse peale tekib kindlasti küsimus, et kuhu poole nüüd paanikas jooksma peaks ja mida tegema? Ja miks see üleüldse nii kaua aega võtab?

Üks on selge – protsessoreid välja vahetama ei hakka ei Intel ega ka ükski teine tootja ning nendest probleemidest vabad protsessorid jõuavad meieni ilmselt alles järgmisel aastal. Kuid rahu, ainult rahu. Probleemid on vaatamata tõsidusele protsessoritootjate abiga tarkvaras lahendatavad ning kõigi arenduses olevate operatsioonisüsteemide arendajad on praegu ametis. Aega võtab see ka selle pärast, et olukord on väga paljudele uus – tarkvara ja riistvara tootjad peavad tegema koostööd ja üksteist ka usaldama. Ma olen kindel, et tsivilisatsioon ei kuku veel selle pärast kokku, kuid turvapaikade operatiivne paigaldamine on olulisem kui kunagi varem. Nagu juba eespool öeldud, on Meltdown praeguseks juba suuremates opsüsteemides paigatud ning kui sul on uuemad turvapaigad seadmetes, oled sa tõenäoliselt selle vastu juba kaitstud.

Oluline on ka mõista, et kui ründajal pole seadmes võimalik koodi käivitada, otsest ohtu pole. Mis ei tähenda muidugi seda, et esimesel võimalusel uuendamist siiski ette võtma ei peaks – Meltdown ja Spectre võivad olla osa keerulisemast ründest, kus mingi teise turvaprobleemi tõttu saavutatakse kõigepealt koodi käivitamise õigus.

Kuidas Meltdown ja Spectre Zone servereid mõjutavad?

Nii Virtuaalserverite kui Pilveserverite puhul jagab hulk kliente sama riistvaralist serverit ning turvaprobleemid, kus ühe kliendi serveris jooksev kood võib mõjutada teisi, on meie jaoks kõrgeima prioriteediga. Tänaseks on Zone serverid Meltdowni vastu kaitstud – enamus juba 06-08.01 nädalavahetusel.

Küll aga tuletame meelde, et Pilverserver PRO kasutajad peavad oma virtuaalmasinate kernelite uuendamise eest ise hoolt kandma (Pilveserver VPS kernelid uuendasime 07.01 varahommikul).

Meie tehnikud jälgivad sündmuste arenguid ja paigaldavad parandused ka Spectre vastu niipea kui võimalik. Võimalik, et selleks on vaja veel üht erakorralist hooldusakent.

Kas Meltdown’i paikamine mõjutas ka serverite töökiirust?

Paikade mõju sõltub rakendusteks, aga tavapärase veebirakenduse puhul on meie seninsed testid näidanud, et muutus on pea olematu. Tegime oma koormustestiks kasutatava WordPress+WooCommerce+WPML+Flatsome näidisrakendusega teste ning uurisime rakenduse tasemel monitooringus olevate veebide käitumist ning mingit mõõdetavat erinevust ei tuvastanud.

Küll aga on muutus näha Pilveserver VPS protsessori-aja kasutuses. Sellel pildil on üks hardware node, kus ilmselt VPSides jooksvate rakenduste eripärast lähtuvalt on syscall’ide osakaal märkimisväärne ja kasvab ca 2% pealt ca 10% peale:

Kuna enamikul ülejäänutest oli kasv oluliselt väiksem, tasub rakenduse töökiiruse muutumisel vaadata üle kõik syscall’e põhjustav ehk ennekõike IO, sh andmebaasikasutus. Selle osa optimeerimine on mõistlik ka ilma Meltdown ja Spectre paikade negatiivse mõju peale mõtlemata.

Trivialiseeritud Meltdown ehk “Kuidas lugeda võõrast mälu?”

Probleemide olemuse mõistmine pole tegelikult ühelegi programmeerimisega kokku puutunule üle jõu käiv, kuid illustreerib väga hästi külgkanalründe olemust. Alljärgnev on kõvasti lihtustatud versioon Meltdown probleemist. Kõigepealt räägime pisut kaasaegse protsessori tööst.

Kaasaegsed protsessorid on kiired, kuid mälust lugemine ja sinna kirjutamine ca 100x aeglasem. Et protsessor mälu taga pidevalt ootama ei peaks, on protsessoritel varuks hulga trikke, millest olulisimad on spekulatiivne käivitamine ja vahemälu.

Kui arvutitunnis räägiti teile, et protsessor käivitab ühe käsu teise järel, siis tänapäeval ei vasta see tihti enam tõele. Kuna protsessorid on mälust nii palju kiiremad, üritavad nad juhul, kui neil midagi targemat teha pole, järgmiseks käivitatavaid programmi harusid ette aimata ning selle töö ka igaks juhuks ette ära teha. Kui peaks juhtuma, et tõenäoline stsenaarium siiski ei realiseerunud, unustatakse see igaks juhuks ette tehtud töö tulemus lihtsalt ära. Kuna spekulatiivset tööd tehakse protsessori “vabast ajast”, ei muuda see midagi aeglasemaks, kuid kui stsenaarium realiseerub, on kiirusevõit oluline.

Võtame näiteks alltoodud veebilehe vaatamise pseudokoodi. Lehe kerimine on veebilehel oluliselt tõenäolisem sündmus kui lingile vajutamine ning protsessoril on kasulik see alati ette ära teha, isegi kui kasutaja veel kerimise liigutust teinud pole.

kui (kasutaja kerib lehte alla) {
  liigu rida allapoole;
} vastasel juhul kui (vajutatakse lingile) {
  liigu uuele lehele;
}

Sellisest spekulatiivsest käivitamisest poleks iseenesest aga väga palju kasu, sest suure tõenäosusega vajavad ka need käsud mälu poole pöördumist. Selle vältimiseks on protsessorites endis olemas hästi kiire vahemälu, kus hoitakse hiljuti kasutatud või sagedamini vaja minevaid andmeid neid mälust sinna portsu kaupa laadides. Kui protsessor vajab käsu täitmiseks andmeid mälust, laaditakse need vahemällu, kuhu need jäetakse ka pärast käsu täitmist – igaks juhuks, äkki läheb vaja.

Nüüd on meil olemas kõik põhiteadmised, et mõista alljärgnevat pseudokoodi. Pahatahtlik häkker soovib teada saada mis on mäluaadressi 0x200 vähima kaaluga biti väärtus. Rakendus ei saa seda mäluaadressi otseselt lugeda, kuid ta saab kirjutada sellise programmi.

kui (tingimus) {
  kui (aadressil 0x200 on 1) {
    loe väärtus aadressilt 0x800;
  } vastasel juhul {
    loe väärtus aadressilt 0x900;
  }
}
loe väärtus aadressilt 0x800;
mõõda eelmise käsu täitmiseks kulunud aeg;
loe väärtus aadressilt 0x900;
mõõda eelmise käsu täitmiseks kulunud aeg;

Protsessor täidab spekulatiivselt tingimuslaused ja kuigi selle käigus toimub lugemine aadressilt 0x200, millele pahatahtlik rakendus ei tohiks ligi saada, on see esmapilgul ohutu, sest protsessor on disainitud nii, et rakendus lõpetaks töö kohe, kui „tingimus“ peaks tõeks osutuma ja enne, kui 0x200 aadressilt lugemine rakenduseni reaalselt jõuaks. Sellel spekulatiivsel tingimuslausete täitmisel on aga kõrvalefekt – kas 0x800 või 0x900 aadress laaditakse protsessori vahemällu. Kui nüüd pärast seda mõõta 0x800 ja 0x900 aadresside lugemiseks kuluvat aega, on meil võimalik järeldada kas kumbki neist oli juba protsessori vahemälus olemas (kiire) või tuli seda mälust lugemas käia (aeglane) ning sellest järeldada aadressil 0x200 asuva biti väärtuse.

Tegelikult on probleemide olemus ja ära kasutamine muidugi märksa keerulisem, kuid põhimõte on just nii lihtne – pahatahtlik rakendus saab aja mõõtmise abil järeldada mis väärtused on mäluaadressidel, millele ta muidu ligi ei pääse. Kuna mäluaadresse otse ei loeta, vaid seal leiduva kohta tehakse järeldusi käskude käivitamiseks kulunud aega mõõtes, nimetataksegi selliseid ründeid külgkanalrünneteks (inglise keeles side-channel attack).

Need tüütud salasõnad

Alguses oli salasõna. Ja salasõna oli ‘god’… või ‘love’ või ‘sex’ või ‘secret’. Möödusid aastad ja enam pole ka ‘s3x-g0d-l0ve-s3cr3t’ piisavalt keeruline. Mis nüüd?

teh-plague

The Plague: Our recent unknown intruder penetrated using the superuser account, giving him access to our whole system.

Margo: Precisely what you’re paid to prevent.

The Plague: Someone didn’t bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and…

Margo: [glares at The Plague]

The Plague: god. So, would your holiness care to change her password?

Juba arvutite ja Interneti koidikul vajasid süsteemid tõendit, et terminali taga istuv kasutaja on just see, kes ta väidab ennast olevat ning lühike tekstijupp kõlbas selleks väga hästi. Alguses polnud salasõna keerukus kuigi oluline, sest arvutiteid oli vähe ning nendes olev info polnud ka kuigi kriitiline. Piisas sellest, kui parool polnud liialt kergesti ära arvatav. Asjade arenedes tekkis aga pahatahtlikematel kodanikel huvi paroole ära arvata ja murda ning rakendada selleks ka selleks tööks sobivaid masinaid – arvuteid. Et arvutid mõistliku ajaga seda ülesannet lahendatud ei saaks, mõtlesid targad inimesed välja Turvalise Salasõna Reeglid.

Me kõik oleme paroolireeglitega kokku puutunud. „Paroolis tuleb kasutada suuri ja väikseid tähti, vähemalt üht numbrit ja üht muud sümbolit ning see peab olema vähemalt 8 sümbolit pikk.“ Probleemid selle lähenemisega ilmnesid tegelikult juba päris alguses. Ükskõik kui keerulisi reegleid sa ka ei kehtesta, leidub ikka väga lihtsalt ära arvatavaid paroole, mis kõigile keerukuse tingimustele vastavad. „Parool1.“ on täielikult eelpool toodud tingimustele vastav salasõna. Asja tegi veel hullemaks kellegi rumal idee, et kasutajad peavad iga kolme kuu tagant paroole vahetama. See sundis kasutajaid veel eriti leidlik olema, et uusi kiirelt meeldejäävaid “turvalisi” paroole leiutada. Nii, kuidas on kasvanud arvutite paroolimurdmise võimekus, on läinud rangemaks ka paroolile kehtivad nõuded. Ükskõik kui keerulist kaheksa sümboliga parooli ei loeta juba tükimat aega turvaliseks ja paroolide meeles pidamine on muutunud järjest raskemaks.

Vahepeal levinud nõuanne kasutada lühema suvaliste sümbolite jada asemel palju pikemat suvaliste sõnade jada, mis oleks nagu arvutile raskem murda, oli kasulik ainult nii kaua, kui paroolide murdmiseks kasutatav tarkvara polnud nendega arvestanud. Praeguseks kasutavad kõik popimad paroolimurdjad ka sõnastikke ning “My-Very-Secure-But-Long-Not-Random-Password” stiilis salasõnu ei loeta ka enam turvaliseks. Isegi juhuslike tähtede asendamine numbritega ei aita. Eestlasi aitab hetkel natuke see, et meid on nii vähe ja eesti keele sõnastikud pole paroolimurdjates veel levinud. Kuid nende sinna jõudmine on ainult aja küsimus.

Aegamööda tekkis kasutajatel teenuseid, kus parooliga ennast tuvastama peab, järjest juurde – e-poed, hobifoorumid, uudisteportaalid jne. Erinevatel andmetel on keskmisel internetikasutajal praeguseks üle 100 erineva konto. Sellist hulka erinevaid turvalisi paroole ei suuda muidugi enam keegi meeles pidada ning väljapääse on kaks – kas kirjutada salasõnad üles või neid taaskasutada. Paljud läksid muidugi kergema vastupanu teed ja valisid viimase. Heal juhul paar erinevat parooli erineva turvatasemega kontodele (olulistel üks parool, vähemolulistel teine), kehvemal juhul üks parool kõigile. Ega tegelikult saa seda neile ka väga pahaks panna, sest turvaeksperdid olid eelnevalt aastaid (aastakümneid?) korranud pidevat mantrat – „Paroole EI TOHI üles kirjutada!“.

Paroolide taaskasutamine pole ka muidugi kunagi väga hea idee olnud, kuid see on kasutajate enamuse jaoks toiminud – kuni nad pole sihitud rünnaku sihtmärgiks sattunud. Uued ajad on toonud aga uued probleemid. Nii, kuidas järjest rohkem infot on võrku liikunud, on kasvanud ka võimalused seda infot rahaks teha. IGA konto, ükskõik kui tähtsusetu see sulle ka ei tundu, on pahatahtlike kodanike jaoks ressurss, mida on võimalik kuidagi raha teenimiseks kasutada. Kui mitte muul moel, siis rämpspostituste tegemiseks ikka. See omakorda on tekitanud pahatahtlikes häkkerites enneolematu huvi kasutajate info teenuspakkujate juurest pihta panna – pahatihti ka väga edukalt [1]. Ka ei ole sellised lekked enam ammu teisejärguliste ja vähemtähtsate teenuste pärusmaa. Aja jooksul on kümnete miljonite kasutajate andmeid lekitanud Linkedin, Evernote, Dropbox, Ebay, Mail.ru, Yahoo ja paljud teised. Viimane suurem leke toimus täsikasvanute portaale haldavast firmast “Friend Finder Network”, kust lekkisid 412 miljoni kasutaja andmed, sh paroolid.

Kurjategijate peamine huvi on saada ükskõik mis teenusest kasutajate e-posti aadressid ja salasõnad. Kui teenusepakkuja on olnud väga lohakas ja hoiab paroole krüpteerimata kujul, on pahalase töö eriti kerge. Kui ettevaatusabinõud on tarvitusele võetud, on paroolid küll krüptitud, kuid nende lahti murdmine sõltub põhiliselt parooli turvalisusest. OK, saavad pahad parooli teada, mis nad selle infoga peale hakkavad? Nad kasutavad seda infot katseteks murda teisi teenuseid. Lihtsustatult – kui sul on lillekasvatajate foormis konto meiliaadressiga “kukununnu98@gmail.com” ja mille parooli kurjategija kätte saab, on loogiline samm katsetada selle sama infoga sisse logida Gmail’i, Facebook’i, teistesse foorumitesse jne Kui sa paroole taaskasutad, ongi sinu olulised kontod kaaperdatud. Kui läheb hästi, pääsed ehmatuse ja salasõnade vahetusega, kuid juhtumid, kus kurjategijad kasutavad kaaperdatud kontosid edasisteks pettusteks ning inimesed saavad olulist maine- ja rahalist kahju, pole sugugi harvad.

Lahendusi, kus kasutaja tuvastamine ei sõltu ainult ühest suhteliselt kergelt näpatavast salasõnast, on olemas küll – on riistvaralisel krüptograafial põhinevad lahendused (Eesti ID-kaart) ja on mitmeastmelisest autentimist kasutatavad lahendused. Ka Zone teenusportaalis saavad kasutajad ennast ID-kaardi või mobiil-ID abil tuvastada ning parooli kasutamise võimaluse üldse välja lülitada. Mitmeastmelisel autentimisel ei hakka ma lähemalt peatuma, sest RIA on oma blogis sellest pikalt kirjutanud [2] ning avaldanud ka juhised kuidas kaheastmelist tuvastus Gmailis [3] ja Facebookis [4] kasutusele võtta. Mitmeastmeline autentimine on praegu laialt saadaolevatest võimalustest parim kaitse kontode kaaperdamise vastu ning igaüks peaks seda võimalusel kasutama! Probleem on aga selles, et nendest sadadest teenustest, mida me iga päev kasutame, on mitmeastmelise autentimise kasutamine võimalik väga vähestel – minu aastate jooksul kogunenud ca 500-st kontost on sellised ainult 18. Seega kasutab rõhuv enamus kontosid kasutaja tuvastamiseks endiselt ainult salasõna. Miks?

Põhjuseid on päris palju, kuid olulisim sellest on kasutamise keerukus – nii teenusepakkujatele kui ka kasutajatele. IT arhitektide poolelt ma luban, et me oleme üle maailma juba joonestuslaudade taga ja kindlasti tuleme me välja paremate lahendustega, kuid me peame kuidagi ka sinnamaani hakkama saama. Kuidas on siis võimalik Internetis paroole kasutades ellu jääda? Erinevalt andmetel loetakse praegu turvaliseks juhuslikest sümbolitest salasõnu, mis on pikemad kui 16 sümbolit ning sama parooli kasutamine erinevates teenustes peaks olema täielikult välistatud. Kuidas need sajad paroolid meelde jätta? Ega see polegi võimalik ning lahendust pakuvad paroolihaldurid.

Paroolihaldur on tarkvara, mis hoiab kõiki su salasõnu krüpteeritud andmebaasis, mille kasutamiseks on vaja meeles pidada ainult üks (kuid siiski keeruline ja pikk!) salasõna. Moodsad paroolihaldurid abistavad sind kõiges, mis paroolide veebis kasutamist puudutab. Need aitavad sul turvalisi paroole genereerida, meeles pidada ning täidavad brauserite pluginate abil automaatselt sisselogimise vorme. Targemad paroolihaldurid tegelevad ka lekete info kogumisega ning hoiatavad kasutajat kui mõni nende parool on teenusepakkuja juurest Internetti lekkinud. Jah, paroolihaldurid pole ideaallahendus, need loovad omakorda uusi turvaprobleeme, kuid tõstavad latti siiski oluliselt kõrgemale ning on hetkel parim lahendus salasõnade kasutamiseks.

Ka paroolihaldurid on keerulisemad, kui üks laiatarbe turvalahendus olla võiks, kuid see pole raketiteadus – vähese õpetamise järel saavad kõik sellega hakkama. Kui te seda veel teinud pole, võtke kohe kasutusele LastPass [5] või mõni muu paroolihaldur (tundmatumaid asju soovitan siiski vältida). Tehke see selgeks endale ning õpetage ka abikaasale, lastele, vanematele ja sõpradele. Kuni IT-süsteemide arhitektid üle maailma parema süsteemi välja mõtlemiseks ajusid ragistavad, päästavad paroolihaldurid meid hullemast.

[1] http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/
[2] https://blog.ria.ee/multiautentimisest/
[3] https://blog.ria.ee/kaheastmeline-autentimine-gmail/
[4] https://blog.ria.ee/kaheastmeline-autentimine-facebook/
[5] https://www.lastpass.com/

Räpased koduloomad serverites – Dirty COW

Lõbusa nime Dirty Cow taga peitub viimase aja üks ohtlikumaid Linux operatsioonisüsteemi turvanõrkuseid. Kui sinu haldusalas on Linux servereid, siis loe kindlasti mida kirjutab selle kohta Zone.ee infosüsteemide arhitekt.

cow-147576_1280Eelmisel nädalal parandati esialgu suurema kärata Linuxi kernelis mäluhalduse viga, mis on suutnud seal 9 aastat märkamatuks jääda. Peagi selgus, et asi on oluliselt tõsisem kui paranduse tekstist arvata võis – viga kasutatakse pahatahtlike häkkerite poolt juba aktiivselt ära ning tõenäoliselt on seda tehtud juba pikemat aega. Probleem on niivõrd tõsine, et sundis teenusepakkujaid üle maailma erakorralisi hooldustöid ette võtma ning on teada ka juhtumeid, kus halvima ära hoidmiseks teenustel paranduse paigaldamiseni sõna otseses mõttes juhe seinast tõmmati. Ka Zone tehnikutel olid nädala lõpus käed tööd täis. Ning nagu tõsiste turvaprobleemide puhul tänapäeval tavaline, sai probleem oma veebilehe, logo ja nime – Dirty COW.

Miks selline paanika? Lühidalt saavad süsteemi tavakasutajad leitud viga ära kasutades kirjutada mälupiirkondadesse, kuhu kirjutamise õigust neil olla ei tohiks, ning sellisel moel oma õigusi süsteemis suurendada. Koos vea avalikustamisega käivitus ka võistlus koodikirjutajate vahel – kes suudab välja tulla lihtsama ning töökindalama meetodiga, kuidas anda tavakasutajale root kasutaja õigused ja seega täielikku kontrolli kogu süsteemi üle? Tänaseks on Internetis vabalt saada mitmeid koodijuppe, mis teevad seda nii hästi, et nende kasutamine pole mingi probleem ka kõige kogenematule pahalasele. Kui alguses levis ka info, kuidas süsteemi uuendamata enda süsteeme kaitsta, siis praegu levivate ründeprogrammide vastu on need kasutud. Ainuke toimiv kaitse on kerneli uuendamine.

K: Kes/mis on mõjutatud?
V: Kõik Linuxi süsteemid, mis kasutavad kerneli versiooni 2.6.22 või uuemat. Kuna 2.6.22 ilmus aastal 2007, siis võib põhimõtteliselt vist öelda – pea kõik maailmas leiduvad Linuxid, mida pole viimase nädala jooksul tahtmatult või tahtlikult uuendatud. Alloloevast nimekirjast leiad populaarsemate Linuxi distributsioonide kernelite versioonid, kus viga juba parandatud. Kui sinu süsteemis on kerneli versiooninumber (seda saad vaadata käsuga „uname -rv“) väiksem kui tabelis, on süsteem haavatav.

  • Ubuntu 16.10 – 4.8.0-26.28
  • Ubuntu 16.04 LTS – 4.4.0-45.66
  • Ubuntu 14.04 LTS – 3.13.0-100.147
  • Ubuntu 12.04 LTS – 3.2.0-113.155
  • Debian 8 – 3.16.36-1+deb8u2
  • Debian 7 – 3.2.82-1
  • RedHat/Centos 7 – 3.10.0-327.36.3

K: Mida ma teha saan?
V: Aitab ainult kerneli uuendamine. Kui su hallata on süsteemid, mis veel uuendamata, tee seda niipea kui võimalik.

K: OK, aga mida ma Zone kliendina tegema pean?
V: Kui kasutad meie tarkvaraplatvormiga serveriteenust (nagu Virtuaalserver või Nutikas Privaatserver) või Pilverserver VPS-i, kannab uuendamise eest hoolt Zone. Küll aga pead sa ise muret tundma ja tegutsema, kui oled Privaatserveri või Pilveserver Pro SSD kasutaja.

K: Kui mu süsteemis shelli kasutajaid pole, pole probleemi?
V: Probleem on ikka, lihtsalt natuke keerulisem ära kasutada. Interneti pimedamates nurkades on juba levimas ka valmiskomplektid stiilis “WordPressi turvaveaga tavakasutajaks + räpase lehmaga root kasutajaks”. Kui su Linux on Internetiga ühendatud, on selle turvalisus ohus.

Viited

https://dirtycow.ninja/
https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html
https://security-tracker.debian.org/tracker/CVE-2016-5195
https://access.redhat.com/security/vulnerabilities/2706661