Tag Archives: teek

Olulised turvanõrkused 2022. aasta 43. nädalal

OpenSSL-i teegis parandatakse kriitiline haavatavus

Eelmisel nädalal teatas OpenSSLi teegi arendaja, et 1. novembril ajavahemikus 15.00–19.00 (EET) avalikustatakse teegist uus versioon 3.0.7, mis paikab kriitilise turvanõrkuse (OpenSSL, ZDNET).

Arendaja hinnangul on nõrkus kriitiline, kui see mõjutab laialt levinud konfiguratsioone ja on tõenäoliselt ka ärakasutatav[1]. Lisaks hindab arendaja nõrkuseid kriitilise tasemega siis, kui nende abil on võimalik kerge vaevaga kompromiteerida serverite privaatvõtmeid või teostada koodi kaugkäitust.

Kes ja mida peaks tegema?

Kirjutamise hetkel ei ole teada, milles turvanõrkus seisneb, kuid see mõjutab OpenSSLi versioone 3.0.0 kuni 3.0.6.

Kuna turvanõrkus võib mõjutada paljusid erinevaid IT-süsteeme, tuleb süsteemide halduritel kindlasti kontrollida, kas haavatavaid OpenSSLi teeke kasutatakse. Kui jah, tuleb 1. novembril vastav uuendus kindlasti rakendada, sest tagajärjed võivad olla üsna tõsised.

Soovitame jälgida ka seda Githubi repositooriumi.

Kontekst: OpenSSL on teek, mida kasutavad näiteks veebiserverid sageli krüpteeritud HTTPS-ühenduste loomiseks. Meiliserverid ja VPN-protokollid (nt OpenVPN) kasutavad krüpteeritud sidekanalite loomiseks samuti OpenSSL-i. Teeki võib leida ka paljudest teistest toodetest.

Viimase kümne aasta jooksul on teegis olnud kaks tõsisemat turvaviga. Esimene avastati 2016. aastal ja see võimaldas süsteeme üle võtta ning nende tööd häirida.

Teine turvanõrkus pärineb 2014. aastast (CVE-2014-0160) ja seda teatakse IT-maailmas nimetusega HeartBleed. Viga mõjutas miljoneid veebilehti ja selle abil oli võimalik ründajatel varastada tundlikke andmeid (krediitkaardinumbreid, nimesid jne).

Apple paikas nullpäeva turvanõrkuse

USA tehnoloogiahiid Apple teavitas 24. oktoobril üldsust mitmetest turvanõrkustest, mis paigati uutes iOSi ja iPad OSi operatsioonisüsteemide versioonides. Üht olulisemat parandatud turvanõrkust nimetatakse tähisega CVE-2022-42827 ja see mõjutab nii iPhone kui ka iPade. Apple sõnul on üritatud seda turvanõrkust aktiivselt ka ära kasutada, kuid täpsemaid detaile ei ole ettevõte jaganud (BP, Apple, RIA, BP).

CVE-2022-42827 turvanõrkuse abil saab häirida rakenduste tööd või käivitada pahatahtlikku koodi, et saada kasutaja seadmes kõrgemad õigused tegutsemiseks: nii saab ründaja teoreetiliselt varastada seadmesse kogutud andmeid, teha kuvatõmmiseid süsteemist jne.

Kes ja mida peaks tegema?

Konkreetne turvanõrkus, lisaks paljudele teistele haavatavustele, on parandatud uuemate seadmete jaoks iOSi versioonis 16.1 ja iPadOSi versioonis 16.

iOS 16.1 või iPadOS 16 saab paigaldada järgmistele mudelitele:
iPhone 8 ja uuemad
iPad Pro (kõik mudelid)
iPad Air 3 ja uuemad
iPad viies põlvkond ja uuemad
iPad mini 5 ja uuemad

Vanemate seadmete puhul on turvaviga parandatud iOSi versioonis 15.7.1 ja iPadOSi versioonis 15.7.1.

