Avastati kriitiline turvanõrkus Confluence’i tarkvaras

Uuendatud 6. juunil kell 12

Nimetus: CVE-2022-26134

Taust

2. juunil avalikustas Atlassian Confluence’i tarkvara mõjutava kriitilise nullpäeva turvanõrkuse CVE-2022-26134 , mille abil saab autentimata kasutaja haavatavas süsteemis teostada koodi kaugkäitust. Turvanõrkuse avastas üks küberturbeettevõte, kes analüüsis parasjagu kliendi küberintsidenti ja leidis, et selle käigus oli kasutatud just seda seniteadmata haavatavust[1]. Ettevõtte sõnul kasutavad tõenäoliselt mitmed Hiinaga seostatavad küberühmitused hetkel aktiivselt seda turvanõrkust haavatavate süsteemide ründamiseks. Need rühmitused ei ole ainsad, kes on üritanud haavatavust kuritarvitada, vaid haavatavate süsteemide kaardistamisega tegelevad ka paljud teised pahatahtlikud osapooled[2].

Võimalik mõju ja haavatavad süsteemid

Turvanõrkus võimaldab süsteemi paigaldada autentimata kasutajal näiteks veebikesta, mille abil saab anda täiendavaid pahaloomulisi käske. Käskude abil on potentsiaalselt võimalik varastada kompromiteeritud süsteemides leiduvaid andmeid, paigaldada täiendavat pahavara, liikuda lateraalselt edasi või krüpteerida haavatavad süsteemid sootuks.

Kui 03.06.2022 kella 16:00 seisuga ei olnud turvanõrkuse kontseptsiooni tõendus (POC) veel avalikult kättesaadav, siis õige pea avalikustati ka see[3]. Seetõttu on väga oluline, et mõjutatud süsteemide haldajad võtaksid arvesse järgnevas peatükis välja toodud vastumeetmeid ja soovitusi. Tootja on juba jõudnud väljastada ka osadele tarkvaraversioonidele turvapaigad, samuti ka info ajutiste vastumeetmete kohta, kui turvapaikade rakendamine ei ole kohe võimalik. Täpsemat informatsiooni leiate tootja ametlikult kodulehelt.

Haavatavad on Confluence Serveri ja Data Centeri kõik versioonid, mis on uuemad kui 1.3.0[4]. Tootja on seisuga 06.06.2022 09:30 väljastanud turvapaigad versioonidele 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 ja 7.18.1. Mõjutatud ei ole Atlassian Cloudi kasutavad Confluence’i lehed.

