Researcher breaches Apple, Tesla, Microsoft, and others with installer hack

A security researcher found a method to hack Apple, Tesla, Microsoft, Netflix, and more than 30 other companies using an open-source software proof-of-concept exploit.

Ax Sharma for BleepingComputer:

Researcher breaches Apple, Tesla, Microsoft, and others with installer attackLast year, security researcher Alex Birsan came across an idea when working with another researcher Justin Gardner.

Gardner had shared with Birsan a manifest file, package.json, from an npm package used internally by PayPal…

Birsan soon realized, should a dependency package used by an application exist in both a public open-source repository and your private build, the public package would get priority and be pulled instead — without needing any action from the developer.

In some cases, as with PyPI packages, the researcher noticed that the package with the higher version would be prioritized regardless of wherever it was located.

Using this technique, Birsan executed a successful supply chain attack against Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp, and Uber simply by publishing public packages using the same name as the company’s internal ones…

Overall, the researcher managed to earn over $130,000 in rewards through bug bounty programs and pre-approved penetration testing arrangements… For Birsan’s disclosure, Microsoft has awarded him their highest bug bounty amount of $40,000 and released a white paper on this security issue… Apple has told BleepingComputer that Birsan will get a reward via the Apple Security Bounty program for responsibly disclosing this issue.

MacDailyNews Take: Congrats and thanks to Alex Birsan!

2 Comments

    1. Not sure it’s either. You can build a bridge that is completely safe to go over and has been stable for years, then one day a big wind comes around and creates a resonance that tears it apart. It fulfilled it’s original purpose but was found to be have a catastrophic result when a certain condition was met. It wasn’t ‘bad’ engineering under the criteria it was built, but I suppose since then can be categorized as ‘bad’ engineering given the new information. I think the current exploit falls under ‘unintended consequences’ of package selection priority. And from this point could be added to the the list of ‘bad’ engineering for future development.

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.