Ads 468x60px

torstai 7. heinäkuuta 2011

LulzSecin hakkerointimenetelmistä

LulzSec on yksi vuoden 2011 merkittävimmistä tietoturvailmiöistä. Lyhyen elinikänsä aikana ryhmä ehti murtautua mm. Sonyn ja Nintendon palvelimille, aiheuttaa merkittävän määrän haittaa ja saavuttaa paljon julkisuuttaa (tarkka lista LulzSecin nimiin laitetuista tietomurroista löytyy täältä).

LulzSec-juttujen lukeminen saa miettimään, mitä menetelmiä hakkerit käyttivät hyökkäysten toteuttamiseen. Tietoturvayhtiö Imperva julkaisikin hiljattain blogissaan analyysin, jossa kuvataan LulzSecin käyttämiä menetelmiä. Informaatio raporttiin on saatu Guardianin julkaisemista, LulzSecin jäsenen vuotamista IRC-lokeista.

Impervan analyysin mukaan kolme tärkeintä käytettyä hakkerointimenetelmää oli:

#1 Remote File Inclusion (RFI)
RFI-hyökkäyksessä hakkeri lataa oman tiedostonsa web-palvelimen suoritettavaksi käyttäen hyväksi web-sovelluksen syötteen käsittelyssä olevia puutteita. Tyypillisesti ladattu tiedosto on hakkerin kirjoittama skripti. IRC-lokien mukaan LulzSecc käytti RFI-haavoittuvuuden kautta boteiksi valjastettuja palvelimia hajautettujen palvelunestohyökkäysten toteuttamiseen mm. CIA:n julkista web-palvelinta vastaan.

#2 SQL-injektio (SQLi)
SQLi on web-hyökkäyksistä tunnetuin ja vaarallisin. SQLi-hyökkäyksessä käytetään hyväksi puutteita web-sovelluksen syötteenkäsittelyssä ja saadaan näin SQL-lauseita toteutettavaksi sovelluksen käyttämässä tietokannassa. IRC-lokien mukaan SQLi-hyökkäystä käytettiin ainakin Sonyn ja X-Factorin palvelimille tunkeutumisessa. Lisäksi lokeista selviää, että SQLi-hyökkäyksien toteuttamiseen on käytetty ilmaista sqlmap-työkalua, jota mekin käytämme SQLi-haavoittuvuuksien etsimiseen.

Tietoturvaorganisaatio OWASP julkaisee säännöllisesti top 10-listaa web-sovelluksen vaarallisimmista tietoturvariskeistä. Vuoden 2010 listauksessa SQLi löytyy kärkisijalta muiden injektiohaavoittuvuuksien kanssa.

#3 Cross site scripting (XSS)
XSS on toinen tunnettu ja vaarallinen web-hyökkäys. Tässä hyökkäyksessä sovellus saadaan suorittamaan hyökkääjän kirjoittamia käyttäen hyväksi puutteita sovelluksen syötteen käsittelyssä. XSS-hyökkäystä käytettiin ainakin Fox.com -verkkopalvelua vastaan. Myös XSS sijoittuu yleensä korkealle

OWASP:n vuoden 2010 top 10 -listauksessa XSS löytyy toiselta sijalta.

Mitä ylläolevista menetelmistä sitten voi päätellä? IRC-lokien mukaan LulzSec ei käyttänyt viruksia tai muita haittaohjelmia hyökkäysten toteuttamiseen. Ryhmä ei myöskään kirjoittanut hyväksikäyttökoodeja sovellustoimittajan vielä paikkaamattomiin haavoittuvuuksiin (ns. 0-day attack). Pääosa onnistuneista hyökkäyksistä tehtiin käyttäen yksinkertaisia menetelmiä ja julkisesti saatavilla olevia työkaluja. Myös hyväksikäytetyt haavoittuvuudet olivat hyvin tunnettuja web-sovellusten haavoittuvuustyyppejä, joita mekin löydämme testeissämme jatkuvasti.

Kaikki yllä mainitut haavoittuvuudet aiheutuvat puutteista sovelluksen syötteen käsittelyssä. Haavoittuvuuksien estäminen sovelluksen toteutusvaiheessa olisi yksinkertaista, mikäli tietoturva-asioihin kiinnitettäisiin enemmän huomiota jo web-sovelluksen toteutuksen yhteydessä. Eritoten seuraaviin asioihin panostamalla jo suunnitteluvaiheessa yllä käsiteltyjä hyökkäyksiä saa estettyä tehokkaasti:

#1 Syötteen käsittely
Puutteellinen syötteen käsittely on web-sovellusten yleisin ongelma, ja valitettavasti myös seurauksiltaan vakavin. Turvallisesti toteutettua syötteen käsittelyä on vaikea liittää jälkeenpäin valmiiseen sovellukseen, joten hyvä syötteenkäsittely tulisi suunnitella jo ennen implementoinnin aloittamista. Kannattaa myös yrittää välttää pyörän uudelleenkeksimistä ja käyttää alustan syötteenkäsittelymekanismeja ja/tai valmiita kolmannen osapuolen kirjastoja. Hyvä syötteen käsittelyn toteutus löytyy esim. OWASP:in ESAPI-kirjastosta.

#2 Sovelluksen lokikirjoitukset
Toinen tyypillinen web-sovelluksen puute liittyy tietoturvaan liittyvien tapahtumien lokikirjoituksiin. Tyypillisesti sovellukset eivät kirjoita riittävästi informaatiota tietoturvatapahtumista, jolloin hyökkäysten havaitseminen ja estäminen on vaikeaa. Erityisesti automaattisten hyökkäystyökalujen käyttämien aiheuttaa suuren määrän tapahtumia palvelimelle, joten toimivan lokituksen avulla hyökkäys havaittaisiin varmasti. Myöskään toimivaa lokitusta ei saa helposti liimattua valmiiseen web-sovellukseen, vaan mekanismi ja lokitettavat asiat tulee suunnitella huolella etukäteen. Toki jonkun pitää myös valvoa lokeja, jotta hyökkäykset havaittaisiin ajoissa.

Ei kommentteja:

Lähetä kommentti