TigerTeam - suomalainen tietoturvablogi

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.

Ensimmäinen mielikuva esimerkiksi luottokorttiyhtiöiden ja tietoturvatoimijoiden verkkosivustostoista on usein vaatimus korkeasta tietoturvatasosta. Aina tietoturva ei kuitenkaan toteudu käytännössä. Seurasimme lokakuussa maailmalla raportoituja XSS-tyyppisiä turva-aukkoja. Käytännössä siis esimerkiksi sitä minkä toimialan sivustoilta on raportoitu haavoittuvuuksia verkkosivun rakenteen muutoshyökkäykselle. Lähteenä oli XSS-aukkojen raportointiin keskittynyt sivusto XSSed.com ja viime kuukausina aktiisesti XSS:iä raportoineen ryhmän sivusto Team Elite - tosin täysin kattavana ei otosta kuitenkaan voida pitää.

XSS-haavoittuvuuksia on raportoitu viime kuussa mm. tunnettujen virustorjuntayhtiöiden verkkosivuilla, esimerkkinä Symantecin tapaus. Eikä kyseessä ole ainut tietoturvatoimija. Myöhemmin lokakuussa raportoitiin mm. ESETin haavoittuvuudesta.

Myös luottokorttiyhtiö Visan pääsivustolta löydettiin hiljattain cross-site scripting – eli XSS-haavoittuvuus, joka salli skriptikoodin ajamisen sivustolla.

Mutta siis mikä XSS? Cross-site scripting, lyhenteenä XSS, tarkoittaa OWASP-yhteisön suomentamin termein tilannetta, jossa “Verkkosivun rakenne ei säily”. Tällaisessa ns. verkkosivun rakenteen muutoshyökkäyksessä käyttäjän antama syöte välitetään selaimelle tarkistamatta. Lopputuloksena on sivun ulkoasun muuttuminen esim. vieraalta palvelimelta ladatulla sisällöllä.

XSS-aukkoja on olemassa useaa tyyppiä ja osalla aukoista voidaan hankkia esim. kirjautumiseen käytettävä eväste sivustolta.

Kuun viimeisinä päivinä listalle liittyivät vielä tunnettu uutissivusto Zdnet XSS-haavoittuvuuksineen sekä sunnuntaina Yhdysvaltain presidentin my.barackobama.com-sivusto, jolta haavoittuvuuksia löytyi peräti kolme kappaletta.

Visa-tapauksesta on muiden ohella tallessa kopio XSSed-sivun arkistossa. Samalla sivustolla on listattuna myös kolme American Expressiä ja MasterCardia koskevaa XSS-aukkoa.

Luottokorttiyhtiöillä aikaisemminkin samoja aukkoja

Lokakuussa raportoitujen tapausten luonne ja vakavuus vaihtelee, mutta valitettavasti suurin osa tapauksista on edelleenkin korjausta vailla. Mikään uusi asia eivät XSS:t toimijoiden sivuilla ole. Toissa jouluna VISA:n sijoittajasuhteisiin keskittynyt Investor.visa.com-sivusto kärsi myös XSS-haavoittuvuudesta, keväällä 2007 haavoittuvuus oli puolestaan Visa.com-sivuston hakutoiminnossa.

Herääkin kysymys miten XSS-haavoittuvuus on voinut jäädä luottokorttiyhtiöille tietoturva-auditoinnin tehneeltä taholta huomaamatta ja millä aikajänteellä auditoinnit on suoritettu. Sivuston koodin muututtua kun usein tulee ilmi uusia XSS-haavoittuvuuksia.

Virustorjuntatoimijoiden sivuilta aukot löytänyt ja julkistanut ryhmä Team Elite kuuluu ns. valkohattuhakkereihin eli ryhmän toimintaperiatteena on julkaista tieto haavoittuvuuksista vasta kun ne on saatu korjattua. Aina eivät turva-aukkojen löytäjät kuitenkaan toimi vastuullisesti. Joka tapauksessa – raportoitiin aukot vastuullisesti tai ei – ei XSS:n löytyminen maailmanlaajuisen luottokorttiyhtiön sivustolta ainakaan eduksi toimijan maineelle ole.

Vain vuosi siitä kun edellinen versio BSIMM:stä tuli ulos McGraw, Miguel ja Chess ovat päivittäneet BSIMM:n uuteen 2.0-aikaan. BSIMM (Build Security In Maturity Model) on tietoturvallisen ohjelmistokehityksen kypsyysmalli, jonka avulla voidaan arvioida organisaation kyvykkyyttä tuottaa tietoturvallisia ohjelmistoja. Kysymys on siis siitä kuinka hyvin tietoturva otetaan ohjelmistokehityksen aikana huomioon. BSIMM:n tekijöillä on ollut tavoitteena muodostaa sellainen malli, jota oikeasti on käytetty käytännössä, ja tekijät ovat keränneet eri yrityksiltä tietoa siitä, millä keinoilla ja menetelmillä yritykset ovat toteuttaneet tietoturvallista ohjelmistokehitystyötä.

