Foliohatun painajainen

Sain aiemmin tänä vuonna tehtäväksi tehdä tietoturva-auditoinnin erään keskisuuren kunnan verkkosivustolle. Tarkoitus oli käydä läpi sivuston tietoturvan nykytila ja tehdä sen jälkeen auditointi sivuston koodille ja käytetyille lisäosille.

Sivusto oli kohtuullisen uusi ja sen toteutus oli tilattu ”WordPress-sivustoihin erikoistuneelta” yritykseltä. Itse en ollut siitä kuitenkaan kuullut aiemmin enkä löytänyt sitä Vierityspalkin WP-toimistojen listalta.

Sivuston nykytilan kartoitusta varten sain käyttööni WordPressin pääkäyttäjätunnuksen ja salasanan, joilla pääsin tutkimaan sivustoa. Ensimmäisenä huomioni kiinnittyi annettuun salasanaan: se oli 8-merkkinen yksinkertainen salasana, joka sisälsi ainoastaan kirjaimia ja numeroita. Kun tähän yhdistetään se, että ko. pääkäyttäjätunnus oli nähtävissä sekä kirjoittaja-arkiston että REST-rajapinnan kautta, puhutaan kohtuullisen helposti murrettavasta tunnuksesta.

Seuraavaksi lähdin selvittämään, mitä ylläpidossa kyseisellä tunnuksella voisi tehdä. Koska sivusto oli selvästi rakennettu ns. suoraan tuotannossa ja koodin muokkaukseen oli käytetty WordPressin sisäänrakennettua teemaeditoria, keksin heti kolme tapaa hankkia pääkäyttäjätunnuksen avulla tietokannan käyttäjätunnuksen ja salasanan: teema- tai lisäosamuokkaimen kautta tai asentamalla lisäosa, joka poimii tiedot DB_PASSWORD ja DB_USER -muuttujista.

Vaikka tässä vaiheessa olin jo saanut useita merkkejä siitä, että sivuston tietoturva ei ole kaikilta osin toteutettu parhaiden käytäntöjen mukaan, olin yllättänyt, kun WordPressin tietokantayhteyden muodostamiseen oli käytetty MySQL:n root-tunnusta. Käytännössä tämä tarkoitti sitä, että WordPressin ylläpidon kautta oli pääsy palvelimen kaikkiin tietokantoihin korkeimmilla mahdollisilla käyttöoikeuksilla.

Samalla tein toisen merkittävän huomion: tietokannan root-käyttäjän salasanana oli käytetty samaa yksinkertaista salasanaa, jonka olin saanut itselleni WordPressin ylläpitotunnuksen mukana.

Tämän jälkeen ei vaatinut kummoisia salapoliisitaitoja arvatakseen, että samaa salasanaa oli käytetty myös palvelimen root-tunnuksessa. En kuitenkaan uskonut, että root-kirjautuminen olisi salasanan avulla mahdollista mistä tahansa ip-osoitteesta, mutta päätin kokeilla sitä osana testausta.

Järkytykseni oli suuri, kun kirjautuminen onnistui ensimmäisellä yrityksellä.

Muutamassa minuutissa oli WordPressin pääkäyttäjätunnuksesta päästy tilanteeseen, jossa potentiaalinen hyökkääjä olisi voinut saada koko palvelimen haltuunsa ja tehdä sille mitä tahansa: asentaa haitta- ja vakoiluohjelmia, sulkea palvelimen ylläpitäjät ulos järjestelmästä tai tuhota koko palvelimen.

Ylläoleva tarina on harvinainen, mutta ei täysin poikkeuksellinen. Halusin kertoa sen nyt, kun sivuston tietoturva on laitettu kuntoon, jotta vastaavat tilanteet voitaisiin välttää mahdollisimman monen verkkosivuston kohdalla.

Muutamassa minuutissa oli WordPressin pääkäyttäjätunnuksesta päästy tilanteeseen, jossa potentiaalinen hyökkääjä olisi voinut saada koko palvelimen haltuunsa ja tehdä sille mitä tahansa: asentaa haitta- ja vakoiluohjelmia, sulkea palvelimen ylläpitäjät ulos järjestelmästä tai tuhota koko palvelimen.

Mitä voidaan oppia?

Ensimmäinen opetus on, että julkaisujärjestelmän salasanoilla on merkitystä. Yhdenkin pääkäyttäjätunnuksen vuotaminen tai murtuminen riittää, vaikka se olisi tehty koulutus- tai testauskäyttöön. Lisäksi salasanan arvaamiseen tähtääviä hyökkäyksiä ei kannata helpottaa paljastamalla tunnukset WordPressin rajapintojen kautta.

Toinen opetus on, että ylläpidon kautta ei tule päästä käsiksi koodiin. Vakavasti otettavalla sivustolla lisäosien asentaminen tai lähdekoodin muokkaaminen ei saa olla mahdollista tuotantopalvelimen ylläpidon kautta. Huonon tietoturvan lisäksi se on myös käytäntönä huono: lähtökohtaisesti kaikki koodimuutokset on testattava vähintään paikallisesti ja versioitava versionhallintaan.

Kolmas opetus on, että tietokantayhteydessä tulee käyttää tietokantakohtaista käyttäjätunnusta ja salasanaa, jolla estetään lisävahinkojen syntyminen, mikäli se jostain syystä päätyy vääriin käsiin. Lisäksi yhteys tietokantaan tulee rajoittaa sille palvelimelle, josta tietokantaa käytetään.

Neljäs opetus on, että samaa salasanaa ei kannata käyttää useassa paikassa, etenkään, kun kyse on kriittisistä palveluista. Jo kaksi salasanaa riittää paljastamaan kaavan, kun se on muotoa x=1 ja x=1, määrittele x.

Viides opetus on, että salasanakirjautuminen root-tunnukselle ei tulisi olla mahdollista. Kirjautuminen tulee rajata tiettyyn IP-osoitteeseen ja käyttää aina SSH-avainpareja kirjautumiseen.

Kuudes opetus on, että WordPress-sivuston kilpailutuksessa mukaan kannattaa ottaa yrityksiä, joilla on todennettua näyttöä sivustojen ammattimaisesta ja tietoturvallisesta toteutuksesta. Vinkkejä näistä yrityksistä saa esimerkiksi Vierityspalkin WP-toimistot -listalta.

Mikko Virenius

Työskentelen Valu Digitalissa WordPress-asiantuntijana. Koulutukseltani olen kauppatieteiden maisteri.

JÄTÄ KOMMENTTI