Die CocoaPods Saga: Het oopbron Apple se sekuriteitsmodel gebreek?

Oopbron-afhanklikhede het 'n groeiende bron van risiko vir organisasies van alle vorms en groottes geword. log4j, xz Gebruik en ander hoëprofielverhale het sistematiese swakhede in die ekosisteem uitgelig, wat bedreigingakteurs toenemend in staat is om te ontgin. Maar min het vermoed dat Apple ooit geraak sou word. Dit is immers die verkoper wat enige toepassings wat op sy App Store toegelaat word, streng ondersoek. Wel, dit was tot 1 Julie, wanneer sekuriteitsnavorsers laat val nog 'n oopbronbom: kritieke nuwe kwesbaarhede in 'n gewilde afhanklikheidsbestuurder wat in meer as drie miljoen macOS- en iOS-toepassings gebruik word.

Die foute is reggemaak, maar niemand weet of hulle reeds in geheime voorsieningskettingaanvalle uitgebuit is nie. Dit laat 'n toenemend algemene vraag ontstaan: Hoe los ons 'n probleem soos oopbron op?

Wat het gebeur?

Die kwesbaarhede is gevind in CocoaPods, 'n bewaarplek vir oopbron Swift- en Objective-C-projekte waarop miljoene Apple-toepassings afhanklik is. Dit beskik oor meer as 100,000 XNUMX eksterne biblioteke (of 'peule'), wat sommige van die wêreld se gewildste toepassings gebruik – insluitend Airbnb, Instagram en Uber. Volgens EVA Information Security is die kwesbaarhede soos volg:

CVE-2024-38368: 'n Ontwerpfout in die CocoaPods-bediener laat enige gebruiker toe om 'n peul te eis wat nie 'n geïdentifiseerde eienaar het sonder dat enige verifikasie nodig is nie. Daar is vandag duisende van hierdie eienaarlose peule. Volgens Endor Labs beteken dit dat 'n bedreigingsakteur 'n CocoaPods-rekening kon registreer, 'n peul kon opeis en wanware begin versprei het asof hulle 'n betroubare onderhouer was. Dit het 'n CVSS-telling van 9.3.

CVE-2024-38367: Die CocoaPods-bediener vertrou 'n versoekopskrif wat dit nie moet nie, wat 'n aanvaller in staat stel om die e-posvalideringswerkvloei te ondermyn om rekeningoornames te voorkom. Dit kon daartoe gelei het dat bedreigingsakteurs bestaande gebruikersrekeninge gekaap het en die gepaardgaande peule met kwaadwillige of gekompromitteerde weergawes vervang het. Dit het 'n CVSS-telling van 8.2.

CVE-2024-38366: Kom uit 'n kwesbaarheid in 'n Ruby-edelsteen genaamd "rfc-822", wat 'n oopbron-biblioteek is waarvan die CocoaPods-bedienersagteware afhanklik is om e-posadresse te valideer. Bedreigingsakteurs kon dit uitgebuit het om eksterne kode-uitvoering op die Trunk-bediener te verkry. Dit het 'n CVSS-telling van 10.0.

Wat gebeur volgende?

Die goeie nuus is dat die foute verlede Oktober reggestel is. Maar daar bly vraagtekens oor of hulle dalk die afgelope dekade uitgebuit is, gegewe die aantal peule wat blootgestel is en die tydsduur wat hulle blootgestel is (10+ jaar). As hulle het, sou die kompleksiteit van die sagteware-verskaffingsketting die bedreigingsakteur(s) baie dekking gegee het.

“Terwyl daar geen direkte bewyse is dat enige van hierdie kwesbaarhede in die natuur uitgebuit word nie, is bewyse van afwesigheid nie afwesigheid van bewyse nie,” waarsku EVA.

Dit is hoekom die verkoper enige ontwikkelaars wat geraak word (diegene wat CocoaPods voor Oktober 2023 gebruik) aanbeveel om hul kode deur die volgende stappe te beveilig:

• Hou "podfile.lock"-lêers gesinchroniseer met alle CocoaPods-ontwikkelaars sodat almal op dieselfde weergawe van die pakkette is. Dit beteken dat as 'n nuwe skadelike opdatering gepleeg word, ontwikkelaars nie outomaties daarby sal opdateer nie.
• Vir peule wat intern ontwikkel is en slegs in CocoaPods gehuisves word vir verspreiding, moet ontwikkelaars CRC (checksum) validering uitvoer teen die een wat van die CocoaPods stambediener afgelaai is om te verseker dat dit dieselfde is as die een wat intern ontwikkel is.
• Implementeer 'n deeglike sekuriteitsoorsig van enige derdeparty-kode wat in toepassings gebruik word
• Hersien CocoaPods afhanklikhede en verifieer dat jy nie 'n wees peul gebruik nie.
• Gebruik slegs derdeparty-afhanklikhede wat aktief onderhou word en waarvan die eienaarskap duidelik is.
• Voer periodieke sekuriteitskodeskanderings uit om geheime en kwaadwillige kode op alle eksterne biblioteke op te spoor, veral CocoaPods.

Die groter prentjie

Ontwikkelaars maak steeds staat op oopbronkomponente omdat dit 'n vinnige, koste-effektiewe en maklike manier is om ontwikkelingstye te verkort. Maar die risiko's word te groot om te ignoreer. Volgens ISMS.online's Stand van inligtingsekuriteitsverslag 2024, is driekwart (75%) van organisasies geraak deur 'n sekuriteitsvoorval wat deur 'n derdeparty-verskaffer of -verskaffer veroorsaak is. En byna die helfte (45%) het die afgelope jaar verskeie voorvalle gehad.

