TigerTeam - suomalainen tietoturvablogi

Kuluvan kuun aikana olemme nähneet harvinaisen paljon OS X -käyttöjärjestelmässä toimivaa haittaohjelmaa koskevia uutisia. Jo useamman vuoden ajan on povattu, että hyökkäykset OS X:ää vastaan tulevat lisääntymään kunhan käyttöjärjestelmän markkinaosuus on ”riittävän kiinnostava”. Nyt ollaan varmastikin tässä tilanteessa. Niin sanotun Flashback-epidemian alkuvaiheessa yli 600 000 tietokoneen kerrottiin saastuneen ko. troijalaisella. Suomesta tartuntoja raportoitiin muutamia satoja.

Applen tietoturvapäivitystä Oraclen jo helmikuun puolivälissä korjaamaan Java-haavoittuvuuteen CVE-2012-0507 saatiin odotella ja niinpä kyseinen Flash-päivitykseksi naamioitu haittaohjelmamuunnos syntyi.

Myöhemmin ilmestyi myös SabPub-niminen troijalainen, jonka uskotaan liittyvän Luckycat-bottiverkkoon. Myös Maceille suunnattuja, Word-haavoittuvuuksia hyödyntäviä APT-hyökkäyksiä (pitkäkestoinen kohdistettu hyökkäys) on tässä kuussa nähty.

Onko työasemani Java haavoittuva?

Ensimmäistä kertaa koko OS X:n olemassaolon aikana usea toimija julkaisi muutaman päivän välein Flashback-poistotyökalun sekä isjavaexploitable.com:n ja flashbackcheck.com:n kaltaisia tarkistussivustoja, joilla voi tarkistaa onko oman työaseman Java päivitetty. Onpa troijalainen saanut myös englanninkielisen Wikipedia-artikkelinsa. Lopulta Java-päivitys Applelta tuli jakeluun poistaen samalla tietokoneessa mahdollisesti majailleen troijalaisen.

Yhtenä viimeisimmistä käänteistä asiassa on tieto, jonka mukaan keskimäärin Mac-tietokoneissa on runsaasti Windows-haittaohjelmia. Ei mikään mitätön asia, mikäli Macissä ollut muistitikku käy Windows-koneessa.

Miksi näin sitten pääsi käymään?

• Moni käyttäjä tuudittautuu siihen, että OS X:llä on turvallinen maine ja haittaohjelmia on käyttöjärjestelmälle olemassa vain kourallinen. Tämä johtaa siihen, ettei Javaa, Flashia, Quicktimea tai esimerkiksi selaimen lisäosia tule päivitettyä, sovellusohjelmista puhumattakaan.

• OS X:n tapa kysyä käyttäjän salasanaa on varoittava merkki käyttäjälle jostain poikkeuksellisesta. Käyttäjä on tottunut syöttämään salasanansa esimerkiksi ohjelmia asennettaessa. Flashback-tapauksessa salasanaa ei kuitenkaan kysytä, vaan haittaohjelma aktivoituu taustalla ilman käyttäjän toimenpiteitä.

• Oletuksena OS X muistuttaa saatavilla olevista päivityksistä vain kerran viikossa. Ellei käyttäjä ole muuttanut Ohjelmiston päivitys (Software Update) -asetuksia ei muistutusta esimerkiksi Flashbackiin liittyvästä Java-päivityksestä tullut käyttäjälle ajoissa. Osa käyttäjistä sai varmuudella tartunnan aikana, jolloin päivitys olisi jo ollut saatavilla.

• Myös mm. Microsoft Officen päivittämisestä huolehtiva Microsoft AutoUpdate -toiminto ilmoittaa päivityksistä viikon välein. Senkin asetuksia kannattaa tihentää:

• Windowsin tavoin tietoturvapäivitysten jakelu vanhempiin versioihin loppuu aikanaan. Leopard-versioon eli 10.5:een ei Java-päivitystä enää julkaistu. Vaihtoehtoina on tässä tilanteessa joko päivittää uudempaan OS X -versioon tai kytkeä Javan suoritus pois päältä.

• Ylläpitäjiä varten Apple on julkaissut kattavat konfigurointiohjeet käyttöjärjestelmän koventamisesta Snow Leopardiin asti. Pirteänä alkuna voi tutustua puolestaan NSA:n julkaisemaan kahden arkin vinkkilistaan, linkki pdf:ään tässä.

Johtopäätöksenä voi sanoa, että Flashback ei ole Macin tietoturvattomuuden alku, mutta herättäjänä ja prosessien tarkistajana se kannattaa ottaa. Microsoft Office, Flash, mediasoitin ja monet, monet muut ohjelmistot eivät päivity itsestään. Maccejä on yrityksissä jo niin paljon, että rikolliset alkavat pitää Mac-työasemia potentiaalisina hyökkäyskohteina.

