The CocoaPods Saga: Har Open Source ødelagt Apples sikkerhedsmodel?

Open source-afhængigheder er blevet en voksende kilde til risiko for organisationer af alle former og størrelser. log4j, xz Utils og andre højprofilerede historier har fremhævet systematiske svagheder i økosystemet, som trusselsaktører i stigende grad er i stand til at udnytte. Men få formodede, at Apple nogensinde ville blive påvirket. Når alt kommer til alt, er dette leverandøren, der grundigt kontrollerer alle applikationer, der er tilladt i dens App Store. Nå, det var indtil 1. juli, hvor sikkerhedsforskere faldt endnu en open source-bombe: kritiske nye sårbarheder i en populær afhængighedsmanager brugt i over tre millioner macOS- og iOS-applikationer.

Fejlene er blevet udbedret, men ingen ved, om de allerede er blevet udnyttet i hemmelige forsyningskædeangreb. Dette rejser et stadig mere almindeligt spørgsmål: Hvordan løser vi et problem som open source?

Hvad skete der?

Sårbarhederne blev fundet i CocoaPods, et opbevaringssted for open source Swift- og Objective-C-projekter, som millioner af Apple-apps er afhængige af. Den har over 100,000 eksterne biblioteker (eller 'pods'), som nogle af verdens mest populære apps bruger – inklusive Airbnb, Instagram og Uber. Ifølge EVA Information Security er sårbarhederne som følger:

CVE-2024-38368: En designfejl i CocoaPods-serveren gør det muligt for enhver bruger at gøre krav på en pod, der ikke har en identificeret ejer, uden at der er behov for bekræftelse. Der er tusindvis af disse ejerløse bælg i dag. Ifølge Endor Labs betyder det, at en trusselaktør kunne have registreret en CocoaPods-konto, gjort krav på en pod og begyndt at distribuere malware, som om de var en betroet vedligeholder. Den har en CVSS-score på 9.3.

CVE-2024-38367: CocoaPods-serveren har tillid til en anmodningsheader, den ikke burde, hvilket gør det muligt for en hacker at undergrave e-mailvalideringsworkflowet for at forhindre kontoovertagelser. Dette kunne have ført til, at trusselsaktører kaprede eksisterende brugerkonti og erstattede de tilknyttede pods med ondsindede eller kompromitterede versioner. Den har en CVSS-score på 8.2.

CVE-2024-38366: Stammer fra en sårbarhed i en Ruby-perle kaldet "rfc-822", som er et open source-bibliotek, som CocoaPods-serversoftwaren afhænger af for at validere e-mail-adresser. Trusselsaktører kunne have udnyttet det til at opnå fjernudførelse af kode på Trunk-serveren. Den har en CVSS-score på 10.0.

Hvad sker der nu?

Den gode nyhed er, at fejlene blev rettet i oktober sidste år. Men der er stadig spørgsmålstegn ved, om de kan være blevet udnyttet i løbet af det sidste årti, givet antallet af eksponerede bælg og den tid, de har været udsat for (10+ år). Hvis de havde, ville kompleksiteten af ​​softwareforsyningskæden have givet trusselsaktøren(e) masser af dækning.

"Selvom der ikke er nogen direkte beviser for, at nogen af ​​disse sårbarheder bliver udnyttet i naturen, er bevis for fravær ikke fravær af beviser." advarer EVA.

Det er derfor, leverandøren anbefaler alle berørte udviklere (dem, der bruger CocoaPods før oktober 2023) at sikre deres kode gennem følgende trin:

• Hold "podfile.lock"-filer synkroniseret med alle CocoaPods-udviklere, så alle er på den samme version af pakkerne. Det betyder, at hvis en ny skadelig opdatering er begået, vil udviklere ikke automatisk opdatere til den.
• For pods udviklet internt og kun hostet i CocoaPods til distribution, bør udviklere udføre CRC (checksum)-validering mod den, der er downloadet fra CocoaPods-trunkserveren for at sikre, at den er den samme som den, der er udviklet internt.
• Implementer en grundig sikkerhedsgennemgang af enhver tredjepartskode, der bruges i applikationer
• .Gennemgå CocoaPods afhængigheder og bekræft, at du ikke bruger en forældreløs pod.
• Brug kun tredjepartsafhængigheder, der vedligeholdes aktivt, og hvis ejerskab er klart.
• Udfør periodiske sikkerhedskodescanninger for at opdage hemmeligheder og ondsindet kode på alle eksterne biblioteker, især CocoaPods.

Jo større billede

Udviklere fortsætter med at stole på open source-komponenter, fordi de er en hurtig, omkostningseffektiv og nem måde at forkorte udviklingstiden. Men risiciene bliver for store til at ignorere. Ifølge ISMS.online's Status for informationssikkerhedsrapport 2024, er tre fjerdedele (75%) af organisationerne blevet påvirket af en sikkerhedshændelse forårsaget af en tredjepartsleverandør eller -leverandør. Og næsten halvdelen (45 %) har været udsat for flere hændelser i løbet af det seneste år.

