Miten ison digitoimiston ylläpito reagoi, kun php2shell-haavoittuvuuden vakavuus alkoi selvitä – haastattelussa Tiia Ohtokallio

Vanhaa sanontaa mukaillen, on vain kahdenlaisia internet-sivustoja: niitä joihin on murtauduttu ja niitä jotka eivät tiedä tulleensa murretuiksi.

Viime viikolla tästä ikävästä todellisuudesta saatiin maistiaisia, kun internetin yksi peruskivi, eli PHP-ohjelmointikieli, julkaisi tiedon vakavasta haavoittuvuudesta. Tieto tuli aamulla ja päivitys luvattiin julkaista iltapäivällä klo 17.00. Tietoa saatiin lisää pitkin päivää, ja tämän perusteella Suomessakin suljettiin valtava määrä sivustoja, koska pelättiin laajaa tietomurtojen aaltoa. Esimerkiksi valtionhallinnossa suljettiin sivustoja erittäin laajasti, vaikka suurin osa näistä suljetuista sivustoista ei edes käyttänyt pääjärjestelmänään PHP:hen pohjautuvia järjestelmiä. Kyse oli siis poikkeuksellisen vakavasta haavoittuvuudesta, jonka kohdalla otettiin käyttöön raskaita suojaustoimia.

Tilanne oli erityisen haastava sellaisille toimistoille, joiden ylläpidossa on satoja, jopa tuhansia sivustoja. Käytännössä kaikki sivustot oli käytävä läpi ja arvioitava päivitystarpeet, ja sen jälkeen päivitykset piti ajaa mahdollisimman nopeasti.

Hion on yksi Suomen suurimpia WordPress-toimittajia, joten on kiinnostavaa kuulla, miten päivä eteni heidän sisäisessä päätöksenteossa ja kuinka sulkemispäätökseen päädyttiin, ja ehdittiinkö kaikkien asiakkaiden kanssa edes keskustella asiasta.

Kuten Tiia Ohtokalliokin toteaa haastattelussa, tällaiset kriisit saattavat olla uusi normaali verkkosivustojen ylläpitäjille. Tekoäly tehostaa haavoittuvuuksien löytämistä ja monet internet-sivustot ja -sovellukset ovat luonteeltaan haavoittuvia, koska nojaavat usein lukuisiin erilaisiin kirjastoihin ja komponentteihin, ja pääsyn rajaaminen ei aina ole mahdollista samalla tavalla kuin joissain yritysten sisäisissä sovelluksissa ja järjestelmissä.

Asiakkaiden kannalta tämä uusi todellisuus korostaa entisestään ylläpitopalvelun laatua. Mitä kriittisempi sivusto, verkkokauppa tai sovellus, sitä tärkeämpää on maksaa jollekin osaavalle kumppanille sen ylläpidosta ja päivityksistä.

Nykyisin ylläpitopalveluiden reaktio- ja korjausajat ovat myös relevantteja pienemmille asiakkaille, koska jos tällaisia vakavia haavoittuvuuksia alkaa olemaan usein, ei voi enää odotella viikkoa tai paria päivitysten ajamista. Vierityspalkissakin on laadukkaiden ylläpitopalveluiden puolesta puhuttu vuosien ajan.

Esimerkiksi freelancereiden ja pienten toimistojen vahvuuksia eivät aina ole nämä ylläpitoasiat, joten joskus kannattaa käyttää kolmansia osapuolia palvelun perusylläpidon hoitamiseen tai sitten suosiolla valita isompi toimisto. Suomessakin moni toimisto nojaa esimerkiksi Seravon ja vastaavien toimijoiden palvelinympäristöihin, jolloin vastuu on jaettu hosting-tarjoajan ja digitoimiston välillä. Tällainenkin malli voi olla aivan toimiva, olennaista on miten reagointi toimii käytännössä.

Usein isommilla toimistoilla on ympäristöt kuitenkin enemmän omissa käsissä, kuten on asia Hionillakin, jonka reagointia tämä haastattelu käsittelee. Tekniset ympäristöt ja päivitykset hoituvat siis täysin Hionin oman ylläpitoyksikön toimesta.

