PHP 7.1, testijate ID-kaardid, kehtivuskinnituse manustamine ja turvapaik, mis tekitab turvaaugu

Tänane blogipost räägib uutest ja unikaalsetest võimalustest Zone tarkvaplatvormis. Käsitlemist leiavad HTTPS sertifikaatide ‘OCSP stapling’, preili Cøntrolina Ålt-Deletè ID-kaart, PHP faililaienditega seotud nokk-kinni-saba-lahti tüüpi riskid ja PHP 7.1 toe lisandumine.

Ega’s midagi, paneme aga progressile hagu alla ja proovime lahti seletada, kuidas see kõik maailmarevolutsioonile kasulik on.

OCSP stapling ehk kehtivuskinnituse manustamine

Selle vajadus tuli meil esimest korda jutuks, kui rahvusvaheliselt Magento-arendusega tegelev Vaimo mainis HTTPS’ist rääkides aeglasema ühendusega turge kolmanda maailma riikides. Nimelt kontrollivad veebibrauserid HTTPS-ühenduse loomisel serveri sertifikaadi kehtivust, tehes täiendava päringu selle väljastanud sertifitseerimisasutuse poole, see aga võtab aega ja võib kehva ühenduse puhul ka ebaõnnestuda.

Probleemist aitab üle OCSP stapling, mille puhul server hangib perioodiliselt ise OCSP ehk Online Certificate Status Protocol abil digiallkirjastatud kehtivuskinnituse, puhverdab selle ning väljastab ühenduse loomisel koos oma sertifikaadi-ahelaga. Nii saab brauser olemasoleva juursertifikaadi abil kontrollida kõigi sertifikaatide kehtivust ilma täiendavate päringuteta.

Zone Virtuaalserverites on nüüd olemas OCSP stapling tugi, mis on automaatselt aktiveeritud kõigile Let’s Encrypt sertifikaati kasutavatele serveritele,  aga seda saab lubada ka muid sertifikaate kasutades eeldusel, et vahetaseme ehk intermediate sertifikaadid on korrektselt seadistatud. Olgu öeldud, et SSLlabs’i testis hea hinde saamiseks on intermediate ahela seadistus niikuinii vajalik – ja kuuldavasti hakkab hinne A varsti sõltuma ka OCSP stapling’u kasutamisest.

Seadistuse saab muuta Virtuaalserveri haldusest:

ocsp-stapling

Selle kohal on aga näha teine uuendus:

Eesti test-IDkaardi tugi ehk ẘĕļƈỗɯẹ, Cøntrolina Ålt-Deletè

controlina

Zones tarkvara-arenduses kasutame Sertifitseerimiskeskuse väljastatud test-IDkaarte vältimaks vajadust rakenduse testimisel reaalselt siduvaid digiallkirju anda ning potentsiaalset segadust domeeni sdfghjklö.ee registreerimise või asdasd.ee omanikuvahetusega. Oma arendus-serveri puhul test-sertifitseerimisasutuse seadistamine osa tavapärasest tööprotsessist, aga samas võiks edumeelne arendaja teha ka Virtuaalserveri puhul alamdomeenid test.* ja staging.* ning seal julgelt katsetada.

ID-kaardi tugi on olemas kõigis meie Virtuaalserverites ja realiseeritud nii, et server nõuab brauserilt kasutaja sertifikaati ning kontrollib selle väljastajat ja kehtivust. Ametliku ID-kaardi sertifikaadi väljastajaks on EE Certification Centre Root CA, testsertifikaadil TEST of EE Certification Centre Root CA:

sk-root-certs

Valides Virtuaalserveri halduses serverile või (soovitavalt) testiks kasutatavale alamdomeenile TEST ID-kaardi toe kontrollib server kliendi-sertifikaadi vastavust test-ahelale… ehk nii lihtne see ongi. Kuna valik on binaarne ehk üks-või-teine, puudub ka oht, et “tootmiskeskkonnas” saaks kasutada test-kaarte.

Kolmas ja neljas muudatus on aga seotud PHPga.

Mitme faililaiendi toe väljalülitamise võimalus

See on üks salakaval valik, mille mõlemad olekud tekitavad erinevat laadi turvaprobleeme.

Mitme faililaiendi tugi – mis meil ajalooliselt on lubatud olnud – tähendab seda, et PHP käivitamiseks ei pea .php olema ilmtingimata viimane laiend failinime lõpus – väidetavasti on ajaloolistel isikutel olnud kombeks kasutada pisipiltide loomiseks skripte, millel nimi stiilis teeme-väiksed-pildid.php.png, samuti leiab serveritest hulgaliselt faile nimedega stiilis wp-config.php.bak. Mitme laiendi tugi tagab nende mõlema käivitamise PHP-na ehk esimesel puhul tehakse pisipilt ja teisel puhul ei kuvata kõigile huvilistele välja seadistuste failis olevaid andmebaasi kasutajatunnuseid.

