Java-sovelluksissa on havaittu sarjallistamisen purkuun liittyvä haavoittuvuus on arvioitua laajempi

Teemu Kääriäinen

Teemu Kääriäinen

Joulukuu 8, 2015 at 10:30

Viestintäviraston vajaa kuukausi sitten julkaiseman haavoittuvuustiedotteen mukaan Apachen Commons Collections -kirjastosta raportoitiin haavoittuvuus. Teknisesti se liittyy sarjallistamisen purkuun (deserialization tai unserialization). Kyseinen haavoittuva kirjasto on käytössä monissa erilaisissa ohjelmistoissa.

Haavoittuvuudesta on syytä huomioida, että ongelma ei kuitenkaan rajoitu pelkästään Apache Commons Collections -kirjastoon, vaan sen juurisyy on Javan luokkien serialisointimekanismi.
Serialisoituvien Java-luokkien mukana on mahdollista toimittaa järjestelmään haavoittuvan palvelun kautta vahingollisia olioita, joiden avulla voidaan suorittaa järjestelmässä komentoja eli ajaa haluttuja sovelluksia. Se siis käytännössä mahdollistaa käyttöjärjestelmätason sovellusten ja komentojen ajamisen.

Ongelma on siis on poikkeuksellisen laaja ja vakava.

Tyypillisiä paikkoja, joissa Javassa käytetään serialisoituvia luokkia ovat:

1. HTTP-pyynnöt, -parametrit, -tilatiedot, -evästeet jne.
2. RMI (Remote Method Invocation), perustuu täysin serialisointiin
3. RMI over HTTP, perustuu myös täysin serialisointiin
4. JMX (Java Management Extensions) perustuu täysin serialisointiin
5. JMS-viestit (Java Message Service -rajapinta)

Ongelman laajuudesta ja lukuisista toiminnallisuuksista, joissa juurisyy (Java-luokkien serialisointi) on käytössä, johtuen ongelman korjaaminen ei siis ikävä kyllä ratkea vain Commons Collections -kirjaston päivittämisellä.

Ongelman tunnistamiseen sekä korjaamiseen on olemassa seuraavat suositellut ratkaisut:

1. Apache Commons Collections -päivitys versiosta 3.2.1 versioon 3.2.2. Koskee kaikenlaisia sovelluksia eli web-sovellusten ohella myös sellaisia, jotka tarjoavat RMI/JMX/TCP-rajapintoja.
2. Turhien sovelluksen end-point URL:ien täydellinen eristäminen ulkoverkosta reverse proxy - tai LB-tuotteen avulla (toteutetaan whitelist sallituille osoitteille).
3. Vaarallisten sovellusparametrien täydellinen eristäminen ulkoverkosta reverse proxy - tai LB-tuotteen avulla (whitelist sallituille parametreille).
4. Kohtien 2. ja 3. tekeminen myös sisäverkossa mahdollisimman tiukasti. Ongelmia sisäverkossa voidaan aiheuttaa esim. CSRF-mallin mukaisilla hyökkäyksillä. Pääsyn rajaaminen sisäverkkoon ei kuitenkaan täysin suojaa haavoittuvuudelta, koska hyökkäys on mahdollinen myös esimerkiksi sähköpostitse toimitettavan linkin avulla.
5. Sovelluskoodin analysointi, jossa tarkistetaan miten sovellukset käsittelevät serialisoituvia luokkia ja miten niitä käsittelevät rajapinnat on toteutettu, sekä sovellusten päivittäminen.
6. Pääsyn estäminen RMI- ja JMX-rajapintoihin palomuuriratkaisujen avulla. Lisäksi pitää eristää myös muut TCP-rajapinnat (esim. JMS), jotka sallivat serialisoidun datan toimittamisen sovellukselle.
7. Sovellusten ja verkon skannaaminen haavoittuvien sovellusten löytämiseksi.

Ongelmia voivat aiheuttaa myös sovelluspalvelinten oletusasennuksissa näkyvissä olevat palvelut, jotka on myös syytä tarkastaa (esimerkiksi JBoss ja Weblogic). Myös haavoittuva Commons Collections -versio saattaa tulla sovelluspalvelimen luokkapolusta (esim. Jboss EAP 6.0 – 6.3). Ylipäätään haavoittuvuus on erittäin laaja ja sille avoinna olevia sovelluksia, frameworkeja ja kirjastoja löytyy todennäköisesti lisää.

Nixussa on jo tutkittu ja kehitetty tapoja ja menetelmiä tarkastaa palveluita ja löytää haavoittuvuudelle alttiita sovelluksia. Mikäli haluatte lisätietoa asiasta tai apua palveluidenne tarkastamisessa tai arvioinnissa haavoittuvuuden kannalta niin autamme mielellämme.