 Tom here from Orange Systems, and I was a skeptic when I seen this headline right here. Dependency, confusion, how I hacked into Apple, Microsoft, and dozens of other companies. That includes Shopify and PayPal. And I was a skeptic at first, but this was a really interesting supply chain attack pulled off by a security researcher. Legitimately pulled off and also with authorization. That's an important distinction and this write-up is very detailed. We're just going to cover the basics of what happened here because wow, is it interesting after I read through it twice to try to gain a better understanding of what was going on. Now, this is a supply chain attack. It's a software supply chain attack because the idea is if you can get into the supply chain, then the distribution models of that software will allow you to get whatever you wanted out there, out there at scale. And hopefully no one will notice. This is the same type of attack that happened with the SolarWinds, different methodology. But this is what happened in December of 2020 when we discovered the SolarWinds attack. It's a software supply chain attack. And as we know now, those are definitely something that, well, it happens at scale and it can be very, very scary and very, very hard to find. And that's where this security researcher went. And it starts with this idea right here of the way software is built with dependencies and the leak that occurs with some companies when they're building that they leak what those dependencies are. So when you're building software, you have two pieces. You have your external dependencies and then your internal dependencies. And you glue them all together. The external dependencies are essentially so you don't have to rewrite and reinvent everything every time you want to build a new product. There are common libraries out there to do common tasks. They're well vetted, they're well documented, especially when it comes to things like cryptography. You want a package that is well good and well put together versus trying to write your own crypto. This is where a lot of companies do try to get in trouble is without going to external dependencies, they try to write everything from top to bottom themselves that takes a very big team, a very talented team. And it can sometimes lead to problems. So the more common process is to rely on these external dependencies. And that's not exactly a bad thing because now they're using common libraries, like I said, that it can be well audited and well vetted. But there is, of course, the time when it pulls internal dependencies. And if that information gets leaked out, such as in your package.json file, and through a series of interesting steps, this security situation was able to find the dependencies many companies have, you're able to look up what is being asked for. And we have files like pplogger, auth-paypal, wrfl-paypal, analytics-paypal. These are not public facing pieces of dependencies that are out there. This is actually internal ones. So where this attack actually occurs is at the build server level. And once you know what it's calling for and it's looking for it, what if, what if you took and registered those names in the public registry of things? And that's exactly what this person did. What happens if malicious code is uploaded to NPM under these names? Is it possible that some of PayPal's internal projects will start defaulting to the new public packages and some of the private ones? Will developers or even automated systems start running the code inside these libraries? If this works, can we get a bug bounty off of it? Would this attack work against other companies too? Dancers, yes, worked off quite a few companies. And skipping down towards the results, and I'll leave a link so you can read all the details. This is essentially what they came up with here. The system checks if the library exists on the specified internal package index. The system checks whether the library exists on the public package index. And it installs whichever version is found. If the package exists on both, it defaults to installing the one with the higher version number. So in short, what you have to do to make this happen is create a version number higher than the one that they have. And this was found at quite a few companies that they would simply accept this. And he come up with a few different clever ways to prove that he got into the servers because he's not actually getting remote access to them. Just pulling these public code, grabbing it down and matching it essentially. So if we know that we have this PayPal dash off file, we created a public version of it. And now it can see both and it wants to pull from the PayPal off internal. But then it finds out there's a newer one available on the internet. Well, we want to use that newer one because that's what the build server defaults to. Now, the good news is this was paid out as bug bounties from a lot of different companies. And that was wonderful. They are a little bit less than clear what they did to mitigate or fix this because this is kind of their internal secret sauce of how they actually build software. My guess is be they just removing any external dependency for certain packages and probably creating some locks that, well, stop these packages from existing anymore or being able to be pulled anymore from any external sources. So they're probably just doing a lot of implicit stuff that should have been done a long time ago. It's exciting to see that a lot of money was paid out for these. Some of the bug bounties rewarded from each of these companies was 30,000, which they may have even awarded more. But I think there's some maximums that they have set for how much they'll reward for each bug found. So this bug was repeated off several different companies. Shopify, Microsoft even had one and PayPal and lots of companies, of course, leak what their build data is. And that's download detailed out in here and is able to get copies of companies list of dependencies, which offers up the opportunity to go register more names, even companies that may not have participated in bug bounties. What this also means is there could be someone exploiting this or has been exploiting this. And I'm hoping that this information really gets out there to people doing development. Now, obviously, going after big names is big headline and very important because of the scale and scope at which these companies operate. But there's going to be a ton of smaller projects and smaller developers that I'm hoping change the ways they're doing this because they could already have this problem. This problem could have already been exploited on them. And we wouldn't really know they're not big enough to even offer that kind of bug bounty program yet. But this is one of those things we're going to have to keep watching in the software ecosystem as things get developed. Honestly, it's going to come down to a much stronger build process, much more scrutiny of where those dependencies live, which versions you're pulling from. And if you do have your own internal dependencies that they probably should never exist or should never be pulled. If you know that PayPal dash off should only ever be internal. There should be no way to ever have your build server pull that externally. And I'm sure that's the type of mitigations lots of these companies are doing right now. But I just thought this was a great read a great write up and just some fun security research that is complicated to get to this conclusion. But boy, the execution of it a little bit more simple, the fact that these systems are able to pull from this. And raising awareness is how we get further. And we're going to just keep locking things down that much more in the years to come. All right, thanks. And thank you for making it to the end of this video. If you enjoyed this content, please give it a thumbs up. If you'd like to see more content from this channel, hit the subscribe button and the bell icon. To hire a share project, head over to LawrenceSystems.com and click on the hires button right at the top. To help this channel out in other ways, there's a join button here for YouTube and a Patreon page where your support is greatly appreciated. For deals, discounts and offers, check out our affiliate links in the descriptions of all of our videos, including a link to our shirt store, where we have a wide variety of shirts and new designs come out well randomly. So check back frequently. And finally, our forums, forums.laurancesystems.com is where you can have a more in-depth discussion about this video and other tech topics covered on this channel. Thank you again, and we look forward to hearing from you. In the meantime, check out some of our other videos.