On aga ka negatiivne pool – nimelt leidub paljudes sisuhalduslahendustes ja nende laiendustes mitte-kõige-osavamalt-kirjutatud faili-üleslaadimise-koodi, mis heal juhul kontrollib failinime lõpus olevat laiendit ja lubab rahulikult … näiteks teeme-väikse-tagaukse.php.png laadimist serverisse. Kui on lubatud selliste failide käivitamine PHP-na, siis muutub oluliselt suurem hulk haavatavusi reaalselt ärakasutatavateks. Kui me aga selle välja lülitaks, võiks osa veebe katki minna ja teistes muutuksid kogemata serverisse ununenud .php.bak failid nähtavaks (neid skannitakse pidevalt).

Seega on igaühel nüüd võimalik mitme-laiendi-tugi välja lülitada, olles eelnevalt koristanud ära failid, millel kogemata on .php taha sattunud veel mõni muu laiend. Hea mõte oleks ka .htaccess’i algusesse mõned reeglid lisada, mis takistavad config-nimeliste failide kogemata kuvamist – päris hea kollektsioon on Perishable Press’i 6G reeglites (või minu väikeste kohendustega versioon gist’ina)

php-71

… ja PHP 7.1 on beetast väljas!

Meile teadaolevalt ei kaasne üleminekuga 7.1 peale suuremaid probleeme koodile, mis 7.0 all toimib. Esile võiks tuua vahest mcrypt’i (vt mcrypt-viking-funeral), mis hakkab andma hoiatusi ja kaob lõplikult järgmises versioonis.

Tõenäoliselt hakkame mõne alam-versiooni järel seadistama 7.1 uute Virtuaalserverite vaikeversiooniks – ning vastavalt väljakuulutatud poliitikale saab 6 kuu pärast ehk mais 2017 sellest SAPI ehk Apache moodulis kasutatav versioon ning ühtlasi läheb 7.1 kasutusse vaikimisi käsurealt käivitatava versioonina.

Tähistame .EU tippdomeeni tähtpäeva ainulaadse pakkumisega

.EU tippdomeen on ühendanud Euroopa Liitu ühtseks digitaalseks turuks juba enam kui 10 aastat. Tähistame seda registreerides .EU domeene erakordselt soodsatel tingimustel.

.EU logo
7. detsembril 2005. aastal tekkis Euroopa Liidus esmakordselt võimalus registreerida .EU domeene. Tol hetkel said selle privileegi osaliseks kaubamärkide omanikud.

Mõned kuud hiljem, 2006. aasta aprillis, järgnes sellele valjem stardipauk, mis tõi domeenid ka laiema avalikkuse käeulatusse. Võidujooks domeenidele oli erakordselt aktiivne ja viis nende koguarvu juba esimese aasta lõpuks miljonitesse.

Nii seob .EU tippdomeen Euroopa Liidu 500 miljonit elanikku üheks suureks digitaalseks turuks juba enam kui 10 aastat ning sellest on saanud üks ühendusesisese e-kaubanduse alustalasid.

Zone tähistab Euroopa Liidu internetikogukonnale olulist tähtpäeva unikaalse pakkumisega.

Nimelt pakume ettevõtjatele, kel on mõtteid ja ambitsioone Euroopa Liidu ühisturu suunas, aga puudub veel konkreetne tegevuskava, võimalust reserveerida oma .EU identiteet pikemaks ajaks erakordselt soodsatel tingimustel:

1. detsembrist kuni 9. detsembrini on kõigil huvilistel võimalik registreerida endale .EU domeen 10 aastaks hinnaga 24€.

10. detsembrist pakkumine muutub ja aasta lõpuni saab domeeni samaks ajaperioodiks registreerida 36€ eest.

Võttes meie kampaaniast osa, saavad ettevõtted kindlustunde, et ambitsioonide vormumisel konkreetseks tegevuskavaks, on vajalik interneti-identiteet kindlasti olemas.

Head .EU domeeni registreerimist!

P.S. Ühtlasi tasub vist meelde tuletada, et Zone Virtuaalserveritele saab liita aliaseid ilma täiendava teenustasuta. Nii on peale registreerimist võimalik .EU domeen lisada olemasoleva .EE kõrvale ilma täiendava kuluta.

Käivitus .BLOG tippdomeen

WordPressi arendajana tuntud Automattic on koos oma fantastiliselt nimetatud tütarettevõttega ‘Knock Knock, WHOIS There’ käivitanud uue tippdomeeni ja pakub nüüd kõigile .BLOG lõpuga internetiaadresse.

Automatticu ja KKWT usk sellesse, et tegemist on hästieristuva ja populaarse nimega on end ära tasunud, sest esimese 24 tunni jooksul on värskes tippdomeenis registreeritud juba rohkem kui 19.000 uut domeeni.

Domeeni registreerimise tasu on .BLOG tippdomeenis küll mõnevõrra suurem geneerilistest domeenidest (nagu .COM) ja isegi rahvuslikest tippdomeenidest (nagu .EE), kuid sellel on ka positiivne külg, nimeruum ei risustu nii kiiresti ja head domeenid püsivad kauem vabana. Tõenäoliselt loodavad tippdomeeni arendajad ka, et see hoiab ühtlasi blog-lõpuliste veebisaitide sisu keskmisest kvaliteetsemana.