iOS 15.7.1 või iPadOS 15.7.1 saab paigaldada järgmistele mudelitele:
iPhone 6s või uuemad
iPad Pro (kõik mudelid)
iPad Air 2 või uuemad
iPad viies põlvkond ja uuemad
iPad mini 4 või uuemad
iPod touch (seitsmes põlvkond)

Kui sinu Apple’i telefon või tahvelarvuti on andnud märku uuendamisest, palun tee seda esimesel võimalusel!

Google parandas uue nullpäeva turvanõrkuse Chrome’i veebilehitsejas

Google avalikustas Maci, Linuxi ja Windowsi operatsioonisüsteemidele Chrome’i uue versiooni 107.0.5304.87, milles parandati üks kõrge tasemega haavatavus (CVE-2022-3723). Nõrkus peitub Chrome’i V8 JavaScripti komponendis ja ründaja saab seda teoreetiliselt kasutada näiteks andmete lugemiseks teistest rakendustest. Google on teadlik, et nõrkusele on olemas eksploit (nõrkust ärakasutav programm) (DR, CR). 

Kes ja mida peaks tegema?

Kui te kasutate Chrome’i veebilehitsejat, uuendage see esimesel võimalus. Juhised uuenduste installeerimiseks leiate siit.

Cisco hoiatab kahest turvanõrkusest, mida taas kuritarvitatakse

Cisco hoiatas oma kliente turvavigadest Cisco AnyConnect Secure Mobility Client for Windows tarkvaras. Turvanõrkused avastati juba 2020. aastal (CVE-2020-3433 ja CVE-2020-3153), kuid neid on viimasel ajal hakatud taas aktiivselt kuritarvitama. Mõlema turvanõrkuse kuritarvitamiseks peab ründajal olema süsteemile autentitud ligipääs (BP).

CVE-2020-3433 (7.8/10.0) nõrkuse põhjuseks on ressursside ebapiisav valideerimine, mida rakendus töötamise ajal laadib. Ründaja võib seda nõrkust ära kasutada, saates AnyConnecti protsessile spetsiifilise IPC (interprocess communication) sõnumi. Edukas ärakasutamine võib lubada ründajal käivitada mõjutatud masinas suvalist koodi süsteemiõigustes.

CVE-2020-3153 (6.5/10.0) haavatavus võimaldab ründajal kopeerida faile süsteemikataloogidesse. Haavatavuse põhjuseks on kataloogiteede (directory path) ebakorrektne käsitlemine.

Kes ja mida peaks tegema?

2020. aastal väljastati turvanõrkustele parandused ning kui te ei ole mõjutatud tarkvara siiani paiganud, soovitame kindlasti esimesel võimalusel tarkvara uuendada. Informatsiooni haavatavate versioonide kohta leiate ametlikelt tootja veebilehtedelt, millele on viidatud ülal.

[1] https://www.openssl.org/policies/general/security-policy.html

RIA analüüsi- ja ennetusosakond

Kuhu heidame usaldusankru?

Riigi Infosüsteemi Ameti analüütik Anto Veldre kirjutab usaldusnimekirjade aegumisest.

5_500

Allikas: http://oceanexplorer.noaa.gov/history/readings/gulf/media/5_500.jpg

Internetis leidub üks ressurss, mida tavainimene otseselt ei vaja – nimelt TL – Trusted List. Küll aga vajab seda ressurssi ID-kaardi baastarkvara, eriti ja eelkõige siis DigiDoc3 klient (programm). Ehk siis – sama programm, mida kasutatakse oma arvutis digiallkirja andmiseks.

Tegelikult – DigiDoc3 klientprogramm küsib kohe käivitudes netist järele, keda ta allkirjade küsimuses üldse peaks usaldama. Teistpidi sõnastades, TL on Euroopa poolt heaks kiidetud, sertifitseeritud ja muidu toredate teenusepakkujate nimekiri (list), ilma milleta on arvutis pea võimatu digiallkirju anda või verifitseerida.

