Ads 468x60px

tiistai 29. heinäkuuta 2014

Instagram istunnon kaappaaminen on helppoa

Taas kerran turvattomien protokollien käyttö on noussut esiin ja huomaamme kuinka vähän loppukäyttäjä voi luottaa jopa tunnettujen palveluiden tietoturvaan. Viime päivinä Internetissä on käyty vilkasta keskustelua Instagramin API-kutsujen tietoturvasta. Instagramin mobiilisovellus (Android ja iPhone) tekee API-kutsut käyttäen salaamatonta HTTP-protokollaa. Jos käyttäjä selaa Instagramia suojaamatonta/heikosti suojattua (WEP) langatonta verkkoa käyttäen, on istunnon kaappaaminen hyvinkin helppoa. Alla on esimerkki miten istunnon kaappaus toteutetaan, kun henkilö selaa Instagramia suojaamatonta langatonta verkkoa käyttäen.

Ensimmäiseksi asetetaan langaton verkkokortti monitoroivaan tilaan
iwconfig wlan0 mode monitor 

Tämän jälkeen kuunnellaan Instagramin API-kutsuja esimerkiksi tcpdumpilla ja tallennetaan dump tiedostoon (esimerkki komento tallentaa kaiken liikenteen, joka on kohdistettu HTTP porttiin 80)
tcpdump -i wlan0  -n -vv -w instagramdump.pcap dst port 80

Nyt voi tcpdumpin antaa kerätä liikennettä ja pysäyttää se, kun paketteja on kertätty tarpeeksi. Jo yksi HTTP kysely Instagramin API:in riittää paljastamaan käyttäjän istuntotunnisteen. Seuraavaksi kerättyä dataa voidaan analysoida Wiresharkilla. Avataan kerätty instagramdump.pcap Wiresharkilla ja filteröidään protokollaksi HTTP. Kaikissa kyselyissä jotka lähtevät Instagramin API:in välitetään eväste sessionid. Kun hyökkääjän on onnistunut kaapata liikennettä jossa on välitetty edellä mainittu istuntotunniste, voi hän käyttää kaappaamaansa tunnistetta esimerkiksi asentamalla Firefoxiin Firebug lisäosan sekä muuttamalla käyttäjän user agentin.

User agentin voi muuttaa Firefoxista esimerkiksi lisäosalla tai kirjoittamalla osoiteriville about:config ja luomalla uuden String asetuksen, jonka nimeksi tulee:

general.useragent.override

Ja arvoksi:

Instagram 6.0.5 (iPhone6,2; iPhone OS 7_1_1; en_GB; en-GB) AppleWebKit/420+

Firebugista asetetaan uusi eväste, jonka nimi on sessionid ja sen arvoksi kaapattu istuntotunniste. Tämän jälkeen voi hyökkääjä tehdä selaimelta Instagramin API-kutsuja kaapatun käyttäjän istunnolla. Näillä API-kutsuilla voi hyökkääjä käytännössä tunnistautua uhrina Instagramiin ja näin hallita uhrin Instagram-tiliä.

No, mikä tässä sitten on niin ihmeellistä tai huolestuttavaa?  Yksinkertainen vastaus on salaamattoman HTTP-protokollan käyttö yhdessä maailman suosituimmista sosiaalisen median sivustoista. Erityisen epämielyttävä tilanne on loppukäyttäjien kannalta, koska he eivät usein voi suoraan vaikuttaa mobiilisovellusten tietoturva-asetuksiin tai todentaa helpolla millaisia tiedonsiirtoprotokollia käytetään.

Facebookille (omistaa Instagramin) on raportoitu aiheesta heinäkuun 24. päivä mutta ainakin viimeisin Instagramin version niin iPhonelle kuin Androidille on edelleen haavoittuva tämänkaltaisia hyökkäyksiä vastaan. Siihen asti kunnes Instagram alkaa käyttää salattua yhteyttä API-kutsujen yhteydessä on erittäin suositeltavaa välttää Instagramin mobiilisovelluksen käyttöä erityisesti salaamattomissa/heikosti salatuissa langattomissa verkoissa. Jos Instagramin mobiilisovellusta käyttää hyvin suojatuissa langattomissa tai 3G/4G verkoista ei näin yksinkertainen hyökkäys ole enää mahdollinen. Liikenne kuitenkin suuntautuu Internettiin, jossa käyttäjällä ei ole mitään hallintaa siitä miten hänen lähettämänsä paketit reitittyvät. Tästä syystä jossain muussa pisteessä sijaitseva hyökkääjä voi edelleen kaapata Instagram-käyttäjän istunnon.


keskiviikko 16. heinäkuuta 2014

Datan fyysisen sijainnin merkitys vähenemässä radikaalisti


Gartnerin raportin (The Snowden Effect: Data Location Matters) mukaan datan fyysinen sijainti on muuttumassa yhä enemmän merkityksettömäksi ja vuoteen 2020 mennessä oikeudellinen, poliittinen ja looginen sijainti tulevat korvaamaan sen useimmissa organisaatioissa. 

Edward Snowdenin NSA-paljastukset nostivat otsikoihin datan sijaintiin ja sen hallinnointiin liittyviä kysymyksiä. Useissa organisaatioissa epätietoisuus omistamansa datan sijainnista on arkipäivää, ja kansallisten lakien tulkitseminen monikansallisessa tietotekniikan infrastruktuurissa herättää kysymyksiä. Missä data itse asiassa sijaitsee ja kuinka sijainti edes tulisi määritellä? Gartner yksilöi raportissaan neljä datan sijainnin tyyppiä, jotka ovat:

