Drupalgeddon 2 – bugi ja kuinka se korjattiin

28.3.2018: “Kriittinen haavoittuvuus Drupal -sisällönhallintaohjelmistossa. Päivitä viipymättä!”

Eräänä kevättalvisena iltana ohjelmistokehittäjämme Jasper Mattsson selaili työpäivänsä päätteeksi Drupal-julkaisujärjestelmän uusimman version lähdekoodia perehtyäkseen sen ominaisuuksiin ja selvittääkseen, kuinka päivityksen tuomia ominaisuuksia voisi hyödyntää omassa työssään sekä tutkiakseen samalla järjestelmän mahdollisia haavoittuvuuksia.

“Homma lähti siitä, että halusin opetella Drupal kasia. Luin sen lähdekoodia läpi ja aloin miettiä, että voisivatko jotkin asiat aiheuttaa tietoturvaongelmia. Sitten aloin etsimään ja purkamaan muutamaan eri asiaan liittyviä ongelmia. Tässä vaiheessa minulla ei ollut edes Drupalia asennettuna tätä varten – kaikki etsiminen tapahtui lähdekoodia lukemalla.”

Kokeneelle ohjelmistokehittäjälle muiden kirjoittaman koodin tutkiminen on rutiininomainen keino tutkia, kuinka muut ovat ratkaisseet tiettyjä ongelmia ja siten syventää myös omaa osaamistaan. Käytäntöä voisi verrata minkä tahansa teknisen laitteen purkamiseen ja erillisten osien sekä niiden välisten kytkentöjen tutkimiseen. Yleensä osia ja kytkentöjä – tässä tapauksessa koodia – tutkimalla ei löydy juuri käytännön pikkuniksejä ihmeellisempää, mutta tuona iltana tilanne oli toinen.

Bugi löytyy

“Kiinnitin huomiota tapaan, jolla joissain lomakkeissa käsiteltiin käyttäjän syöttämiä arvoja ja aloin sen perusteella etsiä kohtia, joissa tästä voisi seurata tietoturvaongelmia.”

Jasper huomasi, että ohjelmointivirheen avulla Drupal oli mahdollista saada käsittelemään käyttäjän lomakkeelle syöttämiä arvoja ohjelmakoodina. Tämän avulla hyökkääjä voi esimerkiksi ajaa omaa haittakoodiaan Drupalissa. Näin on esimerkiksi onnistuttu asentamaan kryptovaluuttojen mainaukseen tarkoitettuja ohjelmia palvelimelle sivuston ylläpitäjän tietämättä. Hyökkäyksiä tehdään automatisoidusti – hakkeroidut sivustot valjastetaan hyökkäämään muihin päivittämättömiin sivustoihin. Ovelimmat automaattisista hyökkäyksistä asentavat Drupaliin tietoturvapäivityksen päästyään sisään, jotta kilpailevat hyökkääjät eivät pääse palvelimelle.

Itse bugiin liittyi kaksi puolta; vahingollisen syötteen saaminen Drupaliin sisään ja se, että Drupalin sai suorittamaan sen koodina. Mikäli satunnainen lähdekoodia tutkiva henkilö olisi löytänyt vain toisen näistä ongelmista, hän ei välttämättä olisi ajatellut kyseessä olevan tietoturvaongelma. On varsin todennäköistä, joskin täysin spekulatiivista, että molemmat yksittäiset ongelmat ovat olleet joidenkin toimijoiden tiedossa, sillä haavoittuvuus oli ehtinyt ollut Drupalissa ainakin vuonna 2011 julkaistusta 7-versiosta lähtien, sekä mahdollisesti jossain muodossa jo vuonna 2008 julkaistussa Drupal 6:ssa. Kahden satunnaisen pikkuongelman havaitsemisen lisäksi erityisen ratkaisevaa tässä tapauksessa oli kuitenkin ongelmien välisten syy-seuraussuhteiden ja niiden yhdessä muodostaman riskin vakavuuden ymmärtäminen.

Korjaustoimenpiteet

Ensimmäisestä huomion herättäneestä havainnosta bugiepäilyn vahvistamiseen kului aikaa vain muutamia tunteja. Ongelman havaittuaan Jasper raportoi bugin Drupalin tietoturvatiimille ja ilmoitti havaintonsa tueksi esimerkkitilanteen (Proof of Concept), jossa haavoittuvuus oli hänen koneellaan ilmennyt. Tarvittavien tietojen raportoimiseen kului aikaa muutama päivä, tosin esimerkkitilanteen toistamisessa oli alkuvaikeuksia.

Hyvin pian vapaaehtoisista ja luotettaviksi todetuista Drupal-kehittäjistä koostuva tietoturvatiimi pääsi kuitenkin tekemään korjauksia. Myös Jasper osallistui niiden testaamiseen, mahdollisten uusien aukkojen etsimiseen ja korjausehdotuksiin liittyvään keskusteluun.

“Drupalin tietoturvatiimi kehitti korjauksia nopealla tahdilla ja hyvällä yhteistyöllä – keskustelun ja korjauksien testaamisen tahdissa ei meinannut pysyä mukana”.

Kehittämiseen vierähti muutama viikko ja useampi iteraatiokierros ennen kuin päivitys oli saatu riittävälle tasolle julkaisua varten.

Kun tietoturvatiimillä oli aukko tiiviisti tilkittynä, he tiedottivat korjauspäivityksen julkistamisajankohdan. Tässä vaiheessa itse haavoittuvuuden yksityiskohdat pidettiin luonnollisesti vielä tiukasti salassa ja kerrottiin vain, että kyseessä on kriittinen tietoturva-aukko. Myös päivitysversion korjaukset koordinoitiin ja toteutettiin siten, ettei päivityksen koodista pystyisi helposti päättelemään mistä tietoturva-aukko tarkemmin löytyisi.

Välttämättömät korjaukset paikkaava päivitys julkaistiin pääsiäistä edeltävänä keskiviikkona 28.3. jolloin Druidilla sekä muissa Drupal-taloissa oltiin valmiudessa päivittämään sivustot. Drupal.org kaatui hetkellisesti suuren kävijämäärän vuoksi kehittäjien ladatessa sivua uudelleen malttamattomina.

Ennen päivitystä pelättiin, että päivityksen perusteella saattaisi huolellisista varotoimista huolimatta olla mahdollista päästä tietoturva-aukon jäljille ja että sitä hyödyntävää haittakoodia voisi olla tarjolla hyvinkin pian päivityksen julkaisun jälkeen. Näin oli käynyt ensimmäisen Drupalgeddon-haavoittuvuuden kanssa vuonna 2014. Ensimmäiset haavoittuvuutta käyttävät hyökkäykset huomattiin kuitenkin vasta 11.4., joten sivustojen ylläpitäjillä oli lähes kaksi viikkoa aikaa päivittää sivustonsa.

Mikäli sivustosi jäi Drupalgeddonin jalkoihin tai tarvitset luotettavaa kumppania pitämään huolta verkkopalveluistasi, ota meihin yhteyttä!