Peatselt aga seisab meil ees sündmus, kus TL vana versiooni (v30) kehtivusaeg saab ümber, mistõttu digiallkirjadega toimetavad programmid peavad endale hankima Trusted Listi uue versiooni. Kõige uuem ja praegu kehtiv TL kannab muide versiooninumbrit 32.

Mis seal salata, vahepeal õppisid kontorite itimehed usaldusankrut pisut “sättima”. Selmet kogu kontoris tarkvara ära uuendada, trikitasid nad oma ankru merre TL vana versiooni kohal. Ent nagu öeldud, detsembris saab see epohh läbi, sest TL v30 lihtsalt aegub, lõpetab kehtivuse.

Ja nüüd asub kontorisündmusi juhtima pisuke “lisamure”. Vahepeal nimelt uuendati kogu Euroopas TL vormingut. Kui Trusted List v30 avalikustati veel vanas vormingus (v4), siis praegu kehtiv TL on sõnastatud juba järgmises, v5 vormingus. Seega, iga programm, mis soovib digiallkirjadega toimetada (koduarvutis, tööarvutis, teenuseserveris), peab suutma TL v5 vormingut lugeda.

Mäletatavasti juulist ajaarvamine muutus ning pärast usaldusteenuste üleminekut eIDASele saame üle-euroopalises kontekstis vaid ülejäänud Euroopaga sama jalga käia. Trikitamisvõimalused on otsas.

Kodukasutaja

Klientide pool jookseb piir baastarkvara v 3.12.4 juurest. Teisisõnu, usaldusteenuse pakkujate nimekirja uut vormingut suudab töödelda ID-kaardi tarkvara alates versiooninumbrist 3.12.4. Kõik eelmised versioonid jäävad uue vormingu lugemisega hätta.

tarkvara-klient

Allikas: id.ee

Kodukasutajal pole vaja teha suurt muud, kui tuua aadressilt installer.id.ee endale ID-kaardi tarkvara uusim versioon ning see paigaldada. Uuendamine toimub kiiresti ning juba viie minuti pärast töötab kõik taas. Versiooninumbrid… nende teadmine kahju ei tee, kuid kaasajal saab ka ilma mõtlemata – uusim tarkvara töötab kõige paremini.

Kui kristalselt aus olla, siis võiks kasutaja veel üle vaadata, ega mõni brauseriplugin järsku sättimist ei vaja… sirvikutootjad on läinud väga täpseks ja võib juhtuda, et sirviku pluginates vajab mõni linnuke tegemist.

Ent Vista ja XP? See rong on läinud, neid operatsioonisüsteeme ei toetata juba poolteist aastat. Põhjus lihtne – pole mõtet maksumaksja raha surnud hobusesesse pumbata.

Teekide ajaloost

Kogu edasine jutt on mõeldud asutuste ja firmade asjapulkadele – kodukasutajale pole järgnev info ülearu põnev. Et siis millal täpselt tekkis vajadus jDigiDoc välja vahetada DigiDoc4j vastu?

Vanasti kasutasid asutused ja firmad digitaalallkirjastamiseks ja allkirjade kontrolliks teeki (ingl.k. library) nimega jDigiDoc. DDOC formaadiga sai see teek kenasti hakkama, kuid siis ajad muutusid – saabus BDOC vorming, saabusid euronõuded. Et saada hakkama ka digitaalallkirja uuemate vormingutega, nagu BDOC või suisa ASiC-E, valmis uus teek nimega DigiDoc4j (muide, vahel kasutatakse DigiDoc4j asemel ka lühendit DD4J.)

DD4J tuleku ajalugu (lihtsalt selleks, et keegi ei saaks öelda, et ta pole probleemipüstitusest kunagi varem kuulnud):

versioon-avaldatud

Allikas: id.ee

Vajadusest uuele teegile üle minna hakati rääkima juba päris ammu. Infohommiku materjal märtsist 2015. Novembris 2015 avalikustati DigiDoc4j teegi versioon 1.00. Vajadust vana teek kiiremas korras välja vahetada toonitati veel kord mais 2016. Lõpuks, oktoobris 2016 käib jutt juba üksnes uue teegi uuemast versioonist, eeldatakse, et vana jDigiDoc teek enam kasutuses pole.

