Ads 468x60px

tiistai 30. lokakuuta 2012

Tarkastavatko pilvipalvelut, mobiilit ja sulautetut järjestelmät varmenteita vai eivät?

TLS/SSL lienee maailman käytetyin salausjärjestelmä ja protokolla. Salaus onkin helppoa, sen sijaan ei ole niinkään helppoa varmistaa, että yhteys menee sinne, minne sen luullaan menevän, ilman ylimääräistä salakuuntelijaa välissä.  Jos kyseessä on ns. tavallinen tapaus, homman riskit ymmärretään jotenkin: selain, interaktiivinen käyttäjä, tunnetut varmentajat. Jos ruudulle tulee huomautus, että varmenteessa on jotakin pielessä, esim. "varmentaja on tuntematon", asiantunteva (!?) käyttäjä voi ottaa kantaa, uskaltaako hän hyväksyä sen.

The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software
http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

Tässä tutkimuksessa tilanne on kuitenkin toinen. Tutkittiin erilaisia SSL-kirjastoja, esim. Amazonin EC2-Java-kirjastoja ja Amazonin ja Paypalin kauppapaikoille tarjomia maksu-SDK-kirjastoja ja lukuisia muita Web-kauppa- ja mobiilisoftia.

Suurin osa haasteesta palautuu siihen, miten yleisimmät TLS-toteutukset (JSSE, OpenSSL, GnuTLS) implementoivat varmenteen tarkastamisen. Lopputulos on, että usein APIt aivan liian helposti mahdollistavat sen, että väärää varmennetta ei torjuta. Mikäli interaktiivista käyttäjää ei edes ole (esim. sulautetuissa järjestelmissä, eräajoissa, taustaoperaatioissa, palvelin-palvelin-yhteyksissä) ohjelmoijalla on ikävä valinta: joko epävarmakin varmenne (esim. self-signed, tai mikä tahansa tuntemattoman varmentajan varmenne) hyväksytään, tai yhteyttä ei voida muodostaa.

Usein järkevää valintaa ei ilmeisesti ole edes mietitty, vaan varmenteet hyväksytään ihan silkasta typeryydestä, tai siksi, että sekavaa APIa ei osattu käyttää oikein.

Myös KPMG:n omissa koodi- ja järjestelmäauditoinneissa on nähty, että jopa tietoturvakriittiset mobiili-clientit joko vahingossa tai tahallaan mieluummin avaavat yhteyden heikolla varmenteella kuin antavat virheilmoituksen lokiin ja lopettavat toimintansa.

Lopputulos on, että monen "turvatun" pilvipalvelun sekä kriittisen pankki- ja maksujärjestelmän TLS-yhteyksien salakuuntelu ja modifikaatio lennossa on mahdollista. Tämä toki vaatii, että ensin hyökkääjä pääsee liikenteen varrelle. Eli esim. samaan lähiverkkoon (ja VLANiin, jossa voi ARP-huijata), jossa joko a) client tai b) palvelin on. Tai "hyökkääjä" (esim. valtiollinen vakooja) on operaattorin verkossa.

Jatkossa ottakaame opiksi, kun tehdään/hankitaan/käytetään näitä softia:

1. Testaa: hyväksyykö järjestelmä itse tehtaillun varmenteen!
2. Alä disabloi varmennetarkastusta tuotantoversiossa,  mielellään älä testiversiossakaan!
3. Alä luota (kirjastojen tai systeemien) varmennetarkastusten oletusasetuksiin, varmista, että tarkastus on päällä!

2 kommenttia:

Anssi Porttikivi kirjoitti...

Lisäselvennys:

Kun siis käytät mitä tahansa Web-palvelua X, joka käyttää taustalla Amazonin pilveä, se saattaa hyvinkin olla alttiina vihollisen salakuuntelulle ja tiedon muokkaamiselle lennossa siirtäessään dataa TLS-salattuna palvelun X ja Amazonin välillä.

Kun käytät mitä tahansa mobiilisovellusta, joka sisäisesti siirtää dataa TLS-yhteyden yli verkon kanssa, se saattaa olla alttina viholliselle.

Kun käytät mitä tahansa softaa missä tahansa, joka sisäisesti avaa TLS-yhteyksiä taustajärjestelmiin, saatat olla alttiina.

TLS-yhteydet palvelimien välillä samoin.

Anssi Porttikivi kirjoitti...

Asiaan liittyen päivän uutinen, Diginotarin CA-murron post mortem -raportti on vihdoin annettu julkisuuteen kiistelyn jälkeen. Kirjoitettu Hollannin hallituksen toimeksiannosta. Keskustelu Slashdotissa:

http://tech.slashdot.org/story/12/10/31/207212/dutch-diginotar-servers-were-fully-hacked

Lähetä kommentti