Pienempiä toimijoita mukana otoksessa

Tällä kerralla muutokset mallissa ovat olleet pieniä, mutta haastateltujen yritysten määrä on kasvanut 30:een, ja mukaan on tullut aikaisempaa pienempiä yrityksiä. Tietoahan ei ole julkaistu suoraan, mutta se on pääteltävissä keskiarvojen pienentymisestä.

Yksi merkittävimmistä tunnusluvuista kuitenkin on pysynyt samana – tietoturvallisen ohjelmistokehityksen yksikön koko on vieläkin 1 % ohjelmistokehittäjien lukumäärästä. Tietoturvaa saa siis halvalla? Ehkä ei niinkään. Mallissa on 109 tehtävää tai toimintoa, joista jokaista harrastetaan siis vähintään yhdessä yrityksessä. Parhaimmat yritykset pystyvät kuitenkin tekemään samanaikaisesti 74 näistä, ja huonoimmat yhdeksän keskiluvun ollessa noin viidenkymmenen paikkeilla. Eli prosentilla saa noin puolet tietoturvasta? Onko malli liian kunnianhimoinen, vai onko osa tehtävistä sellaisia, jotka vain soveltuvat erityisen hyvin jollekin organisaatiolle? Ilmeisesti ainakaan mallin tekijöiden mielestä tehtäviä ei ollut liikaa, sillä 2.0-versiopäivityksessä vain niiden tasoja korjailtiin.

Mikä sitten harvojen herkkua?

Kuitenkin mallissa on vielä kuusi tehtävää, joita tekee vain muutama yritys. Automaattiseen koodivirheiden analysointiin ja raportointiin, missä otetaan huomioon havainnot useasta lähteestä, uskoo vain yksi yritys. Tällaisen rakentamiseenkin toki voi jo mennä vuosi jos toinenkin, ja tulevaisuus näyttää, pysyykö tämä mielenkiintoinen mutta epäilemättä harvoin kustannustehokas koodinkatselmointityökalu mallissa mukana.

No mitä useimmat tekevät? 66 % yrityksistä tekevät näitä, mutta kirjoittajatkin myöntävät, että tilastoista ei taida olla mallin tekijäksi, vaan suosittelevat, että tietoturvallista ohjelmistokehitystä kehittävät harkitsisivat seuraavia toimenpiteitä:

• Tietoturvakriteerien asettaminen [SSDL Gates]

• Vaatimuksenmukaisuusvaatimusten [Compliance] ymmärtäminen (PCI, SOX, HIPAA, VARe, VAHTI, tietoturvatasot)

• Yksityisyydensuojan tietoisuuden korostaminen [promote]

• Ohjelmistokehityksen tietoturvapolitiikan luominen asiakastarpeita ja säätelyä vastaavaksi

• Tietoturvatietoisuuskoulutuksen järjestäminen

• Tiedon luokitteluun ja säilytykseen tarkoitetun järjestelmän luominen

• Asiakkaan tarpeita vastaavien tietoturvastandardien luominen

• Tietoturvavaatimuksien katselmointi

• Sekä automaattisten työkalujen että manuaalisen katselmoinnin käyttäminen

• QA:n raja-arvotestauksen tukemisen varmistaminen [edge/boundary value condition testing]

• Ulkoisen hyökkäystestaajan käyttäminen

• Verkon suojauksen varmistaminen

• Poikkeustilaprosessien luominen

• Tuotannossa havaittujen virheiden vieminen tuotekehitykseen

Lista ei vaikuta mitenkään hirvittävän vaativalta, ja voihan olla, että nämä tehtävät toteutetaan suurimmassa osassa yrityksiä, koska ne nyt vain ovat helpoimpia. Mallin kattavuuden arviontia eivät ulkopuoliset tämän tarkemmin pääse arvioimaan, koska kirjoittajat eivät julkista tarkempia tutkimustietoja.

BSIMM sinällään näyttäisi olevan mielenkiintoinen malli tietoturvallisuuden ohjaamiseen, joka korostaisi mallin käytettävyyttä verrattuna ylhäältä annettuun malliin. Tällä hetkellä joko suppeahko otos verottaa johtopäätösten tekemistä tai malli sinällään ei toimi. Se ei kylläkään vie arvoa yhdestäkään mallissa esiteltävästä tehtävästä ja aivan varmasti voidaan todeta, että jos yritys pystyy toteuttamaan puoletkin näistä tehtävistä on tietoturvan taso merkittävästi paremmalla tolalla kuin ilman näitä tehtäviä.

