Päivä alkoi kuitenkin poikkeuksellisesti, koska kaksi asiakastamme ilmoitti, että heidän sivustonsa eivät aukea normaalisti. Palvelinseurantamme mukaan sivusto kyllä vastasi normaalisti, mutta huomasimme, että sivusto yritti hakea javascript- ja css-tiedostoja poikkeuksellisesta osoitteesta.

Ymmärsimme nopeasti, että kyseessä on todennäköisesti tietoturvaloukkaus ja päivän suunnitelmat menivät uusiksi.

Miten hyökkäykseen reagoitiin?

Perustimme välittömästi toimistollemme tilannehuoneen ja kutsuimme kaikki asiantuntijat selvittämään tilannetta. Johto sekä asiakkuuspäälliköt ottivat vastuulleen tiedottamisen ja viestinnän asiakkaiden suuntaan. Tiedotimme asiasta Valun Twitter-tilillä ja olimme tiiviisti yhteydessä asiakkaisiin, joita asia koski. Kun tapaus oli selvitetty, teimme vielä saman päivän aikana myös ilmoituksen Kyberturvallisuuskeskukselle tietoturvaloukkauksesta.

Kävimme välittömästi hyökkäyksen huomattuamme läpi kaikki sivustot ja kartoitimme ongelman laajuuden hyödyntäen palvelinautomaatiotamme. Estimme heti liikenteen kuudelle sivustolle, joissa havaitsimme muutoksia. Yksi näistä osoittautui vääräksi hälytykseksi, mutta loput viisi olivat sellaisia, joissa hyökkäys oli vähintään osittain onnistunut.

Lokitiedostoja ja tehtyjä muutoksia analysoimalla paikansimme ongelman PublishPress Capabilities/Capability Manager Enhanced -lisäosaan, johon liittyvä hyökkäys oli ollut toista päivää käynnissä.

Ongelman laajuutta ylläpidossamme olevilla sivustoilla rajasi se, että olimme jo viisi vuotta sitten jättäneet lisäosan pois uusista projekteista, mutta ylläpidämme sitä niille asiakkaille, joiden sivustolla lisäosaa ei ole voinut korjata vaihtoehtoisella ratkaisulla.

Miten palautuminen hoidettiin?

Kun ongelman laajuus oli selvillä, selvitimme lokitiedostoista ajankohdan, jolloin ensimmäinen onnistunut muutos oli tapahtunut. Se ajoittui aikaan, kun haavoittuvuutta hyödynnettiin nollapäivähaavoittuvuutena ja paikkausta ei oltu vielä julkaistu.

Päätimme luoda uudet levyt viimeisimmästä puhtaasta varmuuskopiosta, paikata lisäosan, nollata salasanat varotoimenpiteenä ja palauttaa liikenteen sivustolle.

Olemme varmistaneet sivustomme tuplavarmuuskopioinnilla. Otamme varmuuskopion erilliseen palvelinsaliin vähintään 30 päivän ajalta ja teemme tämän lisäksi palvelimesta snapshotin seitsemän päivän ajalta.

Tässä tapauksessa nopein tapa oli palauttaa sivusto viimeisimmästä puhtaasta snapshotista ja tehdä tämän jälkeen paikkaus haavoittuvaan lisäosaan. Kun olimme sataprosenttisen varmoja, että sivusto on puhdas ja vastaavan hyökkäyksen tekeminen on estetty, sallimme liikenteen puhdistetulle palvelimelle noin neljän tunnin kuluttua siitä, kun se oli estetty.

Tämän jälkeen siirryimme analysoimaan tarkemmin hyökkääjän toimintaa ja mahdollisesti aiheutettuja vahinkoja.

Miten analysointi tehtiin?

Kun liikenne oli saatu palautettua, analysoimme lokitiedostojen avulla, miten hyökkäys oli edennyt ja mitä vahinkoja oli saatu aiheutettua.

Lokitiedostojen osalta on erittäin tärkeää tehdä lokitus palvelintasolla ja suojata lokit muutoksilta, koska esimerkiksi WordPressin tietokantaa käyttävä muutosloki on helppo poistaa. Tässäkin tapauksessa kattava palvelintason lokitus mahdollisti tapahtumien kulun selvittämisen nopeasti ja tarkasti.

Miten hyökkäys eteni?

Kyseessä oli automatisoitu hyökkäys, jonka tarkoitusperistä ei ole täyttä varmuutta, mutta selvästi pyrkimyksenä on ollut vahingoittaa mahdollisimman montaa sivustoa ja todennäköisesti kalastella käyttäjien tietoja.

Ensin hyökkääjä ohjasi kirjautumissivun kalastelusivulle

1. Tämän jälkeen hyökkääjä pyrki tekemään asetusmuutoksia siten, että uusien pääkäyttäjien rekisteröinti on mahdollista
2. Tämän jälkeen hyökkääjä yritti luoda uuden pääkäyttäjän ja kirjautumaan sillä sisään
3. Kun käyttäjä oli päässyt sisään, hän pyrki asentamaan haitallisen lisäosan ja ajamaan php-koodia WordPressin mediakirjaston hakemistossa

