Open-sourceafhankelijkheden vormen een steeds grotere bron van risico voor organisaties van alle soorten en maten. log4j, xz Hulpmiddelen en andere spraakmakende verhalen hebben systematische zwakheden in het ecosysteem benadrukt, die steeds beter in staat zijn te exploiteren. Maar weinigen vermoedden dat Apple ooit getroffen zou worden. Dit is tenslotte de leverancier die alle applicaties die in zijn App Store worden toegestaan, streng controleert. Nou, dat was tot 1 juli, toen beveiligingsonderzoekers lieten vallen Nog een opensourcebom: kritieke nieuwe kwetsbaarheden in een populaire afhankelijkheidsbeheerder die in meer dan drie miljoen macOS- en iOS-applicaties wordt gebruikt.

De bugs zijn verholpen, maar niemand weet of ze al zijn uitgebuit in geheime supply chain-aanvallen. Dit roept een steeds vaker voorkomende vraag op: hoe lossen we een probleem als open-source op?

Wat is er gebeurd?

De kwetsbaarheden werden gevonden in CocoaPods, een repository voor open-source Swift- en Objective-C-projecten waar miljoenen Apple-apps van afhankelijk zijn. Het bevat meer dan 100,000 externe bibliotheken (of 'pods'), die enkele van 's werelds populairste apps gebruiken, waaronder Airbnb, Instagram en Uber. Volgens EVA Information Security zijn de kwetsbaarheden als volgt:

CVE-2024-38368: Een ontwerpfout in de CocoaPods-server zorgt ervoor dat elke gebruiker een pod kan claimen die geen geïdentificeerde eigenaar heeft zonder dat er verificatie nodig is. Er zijn tegenwoordig duizenden van deze eigenaarloze pods. Volgens Endor Labs betekent dit dat een bedreigingsactor een CocoaPods-account had kunnen registreren, een pod had kunnen claimen en malware had kunnen verspreiden alsof hij een vertrouwde beheerder was. Het heeft een CVSS-score van 9.3.

CVE-2024-38367: De CocoaPods-server vertrouwt een aanvraagheader die hij niet zou moeten vertrouwen, waardoor een aanvaller de e-mailvalidatieworkflow kan ondermijnen om accountovernames te voorkomen. Dit zou ertoe kunnen hebben geleid dat bedreigingsactoren bestaande gebruikersaccounts hebben gekaapt en de bijbehorende pods hebben vervangen door kwaadaardige of gecompromitteerde versies. Het heeft een CVSS-score van 8.2.

CVE-2024-38366: Komt voort uit een kwetsbaarheid in een Ruby gem genaamd "rfc-822", een open-source bibliotheek waarvan de CocoaPods server software afhankelijk is om e-mailadressen te valideren. Threat actoren zouden het kunnen hebben misbruikt om remote code execution op de Trunk server te bereiken. Het heeft een CVSS score van 10.0.

Wat gebeurt er nu?

Het goede nieuws is dat de bugs afgelopen oktober zijn opgelost. Maar er blijven vraagtekens over of ze de afgelopen tien jaar zijn uitgebuit, gezien het aantal blootgestelde pods en de tijdsduur dat ze zijn blootgesteld (10+ jaar). Als dat zo was, zou de complexiteit van de software-aanvoerketen de dreigingsactor(en) voldoende dekking hebben gegeven.

"Hoewel er geen direct bewijs is dat een van deze kwetsbaarheden in het wild wordt uitgebuit, is bewijs van afwezigheid geen afwezigheid van bewijs," waarschuwt EVA.

Daarom raadt de leverancier alle getroffen ontwikkelaars (die CocoaPods vóór oktober 2023 gebruikten) aan om hun code te beveiligen via de volgende stappen:

  • Houd "podfile.lock"-bestanden gesynchroniseerd met alle CocoaPods-ontwikkelaars, zodat iedereen dezelfde versie van de pakketten gebruikt. Dit betekent dat als er een nieuwe schadelijke update wordt gecommit, ontwikkelaars deze niet automatisch updaten.
  • Voor pods die intern zijn ontwikkeld en alleen in CocoaPods worden gehost voor distributie, moeten ontwikkelaars CRC-validatie (checksum) uitvoeren op basis van de pods die zijn gedownload van de CocoaPods-trunkserver om er zeker van te zijn dat deze gelijk is aan de intern ontwikkelde pods.
  • Voer een grondige beveiligingsbeoordeling uit van alle code van derden die in applicaties wordt gebruikt
  • Controleer de CocoaPods-afhankelijkheden en controleer of u geen weespod gebruikt.
  • Gebruik alleen afhankelijkheden van derden die actief worden onderhouden en waarvan de eigenaar duidelijk is.
  • Voer periodieke scans van de beveiligingscode uit om geheimen en schadelijke code in alle externe bibliotheken te detecteren, met name CocoaPods.

The Bigger Picture

Ontwikkelaars blijven vertrouwen op open-sourcecomponenten omdat ze een snelle, kosteneffectieve en gemakkelijke manier zijn om ontwikkeltijden te verkorten. Maar de risico's worden te groot om te negeren. Volgens ISMS.online's Rapport Staat van Informatiebeveiliging 2024, driekwart (75%) van de organisaties is getroffen door een beveiligingsincident veroorzaakt door een externe leverancier of leverancier. En bijna de helft (45%) heeft het afgelopen jaar meerdere incidenten gehad.

