Lento-onnettomuustutkintaa perjantai-iltapäivänä – Kun legacy-järjestelmän pääsynhallinta pettää

Alla kuvattu tapaus tapahtui eräänä perjantai iltapäivänä erääseen vanhaan web-järjestelmään tehtävän siivouksen yhteydessä ja lopulta sen selvittäminen alkoi muistuttaa lento-onnettomuuden tutkintaa.

Kaikki alkoi siitä kun proxyn lokeja tutkiessa pisti silmään harvakseltaan toistuvia kutsuja toimintoihin jotka eivät enää ole käyttäjän saavutettavissa.

access_log:40.77.167.5 - - [26/Apr/2022:00:04:58 +0000] "GET /cgi-bin/some_api.cgi?command=COMMAND_NAME-SESSION_TOKEN-PARM1 HTTP/1.1" 200 35561 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Kutsujen tekijä ilmoitti olevan bingbot niminen use agent ja IP-osoitteen tarkistus vahvisti kyseessä olevan BING-hakukoneen web-crawler joka käy automaattisesti läpi internet-sivuja. Hälytyskellot alkoivat soida, kun yhden haetuista sivuista pitäisi vaatia kirjautumisen ja lokin mukaan se haettiin onnistuneesti. Luonnollisestikaan hakukoneen ei pitäisi päästä kirjautumisen takana oleville sivuille.

Mikäli hakukone oli indeksoinut kyseisen sivun, pitäisi se myös löytyä sopivilla hakusanoille. Tämä varmistui oikeaksi muutaman yrityksen jälkeen hakukoneen listatessa kyseisen sivun ja tulosta klikatessa päästäen käyttäjän suoraan itse sivulle ilman kirjautumista!

Tästä alkoi intensiivinen muutaman tunnin tutkimus, jonka tarkoituksena oli selvittää mistä on kyse ja miten suurta osaa järjestelmästä ongelma koskettaa. Tutkimuksissa käytettiin hyväksi järjestelmän lokeja, lähdekoodeja ja tietokannan sisältöä.

Kuten monesti lento-onnettomuuksissa, monen asian on täytynyt mennä pieleen. Niin oli käynyt tässäkin tapauksessa: ongelman aiheutti pitkän ajan saatossa ketjuuntuneet yllättävätkin asiat.

Mikä ongelman aiheutti?

1. Session-tokenin välittäminen HTTP-query parametreissä
   • Tekniikan käyttäminen mahdollisti kirjautuneen käyttäjän session-tokenin vuotamisen helposti
   • Tämä tekniikka on jo pitkään ollut ei suositeltujen listalla, mutta vanhaa järjestelmää ei ole lähdetty muuttamaan tältä osin
   • Uloskirjautumisen jälkeen session-tokenin käyttäminen ei olisi pitänyt olla mahdollista (bugi)
2. Linkin vuotaminen hakukoneen löytämään paikkaan
   • Se miten sessio-tokenin sisältämä linkki on vuotanut ulos ei selvinnyt ja kyseessä saattaa olla vanhakin tapahtuma
   • Yksi vaihtoehto on julkisena ollut online-ohje, johon linkki olisi voitu lisätä ymmärtämättä sen sisältämän session-tokenin merkitystä
3. Autentikointilogiikan pettäminen
   • Autentikoinnin pettäminen oli yhdistelmä koodibugia ja juuri siihen sopivaa sisältöä tietokannassa
   • Copy/paste koodia joka ei ollut pysynyt samanlaisena joka paikassa (DRY-periaate)
   • Tietokantaan oli ajan saatossa luotu käyttäjä tyhjällä käyttäjätunnuksella ja merkitty disabloiduksi
   • Hallintakäyttöliittymä mahdollisti käyttäjän luomisen tyhjällä käyttäjätunnuksella
   • Viallista käyttäjää ei ollut poistettu koska hallintakäyttöliittymä ei mahdollistanut poistoa
   • Onneksi ongelma koski lopulta vain pientä osaa järjestelmästä

Miten tällainen tilanne vältetään?

1. Koodin kehitys ja ylläpitäminen (DEVOps)
   • Koodin laatu (asioiden tekeminen kunnolla maksaa itsensä takaisin)
   • Oikeiden valmiiden komponenttien valitseminen
     • Nykyisin löytyy paljon valmiita kirjastoja joita käytetään (ja testataan) tuhansien muiden toimesta joka päivä
   • Pitkän elinkaaren omaavia järjestelmiä tulee ylläpitää 
     • Tiettyyn aikaan tehty tekninen ratkaisu saattaa myöhemmin osoittautua vaaralliseksi ja vaatia sen korjaamista paremmaksi/turvallisemmaksi
   • Toimiva ja testattu CI/CD-pipeline mahdollistaa korjausten viemisen tuotantoon tarvittaessa nopeasti
2. Tuotannon operointi (devOPS)
   • Tietokannan sisällön laadusta huolehtiminen
     • Site reliability engineering järjestäminen koodaamisen lisäksi
   • Poikkeavuuksien havaitseminen
     • Tuotantoympäristön valvonta (monitorointi ja lokienhallinta) ovat tärkeitä työkaluja kun halutaan pitää järjestelmät turvallisina
3. Tietoturvaprosessit
   • Prosessit pitää olla mietitty ja dokumentoitu valmiiksi
     • Kaikkien mukana olevien tekijöiden täytyy tuntea ne (myös alihankkijat)
   • Selkeät vastuut
     • Kenelle ilmoitetaan
     • Kuka voi tehdä päätöksen järjestelmän sulkemisesta viikonloppuna jos tilanne sitä vaatii
     • Kuka hoitaa kriisiviestinnän ulospäin
   • Osaavatko kaikki toimia koko ketjun läpi
     • Analysointi -> päätökset -> toimenpiteet -> tiedottaminen
     • Harjoittelulla varmistetaan että ketju toimii tositilanteessa

Tämän ongelman havaitsi koodin parissa työskennellyt alihankkija. Ilmoitus tehtiin välittömästi järjestelmän omistajalle ja tutkimukset aloitettiin ongelman laajuuden selvittämiseksi. Mitä jos ongelman havaitsija ei olisi ilmoittanut asiasta eteenpäin, lähtenyt viikonlopun viettoon ja ongelma olisi koskenut koko järjestelmää?

Tietoturvapoikkeamat ovat usein monen tekijän summa, mutta niitä voidaan välttää pitkäjänteisellä työllä aina ohjelmiston kehittämisen alkuajoista lähtien koko sen elinkaaren loppuun. Tämä vaatii asioiden tunnistamista ja niihin suunnitelmallista varautumista. Yksi tapa parantaa yrityksen johdon tukea palvelulle ja sen kehittämiselle on ottaa tietoturva-asiat mukaan yrityksen riskienhallintaan ja perustaa tietoturvaan tehtävät investointipäätökset todellisiin riskeihin ja niiden vaikutuksiin/todennäköisyyksiin yrityksen toiminnalle.

Tämä saattaa kuulostaa kaukaiselta asialta koodarin työpöydältä katsottuna, mutta johdon sitouttaminen päätöksentekoon auttaa kehitystiimiä keskittymään oikeisiin asioihin ja vie vastuun tietoturvaan liittyvistä päätöksistä sinne missä myös niiden seurauksista joudutaan vastaamaan.