Tammikuussa 2017 uutisoitiin muiden tietoturvauutisten joukossa muutamista (sadoista, tuhansista?) ns. ransom-hyökkäyksistä, jotka kohdistuivat MongoDB -tietokantaa käyttäviin saitteihin ja palveluihin. Kevään 2017 edetessä ilmiö eteni kiihtyvällä tahdilla aika epidemiaksi.

Mikä on ransom -hyökkäys?

Ransom on siinä mielessä ikävä hyökkäys, että siinä data kaapataan, kryptataan lukkojen taakse, jonka jälkeen omistajaa kiristetään maksamaan vapautusmaksu. Alkuperäinen data joko poistetaan tai ylikirjoitetaan salakirjoitettuna, jolloin alkuperäisen järjestelmän omistajalle jää korkeintaan kasa satunnaiselta näyttäviä bittejä – tietoa ei voi sellaisenaan enää käyttää.

Hyökkääjä todennäköisesti jättää mieluusti kryptatussa muodossa olevan datan uhrille, jotta tämä vakuuttuisi enemmän mahdollisuudesta vielä nähdä alkuperäinen data maksun jälkeen.

Kuten mikä tahansa panttivankitilanne, takuita tiedon vapautuksesta maksun jälkeen ei ole. Usein maksu pyydetään elektronisessa muodossa, esimerkiksi Bitcoineina. Vapautus tapahtuu salasanan tai koodin / lukituksenpoisto-ohjelman kautta. (Kts. F-secure FSLabs -video aiheesta: Activation Ransom trojan (Youtube) – vaikka videossa on kyse Windowsin kaappaamisesta, periaate on aivan sama).

Nyt huhtikuussa 2017 paljastui enemmän teknisiä yksityiskohtia näistä MongoDB -kiristyksistä. Lukittujen järjestelmien lukumäärä on ilmeisesti yli 30000 tällä hetkellä.

Mikä mahdollisti hyökkäyksen?

MongoDB on siis tietovarasto. Ongelmaksi muodostui löpsö vakiokonfigurointi, joka on ollut olemassa kaikissa MongoDB:n 2.6.0 vanhemmissa versioissa: asennettaessa tietokanta ei vaadi asettamaan salasanaa pääkäyttäjälle. Toisin sanoen tietokanta on sepposen selällään kenelle tahansa joka huomaa tietyssä IP-osoitteessa pyörivän tietokannan.

Versiota 2.6.0 vanhemmissa tietokannoissa MongoDB suostuu ottamaan yhteyksiä vastaan “mistä tahansa” päin maailmaa, ja sen lisäksi, kuten aiemmin mainittu, se ei vaadi salasanaa. Toisin sanoen: jos pahaa tarkoittava hyökkääjä kokeilee hieman tikulla jäätä, ja huomaa että netissä on amatöörin pystyttämä MongoDB (versiota 2.6.0 aiempi), niin hyökkäys on pala kakkua. MongoDB on siis vakioasetuksilla täysin turvaton.

Miksi v. 2017 hyökkäykset yleistyivät?

Ensimmäisen kerran mahdollinen turva-aukko huomattiin jo 2015. Hackernews toitotti maailmalle, että webissä on satoja MongoDB:tä käyttäviä palveluita, joiden tietokanta on siis turvaton. Hackernews kertoi varsin selväsanaisesti myös viestin: tietokanta on vakioasetuksillaan todella turvaton.

Luulisi tällöin tapahtuvan jotain. Kenties turvatonta tietokantaa pyörittävän firman ylläpitäjä tai ohjelmoija muuttaisi pääkäyttäjän siten, että salasana turvaisi tietokannan tästedes?

Miksi tuhansia tietokantoja jäi silti suojaamatta?

On useita (mahdollisia) syitä.

• tietoturva-aukosta kertova uutinen ei päädy koskaan asianomaisen näköpiiriin
• uutinen on tiedossa, mutta firmassa on troijalainen – henkilö, joka ei toimi firman parhaiden intressien mukaisesti
• ne kehittäjät, jotka ovat projektissa, eivät alunperin ole pystyttäneet tietokantaa, eivätkö tiedä haavoittuvuudesta. Arkkitehti on jo toisessa projektissa, tai lähtenyt firmasta.
• uhkaa on tiedossa, mutta sitä ei pidetä riittävän suurena, jotta siihen “kannattaisi” reagoida
• asia hautautuu jostain inhimillisestä syystä ja sitä ei käsitellä ajoissa

