Blogi
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?
- 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)
- 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ä
- 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?
- 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
- 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
- Tietokannan sisällön laadusta huolehtiminen
- 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
- Prosessit pitää olla mietitty ja dokumentoitu valmiiksi
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.
Kirjoittaja
Lauri Korpela
Senior Software Architect
Lauri on kokenut ohjelmistoarkkitehti jolla on monipuolisesti kokemusta koodin kirjoittamisesta tietoturvakriittistä palvelua tuottavan DevOps-tiimin vetämiseen. Hän uskoo että ohjelmistojen ja niistä luotavien palvelujen kanssa parhaisiin lopputuloksiin päästään kun kaikki sidostahot johdosta kehittäjiin ovat mukana ja jokaisella on oma selkeä roolinsa kokonaisuudessa. Voisimmeko tarjota aivan tavallista, ohjelmistokehitystä ja sen ympärille kertynyttä kokemusta myös teille?
Lue lisää ajatuksiamme
Uutena työntekijänä Varaanilla
Liittyessäni Varaaniin keväällä 2023 yrityksemme koko perehdytysprosessi oli juuri
Aivan tavallinen etsii aivan tavallista
Aloitin Varaanilla käyttöliittymäsuunnittelijana keväällä 2023. Minulla on paljon kokemusta
Huono kiire kuriin ohjelmistokehityksessä
Ohjelmiston kehitystiimillä on aina akuutti aika- ja resurssipula. Pahimmillaan