Kirjoittaja on ollut sataprosenttinen Mac-käyttäjä yli viiden vuoden ajan, mutta käyttää kuitenkin virustorjuntaohjelmistoa ja mm. tietoturvaa parantavia selaimen lisäosia sekä pitää Maccinsä päivitettyinä.

Normaalitilanteessa ylläpitäjät ja tietoturvahenkilöstö sekä käyttäjät voivat tutustua uudessa ohjelmistoversiossa korjattuihin haavoittuvuuksiin tai tietoturvaparannuksiin. Aina ei näin kuitenkaan tapahdu.

Hiljainen päivitys on ohjelmistoon julkaistu tietoturvapäivitys, jossa korjattuja haavoittuvuuksia ei ole julkisesti dokumentoitu eikä yksilöity.

Päivitystä ei siis edes kutsuta tietoturvapäivitykseksi, mikäli samalla kertaa ei ole korjattu muita haavoittuvuuksia, jotka yksilöidään tietoturvatiedotteessa (advisory).

Mikäli ilmoittamatta jäävä korjattu haavoittuvuus on ainut tietoturvapäivitys, mutta valmistaja nimeää päivityksen esimerkiksi ylläpito- tai vakauspäivitykseksi saattavat ohjelmiston ylläpidosta vastaavat organisaatioissa jättää päivityksen väliin. On helppoa olla kiirehtimättä päivityksen jakelussa, ellei sen tietoturvaluonnetta ole tiedossa.

Hiljaisia päivityksiä (englanniksi silent patch) harrastavat niin isot kuin pienetkin ohjelmistovalmistajat. Viime päivinä aiheesta on puhuttu Adoben julkaistua Flashia koskevan säännöllisen tietoturvapäivityksen. Microsoftin on kerrottu toimineen viime vuonna MS10-024- ja MS10-028-päivityksien kohdalla myös “hiljaisesti”.

Adoben tapauksessa Googlen Tavis Ormando väittää Adoben jättäneen yksilöimättä nelisensataa tietoturvaparannusta, jotka ovat tulleet ilmi Flashiin kohdistuneessa auditoinnissa Chrome-selaimeen integroimiseen liittyen. Ormando perää tapauksille CVE-tunnuksia ja haavoittuvuuksien löytäjän nimeä esile.

Aikaisempia tietoturvatermejä koskevia kirjoituksia voi lukea avainsanalla tietoturvatermit.

Etsiessäsi verkosta tietoja haavoittuvuuksista ja esimerkiksi tutustuessasi tietoturva-auditointiraporttiin olet varmasti törmännyt CVE-alkuisiin tunnuksiin. Mikä tuo CVE sitten on?

CVE on lyhenne sanoista Common Vulnerabilities and Exposures - yleinen haavoittuvuuksien ja paljastuneiden heikkouksien hallintamenetelmä. CVE-tunnisteen voi saada niin käyttöjärjestelmän, sovellusohjelman kuin vaikkapa reitittimen haavoittuvuus. CVE-tunniste siis yksilöi haavoittuvuuden.

Hankkeessa haavoittuvuudelle luodaan mahdollisimman selkeä kuvausteksti, annetaan sille järjestysnumero ja verkkoa kahlaamalla lista lisätietoreferensseistä. Ohessa esimerkki Windowsia koskevan CVE-tunnisteen CVE-2011-0096 kuvauskentästä:

Ilman CVE-järjestelmää haavoittuvuuksien hallinta esimerkiksi pelkkien haavoittuvuustietokantojen ja valmistajien tietoturvatiedotteiden avulla olisi hyvin hankalaa. Hanke on jo yli kymmenen vuoden ikäinen ja tunnisteita on annettu jo lähes 45 000 kappaletta. Hanketta pyörittää yhdysvaltalainen MITRE Corporation, joka saa hankkeeseen tukea Yhdysvaltain Kotimaan turvallisuuden virastolta. Yksityiskohtaisempi National Vulnerability Database -tietokanta NVD taas käyttää CVE:n tietoja.

Erityisesti CVE-tunniste auttaa yhdistämään tietyt haavoittuvuudet ja niihin julkaistut korjauspäivitykset toisiinsa.

CVE-tunnisteiden muoto on CVE-2011-xxxx.

Tässä CVE merkitään aina isoin kirjaimin, 2011 on julkaisuvuosi ja xxxx neljällä numerolla ilmaistu järjestysnumero. Tiedot on eroteltu toisistaan yhdysmerkillä.

Huomattavan vanhoja haavoittuvuuksia käsitellessä voi törmätä tunnisteeseen muotoa CAN-2003-0714. Tällöin kyseessä on ns. kandidaattitunniste, jolla ei luontihetkellä ollut vielä virallisen tunnisteen roolia. Tieto käy ilmi tunnisteen Status-kentästä, mutta CAN-tunnisteiden käytöstä on muutama vuosi sitten luovuttu.

Referensseistä tiedon lähteille