Haastattelussa Hion Digitalin Tiia Ohtokallio avaa sitä, miten Hion reagoi tähän viimeisimpään kriisiin ja kuinka heidän ylläpidossaan toimivat palvelut päivitettiin.

1. Palataan siihen aamuun, kun tieto php2shell-haavoittuvuudesta saavutti teidät – mitä kanavaa pitkin tieto tuli ja mikä oli ensimmäinen konkreettinen asia, jonka teit sen jälkeen?

Tieto php2shell-haavoittuvuudesta tuli meille keskiviikkoaamuna tiimin sisältä. Kehittäjä nosti uutisen Slackiin, ja toinen liitti perään PHP:n tietoturvatiimin virallisen ennakkoilmoituksen, jonka mukaan iltapäivällä julkaistaan korjaus kahteen kriittiseen haavoittuvuuteen. Meillä on myös virallisia seurantakanavia eri lähteistä, mutta niiden kautta tieto on tyypillisesti tullut vähän hitaammin.

Ensimmäiseksi selvitimme tiimin kanssa, kuinka nopeasti saamme omat sisäiset tekniset toimet tehtyä, kun korjaus julkaistaan. Meillä on muutamia erilaisia ympäristöjä WordPress-asennuksia varten, jokaiseen päivityksiä tehdään eri tavalla, joten tämä vaatii aina valmistelua. Tässä rinnalla käynnistettiin sisäinen tiedotus eri sidosryhmille: johto, esihenkilöt, asiakasvastaavat, jotta kaikki tietää minkä parissa todennäköisesti valtaosa tiimistä tulee aikansa viettämään.

Samalla päätimme, ettemme jää odottamaan iltapäivää, vaan alamme heti asentaa väliaikaisia suojauksia eli mitigaatioita kaikkiin ylläpitämiimme ympäristöihin varmuuden vuoksi. Haavoittuvuudet pidetään yleensä salassa (embargo), mutta ei se epätavanomaista ole että päivitykset ja proof-of-concept -toteutukset vuotaa etukäteen, oli mahdollisuus että tämä saattaa eskaloitua nollapäivähaavoittuvuudeksi. Nollapäivähaavoittuvuus (zero-day vulnerability) tarkoittaa tietoturva-aukkoa, jolle ei ole vielä ehditty julkaista korjauspäivitystä.

Asiat etenivät meillä sisäisesti nopeasti. Puolen tunnin sisällä aamun aikana johto oli tietoinen tilanteesta, kehittäjät olivat saaneet ohjeet ja asiakkuusvastaavat tiesivät, että asiakastiedote on tulossa. Aamulla tehty alkuperäinen suunnitelma oli tehdä tarvittavat toimet jotta päivityksiä päästään tekemään heti klo 17 ja niitä tehdään se mitä tehdään ja jatketaan aamulla. Tilanne ei ollut vielä kriittinen, koska ajateltiin että mitigaatiot toimivat hidasteena mahdollisessa hyökkäyksessä.

2. Mitä nämä alkuvaiheen väliaikaiset suojaukset eli mitigaatiot käytännössä olivat, ja miksi ne vaikuttivat aluksi riittäviltä?

Php2shell-haavoittuvuuden väliaikaiset suojaukset olivat PHP:n ja palvelinympäristön asetusmuutoksia, joilla suljettiin tunnetut hyökkäyspolut ennen varsinaista korjausta. Käytännössä estimme Hionin ylläpitämillä WordPress-sivustoilla muun muassa tiedostojen latauksen edistymisseurannan ja palvelinpään multipart-pyynnöt, eli tiedostolataukset ja lomakkeiden lähetykset. Muutokset vietiin keskitetysti konttipohjaisten ympäristöjen pohjaimageihin ja projektikohtaisesti eri alustoille. Aamupäivän tiedon perusteella niiden piti pienentää riskiä merkittävästi siihen asti, kunnes PHP:n korjaus on asennettu. Tämä tarkoitti myös sitä, ettei sivustoille voinut hetkeen ladata kuvia, ja tästä tiedotimme asiakkaita.

