CocoaPods Saga: Onko avoimen lähdekoodin rikkonut Applen suojausmallin?

Avoimen lähdekoodin riippuvuuksista on tullut kasvava riskilähde kaikenmuotoisille ja -kokoisille organisaatioille. log4j, xz Utils ja muut korkean profiilin tarinat ovat tuoneet esiin ekosysteemin systemaattisia heikkouksia, joita uhkatoimijat pystyvät yhä enemmän hyödyntämään. Mutta harvat epäilivät, että Apple koskaan vaikuttaisi asiaan. Loppujen lopuksi tämä on myyjä, joka valvoo voimakkaasti kaikkia App Storessa sallittuja sovelluksia. No, se oli heinäkuun 1. päivään asti, jolloin turvallisuustutkijat putosivat toinen avoimen lähdekoodin pommi: kriittisiä uusia haavoittuvuuksia suositussa riippuvuushallinnassa, jota käytetään yli kolmessa miljoonassa macOS- ja iOS-sovelluksessa.

Virheet on korjattu, mutta kukaan ei tiedä, onko niitä jo hyödynnetty salaisen toimitusketjun hyökkäyksissä. Tämä herättää yhä yleisemmän kysymyksen: Kuinka ratkaisemme avoimen lähdekoodin kaltaisen ongelman?

Mitä tapahtui?

Haavoittuvuudet löydettiin CocoaPodsista, avoimen lähdekoodin Swift- ja Objective-C-projektien arkistosta, josta miljoonat Apple-sovellukset ovat riippuvaisia. Siinä on yli 100,000 XNUMX ulkoista kirjastoa (tai "podsia"), joita jotkut maailman suosituimmista sovelluksista käyttävät – mukaan lukien Airbnb, Instagram ja Uber. EVA Information Securityn mukaan haavoittuvuudet ovat seuraavat:

CVE-2024-38368: CocoaPods-palvelimen suunnitteluvirhe mahdollistaa sen, että kuka tahansa käyttäjä voi vaatia kotelon, jolla ei ole tunnistettua omistajaa, ilman vahvistusta. Näitä omistamattomia paloja on nykyään tuhansia. Endor Labsin mukaan tämä tarkoittaa, että uhkatekijä olisi voinut rekisteröidä CocoaPods-tilin, lunastaa podin ja alkaa levittää haittaohjelmia ikään kuin he olisivat luotettu ylläpitäjä. Sen CVSS-pistemäärä on 9.3.

CVE-2024-38367: CocoaPods-palvelin luottaa pyynnön otsikkoon, johon sen ei pitäisi, jolloin hyökkääjä voi horjuttaa sähköpostin vahvistuksen työnkulkua tilin haltuunoton estämiseksi. Tämä olisi voinut johtaa siihen, että uhkatoimijat kaappasivat olemassa olevat käyttäjätilit ja korvasivat niihin liittyvät kotelot haitallisilla tai vaarantuneilla versioilla. Sen CVSS-pistemäärä on 8.2.

CVE-2024-38366: Johtuu "rfc-822"-nimisen Ruby-helmen haavoittuvuudesta, joka on avoimen lähdekoodin kirjasto, josta CocoaPods-palvelinohjelmisto käyttää sähköpostiosoitteiden vahvistamista. Uhkatoimijat olisivat voineet hyödyntää sitä koodin etäsuorittamiseen runkopalvelimella. Sen CVSS-pistemäärä on 10.0.

Mitä tapahtuu seuraavaksi?

Hyvä uutinen on, että virheet korjattiin viime lokakuussa. Mutta kysymysmerkkejä on edelleen siitä, onko niitä saatettu hyödyntää viimeisen vuosikymmenen aikana, kun otetaan huomioon paljaiden palojen määrä ja altistumisaika (yli 10 vuotta). Jos he olisivat tehneet, ohjelmistojen toimitusketjun monimutkaisuus olisi antanut uhkatoimijalle (toimijoille) runsaasti suojaa.

"Vaikka ei ole suoria todisteita näiden haavoittuvuuksien hyödyntämisestä luonnossa, todiste poissaolosta ei ole todisteen puuttuminen." varoittaa EVA.

Tästä syystä toimittaja suosittelee kaikkia vaikuttavia kehittäjiä (jotka ovat käyttäneet CocoaPodeja ennen lokakuuta 2023) suojaamaan koodinsa seuraavien vaiheiden avulla:

• Pidä "podfile.lock"-tiedostot synkronoituina kaikkien CocoaPods-kehittäjien kanssa, jotta kaikki käyttävät samaa pakettien versiota. Se tarkoittaa, että jos uusi haitallinen päivitys tehdään, kehittäjät eivät päivitä sitä automaattisesti.
• Sisäisesti kehitetyille podeille, joita isännöidään vain CocoaPodsissa jakelua varten, kehittäjien tulee suorittaa CRC (checksum) -tarkistus CocoaPods-runkopalvelimelta ladattua palvelinta vastaan ​​varmistaakseen, että se on sama kuin sisäisesti kehitetty.
• Suorita perusteellinen tietoturvatarkistus kaikille sovelluksissa käytetylle kolmannen osapuolen koodille
• .Tarkista CocoaPods-riippuvuudet ja varmista, että et käytä orpoa.
• Käytä vain kolmannen osapuolen riippuvuuksia, joita ylläpidetään aktiivisesti ja joiden omistajuus on selvä.
• Suorita säännöllisiä suojakoodiskannauksia löytääksesi salaisuudet ja haitalliset koodit kaikissa ulkoisissa kirjastoissa, erityisesti CocoaPodsissa.

Bigger Picture

Kehittäjät luottavat edelleen avoimen lähdekoodin komponentteihin, koska ne ovat nopea, kustannustehokas ja helppo tapa lyhentää kehitysaikoja. Mutta riskeistä on tulossa liian suuria, jotta niitä ei voida jättää huomiotta. ISMS.onlinen mukaan Tietoturvan tilaraportti 2024, kolme neljäsosaa (75 %) organisaatioista on kärsinyt kolmannen osapuolen toimittajan tai toimittajan aiheuttamasta tietoturvahäiriöstä. Ja lähes puolet (45 %) kärsi useista tapauksista viimeisen vuoden aikana.

”Avoimen lähdekoodin ohjelmistot, jotka ovat julkisesti saatavilla, voivat sisältää havaitsemattomia tai korjaamattomia haavoittuvuuksia, joita pahantahtoiset toimijat voivat hyödyntää. Tätä pahentaa omistetun tuen puute monissa avoimen lähdekoodin projekteissa, minkä vuoksi on haastavaa saada oikea-aikaista apua tai päivityksiä, kun ongelmia ilmenee”, väittää Rich Hildyard, ohjelmistotuote- ja toimituspäällikkö MOBSTR:sta.

”Toinen merkittävä riski liittyy lisensointiin. Avoimen lähdekoodin lisenssien noudattamatta jättäminen voi johtaa oikeudellisiin hankaluuksiin, varsinkin kun lisensseillä on erityisiä vaatimuksia, joita on noudatettava."

Hildyard varoittaa myös projekteista, jotka ylläpitäjät saattavat hylätä.

"Kun näin tapahtuu, käyttäjät jäävät ilman olennaisia ​​päivityksiä tai korjauksia, mikä voi vaarantaa heidän järjestelmiensä vakauden ja turvallisuuden", hän kertoo ISMS.online-sivustolle. "Yhteensopivuusongelmat ovat myös uhka, koska avoimen lähdekoodin riippuvuuksien päivitykset voivat joskus aiheuttaa muutoksia tai ristiriitoja muiden ohjelmistokomponenttien kanssa, mikä häiritsee yleistä toimintaa."

Boris Cipot, Synopsys Software Integrity Groupin vanhempi tietoturvainsinööri, väittää, että suorien ja transitiivisten riippuvuuksien monimutkaisuus ja valtava määrä tekevät CISO:lle haastavaa hallita ja seurata haavoittuvuuksia, jotka vaikuttavat useisiin projekteihin. Vaikka voisivatkin, korjaus saattaa viivästyä yhteensopivuusongelmien ja/tai testausvaatimusten vuoksi, hän kertoo ISMS.onlinelle.

Avoimen lähdekoodin riskin vähentäminen ISO 27001:n avulla

Toisen Log4Shellin tai CocoaPodin riskin pienentäminen on kuitenkin mahdollista. Hän väittää, että avoimen lähdekoodin komponenttien jatkuva seuranta, mukaan lukien Software Composition Analysis (SCA) -työkalut, avoimen lähdekoodin komponenttien ja niiden riippuvuuksien tunnistamiseksi ja hallitsemiseksi automaattisesti auttaa. Cipot kannattaa myös turvatiimejä, jotka noudattavat ISO 27001 -standardia.