Võimalikud vastumeetmed ja soovitused

  1. Rakendada turvapaik, kui see on kättesaadav. Täpsema informatsiooni leiate tootja kodulehelt.
  2. Kõikidele Confluence Server ja Data Center süsteemidele tuleks piirata internetist ligipääs, näiteks ACL reeglitega.
  3. Kui ligipääsu piiramine ei ole võimalik, tuleks Confluence Serveri ja Data Centeri süsteemide kasutamine ajutiselt peatada ning oodata seni, kuni tootja väljastab turvapaiga ja see rakendada.
  4. Soovitame enda veebirakenduse tulemüüri pakkujalt uurida, milliseid kaitsemeetmeid Confluence’i vastu suunatud rünnete kohta pakutakse. Kui te ei ole veebirakenduse tulemüüri kasutusele võtnud, soovitame seda teha.
  5. Tootja hinnangul võib ohtu vähendada ka spetsiaalse reegli rakendamine veebirakenduse tulemüüris, mis blokeerib kõik URLid, mis sisaldavad ${.
  6. Veenduge, et rakendatud oleks süsteemide logimine ja võimalus logisid ka võimaliku intsidendi korral kätte saada ja analüüsida. Võimalusel tuleks logide varundusi hoida eraldatud süsteemis.
  7. Soovitame tutvuda järgneva intsidendi analüüsiga siin ning uurida, kas märkate logidest artiklis välja toodud IOC-sid. Samuti on artiklis välja toodud Yara reeglid, mis aitavad tuvastada süsteemidest veebikestade olemasolu, mida selle konkreetse intsidendi jooksul kasutati.
  8. Haavatavate süsteemide kompromiteerumise kahtluse korral palume teavitada CERT-EE-d, kirjutades meiliaadressile cert@cert.ee
  9. Kuna turvanõrkuse kohta tuleb informatsiooni jooksvalt juurde, soovitame jälgida CERT-EE igahommikust uudiskirja, mis kajastab kõige olulisemaid kübermaailmaga seotud uudiseid. Kui te ei ole sellega veel liitunud, siis leiate liitumiseks vajaliku informatsiooni siit. Samuti soovitame aeg-ajalt uurida tootja ametlikku lehte siin.

[1] https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/

[2] https://blog.cloudflare.com/cloudflare-observations-of-confluence-zero-day-cve-2022-26134/

[3] https://www.bleepingcomputer.com/news/security/exploit-released-for-atlassian-confluence-rce-bug-patch-now/

[4] https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html

3. juuni 2022 kella 16 seisuga ei ole turvanõrkuse kontseptsiooni tõendus (POC) veel avalikult kättesaadav. See vähendab küll veel hetkel haavatavuse laialdast kasutamist, kuid suure tõenäosusega avaldatakse kontseptsiooni tõendus ka lähiajal. Juhime samuti tähelepanu sellele, et selleks ajaks ei olnud tootja väljastanud turvapaika haavatavuse parandamiseks. Seetõttu on tähtis, et mõjutatud süsteemide haldajad võtaksid arvesse järgnevas peatükis välja toodud vastumeetmeid ja soovitusi.

Haavatav on Confluence Server versioon 7.18.0 ning Confluence Data Centeri versioonid 7.4.0 või uuemad[2]. Mõjutatud ei ole Atlassian Cloudi kasutavad Confluence’i lehed [3].

Võimalikud vastumeetmed ja soovitused

  1. Kõikidele Confluence Server ja Data Center süsteemidele tuleb piirata internetist ligipääs, näiteks ACL reeglitega.
  2. Kui ligipääsu piiramine ei ole võimalik, tuleks Confluence Serveri ja Data Centeri süsteemide kasutamine ajutiselt peatada ning oodata seni, kuni tootja väljastab turvapaiga ja see rakendada.
  3. Kui kahte eelnevat soovitust ei ole võimalik järgida, siis võib tootja hinnangul ohtu vähendada ka spetsiaalse reegli rakendamine veebirakenduse tulemüüris, mis blokeerib kõik URLid, mis sisaldavad ${.
  4. Veenduge, et rakendatud oleks süsteemide logimine ja võimalus logisid ka võimaliku intsidendi korral kätte saada ja analüüsida. Võimalusel tuleks logide varundusi hoida eraldatud süsteemis.
  5. Kui tootja on turvapaiga kättesaadavaks teinud, tuleks see kohe rakendada.
  6. Soovitame tutvuda järgneva intsidendi analüüsiga siin ning uurida, kas märkate logidest artiklis välja toodud IOC-sid. Samuti on artiklis välja toodud Yara reeglid, mis aitavad tuvastada süsteemidest veebikestade olemasolu, mida selle konkreetse intsidendi jooksul kasutati.
  7. Haavatavate süsteemide kompromiteerumise kahtluse korral palume teavitada CERT-EE-d, kirjutades meiliaadressile cert@cert.ee
  8. Kuna turvanõrkuse kohta tuleb informatsiooni jooksvalt juurde, soovitame jälgida CERT-EE igahommikust uudiskirja, mis kajastab kõige olulisemaid kübermaailmaga seotud uudiseid. Kui te ei ole sellega veel liitunud, siis leiate liitumiseks vajaliku informatsiooni siit. Samuti soovitame aktiivselt jälgida jooksvalt uuendatavat blogi siin ning tootja ametlikku lehte siin.

[1] https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/

[2] https://blog.cloudflare.com/cloudflare-customers-are-protected-from-the-atlassian-confluence-cve-2022-26134/

[3] https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html

Tarneahelaründed: võimalik mõju ja kuidas end kaitsta

Kõige suurema majandusliku mõjuga NotPetya-nimeline rünne teostati 2017. aastal, mille põhjustas kompromiteeritud raamatupidamistarkvara. Petya lunavaraga nakatunud ostukeskus Kharkyvis.

Taust

Viimastel aastatel on üha enam toimunud tarneahelaründeid, mille tagajärjel saadakse sihtmärkide võrkudele ja infosüsteemidele ligipääs ühise IT-teenusepakkuja kaudu. Oletame, et sama IT-teenusepakkuja tarkvara kasutavad nii advokaadibüroo, toidukaupluste kett kui ka ehitusettevõte. Selle asemel, et neid ettevõtteid eraldi rünnata, võib olla lihtsam kompromiteerida see tarkvara, mida nad kõik kasutavad ning selle kaudu organisatsioonide süsteemidele korraga ligi pääseda. Tarneahelaründed võivad avaldada mõju nii süsteemide käideldavusele, terviklikkusele kui ka konfidentsiaalsusele ja toovad sageli kaasa nii finants- kui ka mainekahju. Kasutades kolmanda osapoole tarkvara või riistvara, tuleb paratamatult arvestada tarneahela turvalisuse riskidega.

Lähiminevikus on toimunud mitmeid kaalukaid tarneahelarünnakuid. Kõige suurema majandusliku mõjuga NotPetya-nimeline rünne teostati 2017. aastal, mille põhjustas kompromiteeritud raamatupidamistarkvara. Rünnak oli esialgu suunatud Ukraina vastu, kuid levis kiiresti üle kogu maailma. Ründe taga oli Venemaa Föderatsiooni välissõjaväeluure küberrühmitus ning see tekitas kokku 10 miljardi USA dollari ulatuses kahju. Suurfirmadest olid ründest mõjutatud teiste seas Taani laevanduskompanii Maersk, USA farmaatsiafirma Merck, Saksa logistikaettevõte DHL ja Prantsuse ehitusettevõte Saint-Gobain.

2020. aasta detsembris sooritati ülemaailmse mõjuga tarneahelarünnak USA ettevõtte Solarwindsi Orion-nimelise tarkvara[1] vastu. Rünnakut on nimetatud ka IT-maailma Pearl Harboriks. Pahavara levitati tarkvarauuenduse kaudu, mille tuhanded Orioni kasutajad pahaaimamatult endale alla laadisid. Rünnak mõjutas kuni 18 000 sihtmärgi IT-taristut. Nende sihtmärkide hulka kuulusid ka USA valitsusasutused (Pentagon, sisejulgeolekuministeerium, välisministeerium, energeetikaministeerium ja rahandusministeerium) ning suurettevõtted nagu MicrosoftIntel ning Cisco. Rünnaku taga oli Venemaa Föderatsiooni välisluurega seotud küberrühmitus.

2021. aasta juulis tehti tarkvarafirma Kaseya vastu lunavararünnak, mida seostatakse Venemaal tegutseva küberrühmitusega REvil. See mõjutas ligi 1500 ettevõtet 17 riigist, mis kasutasid Kaseya pilvepõhist lahendust IT-süsteemide kaughalduseks. Rünnaku üheks ohvriks oli näiteks ka COOPi kauplusekett Rootsis, mis pidi sulgema ligi 500 poodi, sest nende arveldussüsteemid ei töötanud [2].

Euroopa küberagentuuri ENISA analüüsi[3] kohaselt avastati 2020. aasta jaanuarist kuni 2021. aasta juulini 24 tarneahelarünnakut. 50% juhtudest olid rünnakute taga riiklikud küberrühmitused. Tõenäoliselt on tarneahelarünnete arv tõusuteel, sest nende potentsiaalne mõjuulatus on tihti lai, muutes ründevektori ärakasutamise pahalastele ahvatlevaks.

Tarneahela turvalisuse teema olulisust kirjeldab ka tõik, et selle jaoks on loodud Euroopa Komisjonis vastav töögrupp, kus osalevad paljud liikmesriigid, nende hulgas ka Eesti. Rahvusvahelisel tasandil on samuti loodud mitmeid tarneahela turvalisusega seotud dokumente, näiteks eelpool viidatud ENISA raport ja USA riikliku standardite ja tehnoloogia instituudi NIST (National Institute of Standards and Technology) ning USA valitsuse küber- ja teabetaristu turvalisuse agentuuri CISA (Cybersecurity and Infrastructure Security Agency) koostöös valminud dokument.

Millised on erinevad viisid tarneahelarünnakute läbiviimiseks?

  • Kesksete tarkvarauuenduste kaudu süsteemide kompromiteerimine. Paljude seadmete ja tarkvarade tootjad pakuvad oma klientidele võimalust uuendada tooteid automaatselt. Sageli pakutakse uuendusi läbi kesksete serverite. Kui ründajal õnnestub kompromiteerida süsteem, mis uuenduste jagamisega tegeleb, annab see talle võimaluse manipuleerida klientidele jagatavate uuendustega ja seeläbi kompromiteerida ka klientide süsteemid. Sellist ründetüüpi kasutati NotPetyarünnakus 2017. aastal. 
  • Tarkvarakoodi usaldusväärsuse ja terviklikkuse kinnitamiseks mõeldud sertifikaatide kuritarvitamine. Legitiimsete programmide terviklikkuse ja usaldusväärsuse tõestamiseks mõeldud sertifikaatide varastamise korral on ründajal võimalik jätta mulje, et pahavara näol on tegu usaldusväärse programmiga. 2022. aasta märtsis tabas videokaartide tootjat NVIDIA küberrünnak, mille tagajärjel õnnestus kurjategijatel varastada ka kaks ettevõtte programmide usaldusväärsuse ja terviklikkuse kinnitamiseks kasutatud sertifikaati.[4] Selle abil on võimalik pahalasel jätta ohvri Windowsi operatsioonisüsteemile mulje, et pahavara näol on tegu NVIDIA draiveritega ning seeläbi lihtsamalt ohvrite masinates seda käivitada[5].  
  • Avaliku lähtekoodihoidla kompromiteerimine. Repositoorium ehk hoidla on keskkond, mille kaudu on võimalik näiteks koodimuudatusi ülesse või alla laadida. Ründajal on võimalik lähtekoodihoidla kompromiteerida ja sinna lisada pahaloomuline koodijupp. Kõik, kes selle muudetud koodiga tarkvara endale alla laevad, võivad nakatuda pahavaraga. Ründajaks võib olla nii pahaloomuliste kavatsustega tarkvaraarendaja kui ka kolmas osapool, kes on saanud pearepositooriumile ligipääsu. Näiteks 2020. aastal avastas GitHubi turvatiim, et GitHubi kasutavad 26 avatud lähtekoodiga tarkvaraprojekti olid kompromiteeritud. Projektide koodid sisaldasid Octopus Scanneri nimelist pahavara, mis võimaldas ründajatel tarkvara allalaadijate süsteemi paigutada tagaukse[6].
  • Pahaloomulise komponendi lisamine riistvarale. Lisaks tarkvaraga seotud tarneahelarünnakutele oleks teoorias võimalik sooritada rünne ka riistvara abil. Kuigi selle kohta puuduvad hetkel ametlikult kinnitatud elulised näited, on mitmed uurijad leidnud, et pahaloomulise mooduli lisamine riistvara komponendile rünnaku läbiviimiseks on teostatav. Näiteks õnnestus ühel Rootsi uurijal edukalt ühildada pahaloomuline mikrokiip ühe võrguseadme emaplaadiga, mille abil oli tal võimalik luua seadme süsteemi uus kõrgendatud õigustega kasutaja [7]. Mikrokiibiga pääses ta ligi võrguseadme konfiguratsiooniseadetele, mille abil oleks tal olnud võimalik tekitada seadmele kaugligipääs, eemaldada seadme turvameetmed või uurida seadmega seotud logisid.

Mõju Eestis

Eesti organisatsioonid ei ole jäänud tarneahelarünnakutest puutumata, kuid seni on rünnakute mõju ulatus olnud siiski suhteliselt väike. 

2017. aastal jõudis NotPetya rünnaku mõju Eesti ettevõteteni, kuna Prantsuse tööstusgruppi Saint-Gobaini kuulusid mitu Eesti ettevõtet. Ehituse ABC sulges oma kauplused rünnaku tõttu umbes nädalaks. Lisaks olid mõjutatud ka klaasitootja GLASSOLUTIONS Baltiklaas ning uuringufirma Kantar Emor [8]. Klaasitootja kuulub samuti Saint-Gobaini gruppi ning tehase arvuteid ei olnud võimalik ründe tagajärjel kasutada. Kantar Emor sulges enda arvutisüsteemid ennetavalt, kuid teadaolevalt nende süsteeme ei krüpteeritud [9].

Venemaa agressiooni tõttu Ukrainas on küberrünnakute ja sealhulgas ka tarneahelarünnakute oht Eestis tavapärasest suurem. Esiteks tõdeti aprillis avaldatud Microsofti raportis, et juba 2021. aasta keskpaigaks olid võtnud Venemaaga seotud küberrühmitused sihikule teenusepakkujad Ukrainas ja mujal maailmas, et tagada edasine juurdepääs mitte ainult Ukraina IT-süsteemidele, vaid ka NATO liikmesriikide süsteemidele laiemalt [10]. Rünnak Viasati KA-SAT võrgusüsteemi pihta 24. veebruaril mõjutas kümnete tuhandete ettevõtte klientide internetiühendust nii Ukrainas kui ka mujal Euroopas[11].  

Teiseks kasutatakse väliseid teenusepakkujaid nii Eestis kui ka mujal maailmas üha rohkem, sest see on kuluefektiivsem. Seega ei sõltu Eesti organisatsioonide küberturvalisus paraku ainult nende enda süsteemidest vaid ka välistest teenusepakkujatest. Üheks tarneahelarünnakute potentsiaalse kasvu võimalikuks põhjuseks on ka asjaolu, et sihtmärkideks valitud organisatsioonide infosüsteemide turvameetmed on liiga heal tasemel ja neid on keeruline otse rünnata. Seega analüüsitakse ründe planeerimisel väliseid teenusepakkujaid, kelle süsteemide kaudu õnnestuks seatud pahaloomulised eesmärgid saavutada. 

Kolmandaks on potentsiaalselt võimalik saavutada tarneahelarünnakuga palju suuremat mõju võrreldes sellega, kui rünnata sihtmärki otse. Näiteks oleks võimalik tarneahelarünnakuga krüpteerida lisaks teenusepakkuja süsteemidele ka klientide süsteemid. See tekitab ründajale palju laiaulatuslikuma mõjupositsiooni, mida tihti sihtmärkide survestamiseks saab ära kasutada.  See tähendab seda, et kui ründaja näiteks ohvriga läbirääkimisi peab, siis saab ta viidata, et on krüpteerinud ka mitmete teenusepakkuja klientide süsteemid ning seeläbi mõjutada teenusepakkujat lunaraha maksma. 

Nõuanded

  1. Soovitame organisatsioonidel läbi mõelda, kuidas hallata logisid ja monitoorida oma võrke nii, et sissemurdmise ja muu pahaloomulise tegevuse puhul jääks sellest märk maha. Erinevaid ründeid on keeruline uurida, kui puuduvad logid ja tõestusmaterjal. Logisid soovitame minimaalselt säilitada vähemalt ühe aasta.
  2. Jagage erinevaid õiguseid ja ligipääse lähtuvalt vähima õiguse printsiibist. See tähendab, et tuleb kaardistada täpselt, millised õigused ja ligipääsud on kasutajale või programmile töö tegemiseks vajalikud ning anda õiguseid üksnes lähtuvalt sellest (mitte rohkem).
  3. Võrk tuleks segmenteerida. Erinevate eesmärkidega teenused ja seadmed peaksid asuma erinevates võrkudes või tsoonides ning nende ligipääsud üksteisele peavad olema piiratud, lähtudes vähima õiguse printsiibist. Soovitame lisainformatsiooni saamiseks tutvuda Eesti infoturbestandardi peatükiga “NET.1.1: Võrgu arhitektuur ja lahendus” siin.
  4. Võimalusel veenduge selles, et lepingupartnerite turvaauditid on tehtud ning nendes on kaetud organisatsiooni jaoks olulised valdkonnad. Selle tagamiseks tuleks võimalusel sõlmida leping, milles oleksid eelnimetatud punktid kajastatud. 
  5. Pöörake tähelepanu tarneahela turvalisusega seotud riskihaldusele: dokumenteerige teenusepakkujad ja määratlege, millised riskid võivad kaasneda kolmanda osapoole tarkvara või riistvara kasutamisega.
  6. Määrake toodete ja teenuste turbenõuded ning kajastage need kahepoolses lepingus. 
  7. Kontrollige, kas lepingus sätestatud küberturbenõuetest peetakse kinni ja tehke kindlaks, kuidas teenusepakkuja intsidente, haavatavusi, turvapaikasid ja turvanõudeid käsitleb.
  8. Riskide vähendamiseks soovitame tutvuda Eesti infoturbestandardi (E-ITS) riskihaldusjuhendiga (siin) kui ka standardi rakendamisega laiemalt.

[1] Orion on IT-taristu haldus- ja monitoorimistarkvara

[2] https://www.bbc.com/news/technology-57707530

[3] https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks

[4] https://cyware.com/news/nvidias-code-signing-certificates-stolen-and-abused-in-attacks-3cc710e1

[5] https://blog.malwarebytes.com/awareness/2022/03/stolen-nvidia-certificates-used-to-sign-malware-heres-what-to-do/

[6] https://www.techtarget.com/searchsecurity/news/252483808/Supply-chain-attack-hits-26-open-source-projects-on-GitHub

[7] https://www.wired.com/story/plant-spy-chips-hardware-supermicro-cheap-proof-of-concept/

[8] https://blog.ria.ee/petya-voi-notpetya/

[9] https://www.err.ee/604539/rahvusvahelise-kuberrunnaku-tottu-suleti-koik-ehituse-abc-poed

[10] https://blogs.microsoft.com/on-the-issues/2022/04/27/hybrid-war-ukraine-russia-cyberattacks/

[11] https://www.viasat.com/about/newsroom/blog/ka-sat-network-cyber-attack-overview/

CERT-EE: mida teha, kui sinu Facebooki konto on kaaperdatud?!

RIA intsidentide lahendamise osakond CERT-EE saab iga päev teateid kaaperdatud Facebooki kontodest, mille kaudu levitavad kurjategijad veebilinki. See link viib inimesed pahavaraga nakatunud veebilehele. Kurjategijad saadavad kaaperdatud konto kaudu sõnumeid nagu „Kas see oled sina selles videos?“ või „Kas oled näinud, mida sinust Facebookis kirjutatakse?”. Sarnane petuskeem kogub tuure ka Instagramis.

Pärast seda, kui ründajad saavad inimese sotsiaalmeediakonto enda kätte, vahetavad nad konto parooli, telefoninumbri ja e-posti aadressi. See aga muudab konto taastamise pea võimatuks.

Eriti tähelepanelikud peavad olema kasutajad, kelle sotsiaalmeediakonto on seotud pangakaardiga. Sellisel juhul tuleb teatada pangale ning esimesel võimalusel kaart sulgeda.

Selleks, et kaitsta enda seadmeid pahavara eest ning mitte langeda Facebooki konto varguse ohvriks, ei tohi neile kirjadele vastata ega avada neis sisalduvaid linke. Samuti tuleb kaaperdatud konto kohta raporteerida Facebookile ning kui endal ei ole seda võimalik teha, siis paluda selleks sõbra abi. Kaaperdatud konto sulgemine on vajalik selleks, et piirata pahavara levitamist ning konto jätkuvat ära kasutamist. 

Sarnane petuskeem kogub tuure ka Instagramis

Instagramis leviva skeemi keskseks ideeks on see, et inimene saab sõbralt teate, milles too on hädas ja küsib abi. Sõber saadab sõnumis lingi, millele ei pea isegi vajutama – lingist palutakse teha kuvatõmmis ehk screenshot ja lihtsalt sõbrale tagasi saata.

Selliselt käitudes kompromiteeritakse kasutaja Instagrami konto. Mitte mingil juhul ei tohi vajutada lingile ega kuvatõmmist tagasi saata. Pahatahtlik pool võtab sinu Instagrami konto üle ning hakkab jagama seal üsna tõetruu sisu, mis võib tuua kaasa isegi rahalisi kaotusi.

Oled siiski pahaaimamatult täitnud „sõbra“ palveid ja jäänud enda kontost ilma? RIA-le teadaoleva info põhjal on kompromiteeritud Instagrami konto tagasi saadud järgides juhendeid, mis on antud siin YouTube’i videos.

Sinu FB konto on kaaperdatud? Tee nii:

  1. Raporteeri juhtunust Facebooki. Selleks mine seadete all asuvasse abikeskusesse, kus on kirjeldatud täpsemad toimingud;
  2. Kui sul endal puudub Facebookile ligipääs, siis palu, et keegi sinu sõbralistis olevatest inimestest teavitaks ning paluks kaaperdatud konto sulgeda;
  3. Teavita enda konto kaaperdamisest ka oma sõbralistis olevaid inimesi või palu seda teha mõnel sõbral. Nii hoiad ära kaaperdamise järgmisi ohvreid!
  4. Kui sinu konto on seotud krediitkaardiga, siis teavita panka ning sulge kaart ehk vaheta see ümber:

Vajutasid kaaperdatud kontolt tulnud kirja lingile? Tee nii täpselt sellises järjekorras:

  1. Kontrolli, kas seadetes on kirjas endiselt õige telefoninumber (kui see oli eelnevalt sinna lisatud);
  2. kontrolli, kas Facebooki kontoga on endiselt seotud sinu e-posti aadress või on seda vahetatud; 
  3. vaheta parool; 
  4. aktiveeri kaheastmeline sisselogimine (Seadete alt rubriigis „Turvalisus ja sisselogimine“.)
  5. logi välja kõikidest seanssidest  (Facebooki menüüst “Seaded ja privaatsus” – “Seaded” – “Turvalisus ja sisselogimine” – “Kuhu sa sisse logitud oled” – “Logi kõikidest seanssidest välja”).
  6. logi uuesti Facebooki sisse.
  7. anna kahtlasest veebilingist teada raport.cert.ee keskkonna kaudu või kirjutades e-posti aadressile cert@cert.ee.

NB! RIA kodulehel on ka juhend, kuidas kompromiteeritud Facebooki kontole uuesti ligi pääseda (PDF), kui ülevõtja on ära muutnud meiliaadressi ja telefoninumbri. Juhendi leiab aadressila: https://www.ria.ee/sites/default/files/content-editors/kuberturve/fb_taastamise_juhend_22.03.2022.pdf.

NB! Kaitse enda seadmeid pahavara eest RIA väljatöötatud äpi abil! Loe lähemalt RIA veebilehelt aadressil: https://www.ria.ee/et/uudised/cert-ee-valjatootatud-app-kaitseb-ongitsuste-ja-pahavara-eest.html.