TigerTeam - suomalainen tietoturvablogi

Äskettäinen vakava tietoturvalöydös GitHubissa nostatti varmasti monien kulmakarvoja. Vaikka kyseessä ei ollut pahantahtoinen yritys hyökätä järjestelmää ja sen tietoja vastaan, koko kuviossa on monta mielenkiintoista ja huolestuttavaakin puolta.

Ensinnäkään moni ei varmaankaan ole oikeasti miettinyt, kuinka paljon avoimiin open source -komponentteihin oikeasti luotetaan. Tässä tapauksessa olisi ollut verrattain triviaalia saada ujutettua pahantahtoista koodia sopiviin projekteihin. Ehkä asia olisi huomattu, ehkä ei. Moni ei ole itse käynyt läpi käyttämäänsä avoimen lähdekoodin koodia, mutta voi toivoa että projektin kehittäjät kiinnittäisivät asiaan huomiota.

Toisekseen haavoittuvuuden käsittely (varsinaisesti Ruby on Railsissa) ei ehkä mennyt kaikkien taiteen sääntöjen mukaan. Selviönä ei voi pitää, että aina vakavatkaan ongelmat saataisiin oikeasti nopeasti korjattua.

Asiasta on kuitenkin nostettava esille sen perimmäinen ongelma, eli Ruby on Railsissa oleva haavoittuvuus. Se ei ole mitenkään uniikki, vaan samanlaisia ongelmia on nähty muissakin teknologioissa.

Entä kun parametreina onkin vihamielistä sisältöä

Teknisesti GitHubin tapauksessa kyse oli Ruby on Railsin ns. Mass Assignment -toiminnon väärinkäytöstä, jossa tietokantaa päivitetään automaattisesti käyttäjän lisäämien parametrien perusteella. Näin tapahtuu myös niiden kenttien osalta, joita ei ollut tarkoitettu päivitettäväksi.

Hyvin samantyyppinen ongelma todettiin vuonna 2008 Spring MVC -frameworkissa, tapaus tunnetaan nimellä Data Submission to Non-Editable Fields. Spring MVC:ssä todettiin pari vuotta sitten myös vakavampikin ongelma, jossa käyttäjän lähettämät request-parametrit käsiteltiin niin, että tuloksena palvelin lähti lataamaan taglibien koodia hyökkääjän antamasta HTTP-osoitteesta – uskomatonta mutta totta. Haavoittuvuus referensseineen on kuvattu CVE-2010-1622-dokumentissa.

Vastaavanlainen tapaus on Strutsin OGNL-lausekkeiden käsittely. Struts käsittelee käyttäjän antamia OGNL-muotoisia request-parametreja automaattisesti ja mahdollistaa esimerkiksi järjestelmäkomentojen ajamisen etänä palvelimella. Tekniikkaan liittyy lukuisa määrä vakavia haavoittuvuuksia (vanhimmasta uusimpaan CVE-2007-4556, CVE-2008-6504, CVE-2010-1870, CVE-2012-0391 ja CVE-2012-0838). Nämä haavoittuvuudet ovat siis olemassa vaikkei kyseistä toimintoa varsinaisesti käyttäisikään.

Kaikki tapaukset ovat vakavia tietoturvaongelmia. Parhaiten niitä kuvaa seuraava Dr Dobb’s Journalissa esitetty kaavio (Thompson, Whittaker: ”Testing for Software Security”, Dr Dobb’s Journal November 2002):

Pääosin ohjelmisto tekee sen mitä sen on speksattu tekevän. Kuitenkaan kaikilta osin se mitä järjestelmän speksataan tekevän, ei välttämättä päädy toteutukseen. Tällöin syntyy juuri niitä tyypillisiä ohjelmistobugeja. Yllättävää kyllä, ohjelmisto toisaalta tekee asioita, joita sen ei ole tarkoitettu tekevän.

Nämä ovat hyviä kandidaatteja tietoturvaongelmien lähteiksi, ja juuri tällaisista asioista edellä mainituissa tapauksissa on kyse.

Mistä tällainen speksaamaton toteutus sitten syntyy? Tietenkään harva koodailee järjestelmään ylimääräisiä kiemuroita ilman mitään varsinaista tarvetta, oli se kirjattu spekseihin tai ei.

Käytännössä kyse on jostain seuraavista asioista:

• Järjestelmän toimintalogiikkaa ei ole mietitty riittävän kattavasti, joten tietyillä syötteen arvoilla oikea toiminta on jätetty määrittämättä. Koska järjestelmän täytyy kuitenkin tehdä jotain syötteelle, ollaan vaarallisella vyöhykkeellä. “Hauskimpia” esimerkkejä ovat online-ostospalvelut, joissa voi esimerkiksi jättää palvelulle negatiivista tippiä. Tällöin ostoksen loppusumma pienenee sopivasti. Koska missään ei erikseen määritelty (tai mietitty) mitä negatiivisille arvoille tehdään, niin järjestelmä luonnollisesti laskee loppusumman ostosten hinnan ja tipin matemaattisena summana.