Käytännössä suljimme ainoan tuolloin tunnetun hyökkäystavan eli estimme tiedostolatausten edistymisseurannan ja multipart-pyynnöt. Tiesimme kuitenkin, että haavoittuvuuksia oli kaksi ja että muita hyökkäyspolkuja saattoi olla, joten pelkkien mitigaatioiden varaan ei uskallettu jättäytyä.

Keskiviikko oli kaikin puolin kiireinen muun asiakastyön osalta. Puolen päivän jälkeen kävi ilmi, että embargo oli käytännössä rikkoutunut, tiedot haavoittuvuudesta olivat laajalti tiedossa verkossa.

Aloimme kasaamaan lyhyellä varoitusajalla incident response -iltatiimiä, joka jäisi ylitöinä tekemään päivityksiä ja monitoroimaan asiakkaiden palveluita.

3. Kuvaile se hetki ja ne signaalit, joiden perusteella ymmärsitte, että mitigaatiot eivät riitä ja kyse on nollapäivästä – mikä muutti tilannekuvan?

Keskiviikkona puolenpäivän jälkeen alkoi tulla tietoa, että php2shell-haavoittuvuuden hyödyntämiseen oli jo olemassa tunnettu tapa, vaikka PHP:n korjausta ei ollut vielä julkaistu. Samaan aikaan PHP:n kehittäjäpiireistä ja tietoturvayhteisöstä tuli yhä selvempi viesti, että ainoa todellinen suoja on päivittäminen ja aamulla asentamamme väliaikaiset suojaukset vain pienentävät riskiä. Siinä kohtaa tilanne muuttui ennakoitavasta päivityksestä nollapäiväksi. Annoimme tiimille ohjeen, että suojausten asentaminen menee kaiken muun asiakastyön ja palaverien edelle, asiakastapaamisia peruttiin ja aloimme valmistella palveluiden alasajoa.

4. Kun raportoit johdolle, että ollaan nyt vakavan asian äärellä, millä sanoilla ja millä tiedoilla kehystit tilanteen niin että päätöksiä pystyttiin tekemään nopeasti?

Kun php2shell-tieto tuli keskiviikkoaamuna, raportoin Hionin johdolle lyhyesti neljä asiaa:

1. haavoittuvuus on erittäin vakava (CVSS 9.2/10, samaa luokkaa kuin kesän wp2shell),
2. korjaus tulee iltapäivällä klo 17,
3. hyökkäysten odotetaan alkavan minuuteissa korjauksen julkaisusta ja
4. kaikki asiakkaille ylläpitämämme WordPress-sivustot ovat vaarassa.

Kysyin suoraan, toimitaanko sopimusten mukaisesti normaalina työaikana vai heti. Vastaus tuli muutamassa minuutissa: heti ja mahdollisimman nopeasti luki sopimuksissa mitä tahansa palvelutasoista. Kriittiset asiakkaisiin sekä työnohjauksellisiin kustannuksiin vaikuttavat päätökset teki Hionin ylin johto. Myös hallitusta tiedotettiin.

Puolen päivän jälkeen kun tilanne oli eskaloitunut nollapäivähaavoittuvuudeksi pelkkä Slack-viesti ilmoitus ei enää riittänyt. Käytännössä katsoimme meidän tech leadin kanssa, että missä meetsissä meidän ylin johto tällä hetkellä on ja menimme samaan meetsiin mukaan. Heillä oli silloin sisäinen tapaaminen käynnissä, jossa oli mukana meidän asiakkuusjohtoa. Keskeytimme heidän tapaamisen ja kerroimme että php2shell oli eskaloitunut nollapäivähaavoittuvuudeksi ja piti tehdä päätös ajetaanko mekin asiakkaiden palveluita alas varotoimena. Käytiin läpi eri skenaarioita ja johto tekisi päätöksen millä skenaariolla edetään.