Kun CVE:stä tulee julkinen on sillä ainakin yksi referenssilinkki - valmistajan tietoturvatiedote, linkki postituslistalla julkaistuun hyökkäyskoodiin tai verkossa julkaistu hyödyllinen analyysi haavoittuvuudesta. Referenssi kuuluu johonkin yli 80 lähdekategoriasta, esim. BID:45254 tarkoittaa BID-tietuetta (Bugtraq ID) numero 45254 SecurityFocus-haavoittuvuustietokannassa. Esimerkissä käytetyn OpenSSL-haavoittuvuuden referenssi REDHAT:RHSA-2010:0977 puolestaan viittaa Linux-jakelija RedHatin tiedotteeseen (RedHat Security Advisory) otsikolla RHSA-2010:0977. Haavoittuvuuskenttä onkin melkoinen lyhenteiden temmellyskenttä.

Uusi aukko, mutta sillähän on jo CVE

Isot ohjelmistovalmistajat, kuten Apple, Microsoft, Red Hat ja Oracle saavat sarjan CVE-tunnuksia käyttöönsä vuosittain. Mitä tämä tarkoittaa sitten käytännössä? Kun kohtaat esimerkkinä käyttämämme CVE-tunnisteen CVE-2011-0096 löydät siitä tiedon

Assigned (20101221):

Ohjelmistovalmistaja, eli tässä tapauksessa Microsoft, on osoittanut tunnisteen tälle haavoittuvuudelle 21. joulukuuta. Kun haavoittuvuus tulee julkiseksi ja siitä julkaistaan esimerkiksi tietoturvatiedote voidaan CVE:hen viitata ja linkittää saman tien.

Myös yksityiset tietoturvatutkijat voivat hakea löytämilleen haavoittuvuuksille oman CVE:n. Hyvä käytäntö on kertoa hakuajankohta tietoturvatiedotteen aikatauluosiossa:

VIII. DISCLOSURE TIMELINE

04/23/2009 - Requested CVE

04/24/2009 - CVE received

Kirjoitus kuuluu haavoittuvuuksiin liittyviin termeihin ja lyhenteisiin tutustuttavaan kirjoitussarjaan.

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

Kesällä havaittu Stuxnet-haittaohjelma on paljastunut analysoinnin edistyessä monella tavalla merkilliseksi ja ainutlaatuiseksi tapaukseksi. Vähitellen eri tahoilta tihkuneet tiedot alkavat saada jo vakoiluromaanimaisia ulottuvuuksia, joten lienee paikallaan hetkiseksi pysähtyä pohtimaan mitä oikein on tapahtumassa.

Haittaohjelman löysi kesäkuussa valkovenäläinen VirusBlockAda-tietoturvayritys erään iranilaisen asiakkaansa tietokoneesta. Aluksi se vaikutti varsin tavanomaiselta USB-tikkujen kautta leviävältä madolta, jonka merkittävin ominaisuus oli Windowsin ennalta tuntemattoman .LNK-tiedostojen käsittelyyn liittyvän haavoittuvuuden käyttö leviämistienä. Kun madon tartuttama USB-muistitikku kytketään tietokoneeseen, siellä piilotteleva ohjelma käynnistyy automaattisesti ja asentaa käyttöjärjestelmään välittömästi ns. rootkitin, jonka avulla se kätkee itsensä näkyvistä.

Tarkkaan katsomalla voi nähdä kuinka avautuvassa resurssienhallinta-ikkunassa vilahtaa kuusi tiedostoa, jotka kuitenkin häviävät hetken päästä. Muut tikulla olevat tiedostot näkyvät normaalisti ja kaikki vaikuttaa olevan kunnossa, mutta konepellin alla käy kuhina: uusia prosesseja käynnistetään, valmiiksi käynnissä oleviin lisätään uutta ohjelmakoodia ja tunnistetut virustorjuntaohjelmat lamautetaan. Vain tavallista vilkkaammin vilkkuva kiintolevyn merkkivalo saattaisi antaa aihetta olettaa että jotain outoa on tekeillä, mutta Tehtävien ja Palveluiden hallinta näyttävät vain tuttujen ja turvallisten ohjelmien olevan käynnissä, koska rootkit piilottaa niistä Stuxnetin lisäämät osat.

Ajurit kavalasti allekirjoitettuja

Huolestuttava piirre Stuxnetissa on se, että se onnistuu asentamaan tartuttamiinsa järjestelmiin huomaamatta uusia laiteajureita, vaikka uudemmissa Windows-versioissa näiden käyttöjärjestelmäläheisten osien tulee olla digitaalisesti allekirjoitettuja. Se johtuu siitä että ajureilla onkin hyväksyttävä, VeriSignin taiwanilaiselle Realtek-yritykselle myöntämällä varmenteella tehty allekirjoitus. Myöhemmin havaitiin myös muunnos, jossa oli käytetty niin ikään taiwanilaisen JMicronin varmennetta. On erittäin harvinaista että ohjelmistojen allekirjoittamiseen myönnetyt varmenteet päätyvät vääriin käsiin, saati sitten kahden eri yrityksen.