• Järjestelmässä käytetään komponentteja, jotka helpottavat koodaajan työtä ja tekevät erilaisia asioita automaattisesti ja pyytämättä. Erilaiset automaattiset request-parametrien käsittelyt menevät juuri tähän kategoriaan. Kätevä toiminto, kyllä, mutta kovin vaarallinen. Jos miettii millainen määrä koodia oikeasti ajaa tyypillistä web-tietojärjestelmää, niin räätälöidyn ohjelmakoodin osuus on häviävän pieni verrattuna frameworkeihin, komponentteihin, sovelluspalvelimen koodiin ja muuhun ajettavaan koodiin, vaikka jättäisi käyttöjärjestelmätason kokonaan huomioimatta. Tämän huomaa helposti katsomalla virhetilanteiden yhteydessä näkyviä ns. stack traceja, joissa kutsupuun muutama taso on räätälöityä koodia ja 100 tasoa kaikenlaista muuta koodia.

• Järjestelmässä on tuotantokäytön kannalta kuollutta koodia, esimerkiksi testaukseen ja vianselvitykseen käytettävää logiikkaa. Tällaista logiikkaa voi tietenkin olla myös muualla kuin räätälöidyssä koodissa, tyypillisesti vaikkapa frameworkin esimerkkikoodin muodossa.

Pahantahtoisen koodin ja takaporttien mahdollisuutta ei tietenkään voi sulkea pois, mutta käytännössä tällaiset tapaukset ovat kovin harvinaisia.

Mitä asialle sitten pitäisi tehdä?

Pohjimmiltaan pitäisi pystyä tarkasti määrittämään, mitkä ovat järjestelmän kannalta sallittuja ja odotettuja syötteitä (esim. URL-osoitteita, parametrien nimiä ja syötteiden arvoja). Kaikki muu pitäisi olla kiellettyä. Käytännössä tällaisen teknisen määrityksen muodostaminen, ylläpitäminen ja tekninen käyttö on hyvin hankalaa. Yhtenä vaihtoehtona on varmistaa, että käyttäjältä hyväksytään vain toimintoja ja syötteitä, jotka järjestelmä itse tarjoaa käyttäjälle. Parhaimmillaan tähän soveltuu käytetyn UI-frameworkin omat suojaukset (esim. linkkien kryptaus à la Wicket), mutta ulkoisiakin komponentteja voi sovitella paikalleen (esim. HDIV). Voi myös kerätä lokia järjestelmälle tulevista syötteistä ja parametreista ja sitten määrittää sallittu syötejoukko. Tietysti itse syötteiden arvoja harvoin pystyy kiinnittämään.

Jos ongelman onnistuu taklaamaan, samalla tulee usein hoitaneeksi OWASP:in Top 10 -listan ongelmat A4, A5 ja A8. Käänteisesti toimiminen ei kuitenkaan toimi eli Top 10 -listan huomioiminen ei suojaa tällaisilta ongelmilta.

Pahimpaan on kuitenkin syytä varautua ja rakentaa järjestelmän puolustus useamman kerroksen varaan ja hyviä periaatteita noudattaen. Toimiva komponenttihaavoittuvuuksien seuranta on myös keskeinen osa haavoittuvuuskartalla pysymistä.

Vielä lyhyesti alun GitHub/Ruby on Rails -ongelmaan. Hyviä yksirivisiäkin puolustustapoja sitä vastaan löytyy, kunhan niistä ollaan tietoisia ja velvoitetaan koodaajatkin seuraamaan valittua toimintatapaa. Tapa tulee kirjata kehittäjien Secure Coding Guidelinesiin tai vastaavaan käytännön ohjeeseen. Ja jos ohjeistusta ei vielä ole, sellainen on viimeistään nyt hyvä muodostaa ja ottaa käyttöön.

Lisää aiheesta: How Homakov hacked GitHub and the line of code that could have prevented it

SANS-instituutin Ed Skoudis lähestyi taannoin tietoturva-asiantuntijaamme luettuaan ratkaisuehdotuksia sovellustestaamiseen SANS:n murtotestauskurssien postituslistalta. Jaamme nyt nämä Miika Turkian postituslistalle lähettämät vinkit ja ajatukset kuvankaappauksineen blogin lukijoille.