Kahjuks, nagu uutele tippdomeenidele kombeks, on väga väärtuslikud nimed registri poolt reserveeritud ja müüakse maha erihinnaga. Nii ei maksa meil unistadagi zone.blog nimelisest domeenist, kui me ei taha selle eest aastas välja käia 11 500 € suurust summat. Jätame seekord vist vahele 🙂

Kõigil teistel on .blog domeene võimalik registreerida Zone kaasabil, kasutades selleks meie värskenduskuuri läbinud domeenide otsimise vormi: https://www.zone.ee/et/domeeni-otsing

Kuidas veebilehe koodist pahavara üles leida

Õpetame tuvastama mustkunstitrikke, mille abil pahavara autorid oma loomingut kodulehe koodi ära peidavad ja märkama seda, kui veebilehel on midagi viltu.

malware

Pahavara on mitmesugust, seda on nii erineva otstarbega kui ka erineva tehnilise teostusega. Kui nakatunud JavaScripti failid ründavad eelkõige lehekülje kasutajat, näiteks kasutaja krediitkaardiandmete varastamiseks, siis nakatunud või serverisse sokutatud php-failid on pigem hõivatud serveri ressursside kasutamisega. See oleks nii võrguühenduse kasutamine spämmi saatmiseks, arvutusvõimsuse kasutamine bitcoinide kaevandamiseks ja muud taolised tegevused.

Muidugi tegelevad ka serveris olevad pahavarad kohati andmete vargusega, kuid tavaliselt on massiliselt leviv pahavara siiski “rumal” ja mõeldud teostama mingit suhteliselt lihtsat tegevust. Eelkõige siis selle tõttu, et igasugune vargus eeldab täpsemat sihtimist, suvaliselt kõike maailmas salvestatut kokku kuhjata läheb kallimaks, kui potentsiaalne tulu. Krediitkaardi andmeid saab varastada ju ainult siis, kui saab eeldada, et need andmed võivad üldse eksisteerida, spämmi võib aga saata kasvõi nutipirnist või -röstrist. See muidugi ei tähenda, et andmeid või identiteete varastavat pahavara ei peaks kartma, muidugi peab, lihtsalt et kui mingi pahavara on serverisse jõudnud, siis suurema tõenäosusega on see just “rumalat” laadi. Rumal siinkohal tähendaks sellist pahavara, mis ei tea ega hooli keskkonnast, kuhu on sattunud, oluliseks on ainult selle poolt pakutav arvutusvõimsus jmt. ressurss.

Veebiressursi omanikena me samas taolist pahavara enda kodulehele ei taha. Krediitkaardi andmete vargus tähendab suurt plekki meie äritegevusele, spämmi saatmine omakorda võib tähendada, et meie kinnitus- ja muud kirjad klientidele ei jõua enam kohale, kuna kõik meie serverist tulev tembeldatakse kahtlase ajaloo tõttu automaatselt spämmiks. Bitcoini kaevandamine või DDoS-botnetis osalemine muudab meie kodulehe nii aeglaseks, et kliendid lähevad konkurendi juurde. Seega on selgelt meie huvides, et igasugune pahavara võimalikult kiirelt avastada ja eemaldada.

Tänapäeval on õnneks olemas mitmeid automaatseid vahendeid pahavara avastamiseks, kuid kohati võib olla vajalik ka käsitsi faile üle vaadata. Päris kõiki faile ei ole ilmselt mõtet selle jaoks läbi käia, peamiselt tasuks keskenduda nendele failidele, mida on hiljuti muudetud või mis on täitsa uued.

Muutmisaja järgi faile sorteerida saab kasvõi käsurealt, näiteks järgmise käsuga:

find . -printf "%T@ %Tc %p\n" | sort -rn

kuid sellest ei pruugi olla alati abi kuna pahavara võib proovida faili muutmisaega ära peita. Tavaliselt käib see nii, et pahavara otsib üles samas kaustas oleva kõige vanema faili ning määrab iseendale sama muutmisaja. Kuidas sellisest petmisest mööda saada, võib lugeda ühest varasemast postitusest.

Ütleme, et oleme nüüd leidnud serverist mõned php-failid, mida on hiljuti muudetud ja tahaksime kontrollida, et kas need on kahtlased või mitte. Vaatakski mõningaid mustreid, mis võivad viidata pahavara olemasolule.

1. Uued failid

Kui meie serverisse on installitud WordPress ning ühtäkki tekib wp-includes kausta uus php-fail (rakenduse seadistusest sõltuvalt ei pruugi php-faili laiend olla alati .php, see võib olla ka .inc vmt.), siis võib see olla märk kahtlasest tegevusest, kuna wp-includes kausta sisu peaks muutuma ainult WordPressi versiooni uuendamise käigus. Samas ei tähenda see veel 100% kindlusega pahavara olemasolu, süüdi võib olla hoopis mõni kehvavõitu plugin, mis ei järgi ettenähtud parimaid praktikaid.

