14. nädal: asotsiaaltarkvara

IDN homograph attack

Rahvusvahelised domeeninimed (Internationalized Domain Names – IDN) on sellised domeeninimed, kus on lubatud ka mitte ASCII märgised. Idee ise hea ja meelepärane kindlasti väga paljudele inimestele üle maailma, nagu meie isegi, kelle keeles ASCII tähestikuga sugugi toime ei saa. Samas põhjustab see mitmeid probleeme, näiteks, kuidas peaks US klaviatuuriseadetega inimene sisestama aadressis ä-tähte?

Palju olulisem probleem on aga turvalisusega seotud. Kuidas teha vahet nendel linkidel:

  1. paypal.com
  2. pаypal.com

Visuaalsel vaatlusel tunduvad need identsed. Kuid ainult esimene neist on korrektne, samas kui teine viitab hoopis teoreetilisele kalastamisveebile. Võimalik on see homoglüüfide tõttu – teises aadressis on esimese ‘a’ tähe ASCII märgi asemel kirillitsa täht ‘а’ ehk Unicode’i täht U+0430. Inimese jaoks on tegu sama tähega, kuid arvutite ja domeenisüsteemi jaoks täiesti erineva tähega, seega täiesti erineva domeeniga. Taolist rünnet demonstreeriti 7. veebruaril 2005 Schmooconil.

Parim võimalik lahendus oleks ülemaailmne kontroll domeenide registreerimisel, et ei võimaldataks registreerida homograafseid domeeninimesid. Kuna tippdomeenid (.com, .net, .org, .ee jt) on ASCII, siis domeen lõpeb alati ASCII tähtedega ja DNS päring jõuab alati vastava tipp-registri serverisse. Poleks ilmselt lihtne üles seada alternatiivset DNS süsteemi, mis lahendaks .cоm-lõpulisi domeene (jällegi o asemel kirillitsa täht), kuna see hõlmaks juurserveritele suunatud päringute kaaperdamist.

Selge on aga see, et taoline totaalne kontroll on väga raske juurutada ja pidevalt töömahukas. Seetõttu on brauserite arendajad läinud seda teed, et IDN domeenide puhul ei näidata kasutajale mitte tema IDN esitust, vaid ASCII-põhist domeenisüsteemi-sisest esitust ehk Punycode’i: xn--pypal-4ve.com

Et kasutajate elu pisut mugavamaks teha, üritatakse leida kuldset keskteed ja Firefox ning Opera näitavad IDN nimekuju, kui on teada, et vastav tippdomeen rakendab ülalnimetatud kontrolle domeeni registreerimisel. IE näitab IDN nimekuju, kui domeen ei sisalda mitut tähestikku (st on läbinisti kirillitsas).

Facebooki rakendused

Populaarse suhtlusvõrgustiku Facebook üheks väga populaarseks osaks on erinevad rakendused, mida välised arendajad on loonud. Loomulikult kuulub taoliste avatud platvormiga keskkondade juurde ka teatav hulk pahalasi, kes üritavad oma loodud rakendustega teiste andmeid varastada või muud kurja korda saata. Õnneks nii Facebook kui ka veebilehitsejad annavad endast parima, et taolised ründed võimalikult keerulised oleks, kuid pettuste ohvriks langeb ikka inimesi.

Üheks taoliseks näiteks oli rakendus, mis esitas mõistatuse ja väitis, et iga lasteaialaps teab vastust, kuid mitte ükski geenius pole seda suutnud veel lahendada. Selline väide kõditab loomulikult iga inimese eneseuhkust, eriti kui ta usub, et ta teab vastust. Vastuse kontrollimiseks tuli vajutad mingit nuppu. Seejärel ilmusid juhised, mis palusid all hoida mingit klahvikombinatsiooni ja siis samaaegselt veel vajutada uut nuppu. Sobivates veebilehitsejates võimaldas selline kasutajapoolne kaasabi pahavaral turvasüsteemidest mööda hiilida ja käivitada skriptid, mis ohvri Facebooki sõbranimekirjas kõikidele inimestele lingi sellele samale rakendusele saatis. Võibolla tegi ta taustal veel midagi halba, nt kopeeris infot vmt, kuid selle kohta mul info puudub.

Orkut phishing

Lõpetuseks midagi oma kogemustepagasist.