Monet asiakassovellukset lähettävät tietorakenteita tai olioita sarjallistetussa muodossa palvelimelle. Näitä sovelluksia on paljon sekä älypuhelimissa että perinteisen tekniikan PC-ohjelmistoissa. Tällaisen liikenteen testaus vaatii uusia temppuja tavalliseen HTTP/HTTPS-liikenteeseen verrattuna. Perinteisesti sarjallistetun liikenteen testausta on yritetty tehdä hexa-editorilla, jolloin virheiden mahdollisuus kasvaa ja testauksen kattavuus kärsii merkittävästi. Seuraava kuvaruutukaappaus näyttää perinteisen näkymän sarjalliseen liikenteeseen:

Sarjallistetun protokollan tehokas murtotestaus vaatii liikenteen muuttamiseen ymmärrettävään muotoon tutkimista ja muokkausta varten. Tämän jälkeen viesti muutoksineen sarjallistetaan automaattisesti ennen palvelimelle tai asiakassovellukselle lähettämistä. Tämä voidaan tehdä esimerkiksi PortSwiggerin BurpSuite-nimisen työkalun laajennusrajapintaa ja XStream-kirjastoa käyttäen, jolloin käytettävissä on kaikki tutut BurpSuiten testaustyökalut. Sarjallistettu liikenne muutetaan XML-muotoon analyysiä ja testausta varten, kuten seuraava kuvaruutukaappaus osoittaa:

Kuvassa Javan sarjallistettu olio on selväkielisessä muodossa ja muokkaus on varsin helppoa, kun esimerkiksi tekstikentän pituudet lasketaan automaattisesti taustalla. BurpSuiten Intruder -fuzzaus-työkalu onkin esimerkissämme konfiguroitu testaamaan sekä numeerista että tekstimuotoista kenttää sopivilla syötteillä automaattisesti. Jäljelle jää testin varsinainen suoritus ja tulosten analysointi.

Tällä menetelmällä olemme löytäneet huomattavan määrän ongelmia, jotka olisivat ennen menetelmän kehittämistä suurelta osalta jääneet havaitsematta. Esimerkiksi käyttövaltuuksien nostaminen ja toisena käyttäjänä esiintyminen, mielivaltaisten tiedostojen lataus palvelimelta ja SQL-injektio. Kuitenkin ehkä suurin etu tekniikan käytöstä on liiketoimintalogiikan testauksen merkittävä tehostuminen – ellei peräti mahdollistuminen.

Yleisenä havaintona asiakassovellusten testauksesta voi todeta, että erillisen sovelluksen tuottamaan näennäiseen turvaan luotetaan vielä enemmän kuin mitä web-sovelluksissa usein näkee. Asiakassovelluksen erilaiset tarkistukset ja datan piilottaminen kuvitellaan toimivaksi ratkaisuksi, kun verkon yli lähetettävä tieto ei ole selväkielisessä muodossa. Onneksi tällaiset heikkoudet on helppo havaita, kun verkkoliikenne analysoidaan XML-muodossa perinteisen binäärisen “mössön” sijaan.

Varsinainen artikkeli on kirjoitettu tietoturvaorganisaatio SANS:in uuteen murtotestaukseen keskittyvään blogiin, josta kiinnostuneet voivat käydä lukemassa tarkemmat yksityiskohdat. Koko SANS:in uusi murtotestaussivusto on hyödyllinen tietolähde kaikille aiheen parissa työskenteleville.

Kirjoittaja Miika Turkia toimii Nixussa johtavana tietoturvakonsulttina Inspect-yksikössä.

Tietojärjestelmien suunnittelu on edelleen vaikeaa ja valitettavan usein suuret hankkeet epäonnistuvat tavoitteissa budjetin ja aikataulun osalta. Kiire ja puutteellinen suunnittelu aiheuttavat myös vakavia virhetilanteita, jotka puutteellisen testauksen takia havaitaan vasta tuotannossa. Kun ydintoiminnallisuudenkin toteuttaminen on näin vaikeaa, niin miten hyvin suunnittelussa on sitten otettu huomioon järjestelmien tietoturvavaatimukset?

Oma kokemukseni tietojärjestelmien tarkastuksista osoittaa, että tietoturvaa ei edelleenkään oteta riittävissä määrin huomioon suunnittelun alkuvaiheessa. Tietoturva on edelleen tarkistuspiste järjestelmien käyttöönoton yhteydessä.

“Onhan meidän järjestelmät turvallisia, koska meidän koodarit ovat tosi taitavia.”