"ISO/IEC 27001 on kansainvälinen tietoturvallisuuden hallintajärjestelmien (ISMS) standardi, joka tarjoaa systemaattisen lähestymistavan yrityksen arkaluonteisten tietojen hallintaan ja sen turvallisuuden varmistamiseen", hän selittää. Tämä standardi voi myös auttaa organisaatioita vähentämään avoimen lähdekoodin ohjelmistojen käyttöön liittyviä riskejä luomalla jäsennellyn viitekehyksen, joka käsittelee erilaisia ​​riskejä ja parantaa näin yleistä tietoturvaa."

Se tarjoaa erityistä arvoa:

• Riskien arviointi ja käsittely: mukaan lukien avoimen lähdekoodin ohjelmistojen käytön riskien, kuten haavoittuvuuksien, tuen puutteen tai lisenssiongelmien, arvioiminen ja toimenpiteiden toteuttaminen näiden riskien vähentämiseksi
• Omaisuudenhallinta: Tietovaraston ylläpito, mukaan lukien avoimen lähdekoodin ohjelmistot, auttaa tunnistamaan ja hallitsemaan ohjelmiston turvallisuusnäkökohtia ja varmistamaan, että kaikki komponentit ovat ajan tasalla ja turvallisia.
• Kulunvalvonta: Jotta vain valtuutetut henkilöt voivat käyttää tai muokata avoimen lähdekoodin ohjelmistoja, estetään luvattomat muutokset, jotka voivat aiheuttaa haavoittuvuuksia
• Suojauskäytännöt ja -menettelyt: Nämä voivat sisältää ohjeita avoimen lähdekoodin ohjelmistojen käyttöön, valvontaan ja päivittämiseen
• Toimittajasuhteet: Varmistetaan, että kolmannen osapuolen avoimen lähdekoodin ohjelmistotoimittajat noudattavat turvallisuusstandardeja ja -käytäntöjä, jotka ovat organisaation omien vaatimusten mukaisia.
• Korjausten hallinta: Varmistaaksesi, että avoimen lähdekoodin ohjelmistojen tietoturvaheikkoudet tunnistetaan ja korjataan nopeasti
• Tapahtumanhallinta: Määritelty prosessi tietoturvatapahtumien hallintaan, mukaan lukien avoimen lähdekoodin ohjelmistoihin liittyvien haavoittuvuuksien tai rikkomusten havaitseminen ja niihin vastaaminen, vahinkojen minimoiminen ja nopea palautuminen
• Lakisääteisten vaatimusten noudattaminen: Standardi auttaa organisaatioita noudattamaan laki-, säädös- ja sopimusvaatimuksia, mukaan lukien avoimen lähdekoodin lisenssien noudattaminen ja varmistaminen, että avoimen lähdekoodin ohjelmistojen käyttö ei riko immateriaalioikeuksia koskevia lakeja.
• Jatkuva parantaminen: Jatkuvan parantamisen kulttuurin edistäminen, jossa turvavalvonnan tehokkuutta, mukaan lukien avoimen lähdekoodin ohjelmistoihin liittyvät, tarkistetaan ja parannetaan säännöllisesti.
• Koulutus ja tietoisuus: Varmistetaan, että työntekijät ymmärtävät avoimen lähdekoodin ohjelmistoihin liittyvät riskit ja toimenpiteet näiden riskien vähentämiseksi

Nykyään avoin lähdekoodi on kaikkialla, mikä tekee tietoturvaparannuksista jaetun vastuun kaikkien käyttäjien, ylläpitäjien, avustajien ja tukien kesken.

"CISO:n tulisi edistää suhteita yhteisön sisällä ja osallistua yhteistyöhön turvakäytäntöjen parantamiseksi koko toimitusketjussa", Cipot päättää. Sillä välin kulttuurin muutos saattaa olla tarpeen monissa loppukäyttäjäorganisaatioissa. Avoimen lähdekoodin riskit eivät ole samoja kuin ne, jotka johtuvat omasta koodista. Mitä nopeammin CISO:t hyväksyvät ja oppivat hallitsemaan tämän tosiasian, sitä parempi.