Missä hyökkääjä onnistui?

Hyökkääjä onnistui kaikissa tapauksissa tekemään muutoksen sivuston url-osoitteeseen ja ohjaamaan kirjautumissivun kalastelusivustolle.

Yhdessä tapauksessa hyökkääjä onnistui luomaan käyttäjän, mutta sen jälkeen hyökkäys pysähtyi suojausratkaisuihimme. Haitallisen lisäosan asentaminen epäonnistui, koska levylle kirjoittaminen ja lisäosien asentaminen Valun tuotantoympäristöissä on estetty ja kaikki päivitykset tehdään hallitusti ihmisen valvomana ja viedään hallitusti tuotantoon versionhallinnan kautta.

Tässä tapauksessa varmistimme lokitiedostojen avulla, että lomaketietoja tai käyttäjätietoja ei oltu manuaalisesti tarkasteltu. Emme löytäneet todisteita siitä, että käyttäjätietoihin, salasanatiivisteisiin tai muihin henkilötietoihin olisi päästy käsiksi. Vakiolokien lisäksi hyödynsimme analyysissä omaa palvelintason audit-lokiamme, johon tallennetaan WordPressin ylläpidossa suoritetut kriittiset toiminnot, kuten sisään- ja uloskirjautumiset, käyttäjien luominen ja poistaminen, lomakemerkintöjen tai käyttäjälistojen tarkastelu jne. Hyökkäys ei onneksi ollut kohdennettu ja tietoja ei oltu lähdetty keräämään manuaalisesti järjestelmään luodun käyttäjän avulla. 

Muissa tapauksissa hyökkäyksen onnistuminen jäi pelkkään asetusmuutokseen, koska käyttäjän luonti ei onnistunut multisite-ympäristössä. Näissä tapauksessa vahinko rajautui siihen, että joku sivuston ylläpitäjästä on voinut syöttää teoriassa salasanansa kalastelusivustolle. Tämän vuoksi kaikki salasanat vaihdettiin ja salasana ohjeistettiin vaihtamaan myös muihin palveluihin, joissa samaa salasanaa on mahdollisesti käytetty.

Selvityksemme perusteella hyökkääjä ei ole myöskään saanut pääsyä tietokantaan, palvelimelle tai palvelininfrastruktuuriin

Miksi näin pääsi käymään?

Miten näin pääsi käymään, vaikka asiakkaillamme on käytössä kaksinkertainen palomuuri, tunkeutumisenestojärjestelmä ja haavoittuvuuksia seurataan sekä paikataan aktiivisesti?

Seuraamme haavoittuvuusilmoituksia päivittäin ja saamme hälytykset sekä sähköpostiin että Slack-kanavallemme ja teemme tietoturvapäivitykset, kun haavoittuvuusilmoitus tavoittaa meidät.

Tällä kertaa seurannassa tapahtui inhimillinen virhe, koska olimme asentaneet lisäosan alunperin nimellä Capability Manager Enhanced, mutta haavoittuvuusilmoitus tuli lisäosan omistajan vaihtumisen vuoksi lisäosalle, jonka nimi oli PublishPress Capabilities.

Koska lisäosan nimi ei täsmännyt, emme alkaneet normaaliin toimenpiteisiin kriittisen tietoturvapäivityksen viemiseksi kaikille asiakkaillemme.

Tällä kertaa nopea päivittäminenkään ei olisi auttanut, koska haavoittuvuutta alettiin hyödyntämään jo noin vuorokausi ennen kuin korjaus oli saatavilla. Kyseessä oli siis ns. nollapäivähaavoittuvuus.

Nopea paikkaaminen olisi kuitenkin todennäköisesti pelastanut osan sivustoista onnistuneelta hyökkäykseltä.

Miksi emme käytä WordPressin automaattipäivityksiä?

WordPressin automaattipäivitykset voivat olla hyvä juttu henkilökohtaisen blogin ylläpitäjille, mutta hallitsematon päivitys kriittiselle verkkosivustolle ei ole hyvä toimintatapa. Käytännössä enterprise-sivustojen kohdalla poikkeuksetta edellytetään, että kaikki päivitykset testataan automatiikan lisäksi manuaalisesti ja versioidaan asianmukaisesti ennen tuotantopalvelimelle siirtämistä, sillä usein päivitykset vaativat muutoksia sivustolle eri lisäosien yhteensopivuuden varmistamiseksi. Hallitsematon päivitys voi pahimmassa tapauksessa aiheuttaa enemmän vahinkoa, kuin mitä automaattipäivityksellä pyritään paikkaamaan.

Lisäksi automaattipäivitykset vaativat, että tiedostojen muokkaus ja levylle kirjoittaminen olisi päällä tuotannossa, mikä käytännössä estää vahinkojen minimoimisen. Tässä tapauksessa se olisi tarkoittanut, että sivustolle olisi pystytty asentamaan haitallinen lisäosa. Lisäosan kautta hyökkääjä olisi saanut halutessaan myös täyden pääsyn tietokantaan ja voinut viedä kaikki henkilötiedot ja salasanatiivisteet kerralla lataamalla tietokannan. 

