Ilmeisesti noiden salasanojen varsinainen tekninen ongelma oli phpbb-keskustelufoorumeiden haavoittuvuus. Haavoittuvuus, joka oli kuulemma paikattu jo aikoja sitten, mutta ylläpitäjät eivät oleet huomanneet, viitsineet tai jaksaneet asentaa uutta versiota. Tämähän on täysin tuttu tarina, joka puraisi minuakin nilkkaan aikaisemmin.

Mutta entä sitten tekniseltä näkökannalta, minkälaiset temput voivat saada aikaiseksi käyttäjätunnusten ja salasanojen paljastumista näin suuressa määrin? Olen muutamankin web-sovelluksen tarkastanut erilaisten tietoturvaongelmien varalta ja sisäänkirjautumisen käsittely on yksi merkittävä tarkastuksen kohde ja siellä on varsin monia teknisiä yksityiskohtia, jotka on syytä tarkistaa.

Esimerkiksi, minkälainen virheilmoitus tulee jos antaa oikean käyttäjätunnuksen ja väärän salasanan? Entä minkälainen virheilmoitus tulee jos antaa puppukäyttäjätunnuksen ja puppusalasanan? On täysin mahdollista, että oiketa käyttäjätunnuksia saa etsittyä automaattisesti, jos ensimmäisessä tapauksessa virheilmoitus on "Väärä salasana" ja toisessa tapauksessa "Väärä käyttäjätunnus/salasana". Koska käyttäjätunnuksen ja salasanan oikeellisuus tarkastetaan varsin usein eri kohdassa ohjelmalogiikkaa, virheilmoitus voi myös erota toisistaan. Edistyneemmissä sovelluksissa käyttäjätunnus voi mennä ns. lukkoon, jos yrittää liian monta kertaa väärää salasanaa, mutta tällaista käyttäjätunnusten arvailua vastaan ei juurikaan ole teknisiä aseita.

Tällainen "usename harvesting"-tekniikka ei yleensä mahdollista kymmenien tuhansien käyttäjätunnusten ja salasanojen troolausta. Siihen tarvitaan järeämpiä aseita, käytännössä pääsyä suoraan tietokantaan ja dumppia sieltä. Tähänkin on toki keksitty keinoja, ns. SQL Injection -hyökkäykset ovat siitä paras esimerkki. Jos web-sovellus ei tarpeeksi hyvin suodata saamiansa syötteitä esim. URL-parametreja tai web-lomakkeiden kenttiä, niissä voikin olla sisältöä, joka huonosti tehdyssä järjestelmässä siirtyykin tietokannan SQL-kyselyn osaksi. Ja tällä tekniikalla voi saada tietokannasta monenlaista tietoa, esimerkiksi vaikka kaikki käyttäjätunnukset ja salasanat. Sarjakuvana hauskan käytännön pilan asian tiimoilta voi nähdä sivulla http://www.xkcd.com/327/. Moms, don't try this at home!

 

Tästä uhasta on jonkin verran puhuttu julkisuudessakin ( ks. http://www.digitoday.fi/tietoturva/2007/10/12/Nettilomake+on+tulevaisuuden+tietoturvauhka/200725346/66) mutta jos Digitoday kuvaa tuon ruotsalaisen Outpost24:n ratkaisun oikein, niin se on ainoastaan osittaisratkaisu. SQL Injection tai vastaavat syötteiden käsittelyn ongelmat eivät koske pelkästään webbilomakkeita. Sama ongelma voi olla missä tahansa kohdassa sovellusta, esimerkiksi kun siirrytään ohjelman logiikassa seuraavaan vaiheeseen ja ohjelmalle välitetään parametreja esim. URLissa. Sinänsä samaa "brute force"-tekniikkaa käyttää monikin web-sovellusten tarkastamisessa avustava sovellus, esim. käytössäni oleva Acunetixin Web Vulnerability Scanner. Ja ratkaisuna ei pitäisi olla pelkästään sen yhden lomakkeen käsittelyn korjaus, vaan koko syötteiden käsittelyn arkkitehtuuri pitäisi muuttaa.

 

Valittaviin suojauskeinoihin tietysti jonkin verran vaikuttaa se, millainen sovellus on kyseessä ja mikä on käyttäjäryhmä. Finanssialueen sovelluksista (joita enimmäkseen olen tarkastanut) on varsin pitkä matka johonkin Rakkausruno-foorumiin. Käyttäjiltä, joiden rahoja sovelluksessa käsitellään, voidaan odottaa tiettyä käytöstä ja heidän voidaan olettaa sietävän vähän hankalampia tunnistusmenetelmiä. Toisaalta taas jossain avoimessa yhteisöpalvelussa käytäjät saadaan taatusti kaikkoamaan välittömästi, jos rekisteröitymisrumba tai palvelun käyttö on todella vaikeaa. Tekniset suojaustoimenpiteet on siis sovitettava riskien koon mukaisiksi.

Jos siis teette mitä tahansa web-sovellusta, niin käykääpä OWASP-projektin sivuilla, http://www.owasp.org/. Siellä on varsin hyvät ohjeet siitä, mitä suuria arkkitehtuurin asioita tulee ottaa huomioon kun web-sovellusta tehdään. OWASPin listaa minä käytän erilaisten sovellusten tarkastuksen ohjenuorana. Teknisen tietoturvatarkastuksen tekeminen on varsin tarpeellista ennen kuin järjestelmä otetaan tuotantoon, mutta oikeasti tietoturva-asiat olisi pitänyt ottaa huomioon jo järjestelmää rakennettaessa. Autan mielelläni sekä tekemällä web-sovelluksiin tietoturvatarkastuksia mutta myös  järjestelmän rakennusvaiheessa suunnittelemalla oikeaa arkkitehtuuria ja tietoturvapiirteitä.

P.S. Yleisin salasana muuten tuossa julkisuudessa olleessa joukossa tuntui olleen...."salasana".  Lisää listaa vielä toistaiseksi http://10.uraanikaivos.com/yleisyys.txt.

 

P.P.S. Kirjoitin tuon yllä olevan tekstin 15.10.2007, mutta tänään 16.10. luin Digitodaystä artikkelin http://www.digitoday.fi/tietoturva/2007/10/16/Tietoturva+ei+huoleta+verkkopalveluita/200725591/66

ja minun oli pakko jatkaa. Artikkelissa huuto.net-palvelun kehityspäällikkö päästää suustaan varsin klassisen sammakon "Palvelumme on niin monen palomuurin takana, että tuontyyppisen tietomurron ei pitäisi olla mahdollinen". Jos nyt palataan hetkiseksi tietoliikennetekniikan perusteisiin niin milläs tasolla OSI:n tai Internetin pinomallia palomuurit yleensä toimivatkaan? Ja milläs tasolla ohjelmiston sisäänkirjautuminen ja tietokantakyselyt toimivat? Annan vinkin: ne eivät toimi samalla kerroksella. Verkkoteknisin keinoin ei yleensä voida puuttua täysin sovellustason ongelmiin. On toki mahdollista tehdä sovellustason palomuureja ja sovelluksen semantiikkaa jollain tasolla ymmärtäviä IDS/IPS-laitteita, ja näin on toki tehtykin,  mutta haluaisin nähdä sen palomuurin, joka blokkaa hyökkäyksen, jossa URL:in parametriin (esim. /show.php?account=123) account-parametria muuttamalla pääseekin näkemään toisen käyttäjän tiedot. Siinä sitä haastetta huuto.net:in palomuureille.