Vulnerabilities found in Swift repository left millions of iPhone apps exposed

Posted:
in General Discussion edited July 3

The open-source Swift and Objective-C repository, CocoaPods, had multiple vulnerabilities that left millions of iOS and macOS apps exposed to potential attacks for a decade, but it is now patched.

An iPhone with green binary code in the screen and a Swift logo
CocoaPods leave millions of iOS and macOS apps vulnerable to attack



Even though the CocoaPods repository was a potential target for so long and so many apps, there are no known exploits in iOS or macOS apps. The vulnerabilities in question were patched in October and are now being exposed in a report from EVA Information Security.

The report was detailed by Ars Technica, explaining what went wrong and how the vulnerabilities could be exploited. These issues could have led to serious problems if a bad actor managed to exploit them, and there's always a chance they were exploited without anyone knowing.

CocoaPods vulnerabilities



There were three key issues with CocoaPods, a repository for Swift and Objective-C packages. They all relate to how developers logged in to manage their so-called pods, which are code packages developers could include in their apps that were updated remotely.

When a pod manager logged in, they needed to enter the email address associated with the pod. An email with a verification link was sent that took them straight to their account page, already authenticated.

Manipulating this link could allow a bad actor to point it to a server they control (CVE-2024-38367), invade and control abandoned pods (CVE-2024-38368), or execute code on a trunk server (CVE-2024-38366). The results would lead to a bad actor being able to affect a pod that may be used in any of the millions of iOS and macOS apps that take advantage of CocoaPods.

In theory, the way this would work is a bad actor could manipulate a pod, causing it to automatically update in every app it is used in, and thus performing whatever new instruction it was given. If the pod had access to sensitive user information like passwords or credit card data, that info would now be in the bad actor's hands.

"Being able to execute arbitrary shell commands on the server gave a possible attacker the ability to read our environment variables, which could be used to write to the CocoaPods/Specs repo and read the trunk database," CocoaPods maintainer Orta Therox explained. "Being able to trick people into clicking on a link that would take them to a third-party site could be used to steal their session keys. I can't guarantee neither of these happened, and I'd rather be on the safe side."

Developers using CocoaPods prior to October have a few things they can do to ensure they are safe from attack.


  • 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.

What you need to do



The long and short of it is simple -- you're probably fine. There isn't any evidence that these vulnerabilities were ever exploited. Of course, the lack of evidence doesn't mean there isn't any evidence, so it isn't a total win.

An iPhone facedown on a surface
Keep your iPhone and apps updated to stay safe from known vulnerabilities



However, if a pod had been altered and used to gather sensitive data or infect machines in other ways, it clearly hasn't been done in a way anyone has noticed. As a user, the only thing you can do is ensure you're using trusted apps that stay up to date, and you should be monitoring your accounts for strange activity.

The issue has been patched, and the old session keys have been wiped. So, future problems with CocoaPods related to these vulnerabilities shouldn't occur.

Keep your devices and apps up to date to ensure you're always working with the latest patches and bug fixes.



Read on AppleInsider

Comments

  • Reply 1 of 3
    PemaPema Posts: 62member
    Sounds like shutting the barn door after the horse has bolted.  :s
  • Reply 2 of 3
    aptfxaptfx Posts: 8member
    Your title is very misleading. "Swift Repository" would be the Git repository of the Swift programming language. Vulnerabilities in this repository could happen too of course but thats not what actually happened here. CocoaPods is a separate entity... a package manager with packages from an undefined big number of sources... so there is much less control about what code gets in there... as with ANY other package manager too (npm...). Nearly any website and even many apps on iOS, Android, macOS and Windows are vulnerable because they in some way use tools or packages from npm. It's the obligation of the developer of an app to ensure this. That's the price you have to pay for relying on OpenSource.
    danoxJollyRoger
  • Reply 3 of 3
    Wesley HilliardWesley Hilliard Posts: 216member, administrator, moderator, editor
    aptfx said:
    Your title is very misleading. "Swift Repository" would be the Git repository of the Swift programming language. Vulnerabilities in this repository could happen too of course but thats not what actually happened here. CocoaPods is a separate entity... a package manager with packages from an undefined big number of sources... so there is much less control about what code gets in there... as with ANY other package manager too (npm...). Nearly any website and even many apps on iOS, Android, macOS and Windows are vulnerable because they in some way use tools or packages from npm. It's the obligation of the developer of an app to ensure this. That's the price you have to pay for relying on OpenSource.
    It isn't *the* Swift Repository. It is *a* repository for Swift data packages. Semantics will destroy the world.
Sign In or Register to comment.