Fyysinen sijainti
Joissain organisaatioissa uskotaan datan olevan paremmin turvattu, jos se on tallennettu paikallisille palvelimille. Saatetaan myös ajatella, että tietomurron alkaessa vain yksinkertaisesti vedetään kaapelit irti. Datan paikallinen talletus ei kuitenkaan takaa mitään, sillä usein koneita voidaan etäkäyttää ja useimmissa tapauksissa tietomurto huomataan vasta, kun se on jo tapahtunut. KPMG:n tutkimuksen mukaan tietomurrot havaitaan tyypillisesti vasta satojen päivien jälkeen. 

Oikeudellinen sijainti
Oikeudellinen sijainti määräytyy datan hallinnasta päättävän oikeushenkilön mukaan. Tämän organisaation datan prosessoinnista saattaa vastata toinen oikeushenkilö, kuten IT-palvelutalo. Lisäksi kolmas oikeushenkilö voi tarjota edellä mainitulle prosessointia tukevia palveluita, kuten konesalipalveluita, joita pyörittävät palvelimet voivat fyysisesti sijaita missä päin maailmaa tahansa.

Poliittinen sijainti
Gartnerin mukaan useimmat monikansalliset yritykset valitsevat tyypillisesti palveluntarjoajan, joka tarjoaa parhaan vastineen rahalle täyttäen tietyt vähimmäisvaatimukset. Onko kuitenkaan selvillä, ulkoistaako tämä palveluntarjoaja työtä esimerkiksi halvan työvoiman maihin? Joillekin järjestöille sillä on merkitystä, miten heidän sopimuksensa palveluntarjoajan kanssa näyttäytyy julkisuudessa. Poliittiseen sijaintiin liittyvät kysymykset koskettavat eniten julkisyhteisöjä, kansalaisjärjestöjä sekä yrityksiä, jotka palvelevat miljoonia kuluttajia tai joiden maine on jo pilalla. 

Looginen sijainti
Datan looginen sijainti määräytyy sen mukaan, kenellä on pääsy dataan. Esimerkiksi suomalainen yritys tekee sopimuksen yhdysvaltalaisen pilvipalvelutarjoajan irlantilaisen tytäryhtiön kanssa tietoisena siitä, että kaikki varmuuskopiodata on tallennettu fyysisesti Intiassa sijaitsevaan datakeskukseen. Vaikka oikeudellinen sijainti olisi Irlanti, poliittinen sijainti Yhdysvallat ja fyysinen sijainti Intia, loogisesti kaikki tiedot voivat olla Suomessa. Tämä edellyttää, että kaikki kuljetettava ja Intiassa sijaitseva data on salattu Suomessa sijaitsevalla avaimella. Huolimatta siitä, että tällainen arkkitehtuuri nostaa kustannuksia, lisää monimutkaisuutta ja heikentää käytettävyyttä, Gartnerin arvion mukaan looginen sijainti on nousemassa kansainvälisen tietojenkäsittelyn todennäköisimmäksi järjestelyksi.

perjantai 4. heinäkuuta 2014

Havex / Dragonfly / Energetic Bear: kohteena automaatiojärjestelmät

Viime päivinä on uutisoitu runsaasti haittaohjelmasta, joka vaikuttaa olevan kohdennettu energiasektorin toimijoihin ja automaatiojärjestelmiin (Industrial Control Systems, ICS). Itse asiassa Havex-nimellä tunnettu haittaohjelma ja sen taustalla vaikuttava ryhmä ovat olleet virustorjuntaohjelmistojen valmistajien ja muiden tahojen tiedossa jo pidemmän aikaa.

Varsinainen uutinen tuli viime viikolla, kun F-Secure raportoi ensimmäisenä haittaohjelman ja sen taustatoimijoiden vaikuttavan olevan kiinnostuneita nimenomaan automaatiojärjestelmistä (Havex Hunts For ICS/SCADA Systems, 23.6.2014). Symantec, joka kutsuu ryhmää nimellä Dragonfly, julkaisi tällä viikolla oman analyysinsä aiheesta (Dragonfly: Western Energy Companies Under Sabotage Threat, 30.6.2014). Vaikka laajan ja paikoitellen raflaavan uutisoinnin perusteella voisi päätellä toisinkin, on tällä hetkellä käytössä olevan tiedon perusteella vielä vaikea lähteä arvioimaan, kuinka vakavasta asiasta on kyse. Potentiaalisesti erittäin vakavasta, mutta toistaiseksi olemme nähneet ainoastaan tiedusteluun viittaavia toimia.

Eräs pidempään Dragonflyn toimintaa tarkkaillut taho on CrowdStrike, joka käyttää ryhmästä nimeä Energetic Bear ja kertoo raportissaan toiminnan kohdistuneen erityisesti energiasektorin toimijoihin (CrowdStrike: 2013 Year in Review: Actors, Attacks, and Trends, 22.1.2014). Ohjelman aikaleimojen (käännösaika) ja hallintapalvelimien aktiviteettien ajoittumisen perusteella CrowdStrike arvioi ryhmän toimivan Venäjältä käsin. Hyökkäyksen kohteiden sijainnin ja luonteen, sekä toiminnan laajuuden ja ammattimaisuuden perusteella monet arvioivat, että ryhmällä saattaa olla kytköksiä Venäjän valtioon tai että se saattaa olla Venäjän rahoittama. Uutisotsikoissa haittaohjelma onkin jo nimetty venäläiseksi, mutta kuten tyypillistä kyberhyökkäysten osalta, on todellisen alkuperän osoittaminen erittäin vaikeaa ja se jää yleensä enemmän tai vähemmän spekulaation varaan.