2. Pikad koodiread

Tihti pakitakse ja obfuskeeritakse pahavara võimalikult kitsalt kokku, mis võib ka tähendada seda, et pahavara kood paigutatakse ühele või paarile reale koodifailis. PHP jaoks ei ole reavahetusi tarvis, seega võib koodirida olla ka megabaidi pikkusega. Samas inim-programmeerija jaoks on omane kasutada palju lühemaid ridu, näiteks 120 sümbolit vmt. kuna pikemat rida on lihtsalt keeruline hoomata. Seega kui ülejäänud kood kasutab lühikesi ridu, siis ülipikad read lühikeste vahel on kindlasti kahtlased.

3. Miksitud koodistiil

Vahel peidetakse (eelkõige kommertstarkvara puhul) rakenduse kood obfuskeerimise taha. St. et kood lastakse läbi automaatse süsteemi, mis näiteks muudab ära kõik muutujate ja funktsioonide nimed (uued nimed on lühikesed juhuslike sümbolite jadad), eemaldab kommentaarid, üleliigsed tühikud, reavahetused jmt. mille tulemusena muutub kood raskesti loetavaks. JavaScripti, HTML’i ja CSS puhul on see täiesti tavaline praktika ka tasuta tarkvara puhul, kuid seal ei kaitsta koodi mitte konkurendi silmade eest, vaid selline töötlemine tagab lühema koodi ja seega ka kiirema kodulehe ja väiksema ressursikulu – 200 kB JavaScripti laadimise asemel peab kasutaja brauser laadima võibolla ainult 120 kB.

Ühesõnaga, koodi obfuskeerimine on iseenesest levinud praktika, kuid see võib tekitada ka mõningaid kahtlusi. Näiteks serveri poolse koodi obfuskeerimine on siiski pigem haruldane ja võiks täiendavat huvi tekitada. Eriti kahtlane on selline olukord, kus failis olev kood on muidu niiöelda inimloetav, aga vahepeal on mingid koodiread, mis viitavad obfuskeerimisele (loetamatute nimedega muutujad ja funktsioonid, koodi “treppimise” puudumine). Samuti on kahtlane kui muidu on kood obfuskeeritud, aga siis on kuskil faili lõpus või alguses justnimelt loetav kood.

4. Base64 kasutamine

Base64-kodeeringu kasutamine on tegelikult üsna tavaline, sest see annab võimaluse edastada binaarset infot üle tavalise teksti. Base64 puhul võetakse suvaline binaarne väärtus (st. baitide jada) ja esitatakse seda kasutades 64 erinevat sümbolit, mille hulka kuuluvad suured ja väikesed ladina tähed, numbrid ja mõned kirjavahemärgid. Näiteks teksti “Veebi turvalisusel on ka äriline mõõde” base64-kodeeritud esitus näeb välja nii:

VmVlYmkgdHVydmFsaXN1c2VsIG9uIGthIMOkcmlsaW5lIG3DtcO1ZGU=

Siit peaks kohe näha olema ka põhjus, et miks pahavara base64 kodeeringut väga armastab – see muudab teksti inimsilmale loetamatuks. Arvuti jaoks ei ole väga vahet, et kas mingi tekst on esitatud tavaviisil või base64-kodeeringus, küsimus on lõpuks vaid bittide asetuses (base64-kodeering kasutab 24 bitise info salvestamiseks 4 baiti tavapärase 3 asemel).

Base64 ilmnemise tunnuseks on eelkõige pikad ja seosetud tekstiread, kus puuduvad tühikud (küll võivad olla reavahetused) ning mis tihti lõppevad ühe või rohkema võrdusmärgiga. Võrdusmärk teksti lõpus tähistab puuduvate bittide täidist (base64 minimaalne “sümboli” pikkus on 3 baiti ning kui sisendist jääb selle jaoks puudu, siis täidetakse puudu jääv osa võrdusmärkidega).

$_jmo12r_='VGhlIHBhcnRpY3VsYXIgY2hvaWNlIG9mIGNoYXJhY3RlcnMg
dG8gbWFrZSB1cCB0aGUgNjQgY2hhcmFjdGVycyByZXF1aXJlZCBmb3IgYmF
zZSB2YXJpZXMgYmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMuIFRoZSBnZW5lch
...
lciB2YXJpYXRpb25zLCB1c3VhbGx5IGRlcml2ZWQgZnJvbSBCYXNlNjQsIH
oYXJlIHRoaXMgcHJvcGVydHkgYnV0IGRpZmZlciBpbiB0aGUgc3ltYm9scy
aG9zZW4gZm9yIHRoZSBsYXN0IHR3byB2YWx1ZXM7IGFuIGV4YW1wbGUggdH
aXMgVVRGLTcu==';

Meie peaksime otsima koodist base64_decode funktsiooni kasutamist, mis muudab base64-vormingus teksti tagasi esialgsele binaarkujule. Selle vastandfunktsioon base64_encode on pahavara puhul palju haruldasem, kuna kodeerimise töö on pahavara autor juba eelnevalt ära teinud, nüüd tuleks base64 lihtsalt lahti dekodeerida.