Suurin osa Stuxnetin sisältämästä ohjelmakoodista on salakirjoitettu, joten otti aikansa ennen kuin sen varsinaiset tarkoitusperät alkoivat selvitä. Heinäkuun puolivälissä tietoturvatutkija Frank Boldwein onnistui purkamaan salakirjoituksen ja kansainvälisen tietoturvayhteisön mielenkiinto heräsi. Kävi nimittäin ilmi, että Stuxnetilla oli hyvin täsmällinen kohde: Siemensin Step 7 -prosessinohjausjärjestelmä, jota käytetään yleisesti teollisuuslaitoksissa ja voimaloissa. Stuxnet aktivoitui vain jos tartunnan saaneeseen tietokoneeseen oli asennettu järjestelmän WinCC-ohjaus- ja seurantaohjelmisto, muussa tapauksessa se tyytyi vain levittämään itseään lähiverkkoyhteyksien välityksellä naapurikoneisiin ja tartuttamaan koneessa käytetyt muistitikut.

Tässä vaiheessa Tofino Securityn Eric Byres arveli, että kysymys on teollisuusvakoilusta, koska kohteensa löydettyään Stuxnet tekee WinCC:n tietokantaan joukon kyselyjä ja lähettää yhteenvedon tiedoista kahdelle hyvin viattomalta vaikuttavalle jalkapalloveikkausivustolle, joista toinen sijaitsee Tanskassa ja toinen Malesiassa. Vastatoimenpiteisiin ryhdyttiin ripeästi. Heinäkuun loppuun mennessä Microsoft julkaisi normaalin päivitysaikataulunsa ulkopuolella korjauspäivityksen .LNK-haavoittuvuudelle MS10-046, VeriSign peruutti Realtekin ja JMicronin varmenteet, Stuxnetin käyttämät jalkapallosivustot korvattiin tartuntoja seuraavilla palvelimilla ja virustorjuntaohjelmistojen valmistajat lisäsivät Stuxnetin tietokantoihinsa estääkseen sen leviämisen. Heinäkuun 23. päivänä Kaspersky Labs arvoi noin 45 000 tietokoneen saaneen tartunnan.

Myös Siemensillä toimittiin ripeästi. Havaittuaan järjestelmiensä olevan uhattuna yhtiö lähetti jo seuraavalla viikolla asiakkailleen päivityksen, jolla tartunnat voidaan ehkäistä. Teollisuusautomaation asiantuntija Ralph Langner ryhtyi analysoimaan Stuxnetin keskeisiä osia ja huomasi pian että Stuxnetin tekijöillä on erinomaiset tiedot kohteestaan. Tämänhetkisen tiedon mukaan Stuxnet lisää omaa ohjelmakoodiaan WinCC-järjestelmään kytkettyihin PCS-prosessinohjauslaitteisiin, mutta piilottaa nämä osat huolellisesti muokkaamalla WinCC-järjestelmää niin että lisäyksiä ei voi havaita eikä poistaa. Tietoa siitä mitä nämä lisäykset saavat aikaan ei ole annettu julkisuuteen, ja Langner kommentoi säästeliäästi: “koko tämä juttu näyttää niin uskomattomalta, että en oikein tiedä mitä siitä voi kertoa yleisölle”.[1]

Nollapäiväaukkoja kerrakseen

Näin taitavasti laadittu haittaohjelma olisi helposti kyennyt tartuttamaan suuremmankin joukon tietokoneita. Kävi ilmi että USB-muistitikkujen lisäksi mato levitti itseään myös toisella, Windowsin kirjoitinjonoon liittyvällä haavoittuvuudella, jota aluksi epäiltiin niin ikään ennen tuntemattomaksi. Lisäksi Stuxnet käyttää kahta niin ikään ennen tuntematonta paikallista haavoittuvuutta saadakseen kohdekoneessa rajoittamattomat käyttöoikeudet. Pelkästään yhden tällaisen Zero-day-haavoittuvuuden löytyminen on uutinen, mutta kolmen tai neljän samanaikainen käyttäminen on ennenkuulumatonta. Ja kuitenkin Stuxnet on ohjelmoitu lopettamaan leviämisensä kolme eri tietokonetta tartutettuaan.

Stuxnetin maantieteellinen levinneisyys on myös hyvin mielenkiintoinen. Symantec huomasi haltuunottamiensa jalkapallosivustojen avulla että yli puolet Stuxnetin tartuttamista tietokoneista on Iranissa. Indonesia, Intia, Azerbaizan ja Pakistan ovat myös kuuden eniten tartuntoja kärsineen maan joukossa. Näin voimakas maantieteellinen keskittyminen johtuu siitä että Stuxnet ei leviä Internetin välityksellä, vaan ainoastaan yleensä vain lähiverkoissa toimivan kirjoitinpalvelun ja fyysistä kontaktia vaativan USB-muistitikun avulla. Ei liene liioiteltua olettaa että haittaohjelman liikkeellelaskijan tarkoitus oli iskeä nimenomaan Iraniin, ja muihin maihin levinneet tartunnat ovat USB-tikkuja mukanaan kuljettaneiden tietotyöläisten aiheuttamia oheisvahinkoja.