Ja yleensä koodarit ovatkin taitavia, ongelmana on vain, että toteuttajat toteuttavat asiat määritysten mukaan. Suunnitteluvaiheessa tietoturvakontrolleja otetaan mukaan, silloin kun niitä otetaan, käyttäen apuna yleisesti tunnettuja hyviä käytäntöjä. Yleisesti hyviksi todettujen käytäntöjen hyödyntäminen ei välttämättä ole huono asia, mutta on hyvä muistaa, että ne ovat edelleen yleisiä, eikä kyseiselle järjestelmälle liiketoimintaperusteista johdettuja kontrolleja ja vaatimuksia. Usein lopputulos on, että arkkitehti tai suunnittelija tekee johtajien puolesta päätökset järjestelmälle hyväksytyistä riskeistä, ilman johtajien liiketoimintanäkemystä. Tietenkään johtajilta ei voi ottaa pois vastuuta, joten he joutuvat hyväksymään arkkitehdin näkemykset heidän kyvystään kantaa riskejä. Kuulostaako hyvältä?

Kuinka liiketoimintariskit saadaan prosessiin mukaan?

Kuinka olisi mahdollista kehittää tietojärjestelmät niin, että:

• Tietoturvariskit olisivat liiketoiminnalle selkeästi esitettävissä ja siten tietoisesti hyväksyttävissä

• Järjestelmien suunnittelussa otettaisiin alusta asti huomioon liiketoimintariskit

• Tietoturvakontrolleihin olisi selkeä liiketoiminnallinen tarve

• Liiketoiminnallinen tarve olisi mahdollista jäljittää toteutetussa lopullisessa tietojärjestelmässä tietoturvakontrolliin ja näin perustella sen olemassaolo

Vastauksen näihin haasteisiin tuo SABSA (Sherwood Applied Business Security Architecture). Se kehitettiin jo vuonna 1995, mutta ei ole vielä levinnyt laajalti ammattilaisten tietoisuuteen Suomessa tai Euroopassa yleensäkään. Yhdysvalloissa sekä Aasian ja Australian suunnalla yritykset ovat ottaneet SABSA:n hyvin vastaan ja osaksi organisaatioiden tietoarkkitehtuuristrategiaa. Esimerkiksi Iso-Britannian puolustusministeriö ja Kanadan hallitus ovat adoptoineet standardin kehitysmallikseen.

Suomessa järjestettiin elokuussa ensimmäinen SABSA Foundation -kurssi, johon myös allekirjoittanut osallistui. Kurssia oli yritetty järjestää jo kuutisen vuotta ja viimein se saatiin tänne – sekä vetäjäksi yksi mallin kehittäjistä, David Lynas. SABSA tarjoaa kolmiportaisen sertifiointiohjelman tietoturva-arkkitehdeille: Foundation (SCF), Practitioner (SCP) ja Master (SCM).

SABSA on liiketoiminnan näkökulmasta lähtevä malli kehittää tietoturvaratkaisuja, tietoturva-arkkitehtuureja, organisaation tietoturvastrategiaa, tietoturvapalveluja ja yksittäisiä tietojärjestelmiä tai komponentteja. SABSA:n kuusitasoinen malli kattaa kaikki neljä IT-kehityksen vaihetta: strategia, suunnittelu, toteutus ja hallinta sekä operointi. Riskipohjainen lähestymistapa yhdistettynä kaksisuuntaiseen jäljitettävyyteen toteutuksesta liiketoimintavaatimuksiin ja päinvastoin mahdollistaa selkeän näkymän myös yrityksen johdolle. Toteutetut tietoturvakontrollit ovat myös mitattavissa ja siten niiden hyödyllisyys on todistettavissa. Mallia on mahdollista hyödyntää myös erittäin kompleksisissa ympäristöissä ja se on siten hyvin skaalautuva eri käyttötarkoituksiin. SABSA on myös täysin yhteensopiva muiden mallien kuten ISO 27000, ITIL ja CobIT kanssa.

Laajemmin asiaa voi käsitellä organisaation tietoarkkitehtuuristrategiana (Enterprise Architecture, EA). Tällä hetkellä ehkä suosituin käytetty malli on TOGAF (The Open Group Architecture Framework), joka tarjoaa työkalut informaatioarkkitehtuurin suunnitteluun, kehittämiseen, toteutukseen ja hallintaan (governance). Merkittävä uutinen SABSA:n kannalta on, että TOGAF tulee integroimaan SABSA:n osaksi tietoturvaosuuttaan, mikä tulee varmasti lisäämään SABSA:n käyttöönottoa maailmalla.

Seuraava SABSA-kurssi Suomessa on suunniteltu toukokuulle 2012, joten rohkeasti mukaan!

Kirjoittaja Jari Pesonen toimii Nixussa tietoturva-arkkitehtuurien konsulttina ja tietojärjestelmien auditoijana.