Suomessa asiasta uutisoivat mm. Helsingin Sanomat ja Tekniikka & Talous. Maailmalla aiheeseen tarttuivat useat arvostetut julkaisut ja verkkosivut, mm. Wall Street Journal, Financial Times, New York Times ja CNN (linkkejä uutisiin ja muihin lähteisiin on listattu kirjoituksen lopussa). Uutistoimistot ja verkkosivustot tekevät nähdäkseni sitä mitä niiden pitääkin, eli tuovat asioita laajemman yleisön tietoon referoimalla mielenkiintoisten raporttien sisältöä parhaansa mukaan. Toimittajat eivät ymmärrettävästi voi olla jokaisen uutisoimansa aiheen asiantuntijoita, uutiset pitää saada pikaisesti julkaistua, ja värikkäät otsikot myyvät. Nämä tekijät huomioon ottaen suosittelen lukemaan muutaman uutisen aiheesta pikaisen yleiskuvan saamiseksi, ja siirtymään sen jälkeen F-Securen ja Symantecin blogikirjoitusten pariin tiedon "alkulähteille".

Vähemmän teknisten lukijoidenkaan ei kannata säikähtää F-Securen kirjoituksen sisältämiä koodinpätkiä, sillä itse teksti on erittäin hyvä ja kiinnostava vaikka osa yksityiskohdista menisikin ohitse. Kannattaa myös lukea Symantecin tarkempi raportti aiheesta (pdf löytyy täältä) ja Yhdysvaltain ICS-CERT:n varoitus ja tiedote.. Kooste aiheeseen liittyvistä resursseista löytyy myös ScadaHackerin sivuilta, ja kuten tavallista, Dale Peterson ja Digital Bond tarjoaa hyviä kannanottoja. Jos työskentelet automaation (tietoturvan) parissa tai olet muuten kiinnostunut aiheesta, suosittelen ehdottomasti lisäämään kolme viimeistä lähdettä lukulistallesi, jos ne eivät siellä jo ole.

En käsittele tässä yksityiskohtaisemmin haittaohjelman toimintaa, koska se on jo ansiokkaasti tehty muualla - asiaa paremmin ymmärtävien toimesta. Pyrin kuitenkin käymään läpi nimenomaan automaation tietoturvan kannalta kiinnostavia kohtia, ja pohtimaan millaisia puolustuskeinoja olisi mahdollisesti voitu hyödyntää.

Mistä on kyse, hyvin lyhyesti:

Havex-haittaohjelmaa on tämän hetkisen tiedon mukaan levitetty ainakin kolmella tavalla:
  1. Lähettämällä haitallinen liitetiedosto sähköpostitse. Kyseessä kohdennettu kampanja, yritykset ja vastaanottajat on valikoitu.
  2. Saastuttamalla "tavallisia" verkkosivuja, joilla vierailevat saavat haittaohjelmatartunnan. Jälleen kohdennettu, viimeisimmässä vaiheessa valittu sellaisia sivustoja, joilla energia-alan toimijat mahdollisesti vierailevat. Tästä käytetään termiä Strategic Web Compromise, SWC, tai watering hole attack.
  3. Saastuttamalla valmistajien verkkosivuilta ladattavia ohjelmistojen asennuspaketteja. Kohteena ollut tämän hetkisen tiedon mukaan vähintään kolme nimenomaan automaatioalan laite/ohjelmistotoimittajaa. Myös tästä levityskeinosta käytetty termiä watering hole attack, koska tässäkin lopulliseen kohteeseen pyritään pääsemään sellaisten välietappien kautta, joista lopullinen kohde todennäköisesti olisi kiinnostunut.
Mitä haittaohjelma (muun muassa) tekee kohteessa?
  1. Yrittää ottaa yhteyden tunnettuihin verkkosivuistoihin/palvelimiin selvittääkseen onko sillä yhteys Internetiin. Jos on, haittaohjelma ottaa yhteyden joihinkin useista hallintapalvelimista.
  2. Hallintapalvelimelta ladataan ohjeet jatkotoiminnalle, eli lisäkomponentteja suoritettavaksi.
  3. Komponentit keräävät monenlaista tietoa ja lähettävät sitä hallintapalvelimelle. Mielenkiintoinen on komponentti, joka analysoi lähiverkkoon kytkettyjä laitteita ja erityisesti etsii OPC-palvelimia ja kerää niistä eri tietoja. 

Miksi tätä kutsutaan "ICS/SCADA-haittaohjelmaksi"?

Yllä esitettyä tai hyvin vastaavaa toimintamallia noudattavat monet haittaohjelmat, eikä tietyn toimialan valitseminen kohteeksi ole myöskään mitenkään ennenkuulumatonta. Mikä nyt käsiteltävästä tapauksesta sitten tekee erikoislaatuisen ja automaatiospesifin?

Ensinnäkin se, että levittämiskeinoista kolmannessa (asennuspakettien saastuttaminen) on valittu nimenomaan automaatioalan toimittajien sivuilta ladattavia asennuspaketteja. Jos olisi haluttu vain saastuttaa mahdollisimman monia kohteita toimialasta riippumatta, olisi varmasti parempiakin vaihtoehtoja löytynyt. Toisekseen se, että ohjelma monen muun keräämänsä tiedon lisäksi vaikuttaa etsivän lähiverkosta OPC-palvelimia.

Lyhyesti: mikä on OPC?