Summataanpa yhteen. Stuxnetin tekijöillä on käytössään huippuasiantuntemusta niin tietoturvasta kun prosessikontrollista, hallussaan varastettuja varmenteita ja keinoja käyttää hyväksi useita ennen tuntemattomia haavoittuvuuksia melkeinpä tuhlailevasti. Heidän kohteenaan ovat Iranin teollisuuslaitokset, joista mainittakoon esimerkiksi Busheriin rakenteilla oleva ydinvoimalaitos ja -rikastamo. Onkohan siellä käytössä Siemensin Step 7 -prosessinohjausjärjestelmä?

Mutta mitä hyökkääjät havittelivat? Pari pientä yksityiskohtaa jää vaivamaan ainakin minua. Siihen verrattuna miten taitavasti Stuxnet muuten on laadittu, siihen on jätetty ilmeisesti tarkoituksella pari outoa kömpelyyttä. Miksi rootkit ei estä näkemästä Drivers-hakemistoon lisättyjä tiedostoja? Miksi www-osoitteet joihin ohjelma ottaa yhteyttä on vakioitu? Tumpelommatkin botnetin rakentajat ovat jo pitkään osanneet kierrättää command and control -palvelimien domain-nimiä jonkin vaikeasti arvattavan algoritmin mukaan. Ikään kuin olisi varta vasten haluttu tehdä helpoksi nähdä kuka ja missä on saanut tartunnan.

Itse veikkaisin että kyseessä on varoitus. Joku on halunnut lähettää Iranin päättäjille viestin: me voimme räjäyttää teidän tehtaanne taivaan tuuliin niiden omilla laitteilla jos haluamme. Pitäkää varanne! Lieneekö sattumaa, että Langnerin analysoimassa koodissa esiintyy liipaisinarvona luku #DEADF007, josta saa pienellä mielikuvituksella sanat “dead fool”?

Totuus ehkä selviää aikanaan. Oli asialla kuka tahansa, kissa on nyt nostettu pöydälle arvaamattomin seurauksin. Se on vielä pientä että muuta haittaohjelmian kirjoittajat ovat innokkaasti ryhtyneet lainaamaan Stuxnetin käyttämiä leviämiskeinoja. Mielestäni paljon vakavampi seuraus on se ainakin minut yllättänyt tieto, miten heikosti teollisuuden prosessinohjausjärjestelmät on suojattu. Tilanteen kehittymistä tiiviisti seuranneen Industrial Defender -yrityksen julkaisemasta “The Stuxnet Worm and Options for Remediation” white paperista[2] käy ilmi erittäin huolestuttavia asioita.

• Stuxnetin tehtävä lukea tai tarvittaessa muuttaa WinCC-järjestelmän tietokantaa on helppo, koska tietokantaan pääsee kytkeytymään vakioidulla valmistajatunnuksella. Tunnus on kovakoodattu WinCC-ohjelmiin, joten sitä ei voi edes muuttaa vaikka käyttäjä tulisikin asiaa ajatelleeksi. (Tiedossani ei ole muuttaako Siemensin 22.7. toimittama päivitys tätä tilannetta, mutta käytäntö on kuulemma alalla yleinen.)

• Ohjausjärjestelmissä käytetään yleisesti vanhentuneita käyttöjärjestelmäversioita. Industrial Defenderin keräämien tietojen mukaan lähes puolet Stuxnet-tartunnan saaneista tietokannasta käytti joko Windows 2000 - tai Windows XP SP2 -versioita, joita ei enää tueta ja joille Microsoft ei enää toimita korjauspäivityksiä.

• Ohjausjärjestelmien päivityssyklit ovat hyvin hitaita. Tämä on ymmärrettävääkin, koska teollisuusympäristössä päivitykset on tapana testata ja validoida huolellisesti ennen asentamista. Ikävä kyllä se myös merkitsee sitä, että päivityksiä tehdään harvoin, ja esimerkiksi Stuxnet pystyi menestyksekkäästi käyttämään vielä yhtenä leviämiskeinona jo vuonna 2008 korjattua RPC-haavoittuvuutta MS08-067.

• Lukuisilta WinCC-järjestelmää pyörittäviltä tietokoneilta on suora yhteys julkiseen Internetiin. Symantecin oli helppo todentaa tämä, koska Stuxnet ottaa yhteyttä www-sivuille vain löydettyään WinCC-asennuksen. Siemensin mukaan ainakin 14 tuotantokäytössä olevaa ohjausjärjestelmää on saanut Stuxnet-tartunnan.[3]

• Itse PCL-moduulien suojaus on lähes olematon. Firmaware-päivityksiä ei tarvitse allekirjoittaa, ja niitä voi tehdä miltä tahansa järjestelmään kytketyltä tietokoneelta.