Työntekijämme vierailevat säännöllisesti luennoimassa tietoturva-alan tilaisuuksissa. Tässä kuussa nixulaisia oli puhumassa OWASP-järjestön Suomen paikallisjaoksen kevätkauden viimeisessä tilaisuudessa Helsingissä.

Ari Kesäniemen aiheena oli Mobile application threat analysis ja Nixu Open -yksikköä edustanut Juhani Mäkelä taas piti esityksen otsikolla Why Privacy Matters? – Some thoughts about privacy and mobile application security.

Esityksiin voit tutustua PDF-muodossa OWASP Helsinki -jaoksen sivuilla vaikket tilaisuuteen olisi päässytkään osallistumaan.

Esitykset ovat englanninkielisiä.

Mikä OWASP?

Verkkosovelluksien tietoturvaan keskittyneen, kansainvälisen vapaaehtoisjärjestö OWASP:n (Open Web Application Security Project) tarkoituksena on edesauttaa turvallisten sovellusten kehitystä ja ylläpitoa OWASP Helsinki Chapter -alajaos perustettiin Suomeen vuonna 2006.

Käsittelimme tällä viikolla samalla otsikolla Windows-alustan turvaton DLL-kirjastojen lataus -haavoittuvuutta. Tämä jatko-osa pureutuu tietoturvallisiin sovelluskehitystapoihin ja haavoittuvuudelta suojautumiseen:

Huolestuttavinta kyseisessä haavoittuvuudessa kuitenkin on se, että haavoittuvia sovelluksia epäilemättä julkaistaan vielä tulevaisuudessakin. Microsoft ei voi muuttaa ohjelmistokirjastojen lataamisrutiineja olemassa olevissa Windows-käyttöjärjestelmissä ymmärrettävästi, joten vastuu jää Windows-sovelluskehittäjille. Kuten kävimme läpi haavoittuvuuden ydin on tavassa, jolla sovellukset kutsuvat erillisiä kirjastoja. Lyhyt oppimäärä kirjastokutsuista tiivistyy seuraaviin kolmeen ohjeeseen:

1) Käyttäessäsi ohjelmassasi mitä tahansa alla olevia (tai muita kirjastoja muistiin lataavia) Windows-funktioita

CreateProcess

ShellExecute

WinExec

LoadModule

_spawn*p

_exec*p

Näistä lihavoidut viittaavat kaikkiin funktion erinimisiin versioihin

2) Määritä aina absoluuttinen hakemistopolku ladattavaan kirjastoon (DLL) tai ohjelmatiedostoon (EXE)

tai

3) Käytä Windows-funktioita GetWindowsDirectory, GetSystemDirectory tai SetDllDirectory kontrolloidaksesi kirjastohakuja tai määritä sovelluksen toiminnallisuus sovelluksen mukana jaeltavassa Manifest-tiedostossa.

Neuvoja ja työkaluja verkosta

Kannattaa tutustua myös verkosta löytyvään materiaaliin, sillä haavoittuvuus on monimutkainen ja tarjolla on erilaisia tapoja torjua hyökkäyksiä sekä sovelluskehittäjille, loppukäyttäjille että verkkojen ylläpitäjille. ACROS Security on pitkälti vastuussa koko haavoittuvuuden saattamisesta yleiseen tietoisuuteen. He ovat koostaneet myös erinomaisen oppaan sovelluskehittäjille ja ylläpitävät BinaryPlanting.com-sivustoa, johon on koottu erilaista haavoittuvuuteen liittyvää materiaalia.

Microsoft on julkaissut suojausneuvoja sisältävän artikkelin yksittäisten ohjelmistopäivitysten lisäksi sekä käsitellyt haavoittuvuutta useissa blogikirjoituksissa. Microsoft on myös julkaissut uhkaa lieventävän rekisterimerkinnän ja Fix It -työkalun sen käyttöönottoa helpottamaan.

Metasploit-sovellukseen on saatavilla moduuli, joka automatisoi hyökkäyksen ja Metasploitin kehittäjä H D Moore on niin ikään laatinut blogikirjoituksen haavoittuvuudesta ja julkaissut auditointisovelluksen ohjelmistojen testausta varten.

Kuten puskurin ylivuotovirhekin myös DLL-kirjastohaavoittuvuuden ovat löytäneet lukuisat eri tutkijat ja tässäkin kirjoituksessa mainitut listat haavoittuvista ohjelmistoista päivittyvät edelleen. Ensimmäinen merkintä haavoittuvuudesta löytyy vuodelta 2000, jolloin Georgi Guninski lähetti win2ksecadvice-postituslistalle viestin, jossa varoitettiin ylimääräisten ohjelmien ajosta Microsoft Office -dokumenttien avaamisen yhteydessä. Viime talvena Kalifornian yliopiston opiskelija Taeho Kwon määritteli automaattisen metodin sovellusten auditointia varten tutkimustyössään [PDF]. Laajemmalti haavoittuvuus nousi julkisuuteen kuitenkin vasta viime syksynä.