"Open source-software, der er offentligt tilgængelig, kan indeholde uopdagede eller uoprettede sårbarheder, som ondsindede aktører kan udnytte. Dette forværres af manglen på dedikeret support i mange open source-projekter, hvilket gør det udfordrende at få rettidig assistance eller opdateringer, når der opstår problemer,” argumenterer Rich Hildyard, softwareprodukt- og leveringsleder hos mobilsikkerhedsspecialist MOBSTR.

"En anden væsentlig risiko er relateret til licensering. Manglende overholdelse af open source-licenser kan føre til juridiske komplikationer, især når licenser har specifikke krav, som skal overholdes."

Hildyard advarer også om projekter, der kan blive forladt af deres vedligeholdere.

"Når dette sker, står brugerne tilbage uden væsentlige opdateringer eller rettelser, som kan bringe stabiliteten og sikkerheden af ​​deres systemer i fare," siger han til ISMS.online. "Kompatibilitetsproblemer udgør også en trussel, da opdateringer i open source-afhængigheder nogle gange kan introducere ændringer eller konflikter med andre softwarekomponenter, hvilket forstyrrer den overordnede funktionalitet."

Boris Cipot, senior sikkerhedsingeniør hos Synopsys Software Integrity Group, hævder, at kompleksiteten og det store omfang af direkte og transitive afhængigheder gør det udfordrende for CISO'er at administrere og spore sårbarheder, der påvirker flere projekter. Selvom de kan, kan patchningen blive forsinket på grund af kompatibilitetsproblemer og/eller testkrav, siger han til ISMS.online.

Afbødning af Open Source-risiko med ISO 27001

Det er dog muligt at mindske risikoen for en anden Log4Shell eller CocoaPods. Han hævder, at løbende overvågning af open source-komponenter, herunder ved hjælp af Software Composition Analysis (SCA) værktøjer, for at identificere og administrere open source-komponenter og deres afhængigheder automatisk vil hjælpe. Cipot går også ind for, at sikkerhedsteams følger ISO 27001.

"ISO/IEC 27001 er en international standard for informationssikkerhedsstyringssystemer (ISMS), der giver en systematisk tilgang til håndtering af følsom virksomhedsinformation og sikring af dens sikkerhed," forklarer han. Denne standard kan også hjælpe organisationer med at mindske risici forbundet med at bruge open source-software ved at skabe en struktureret ramme, der adresserer forskellige risici, og derved forbedre den overordnede informationssikkerhed."

Det giver særlig værdi med:

• Risikovurdering og -behandling: Herunder evaluering af risici ved at bruge open source-software, såsom sårbarheder, manglende support eller licensproblemer, og implementering af foranstaltninger til at afbøde disse risici
• Asset management: Vedligeholdelse af en fortegnelse over informationsaktiver, herunder open source-software, hjælper med at identificere og administrere softwarens sikkerhedsaspekter og sikre, at alle komponenter er opdaterede og sikre
• Adgangskontrol: For at sikre, at kun autoriseret personale kan bruge eller ændre open source-software, hvilket forhindrer uautoriserede ændringer, der kan indføre sårbarheder
• Sikkerhedspolitikker og -procedurer: Disse kan omfatte retningslinjer for brug, overvågning og opdatering af open source-software
• Leverandørforhold: Sikring af, at tredjeparts open source-softwareudbydere overholder sikkerhedsstandarder og -praksis, der stemmer overens med organisationens egne
• Patch-administration: For at sikre, at eventuelle sikkerhedssårbarheder i open source-software straks bliver identificeret og rettet
• Incident Management: En defineret proces til styring af sikkerhedshændelser, herunder opdagelse og reaktion på sårbarheder eller brud i forbindelse med open source-software, minimering af skader og hurtig genopretning
• Overholdelse af lovkrav: Standarden hjælper organisationer med at overholde juridiske, regulatoriske og kontraktlige krav, herunder overholdelse af open source-licenser og sikring af, at brugen af ​​open source-software ikke overtræder love om intellektuel ejendomsret
• Kontinuerlig forbedring: Fremme en kultur for løbende forbedringer, hvor effektiviteten af ​​sikkerhedskontroller, herunder dem, der er relateret til open source-software, regelmæssigt gennemgås og forbedres
• Uddannelse og bevidsthed: For at sikre, at medarbejderne forstår de risici, der er forbundet med open source-software og de foranstaltninger, der er på plads for at mindske disse risici

I dag er open source overalt, hvilket gør sikkerhedsforbedringer til et fælles ansvar blandt alle brugere, vedligeholdere, bidragydere og bagmænd.

"CISO'er bør fremme relationer i samfundet og deltage i samarbejdsbestræbelser for at forbedre sikkerhedspraksis på tværs af forsyningskæden," slutter Cipot. I mellemtiden kan et kulturskifte være nødvendigt i mange slutbrugerorganisationer. Open source-risici er ikke de samme som dem, der stammer fra proprietær kode. Jo før flere CISO'er accepterer og lærer at håndtere dette faktum, jo ​​bedre.