Industrial Defender ei ujostele häpeilemättä mainostaa paperissaan omia IPS- (intrusion prevention) ja IDS- (intrusion detection) -järjestelmiään. Jotain sellaista toivoisi todellakin käytettävän, vaikka parempiakin vaihtoehtoja ehkä olisi, esimerkiksi haittaohjelmille alttiiden ohjaustietokoneiden kertakaikkinen korvaaminen vastustuskykyisemmillä järjestelmillä. Siitä huolimatta suosittelen lämpimästi heidän www-sivuihinsa tutustumista kaikille prosessiautomaation ja tietoturvan parissa vaikuttaville. Pandoran lipas on nyt avattu ja kiinni sitä ei enää saada.

Lähteet:

[1] www.pcworld.com/businesscenter/article/205827/was_stuxnet_built_to_attack_irans_nuclear_program.html

[2] “The Stuxnet Worm and Options for Remediation”, PDF-dokumentti:

www.industrialdefender.com/advisory/stuxnet/tech_paper/stuxnet_08.2010.pdf

[3] krebsonsecurity.com/2010/09/stuxnet-worm-far-more-sophisticated-than-previously-thought/

[Langner]

www.langner.com/en/index.htm

[Symantec]

www.symantec.com/connect/blogs/w32temphid-commonly-asked-questions

www.symantec.com/connect/blogs/w32stuxnet-installation-details

www.symantec.com/connect/blogs/distilling-w32stuxnet-components

www.symantec.com/connect/blogs/stuxnet-introduces-first-known-rootkit-scada-devices

www.symantec.com/connect/blogs/stuxnet-using-three-additional-zero-day-vulnerabilities

www.symantec.com/connect/blogs/stuxnet-print-spooler-zero-day-vulnerability-not-zero-day-all

[Industrial Defender]

findingsfromthefield.com/?p=549

Industrial Defender Download Center, vaatii rekisteröitymisen:

www.industrialdefender.com/general/downloads/recordings/stuxnet1/index.htm www.industrialdefender.com/general/downloads/recordings/stuxnet2/index.htm

Kun organisaation jokaisesta työasemasta löytyvästä, paljon käytetystä ohjelmistosta löytyy nollapäiväaukko soisi turvapäivityksen tulevan jakeluun mahdollisimman nopeasti. Joskus paikkausta on kuitenkin odoteltava viikkoja ja kuukausia.

Otetaanpa esimerkiksi viime viikolla havaittu Flash-nollapäiväaukko (CVE-2010-1297), joka koskee myös Adobe Reader -ohjelmistoa. Valmistajahan kertoi haavoittuvuuden aktiivisesta hyödyntämisestä viime perjantaina ja tällä viikolla haavoittuvuutta on hyödynnetty laajemmalti ainakin sähköpostiliitteiden avulla.

Nyt tiedämme Flash-korjauksen tulevan jakeluun tänään torstaina - ilmeisesti illalla Suomen aikaa. Adobe Reader - ja Adobe Acrobat -ohjelmistojen osalta korjaus tulee kuitenkin saataville vasta kuun loppuun mennessä. Kolme viikkoa on pitkä aika odottaa.

Mitä organisaatio voi ja sen kannattaa tehdä turvapäivitystä odottaessa:

• Kartoita onko organisaatiossasi PDF-toiminnallisuutta, joka perustuu JavaScriptin tai Flashin ajamiseen PDF-dokumentissa. Harkitse ominaisuuksien poiskytkemistä PDF-lukijasta - haavoittuvuuksien löytyminen ei rajoitu tähän tuoreimpaan.

• Onko haavoittuvalle ohjelmistolle vaihtoehtoja? PDF-lukijan vaihtaminen ei kuitenkaan ole aivan yksiselitteistä. Mikäli organisaatio käyttää suomenkielisiä toimisto-ohjelmia ja suomenkielistä selainta on esimerkiksi englanninkielisen ohjelmiston tuominen palettiin konstikasta.

• Ota selville onko organisaatioosi jo hyökätty Adobe-aukolla. Virustorjunnan lokeista löytyvät tunnistusnimet, mainittakoon esimerkiksi Exploit:W32/Pidief.CPT, Trojan.Pidief.J ja TROJ_PIDIEF.WX, kielivät tästä. Tarkista myös ovatko selaimen generoimat tietoturvahälytykset lisääntyneet.

Pohdiskelimme tammikuussa isojen ohjelmistovalmistajien siirtymistä vuosineljänneksittäisiin päivityksiin. Ainakin Adoben osalta tämä haavoittuvuus pakotti sen luopumaan säännöllisestä julkaisuaikataulusta.

Tämä tiistai on IT- ja tietoturva-ammattilaisille harvinaisen haastava. Samana päivänä tietoturvapäivityksensä julkaisevat niin Adobe, Microsoft kuin Oraclekin.