Yksi viime vuoden merkittävistä tietoturvauutisista oli Windows-alustan turvaton DLL-kirjastojen lataus -haavoittuvuuden (DLL Hijacking vulnerability) julkaisu. Microsoft ilmoitti viime viikolla, että tammikuun päivitysjulkaisun myötä kaikki tunnetut DLL Hijacking -haavoittuvuudet Microsoftin omissa ohjelmissa on nyt paikattu.

Kyse on oikeastaan pikemminkin uudesta haavoittuvuusluokasta kuin yksittäisistä haavoittuvuuksista. Aivan kuten 15 vuotta sitten tietoturva-asiantuntijat koostivat kuumeisesti listoja C-ohjelmointikielen funktioista, jotka eivät tarkistaneet vastaanottamaansa syötettä ja näin altistuivat puskurin ylivuotovirheille, nyt on korkea aika alkaa koostaa listoja eri Windows-funktioiden tavoista ladata erillisiä ohjelmistokirjastoja ja ohjelmatiedostoja sovellusten käyttöön.

Windows-alustallahan sovellukset koostuvat nykyään lukuisista erillisistä ohjelmistokirjastoista, jotka yhdessä tuottavat ohjelman toiminnallisuuden. Näistä kirjastoista käytetään nimeä Dynamic Link Library eli DLL. Nämä dynaamiset ohjelmistokirjastot mahdollistavat ohjelmakoodin vaivattoman kierrätyksen ja sallivat ohjelmoijien käyttää joko käyttöjärjestelmän tai muiden sovelluskehittäjien luomaa ohjelmakoodia suorittamaan tarvitsemiaan toimintoja.

Jokainen käyttöjärjestelmäalusta määrittelee erikseen rutiinit tällaisten erillisten, uudelleenkäytettävien ohjelmistokirjastojen käytölle. Windows tarjoaa lukuisia funktioita erillisten kirjastojen lataukselle sovellusten tueksi. Yleisesti ottaen sovellukset voivat ladata kirjastoja käyttöönsä kahdella tavalla:

• joko määrittelemällä tarkan tiedostopolun, josta kirjasto löytyy (esimerkiksi C:\Windows\System32\esimerkki.dll)

• tai määrittelemällä pelkän kirjaston nimen (esimerkiksi LoadLibrary(esimerkki.dll)), jolloin käyttöjärjestelmä lataa kirjaston etsimällä sitä tietyistä hakemistoista tietyssä järjestyksessä.

Nimenomaan jälkimmäinen tapaus mahdollistaa turvaton DLL-kirjastojen lataus -haavoittuvuuden hyväksikäytön. Jos olet törmännyt viime syksystä lähtien termeihin DLL Hijacking tai Insecure Library Loading on kyseessä juuri samainen haavoittuvuus. Kaivaudutaanpa hieman syvemmälle.

Ja kuinka kirjastotiedoston haku sitten toimii

Käytetään esimerkkinä Windowsin CreateProcess-funktioita. Mikäli sovellus lataa erillisen ohjelmistokirjaston määrittelemällä pelkästään kirjaston nimen CreateProcess-funktiota käyttäen, Windows etsii kirjastoa seuraavista hakemistoista seuraavassa järjestyksessä:

1. Hakemisto, josta kutsuva sovellus käynnistettiin
2. Senhetkinen työhakemisto
3. 32-bittinen Windows System -hakemisto (Windows\System32)
4. 16-bittinen Windows System -hakemisto (Windows\System)
5. Windows-hakemisto
6. PATH-muuttujassa määritellyt hakemistot

Kuvitellaan, että sovellus lataa kirjaston, jonka oikea versio on esimerkiksi Windows-hakemistossa. Mikäli hyökkääjä kopioi kirjastosta haitallisen, mutta samannimisen version esimerkiksi senhetkiseen työhakemistoon, Windows lataa haitallisen version kirjastosta sovelluksen käyttöön sitä sen kummemmin tarkistamatta. Tilannetta pahentaa se, että kulloinenkin työhakemisto voi olla myös verkkolevyllä tai esimerkiksi pakattu hakemisto, joka avataan kohdekoneessa. Ja pahentunutta tilannetta pahentaa edelleen se, että suurin osa ylläolevasta pätee sellaisenaan myös erillisiin EXE-tiedostoihin, joita sovellukset mahdollisesti lataa ajon aikana käyttöönsä.

Kirjasto täytyy saada vielä ajettua – onnistuu

