Kalastamine (phishing)
Selle nädalasel
teemaspektril olen ma kõige rohkem kokku puutunud kalastamisega (phishing). Nimelt
minu kokkupuude sai alguse mängust „Runescape“, kus on teatavasti ka reaalne turg
(„real world trading“) mängu valuuta üle „coins“ („gp“)
Kuid rääkides nüüd
kalastamisest endast, siis võtsin appi Cybernetica andmekaitse ja infoturbeleksikoni, mis on siis tõlkinud ISO/IEC 27032 järgi kalastamise definitsiooni.
Kalastamine on petturlik protsess, millega elektroonilises suhtluses usaldatavat olemit teeseldes püütakse saada privaatset või konfidentsiaalset teavet, suhtlusosavusega või tehnilise pettusega.[1]
Ehk kergelt öeldes on tegu teesklusega, eesmärgiga saada konfidentsiaalset või privaatset teavet.
Tavaliselt
antakse Ajakirjanduses sellele märksõnu nagu andmepüük, petukiri, õngituskiri
jne. Kuid ega kalastamine on meid saatnud terve globaalse Interneti tekke
algusest alates. Esmakordselt mainiti sõna „Phishing“ 1996. aastal ühes Useneti
grupis[2]. Kui 2000ndate alguses jõudsid veebi pangandus ja erinevad
maksesüsteemid, siis kalastamine hakkas aina hoogu koguma. Kuigi kalastamist
saaks veel oma korda liigitada mitmeti, siis siin postituses ma seda siiski
tegema ei hakkaks ja lihtsalt mainiks, et kõige enam levinum meetod on meililt
veebilehele suunamine, mida illustreerib ka all olev joonis.
Nüüd aga vaataks
veidikene statistikat ja uuriks, kui suur probleem see kalastamine ikkagi on.
Seega siin on järgnevalt joondiagramm, mis representeerib unikaalseid
kalastamise teateid Anti-Phishing Working Groupi (APWG) raportitest.
Selgelt on näha,
et 2013-2015 on toiminud suur tõus raporteerimistel või siis lihtsalt ongi
kalastamisi rohkem. Kuid pärast seda on asi jälle languses. Kas inimeste
koolitamine aadressiribalt HTTPS’i otsima ja kaheastmelist autentimist (2FA)
kasutama on kanda kinnitanud? Võib ka nii öelda. HTTPS’i teadvustamise mõju
võib selgelt lugeda siin üheks faktoriks, sest pärast 2015. aastast on HTTPS
kalastajate seas aina populaarsemaks muutunud.
Joondiagrammilt
on näha viimastel aastatel suurt õngitsuste langust, siis kindlasti võibki
pidada siin silmas „Mitnicki valmi“ koolituste osa. Inimesed ongi lihtsalt
rohkem teadlikumad ja enam nii kergelt lõksu ei lange. Me käitume veebis
teadlikumalt kui 10 aastat tagasi. Kuid siiski ei leidu päeva, mil ma ei leiaks Twitterist @leak_scavenger lekitatud paroole.
Miks ikkagi
langetakse lõksu?
Seda võib võtta
juba puhtalt inimeste psühholoogiast tulenevalt. Rutiinsetele tegevusetele ei pööragi
me suuremat tähelepanu, kuid kui teeksime investeerimisotsust, siis meie mõttetöö
nõuab rohkem pingutust ja on aeglasem. Sellisel juhul me kaalume otsust seni kuniks
see on meie jaoks leidnud loogilise lahenduse. Erinevad süsteemid aitavad meid,
kuid mitte alati. Meil on rutiiniks kujunenud HTTPS’i olemasolu vaatamine aadressiribal
Esimene näide:
Slack
Slack pakub
ettevõtetele virtuaalseid töökeskkondi.
Vaatame kahte
elektronkirja, millest üks on saadetud nende endi poolt ja teine on õngituskiri.
Leiame, et meiliaadressid
on samad ja tekstis kirjavead puuduvad. Ei olegi võimalik selle pildi põhjal
tegelikult teada saada, et kumb on õngitsus. Mida tegi Slack valesti? Slack ei rakendanud
DNS serveri kandeid (SPF, DMARC) enda domeenil. Seega said sisuliselt kõik
saata nende domeeni nimega kirju.
Järgmine näide:
Amazon Web Services
Sellel korral
vaatame veebilehti.
Näeme, et mõlemad kasutavad HTTPS’i. Mõlema aadressiriba lõpud on samuti samad, kuid vastus peitub aladomeenide süsteemis endas. Amazon on millegipärast kasutanud väga pikki domeene. Mainin ära, et ülemine näide “aws.amazon.com” lõpuline on õige veebileht ja “awssignin.com” on õngitus. Esmalt paistab silma erinevus pärast „us-east-1.“ aladomeeni „signin“ ja „console“. Peaks süttima punane tuluke, kuid tegelikult ei.
Need
kaks aadressiriba (tumedal taust) on tegelikult mõlemad Amazoni enda omad ja
siin me näeme nii kirjeid „console“, „signin“, „aws“. Inimene, kes selliste
süsteemidega igapäevaselt töötab ei pane neid erinevusi ilmselt tähelegi ja
heas usus saadabki enda andmed kalastajale. [5]
Aga
2FA kasutamine lahendab probleemi?
Pigem
ei. See küll lisab kalastajale lisameetmeid.
1)
Tuleb õigel veebilehel andmetega kohe sisse logida koos 2FA koodiga.
2)
Lihtsalt proovida mõnes teises keskkonnas samu andmeid kasutada.
3)
Müüa andmed maha või teha 2) ja 3) korraga.
4)
Ehitada reverse proxy näol üles vingem kalastamisleht.
Viimane variant
on ammu eksisteerinud (Cloudflare DDoS protection), kuid nüüdseks on mõned
sellised õngitsuslehed olemas[6].
Nagu näha siis kalastamine
veel eksisteerib, kuid selle takistamiseks on juba palju ära tehtud. Seda siis
nii tehnoloogiate (2FA, DMARC, SPF, HTTPS) kui ka inimeste teadlikust
kasvatavate projektide näol. Samuti on Google enda AI’ga hakanud paremini
tuvastama õngitsuslehti ja need teinud enda kasutajatele raskemini
kättesaadavamaks (Gmail filterid, Chrome veebilehitseja).
Kasutatud allikad:
[1] - Cybernetica ANDMEKAITSE JA INFOTURBE LEKSIKON
[2] - Phishing.org - History of Phishing
[4] - Phishing Activity Trends Report 2nd quarter 2020 (APWG)
[5] - Ichthyology: Phishing as a Science Karla Burnett (Blackhat 2017)
Comments
Post a Comment