DLL-kirjastoista ja niiden lataamisesta - jatkotarinan osa II: "Puolustus"

Jatkotarinan ensimmäisessä osassa kävin läpi vime päivinä paljon kiinnostusta herättäneen DLL-hyökkäyksen toteuttamisen Windowsia ja jotain sovellusta vastaan. Eka osa päättyi hermoja raastavaan tilanteeseen, jossa hyökkääjä oli onnistunut ujuttamaan sovellukseen SOVELLUS haluamaansa ohjelmakoodia DLL-kirjaston KIRJASTO.DLL välityksellä. Ja nyt tietysti kaikkia lukijoita kiinnostaa, miten tuollaiselta hyökkäykseltä suojaudutaan.

Kerrataanpa vielä, ongelman ydin oli siis siinä, että sovelluksessa ladattiin DLL-kirjasto, mutta latauskutsussa ei määritetty sen polkua. Tällöin Windows lähtee etsimään ko. DLL-kirjastoa joukosta hakemistoja, joista yksi on nykyinen työhakemisto, jota vihamielinen hyökkääjä siis pääsee kontrolloimaan houkuttelemalla käyttäjän avaamaan jonkin haluamansa tiedoston esim. jostain verkkokansiosta, josta siis tulee nykyinen työhakemisto. Nyt jos hyökkääjä sijoittaa haluamansa KIRJASTO.DLL-kirjaston samaan kansioon tiedoston kanssa, on peli menetetty.  

No miten tätä sitten muutetaan? DLL-kirjastojen latausta ei Windowsissa voi muuttaa, koska se on oleellinen osa kaikkien sovellusten toimintaa. Mutta voisiko muuttaa sovelluksen toimintatapaa - mitä jos sovelluksessa määritettäisiin DLL-kirjaston tarkka polku? Hyvä pointti, mutta jätetään sovellukseen tehtävät muutokset kutkuttavasti kolmanteen ja finaaliosaan ja ohitetaan ne hetkeksi. Mitä muuta voisimme tehdä? Olisiko mahdollista ohittaa DLL-kirjaston hakeminen nykyisestä työhakemistosta? Loistavaa - kymmenen pistettä ja papukaijamerkki!

Puolustus I - muutetaan hakujärjestystä:
Juuri näin onkin jo osittain tehty, Windowsissa aiemmin tuo hakujärjestys nimittäin meni niin, että DLL-kirjastoa, jonka tarkkaa polkua ei ole määritetty, etsittiin nykyisestä työhakemistosta jo heti toisena sen hakemiston jälkeen, josta sovellus on käynnistetty. Tätä kuitenkin muutettiin jo Windows XP:n SP2:n myötä, juuri näiden DLL Preloading -ongelmien takia. Eli nyt Windowsin mukana tulevat DLL:t ovat etusijalla ja DLL-kirjastoa etsitään nykyisestä työhakemistosta vasta sovelluksen käynnistyshakemiston ja Windowsin hakemistojen jälkeen, mikä pienentää riskiä jonkin verran.  

Uutena Microsoft on muuttanut DLL-kirjastojen lataustoiminnallisuutta (eli noiden aiemmin mainittujen LoadLIbrary- ja LoadLibraryEx-kutsujen toimintaa). Nyt rekisteriin voidaan lisätä joko kaikkiin sovelluksiin tai johonkin tiettyyn sovellukseen vaikuttava rekisteriavain, jonka avulla voidaan määrittää, että nykyisestä työhakemistosta ei DLL:iä haeta ollenkaan tai ei haeta ainakaan siinä tapauksessa, että nykyinen työhakemisto sijaitsee jossakin verkossa, paikallisen koneen ulkopuolella. Tämä edellyttää kuitenkin kahta asiaa:

1. Windowsiin asennetaan erillinen korjauspaketti, joka muuttaa lataustoiminnallisuutta.
2. Rekisteriin määritetään joko kaikkiin sovelluksiin tai johonkin yhteen tiettyyn sovellukseen vaikuttava rekisteriavain, joka määrittää, miten nykyistä työhakemistoa käsitellään DLL-kirjastoja haettaessa.

Molemmista edellämainituista kohdista on lisätietoja KB-artikkelissa 2264107. KB-artikkelissa on myös linkit korjauspaketteihin eri Windowsin versioita varten (korjauspaketit ovat ladattavissa myös Microsoftin lataussivustosta,  josta niitä voi etsiä käyttämällä hakusanana KB-artikkelin numeroa 2264107). Toki kannattaa huomata, että jotkin sovellukset on ohjelmoitu hyödyntämään DLL-kirjaston lataamista myös nykyisestä työhakemistosta, ja muutosten tekeminen saattaa vaikuttaa sovellusten toimintaan. Eli muutosten vaikutus käytössä oleviin sovelluksiin kannattaa ja pitää testata.  

Puolustus II - rajoita lähteitä:
Tuo on siis yksi, muttei suinkaan ainoa tapa, jolla DLL-hyökkäysten aiheuttamaa riskiä voidaan pienentää. Mitä muuta voidaan tehdä? Luonnollisesti voidaan rajoittaa sitä, missä tuo nykyinen työhakemisto sijaitsee, tai ehkä pikemminkin sitä, mistä LoadLibrary pystyy DLL-kirjaston lataamaan. Avattava tiedosto ja hyökkääjän DLL-kirjasto voidaan sijoittaa esim. johonkin verkon tiedostoresurssissa olevaan kansioon, esim. Z:\kansio tai \\palvelin\tiedostoresurssi\kansio. Tällöin tiedostoja käytetään SMB-protokollan välityksellä, ja koska SMB-protokollan käyttö voidaan palomuureissa estää, voidaan tämä luonnollisesti rajoittaa organisaation sisäverkkoon. Lisätietoja SMB-protokollan käytön rajoittamisesta on englanninkielisen Security Advisoryn kohdassa Workarounds.

Tiedoston avaaminen ja DLL-kirjaston lataaminen voidaan kuitenkin tehdä Windowsissa myös WedDAV-protokollan välityksellä, jolloin yhteys toteutetaan HTTP-yhteytenä. Windowsissa on palvelu nimeltään Web Client, joka toteuttaa WebDAV-protokollan, ja jonka välitykselläö tiedostojen lataaminen suuntaan ja toiseen tapahtuu. Tässä, kuten monen aiemmankin haavoittuvuuden kohdalla, riskiä voidaan pienentää a) estämällä WebDAV-yhteydet palomuureissa organisaation verkon ja julkisen verkon välissä, tai b) poistamalla Web Client -palvelu käytöstä. Jälkimmäisestä on myös lisätietoja englanninkielisen Security Advisoryn kohdassa Workarounds.

Kuten tämän artikkelin alussa jo vähän viitattiin, kolmas ja varmasti tehokkain puolustus onkin sitten muuttaa itse sovelluksen toimintaa. Ja nyt jätetään lukija taasen jyrkänteelle roikkumaan, koska tuota käsitellään vasta jatkotarinan kolmannessa osassa. Tapaamisiin!