Yksi konkreettinen hyökkäys voisi olla seuraavanlainen. Hyökkääjä tietää kohteensa käyttävän Windows Vista -käyttöjärjestelmää ja tietää, että koneelle on asennettu haavoittuvuuden sisältävä Microsoft PowerPoint 2007. Hyökkääjä lähettää kohteelle linkin paikalliselle verkkolevylle, johon hän on tallentanut kohdekäyttäjää kiinnostavan PowerPoint-esityksen nimeltään XXX.ppt ja haitallisen kirjaston nimeltä rpawinet.dll. Kohteen avatessa tiedoston XXX.ppt, PowerPoint 2007 lataa kirjaston nimeltä rpawinet.dll ja alkaa etsimään sitä tiedostojärjestelmästä. Kyseistä kirjastoa ei löydy Windows Vista -käyttöjärjestelmän systeemihakemistoista, joten käyttöjärjestelmä jatkaa etsintää, kunnes se löytää hyökkääjän tallentaman haitallisen version kirjastosta senhetkisestä työhakemistosta (paikallinen verkkolevy) ja suorittaa sen luottaen sen oikeellisuuteen.

Vastaavanlaisia hyökkäyksiä on kirjaimellisesti satoja erilaisia. Haitallinen kirjasto voidaan lähettää käyttäjälle myös pakattuna samaan ZIP-hakemistoon useiden kohdetta kiinnostavien kuvatiedostojen kanssa tai se voidaan siirtää käyttäjän koneelle musiikkia sisältävän torrent-tiedoston mukana. Huomaa, että yllä kuvailtu hyökkäys ei enää toimi täysin päivitetyssä PowerPoint 2007 -sovelluksessa, mutta haavoittuvuuden sisältäviä ohjelmia on yhä satoja ja (julkisesti) testaamattomia ohjelmia on vielä enemmän. Suurin osa isoista ohjelmistotaloista on syksyn aikana paikannut omat ohjelmansa. Exploit Database ylläpitää listaa haavoittuvuuden sisältävistä sovelluksista, josta voi myös tarkistaa päivitystilanteen.

Kirjoituksen jatko-osa keskittyy sovelluskehittäjille suunnattuihin ohjeisiin, joilla haavoittuvuus voidaan estää.

OWASP-yhteisö on julkaissut hiljattain uuden, vuoden 2010 version merkittävimpiä web-turvariskejä käsittelevästä Top 10 -dokumentistaan.

Merkillepantavaa nyt julkaistussa listassa on se, että OWASP haluaa puhua tietoturvariskeistä – ei enää haavoittuvuuksista ja tietoturvaongelmista.

Listan kolmen kärkeen kuuluvat riskit ovat hyvinkin tuttuja. Ykkösenä ovat injektiohyökkäykset, joilla tarkoitetaan taustajärjestelmäkyselyn, esimerkiksi tietokantakyselyn rakenteen muutoshyökkäystä. Myös Suomessa merkittäviä salasanamurtoja on tehty tällä menetelmällä, jossa esimerkiksi käyttöliittymien tekemiin SQL-kyselyihin liittyvä puutteellinen syötteentarkistus mahdollistaa salasanojen varastamisen tietokannasta. Muutaman kuukauden välein nähtävissä massiivisissa SQL-injektiohyökkäyksissä, joissa haittaohjelmia levitetään verkkosivuille injektoituun koodiin, on aina ollut mukana myös suomalaispalvelimilla toimivia sivustoja.

Listan toista sijaa pitävä cross-site scripting eli XSS oli vielä edellisen, vuoden 2007 Top 10 -listauksen ensimmäisellä sijalla, mutta niiden määrä ei ole tekemissämme tarkastuksissa osoittanut vähenemisen merkkejä.

Isoin sijoitusmuutos on uuden listan kolmonen - Puutteellisesti toteutettu tunnistusmenettely ja istunnonhallinta, joka oli edellisessä dokumentissa vasta sijalla 7. Myös tähän liittyviä havaintoja tehdään lähes jokaisessa Nixun tekemässä tarkastuksessa, ja se onkin ansainnut nykyisen sijansa.

Salasanat selväkielisinä saatavilla

Lopullinen lista muuttui julkaisukandidaattivaiheen sisältäneen Failure to Restrict URL Access -luokan osalta siten, että RC1-listalla vielä sijalla 7. ollut luokka putosi lopullisella listalla kahdeksanneksi. Puutteellinen tietojen salaus (Insecure Cryptographic Storage) puolestaan nousi lopullisella listalla sijalta 9. seitsemänneksi.

Tyypillisin tähän liittyvä havainto on edelleen salasanojen tallentaminen selväkielisenä, vaikka tämä on jo pitkään ollut vastoin kaikkia suosituksia.

