Ads 468x60px

perjantai 27. huhtikuuta 2012

Adrian ja pyöristyshyökkäys

Adrian Furtuna KPMG Romaniasta esitteli Hacknetissä seuraavan hyökkäyksen verkkopankkeja vastaan. Hyökkäys perustuu pyöristysvirheeseen valuutanvaihdossa. Adrianin testaamassa pankissa oli mahdollista vaihtaa pieni summa Romanian letejä euroiksi. Oikea vaihtokurssi on noin 4,5 letiä yhtä euroa kohti. Vaihtamalla mahdollisimman pienen summan (0,023 letiä) euroiksi, saa yhden eurosentin. Kurssit luonnollisesti vaihtelevat pankin ja valuuttojen mukaan. Joissakin pankeissa voisi ehkä vaihtaa vielä pienemmän summan.

Uusi vaihtokurssi on siis huomattavasti parempi, noin 2,6 letiä per euro. Toisaalta yhdellä siirrolla voi siirtää erittäin pienen summan rahaa. Tämä ei pankin mielestä ollut mikään ongelma, sillä heillä on käytössään Digipass-laite, jolla tilisiirrot vahvistetaan. Laitteeseen on syötettävä verkkopankin esittämä haasteluku ja laite vastaa luvulla, jolla siirto viedään loppuun. Vastaavia ratkaisuja on suomalaisissa verkkopankeissa, mutta useimmiten ilman elektronista laitetta.

Adrian todisti hyökkäyksen mahdolliseksi rakentamalla fyysisen laitteen. Laitetta ohjataan sovelluksella ja se painaa Digipassin näppäimiä sekä lukee vastauksen web-kameralla. Sovellus muuntaa tämän jälkeen kuvan numeroiksi, jotka se syöttää verkkopankkiin.

Laitteella voi käytännössä tehdä noin 10 siirtoa per minuutti. Päivässä tämä tarkoittaa noin 103 euron voittoa. Suuremman hyökkäyksen toteuttaminen vaatii useita laitteita.

Pankkimaailmassa hyvin harva ratkaisu on loppujen lopuksi turvallinen :)

-Antti A

Kriittisen infrastruktuurin hakkerointi - sinisen tiimin näkökulma

Kilpailu alkoi torstaina noin kello 11. Itse olin siis mukana sinisessä joukkuessa, joka pyöritti CrazyColan tehdasta.

Tiimi jaettiin seuraavasti:

  • Teknisesti osaavat henkilöt
  • "Puolitekniset" henkilöt
  • Ei-tekniset henkilöt
Tämän jälkeen ruvetiin jakamaan ohjeen mukaisia rooleja. En listaa kaikkia tässä, mutta esimerkiksi seuraavia rooleja oli jaettavana:

  • CEO
  • CIO
  • Manufacturing manager
  • Change coordinator
  • Incidents and surveillance manager
  • Forensics analyst
  • HMI Operator (human-manufacturing interface)
  • IT Staff
Jaoimme roolit vielä sisäisesti kolmeen osastoon, joiden sisällä oli omia tiimejä.

Punaiselle joukkueelle ei jaettu vastaavaa organisaatiota. Tämä oli yksi ratkaiseva tekijä. Jälkikäteen ajateltuna punaisen suurin ongelma oli heikko organisointi ja tiedon kulun ongelmat joukkueen sisällä.

Itse olin IT Staff -roolissa. Käytännössä tämä tarkoitti IT-ympäristön turvaamista ja ylläpitoa. Sinisen joukkueen tehtävä oli valmistaa CrazyColaa. Tehdas otti sisään erän soodavettä joka 20 minuutti ja tuotti sitä vastaavan määrän kolaa 20 minuutissa, joka piti toimittaa myyntiin. Jos tuotannossa on ongelmia, syntyy päästöjä. Tuotetta oli myös mahdollista dumpata, josta seurasi isoja rangaistuksia.

Mikäli tehdas ei toiminut oikein, varoitussireeni laukesi sinisen joukkueen tiloissa. Tämä osoittautui todella stressaavaksi siniselle joukkueelle. Sireenin lauetessa kaikki säntäsivät toimintaan tarkastamaan ympäristön tilaa ja etsimään potentiaalisia hakkereita.

Suurin ongelma siniselle joukkueelle oli oman ympäristön tunteminen. Dokumentaatio oli täysin puutteellinen ja tietysti täynnä tietoturvareikiä. Teimme myös ison virheen siinä, että luotimme liikaa dokumentaatioon.


