Category Archives: CERT-EE

Olulised turvanõrkused 2023. aasta 27. nädalal

Üle maailma on enam kui 330 000 seadet, mis on haavatavad Fortigate’i turvanõrkusele

Kirjutasime blogis juuni keskpaigas Fortineti kriitilisest turvanõrkusesest Fortigate’i SSL-VPN seadmetes. Kuigi Fortinet paikas kriitilise turvavea (CVE-2023-27997) juba ligi kuu aega tagasi, on endiselt sajad tuhanded FortiGate’i tulemüürid paikamata ja seetõttu haavatavad FortiOS tarkvaras olevale nõrkusele. Tegemist on veaga, mis on hinnatud kriitilise skooriga 9.8/10. Küberturvalisusega tegelev ettevõte Bishop Fox tegi Shodani päringu, mille tulemusel selgus et 69% internetis avalikult leitavatest FortiGate’i seadmetest on endiselt paikamata. Lisaks selgus, et paljude internetis avalikult leitavate Fortineti seadmete tarkvara ei ole juba 8 aastat uuendatud. Ettevõtte sõnul võib olla turvanõrkust rünnetes ära kasutatud ja seetõttu on eriti oluline tarkvara uuendada esimesel võimalusel.

Fortineti seadmed on maailmas väga laialdaselt kasutusel nii eraettevõtetes kui ka riigiasutustes ning seetõttu on need ka häkkeritele meeldivad sihtmärgid. Viimaste aastate jooksul on mitmed ründed toimunud Fortineti haavatavuste kuritarvitamisel. Näiteks selle aasta veebruaris rünnati erinevaid süsteeme kasutades FortiNACi kriitilist turvanõrkust, mis võimaldas ründajal paigaldada ohvri serverisse veebikest ja saada ligipääs kompromiteeritud süsteemidele (BC, HN, arstechnica).

Kes ja mida peaks tegema?

Kõigil Fortigate’i SSL-VPNi seadmete kasutajatel tuleks FortiOSi tarkvara uuendada. Turvaviga on parandatud FortiOSi versioonides 6.0.17, 6.2.15, 6.4.13, 7.0.12 ja 7.2.5.


Mozilla paikas Firefoxi veebilehitsejas mitu turvaviga

Mozilla Firefox versioonis 115 on parandatud neli kõrge ja seitse keskmise mõjuga turvaviga. Haavatavused võivad muuhulgas kaasa tuua mälupesa sisu soovimatu muutmise ja pahatahtliku koodi käivitamise (IM, Mozilla).

Kes ja mida peaks tegema?

Mozilla soovitab kõigil kasutajatel teha veebilehitseja tarkvarauuendus ja uuendada see kõige viimasele versioonile.

Google paikas 46 turvanõrkust Androidi operatsioonisüsteemis

Androidi nutiseadmetes paigati 46 turvaviga, millest kolme (CVE-2023-26083, CVE-2021-29256 ja CVE-2023-2136) on ettevõtte sõnul juba rünnetes ära kasutatud. Kõige suurema mõjuga parandatud vigadest on kriitiline haavatavus tähisega CVE-2023-21250, mis mõjutab Androidi versioone 11, 12 ja 13. Haavatavus võimaldab ründajal pahatahtlikku koodi kaugkäivitada nii, et seadme kasutaja ei pea enda poolt midagi tegema (BC, MB, Android).

Kes ja mida peaks tegema?

Soovitame Android nutiseadmete tarkvara uuendada esimesel võimalusel. Enamusel seadmetel tuleb selleks valida „About phone“ või „About device“ ning seejärel „Software updates“. Tarkvara on võimalik uuendada neil, kes kasutavad Androidi versioone 10, 11, 12, 12L and 13.

Cisco hoiatas Nexus 9000 seeria seadmetes oleva turvanõrkuse eest

Cisco Nexus 9000 seeria kommutaatorites (swtitch) avastati kõrge mõjuga turvaviga CVE-2023-20185, mis võimaldab autentimata ründajal lugeda või muuta krüpteeritud liiklust. Viga on hinnatud CVSS skooriga 7.4/10. Haavatavus mõjutab kommutaatorite mudeleid Nexus 9332C, Nexus 9364C ja Nexus 9500. Hetkel teadaolevalt ei ole haavatavust rünnete läbiviimisel ära kasutatud (BC, SA, Cisco).

Kes ja mida peaks tegema?

Hetkel veale parandust ei ole ja Cisco sõnul ei ole ka tulevikus plaanis seda viga

parandada. Ettevõte soovitab mõjutatud seadmete kasutajatel  välja lülitada