Emme mitenkään ehtisi kontaktoimaan kaikkia asiakkaita heti samalla sekunnilla, joten oli tehtävä päätös ja alettava valmistelemaan päätöksen toteutusta ja siinä samalla käynnistettävä asiakasviestintä. Koko organisaatio siirtyi kriisiviestintään, josta vetovastuun otti meidän markkinointipäällikkö, joka tyypillisesti hoitaa muitakin asiakastiedotteita ja hallinnoi niihin liittyviä järjestelmiä.

Ylin johto ei tehnyt päätöstä heti, päätöksenteko vaati vähän aikaa. Tällä ajalla kutsuttiin koolle incident response-tiimi, joka tulisi tekemään iltatöitä. Kävimme läpi tilanteen, eri vaihtoehdot ja tulevat toimenpiteet. Työt jatkuivat normaalisti, varauduimme eri skenaarioihin johdon päätöksen mukaisesti.

5. Teillä on ylläpidossa iso määrä sivustoja ja ylläpidon parissa työskentelee iso joukko teidän porukasta. Kuinka moni teidän henkilökunnasta oli mukana operaatiossa ja millaisillä asiantuntijoilla oli isoin rooli käytännön työssä?

Php2shell-operaatioon osallistui Hionilta parikymmentä ihmistä: toistakymmentä kehittäjää, noin kuusi asiakkuusvastaavaa ja viestinnän ammattilaista sekä johto. Iso rooli teknisestä näkökulmasta oli DevOps-osaajilla, jotka päivittivät keskitetyt pohjaimaget ja rakensivat väliaikaiset suojaukset niin, että muut pystyivät viemään ne nopeasti kaikkiin ympäristöihin. WordPress-kehittäjät hoitivat projektikohtaiset päivitykset sekä palveluiden alasajon ja palautuksen. Iltatiimissä oli viisi ihmistä, ja lisäksi moni hoiti omat asiakkuutensa heti, kun päivitys oli saatavilla. Viestinnällisesti asiakasvastaavat tekivät ison työn kontaktoidessaan kaikki asiakkaat henkilökohtaisesti.

6. Kerroit LinkedInissä ”asiakkuusvastaavien soittoringistä” – miten asiakasviestintä hoidettiin, kun piti kertoa sadoille asiakkaille että heidän sivustonsa menevät hetkeksi kiinni?

Kun päätimme ajaa asiakkaiden WordPress-sivustot alas php2shell-haavoittuvuuden takia, avasimme asiakasviestinnälle oman Slack-kanavan, jotta kaikki tieto kulki yhtä reittiä. Kaikille ylläpitoasiakkaille lähti sähköpostitiedote. Asiakkuusvastaavat soittivat kriittisimmille asiakkaille valmiin puherungon pohjalta, ja ne, joita ei tavoitettu, saivat tekstiviestin. Illan aikana asiakkaille lähti vielä tilannepäivitys, ja meillä oli puhelinpäivystys akuutteja kysymyksiä varten. Johto tarkisti tiedotteet ennen lähettämistä, ja se kävi minuuteissa.

7. Sivustojen alasajo on raju päätös. Mitkä konkreettiset riskit painoivat vaakakupissa, kun päätitte ennemmin sulkea palvelut kuin jättää ne pystyyn mitigaatioiden varaan?

Php2shell-haavoittuvuus mahdollisti pahimmillaan koko palvelimen haltuunoton, ja PHP:n kehittäjien mukaan väliaikaiset suojaukset eivät riittäneet sitä estämään. Moni Hionin asiakkaista on julkishallinnon organisaatio tai pörssiyhtiö, ja niiden sivustot ovat kansalaisille ja sijoittajille tärkeä tietolähde. Murto olisi voinut johtaa tietovuotoon, haitallisen sisällön levittämiseen asiakkaan nimissä tai pitkään selvitystyöhön. Muutaman tunnin hallittu katko oli siihen verrattuna pieni hinta. Tiesimme myös, ettemme voi taata, milloin korjaus on käytettävissä koko toimitusketjussa, ja se osoittautui illalla oikeaksi arvioksi.

