Veebileht häkitud? Kui WordPress hakkab võõraste uste taga käima

Sinu veebileht peaks tutvustama teenuseid, tooma päringuid ja aitama müüa. Ühe WordPressi lehe tööülesannete nimekiri oli aga omaniku teadmata pikenenud: teiste serverite skaneerimine ja pahatahtlike skriptide käivitamine.

Keegi oli end tööle võtnud. Palka ei küsinud, aga kahju oskas teha küll.

Häkitud veebileht võib pealtnäha täiesti normaalne välja näha. Logo on paigas, teenuste tekstid alles ja kontaktivorm ootab päringuid. Kapoti all võib samal ajal toimuda midagi hoopis muud.

Selles juhtumis märkas kahtlast tegevust veebimajutaja. Ühes sulgemisteates kirjeldas tehnik olukorda numbriga, mis pani kulmu kergitama: virtuaalserverist oli tehtud poole tunniga ligi 700 000 väljuvat ühendust. Samal ajal töötasid serveris pordiskanneri skriptid.

Ei, need polnud uued kliendid.

Veebilehe omanikuna ei pea sa ise serverisse detektiivi mängima minema. Küll aga tasub teada, milliseid ohumärke tähele panna ja miks ühe kahtlase faili kustutamine ei tähenda veel, et probleem on lahendatud.

Selles artiklis vaatame ühe päris juhtumi põhjal, mida ründaja serveris tegi, kuidas me pahavara eemaldasime ja mida tuli teha selleks, et veebilehed taas turvaliselt tööle saada.

Veebileht karantiinis: mida veebimajutaja sulgemisteade tähendas?

Veebimajutaja piiras veebilehele ligipääsu, sest serveris oli tuvastatud kompromiteerumisele viitav tegevus. Tehniku kommentaarist selgus, et serveris töötasid mitmed pordiskanneri skriptid.

Pordiskanner uurib, millised võrguteenused teistes arvutites või serverites vastavad. Selles juhtumis oli see osa ründaja tööriistakomplektist.

Lihtsamalt öeldes: sinu veebileht peaks kliente vastu võtma. See oli hakanud hoopis võõraste uste taga linke logistama. Halloween, aga mitte 31. oktoobril.

COVID-19 ajast on karantiini mõte kõigile tuttav. Nagu nublu laulus: "tuli mingi viirus, kõigil hakkas puhkus". Veebilehe viirusega läheb paraku vastupidi, veebihalduril tuleb puhkuse asemel rindele minna. Õnneks naise ja lapsega hüvasti jätma ei pea.

Veebimajutaja piiras veebilehele ligipääsu .htaccess-faili kaudu. Veebileht sai sisuliselt karantiini, kuid karantiin ja terveks saamine pole üks ja sama. Külastajatele suletud veebilehe taustal võivad pahatahtlikud protsessid endiselt töötada.

Omanik ei pidanud ise koodiga lahingusse astuma. Meie ülesanne oli välja selgitada, mis kulisside taga toimub, eemaldada pahavara, sulgeda ründaja ligipääsud ning koostöös veebimajutajaga veenduda, et oht on kõrvaldatud.

Veebilehel on viirus. Aga mida see tegelikult tähendab?

Kõnekeeles nimetatakse veebilehe pahavara sageli viiruseks. Tegelikult võib selle sõna taga olla mitu eri probleemi: võõras kood, varjatud ligipääsud, muudetud failid või automaatselt käivituvad pahatahtlikud skriptid.

Sama veebimajutuskonto all töötas kokku kaheksa WordPressi veebilehte, millest ainult kolm olid ajakohased. Ülejäänud viis olid pikalt uuendamata. Kuna veebilehed kasutasid sama serverikontot, võis ühe nõrga veebilehe kaudu avaneda ligipääs ka teiste failidele.

Seetõttu tuli uurida kogu keskkonda, mitte ainult ühte veebilehte. Etteruttavalt öeldes meenutas serveriruum Berghaini klubi hommikul kell neli.

Uurimise käigus leidsime järgmist:

Viimane leid oli eriti murettekitav. Kui ründajal oleks õnnestunud saada serveris kõrgemad õigused, võinuks ohtu sattuda ka teised samas serveris asuvad kliendid.

