CVE of the month, the supply chain vulnerability hidden for 10 years CVE-2024-38368

We have a big one this month and it's brand new. CVE-2024-38368 is a vulnerability that affects the open-source supply chain of iOS and MacOS applications. This one comes from the amazing research team over at EvaSec who discovered three significant vulnerabilities within the CocoaPod ecosystem. Unauthorized account ownership CVE-2024-38368,  Remote code execution CVE-2024-38366 and Account takeover CVE-2024-38367. Honestly, I could write an entire article about each of these as they are significant. But the one I chose was the unauthorized account ownership because of the massive implications combined with the simplicity of the attack. 

What does it affect exactly? 

If you are not familiar with IOS or MacOS development you will probably not be familiar with CocoaPods. CocoaPod is a dependency manager for Swift and Objective-C, essentially it is the NPM, RubyGems or PyPi equivalent of Swift and Objective-C. Over 100,000 libraries are hosted in CoCoPods which are used in over 3 million IOS applications. As of today, there are about 5 million IOS applications on the App Store so the number of applications that use CocoaPod is significant! So when asking what this vulnerability affects… It has the potential to impact huge amount of technology and a bigger number of users.

By taking ownership of a part of the iOS/macOS app supply chain, and based on the documented dependencies we mentioned above, an attacker would have free reign to access millions of mobile apps and the hundreds of millions of people that use them. EvaSec

What does the vulnerability allow? 

The EvaSec research team called this an unauthorized account ownership but in essence, it is an account takeover vulnerability. It allows a malicious actor to completely take over a ‘Pod’ or a package in specific circumstances. This would then allow the attacker to release updates to the pod adding malware so that when tools upgrade to the latest version would be pulling malware directly into their applications. In essence, this vulnerability has the potential to turn thousands (perhaps millions) of applications malicious. The blast radius is huge. 

What is the vulnerability?

The vulnerability allows account takeover for what are called 'unclaimed pods', also referred to as ‘orphaned pods’. This equates to about 2% of pods on the CocoaPod ecosystem or 1,886 pods at the time of discovery. 

To understand the vulnerability we need to go back to 2014 when CocoaPod changed account management workflows. Originally, authors of projects were identified using their GitHub profiles. In what was likely an attempt to improve security and become less reliant on GitHub CocosPod then created a new flow of identifying authors which involved creating an account directly with CocoaPod to manage the pod. During the transition, authors had to ‘claim’ their pods, if an author failed to claim their pod then this was then called an Orphaned pod. 

“In May 2014, CocoaPods announced a migration to a new 'Trunk’ server, which now acts as a centralized repository and distribution platform for CocoaPods” EvaSec

Using a simple CURL command to the publicly-available CocoaPod API the attacker could claim an orphaned pod simply by providing the target pod name.

What is the impact

This certainly has a massive impact, but the reality is that the impact is much smaller now than when vulnerability was first introduced a decade ago. The number of pods that are affected as discussed is around 2% and these are pods that while many are still being used, are not being actively maintained. But there is another, much more terrifying prospect from this, what if pods were already claimed by malicious actors? We are now entering a speculative part of the article, the ‘what if’s’, but it is important to discuss it. The vulnerability lay dormant for a decade, at any time during the last 10 years someone could have discovered this and claimed the unclaimed pods and right now, there is no way of knowing. If the recent attack with the XZ package has taught us anything it is that malicious actors will invest years into supply-chain attacks so there could be an army of malicious accounts waiting to deploy a swarm of evil pods on the iOS world. Although I will admit it does seem unlikely seeing we have not seen any attacks in the wild through this method. 

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

How can we protect ourselves

Supply vulnerabilities like this one are challenging because a lot of the supply chain is out of our control. In this case, the vulnerability only really affects packages or pods that have been unclaimed meaning if you are using well-maintained packages, you have less risk to this vulnerability. Unclaimed pods are called ‘orphaned pods’ and you should check to see if any of these are being used by your applications. 

“Special attention needs to be paid to software that relies on orphaned CocoaPod packages“ EvaSec

Additionally, you may want to consider using SCA tools to check your dependencies don’t have any known vulnerabilities.

EvaSec, the research team that found the vulnerability gave this advice. Source

• Keep your podfile.lock file synchronized with all CocoaPods developers to ensure everyone is on the same version of the packages. This will ensure that when a new, potentially harmful update is committed, developers will not automatically update to it.
• If you are using a Pod which is developed internally and only hosted in CocoaPods for mass 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 (where possible).
• Implement a thorough security review of any third party code used in your applications.
• Review CocoaPods dependencies and verify you are not using an orphaned Pod.
• Ensure you 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. 
• Be wary of very widely used dependencies as these could be a more attractive target for potential attackers to exploit. CocoaPods is only the beginning…

Authors additional thoughts

It is an interesting case this one, CocoaPods was likely trying to be more secure in their move away from GitHub, this reliance on the source management giant has led to some very weird security flaws in other package managers. PyPi and NPM, for example, pull the popularity of a project over from GitHub (in the form of stars) when the project is created, this actually allows someone to link an unrelated GitHub project to a malicious package to give the illusion of popularity and legitimacy. I completely agree with the decision to move away from GitHub to be able to enforce your own security controls and while we can agree on the massive security issue with how they did it, what I believe ultimately went wrong was that this feature was long forgotten showing how unmanaged features can become a massive security flaw in your organization. It also is a stark reminder of how open-source security remains one of the most important security challenges we face, this year, it isn’t just the packages themselves we need to be concerned with it is also the managers of the packages (which are also open-source).