OPC on kokoelma standardeja, jotka on kehitetty ratkaisuksi yhteensopivuusongelmiin automaatiomaailmassa. Alunperin se on lyhenne sanoista OLE (Object Linking and Embedding) for Process Control. Alkuperäinen versio on 1990-luvulta ja perustuu Microsoftin COM/DCOM-teknologiaan. Idea on vähentää työmäärää, kun jokaiseen eri ohjelmistoon ei tarvitse kirjoittaa erillistä kommunikointirajapintaa jokaiselle mahdolliselle automaatiolaitteelle. Karkeasti esittäen: hyödynnettäessä OPC:tä riittää, että jokainen toteuttaa OPC:n mukaisen rajapinnan, ja pystyy sitten keskustelemaan minkä tahansa muun OPC:n mukaisen laitteen/ohjelmiston kanssa. Ilman yhteistä standardia tarvittava rajapintojen määrä kasvaa räjähdysmäisesti kommunikoivien osapuolien määrän kasvaessa.

Alkuperäisen OPC:n ilmestymisestä on pian kaksikymmentä vuotta, ja aikanaan se auttoi ratkaisemaan merkittävän ongelman. Siinä on myös merkittäviä heikkouksia - ei vähiten tietoturvan kannalta - jotka on, jos ei muuten niin jälkiviisaana, helppo havaita. Joka tapauksessa se on yhä erittäin laajassa käytössä automaatiossa. Sittemmin OPC on kehittynyt merkittävästi, mm. uudemman Unified Architecturen (OPC UA) -määrittelyn myötä, joka ei enää käytä COM/DCOM-teknologiaa. Lyhenteen merkityskin on muutettu muotoon "Open Platform Communications". ICS-CERT:n tiedotteen mukaan tämän hetken tunnetut haittaohjelmakomponentit Dragonfly-operaatiossa etsivät nimenomaan OPC:n vanhemman ("classic") version palvelimia, mutta eivät ole kiinnostuneita uudemmista OPC UA:sta.

Seuraava Stuxnet?

Ymmärrettävästi tapaus on yhdistetty aiempaan automaatiojärjestelmiin kohdennettuun haittaohjelmaan, Stuxnetiin. Kuitenkin tämän hetken tiedon perusteella yhteistä vaikuttaisi olevan lähinnä se, että kohteena on automaatiojärjestelmä(t) ja taustalla saattaa olla valtiollisia toimijoita. Toistaiseksi tässä tapauksessa on vain kerätty tietoa, ei aiheutettu varsinaista vahinkoa fyysisille järjestelmille. Vain aika näyttää, joudummeko seuraavaksi todistamaan vakavampia seuraamuksia.

Todettakoon myös, että on haastavuudeltaan omaa luokkaansa luoda haittaohjelma, joka saa kohteena olevan automaatiojärjestelmän toimimaan juuri halutulla tavalla (Stuxnet). Se vaatii syvällistä kohteen tuntemusta. Todennäköisesti paljon helpompaa on luoda ohjelma, joka tekee sattumanvaraisia muokkauksia, mahdollisesti pysäyttäen automaatiojärjestelmän tai pahimmillaan aiheuttaa (sattumanvaraista) tuhoa. Kohteen kannalta molemmat vaihtoehdot ovat tietysti äärimmäisen ikäviä.

Havex-haittaohjelman levittämistä ICS-toimittajien ohjelmistojen asennuspakettien kylkiäisenä voidaan pitää "innovatiivisena" keinona, ja nähdä siinäkin mielessä yhteneväisyyksiä Stuxnetiin. Tämäkin huomioon ottaen tällä hetkellä tiedetyn perusteella Dragonfly / Energetic Bear -operaatio ei ole monimutkaisuudessaan Stuxnetin luokkaa.

Mitä suojauskeinoja olisi voitu käyttää?

Hyökkäys voidaan mieltää useista vaiheista muodostuvaksi ketjuksi, ja eri vaiheita voidaan joko tehdä hyökkääjälle hankalammaksi tai hyökkäys voidaan kokonaan pysäyttää. Käsitellään seuraavaksi muutamia kiinnostavia suojautumismahdollisuuksia. Torjumista voidaan yrittää esimerkiksi estämällä:
  • haittaohjelman leviäminen ja tartunnan saaminen
  • koneelle päätyneen ohjelman suoritus 
  • jo suoritettavaksi päätyneen haittaohjelman "soitto kotiin" eli yhteydenotto hallintapalvelimelle 
  • auktorisoimaton pääsy OPC-palvelimelle
  • ...
Haittaohjelman leviämisen vaikeuttaminen tai estäminen

Levityskeinot 1. ja 2., eli haittaohjelmien levittäminen sähköpostilla tai verkkosivujen kautta on hyvin yleistä, ja eri suojauskeinoja on myös paljon. Tänä päivänä tuskin kukaan kuitenkaan ajattelee, että näiltä tartunnoilta voitaisiin kokonaan välttyä. Osa koneista saa luultavasti tartunnan, mutta mitkä koneet ja missä? Kohteissa, joissa on automaatiojärjestelmiä, on tärkeää pohtia koko verkon arkkitehtuuria: onko tarpeen että samalla koneella selaillaan Internetiä ja luetaan sähköposteja ja ollaan toisaalta yhteydessä OPC-palvelimille? Vastaus voi olla tapauskohtainen, mutta nykyisissä toteutuksissa on varmasti parantamisen varaa. Asiaa hankaloittaa myös se, että OPC on turvallisten palomuuriavausten suhteen erittäin haastava kommunikaatiokeino. Luonnollisesti mille tahansa toimistoverkon työasemalle päätyvä haittaohjelma on ikävä asia. Se on kuitenkin pieni murhe verrattuna haittaohjelmaan koneella, jolla on kyky lukea ja kirjoittaa tietoja OPC-palvelimelle ja siten mahdollisesti ohjata automaatiojärjestelmän laitteita.

