WordPressi turvajutt algab tavaliselt pluginatest ja paroolidest. Uuendused peale, vanad kasutajad välja, failiskann käima. Täitsa õige, aga vahel tuleb rünnak hoopis korrus kõrgemalt.
Kui keegi saab kätte serveri halduspaneeli konto, ei pea ta WordPressi sisselogimisega üldse vaeva nägema. Sealt võib lisada SSH-võtmeid, vaadata varukoopiaid ja jõuda korraga mitme veebileheni. Väikese e-poe omanikule tundub see ehk kauge serveriteema, kuni selgub et ühe vana konto taga oli terve maja võtmekapp.
FlyWP juhtum on siin hea näide, mitte loo peategelane. Point on palju tavalisem: ligipääs, mida enam kellelgi vaja ei olnud, jäi alles.
Mis augustis tegelikult juhtus?
FlyWP avaldas 29. augustil oma ametliku juhtumikirjelduse. Ettevõtte sõnul avastati rünnak 6. augustil ning see puudutas enam kui 700 kliendiserverit.
Ründaja kasutas endise töötaja administraatorikontot, mis oli pärast inimese lahkumist aktiivseks jäänud. Selle kontoga sai kliendiserveritesse SSH-võtmeid lükata. Ehk WordPressi parooli polnud tarvis ära arvata – serverisse tekkis uus otsetee.
Siin tuleb fakt ja oletus lahus hoida. Täpset viisi, kuidas ründaja endise töötaja kasutajatunnused kätte sai, pole teada. See võis olla andmepüük, lekkinud parool või varastatud seanss, aga FlyWP pole meetodit kinnitanud. Kinnitatud jama oli aktiivne konto koos väga laiade õigustega.
Jälgede seas olid uued SSH-võtmed, WordPressi administraatorid, peidetud pluginad ja PHP-failid, mille kaudu sai eemalt käske käivitada. Tehti ka otsingukloakingut – otsingumootor nägi üht sisu, päris külastaja teist. See pole lihtsalt soditud avaleht. Pigem mitu varuust, et hiljem tagasi tulla.
Varukoopia lekkis teist teed pidi
Samas loos oli veel üks, eraldi ligipääsutee. Turunduse taristu hoidis Cloudflare R2 andmeid, millega sai lugeda tootmiskeskkonna andmebaasi varukoopiat. Ründaja sai need andmed kätte ja laadis varukoopia alla.
Saladused olid varukoopias eraldi krüpteeritud ning dekrüpteerimisvõtmeid ei hoitud samas kohas. FlyWP ei leidnud tõendeid, et ründaja oleks need lahti krüptinud. Hea. Aga allalaaditud tootmisandmebaas ei muutu seetõttu ohutuks failiks, mille võib lihtsalt ära unustada.
Praktikas tähendab see vähemalt kolme asja:
- varukoopias olnud ligipääsuandmed tuleb vahetada;
- kontrollida tuleb süsteeme, kuhu nende andmetega pääses;
- turunduslehel ei peaks olema laia lugemisõigust tootmise backup’idele.
Just viimane koht kipub ajaga käest minema. Kunagi oli mingit ühendust vaja, inimene vahetus ja keegi ei mäleta enam, miks võti seal üldse on.
Halduspaneel on sisuliselt peavõti
Väikeettevõtte jaoks on veebimajutus tihti lihtsalt arve, mis kord aastas meilile tuleb. Tegelikult saab moodsa halduspaneeliga luua lehti, muuta serveri seadeid, avada paroolita sisselogimisi, hallata varukoopiaid ja lisada SSH-võtmeid. Korralikult hallatud WordPressi veebimajutus peab seepärast jälgima ka neid uksi, mitte ainult wp-admini.
Kui töötaja, agentuur või arendaja lõpetab, vaata samal päeval üle:
- majutuse, pilveteenuse, DNS-i ja CDN-i kontod;
- SSH-võtmed, serveri kasutajad, SFTP ja juurutustokenid;
- WordPressi administraatorid, seansid ja rakenduseparoolid;
- backup’i hoidla, jagatud paroolihoidla ja API-võtmed;
- SMTP, makselahendused ning ajutised sisselogimislingid.
WordPressi kasutaja kustutamine on ainult üks rida sellest nimekirjast. SSH-võti jääb serverisse edasi, kui keegi seda eraldi ei eemalda. Sama lugu pilvekonto või jagatud parooliga.
Kui ligipääse peab jagama, siis tee seda nimeliste kontodega ja pane kohe paika ka eemaldamise hetk. Kirjutasime sellest pikemalt loos, kuidas anda arendajale ligipääs kontrolli kaotamata. Ausalt öeldes on lahkuja õiguste sulgemine üsna igav töö. Aga just igav töö hoiab sellised jamad ära.
Puhastamine algab kaardist, mitte Delete-nupust
Kui ründajal oli SSH-ligipääs, ei tõesta puhas WordPressi pluginavaade suurt midagi. Faile saab muuta otse, peidetud laaduri panna mu-plugins-kausta ja ajastatud ülesandega pahavara uuesti tagasi tuua. Mõni asi ei paista WordPressi töölaual mitte kuskilt.
Nii et koigepealt hetktõmmis. Serveri seis, andmebaas, logid ja failide ajatemplid tuleb säilitada enne, kui hakata kahtlasi faile hoogsalt kustutama. Muidu võib oluline jälg kaduda ja algne sissepääs jääb ikka lahti.
Meie tööjärjekord on sellise juhtumi puhul pigem see:
- kaardista võõrad kasutajad, SSH-võtmed ja muud ligipääsud;
- vaata läbi WordPressi administraatorid, seansid ja andmebaas;
- kontrolli croni,
mu-plugins-kausta, drop-in-faile, ümbersuunamisi ja muudetud PHP-faile; - asenda WordPressi tuum sama versiooni puhta koopiaga ning paigalda kataloogipluginad uuesti;
- kontrolli käsitsi teemasid, premium-pluginaid ja muud, mida puhta pakiga asendada ei saa;
- pärast puhastamist vaheta SSH-, andmebaasi-, WordPressi-, API-, SMTP- ja makselahenduse andmed.
See on põhjus, miks häkitud WordPressi puhastamine pole ühe skanneri raport. Serverikiht ja WordPressi kiht tuleb mõlemad läbi vaadata. Kui sama paneeli all on viis kodulehte, kontrollitakse kõiki viit, mitte ainult seda kus rämps esimesena silma jäi.
Backup võib vana nakkuse tagasi tuua
Varukoopia olemasolu on hea algus, mitte taastamisplaan. Kui koopia tehti pärast ründaja sisenemist, võib seal sees olla peidetud plugin, võõras admin, pahatahtlik andmebaasikirje või PHP tooriist, mis käske käivitab.
Taastad selle pimesi ja oled mõne tunni pärast samas kohas tagasi. Või taastad vanema puhta koopia, aga jätad serverisse ründaja SSH-võtme. Tulemus on sisuliselt sama.
Enne taastamist võrdle koopia kuupäeva teadaoleva ründeajaga ning kontrolli failide, andmebaasi ja kasutajate seisu. Proovi taastamist eraldi keskkonnas. Pärast vaheta kõik võtmed ja paroolid, milleni ründaja võis jõuda.
Ja testi, et taastatud e-pood päriselt töötab – tellimine, maksed, kirjad ja administraatori ligipääs. Failide lahtipakkimine ilma kontrollita pole taastamine, see on lootus.
Mida teha täna, kui sul on tavaline koduleht?
Sa ei pea õhtul Linuxit õppima ega haldusteenusest loobuma. Pigem küsi oma majutajalt või arendajalt kolm lihtsat küsimust: kellel on praegu paneeli- ja SSH-ligipääs, kuidas eemaldatakse lahkunud inimeste kontod ning milline süsteem saab lugeda varukoopiaid?
Kui vastus on “peaks vist korras olema”, palu teha ligipääsuaudit. Pane kontode omanikud kirja ja määra, kes need sulgeb. Moni vana konto võib olla täiesti süütu, aga seda pole mõtet niisama avatuna hoida.
Ära oota ka ainult majutaja automaatset teadet. Meie varasem näide selgitab, miks hostingu pahavarahoiatus tuleb sageli hilja. Uus SSH-võti, peidetud plugin või võõras admin võib selleks ajaks juba päevi kohal olla.
Vaata, WordPressi parool on üks uks. Halduspaneel, server, varukoopiad ja pilvekonto on teised. Kui üks peavõti lekib, säilita esmalt seis, kaardista kõik kihid, kontrolli backup’e ning alles siis puhasta ja vaheta ligipääsud. Natuke tüütu. Palju odavam kui teine ring sama ründajaga.