Nädal või paar tagasi juhtusid mul kokku langema mitme projekti tähtajad ühele päevale, mistõttu eelmine tööpäev kujunes 19-tunniseks ja peale 3-tunnist uinakut uuesti tööle. Uusi e-kirju läbi vaadates leidus nende hulgas üks, mis oli Orkutist ja andis teada, et kunagine klassivend on jälle midagi põnevat teinud. Nüüd tagantjärele ei suuda ma hästi meenutada, miks ma üldse selles kirjas olnud lingil klõpsisin, sest tavapäraselt ei kuluta ma oma aega igasuguste pildi- ja staatuseuuenduste läbivaatamisele. Unise peaga aga miskipärast seda tegin ja ei pööranud ka tõsisemat tähelepanu avanenud Orkuti sisselogimise lehele, vaid sisestasin oma tunnused. Kuna pärast seda avatud veebileht vastas tavapärasele ja mingit tegelikult põnevat sisu seal tõesti polnudki, siis panin akna kinni ja jätkasin kirjade lugemist.

Mõni tund hiljem andis kolleeg listis teada, et ettevaatust!  mingi Orkuti kalastamise uss on liikvel. Talle oli just tulnud e-kiri, mis teatas, et mina olen midagi põnevat Orkutisse üles riputanud…

Seepeale otsisin prügikastist üles sellesama kirja, mille ise hommikul saanud olin – loomulikult oli see petukiri, mis sisaldas linki paroolide kalastamise lehele. Nii e-kiri kui ka veebileht olid valmistatud piisava sarnasusega päris keskkonnale, et mitte kahtlust äratada. Ainuke, mis pettust reetis oli aadress, kuid ka see polnud tavapärane IP numbrit või kaustana domeeninime sisaldav pikk ja lohisev, mille peale veebilehitseja oskaks lärmi tõsta. Seekord oli tegu päris lühikese, domeeniga, mis ilmselt selleks puhuks ekstra registreeritud või kaaperdatud.

Tegutsemine

Kui esmane ehmatus mööda läks, oli aeg tegutsema hakata. Loomulikult kõige esimese asjana tuli vahetada Google tsentraalne parool. See oli õnneks lihtne ja õnneks polnud pahalased parooli vahetamisega ise algust teinud. Järgmiseks võtsin suure vihaga ette pisut drastilisema sammu – kustutasin Orkuti konto maha, kuna nagunii polnud ma seal enam peaaegu aasta aega aktiivne olnud. Hiljem teavitasin ka Google turvasüsteeme ründeks kasutatud linkidest ja domeenist.

Seejärel oli aga vaja tagada turvalisus kõikidel teistel kümnetel veebidel, kus sisselogimine käib Gmaili aadressiga (ja pean tunnistama – tihti ka sama parooliga). Siinkohal tuli aga appi väga hea programm, mida kasutan paroolihaldurina LastPass. Sellel on töövahend nimega “Security check”, mis vaatab läbi kõik salvestatud andmed ja grupeerib need vastavalt kasutatud paroolile. Edasi jäi üle ainult ühekaupa kõik sellised veebid läbi käia ja parool turvalisema vastu vahetada. Sel korral muidugi lasin tihti LastPassil endal genereerida unikaalseid paroole, et veelgi turvalisust tõsta.

Kokkuvõtvalt võib öelda, et loomulikult peab olema ettevaatlik kõiksugu linkidel klõpsides ja parooli sisestades, kuid vastavalt Mitnicki 3. soovitusele annavad ka protseduurireeglid väga suure kasu, sest LastPass käib peamiselt just protseduurireeglite alla, kuna alustuseks see soovitab tungivalt kasutada erinevaid paroole erinevates veebides, aga muudab ka hädaolukorras tegutsemise efektiivsemaks. Ilma selleta oleks kindlasti nii mõnigi oluline veebileht ununenud, kuhu samuti selle Gmaili aadressi ja parooliga registreerunud olin.


13. nädal: Kogukondlik tarkvaraarendus

Vaba tarkvara arendamiseks ei pea alati kogukonda moodustama. Võib seda teha ka üksinda või firmana, lastes lihtsalt tarkvara koodi sobiva litsentsi all vabaks. Sellest hoolimata on kogukondlikul arendusel oma plussid ja muidugi ka miinused (algse arendaja vaatevinklist). Analüüsimiseks valisin kaks tarkvara:

Mitte täielikult vaba

Alustuseks tuleb kohe öelda, et SMF pole täielikult vaba OSI põhimõtete järgi – kasutamine, muutmine ja muudatuste tegemise juhendite levitamine on lubatud, kuid algse koodi enda levitamine vajab Simple Machines’i kirjalikku nõusolekut. Samas enda kogemusest teame, et selle nõusoleku saamine ei olnud keeruline protsess ja nad tahavad lihtsalt teada, kes ja kus nende koodi levitab. Põhjus on ajalooline – algselt oli SMF litsenseeritud GPL all, kuid arendajate meelest liiga tihti tuli ette litsentsi rikkumisi, kas tingimuste mõistmatusest või lausa pahatahtlikusest.