Tässä kuva oikeasta infrastruktuurista. Laatikot vasemmalta oikealle: "Internet", DMZ, Office ja DMZ. Ylhäällä vasemmalla valkoinen joukkue, joka siis johti harjoitusta.

Sininen joukkue ei esimerkiksi koskaan havainnut kahta muuta web-palvelinta. Punainen joukkue löysi näistä kaksi, joista toiseen he murtautuivat. Sinisten tiedossa oleva palvelin otettiin pois verkosta, kun havaitsimme haavoittuvuuksia. Samalla havaitsimme mm. valmiiksi ladatun c99.php takaoven.

Parhaimpia omia oivalluksia, joissa olin mukana:
  • c99.php takaoven havaitseminen
  • Palomuurisäännöstön korjaus, jotta web-palvelimen mySQL ei näkynyt enää verkkoon
  • Ympäristöstä löytyneen WLAN-tukiaseman neutralointi DEAUTH-hyökkäyksellä
Sinisellä joukkueella ei ollut pääsyä palomuureihin, joten osittain ympäristön puolustaminen oli todella hankalaa. Toisaalta tämä olisi vaikeuttanut punaisen joukkueen työtä todella paljon. Saimme tehtyä muutoksia palomuureihin ainoastaan muutospyyntöjen avulla. Pelin infrastruktuuri oli myös suunniteltu siten, että molemmat joukkueet olivat saman NAT:n takana, jolloin emme voineet yksinkertaisesti sulkea yhteyksiä punaiselta joukkueelta.

Itse en käyttänyt varsinaista tuotantoympäristöä, vaan tämä oli tuotantotiimin vastuulla. Iso osa harjoituksesta oli tuotannon kontrollointia, jotta ei tapahtuisi päästöjä. Lisäksi hallitus valvoi tuotantoa ja hallitukselle oli lähetettävä lokitietoa tuotannon tilasta. Tätä varten oli pystytettävä palvelu harjoituksen aikana.

Illallistauon aikana selvisi, että olemme selkeässä johdossa. Olimme menettäneet paljon pisteitä päästöjen vuoksi, mutta olimme saaneet lisää pisteitä tietoturvaloukkausten raportoinnista, todisteiden keräämisestä ja mm. palomuurisääntöjen parantamisesta. Peli päättyi noin kello 22 illalla. Seuraavana päivänä kaikki kolme joukkuetta pitivät esityksen omasta näkökulmastaan.

Lopullinen pistetilanne. GG red!

Kokonaisuutena harjoitus oli erittäin opettavainen. Molemmat joukkueet ymmärsivät virheensä ja varmasti oppivat niistä. Jälleen kerran luova ajattelu olisi auttanut molemmat joukkueet parempaan lopputulokseen.

-Antti A

torstai 26. huhtikuuta 2012

Kriittisen infrastruktuurin hakkerointikilpailu on alkanut

KPMG:n sisäisen Hacknet-tilaisuuden odotetuin osuus, hakkerointikilpailu on alkanut. Ympäristö/peli on rakennettu seuraavalla tavalla. Kohteena ”Crazy Cola” –niminen yritys, joka valmistaa virvoitusjuomia. Yrityksen IT- ja prosessinohjausjärjestelmät on rakennettu käyttäen Amazon EC2 ja VPC palveluita. Peliin on varattu 40 fyysistä serveriä, joita ei käytä samaan aikaan kukaan muun. Lisäksi on pelin valvontaan käytettäviä koneita, jotka käyttävät jaettuja resursseja. Näitä valvontakoneita tai Amazonin management konsolia vastaan ei saa hyökätä.
Pelin rakentaneet asiantuntijamme kertovat käyttäneensä pelin rakentamiseen yli 1000 tuntia, joten kyseessä on aika merkittävä panostus. Olivat käyneet pitämässä samaa peliä myös Department  of Homeland securitylle.

Hacknet osallistujat on jaettu kolmeen tiimiin:
  • Red Cell team – hyökkää
  • Blue Cell team – Operoi kohdeyritystä ja CIRT tiimiä
  • White Cell team – Toimii kohdeyrityksen johtotiiminä, valvoo peliä ja toimii ”lain vartijoina”
Suomen osallistuja ovat yhtä ”petturia” lukuun ottamatta punaisessa tiimissä. Yksi tiimistämme on sinisessä tiimissä.
Punaisen tiimin tavoitteena on:
  • Häiritä yrityksen kolan tuotantoa
  • Estää yrityksen raportointi viranomaisille
  • Varastaa yrityksen luottamuksellista tietoa
  • Saada pysyvä jalansija yrityksen infrastruktuurissa
  • Toimia niin, että sininen tiimi ei havaitse punaisen tiimin toimintaa