Cisco ACI Multi-Site CloudSec krüpteerimise funktsioon.

MOVEit Transfer kutsub oma kliente tarkvara uuendama

Juunis kirjutasime mitmel korral MOVEit failiedastustarkvaras olevatest turvanõrkustest. Nüüd on taas tarkvaras paigatud üks kriitilise ja kaks kõrge mõjuga turvaviga. Kriitiline haavatavus (CVE-2023-36934) võimaldab teostada autentimata ründajal SQL-süsti. Kõrge mõjuga turvavea (CVE-2023-36932) kaudu on samuti võimalik teostada SQL-süsti, kuid eelnevalt on vaja autentida. Kolmas parandatud viga (CVE-2023-36933) aga võimaldab ründajal programmi töö ootamatult lõpetada (BC, HN).

Kes ja mida peaks tegema?

Turvavead on kõrvaldatud MOVEit Transferi versioonides 2023.0.4 (15.0.4), 2022.1.8 (14.1.8), 2022.0.7 (14.0.7), 2021.1.7 (13.1.7) ja 2021.0.9 (13.0.9). Soovitame tarkvara uuendada esimesel võimalusel ja tutvuda ka tootja poolt avalikustatud informatsiooniga nende kodulehel.

Riigivõrgu seade, mille küljes on hulga seadmeid.

Ülevaade Eesti juur DNS serveritest ning .com ja .net koopiatest

Domeeninimede süsteem ehk DNS ulatab arvutikasutajatele abikäe. Tänu DNS serveritele ei pea inimesed pähe tuupima pikki IP-aadresse: RIA kodulehe külastamiseks ei pea kirjutama aadressi reale 141.101.90.17, vaid piisab, kui trükkida ria.ee. Numbrilised IP-aadressid on hea viis, kuidas masinad, arvutid ja muud seadmed omavahel suhtlevad. Kasutajal on palju raskem seesuguseid jadasid meelde jätta. Kui on soov Google’i esilehele jõuda, siis kirjutatakse „google.com“, mitte 2607:f8b0:4004:c06:0:0:0:69. DNS server on arvuti, mis suudab kokku viia masinatele meelt mööda IP-aadressi ja inimmõistusele lihtsama veebilehe aadressi.

Millised nimeserverid töötavad Eestis? Eesti on kasutusel D, E, F, I, J ja K root DNS serverid, lisaks ka .com ja .net domeenide koopiat hoidev b.gtld-servers.net. Loetletud nimeserveritest kõige värskem on kuu alguses lisandunud J root DNS ning Eesti esimesed .com ja .net koopiad.

Sideteenuse pakkujatele on need interneti alustaristut kindlustavad teenused kättesaadavad läbi Eesti internetisõlmpunkti RTIX-i. Riigi Infosüsteemi Ameti pakutav RTIX on riigi hallatav dubleeriv interneti sõlmpunkt, mis ühendab Eesti internetivõrgud. Selle eesmärk on tagada võrkude omavaheline liiklus ka siis, kui ühendus välisriikidega on mingil põhjusel häiritud. Samuti on RTIX vahendusel otse kättesaadavad kõik .ee tsooni koopiad. Lisandunud hüvedest saavad automaatselt osa sideteenuse pakkujad, kes on liitunud RTIX-ga ning kasutavad RTIX route servereid. 

Miks on oluline, et root DNS või .com ja .net asuvad sulle lähedal?

Root DNSi toimimine on ühtlasi ka interneti toimimise alustala, sest just see teenus hoiab nimekirja, kus asuvad erinevate üladomeenide tsoonide nimeserverid. Näiteks teab root DNS, et .ee nimede kohta tasub küsida .ee tsooni autoriteetsest viiest nimeserverist koos vastavate IP aadressidega: b.tld.ee, e.tld.ee, ee.aso.ee, ee.eenet.ee ja ns.tld.ee.

Mida lähemal on root DNS sinu nimesid lahendavale DNSile, seda kiiremini tuleb ka vastus ehk domeeninimi (www.ria.ee) teisendatakse IP-aadressiks või vastupidi. Selle tulemusena teab sinu arvuti rutem, kus teenus asub, ühendub sinna ning sulle avaneb teenus. Kuid lisaks kiirusele on veelgi olulisem nimede lahendamise tõepärasus. Mida lähemal asub vastus, seda väiksem on võimalus teekonnal vastust mõjutada ning seeläbi sinu internetiliiklust valesti suunata. See ei ole ainult mugavuse, vaid ka turvalisuse küsimus.

