The CocoaPods Saga: Has Open Source Broken Apple’s Security Model?

Open-source dependencies have become a growing source of risk for organisations of all shapes and sizes. Log4j, xz Utils and other high-profile stories have highlighted systematic weaknesses in the ecosystem, which threat actors are increasingly capable of exploiting. But few suspected Apple would ever be impacted. After all, this is the vendor that heavily vets any applications allowed on its App Store. Well, that was until July 1, when security researchers dropped another open-source bombshell: critical new vulnerabilities in a popular dependency manager used in over three million macOS and iOS applications.

The bugs have been remediated, but no one knows if they have already been exploited in covert supply chain attacks. This begs an increasingly common question: How do we solve a problem like open-source?

What Happened?

The vulnerabilities were found in CocoaPods, a repository for open-source Swift and Objective-C projects that millions of Apple apps depend on. It features over 100,000 external libraries (or ‘pods’), which some of the world’s most popular apps use – including Airbnb, Instagram and Uber. According to EVA Information Security, the vulnerabilities are as follows:

CVE-2024-38368: A design flaw in the CocoaPods server allows any user to claim a pod that doesn’t have an identified owner without any verification needed. There are thousands of these ownerless pods today. According to Endor Labs, this means that a threat actor could have registered a CocoaPods account, claimed a pod, and begun distributing malware as if they were a trusted maintainer. It has a CVSS score of 9.3.

CVE-2024-38367: The CocoaPods server trusts a request header it shouldn’t, enabling an attacker to subvert the email validation workflow for preventing account takeovers. This could have led to threat actors hijacking existing user accounts and replacing the associated pods with malicious or compromised versions. It has a CVSS score of 8.2.

CVE-2024-38366: Stems from a vulnerability in a Ruby gem dubbed “rfc-822”, which is an open-source library the CocoaPods server software depends on to validate email addresses. Threat actors could have exploited it to achieve remote code execution on the Trunk server. It has a CVSS score of 10.0.

What Happens Next?

The good news is that the bugs were fixed last October. But question marks remain over whether they may have been exploited over the past decade, given the number of pods exposed and the length of time they were exposed for (10+ years). If they had, the complexity of the software supply chain would have given the threat actor(s) plenty of cover.

“While there is no direct evidence of any of these vulnerabilities being exploited in the wild, evidence of absence is not absence of evidence,” warns EVA.

That’s why the vendor is recommending any impacted developers (those using CocoaPods before October 2023) to secure their code through the following steps:

• Keep “podfile.lock” files synchronised with all CocoaPods developers so everyone is on the same version of the packages. It means that if a new harmful update is committed, developers won’t automatically update to it.
• For pods developed internally and only hosted in CocoaPods for distribution, developers should perform CRC (checksum) validation against the one downloaded from the CocoaPods trunk server to ensure it’s the same as the one developed internally.
• Implement a thorough security review of any third-party code used in applications
• .Review CocoaPods dependencies and verify you are not using an orphaned pod.
• Only use third-party dependencies that are actively maintained and whose ownership is clear.
• Perform periodic security code scans to detect secrets and malicious code on all external libraries, especially CocoaPods.

The Bigger Picture

Developers continue to rely on open-source components because they’re a quick, cost-effective, and easy way to shorten development times. But the risks are becoming too great to ignore. According to ISMS.online’s State of Information Security Report 2024, three-quarters (75%) of organisations have been impacted by a security incident caused by a third-party vendor or supplier. And nearly half (45%) suffered multiple incidents over the past year.

“Open source software, being publicly accessible, can contain undiscovered or unpatched vulnerabilities that malicious actors might exploit. This is compounded by the lack of dedicated support in many open source projects, making it challenging to get timely assistance or updates when issues arise,” argues Rich Hildyard, software product and delivery lead at mobile security specialist MOBSTR.

“Another significant risk is related to licensing. Non-compliance with open source licenses can lead to legal complications, especially when licenses have specific requirements that must be adhered to.”

Hildyard also warns of projects that may become abandoned by their maintainers.

“When this happens, users are left without essential updates or fixes, which can jeopardise the stability and security of their systems,” he tells ISMS.online. “Compatibility issues also pose a threat, as updates in open source dependencies can sometimes introduce changes or conflicts with other software components, disrupting the overall functionality.”

Boris Cipot, senior security engineer at the Synopsys Software Integrity Group, argues that the complexity and sheer volume of direct and transitive dependencies make it challenging for CISOs to manage and track vulnerabilities that impact multiple projects. Even if they can, patching may be delayed due to compatibility concerns and/or testing requirements, he tells ISMS.online.

Mitigating Open Source Risk With ISO 27001

However, mitigating the risk of another Log4Shell or CocoaPods is possible. He argues that continuously monitoring open-source components, including by Software Composition Analysis (SCA) tools, to identify and manage open-source components and their dependencies automatically will help. Cipot also advocates security teams follow ISO 27001.

“ISO/IEC 27001 is an international standard for information security management systems (ISMS) that provides a systematic approach to managing sensitive company information and ensuring its security,” he explains. This standard can also help organisations mitigate risks associated with using open-source software by creating a structured framework that addresses various risks, thereby enhancing overall information security.”

It provides particular value with:

• Risk assessment and treatment: Including evaluating the risks of using open-source software, such as vulnerabilities, lack of support, or licensing issues, and implementing measures to mitigate these risks
• Asset management: Maintaining an inventory of information assets, including open-source software, helps with identifying and managing the software’s security aspects, ensuring all components are up-to-date and secure
• Access control: To ensure only authorised personnel can use or modify open-source software, preventing unauthorised changes that could introduce vulnerabilities
• Security policies and procedures: These can include guidelines for the use, monitoring, and updating of open-source software
• Supplier relationships: Ensuring that third-party open-source software providers adhere to security standards and practices that align with the organisation’s own
• Patch management: To ensure any security vulnerabilities in open-source software are promptly identified and addressed
• Incident Management: A defined process for managing security incidents, including detecting and responding to vulnerabilities or breaches associated with open-source software, minimising damage, and recovering quickly
• Compliance with legal requirements: The standard helps organisations comply with legal, regulatory, and contractual requirements, including adhering to open-source licenses and ensuring the use of open-source software does not violate intellectual property laws
• Continuous improvement: Promoting a culture of continuous improvement, where the effectiveness of security controls, including those related to open-source software, is regularly reviewed and improved upon
• Training and awareness: To ensure that employees understand the risks associated with open-source software and the measures in place to mitigate those risks

Today, open-source is everywhere, making security improvements a shared responsibility among all users, maintainers, contributors, and backers.

“CISOs should foster relationships within the community and participate in collaborative efforts to improve security practices across the supply chain,” concludes Cipot. In the meantime, a culture shift may be necessary in many end-user organisations. Open-source risks are not the same as those stemming from proprietary code. The sooner more CISOs accept and learn to manage that fact, the better.