"Open source software, die openbaar toegankelijk is, kan onontdekte of ongepatchte kwetsbaarheden bevatten die kwaadwillende actoren kunnen misbruiken. Dit wordt verergerd door het gebrek aan toegewijde ondersteuning in veel open source projecten, waardoor het lastig is om tijdige assistentie of updates te krijgen wanneer er problemen ontstaan," betoogt Rich Hildyard, software product en delivery lead bij mobiele beveiligingsspecialist MOBSTR.

“Een ander belangrijk risico is gerelateerd aan licenties. Niet-naleving van open source-licenties kan leiden tot juridische complicaties, vooral wanneer licenties specifieke vereisten hebben waaraan moet worden voldaan.”

Hildyard waarschuwt ook voor projecten die mogelijk door hun beheerders worden verlaten.

"Wanneer dit gebeurt, blijven gebruikers achter zonder essentiële updates of fixes, wat de stabiliteit en veiligheid van hun systemen in gevaar kan brengen", vertelt hij aan ISMS.online. "Compatibiliteitsproblemen vormen ook een bedreiging, omdat updates in open source-afhankelijkheden soms wijzigingen of conflicten met andere softwarecomponenten kunnen introduceren, waardoor de algehele functionaliteit wordt verstoord."

Boris Cipot, senior security engineer bij de Synopsys Software Integrity Group, stelt dat de complexiteit en het enorme volume van directe en transitieve afhankelijkheden het voor CISO's lastig maken om kwetsbaarheden te beheren en te volgen die meerdere projecten beïnvloeden. Zelfs als ze dat kunnen, kan het patchen worden vertraagd vanwege compatibiliteitsproblemen en/of testvereisten, vertelt hij aan ISMS.online.

Het beperken van open source-risico's met ISO 27001

Het is echter mogelijk om het risico van een andere Log4Shell of CocoaPods te beperken. Hij betoogt dat het continu monitoren van open-source componenten, inclusief door Software Composition Analysis (SCA) tools, om open-source componenten en hun afhankelijkheden automatisch te identificeren en beheren, zal helpen. Cipot pleit er ook voor dat beveiligingsteams ISO 27001 volgen.

"ISO/IEC 27001 is een internationale standaard voor informatiebeveiligingsmanagementsystemen (ISMS) die een systematische aanpak biedt voor het beheren van gevoelige bedrijfsinformatie en het waarborgen van de beveiliging ervan", legt hij uit. Deze standaard kan organisaties ook helpen de risico's te beperken die gepaard gaan met het gebruik van open-sourcesoftware door een gestructureerd raamwerk te creëren dat verschillende risico's aanpakt, waardoor de algehele informatiebeveiliging wordt verbeterd."

Het biedt bijzondere waarde bij:

  • Risicobeoordeling en -behandeling: inclusief het evalueren van de risico's van het gebruik van open-source software, zoals kwetsbaarheden, gebrek aan ondersteuning of licentieproblemen, en het implementeren van maatregelen om deze risico's te beperken
  • Assetmanagement: Het bijhouden van een inventaris van informatie-assets, inclusief open-source software, helpt bij het identificeren en beheren van de beveiligingsaspecten van de software, en zorgt ervoor dat alle componenten up-to-date en veilig zijn.
  • Toegangscontrole: om ervoor te zorgen dat alleen geautoriseerd personeel opensourcesoftware kan gebruiken of wijzigen, en om ongeautoriseerde wijzigingen die kwetsbaarheden kunnen introduceren te voorkomen
  • Beveiligingsbeleid en -procedures: Deze kunnen richtlijnen omvatten voor het gebruik, de monitoring en de update van open-source software
  • Relaties met leveranciers: ervoor zorgen dat externe leveranciers van open-source software zich houden aan beveiligingsnormen en -praktijken die aansluiten bij de eigen normen en praktijken van de organisatie.
  • Patchbeheer: om ervoor te zorgen dat beveiligingslekken in opensourcesoftware snel worden geïdentificeerd en aangepakt
  • Incident Management: Een gedefinieerd proces voor het beheren van beveiligingsincidenten, inclusief het detecteren en reageren op kwetsbaarheden of inbreuken die verband houden met open-source software, het minimaliseren van schade en het snel herstellen
  • Naleving van wettelijke vereisten: de norm helpt organisaties te voldoen aan wettelijke, regelgevende en contractuele vereisten, waaronder het naleven van open-sourcelicenties en het garanderen dat het gebruik van open-sourcesoftware geen inbreuk maakt op intellectuele eigendomsrechten.
  • Continue verbetering: het bevorderen van een cultuur van continue verbetering, waarbij de effectiviteit van beveiligingsmaatregelen, inclusief die met betrekking tot open-source software, regelmatig wordt beoordeeld en verbeterd.
  • Training en bewustwording: ervoor zorgen dat werknemers de risico's begrijpen die gepaard gaan met open-source software en de maatregelen die zijn genomen om deze risico's te beperken

Tegenwoordig is open source alomtegenwoordig, waardoor beveiligingsverbeteringen een gedeelde verantwoordelijkheid zijn van alle gebruikers, beheerders, bijdragers en financiers.

"CISO's moeten relaties binnen de community onderhouden en deelnemen aan gezamenlijke inspanningen om beveiligingspraktijken in de hele toeleveringsketen te verbeteren", concludeert Cipot. In de tussentijd kan een cultuuromslag nodig zijn in veel eindgebruikersorganisaties. Open-sourcerisico's zijn niet hetzelfde als die welke voortvloeien uit propriëtaire code. Hoe eerder meer CISO's dat feit accepteren en leren beheren, hoe beter.