Katedraalimudel

SMF arendus käib küll vabatahtlike abil, kuid arendajad moodustavad kitsa siseringi ja väliseid abistajaid kutsutakse esialgu üles vaid kasutajatoe, teemade ja modide või dokumentatsiooni loomisel aitama. Kaasalöömise juhistes ei ole isegi öeldud, kas ja kuidas tuumikmeeskonna liikmeks saada on võimalik. Arvatavasti vajadusel nad valivad lihtsalt Kasutajatoe meeskonnast kõvemaid tegijaid.

Septembris avaldati teade, et Simple Machines LLC asendatakse MTÜ-ga, mis hakkab koordineerima SMF arendust. Võibolla see muudab ka arenduse ülesehitust, kuid ei pruugi, kuivõrd MTÜ juhatus on moodustatud praegusest tuumikringist.

Turumudel

phpBB arendus käib aga palju vabama mudeli järgi – kaasaaitamise lehel on täielik juhis, kuidas paiku tekitada ja kuidas neid meeskonnale kättesaadavaks teha. Kuigi on öeldud, et kogukonna arendajad peaks paikama ainult buge, usun, et arenduse teekaardilt mõne kaugema/vähemnõutud omaduse lisamine, kui see on hästi tehtud, võetakse ikka vastu.

Katedraali eelised

Konkreetsel juhul ei pruugi see tuleneda küll katedraalimudelist, kuid üldjuhul on katedraalimudeli puhul arendustee kindlalt paika seatud ja sellest tulenevalt on uued lisanduvad võimalused eelmistega kooskõlas, sammutakse mingi kindla eesmärgi poole ja see saavutatakse kiiremini. Võibolla sellel põhjusel edestaski kunagi tehtud uue foorumitarkvara valikumaatriksis SMF just oluliste omaduste poolest phpBB’d, kuigi viimasel on omadusi ja võimalusi kokkuvõttes oluliselt rohkem.

Turumudeli eelised

Aeg on aga näidanud välja ühe palju olulisema puuduse katedraalimudelis, mis turumudelis puudub – arenduse venimine. Ilmselt on SMF arendajatel käed-jalad tööd täis ja pole aega vaba tarkvara arendamisele keskenduda, mistõttu on SMF 2.0 juba aastaid Release Candidate staatuses, lastes vaid paari nädala eest välja 4. kandidaadi. Samal ajal on phpBB vaid selle aastanumbri jooksul andnud välja juba 2 uut versiooni, tööversioonid on pidevalt saadaval area51 nimelises keskkonnas.

See on tinginud asjaolu, et esialgu tehtud otsus SMF kasuks on nüüd pisut savijalgadel ja võib üsna varsti kukkuda.

Turumudeli puudused

Loomulikult ei pruugi turumudel alati hästi mõjuda ja väga tihti on ette tulnud killustatust, kus kogukond ei suuda konkreetset arendusteed fikseerida. Halvimal juhul võib kogukond isegi lahku lüüa ja haruprojekti välja kuulutada, et seda teises suunas vedama hakata. See mure on ka katedraalimudeli puhul, kuid mõnevõrra vähemal määral, kuna kogu projekti on juba algusest peale “kindla käega” juhitud ja vaid ootamatu kursimuutus võiks kogukonnas mässu tekitada.

Õnneks phpBB ei tundu selle sündroomi all kannatavat, kuna arendus on üsna sujuv ja pidev ning pole kuulda olnud lahkhelide tõttu haruprojektide käivitamisest.

Kokkuvõte

Nagu näha, võib katedraalimudel kannatada tugevalt, kui arendajatel on ajaprobleemid ja juhtkond seda ei märka, ei taha või ei saa meeskonda suurendada. Turumudeli puhul korrigeerub see automaatselt – kui arendus kipub toppama jääda, siis ikka mõni oskuslikematest kasutajatest oma õla alla paneb (vähemalt teda huvitavate omaduste piires).

Seetõttu pean katedraalimudelit õigustatuks ainult tingimustes, kus algne autor lihtsalt “heast tahtest” avalikustab mingi toote koodi, kuid ei kavatse (nt ajapuudusel) sellest vaba tarkvara projekti kujundama hakata ja tahab säilitada täielikku kontrolli arendusplaani üle. Sellisel juhul aga on kogukonnal võibolla otstarbekam haruprojekt käivitada.