Domeenidest on .com ja .net kõige kasutatavamad domeenid ning selle teenuse olemasolu Eestis vähendab ründepinda kõige laiemalt. See ei ole üksnes teoreetiline oht. Siit saate lugeda hiljutist analüüsi, mis kirjeldab, kuidas Mehhiko WhatsAppi kasutajate päringuid manipuleeriti.

https://labs.ripe.net/author/qasim-lone/detecting-dns-root-manipulation/

Miks on oluline, et sinu nimesid lahendav DNS asub sulle lähedal?

Niisiis, nimesid lahendava DNSi jaoks on tähtis, et tema jaoks autoriteetsed allikad asuvad talle lähedal, et kiirendada nimelahendusi ja vähendada nimelahendustega manipuleerimist. Sama oluline on vahemaa, mis lahutab sind ja nimesid lahendavat DNSi.

Mida kaugemal asub sinu jaoks nimesid lahendav server, seda aeglasemalt tulevad vastused ja seda suurem on võimalus pahatahtlikult teenuse pakkuja nimel valesti vastata. Seeläbi on lihtsam suunata liiklust kuhugi, kuhu ta minema ei peaks. Tasub märkimist, et DNS nimelahenduse turvalisust tagav protokoll DNSSEC ei ole selle ründe objektiks, kuna valideerimine leiab aset, siis toimub nimelahendaja teenuse juures. See aga tähendab, et teekond nimelahendaja juurest sinuni on endiselt haavatav. Sellepärast tuleks eelistada neid nimesid lahendavaid teenuseid, mis asuvad sulle võimalikult lähedal või krüpteerida vastavad päringud.

CERT-EE pakub avalikku nimede lahendamise teenust, mis järgib nimede lahendamisel eri turva- ja privaatsusstandardeid. See teenus ei lahenda neid nimesid, mille taga asuvad õngitsus- või pahavara sisaldavad lehed.  CERT-EE teenust saab kasutadakrüpteeritult toetades nii DNS over HTTPS kui ka DNS over TLS protokolle. Globaalsetest teenusepakkujatest on Eesti internetisõlmpunktis RTIX olemas nii Cloudflare 1.1.1.1 kui ka Quad9 9.9.9.9. 

Hiljutine näide juhtumist Eestis, kus suure teenusepakkuja teenuse nimel vastati klientidele valesti. Nimetatud juhtum mõjutas suurt hulka nimelahendusi.

Mida pean tegema, et nimelahendused oleks võimalikult turvalised?

Kasutades CERT-EE nimeservereid ei ole vaja teha midagi, sest siis kasutad Eesti interneti sõlmpunkti RTIX teenust täiel määral. Ka RIA riigivõrgu kliendid ei pea tegema midagi, sest neile on teenusepakkuja poolt tagatud RTIXi teenuste hüved.

Kui sa ei kasuta CERT-EE nimeservereid ega ole riigivõrgu klient, siis küsi oma sideteenuse ja DNS teenuse pakkuja käest, kas ta on RTIX-il kohal ning kasutab RTIX-i route servereid. Ilma eelnevata ei ole võimalik operatiivselt osa saada hüvedest, mida Eesti internetiteenuse sõlmpunkt RTIX pakub.

RIA küberintsidentide käsitlemise osakond (CERT-EE)

OpenSSLi logo ühes tekstiga "Turvanõrkus OpenSSL teegis".

Olulised turvanõrkused OpenSSLi teegis

Taust

1. novembril avalikustasid OpenSSLi arendajad enda teegist versiooni 3.0.7, millega parandati kaks kõrge tasemega turvanõrkust (CVE-2022-3602 ja CVE-2022-3786). Algselt hinnati esimest nõrkust kriitiliseks, kuid OpenSSLi loojad alandasid kriitilisuse taset pärast arutelusid eri osapooltega[1].

OpenSSL on avaliku lähtekoodiga tarkvara, mida kasutatakse laialdaselt muuhulgas võrguliikluse krüpteerimiseks (sealhulgas VPNi lahenduste või HTTPSi protokolli puhul). OpenSSLi arendajad on varem hinnanud vaid üht nõrkust kriitilise tasemega (HeartBleed-nimeline haavatavus 2014. aastal). Tol korral oli ründajatel võimalik nõrkuse abiga varastada sessiooniküpsiseid, paroole ja muud tundlikku informatsiooni.

Mõju Eestis

Kogu maailmas ja ka Eestis on OpenSSLi kasutamine laialt levinud, kuid on keeruline hinnata, kui ulatuslikult kasutatakse Eestis teegi haavatavaid versioone (3.0.0–3.0.6).