Samuti ei õnnestunud esialgu kindlaks teha, kuidas ründaja serverisse pääses. WordPressi logidest ei leitud võõraid edukaid sisselogimisi, kuid see ei välistanud mõne haavatava plugina või serveritarkvara turvaaugu kasutamist.

Üks kahtlane fail leiti näiteks Akeeba plugina kaustast. See aga ei tõestanud, et just selle plugina kaudu sisse murti. Kahtlusalune ja süüdlane on kaks eri asja. Ka WordPressis.

Kustutad faili. Fail tuleb tagasi. Nagu oleks Rannamaja Inception'isse kinni jäänud.

Suur osa tööst kulus failide ja kaustade läbivaatamisele. Tuli eristada ründaja tööriistu veebimajutuskeskkonna failidest, pluginate komponentidest ja täiesti tavalistest ajutistest failidest.

Kõik imeliku nimega failid ei ole pahavara. Kõik tuttava nimega failid ei ole puhtad.

Eemaldasime tuvastatud veebishelle, tagauksi ja pahatahtlikke seadistusi. Kontrollisime andmebaase, ajastatud ülesandeid ning WordPressi faile.

Aga koristamise ajal tekkis pahavara juurde.

See näitas, et ründaja ligipääs või tema käivitatud automaatika töötas endiselt. Veidi nagu väikese lapsega: saad ühe toa korda, teises on mänguasjakast juba uuesti põrandale kallatud.

Uurimise käigus selgus, et osa pahatahtlikest andmebaasitabelitest loodi automaatselt uuesti. Lisaks oli ründaja muutnud PHP seadistusi ja loonud eraldi käsukanali, mis võimaldas serveris käske käivitada.

Pahavara eemaldamine ja selle tagasituleku takistamine on kaks eraldi tööd. Seetõttu ei piisanud ainult kahtlaste failide kustutamisest. Tuli kõrvaldada ka nende taastamise mehhanismid ja sulgeda ründaja võimalikud ligipääsuteed.

Et saaksime veebilehtede töökindluses ja turvalisuses veenduda, võtsime ette põhjalikuma puhastuse:

• Asendasime kõik WordPressi põhifailid puhaste originaalfailidega, et eemaldada võimalikud muudatused WordPressi enda koodis.
• Asendasime pluginad puhaste versioonidega, et pahatahtlik kood ei jääks peitu mõne tuttava plugina kausta.
• Kontrollisime ja puhastasime andmebaasid, eemaldades pahatahtlikud kirjed ja tabelid ning nende taastamise mehhanismid.
• Vahetasime välja kõik olulised paroolid ja ligipääsuandmed, sealhulgas WordPressi kasutajate, FTP-kontode ja andmebaasikasutajate omad. Uuendasime ka SSH võtmed.
• Kontrollisime serveri seadistusi ja automaatseid ülesandeid, et ründaja ei saaks eemaldatud pahavara uuesti käivitada.

Kuna sama veebimajutuskonto all töötas mitu WordPressi veebilehte, tuli kontrollida kogu keskkonda. Ühe veebilehe puhastamisest pole palju kasu, kui ründajale jääb mõne teise kaudu tagauks lahti.

Pärast puhastamist vaatas veebimajutaja konto omalt poolt üle ja kinnitas, et kõik on korras.

Seekord ei piirdunud koristamine prügikasti tühjendamisega. Tuli veenduda, et keegi ei saaks seda salaja uuesti täita.

Kuidas aru saada, et veebileht võib olla häkitud?

Veebilehe omanik ei näe tavaliselt serveri taustaprotsesse ega tea, mis seal parasjagu toimub. Esimene vihje probleemist võib tulla veebimajutajalt, kliendilt või hoopis brauseri hoiatusest.

Meie juhtumis andis häirekella veebimajutaja, kes märkas serveris ebatavalist tegevust. Alati aga nii hästi ei lähe ning mõnikord tuleb probleem välja alles siis, kui kliendid hakkavad kahtlastest asjadest teada andma.

Millistele ohumärkidele tasub tähelepanu pöörata?

Muidugi ei tähenda aeglane veebileht automaatselt häkkimist. Ka katkine plugin, serveri ülekoormus või mõni tehniline viga võib põhjustada sarnaseid sümptomeid.

Täpselt nagu kerge köha ei tähenda veel, et sul on kopsupõletik. Muidugi ei ole siin nüüd meest, kes vastu ei vaidleks...