Entä sitten haittaohjelman levittäminen asennuspakettien kylkiäisenä? Pohjimmiltaan on kyse tutusta ongelmasta: miten varmistat, että ajettava koodi on peräisin luotettavasta lähteestä eikä sitä ole manipuloitu? Esimerkiksi piraattiversio maksullisesta ohjelmasta tai epäluotettavasta lähteestä ladattu ilmaisohjelma voi periaatteessa sisältää mitä tahansa haitallisia komponentteja. Tässä tapauksessa lähteet olivat kuitenkin luotettavana pidettyjä.

Ilmeisesti toimittajien palvelimilla olleita haavoittuvuuksia hyväksikäyttämällä hyökkääjä onnistui korvaamaan verkkosivuilla jaettavat asennuspaketit omilla, haittaohjelman sisältämillä versioilla. Luonnollisesti toimittajien tulee parhaansa mukaan suojautua tällaiselta tilanteelta (tutuilla keinoilla kuten päivityksistä huolehtimisella, asianmukaisilla kovennuksilla, jne.) Tässä on myös takuuvarmasti parantamisen varaa. Silti, tuskin kukaan lähtee ajatuksesta, että minkään toimittajan yksikään palvelin ei ole ikinä haavoittuva.

Merkittävästi turvallisuutta parantava ratkaisu on tietysti koodin digitaalinen allekirjoittaminen. Näin voidaan (ainakin yrittää) varmentaa, että asennuspaketti on peräisin luotettavasta lähteestä ja ettei sitä ole muokattu. On huomattava, että tämä keskustelu perustuu vain oletukselle, että koodia ei oltu allekirjoitettu. Asiaa ei ole varsinaisesti mainittu alkuperäisissä lähteissä, eikä tietääkseni toistaiseksi ole virallisesti julkistettu toimittajien nimiä, josta saastuneet paketit oli ladattavissa. Yleisesti ottaen alalla ohjelmistot ja päivitykset eivät läheskään aina ole allekirjoitettuja.


Toki allekirjoitus on hyödyllinen vain mikäli allekirjoitusavainten turvallisuudesta huolehditaan. Teoreettinen riski luotetulla avaimella allekirjoitetulle haittaohjelmalle on aina olemassa, mutta valtaosa asiantuntijoista piti aiemmin sellaista hyvin epätodennäköisenä. Myös tämä kuvaa Stuxnetin edistyksellisyyttä: se osoitti, että myös käytännössä voidaan toteuttaa hyökkäys, jossa haittakoodi on allekirjoitettu luotettavana pidetyllä avaimella. Sittemmin tällaiset haittaohjelmat ovat muutenkin yleistyneet, mutta niiden luominen vaatii edelleen merkittävästi enemmän resursseja kuin allekirjoittamattoman haittaohjelman. Olisi siis erittäin suositeltavaa, että ohjelmat ja päivitysversiot allekirjoitettaisiin myös automaatioalan toimittajien toimesta: 
Haittaohjelman yhteydet muihin koneisiin

Asentumisen jälkeen haittaohjelma pyrkii ottamaan yhteyden hallintapalvelimelle, josta se lataa seuraavat ajettavat komponentit, ja jonne se lähettää keräämiään tietoja. On huomattava, että ilmeisesti haittaohjelma ei edes yritä ottaa yhteyttä hallintapalvelimeen, ellei se ensin pysty toteamaan, että käytössä on toimiva yhteys Internetiin (yrittämällä ottaa  yhteyden tunnettuihin verkkosivustoihin).

Eräs suojakeino on yrittää tunnistaa tällaiset yhteydet hallintapalvelimiin ja estää ne. Tyypillisesti käytetyt portit ovat sellaisia, että palomuurilla liikennettä on hankala tai mahdoton estää. Mikäli hallintapalvelimet eivät ole entuudestaan tunnettuja ja päätyneet suodatuslistoille, on torjuminen hankalaa myös IDS/IPS-ratkaisuilla. Tässä tapauksessa haittaohjelman toiminta on niin tyypillistä, että luultavasti kehittyneimmät anomaliapohjaiset suojausteknologiat (FireEye ja vastaavat) pystyvät tunnistamaan haittaohjelman ja estämään callback-yhteydet. Näitä teknologioita on kuitenkin toistaiseksi käytössä vielä rajoitetusti.

Jälleen, vastaava tietoja keräävä haittaohjelma on ikävä missä kohteessa tahansa, mutta erityisen ikävä jos se pyrkii (ja pystyy) kommunikoimaan automaatiojärjestelmien kanssa. Kuvitellaan tilanne, jossa järjestelmän ja verkon arkkitehtuurista riippuen haittaohjelman saastuttaneella koneella on
  1. yhteys Internetiin ja mahdollisuus kommunikoida komentopalvelimen kanssa 
  2. yhteys OPC-palvelimeen (ja mahdollisesti oikeus lukea/kirjoittaa tietoa)
  3. molemmat ylläolevista
