Riippuvuusristiriidat altistavat hyökkäyksille

Mitä riippuvuusristiriidalla (dependency confusion) tarkoitetaan?

Yrityksien sisäisissä ohjelmistoissa käytetään kirjastoja, joista osa on tarkoitettu vain yrityksen sisäiseen käyttöön. Näitä sisäisiä kirjastoja jaellaan yrityksen sisällä, eikä niitä julkaista avoimena lähdekoodina julkisiin palveluihin.

Mikäli yritys on käyttänyt sisäistä kirjastoa ja julkiseen palveluun julkaistaan saman niminen paketti kuin kirjastossa, on mahdollista, että julkaistu saman niminen paketti korvaakin sisäisesti käytössä olevan kirjaston osan esimerkiksi käännösautomaatiossa tai muussa jatkuvan integraation järjestelmässä. Tämä tarkoittaa sitä, että järjestelmä huomaa uuden tiedoston, joka on jaossa uudemmalla versionumerolla kuin tällä hetkellä ajossa oleva.

Tiedosto "xyz_version_31" on siis "uudempi" tai "parempi", kuin ajossa oleva "xyz_version_30" ja näin ollen se käydään päivittämässä automaattisesti uuteen, mikäli päivitysprosessi on näin määritelty. Tällä tavoin hyökkääjä voi saada koodia ajoon yrityksen sisäisiin järjestelmiin julkaisemalla uuden kirjaston sisäisen kirjaston nimellä.
Tämä tapahtui esimerkiksi PayPalille, jonka tietoja näkyi GitHubissa juuri sen verran, että tutkija Alex Birsan sai tietoonsa minkä nimisiä kirjastoja PayPalilla oli käytössään. Tällöin hän asetti tarjolle juurikin uudemmalla versionumerolla olevia paketteja, jotka käytiin lataamassa PayPalin käyttöön.

Kirjastot, luottamus ja riippuvuudet muista toimijoista

Organisaatioissa käytössä olevat tiedostot, ohjelmistot ja järjestelmät muodostavat monimutkaisia ja pitkiä ketjuja. Mikäli näiden toimitusketjujen riskejä halutaan aidosti hallita on syytä myös tietää millaisista osista nämä erilaiset ketjut koostuvat.

Tuntemattomien toimitusketjujen ongelma ei liiketoiminnan näkökulmasta koske pelkästään haavoittuvuuksia. Paljon käytetyt avoimen lähdekoodin ratkaisut voivat myös sisältää lisenssiehtoja, jotka eivät ole komponenttia hyödyntävän ratkaisun omistajan tiedossa. Lisenssiehdot puolestaan voivat edellyttää vaikkapa sitä hyödyntävän tuotteen lähdekoodin avaamista. Onkin siis syytä tietää myös liiketoimintariskin hallitsemiseksi, mistä omat järjestelmät koostuvat.