Samas tasub meeles pidada, et veebilehe tavapärane toimimine ei tähenda alati, et kõik on korras. Ründajal pole kohustust endast avalehel teada anda.

Mida veebilehe omanik tegema peaks?

Kui selgub, et sinu veebileht võib olla häkitud, on esimene soov tavaliselt probleem võimalikult kiiresti ära lahendada. Eriti siis, kui veebilehe kaudu tulevad päringud või toimub müük.

Aga enne, kui hakkad ise kahtlaseid faile kustutama või suvalist varukoopiat taastama, tasub kaasata inimesed, kes oskavad probleemi ulatust hinnata.

1. Edasta veebimajutaja teade veebihaldajale

Kui veebimajutaja saadab hoiatuse, edasta veebihaldajale terve kiri. Ka tehnilised detailid, mis esmapilgul midagi ei ütle, võivad probleemi lahendamisel väga kasulikud olla.

Näiteks meie juhtumis aitasid väljuvate ühenduste arv ja pordiskannerite mainimine mõista, mis serveris toimus.

Kui märkad probleemi ise või klient annab sellest teada, pane kirja:

• Mida märkasid või millest klient teatas?
• Millisel veebiaadressil probleem esines?
• Millal probleemi märgati?
• Kas sul on ekraanipilt või veateade?

Sellest piisab alustamiseks. Paroole pole vaja esimese kirjaga kaasa saata.

2. Kaasa nii veebimajutaja kui ka veebihaldaja

Veebimajutaja näeb serveris toimuvat ja saab vajadusel ligipääsu piirata. Veebihaldaja tunneb veebilehe ülesehitust, pluginaid ja tavapärast toimimist.

Tõsisema juhtumi lahendamine võib vajada mõlema panust. Meie juhtumis piiras veebimajutaja veebilehele ligipääsu, meie tegelesime pahavara eemaldamise ja keskkonna puhastamisega. Pärast tööde lõpetamist kontrollis veebimajutaja konto omalt poolt üle.

Nii ei jää veebilehe omanik kahe osapoole vahele, kus üks ütleb, et nende poolt on kõik korras, ja teine alles uurib, miks pahavara tagasi tekib.

3. Lepi kokku puhastamise ja taastamise järjekord

Soov veebileht kiiresti uuesti tööle saada on täiesti arusaadav. Aga kiirustades võib probleemi hoopis tagasi tuua.

Näiteks võib juhusliku varukoopia taastamine tuua koos veebilehega tagasi ka pahavara. Kui ründaja kasutatud turvaauk või tagauks jääb alles, võib sama probleem peagi korduda.

Seetõttu tuleks enne taastamist välja selgitada, millised failid ja varukoopiad on usaldusväärsed, millised ligipääsud vajavad uuendamist ning mida tuleb teha enne veebilehe uuesti avamist.

Nupp "Taasta" võiks tähendada taastamist, mitte sama jamaga uut hooaega.

Millal saab öelda, et veebileht on jälle korras?

Avalehest üksi selleks ei piisa.

See, et veebileht avaneb ja kontaktivorm töötab, ei tähenda veel, et kogu keskkond on turvaline. Eriti siis, kui ründaja on jätnud endast maha mitu tagaust ja pahavara automaatselt taastavaid mehhanisme.

Meie juhtumis oli veebimajutaja kinnitus konto puhastamise kohta oluline verstapost, kuid sellega taastamistööd veel ei lõppenud.

Lõpuks asendasime kõik WordPressi põhifailid ja pluginad puhaste versioonidega, kontrollisime ja puhastasime andmebaasid ning uuendasime kõik ligipääsuandmed, sealhulgas kasutajate paroolid, FTP-kontod, andmebaasikasutajad ja SSH võtmed.

Eesmärk oli veenduda, et eemaldatud poleks ainult nähtav pahavara, vaid ka võimalused, mille kaudu ründaja saaks uuesti tegutsema hakata.

Üks küsimus jäi siiski õhku: kuidas ründaja algselt serverisse pääses?

Uurimise käigus tuvastasime mitu võimalikku sisenemisteed, kuid ühtegi neist ei saanud olemasolevate andmete põhjal lõplikult kinnitada. See on oluline ka edaspidise turvalisuse seisukohalt, sest tundmatu sisenemistee korral ei saa täielikult välistada sama probleemi kordumist.

Veebilehe omanikuna tasub pärast sellist juhtumit küsida nelja asja:

• Mida leiti ja millised veebilehed olid mõjutatud?
• Milline pahavara eemaldati ja kuidas ründaja ligipääsud suleti?
• Kas kõik vajalikud taastamis- ja turvauuendused on tehtud?
• Kuidas edaspidi kontrollitakse, et probleem ei korduks?

Vastus ei pea olema kümme lehekülge serverilogisid. Küll aga peaks sellest aru saama, mis juhtus, mida parandati ja millises seisus veebilehed praegu on.

Päris lõpuni ei saa ühtegi veebilehte tulevaste rünnakute eest kindlustada. Küll aga saab teha kõik selleks, et sama külaline ei pääseks järgmisel päeval uuesti tagauksest sisse.

Kas häkitud veebileht mõjutab ka SEO-d?

Jah, võib mõjutada. Kui külastaja jõuab sinu teenuselehe asemel võõrale veebilehele või näeb turvahoiatust, kannatavad nii usaldus kui ka võimalus päringut saada.

Google võib turvaprobleemidega veebilehtede puhul näidata otsingutulemustes või brauseris hoiatust. Tuvastatud probleeme saab kontrollida Google Search Console'i turvaprobleemide aruandest.

Meie juhtumis ei leidnud me SEO-spämmi ega pahatahtlikke ümbersuunamisi. See aga ei tähenda, et pärast pahavara eemaldamist võiks veebilehe nähtavuse kontrollimata jätta.

Pärast puhastamist tasub üle vaadata:

• Kas kõik olulised teenuse- ja tootelehed töötavad?
• Kas veebilehele pole lisatud võõrast sisu või ümbersuunamisi?
• Kas Google Search Console näitab turvaprobleeme?
• Kas Google'i tuvastatud probleemide lahendamise järel on vaja taotleda uut ülevaatust?

Kui Google on veebilehel turvaprobleemi tuvastanud, tuleb enne uut ülevaatust veenduda, et probleem on kogu veebilehel lahendatud. Ühe näidislehe korrastamisest ei piisa.

SEO peale kulutatud aeg ja raha väärivad seda, et veebileht püsiks ka tehniliselt korras. Ründaja kasiinolingid pole ilmselt sinu järgmise kvartali sisustrateegia.

Mida sellest juhtumist õppida?

Selle juhtumi kõige olulisem õppetund oli lihtne: veebilehe turvalisus ei sõltu ainult ühest pluginast või tugevast paroolist. Kui sama veebimajutuskonto all töötab mitu veebilehte, tuleb hoolitseda nende kõigi eest.

Turvaplugin üksi ei päästa. See võib aidata ohte tuvastada ja mõningaid rünnakuid takistada, kuid ei asenda regulaarseid uuendusi ega turvalisi ligipääse. Ka vana kampaanialeht või unustatud testveeb võib muutuda nõrgaks lüliks. Veebileht, mida keegi enam ei külasta, ei muutu sellest automaatselt turvaliseks.

Häkitud veebilehte ei pea alati nullist uuesti ehitama. Meie juhtumis õnnestus veebilehed taastada, asendades WordPressi põhifailid ja pluginad, puhastades andmebaasid ning uuendades kõik ligipääsud. Oluline on hinnata kahjustuse ulatust ja veenduda, et taastamiseks kasutatavad failid ning andmed on usaldusväärsed.

Kõige parem kaitse on järjepidev hooldus. WordPress, pluginad ja muu serveritarkvara vajavad uuendamist. Kasutamata kontod ja pluginad tuleks eemaldada, paroolid peavad olema unikaalsed ning võimalusel tasub kasutada kaheastmelist autentimist. Samuti peaks olema selge, kes vastutab varukoopiate, uuenduste ja turvahoiatustele reageerimise eest.

Kõige tähtsam on, et hooldus päriselt toimuks. Keegi vist tegeleb, pole eriti tugev turvameede.

Veebilehe omanik ei pea ise pahatahtlikku koodi lugema ega serveri seadistustes orienteeruma. Küll aga tasub probleemidele kiiresti reageerida ja kaasata inimesed, kes oskavad olukorra lahendada.

Kui sinu veebileht teeb asju, mida sa pole tellinud, kirjuta Ballersile. Lisa veebimajutaja teade või kirjelda, mida märkasid. Vaatame, mis toimub ja millest alustada.