Kolmas tilanne on kahta ensimmäistä merkittävästi ikävämpi, koska tällöin hyökkääjä voi mahdollisesti ensin kysellä tietoja OPC-palvelimelta, ja tiedon perusteella antaa ohjauskäskyjä palvelimen kautta automaatiolaitteille. Stuxnet osoitti, että myös ilman tällaista aktiivista hallintayhteyttä voidaan vaikuttaa automaatiojärjestelmään halutulla tavalla. Tällainen "sokkona" toimiminen on kuitenkin ymmärrettävästi erittäin paljon haastavampaa. Aktiivisen yhteyden muodostamisen jälkeen ohjausten välittäminen automaatiolle on sitä vastoin (tietyin oletuksin eli pahimmassa tapauksessa) lähes triviaalia.

Tämä ei ole ehdoton patenttiratkaisu kaikkeen, mutta järjestelmien ja verkkojen nykyisen tilanteen huomioon ottaen panostamalla oikeanlaiseen arkkitehtuuriin voidaan merkittävästi parantaa tietoturvaa. Riippuu paljon tilanteesta ja toiminnallisista vaatimuksista mitä voidaan tehdä, mutta uskoisin että yllä esitetyistä skenaarioista ensimmäinen ja toinen ovat vähemmän epämukavia kuin kolmas.

OPC:n tietoturva

Perinteinen OPC on monessa suhteessa haastava tietoturvan kannalta. Aihe on laajahko, enkä tässä kirjoituksessa paneudu siihen sen syvemmin. Iso ongelma on OPC:n käyttämä dynaaminen porttien allokointi, mikä perinteisessä palomuurissa käytännössä pakottaisi tekemään niin laajat avaukset, ettei palomuurista ole juuri hyötyä. Toinen iso ongelma on käyttöoikeuksien ja pääsynhallinnan määritykset. Niiden konfigurointi on hankalaa ja oikeudet jäävät hyvin laajoiksi - tämä saattaa olla jopa valmistajan suositus. Myös OPC:n käyttämät protokollat, mm. DCOM ja RPC voivat sisältää vakavia haavoittuvuuksia.

Automaatiomaailmalle tyypillisesti tärkeintä on järjestelmän toimivuus ja tuotannon pyöriminen. OPC:n konfiguroiminen mahdollisimman tietoturvallisesti on varsin hankalaa, ja aiemmin tietoturvan merkitys automaatiossa on ollut paljon vähäisempi. Yritykset konfiguroida OPC tietoturvallisemmaksi johtavat helposti siihen, että kommunikaatio ei enää toimi. Tämä on johtanut siihen, että usein pyritään vain saamaan järjestelmä toimimaan välittämättä tietoturvasta. Ongelmat ovat kyllä varsin hyvin tiedossa. Niihin on myös olemassa erilaisia ratkaisuja, tietoturvallisen konfiguroinnin lisäksi esimerkiksi OPC:n tunnelointi palomuurissa ja uudemman OPC-UA:n käyttö. Monessa tapauksessa kehitystoimiin on varmasti myös ryhdytty. Dragonfly-operaatio toimii toivottavasti herätteenä näiden asioiden pikaiselle kehittämiselle niissäkin kohteissa, jossa tietoturvaa ei ole aiemmin riittävästi huomioitu.

Kävinkö väärässä pubissa? - tiedonjako saastuneista "juomapaikoista"

Huomionarvoista on, että toistaiseksi missään ei ole (ainakaan tietääkseni) virallisesti julkaistu niiden automaatiotoimittajien nimiä, joiden sivuilta saastuneita asennuspaketteja oli ladattavissa. Myöskään Strategic Web Compromise -hyökkäyksen kohteiksi joutuneita verkkosivuja ei ole ilmoitettu. Tämä tieto helpottaisi merkittävästi sen arviointia, kuinka todennäköisesti oma organisaatio on joutunut hyökkäyksen kohteeksi.

Toki voi olla perusteltua, että esimerkiksi Symantec ja F-Secure eivät voi tai halua tätä tietoa julkisesti jakaa. Digital Bondin Dale Peterson kritisoi puutteita tiedonjaossa - jos ei yhtiöiden toimesta niin esimerkiksi CERT:ien tulisi (voida) jakaa tietoa. Kirjoituksessa on myös mainittu nimeltä (luultavasti) tunnistetut kaksi kolmesta automaatiotoimittajasta, joiden sivuilla saastutettuja asennuspaketteja jaettiin. Onnistuneen hyökkäyksen kohteeksi joutuminen ei varmasti tee hyvää yrityksen maineelle, mutta yleensä vielä pahempaa on viivytellä tiedon julkaisemista, jos se kuitenkin ennen pitkää tulee julki. 

Viime hetken päivitys: eWon -yritys kertoo verkkosivuillaan, että heihin kohdistunut murto liittyy nimenomaan tähän tapaukseen.
Mielenkiintoinen idea on esitetty myös Digital Bondin toisen kirjoituksen lopussa: eikö ICS-CERT:n tulisi käydä läpi eri haittaohjelmanäytteitä, ja yrittää selvittää mitkä niistä ovat mahdollisesti kohdennettuja automaatiojärjestelmiin? Jos tällainen idea toteutettaisiin, voisi se pidentää varoitusaikaa, kun tieto automaatiojärjestelmiin kohdennetuista haittaohjelmista voisi saavuttaa alan toimijat jo ennen kuin hyökkäys pääsee täyteen vauhtiin.

Yhteenveto