Enpä itsekään ollut tietoisesti tuota vuoden 2015 Hackernewsin uutista rekisteröinyt. Voi olla, että näin sen, satojen muiden tietoturvauutisointien kanssa. Toisaalta, itse en käytä myöskään MongoDB:tä mihinkään.

Laskelmoiva vs. haparoiva tietoturva organisaatiossa

Yritykset toimivat tietoturvan kanssa usein jommallakummalla tavalla: erittäin laskelmoiden, tai haparoivan satunnaisesti. Laskelmoivassa tavassa tehdään uhka-arviot, ja yksittäiset tunnetut ja tuntemattomat uhka-skenariot pisteytetään suurinpiirtein näin: “Kuinka todennäköinen hyökkäys on; paljonko hyökkäyksellä saavutetaan, ja mitkä ovat seurauksen kustannukset firmalle”. Kaikki tietoturvaan liittyvä toimet toteutetaan ottamalla pistelistalta kivuliammat ongelmat ensiksi käsittelyyn.

Haparoivassa tietoturvassa yksinkertaisesti laitetaan laput silmille ja koodataan menemään, sen kummemmin miettimättä koko asiaa. Firma maksaa myöhemmin ongelmista mainetappiona ja mahdollisesti myös oikeusteitse asiakkaiden karhutessa korvauksia. Jos hyvä tuuri käy, purkkaviritys ei koskaan edes joudu hyökkäyksen kohteeksi.

Laskelmoiva firma siis vähentää riskiä joutua tietoturvahyökkäyksen uhriksi.

Miksi näin laajat hyökkäykset ovat mahdollisia?

MongoDB -kaappauksista tuli hieman mieleen vuoden 2014 kohu-uutinen, Heartbleed -haavoittuvuus. Heartbleedissä pienen pieni koodinpätkä (joka oli sinänsä hyödyllinen, mutta ohjelmoitu väärin) teki miljoonista web-servereistä turvattomia: hyökkääjä saattoi lukea serverin keskusmuistia 64 kilotavun paloissa mielivaltaisen paljon. Heartbleedissä oli kyse netin perusputkiston, OpenSSL-kirjaston, bugista. Haavoittuvuutta hyväksikäyttävä hyökkäys ei jättänyt minkäänlaisia jälkiä lokitiedostoihin, koska nimellisesti hyökkäysliikenne näytti harmittomalta, normaalilta web-liikenteeltä: ainoa ero oli, että hyökkäyspaketissa oli yksi numero erilainen kuin normaalissa liikenteessä. Tuon numeron liian orjallisessa noudattamisessa OpenSSL-koodi teki fataalin virheen: se palauttikin hyökkääjälle paljon enemmän paluupaketissa (serverin muistin sisältöä) kuin olisi ollut fiksua.

Yleensä suuren tietoturvamokauksen paljastuttua alkaa analysointi ja sormen heristely. Kuka on alunperin jättänyt tietoturva-aukon järjestelmään? Miksi näin pääsi käymään? Oliko kyseessä vahinko vai tarkoituksellinen teko? Foliohattuteoriat myös usein saavat kannatusta tässä vaiheessa – ehkä osa näistä on oikeassa, todennäköisesti suuri osa ei ole. Aikoinaan 1980- ja 1990-luvulla tietokonevirusten suurin haitta tuli oikeasti ei niinkään tarkoituksella, vaan vahingossa – myös virusten kirjoittajat tekevät bugista koodia.

MongoDB on C++ :lla koodattu. Se ei oikeastaan vielä kerro mitään. Kieli on edelleen voimissaan, ja sitä ymmärtää sadattuhannet koodaajat. MongoDB on myös avointa lähdekoodia. Tämän pitäisi parantaa tietoturvaa, koska kuka tahansa voi käydä katsomassa, miten tietokanta ja sen turvatoimet on toteutettu.