Kusjuures base64_decode funktsiooni olemasolu ei tähenda veel automaatselt pahavara, kuna seda võidakse kasutada ka täiesti legaalsetel eesmärkidel. Mida me peaksime pigem vaatama on funktsiooni sisend – kas meile on arusaadav, et mis see on ja kust see tuleb? Juhul kui sisendiks on muutuja, mille nimi on juhuslikest sümbolitest, siis on see kindlasti kahtlane. Samuti on kahtlane, kui dekodeeritav sisend on väga pikk, näiteks mitmeid kilobaite.

Alati ei kasuta pahavara base64 dekodeerimiseks base64_decode funktsiooni, kuna seda on suhteliselt kerge tuvastada. Selle asemel implementeeritakse mõnikord vastav algoritm ise, mis viibki meid järgmise punktini.

5. Bitioperatsioonid

Bitioperatsioonid võimaldavad manipuleerida baitides üksikute bittidega ja see on täpselt see, mida läheb vaja näiteks base64 dekodeerimise algoritmi jaoks. Kui me näeme, et koodis on funktsioon, mis käivitatakse base64-laadse sisendiga ja mis kasutab muu hulgas operaatoreid >>, << ja &, siis suure tõenäosusega on tegu just base64 dekodeerimisega.

Täiendavalt on ohu märgiks veel üks oluline bitioperatsioon, nimelt ^ ehk XOR.

6. XOR-krüpteerimine

XOR-šiffer on üks lihtsamaid viise andmete peitmiseks. Seda on lihtne implementeerida, see on väga kiire ja samas tõhus – kui võti on vähegi pikem, siis on algset teksti üsna raske taastada. Seega pole ime, et pahalased seda hea meelega kasutavad.

Vajalik on see tavaliselt pahavara koodi peitmiseks. Kood on failis teksti kujul olemas, kuid koodi tekst on XOR-krüpteeritud. Pahavara kood käivitub veebipäringu peale, mis dekrüpteerib peidetud koodi, kasutades päringus edastatud salavõtit. Juhul kui me ei suuda sellist päringut koos päringu andmetega maha logida (võti on reeglina POST päringu argumendina, seega tavaliselt seda ei logitagi), siis me pahavara koodi ka ise lahti ei saa. Selline meetod hoiab pahavara uinuvas oleks, iseenesest see midagi ei tee, me ei saa ka selle sisu vaadata, aga ründaja saab selle oma päringuga aktiveerida. Tüüpiliselt on see siis omane erinevatele botnetidele.

Kõige lühem XOR-šifri implementatsioon näeks välja järgmine ($code on pahavara lähtekood teksti kujul ja $secret on veebipäringuga edastatud salakood):

for($i = 0; $i < strlen($code); $i++)
  $code[$i] = ($code[$i] ^ $secret[$i % strlen($secret)]);

Sarnast koodi nähes võiks tekkida kahtlus, kas skript ei sisalda mitte pahavara.

Siit aga tekib kohe järgmine punkt, nimelt on vaja sellise teksti kujul salvestatud kood ju rakenduse koodina käima saada ja selles aitab meid eval.

7. eval koodi käivitamiseks

eval on üks jubedamaid PHP (ja ka muude keelte) võimalusi, kuna see lubab interpreteerida tavalist teksti programmikoodina. Kui ründaja leiab võimaluse anda ette mõnele koodis leiduvale eval käsule enda koostatud teksti, on see täiuslik tagauks – ründaja kood pannakse käima nii, nagu oleks see veebirakenduse enda osa. Tavaliselt küll sokutavad ründajad selle eval’i serverisse erinevate turvaaukude kaudu ise, sest küll hiljem jõuab mõelda, et mida selle abil üldse käivitada. Juba ainuksi eval’i esinemine koodifailis on seetõttu kahtlane.

Paraku aga on eval’il ka täiesti legitiimset kasutust ja seetõttu automaatselt neid faile, milles esineb eval, siiski pahavaraks pidada ei saa. Samas on võimalik kahtlast tegevust siiski tuvastada.

Kõige levinum viis eval’it eesmärgipäraselt kasutada, on kujul:

eval('$mingimuutuja=...')

Ühesõnaga, muutujale antakse mingisuguse serialiseerimise käigus koostatud koodi abil väärtus. Pahavara puhul näeb see tegevus välja reeglina hoopis teine, sisend tuleb mingist juhusliku nimega muutujast või koostöös base64_decode funktsiooniga kusagilt pikemast inimloetamatust tekstimassiivist:

eval(base64_decode('ZWNobyAiT2xlbiB2aWlydXMhIjs='));

või

eval($r['_weretwt_']);

Kui eval võtab oma sisendi POST päringust, mitte ei kasuta staatilist tekstiväärtust, siis see viitab kas webshell’ile või botnetile, kus ründaja saab kasutada oma kontrolli all olevaid masinaid sundida tegema seda, mida parasjagu vaja on.

8. Stringmuutujate kasutamine funktsioonidena