8. Miten päätökset sivustojen sulkemisesta tarkalleen tehtiin – kuka esitti, kuka hyväksyi, ja kuinka kauan siitä ehdotuksesta päätökseen kesti? Ehdotitteko te sitä asiakkaille ensisijaisena vaihtoehtona?

Esitin asiakkaiden sivustojen alasajoa osana php2shell-toimintasuunnitelmaa, ja Hionin johto hyväksyi sen. Johto oli linjannut jo aamulla, että toimitaan heti eikä odoteta, joten iltapäivällä ei tarvinnut aloittaa keskustelua alusta. Alasajo oli asiakkaille oletusvaihtoehto. Jokainen asiakas sai kieltäytyä, mutta silloin kerroimme suoraan, että palvelu jää alttiiksi hyökkäyksille. Muutama asiakas pyysi lyhyttä lykkäystä esimerkiksi käynnissä olevan tilaisuuden takia, ja niistä sovittiin yksitellen.

9. Mitä teknisiä komponentteja jouduitte oikeasti päivittämään, ja oliko kyse pelkästä PHP:stä vai venyikö lista laajemmalle (palvelinympäristöt, pluginit, riippuvuudet)? Piti esimerkiksi WordPressissä päivittää useita erilaisia komponentteja?

Php2shell oli haavoittuvuus PHP:ssä itsessään, mutta käytännössä päivitys piti viedä läpi koko toimitusketjun. Hionilla päivitimme omat pohjaimagemme, virallisiin Docker-imageihin perustuvat ympäristöt, PaaS-alustojen PHP-paketit ja tarvittaessa PHP-laajennukset. WordPressiin, lisäosiin tai teemoihin ei tarvinnut koskea. Samana päivänä tuli myös Node.js-tietoturvapäivitys, jonka JavaScript-tiimimme hoiti rinnalla.

10. Miten käytännössä selvititte, mitkä sivustot ja mitkä komponentit ylipäätään olivat haavoittuvia – oliko teillä valmis inventaario vai jouduitteko kartoittamaan tilanteen päivän aikana? (ja jos kyllä, niin miten)

Kun php2shell-tieto tuli, pohja oli Hionilla valmiina: asiakasrekisteri, tieto kunkin projektin hostingalustasta ja vastuuhenkilöistä sekä tiedot ohjelmistoversioista. Meillä on edelleen olemassa yhteinen excel-muotoinen seurantataulukko. Tästä luopumista on mietitty moneen kertaan, mutta kylläpä se työn koordinointiin ja status-päivityksiin on edelleen aika ylivertainen. Seurantataulukossa jokaiselle sivustolle merkittiin alusta, päivittäjä, asiakkuusvastaava ja tila, ja työt jaettiin kehittäjille. Taulukko oli koko päivän tilannekuvan perusta.

11. Palvelut nostettiin takaisin sitä mukaa kuin ne saatiin päivitettyä – miten priorisoitte, mitkä sivustot nousevat ensin, ja mikä oli koko operaation kokonaiskesto?

Kun asiakkaiden sivustoja palautettiin php2shell-päivityksen jälkeen, ensimmäisinä tehtiin kriittisimmät: terveydenhuollon ja julkisen sektorin palvelut, pörssiyhtiöiden sivustot ja asiakkaat, joilla oli samana iltana tilaisuus, joka riippui sivustosta. Asiakkaan sopimus ja palvelutaso huomioitiin. Joillekin asiakkaille otettiin alasajon ajaksi käyttöön valmiiksi rakennetut kriisisivustot, jotta tärkein tieto pysyi saatavilla. Suurin osa sivustoista oli takaisin päivitettynä samana iltana ja muutama harkittu poikkeus hoidettiin torstai-aamuna.

12. Jos saisit jälkiviisastella, mitä tekisitte toisin – oliko jotain, mikä olisi pitänyt olla valmiina etukäteen tai minkä olisi voinut hoitaa fiksummin?

Php2shell:n jäljiltä Hionille jäi neljä kehityskohdetta:

1. Julkinen status-sivu, josta asiakkaat näkevät tilanteen reaaliajassa ilman, että heidän tarvitsee odottaa sähköpostia tai muuta ilmoitusta.
2. Toiseksi tarvitsemme varareitin deploymenteille silloin, kun ulkoiset palvelut, kuten GitHub Actions, eivät toimi.
3. Jokainen asiakaskontakti merkitään jatkossa yhteiseen paikkaan, jotta kukaan ei soita samalle asiakkaalle kahdesti tai jätä jotakuta väliin.
4. Mahdollisuus ottaa asiakkaille helposti käyttöön tilapäinen informatiivinen virhesivu vaikka erillistä kriisisivustoa ei olisikaan.

13. Muuttiko tämä tapaus käsitystäsi PHP:stä teknologiana – parempaan vai huonompaan suuntaan, ja miksi?

Ei muuttanut. Php2shellin kohdalla PHP:n tietoturvatiimi toimi esimerkillisesti. Ennakkoilmoitus tuli päivää aiemmin, ja korjaus julkaistiin jopa vähän etuajassa. Ongelmat olivat muualla toimitusketjussa. Valmiita Docker-imageja odotettiin, PHP:n laajennuskirjasto kaatui kuormaan ja GitHub Actionsissa oli katkoja. Kriittisiä haavoittuvuuksia löytyy kaikista laajasti käytetyistä teknologioista. Log4Shell oli Javaa, React2Shell osui Reactiin ja Next.js:ään, ja samana päivänä php2shellin kanssa Node.js korjasi etäkoodin suorittamisen mahdollistavan haavoittuvuuden. Edelleen luotan ja uskon avoimuuteen, avoimeen lähdekoodiin.

14. Oliko tämä mielestäsi poikkeustapaus vai uusi normaali – pitäisikö WordPress-toimistojen varautua siihen, että tällaisia nollapäiviä tulee jatkossa selvästi enemmän?

Uusi normaali. Php2shell oli jo toinen iso WordPress-ympäristöjä koskeva tapaus tänä vuonna, kun kesällä tuli wp2shell. Tekoäly nopeuttaa sekä haavoittuvuuksien löytämistä että hyökkäysten rakentamista, joten aika korjauksen julkaisusta hyökkäyksiin lyhenee. WordPress-toimistojen kannattaa varautua siihen, että tällaisia tilanteita tulee useammin. Varautuminen tarkoittaa ajan tasalla olevaa inventaariota, keskitettyjä tietoturva-, suojaus- ja päivitysratkaisuja, harjoiteltua toimintamallia ja palautussuunnitelmia sekä valmiutta tehdä isoja päätöksiä nopeasti.

15. LinkedInissä tämä on tietysti saanut kaikki muiden teknologioiden edustajat innokkaasti esittämään vaihtoehtoisia ratkaisuja php-kieleen pohjautuville teknologioille. Yksi yleinen väite on, että headless-ratkaisut ovat turvallisempia tällaisessa tilanteessa, erityisesti jos mallia käytetään siten, että käyttäjien käyttämä sivusto on staattisia html-sivuja pääosin. Onko tällainen malli sinusta parempi ja auttaisiko se tällaisten kriisien kohdalla?

Php2shellin jälkeen moni on tarjonnut headless-mallia ratkaisuksi. Staattinen julkinen sivusto pienentää julkista hyökkäyspintaa, ja se on hyvä ratkaisu tiettyihin tarpeisiin. Kokonaisuus ei kuitenkaan katoa minnekään. Sisällöntuottajat tarvitsevat hallintapaneelin, ja se pyörii jollain palvelimella ja jollain teknologialla. Meidän asiakkailla on Strapia pilvessä ja on-premisenä, on Contentfulia, monenlaista headless-toteutusta.

Kaikkea pitää kuitenkin ylläpitää ja päivittää, ja riippuvuuksia on usein enemmän kuin perinteisessä mallissa, WordPress on lopulta aika standardoitu.

Teknologiaa tärkeämpää on, kuinka nopeasti korjaus saadaan läpi koko toimitusketjun ja kuinka valmis tiimi on toimimaan.

PS. Tilaa Vierityspalkin noin kerran kuukaudessa ilmestyvä uutiskirje.