Päivitys 14:10:
Myös sosiaalinen hakkerointi on sallittu, mutta hotellia, jossa olemme, ei saa vaurioittaa mitenkään.

Sekä punaisesta että sinisestä tiimistä on kadoksissa yksi henkilö,

Näyttää siltä, että sininen tiimi on laittanut ansoja ilmeisiin hyökkäyskohteisiin, joten punaisen tiimin pitää olla varovainen, jotta ei itse joudu hyökkäyksen kohteeksi.

Päivitys 14:35:
Yrityksen tuotannon hälytyssireenit kuuluvat soivan viereisestä huoneesta. Tämä tarkoittaa sitä, että sininen tiimi menettää pisteitä. Kuulimme, että ainakin osittain tämä johtuu ihan sinisen tiimin omasta kyvyttömyydestä ajaa omaa tehdastaan, ei siis pelkästää punaisen tiimin toiminnasta.

Punainen tiimi on jo löytänyt useita mahdollisia haavoittuvuuksia yrityksen infrastruktuurista.

Päivitys 14:55. Monista palveluista puuttuu päivityksiä, sininen tiimi päivittää laitteitaan minkä ehtii ja punainen tiimi etsii toimivia hyökkäyksiä. Kumpi tiimi on nopeampi?

Punaisen tiimin työskentelyä. Työn alla muun muassa Joomala admin konsoli, langaton verkko, yrityksen www-sivut ja sftpd.

päivitys 16:39. Hotelliin tuli pari pakettiautollista sotilaspoliiseja koirineen. Sillä ei toivottavasti ole mitään tekemistä meidän kanssa. Lisäksi meidän murtautuminen etenee liian hitaasti, koska koitamme olla mahdollisimman huomaamattomia ja kohteita on niin paljon.

päivitys 19:36. Ruokatauon jälkeen pidimme pienen yhteenvedon siitä, mitä olimme siihen mennessä löytäneet. Verkko on erittäin voimakkaasti segmentoitu ja sinen tiimi aktiivisesti katkaisee havaitsemiaan yhteyksiä, joten verkon ytimeen on vaikeaa päästä.  Hyvä puoli on se, että saimme hakkerointijuomaa. Ainakin viimevuonna se auttoi. Jaomme punasen tiimin kesken tehtäviä aikaisempaa paremmin ja pyrimme etenemään kohti verkon ydintä.


Sininen tiimi puolustaa

Päivitys 21:34. Aika loppui. Osan palveluista saimme haltuun ja sammutettua, mutta järjestelmiä emme kokonaan saaneet haltuun.

Analyysiä ja johtopäätökset:
Hyökäävänä osapuolena havaitsimme ainakin käytännössä sen, miten hyvällä verkon segmentoinnille ja liikenteen suodatuksella on mahdollista merkittävästi hankaloittaa kohteeseen murtautumista. Oleellista on rajoittaa myös kustakin segmentistä ulospäin lähtevää liikennettä, ei ainoastaan sisään tulevaa liikennettä.

Murtautumista ei myöskään helpota se, että vastapuolella on osaava CIRT-tiimi, joka aktiivisesti tekee toimenpiteitä kohteen puolustamiseksi. Monessa tapauksessa yhteydet katosivat alta juuri, kun jostakin kohdejärjestelmästä oltiin saamassa jotain jalansijaa.

Ehkä saamme blogiin myöhemmin myös sinisen tiimin näkemyksen tilanteesta.

keskiviikko 25. huhtikuuta 2012

KPMG:n tietoturvaosaajat ympäri maailman kokoontuvat Riikaan Hacknettiin

KPMG:n vuotuinen Hacknet on taas alkamassa. Tällä kertaa kokoonnumme Riikaan ja asiantuntijamme ympäri maailman ovat jo alkaneet saapua paikalle.
Huomenna ohjelmassa on eri maiden tiimien esitelmiä tietoturvallisuuteen liittyvistä auditoinneista, työkaluista ja muista ajankohtaisista asioista, joita tiimimme eri maissa ovat toteuttaneet. Huomenna aloitamme myös tiimien välisen kilpailun, jossa kohteena on Amazonin pilveen rakennettu öljyn-jalostamo ja sen prosessinohjausjärjestelmät. Luonnollisesti lähdemme hakemaan voittoa. Viimevuonna olimme saman tyylisessä kilpailussa toisia häviten voittaneelle UK:n tiimille noin 5 minuuttia.
Jos haluat mukaan voittajatiimiin, niin katso avoimet hakumme:

tiistai 24. huhtikuuta 2012

KPMG Hacknet 2012 - mobiilihakkerointi

KPMG:n tietoturva-asiantuntijoiden vuosittainen konfrenssi, Hacknet, on parhaillaan käynnissä Riiassa, Latviassa. Kahtena ensimmäisenä päivänä on käynnissä mobiililaitteiden tietoturvakoulutus. Koulutus keskittyy pitkälti Android- ja iOS-laitteisiin.

Koulutusluokka ja noin 20 osallistujaa. Allekirjoittanut valkoisessa hupparissa. Oikealla Pieter Ceelen, toinen kouluttajista KPMG Hollannista.

Kurssilaisia on ympäri maailmaa. Kaukaisimmat KPMG Etelä-Afrikasta ja Malesiasta. Suurin osa osallistujista on kuitenkin Euroopasta. Rapakon takaa emme valitettavasti ole koulutukseen vieraita, mutta varsinaisen konfrenssin alkaessa heitäkin varmasti saapuu.

Kurssilla on reilusti käytännön harjoituksia. Vielä emme ole päässet käytännön hakkerointiin, mutta palaan niihin myöhemmin.

-Antti A

IAM hankkeissa on syytä ottaa huomioon GRC:n vaatimustenmukaisuus ja IAG:n tuomat mahdollisuudet

Monessa organisaatiossa on tällä hetkellä IAM-hanke (Identity and Access Management) käynnistymässä, käynnistynyt tai päättynyt. IAM-hankkeissa on syytä ottaa huomioon että identiteetin- ja käyttövaltuushallintaan liittyy yhä enemmän myös raportointivelvollisuuksia ja hyvän hallinnon vaatimuksia sisäisten ohjeistusten ja ulkoisten standardien myötä – kuten esim. Valtionhallinon VAHTI-ohje, korttimaailman PCI-DSS ja finanssimaailman Basel II. IAM kuuluu tästä syystä osaksi organisaation omaa GRC:ta (Governance, Risk & Compliance), joka on mahdollisesti myös alun perin käynnistänyt koko IAM-hankkeen organisaatiossa.

Maailmalla on tullut yhä enemmän tavaksi liittää IAM:ää olennaiseksi osaksi GRC:ta, ja tätä lähestymistä kutsutaan IAG:ksi (Identity & Access Governance). IAG:ta helpottamaan voidaan lisäksi integroida IAI:ta (Identity & Access Intelligence). IAM on siis hyvä olla osana GRC:ta ja toisaalta IAM luo velvollisuuksia GRC:n suhteen.

Mutta, perinteiset IAM-toimittajat - joitakin lukuun ottamatta - eivät ole vielä ainakaan isommassa mittakaavassa Integroineet GRC:tä osaksi IAM-ratkaisujaan, eli lisänneet tai laajentaneet ratkaisuja IAG-ominaisuuksilla. Joissain ratkaisuissa on esim. IAG raportointivalmius olemassa, mutta tiedonkeruu raportointia ajatellen ei onnistu. Toisissa sitten tiedonkeruu onnistuu, mutta raportointisovellus puuttuu. Muutamissa IAM-ratkaisuissa on jo täysiverinen tuki IAG:lle, mutta mahdollisesti itse projektissa ei ole otettu IAM-hanketta GRC:n näkökulmasta huomioon ja sitä kautta ottanut IAG-ominaisuudet käyttöön.

On kuitenkin selvää, että identiteetin- ja käyttövaltuustiedon kerääminen (data mining) eri sovelluksista ja järjestelmistä ja sen tallentaminen erilliseen ns. identiteetti-tietovarastoon (Identity Data Warehouse) on haasteellinen tehtävä. Näistä tiedoista pitäisi koostaa järkevän muotoista ja vaatimustenmukaista raporttia esim. IT-tarkastukselle kuukausittain. Tästä syystä löytyykin jo pieni valikoima eri toimittajien puhtaasti IAG-lähtöisiä ratkaisuja joita käytetään täydentämään nykyisiä IAM-ratkaisuja. Myös perinteiset IAM-toimittajat ovat kehittämässä IAG-toiminnallisuuksia nykyisiin ratkaisuihinsa.