Riigi Infosüsteemi Ameti CERT-EE osakonnale ei ole seni teada ühtegi juhtumit, kus haavatavust oleks suudetud ära kasutada. Arendaja kirjutas eilses blogipostituses, et neile ei ole samuti teada ainsatki sellist juhtumit1. Samas on nõrkused väga uued ja informatsiooni aina laekub. Internetist leiab juba esimesi CVE-2022-3602 nõrkuse kontseptsiooni tõendusi (POC).

Ärakasutamiseks on siiski vaja täita teatud eeltingimused (käsitleme neid allpool) ja nõrkuseid ei ole üleüldiselt lihtne kuritarvitada. Lisaks rõhutatakse, et maailmas kasutatakse hetkel rohkem OpenSSLi 1.x versioone kui 3.x.x versioone (Graafik 1).

Graafik 1: OpenSSLi versioonide kasutamise osakaalud pilveteenuste klientide näitel. Allikas: Wiz.io

Millised rakendused on haavatavad?

Haavatavad on kõik rakendused, mis kasutavad OpenSSLi versiooni 3.0.0–3.0.6. Haavatavad ei ole lahendused, mis kasutavad OpenSSLi 1.x.x versioone.

Nimekiri mõjutatud toodetest

Hollandi riiklik küberturvalisuse keskus (NCSC-NL) haldab koostöös partneritega GitHubi repositooriumi, kus on välja toodud nimekiri nõrkuse poolt mõjutatud tarkvaradest. Soovitame IT-ekspertidel ja CISOdel seda veebilehte jälgida.

Selle GitHubi põhjal ei saa teha siiski vettpidavaid järeldusi, et teised süsteemid ja tarkvarad ei ole haavatavad, sest organisatsioonid võivad kasutada lahendusi, mida ei ole nimekirjas välja toodud. Kõik oleneb sellest, kas kasutatakse teegi 3.x versioone või mitte.

Turvanõrkuste olemus

Haavatavused on seotud X.509 sertifikaatide verfitseerimisfunktsiooniga ning nõrkuste abil saab teostada puhvri üle täitumist (buffer overflow). Ründajad saavad nii põhjustada teenusekatkestusi. CVE-2022-3602 puhul on kirjutatud ka võimalusest käivitada pahaloomulist koodi, kuid see järeldus on hetkel teoreetilisel tasemel.

Eduka ärakasutamise jaoks on ründajal vaja, et vähemalt üks järgnevatest tingimustest on täidetud:

  • Pahaloomulise sertifikaadi olemasolu, mille on allkirjastanud usaldusväärne sertifitseerimiskeskus (Certificate Authority).
  • Süsteem, mis kontrollib pahaloomulist sertifikaati, ei valideeri ülemsertifikaate (parent certificates)

Pikem tehniline analüüs CVE-2022-3602 nõrkuse kohta on siin: https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/#vulnerability-description

Soovitused infoturbejuhtidele

1. Tuvasta, kas teie ettevõtte süsteemid on haavatavad siin kajastatud turvanõrkuste vastu. Kasulik on koostada nimekiri haavatavatest tarkvaradest ja plaan, millal ja kuidas mõjutatud komponendid paigata. Samuti tuleks veenduda, et ettevõtte partnerid, kellel on ligipääs teie süsteemidele, ei ole haavatavad nende turvanõrkuste vastu. Halbade asjaolude kokkulangemisel võib partneri süsteem mõjutada ka teie süsteemi.

2. Uuenda haavatavaid OpenSSLi versioone kasutavad rakendused esimesel võimalusel nii, et need kasutaksid vähemalt teegi versiooni 3.0.7. Kui uuendamine ei ole võimalik, soovitab arendaja ühe lahendusena TLS-serverite haldajatele keelata võimalusel TLS-kliendi autentimine seniks, kuni uuendused on rakendatud1.

3. Vaata üle, kas mõjutatud on teenused, mis on interneti kaudu ligipääsetavad. Kui jah, tuleks infoturbejuhtidel või süsteemihalduritel vajadusel hinnata, kas on võimalik ajutise meetmena (kuni paigatud versiooni või alternatiivsete lahenduste rakendamiseni) ligipääsu neile teenustele piirata (need internetist eemaldada, kui kübeintsidendi toimumise risk on suur).

4. Kui te ei ole seda veel teinud, soovitame liituda CERT-EE igahommikuse uudiskirjaga, mis toob teieni kõik olulisemad turvanõrkustega seotud uudised. Juhendi, kuidas uudiskirjaga liituda, leiate siit: https://www.ria.ee/et/kuberturvalisus/cert-ee.html. Samuti kajastame iganädalaselt olulisemaid turvanõrkustega seotud uudiseid RIA blogis.

[1] https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/