Mitä tästä kaikesta pitäisi ajatella? Tähän mennessä nähdyn perusteella uutisointi on ollut paikoin liioiteltua. Silti tämä ja vastaavat operaatiot ovat mahdollisesti vain alkusoittoa ja tiedon keräämistä kohteista. Seuraavat vaiheet voivat potentiaalisesti olla katastrofaalisia. Tämän tyyppisen operaation voisi hyvin kuvitella olevan kybersodankäynnin vaikuttamiskyvyn kehittämisen ensimmäisiä vaiheita. Voi hyvin olla, että eri valtioilla ja muillakin toimijoilla on jo nyt keinot vaikuttaa toisten maiden kriittiseen infrastruktuurin. Rikollisuuden, haktivismin ja terrorismin tapauksissa kybervaikuttamisen kyvykkyyttä todennäköisesti jossain vaiheessa myös käytetään, tai ainakin halutaan muilla keinoin todistaa että sellaista on. Valtiollisen tason toimijoiden tapauksessa voi olla, että iskukykyä kehitetään "pahimman varalle", mutta sitä ei välttämättä koskaan käytetä tai osoiteta olevan olemassa, jos tilanne ei sitä vaadi.

Joka tapauksessa viimeistään nyt on selvää, että on olemassa haittaohjelmia ja hyökkääjiä, jotka ovat kiinnostuneita nimenomaan automaatiojärjestelmistä. Spekuloitavaksi jää, millaista kyvykkyyttä ja millä toimijoilla on tällä hetkellä olemassa. Vain aika näyttää mitä seuraavaksi tulee tapahtumaan. Uskaltaisin veikata, että automaatiojärjestelmiä ja kriittistä infrastruktuuria vastaan tehtävät hyökkäykset tulevat yleistymään. Toivon mukaan tietoturvaan panostetaan ennen kuin vahinkoa tapahtuu.

Suunnitelmallisen automaation tietoturvan kehittämisen lisäksi välittöminä toimenpiteinä on suositeltavaa viimeistään nyt päivittää virustorjuntaohjelmistojen tunnisteet ja tarkistaa järjestelmät tartuntojen varalta. Myös mahdollisten IDS/IPS -järjestelmien tunnisteet tulee päivittää. Yleisiä mitigointikeinoja ja mm. OPC:n tietoturvan kehitystoimenpiteitä on listattu ICS-CERT:n varoituksen ja tiedotteen lopussa, ne on myös suositeltavaa käydä läpi.

Aiheesta muualla: 

23.6.2014 F-Secure: Havex Hunts For ICS/SCADA Systems 
26.6.2014 Digital Bond: Havex / Stuxnet / ICS-CERT / DHS
27.6.2014 ICS-CERT: Alert (ICS-ALERT-14-176-02A) ICS Focused Malware
30.6.2014 Symantec: Dragonfly: Western Energy Companies Under Sabotage Threat
30.6.2014 ICS-CERT: Advisory (ICSA-14-178-01) ICS Focused Malware
2.7.2014 Digital Bond: Havex Hype & Unhelpful Mystery
2.7.2014 McAfee: Operation Dragonfly Imperils Industrial Protocol

3.7.2014 Viestintävirasto: Tietoturva Nyt! Energiasektoriin kohdistuva kybervakoilukampanja

Symantec White Paper (pdf)
CrowdStrike Report (pdf)
SCADAHacker.com -resurssisivu

Uutisointia:
24.6.2014 Helsingin Sanomat: Uusi verkkovakoilulöytö: Rikolliset saastuttavat teollisuuden automaatiojärjestelmiä
30.6.2014  Tekniikka & Talous: Venäläinen haittaohjelma iski satoihin eurooppalaisiin sähkövoimaloihin
1.7.2014 Helsingin Sanomat: Verkkohyökkääjät iskivät Euroopan ja Yhdysvaltain energiayhtiöihin

24.6.2014 PCWorld: New Havex malware variants target industrial control system and SCADA users
24.6.2014 SecurityWeek: Attackers Using Havex RAT Against Industrial Control Systems
24.6.2014 ArsTechnica: Attackers poison legitimate apps to infect sensitive industrial control systems
25.6.2014 SCMagazine: 'Havex' malware strikes industrial sector via watering hole attacks
26.6.2014 Darkreading.com: As Stuxnet Anniversary Approaches, New SCADA Attack Is Discovered
26.6.2014 The Register: Attackers fling Stuxnet-style RATs at critical control software in EUROPE
30.6.2014 Financial Times: Energy companies hit by cyber attack from Russia-linked group (vaatii kirjautumisen)
30.6.2014 The New York Times: Russian Hackers Targeting Oil and Gas Companies
30.6.2014 Daily Mail: Over 1,000 European and US energy firms hit by Russian 'Energetic Bear' virus that let hackers take control of power plants
1.7.2014 BBC: Energy firms hacked by 'cyber-espionage group Dragonfly'
2.7.2014 CNN: Russia attacks U.S. oil and gas companies in massive hack

perjantai 27. kesäkuuta 2014

KPMG:n ja kumppaneiden tietoturvaristeily 21.8.-22.8.2014









KPMG:n ja kumppaneiden tietoturvaristeily 21.8.-22.8.2014



 




Toivotamme teidät lämpimästi tervetulleeksi perinteiselle tietoturvaristeilylle joka järjestetään Silja Europalla. Tarjolla
on tuttuun tapaan kattaus ajankohtaisia tietoturva-asioita ja mielenkiintoisia keskusteluja, verkostoitumista KPMG:n asiantuntijoiden ja kumppanien kanssa, mukavaa yhdessäoloa unohtamatta!


Laiva on Silja Europa, kokoonnumme klo 16.30 lippujen jakoon Länsiterminaalin  toiseen kerrokseen. Laivaan siirtyminen klo 17 alkaen.
Hinta osallistujille  250 € + alv / henkilö.

