Seurasitpa sitten suomenkielisiä tai kansainvälisiä it-uutisia olet hyvin todennäköisesti törmännyt termiin zero-day (tai zero day). Juuri joulun alla saatiin vahvistus Internet Explorerin paikkaamattomasta CSS-haavoittuvuudesta, joka on tyypillinen esimerkki nollapäivätyyppisestä haavoittuvuudesta. Loppuvuoden aikana nollapäiväaukkoja on ollut useasti Flashissa ja Adobe Readerissa ja niitä on myös hyödynnetty.

Suomen kielessä käyttöön ovat vakiintuneet pääasiassa termit nollapäivähaavoittuvuus (tai -aukko) ja zero-day-haavoittuvuus.

Nollapäivä tarkoittaa sitä, että haavoittuvuuden julkitulon ja hyödyntämisen väliin mahtuu nolla vuorokautta.

Hyödyntäminen todentaa haavoittuvuuden olemassaolon ja esimerkiksi sen, että toimiva verkkomato on pystytty kehittämään.

Käytännössä hyökkäysten alkamisen ja haavoittuvuuden julkitulon väli on siis kirjaimellisesti nolla päivää.

Nollapäivään ei korjausta saatavilla

Nollapäivähaavoittuuvuudelle on ominaista myös se, ettei siihen ole valmistajan korjauspäivitystä saatavilla.

Termi Zero Day on myös ZERT-ryhmittymän nimen innoittaja (Zeroday Emergency Response Team), ZDNetin tietoturvablogi, osa Zero Day Initiative -haavoittuvuusjulkistusohjelman nimeä ja ei-tietoturvamaailmassa mm. elokuva ja hip hop-albumi. ZERT on tietoturva-ammattilaisten ryhmä, joka julkaisi vuonna 2007 tilapäiskorjauksen Windowsin kohdistimienkäsittelyä koskevaan nollapäivähaavoittuvuuteen ennen virallisen korjauspäivityksen julkaisua.

Myöhemmin tällaisia epävirallisia korjauspäivityksiä on nähty aina silloin tällöin muihinkin nollapäivähaavoitttuvuuksiin, mutta hyvin harvinaista niiden julkaiseminen kuitenkin on.

Kirjoitus aloittaa termit tutuksi -tyyppisen kirjoitussarjan, joka tutustuttaa tietoturva-alan – erityisesti haavoittuvuuksiin liittyviin – termeihin ja lyhenteisiin.

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ää.

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ä.