Kuigi täiesti lubatud ja kohati ka kasutatud, on stringimuutujate kasutamine funktsioonidena siiski pahavara tunnus. Siinkohal kehtib jälle rusikareegel – kui on aru saada, et millega tegu, siis tõenäoliselt ei ole pahavara, vastasel korral pigem on.

$r = "printf";
$z = 123;
$r($z); // funktsiooni nimi tuleb stringist

Lisapunktid tulevad selle eest, kui funktsiooni nimetus tuleb globaalsest skoobist, see on küll üsna pahavara moodi

$GLOBALS['seosetutekst']($sisend);

9. TCP ühendused

Viimaseks punktiks tooksin välja veel võrguühenduste avamise ning eriti UDP ühenduste loomise. Juhul kui meil on “tavaline” tarkvara, näiteks WordPress vms. siis ei ole sellel tarkvaral reeglina mitte mingisugust põhjust avada kuskile UDP ühendusi. Taustal seda muidugi võib toimuda, näiteks DNS nimepäringute käigus, aga koodis endas vastavaid funktsioone kasutada ei tohiks. UDP puhul võivad erandiks olla siiski logimoodulid, mis saadavad logikirjeid üle UDP, kuid see peaks siis olema muust koodist selgelt eraldatud.

Kui pahavara teeb avab TCP ühendusi portidesse 25, 465, 587, 2525, siis on tegu spämmi saatmisega. Portide 80 ja 443 kaudu postitatakse reeglina rämpskommentaare. Muude portide puhul võib arvata, et tegu on botneti C&C serveriga, kust käidakse endale uut “tegevust” küsimas.

Seega peaksime otsima koodist funktsioone fsockopen ja stream_socket_client. Loomulikult teeb ka tavaline tarkvara võrgupäringuid, kuid tavaliselt avatakse kindel veebiaadress kasutades curl API’t (levinud teek keerukate võrgupäringute tegemiseks), “toorete” ühenduste avamist tuleb ette palju harvem ja reeglina selgelt arusaadavas kontekstis, näiteks HTTP päringute tegemise klassi meetodites juhul kui curl näiteks puudub.

Kusjuures, pahavara kasutab ka ise hea meelega curli teeke, aga kuna curl ei ole kõikides serverites saadaval, siis tuleb paralleelselt implementeerida ka socketi põhised päringud.

Kokkuvõtteks

Üldiselt tasub koodi analüüsimisel otsida eelkõige anomaaliaid, st. stiilierinevusi ülejäänud koodist ning privilegeeritud funktsioonide (eval, fsockopen jne.) kasutamist. Ja jälle – rusikareegel – kui saame aru, mis toimub, siis suure tõenäosusega ei ole tegu pahavaraga, kui aga kasutatakse seosetuid ja juhuslikke muutujanimesid, andmed tuletatakse base64-kodeeritud tekstist, kasutatakse XOR krüpteeringut jne. siis suure tõenäosusega toimub midagi kahtlast. Arusaamise all pean silmas seda, et me ei pruugi loomulikult hoomata kõike seda mida kood teeb, aga see tundub vähemalt olevat loogilises kontekstis. Seega kui tegu on RSS voo parsimise klassiga, siis meetodite nimed kirjeldavad RSS vooga seotud toiminguid, näiteks $rss->get_feed_item(), aga mitte $KcyezF->grebuZ().

Kindlasti ei piirdu pahavara esinemise sümptomid ainult nende 9 punktiga ning osavamad pahavara loojad kasutavad mitmesuguseid võtteid oma tegevuse peitmiseks. Suurem osa pahavarast on ikkagi “rumal,” see on mõeldud täitma mingit kindlat ülesannet ja selle peitmisega pole väga vaeva nähtud, kuna see teeks arendamise aeglasemaks ning kasu oleks sellest vähe – pahavara otsimise ja eemaldamisega tegeleb kahjuks väga väike osa veebiressursside omanikest.

Iga vastutustundliku veebiomaniku kohta on lugematu hulk paikamata Joomlaid ja WordPresse, mida üle võtta ja isegi kui ühe veebi pealt teenib ründaja vaid sente, on see tegevus automaatne ning massiliselt skaleeruv, mis tasub pahavaraga tegelemise ründajale kindlasti ära. Seega läheb see probleem ajas ainult tõsisemaks ja mõistlikum oleks juba kohe praegu oma veebi korrasolekuga tegeleda, mitte jääda mõnd suuremat pauku ootama.

Need tüütud salasõnad

Alguses oli salasõna. Ja salasõna oli ‘god’… või ‘love’ või ‘sex’ või ‘secret’. Möödusid aastad ja enam pole ka ‘s3x-g0d-l0ve-s3cr3t’ piisavalt keeruline. Mis nüüd?

teh-plague

The Plague: Our recent unknown intruder penetrated using the superuser account, giving him access to our whole system.

Margo: Precisely what you’re paid to prevent.

The Plague: Someone didn’t bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and…

Margo: [glares at The Plague]

The Plague: god. So, would your holiness care to change her password?