Kontoris

Kontorikasutajaga on keerulisem lugu. Teatavasti kontorikasutaja ei saa ise oma tarkvaraversiooni muuta, seda teeb tema eest itimees. Itimehel on aga muresid palju – mõne tarkvara mingi versiooni tõstmine või langetamine pole itimehe jaoks primaarne tegevus, kuni ähvardab otsene oht. Vahel mõjutavad itimehe tööd ka suured ülemused, kes sätivad itimehe prioriteete eelarve kaudu. Ent.

Kontorites leidub kaks olulist tarkvara. Kõigepealt juba seesama eelpoolmainitud ID-kaardi baastarkvara, mis tuleb tõsta versioonile 3.12.4. Paraku on kontoreid, kus ajaloolistel ja eelarvelistel põhjustel on otsustatud jätkuvalt DDOCi küljes rippuda, selmet töövood BDOCi või ASiC-E peale häälestada. Nüüd, novembri lõpus, läheb neil kontoritel ikka väga kiireks. Juhul kui kontoriarvutites pole ID-kaardi tarkvara versiooninumbriga vähemalt 3.12.4, siis Euroopa poolt etteantud usaldusankrute listi lugeda ega lahti parsida ei õnnestu. Mis tähendab, et tööprotsessid lähevad katki.

Asutuste ja firmade serveriruumides leidub veel teinegi huvitav tarkvara, nimelt jubin, millega süsteemid automaatselt allkirju annavad ja kontrollivad. Need kontorid, kes ongi juba üle läinud tarkvarale DigiDoc4j, ei peaks väga muretsema. Kui installeeritud on vähemasti versioon 1.0.3 sellest teegist, siis osatakse 3. detsembril kaelakukkuv uus v5 vormingus usaldusnimekiri kenasti välja lugeda. Kui on installeeritud versioon 1.0.0, siis selle tõstmine versioonile 1.0.3 on ikkagi kordades lihtsam kui infosüsteemi sügavamat putitamist nõudev teegivahetus muldvanalt JDigiDoc teegilt moodsale euroteegile DigiDoc4j.

Pole saladus – osa kontoreid on ikkagi nipitanud ja jätnud vana teegi JDigiDoc pealt uuele teegile DigiDoc4j üle minemata, kuigi ülemineku vajadusest on kõigis meediakanalites pröögatud juba vähemalt poolteist aastat. Miks nad nii teevad? Sest IT arengust loobumine tähendab kokkuhoidu. Ju oli raha vaja kusagil mujal.

Ent nüüd on käes tõesti tagumine hetk. Juhul kui firma serverites ongi kasutusel muldvana jdigidoc, siis hakkab ilmnema üha rohkem probleeme – kodukasutaja (või hoopis välismaalane) saadab asutusse täiesti korrektselt allkirjastatud dokumendi, kuid asutuses pruugitav vana teek ei pruugi seda heaks kiita.“.

Pisut vähem paanikat tekib neis asutustes, kus DigiDoc4J on küll installeeritud ja infosüsteemiga sobitatud, kuid versiooninumber pisut liiga varane (1.0.2 või väiksem). Neis kohtades on olukord soodsam seetõttu, et infosüsteem ise on ju uuele teegile üle viidud ja suuremad juurutustööd sooritatud, jäänud on vaid koera saba pikendamine versiooninumbri või paari võrra, mis reeglina on suhteliselt kiire tegevus. Kahe nädalaga veel jõuab!

Patustajaid otseselt nimetamata tsiteerime üht varasemat blogikirjet (juuni 2016): “Vana ja aegunud JDigiDoc teeki (mille eluiga ja tugi on ammu lõppenud) pruugitakse täna 98% digiallkirjade loomiseks. Uus, euroühtesobiv DD4J teek on seni kasutusel vaid 0,05% digiallkirjade loomisel.”.