Adoben julkaisemat päivitykset ovat vuoden ensimmäisen neljänneksen päivityksiä, Microsoftin päivitykset tammikuun kuukausipäivityksiä ja Oraclen 24 päivitystä taas ensimmäisen neljänneksen CPU-päivityspaketti (Critical Patch Update).

Microsoftin päivityksiä koskevia ennakkotiedotteita on ollut käytettävissä vuoden 2005 alusta, samasta hetkestä jolloin Oracle aloitti neljännesvuosipäivityksensä. Etukäteistiedotteet Oracle otti käyttöön kylläkin vasta myöhemmin.

Uusin etukäteistiedottaja kolmikosta on Adobe, joka aloitti säännölliset päivityksensäkin vasta viime kesänä.

Ennakkotietojen laajuus vaihteleekin sitten jo paljon. Oraclen erityispiirteenä on paikattavien haavoittuvuuksien korkeimman CVSS-arvon kertominen. Tällä kertaa arvo on tuotteiden Listener for Oracle Database Server, Secure Backup ja JRockit kohdalla korkein mahdollinen eli 10.0.

Haittaohjelmien tekijöille lisää aikaa

Kuinka ohjelmistojätit sitten ovat onnistuneet päivitysprosesseissaan? Suoraa vastausta ei kysymykseen ole olemassa, mutta Microsoftille päätös on välillä ollut haasteellinen.

Microsoftilla on nimittäin päätetty jättää kuukausipäivitykset julkaisematta kaikkiaan neljä kertaa: joulukuussa 2003, maalis- ja syyskuussa 2005 sekä maaliskuussa vuonna 2007. Samalla kun päivitysten ennakkotiedote edellisen viikon torstaina kertoo päivityksien kohteet, saavat haavoittuvuuksien hyödyntäjät kuten haittaohjelmien tekijät pahimmassa tapauksessa kuukauden lisäaikaa toimilleen.

Buutti tarvitaan, olkaa valppaina

Päivitysten perusteellinen testaaminen ottaa myös aikansa, ja sitä ehdottomasti täällä Nixussa suosittelemme. Ennakkotiedote kertoo ylläpitäjille mitä ollaan paikkaamassa ja auttaa suunnittelemaan esimerkiksi palvelinten uudelleenkäynnistyksen, kun Microsoft kertoo sen pakolliseksi päivityksen astumiseksi voimaan.

Hyökkääjällä on usein useita hyökkäysvektoreita valittavanaan. Hyökkäys voidaan suunnitella ja oikea hyökkäysvektori valita sitä paremmin mitä enemmän aikaa ennen päivityksen julkaisua on käytettävissä.

Adoben tapauksessa tämä onkin jo nähtävissä. Kun aikaisemmin Acrobat-haavoittuvuuksia hyödynnettiin pitkälti lähinnä ns. kohdennetuissa hyökkäyksissä on päivitystä odotellessa nähty yhä uusia haavoittuvuutta hyödyntäviä hyökkäyksiä. Hyödynnettävä haavoittuvuus on miltei poikkeuksetta joulukuun puolivälissä löytynyt, Adoben tietoturvatiedotteessa APSA09-07 mainittu haavoittuvuus (CVE-2009-4324).

Verkkorikolliset käyttävät aikansa tehokkaasti, koska päivityksen tultua tänään saataville vähenee haavoittuvien kohteiden määrä jatkuvasti. Tieto korjausaikataulustahan saatiin jo joulukuun puolivälissä, ei suinkaan viime torstain ennakkotiedotteen kautta. Hyökkäyskoodi on ollut Metasploitissa jo peräti kuukauden.

Saamaansa lisäaikaa verkkorikolliset käyttävätkin usein kehittämällä exploit- eli hyökkäyskoodista koodinajamiseen kykenevän version.

Säännöllisesti tietoturvapäivityksiä jakavien ohjelmistovalmistajien joukko laajenee Adoben siirtyessä kesän aikana vakioituihin tietoturvapäivityksiin. Muutos koskee Adobe Reader - ja Adobe Acrobat -ohjelmistoja. Käytännössä päivitysten jakelupäivä on kunkin vuosineljänneksen toinen tiistai – heinä- ja lokakuussa siis Microsoftin päivityspäivän kanssa sama päivä.

Tieto käy ilmi tällä viikolla ilmestyneestä blogikirjoituksesta, joka kertoo samalla toimijan panostuksista ohjelmakoodin koventamiseen ja incident response -prosessin parantamiseen. Tietoturvayhteisölle uutinen on hyvä ja odotettu – Microsoft ja Oraclehan aloittivat vastaavan jo vuonna 2005.

On ilo nähdä, että Adobe päätyi tiedottamaan aikataulumuutoksesta etukäteen. Adoben mukaan viime maalis- ja toukokuun päivitysjulkaisujen sijoittuminen samalle päivälle Microsoftin ns. tilkkitiistain kanssa on vain sattuma. Brad Arkinin mukaan päivitykset julkaistiin heti niiden valmistuttua.