Juba arvutite ja Interneti koidikul vajasid süsteemid tõendit, et terminali taga istuv kasutaja on just see, kes ta väidab ennast olevat ning lühike tekstijupp kõlbas selleks väga hästi. Alguses polnud salasõna keerukus kuigi oluline, sest arvutiteid oli vähe ning nendes olev info polnud ka kuigi kriitiline. Piisas sellest, kui parool polnud liialt kergesti ära arvatav. Asjade arenedes tekkis aga pahatahtlikematel kodanikel huvi paroole ära arvata ja murda ning rakendada selleks ka selleks tööks sobivaid masinaid – arvuteid. Et arvutid mõistliku ajaga seda ülesannet lahendatud ei saaks, mõtlesid targad inimesed välja Turvalise Salasõna Reeglid.

Me kõik oleme paroolireeglitega kokku puutunud. „Paroolis tuleb kasutada suuri ja väikseid tähti, vähemalt üht numbrit ja üht muud sümbolit ning see peab olema vähemalt 8 sümbolit pikk.“ Probleemid selle lähenemisega ilmnesid tegelikult juba päris alguses. Ükskõik kui keerulisi reegleid sa ka ei kehtesta, leidub ikka väga lihtsalt ära arvatavaid paroole, mis kõigile keerukuse tingimustele vastavad. „Parool1.“ on täielikult eelpool toodud tingimustele vastav salasõna. Asja tegi veel hullemaks kellegi rumal idee, et kasutajad peavad iga kolme kuu tagant paroole vahetama. See sundis kasutajaid veel eriti leidlik olema, et uusi kiirelt meeldejäävaid “turvalisi” paroole leiutada. Nii, kuidas on kasvanud arvutite paroolimurdmise võimekus, on läinud rangemaks ka paroolile kehtivad nõuded. Ükskõik kui keerulist kaheksa sümboliga parooli ei loeta juba tükimat aega turvaliseks ja paroolide meeles pidamine on muutunud järjest raskemaks.

Vahepeal levinud nõuanne kasutada lühema suvaliste sümbolite jada asemel palju pikemat suvaliste sõnade jada, mis oleks nagu arvutile raskem murda, oli kasulik ainult nii kaua, kui paroolide murdmiseks kasutatav tarkvara polnud nendega arvestanud. Praeguseks kasutavad kõik popimad paroolimurdjad ka sõnastikke ning “My-Very-Secure-But-Long-Not-Random-Password” stiilis salasõnu ei loeta ka enam turvaliseks. Isegi juhuslike tähtede asendamine numbritega ei aita. Eestlasi aitab hetkel natuke see, et meid on nii vähe ja eesti keele sõnastikud pole paroolimurdjates veel levinud. Kuid nende sinna jõudmine on ainult aja küsimus.

Aegamööda tekkis kasutajatel teenuseid, kus parooliga ennast tuvastama peab, järjest juurde – e-poed, hobifoorumid, uudisteportaalid jne. Erinevatel andmetel on keskmisel internetikasutajal praeguseks üle 100 erineva konto. Sellist hulka erinevaid turvalisi paroole ei suuda muidugi enam keegi meeles pidada ning väljapääse on kaks – kas kirjutada salasõnad üles või neid taaskasutada. Paljud läksid muidugi kergema vastupanu teed ja valisid viimase. Heal juhul paar erinevat parooli erineva turvatasemega kontodele (olulistel üks parool, vähemolulistel teine), kehvemal juhul üks parool kõigile. Ega tegelikult saa seda neile ka väga pahaks panna, sest turvaeksperdid olid eelnevalt aastaid (aastakümneid?) korranud pidevat mantrat – „Paroole EI TOHI üles kirjutada!“.

Paroolide taaskasutamine pole ka muidugi kunagi väga hea idee olnud, kuid see on kasutajate enamuse jaoks toiminud – kuni nad pole sihitud rünnaku sihtmärgiks sattunud. Uued ajad on toonud aga uued probleemid. Nii, kuidas järjest rohkem infot on võrku liikunud, on kasvanud ka võimalused seda infot rahaks teha. IGA konto, ükskõik kui tähtsusetu see sulle ka ei tundu, on pahatahtlike kodanike jaoks ressurss, mida on võimalik kuidagi raha teenimiseks kasutada. Kui mitte muul moel, siis rämpspostituste tegemiseks ikka. See omakorda on tekitanud pahatahtlikes häkkerites enneolematu huvi kasutajate info teenuspakkujate juurest pihta panna – pahatihti ka väga edukalt [1]. Ka ei ole sellised lekked enam ammu teisejärguliste ja vähemtähtsate teenuste pärusmaa. Aja jooksul on kümnete miljonite kasutajate andmeid lekitanud Linkedin, Evernote, Dropbox, Ebay, Mail.ru, Yahoo ja paljud teised. Viimane suurem leke toimus täsikasvanute portaale haldavast firmast “Friend Finder Network”, kust lekkisid 412 miljoni kasutaja andmed, sh paroolid.