Vertailun vuoksi voidaan mainita, että erilaisia kypsyysmalleja tietoturvalliseen ohjelmistokehitykseen on olemassa useita, joista OWASPin OpenSAMM lienee viimeisin, ja SSE-CMM niitä vanhimpia, ja se on viety ISO-standardiksi ISO/IEC ISO 21827 saakka. Microsoftilla on oma SDL (Security Development Lifecycle) ja OWASPilta löytyy vielä CLASP-prosessinsa – Comprehensive, Lightweight Application Security Process. Nixu tarjoaa Turvaluotsi-palvelua ohjelmistokehityksen tietoturvan parantamiseksi. Palvelu on toteutettu käyttäen hyväksi alan parhaita käytäntöjä.

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.

Sovellustietoturvallisuuden kehittymistä suomalaisissa organisaatiossa läheltä seuranneena huomaan edelleen törmääväni usein siihen, että sovelluksia ostavilla tai sovelluksia kehittävillä henkilöillä on vääriä käsityksiä sovellustietoturvallisuudesta tai jopa perustiedot sovellustietoturvallisuudesta puuttuvat.

Nykyistäkin perustietämystasoa kuvaa hyvin eräs vuoden takainen uutinen, jossa tunnettua suomalaista web-palvelua pyörittävän yrityksen toimitusjohtajalta kyseltiin ovatko palvelun käyttäjätunnukset ja salasanat turvassa, kun juuri aikaisemmin olivat erään toisen web-palvelun käyttäjätunnukset ja salasanat vuotaneet julkisuuteen. Toimitusjohtajan vastaus oli, että käyttäjätunnukset ja salasanat ovat turvassa – ne ovat kahden palomuurin takana.

“Meidän sovelluksemme on suojattu, meillä on palomuurit, virustorjunta ja IDS”, “Mutta kun meidän sovelluskehitys-framework huolehtii näistä tietoturva-asioista”, “Meidän organisaation tietoturva-asiantuntijat hoitavat nämä asiat”. Kuulostaako tutulta?

Näyttää siltä, että kestää vielä tovin kunnes sovelluksen ostaja tai peruskehittäjäkin tiedostaa, että se sovelluksen tietoturvallisuus on omasta työstä kiinni. Ei ole olemassa mitään maagista verkkolaitetta tai tietoturvaohjelmistoa joka huolehtisi siitä, että sovelluksen tiedot olisivat turvassa, jos sovellus itsessään on haavoittuva.

Sovellustietoturvaa läpi koko prosessin

Alan mediakin keskittyy sovellustietoturvasta puhuttaessa vain uusien haavoittuvuuksien uutisointiin. Hyvin harvoin artikkeleissa puhutaan turvallisesta sovelluskehityksestä ja mistä johtuu se, että sovellukset alun alkaenkin ovat niin haavoittuvia.

Onneksi valoa on näkyvissä tunnelin päässä. Useat organisaatiot ovat vihdoin heräämässä ja käynnistäneet hankkeita sovellustietoturvallisuuden tietoisuuden kasvattamiseksi ja oman sovelluskehitys- tai sovellushankintaprosessin uudistamiseksi, niin että tietoturvallisuus tulee huomioitua heti jo uutta sovellusta suunniteltaessa.

Toivottavasti myös alan oppilaitoksetkin pikkuhiljaa alkaisivat ottamaan sovellustietoturvallisuutta opetusohjelmiinsa. Ainakin TKK:lla sovellustietoturvallisuus on melko tuntematon käsite. Lähimpänä tätä aihepiiriä olevat tietoturvallisuuden kurssit keskittyvät vielä verkkoprotokollatasolle.

Sovellustietoturvallisuuteen perehtyminen kannattaa aloittaa OWASPin sivuilta. OWASP (Open Web Application Security Project) on voittoa tavoittelematon organisaatio, jonka tarkoituksena on kasvattaa tietoisuutta ja kehittää sovellusturvallisuutta. Vapaasti kaikkien käytettävissä oleva ASVS (Application Security Verification Standard) on OWASPin ensimmäinen standardi. Standardissa kuvattuja vaatimuksia voidaan käyttää esim. sovelluksen turvallisuusvaatimuksia määriteltäessä, ohjeistuksena sovelluksen turvakontrollien toteutuksessa tai arvioitaessa jo valmiin sovelluksen tietoturvallisuuden tasoa.

Kirjoittajasta:

Inspect-yksikön vetäjä Petteri Arola aloitti vuoden alussa OWASP:n Suomen alajaoksen OWASP Helsinki Chapterin vetäjän tehtävässä.