“If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.”

– Bruce Schneier

Ulkoiset tietoturvavaatimukset ja sisäiset kustannustehokkuuteen painostavat linjaukset eivät aina kulje käsi kädessä. Viime vuosien kestosuosikki, palvelinten virtualisointi, on yksi keskeisistä teknologioista, jolla organisaatiot ovat viime vuosina konsolidoineet palvelujaan ja suoraviivaistaneet infrastruktuuriaan. Virtualisoinnin edut ja mahdollisuudet mm. skaalautuvuuden, rautariippumattomuuden, uusien palvelinten nopean käyttöönoton ja energiasäästöjen osalta sekä mm. testi- ja kehitysympäristöjen alustana ovat kyllä kiistämättömiä. Toisaalta väärin toteutettuna virtualisointi toimii usein vain vianselvitystä hidastavana ja arkkitehtuuria monimutkaistavana uutena kerroksena, joka vaatii päivittämistä ja voi aiheuttaa palvelukatkoja. Virtualisoinnin aiheuttamat haasteet tietoturvallisuuden varmistamiseksi ovatkin jääneet melko pienelle huomiolle – virtualisointiratkaisuilla on kuitenkin usein tärkeä rooli jopa liiketoimintakriittisten palvelujen alustana. Optimisti voisi ajatella, että tämä johtuu ratkaisujen järeistä turvakontrolleista ja huolellisesti testatuista järjestelmistä, mutta onko näin?

Virtualisointia ei ole alunperin tarkoitettu tietoturvamekanismiksi järjestelmien segmentointiin, joten sellaisena sitä ei tule ilman tarkkaa suunnittelua ja huolellista testausta käyttää. Virtualisointituotteiden on usein kuitenkin automaattisesti oletettu soveltuvan myös tämänkaltaiseen käyttöön, lähinnä siksi, että tätä oletusta kumoavia todisteita ei ole ollut saatavilla. Tilanne tämän suhteen on kuitenkin nopeasti muuttumassa. Hiljattain raportoitiin VMware-tuotteita koskevasta kriittisestä haavoittuvuudesta, joka mahdollistaa komentojen ja koodin suorittamisen host-koneella guest-koneen kautta. Haavoittuvuuden toimintaa kuvaava video on myös saatavissa. Myös kokonaan uusi haittaohjelmaluokka virtuaalikonetroijalaiset, Virtual Machine Trojans (VMT), on nostamassa päätään. Kyseessä on netistä ladattava käyttövalmis virtualisoitu palvelin (virtual appliance), jonka toiminnallisuus ei vastaakaan kuvausta, vaan sisältää taustaprosessin, joka esim. lähettää löytämiään sensitiivisiä tietoja haittaohjelman levittäjälle ja mahdollistaa koneen etähallinnan. Viime viikolla julkaistu proof-of-concept-virtuaalitroijalainen, ViMtruder, mahdollistaa haavoittuvuuden demonstroinnin ja testauksen, mutta odotettavissa on varmasti myös haavoittuvuutta hyväksikäyttäviä haittaohjelmia.

Onko virtualisointi sitten näiden löydösten jälkeen katsottava turvattomaksi tekniikaksi, jota ei voida suositella kriittisiin ympäristöihin? Aivan näin ei voida todeta. Järjestelmien teknisten kontrollien merkitys virtuaaliympäristöjen tietoturvallisuudelle on suuri, mutta se itsessään jää merkityksettömäksi, mikäli järjestelmän suunnitteluun, testaukseen sekä hallinta- ja valvontaprosesseihin ei ole kiinnitetty riittävää huomiota. Tilanne sinänsä on siis täysin sama kuin muidenkin, perinteisempien tekniikoiden käytössä. Tietoturvan kultaisen säännön mukaan järjestelmät ovat turvattomia kunnes toisin todistetaan – ja normaalit riskienhallintaprosessit ovat tarpeen myös virtualisointiin siirryttäessä.

Tällä viikolla on raportoitu kahdestakin yleisesti käytössä olevan Adobe Readerin haavoittuvuudesta. Sekä getAnnots()- että customDictionaryOpen()-haavoittuvuuksiin on julkiset hyväksikäyttömenetelmät saatavilla Linux-ympäristöön.

Helmikuussa eli tarkalleen 19.2. julkisuuteen tulleessa JBIG2-tapauksessa (CVE-2009-0658) korjaus tuli saataville maaliskuun toisella viikolla eli noin kolmessa viikossa. Unix-versiot puolestaan julkaistiin vasta kahta viikkoa myöhemmin. Nyt tilanne on toinen, koska valmistaja ei ole kertonut korjatun version julkaisuajankohtaa.

Myös tuolloin useita sekä julkisia että penetraatiotyökaluja tuottavien toimijoiden maksullisia expoit-koodeja julkaistiin.

Käytännössä korjausta odottaessa on mahdollista mm. estää sovelluksen käyttö, siirtyä vaihtoehtoiseen tuotteeseen, rajoittaa hyväksikäyttöä esim. asetusmuutoksilla tai luottaa virustorjunta- ja tunkeutumisenestosuojaan. Acrobat-tapauksessa valmistaja suosittelee Acrobat JavaScriptin poiskytkemistä ohjelmiston valikoista.

Viikkoja kestävä ajanjakso on pitkä aika tilanteessa, jolloin varsinkaan tarkkaa päivityksen julkaisuaikaa ei ole etukäteen tiedossa. Mikäli organisaatio käyttää suomenkielisiä sovellusversioita voi laajaltikin käytössä olevan sovelluksen päivityksen odottaminen kestää jopa kuukausia.

JavaScriptin poiskytkentää ei tule jättää ohjeistuksen varaan ja käyttäjien itsensä toteutettavaksi. Keskitetty asetusmuutos takaa sen, että asetus tulee kattavasti käyttöön niin Windows-, Linux- kuin Mac-työasemissakin.

CVE-2009-0658:n CVSS-arvo oli peräti 9.3). Uusien JavaScript-metodiaukkojen arvoa ei ole vielä saatavilla.

Ongelma joka sekä Acrobatista että Adobe Readerista odottaa paikkausta kuuluu CWE-luokituksessa luokkaan CWE-119 eli Failure to Constrain Operations within the Bounds of a Memory Buffer – samaan kuin JBIG2-haavoittuvuuskin.

Helmikuussa JBIG2-haavoittuvuutta hyödynsi myös yritysvakoilutapauksista tuttu Trojan.Pidief-kategorian takaporttitroijalainen. Kerromme tässä blogissa mikäli vastaavista troijalaisista saadaan nyt viitteitä.