Kurjategijate peamine huvi on saada ükskõik mis teenusest kasutajate e-posti aadressid ja salasõnad. Kui teenusepakkuja on olnud väga lohakas ja hoiab paroole krüpteerimata kujul, on pahalase töö eriti kerge. Kui ettevaatusabinõud on tarvitusele võetud, on paroolid küll krüptitud, kuid nende lahti murdmine sõltub põhiliselt parooli turvalisusest. OK, saavad pahad parooli teada, mis nad selle infoga peale hakkavad? Nad kasutavad seda infot katseteks murda teisi teenuseid. Lihtsustatult – kui sul on lillekasvatajate foormis konto meiliaadressiga “kukununnu98@gmail.com” ja mille parooli kurjategija kätte saab, on loogiline samm katsetada selle sama infoga sisse logida Gmail’i, Facebook’i, teistesse foorumitesse jne Kui sa paroole taaskasutad, ongi sinu olulised kontod kaaperdatud. Kui läheb hästi, pääsed ehmatuse ja salasõnade vahetusega, kuid juhtumid, kus kurjategijad kasutavad kaaperdatud kontosid edasisteks pettusteks ning inimesed saavad olulist maine- ja rahalist kahju, pole sugugi harvad.

Lahendusi, kus kasutaja tuvastamine ei sõltu ainult ühest suhteliselt kergelt näpatavast salasõnast, on olemas küll – on riistvaralisel krüptograafial põhinevad lahendused (Eesti ID-kaart) ja on mitmeastmelisest autentimist kasutatavad lahendused. Ka Zone teenusportaalis saavad kasutajad ennast ID-kaardi või mobiil-ID abil tuvastada ning parooli kasutamise võimaluse üldse välja lülitada. Mitmeastmelisel autentimisel ei hakka ma lähemalt peatuma, sest RIA on oma blogis sellest pikalt kirjutanud [2] ning avaldanud ka juhised kuidas kaheastmelist tuvastus Gmailis [3] ja Facebookis [4] kasutusele võtta. Mitmeastmeline autentimine on praegu laialt saadaolevatest võimalustest parim kaitse kontode kaaperdamise vastu ning igaüks peaks seda võimalusel kasutama! Probleem on aga selles, et nendest sadadest teenustest, mida me iga päev kasutame, on mitmeastmelise autentimise kasutamine võimalik väga vähestel – minu aastate jooksul kogunenud ca 500-st kontost on sellised ainult 18. Seega kasutab rõhuv enamus kontosid kasutaja tuvastamiseks endiselt ainult salasõna. Miks?

Põhjuseid on päris palju, kuid olulisim sellest on kasutamise keerukus – nii teenusepakkujatele kui ka kasutajatele. IT arhitektide poolelt ma luban, et me oleme üle maailma juba joonestuslaudade taga ja kindlasti tuleme me välja paremate lahendustega, kuid me peame kuidagi ka sinnamaani hakkama saama. Kuidas on siis võimalik Internetis paroole kasutades ellu jääda? Erinevalt andmetel loetakse praegu turvaliseks juhuslikest sümbolitest salasõnu, mis on pikemad kui 16 sümbolit ning sama parooli kasutamine erinevates teenustes peaks olema täielikult välistatud. Kuidas need sajad paroolid meelde jätta? Ega see polegi võimalik ning lahendust pakuvad paroolihaldurid.

Paroolihaldur on tarkvara, mis hoiab kõiki su salasõnu krüpteeritud andmebaasis, mille kasutamiseks on vaja meeles pidada ainult üks (kuid siiski keeruline ja pikk!) salasõna. Moodsad paroolihaldurid abistavad sind kõiges, mis paroolide veebis kasutamist puudutab. Need aitavad sul turvalisi paroole genereerida, meeles pidada ning täidavad brauserite pluginate abil automaatselt sisselogimise vorme. Targemad paroolihaldurid tegelevad ka lekete info kogumisega ning hoiatavad kasutajat kui mõni nende parool on teenusepakkuja juurest Internetti lekkinud. Jah, paroolihaldurid pole ideaallahendus, need loovad omakorda uusi turvaprobleeme, kuid tõstavad latti siiski oluliselt kõrgemale ning on hetkel parim lahendus salasõnade kasutamiseks.

Ka paroolihaldurid on keerulisemad, kui üks laiatarbe turvalahendus olla võiks, kuid see pole raketiteadus – vähese õpetamise järel saavad kõik sellega hakkama. Kui te seda veel teinud pole, võtke kohe kasutusele LastPass [5] või mõni muu paroolihaldur (tundmatumaid asju soovitan siiski vältida). Tehke see selgeks endale ning õpetage ka abikaasale, lastele, vanematele ja sõpradele. Kuni IT-süsteemide arhitektid üle maailma parema süsteemi välja mõtlemiseks ajusid ragistavad, päästavad paroolihaldurid meid hullemast.

[1] http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/
[2] https://blog.ria.ee/multiautentimisest/
[3] https://blog.ria.ee/kaheastmeline-autentimine-gmail/
[4] https://blog.ria.ee/kaheastmeline-autentimine-facebook/
[5] https://www.lastpass.com/