Osallistujamaksu sisältää laivamatkat, hytit ja ohjelmaan sisältyvät ruokailut, ruokajuomat sekä seminaariohjelman.

Katso tarkempi ohjelma tästä!

Viimeinen ilmoittautuminen maanantaina 14.7.2014


Ilmoittautuminen




 
Yhteistyökumppani
 






 
Yhteistyökumppani 
 
   




 
Yhteistyökumppani
 
   
 
     




Facebook
LinkedIn
Blogi
Youtube



Mikäli et halua jatkossa KPMG:n sähköistä markkinointipostia, ilmoitathan siitä meille tästä.
Osoitelähde: KPMG:n asiakas- ja markkinointirekisteri
© 2014 KPMG Oy Ab, a Finnish limited liability company and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative ("KPMG International"), a Swiss entity. All rights reserved.



torstai 26. kesäkuuta 2014

Vuonna 1984/2014

"Juuri nyt ajomatka kohteeseen Töölönlahdenkatu kestäisi 16 minuuttia." - iPhone-käyttäjät saivat iOS 7 -päivityksen myötä liudan uusia ominaisuuksia, joista tuo edellä mainittu sitaatti ilmoituskeskuksesta on yksi esimerkki. Kiva ja hyödyllinen uusi ominaisuus, vai mitä?

"Juuri nyt ajomatka kotiin kestäisi 10 minuuttia." - Hetkinen, kuka kertoi puhelimelleni missä asun? Todennäköisesti ei kukaan, vaan puhelimeni on päätellyt asian siitä missä nukun yöni. Tämä muuttaa em. ominaisuuden jo asteen pelottavammaksi. Lisäksi puhelimeni tietää, että maanantaisin ja tiistaisin en yleensä olekaan menossa Töölönlahdenkadulle, vaan toiseen osoitteeseen.

Tokihan voisin iPhonen asetuksista kääntää pois päältä sijaintipalveluiden käytön, mutta tarvitsen niitä muihin tarkoituksiin, joten en tee niin, vaan jatkan käyttöä.

Seuraavaksi törmään asiaan käytyäni bisneslounaalla erään asiakkaan edustajan kanssa. Lounaan jälkeen huomaan että puhelimeni facebook-sovellus ehdottaa minulle ihmisiä, joita saatan tuntea. Listalla on asiakkaan edustaja, jonka kanssa juuri olin lounaalla. Johtuuko tämä siitä, että:

a) olemme Linkedin -kontakteja
b) hän kävi ennen tai jälkeen lounaan katsomassa julkisen facebook-profiilini
c) puhelimemme sijaintitiedot kertoivat että viivyimme tasan saman aikaa samassa paikassa puolen metrin etäisyydellä toisistamme vai
d) kaikkien edellisten yhdistelmästä?

En hyväksy sovelluksen ehdotusta, koska emme tunne kuitenkaan henkilökohtaisella tasolla riittävän hyvin. Meillä ei ole facebookissa yhteisiä tuttuja, joten epäilen sen johtuneen myöskään yksistään b)-kohdasta. Todennäköisesti puhelimemme, joku kolmannen osapuolen sovellus tai mainosoperaattori on yhdistellyt sijaintitietojamme muihin tietoihin.

Eihän ihmisten valvonta ja profilointi sekä tietojen kerääminen ja yhdistely mitään ihmeellistä nykypäivänä ole. Edward Snowden toi tasan vuosi sitten julki koko maailmalle NSA:n systemaattisen tietojen keräämisen ja valvonnan (Blogissamme esitellyt NSA:n vakoilutyökalut), jonka tietoturva-ammattilaiset ja monet muut ovat tienneet jo vuosikausia. Itse kuulin ensimmäisen kerran Echelon-ohjelmasta jo 90-luvulla. Yhdysvallat kielsi Echelonin ja NSA:n (No Such Agency) olemassaolon vielä vuoteen 2000 asti. Toki isonveljen valvonta ja NSA sai lisäpuhtia ja resursseja 911-iskujen jälkeen 26.10.2001 säädetyn Patriot Actin kautta. Kirjoitin jo ennen Snowdenin paljastuksia huhtikuussa 2013 blogitekstin, jossa viittasin ongelmiin mitä saattaa syntyä pilvipalvelujen käytöstä ja tietojen luovuttamisesta yhdysvaltain viranomaisille Patriot Act:in mukaan. Orwell tiesi asian jo vuonna 1948 kirjoittaessaan otsakkeessa viitattua kirjaansa.

Kerron vielä yhden esimerkin, joka viimeistään konkretisoi sijaintipalveluiden käytön ja tietojen yhdistelyn pahimmat puolet. Ystäväni kysyi minulta, miksi facebook ehdottaa hänelle arvostelua  Jorvin lastentautien poliklinikasta samana päivänä, kun hänen vaimonsa on käyttänyt heidän lastaan paikassa. Hän itse ei ollut käynyt lähelläkään Jorvia kyseisenä päivänä, eikä edes lähiaikoina. Hänen vaimonsa ei ole facebookissa, ja heillä on eri merkkiset puhelimet (iPhone ja Lumia). Voihan asia ja ehdotus olla sattumaakin, mutta ainakin itse mietin tapahtuneen jälkeen facebookin ehdotuksia ja suosituksia ihan eri tavalla kuin aiemmin. Yllättävän moni tietää missä olet tänä kesänä!

Hyvää kesää kaikille blogimme lukijoille!