Myös kuljetuskerroksen riittämätön suojaus (Insufficient Transport Layer Protection) nousi yhtä pykälää korkeammalle viime marraskuussa alkaneella kommentointikierroksella.

Tässä kirjoituksessa on käytetty luokista suomenkielisiä vastineita, jotka OWASP Helsinki julkaisi viime kesänä.

Mikä OWASP?

Verkkosovelluksien tietoturvaan keskittyneen, kansainvälisen vapaaehtoisjärjestö OWASP:n (Open Web Application Security Project) tarkoituksena on edesauttaa turvallisten sovellusten kehitystä ja ylläpitoa. Järjestö on voittoa tavoittelematon ja se toimii jo lähes sadassa maassa. Suomen OWASP Helsinki Chapter -niminen alajaos perustettiin reilut kolme vuotta sitten.

Tietoturvallisuus ja etenkin tietoturvattomuus on monia tunteita herättävä aihe. Nixun konsultit osallistuvat usein asiakkaiden kehityshankkeisiin, joissa arvioidaan uusien ratkaisujen tai tuotteiden tietoturvallisuutta tai sitten olemme toisella puolella pöytää kehittämässä uuden liiketoiminnan turvallisuutta.

Tietoturvallisuus tuntuu olevan hyvää markkinointia

Hieman huvittuneina olemme seuranneet myös etenkin perinteisten IT-ratkaisutoimittajien tapaa vakuuttaa asiakkaansa ratkaisunsa tietoturvallisuudesta. Monet web-palvelujen käyttäjät ovat voineet huomata kuinka heidän käyttämänsä web-palvelu on ehdottoman turvallinen koska yhteys on SSL-suojattu.

Kaikki sovellusturvallisuutta tuntevat ymmärtänevät, että tällä lausumalla on vain vähän tekemistä sen kanssa, kuinka turvallista tietojen luovuttaminen sovellukseen on.

Maailmalta on mahdollista löytää myös kaikenlaisia tietoturvatodistuksia, joiden tehtävä on vakuuttaa asiakas siitä, että palvelu on turvallinen. Huvittavin löytämämme on PCI DSS -tietoturvastandardiin kuuluvan haavoittuvuusskannauksen “korvaava” Scanless PCI -palvelu, jossa siis ei näkemyksemme mukaan ole kyse mistään muusta kuin huijauksesta.

Nixun periaatteena on tyypillisesti ollut, ettemme lähde takaamaan minkään ratkaisun tietoturvallisuutta, koska täydellinen takaaminen ei vain ole mahdollista. Jos välineitä ja aikaa on riittävästi murtautuminen yleensä onnistuu. Tällöin kyse on asiakkaan liiketoimintaan liittyvästä riskienhallinnasta, eli siitä, kuinka paljon turvallisuuteen halutaan panostaa.

Nixun tapa antaa tunnustusta tietoturvallisuudesta

Katsottuamme kuitenkin aikamme alalla vallitsevaa epäselvyyttä lanseerasimme pari vuotta sitten Nixu Security Verified -sertifikaatin SaaS-palveluille, jonka avulla pyrimme varmistamaan, että asiakas joka sertifikaattia esittää on panostanut riittävästi turvallisuuteen - eli käytännössä kaikki sovelluksen kriittisiksi luokitellut haavoittuvuudet on korjattu ja sovelluksen ylläpito ymmärtää mitä jatkuva tietoturvallisuuden ylläpito tarkoittaa.

Sertifikaatin myönnämme vain niille asiakkaillemme, jotka ylläesitetyt ehdot täyttävät, esimerkiksi asiakkaamme Balancion on esittänyt tavoitteekseen sertifikaatin hankkimisen ennen tuotantoonmenoa; betassahan tällaista sertifikaattia ei ole.

Toki teemme työtä monien muidenkin kuin sertifioitujen asiakkaiden tai sovellusten kanssa, mutta noudatetaanko suosituksiamme vai ei, on toki aina loppukädessä asiakkaan oma valinta.

Loppukädessä Nixu, eikä mikään muukaan tietoturvayhtiö, voi koskaan taata minkään sovelluksen tai järjestelmän tietoturvallisuutta. Meistä, kuten varmasti muistakin aiheeseen vakavasti suhtautuvista, on kuitenkin tärkeää, että asiakkaat panostavat asiaan ja tekevät sen kunnolla, sen sijaan että hankkisivat feikki-todistuksia markkinointinsa tueksi.

Petri Kairinen vastaa Nixun myynnistä ja markkinoinnista ja on ihmeissään seuratessaan netin tarjoamia esimerkkejä tietoturvalla tapahtuvasta myynninedistämisestä