“Oopbronsagteware, wat publiek toeganklik is, kan onontdekte of ongelapte kwesbaarhede bevat wat kwaadwillige akteurs kan ontgin. Dit word vererger deur die gebrek aan toegewyde ondersteuning in baie oopbronprojekte, wat dit uitdagend maak om tydige bystand of opdaterings te kry wanneer probleme opduik,” argumenteer Rich Hildyard, sagtewareproduk- en afleweringsleier by mobiele sekuriteitspesialis MOBSTR.

“Nog 'n beduidende risiko hou met lisensiëring verband. Nie-nakoming van oopbronlisensies kan tot regskomplikasies lei, veral wanneer lisensies spesifieke vereistes het waaraan voldoen moet word.”

Hildyard waarsku ook teen projekte wat deur hul instandhouers laat vaar kan word.

"Wanneer dit gebeur, word gebruikers sonder noodsaaklike opdaterings of regstellings gelaat, wat die stabiliteit en sekuriteit van hul stelsels in gevaar kan stel," sê hy aan ISMS.online. "Verenigbaarheidskwessies hou ook 'n bedreiging in, aangesien opdaterings in oopbronafhanklikhede soms veranderinge of konflikte met ander sagtewarekomponente kan inbring, wat die algehele funksionaliteit ontwrig."

Boris Cipot, senior sekuriteitsingenieur by die Synopsys Software Integrity Group, voer aan dat die kompleksiteit en blote volume van direkte en oorganklike afhanklikhede dit uitdagend maak vir CISO's om kwesbaarhede wat verskeie projekte beïnvloed, te bestuur en op te spoor. Selfs as hulle kan, kan pleistering vertraag word as gevolg van kommer oor verenigbaarheid en/of toetsvereistes, sê hy aan ISMS.online.

Verminder oopbronrisiko met ISO 27001

Dit is egter moontlik om die risiko van 'n ander Log4Shell of CocoaPods te versag. Hy voer aan dat die voortdurende monitering van oopbronkomponente, insluitend deur sagtewaresamestellingsanalise (SCA)-instrumente, om oopbronkomponente en hul afhanklikhede outomaties te identifiseer en te bestuur, sal help. Cipot bepleit ook dat sekuriteitspanne ISO 27001 volg.

"ISO/IEC 27001 is 'n internasionale standaard vir inligtingsekuriteitbestuurstelsels (ISMS) wat 'n sistematiese benadering bied om sensitiewe maatskappyinligting te bestuur en die sekuriteit daarvan te verseker," verduidelik hy. Hierdie standaard kan ook organisasies help om risiko's wat verband hou met die gebruik van oopbronsagteware te versag deur 'n gestruktureerde raamwerk te skep wat verskeie risiko's aanspreek, en sodoende algehele inligtingsekuriteit verbeter."

Dit bied besondere waarde met:

• Risikobepaling en behandeling: Insluitend die evaluering van die risiko's van die gebruik van oopbronsagteware, soos kwesbaarhede, gebrek aan ondersteuning of lisensiëringskwessies, en die implementering van maatreëls om hierdie risiko's te verminder
• Batebestuur: Die handhawing van 'n inventaris van inligtingsbates, insluitend oopbronsagteware, help met die identifisering en bestuur van die sagteware se sekuriteitsaspekte, om te verseker dat alle komponente op datum en veilig is
• Toegangsbeheer: Om te verseker dat slegs gemagtigde personeel oopbronsagteware kan gebruik of wysig, om ongemagtigde veranderinge te voorkom wat kwesbaarhede kan veroorsaak
• Sekuriteitsbeleide en -prosedures: Dit kan riglyne vir die gebruik, monitering en opdatering van oopbronsagteware insluit
• Verskafferverhoudings: Verseker dat derdeparty oopbronsagtewareverskaffers voldoen aan sekuriteitstandaarde en -praktyke wat ooreenstem met die organisasie se eie
• Patchbestuur: Om te verseker dat enige sekuriteitskwesbaarhede in oopbronsagteware dadelik geïdentifiseer en aangespreek word
• Insidentbestuur: 'n Gedefinieerde proses vir die bestuur van sekuriteitsinsidente, insluitend die opsporing en reaksie op kwesbaarhede of oortredings wat met oopbronsagteware geassosieer word, die minimalisering van skade en vinnig herstel
• Voldoening aan wetlike vereistes: Die standaard help organisasies om te voldoen aan wetlike, regulatoriese en kontraktuele vereistes, insluitend die nakoming van oopbronlisensies en om te verseker dat die gebruik van oopbronsagteware nie intellektuele eiendomswette oortree nie.
• Deurlopende verbetering: Bevordering van 'n kultuur van voortdurende verbetering, waar die doeltreffendheid van sekuriteitskontroles, insluitend dié wat met oopbronsagteware verband hou, gereeld hersien en verbeter word.
• Opleiding en bewustheid: Om te verseker dat werknemers die risiko's wat met oopbronsagteware geassosieer word, verstaan ​​en die maatreëls in plek om daardie risiko's te versag

Vandag is oopbron oral, wat sekuriteitverbeterings 'n gedeelde verantwoordelikheid maak tussen alle gebruikers, onderhouers, bydraers en ondersteuners.

"CISO's moet verhoudings binne die gemeenskap bevorder en deelneem aan samewerkende pogings om sekuriteitspraktyke regoor die voorsieningsketting te verbeter," sluit Cipot af. Intussen kan 'n kultuurverskuiwing in baie eindgebruikersorganisasies nodig wees. Oopbronrisiko's is nie dieselfde as dié wat uit eie kode spruit nie. Hoe gouer meer CISO's daardie feit aanvaar en leer om dit te bestuur, hoe beter.