Gartner on hiljattain julkaissut ensimmäisen "Magic Quadrant for Identity and Access Governance" jossa se ennustaa IAG:n olevan IAM-hankkeiden nopeiten kasvava markkinasektori. Lähitulevaisuus IAM alueella on siis erittäin mielenkiintoinen. IAM-pelikenttä laajenee sekä uusien ominaisuuksien että uusien toimittajien myötä ja ostajan pitää olla entistä valppaampi siitä, mikä on lähtökohtainen IAM:n tarve, mikä on GRC:n vaatimukset ja mitä on tarjolla esim. IAG:n suhteen.

keskiviikko 4. huhtikuuta 2012

Pankkitroijalainen tyhjentää tilejä Suomessakin - ja näin se toimii

Vuosia keksimisensä jälkeen niin sanottu Man in the Browser - hyökkäys ylittää suomessakin uutiskynnyksen.

http://www.iltasanomat.fi/digi/pankkitroijalainen-tyhjentaa-tileja-suomessakin/art-1288460044982.html

KPMG:n hacknet-tilaisuudessa demosimme tätä hyökkäystä muistaakseni 3 tai 4 vuotta sitten. Demossa työntekijämme "huijasi" itseltään ulkomaisesta pankista yhden sentin (omalta tililtään).

Hyökkäys toimii näin:

  1. Hyökkääjä valmistelee sopivan haittaohjelman ja keksii sopivan tavan saada se mahdollisimman monelle käyttäjälle.
  2. Haittaohjelma on testattu eri virusskannereilla sen varmistamiseksi, että sitä ei löydetä - Netissä on tahoja, jotka toimittavat haittaohjelmia takuulla. Jos ohjelma löytyy virusskannerilla ostaja saa takuuseen uuden version.
  3. Uhri saa haittaohjelman koneelleen esim. puuttuvien päivitysten ja varomattoman linkkien klikkailun seurauksena.
  4. Haittaohjelma jää odottamaan, että uhri menee verkkopankkiin.
  5. Uhri menee verkkopankkiin ja kirjautuu sinne esim. kertakäyttösalasanalla.
  6. Uhri menee verkkopankissa maksamaan laskun ja syöttää laskun tiedot.
  7. Haittaohjelma aktivoituu ja selaimessa muuttaa pankille lähetettävän laskun tiedot (tilinumeron ja summan), mutta näyttää käyttäjälle alkuperäisen laskun tiedot.
  8. Uhri hyväksyy laskun, jolloin selain lähettää pankille muokatun laskun ja näyttää käyttäjälle alkuperäisen laskun olevan hyväksytty.
  9. Pankin järjestelmä vastaanottaa muokatun laskun ja lähettää uhrille hyväksymispyynnön.
  10. Selain vastaanottaa hyväksymispyynnön muokattuun laskuun, mutta näyttää uhrille hyväksymispyynnön alkuperäiseen laskuun.
  11. Uhri hyväksyy maksun tunnusluvullaan ja selain lähettää hyväksymisvahvistuksen pankkiin.
  12. Pankki laittaa muokatun maksun maksettavaksi.
  13. Uhri luulee maksaneensa alkuperäisen laskun.
  14. Haittaohjelma jää taustalle ja muokkaa esim. käyttäjälle näytettävää tilin saldoa niin, että käyttäjä edelleen luulee tililtään lähteneen alkuperäisen summan, vaikka sieltä lähti haittaohjelman määrittelemä summa.
  15. Pankin järjestelmässä ei koskaan ollut periaatteessa mitään vikaa tai tietoturvapuutetta, vika oli käyttäjän koneessa. Pankin kannalta käyttäjä on myös itse hyväksynyt maksun omilla tunnuksillaan, joten sopimusehtojen mukaan uhri on itse vastuussa tapahtuneesta transaktiosta. (toistaiseksi pankit ovat kuitenkin monesti korvanneet vahingot)
Miten tämä sitten vältetään?
  1. Käyttämällä nettipankkia mahdollisimman turvalliselta koneelta
  2. Katsomalla saldotietoja välillä joltakin toiselta koneelta
  3. Käyttämällä maksujen tekstiviestivarmennusta tms, jos pankki sitä tukee (ja oikeasti lukemalla tekstiviestissä olevat maksutiedot ennen hyväksymistä. Tekstiviestissä näkyisi muokatun maksun tiedot olettaen, että hyökkääjä ei pysty modifioimaan myös tekstiviestejä - mobiililaitteissa tämäkin voi olla mahdollista....)