Jos sivustosi ylläpidosta löytyy valikko, jonka kautta voit asentaa uuden lisäosan, se tarkoittaa, että kukaan käytännössä ei vastaa sivustosi tietoturvasta ja tarjouspyynnössä pyytämäsi koodin versionhallinta ei ole käytössä. Tätä välilehteä ei tulisi löytyä tuotantosivustolta:

Automaattipäivitykset voivat myös toimia päinvastoin kuin ne on alunperin tarkoitettu. WordPressin lisäosahakemistossa on tullut vastaan tapauksia, joissa lisäosa on siirretty uudelle kehittäjälle, joka on lisäosan ylläpidon jatkamisen sijaan syöttänyt lisäosaan takaportin tai haittakoodin, joka on mennyt automaattipäivityksenä kaikille sivustoille.

Miten nopeista paikkauksista huolehditaan, kun automaattiset päivitykset eivät ole käytössä?

Vaikka Valun lisäosien päivitysprosessi on valvottu, olemme automatisoineet siitä erittäin tehokkaan asiakkaiden kustannusten säästämiseksi ja päivitysten nopean tuotantoon viemisen varmistamiseksi.

1. Kaikkien lisäosien versiot tarkistetaan joka yö ja päivitetään Githubiin
2. Yksittäisen lisäosan päivitykset siirretään projektien versionhallinnan päivitys-haaraan joka yö
3. Kun päivitystarve ilmenee, kehittäjä yhdistää automatiikan tekemät muutokset projektin lähdekoodiin ja suorittaa automaattiset ja manuaaliset testaukset

Testauksen jälkeen muutokset viedään valvotusti versionhallinnan kautta staging- ja tuotantosivustoille.

Pyrimme lisäosien päivityksissä 100% kattavuuteen ja jätämme mahdollisimman vähän asiakkaan oman aktiivisuuden varaan, koska sivuston tietoturvan kokonaisuus on yhtä hyvä kuin sen heikoin lenkki. Tästä syystä hankimme maksullisille lisäosille kehittäjälisenssit ja rakennamme lisäosalle automaattipäivitysmahdollisuuden, mikäli lisäosa ei valmiiksi tue automaattipäivitystä. Maksullisten lisäosien ja WordPressin lisäosahakemistosta löytyvien avoimien lisäosien lisäksi päivitämme myös Githubissa julkaistut avoimet lisäosat.

Mitä tulemme tekemään jatkossa toisin?

Olemme jo vieneet kaikille asiakkaillemme lisäsuojauksen, joka estää uusien käyttäjätilien rekisteröinnin sallimisen kaikissa tilanteissa.

Lisäksi tulemme automatisoimaan haavoittuvuuksien skannausta siten, että tietoturvatarkistus tehdään lisäosan alkuperäistä nimeä vasten, jolloin lisäosan omistajan vaihdoksesta johtuvat nimenmuutokset eivät vaikuta haavoittuvuuden huomaamiseen.

Mitä kaikki voivat oppia?

Jos tämä voi tapahtua yrityksessä, jossa tietoturva on yksi tärkeimmistä arvoista ja siihen panostetaan noin seitsemän prosenttia yrityksen liikevaihdosta, vastaava voi tapahtua kenelle tahansa.

Siksi haluamme jakaa muutaman vinkin, jotka auttavat varautumaan toimimaan vastaavissa tilanteissa:

1. Varaudu tietoturvaloukkaukseen ja suunnittele toiminta etukäteen, todellisessa tilanteessa ei ole aikaa harjoitella tai luoda työkaluja
2. Pidä riittävän pitkää palvelintason lokia sivuston käytöstä ja suojaa se muutoksilta
3. Varmuuskopioi usein ja kattavasti sekä testaa varmuuskopioiden palautusta säännöllisesti
4. Käytä palvelinautomaatiota, manuaalisesti on lähes mahdotonta selvittää nopeasti vahinkojen laajuutta tai viedä korjauksia kerralla kaikille asiakkaille
5. WordPressin lisäosahakemisto ei ole ”App Store”, johon joku on valinnut turvalliset ja käyttötarkoitukseen sopivat lisäosat. Kaikki lisäosat tulee auditoida ennen käyttöönottoa.
6. Älä aja WordPressiä ”kehitystilassa” tuotantosivustolla. Uusien lisäosien asentamisen ja lisäosien muokkaamisen ei pidä olla mahdollista tuotantoympäristössä.
7. Mediakirjaston (wp-content/uploads) hakemiston alta ei pidä pystyä suorittamaan php-koodia tai muuta ohjelmakoodia.
8. Ota tarpeettomat ominaisuudet ja rajapinnat pois käytöstä, jotta niitä ei voida kytkeä vahingossakaan päälle: WordPressin asennustiedostot, käyttäjien julkinen rekisteröintilomake, xmlrpc-rajapinta
9. Tarjoa käyttäjäarkistoista ja käyttäjiin liittyvistä rajapinnoista hyökkääjälle väärää tietoa (ns. hunajapurkki) ja estä ip-osoite, mikäli käyttäjätunnusta yritetään käyttää kirjautumiseen