Tekniikassa itsessään ongelma ei varsinaisesti piile. Ongelman ydin on paljon yksinkertaisempi: MongoDB valitsi käyttäjäystävällisen, “kivan” polun, sen sijaan että pakottaisi käyttämään salasanaa tietokannan suojaukseen.

Helppo ja kiva vs. turvallinen (napit vastakkain)

Kun virittelen aina silloin tällöin MySQL-kantaa omalla läppärillä, harmittaa sen vaatima salasana. MySQL:ssä on yksi pääkäyttäjä, jolla on oikeus tehdä mitä tahansa tietokannassa: lukea, muokata, ja poistaa tietoa. MySQL:ssä käyttäjän nimi on ‘root’.

Useimmiten MySQL on alustana, kun kokeilin jotain asiaa WordPress-blogissa – en täällä julkisessa Internetissä (Jukkasoft-blogissa), vaan omalla koneella. Käytän kantaa niin harvoin, että tuo salasana tuntuu sitten olevan “jossain” kun sitä tarvitsisi. Yleensä kirjoitan tuon salasanan vihkoon, jota pidän kaapissa. Tai vastaavaa.. No, kun 3-6 kk kuluu, voi olla että paperi on ajautunut hieman, enkä löydä välittömästi (alle 5 minuutin etsiskelyn) salasanaa.

MongoDB käytti toisenlaista strategiaa: se ei pakottanut pääkäyttäjää asettamaan tietokantaa turvaavaa salasanaa asennusvaiheessa. Eli ohjelmaa oli helpompi käyttää – kenties myös helpdesk sai vähemmän kyselyitä kadonneiden salasanojen palauttamisesta. (MySQL:ssäkin pääkäyttäjäsalasanan voi palauttaa, jos on itse koneen pääkäyttäjä:  ohje MySQL 5.7:lle ja muille versioille) Ilmeisesti ohjelmisto ajautui sitten sellaisenaan, suojaamattomana, myös paikkoihin joihin sen ei olisi pitänyt päästä – tuotantoon.

Asiakas, esimerkiksi web-saitin toteuttava ohjelmisto, keskustelee MongoDB:n  kanssa TCP-kutsuilla. Yhteyskäytäntö on siis valittu sellaiseksi, että teknisesti sen toteutus on hyvin samanlainen riippumatta, onko asiakas samassa tietokoneessa (paikallinen), vai toisella puolella maapalloa. Luonnollisesti silloin kun kytkeytyvä asiakasohjelma on fyysisesti eri paikassa, on tärkeää käyttää tietoturvallista kytkeytymistapaa. Internet on “luonnostaan” turvaton, joten tietoturva pitää luoda ohjelmistoissa aina siten että molemmat päät noudattavat samaa protokollaa tiedon käsittelyssä.

Mistään uuden uutukaisesta asiasta ei ole kyse. Krypton käyttö kirjautumisessa juontuu jo 1990-luvulle, jolloin mm. SSH-ohjelmisto keksittiin terminaaliyhteyksien suojaamiseen: Otaniemen Teekkarikylässä opiskelija-asuntolan omasta tietokoneesta oli kätevää mennä yliopiston koneille tekemään kotitehtäviä, mutta harmitti, jos joku toinen teekkari salakuunteli yhteydessä käytetyt salasanan. SSH-ohjelmisto esti tällaisen salakuuntelun. Jostain syystä nämä tunnetut reseptit ajoittain “unohtuvat” tai jostain käytännön syystä jäävät käyttämättä.

Summa summarum

Liian aikaista. Asiasta selvinnee vielä uusia yksityiskohtia. Itseni tämän luokan aukko yllätti, kahdella tapaa. Ensin kuvittelin että ransom-uutiset koskevat jo tutuksi käynyttä asiaa: Windows-koneiden kaappaamista ja kiristystä. Kyse ei ollutkaan siitä.

Toinen asia, joka yllätti, oli että tuotannossa on käytetty täysin suojaamattomia tietokantoja. Se on kuin ajelisi valtamerialuksella laput silmillä, autopilot poissa päältä, ilman tutkaa. Odottaa vaan törmäystä.