Adobe kyllä lupasi huhtikuisten nollapäiväaukkojen päivityksen julkaisun tapahtuvan tiettyyn ajankohtaan eli 12.5. mennessä. Koska tarkkaa ajankohtaa ei kuitenkaan ollut tiedossa oli päätöksen tekeminen esimerkiksi rinnakkaisen tuotteen käyttöönotosta tai PDF-dokumenttien suodatuksen laajuudesta vaikeaa.

On mielenkiintoista nähdä, mitä muiden toimijoiden toimintamalleja Adobe ottaa käyttöön ja millä tarkkuudella se ryhtyy päivityksistä etukäteen tiedottamaan. Yksi merkittävä yksityiskohta olisi ainakin se, julkaistaanko päivitys yhtä aikaa englanninkielisen jakelun lisäksi myös eri kieliversioina.

Jeremiah Grossman pohdiskeli viikonloppuna blogissaan yleisimpiä syitä siihen, miksi web-sivustoilta löytyneitä haavoittuvuksia ei korjata.

Hänen listaamiaan syitä ovat mm. seuraavat (ei tärkeys- tai yleisyysjärjestyksessä):

• Organisaatiosta ei löydy henkilöä, jolla on ymmärrystä tai vastuu sivuston koodin ylläpitämisestä

• Sivuston omainaisuuksien säilyttämistä pidetään turvakorjauksia tärkeämpänä

• Sivusto tullaan uusimaan piakkoin

• Haavoittuvan koodin omistaa kolmas osapuoli

Grossmanin mukaan on myös yleistä, että riski sivuston murtamisesta yksinkertaisesti hyväksytään tai organisaation compliance-vaatimukset eivät vain vaadi haavoittuvuuksien korjaamista.

Kaikkein ikävin tilanne on kirjoituksessa viimeksi mainittu tilanne, jossa koko organisaatiosta ei löydy tapauksesta tietävää tai tapauksen vastuulleen ottavaa henkilöä.

Tunnetun tietoturvavaikuttajan ja mm. WASC-konsortion perustajiin kuuluvan Grossmanin pohdiskelu herättää paljon mietittävää. Kirjoituksen kommentteihin jätetty havainto priorisoinnin vaikeudesta on arkipäivää myös Suomen oloissa. Nixun konsultit kohtaavat usein tilanteita, joissa organisaatio ei ole tietoinen kaikista palvelimilta löytyvistä web-sovelluksista. Sovelluksen olemassaolo paljastuu siis vasta kun tietoturvatarkastuksessa löydetään sovelluksesta haavoittuvuuksia.

Mitenkään tavaton ei ole tilanne, jossa tätä kautta organisaation tietoon tulleesta sovelluksesta ovat haavoittuvuudet olleet korjaamatta vuosikausia.

Kerroimme viime viikon lopulla Adobe Acrobatia ja Adobe Readeria koskevista nollapäivähaavoittuvuuksista. Valmistaja vahvisti viikonloppuna paikkauksen julkaisuaikataulun – korjaus saapuu 12. toukokuuta mennessä eli noin viikon kuluttua.

Myös CVE-tunnukset noille kahdelle haavoittuvuudelle on julkaistu. getAnnots()-haavoittuvuus on CVE-2009-1492 ja customDictionaryOpen()-haavoittuvuus taas CVE-2009-1493.

Jokainen haavoittuvuuksiin vähänkin enemmän perehtynyt on törmännyt Common Vulnerabilities and Exposures -yhtenäistystunnuksiin, joita jaetaan tuhansia vuosittain. Tunnuksille annetaan pienellä viiveellä myös sen vakavuutta kuvaava numeroarvo asteikolla 0.0 – 10.0. Pisteytysjärjestelmä tuntee nimen Common Vulnerability Scoring System ja siitä käytetään lyhennettä CVSS. Voidaan puhua myös CVSS-pisteytyksestä.

NVD- eli National Vulnerability Database -tietokannan sisältämä ensin mainitun haavoittuvuuden CVSS-arvo on korkeimpaan High-luokkaan kuuluva 9.3.

Haavoittuvuuksille on jo parin vuoden ajan annettu myös haavoittuvuuden aiheuttaneen ohjelmointivirheen tyyppiä kuvaava CWE-luokitus – Common Weakness Enumeration. Luokka on tässä tapauksessa järjestelmäresurssien hallinnassa tapahtunut virhe tunnuksella 399.

Edellä mainituista jälkimmäinen Adobe Acrobat -aukko eli käyttäjän omiin sanastoihin liittyvä haavoittuvuus puolestaan kuuluu CVSS-arvonsa perusteella keskitasolle arvolla 6.8.

Käytämme CVE-, CVSS- ja CWE-tunnuksia ja -arvoja myös asiakkaille toimittamissamme raporteissa.

Uusia CVE-tunnuksia julkaistaan päivittäin ja samalla haavoittuvuudet saavat CVSS-arvon. CWE-lista taas päivittyi uuteen 1.3-versioon maaliskuussa.