Important: "laravel-lang" Attack and Composer Security Tips

Hello guys, we need to talk about security for Laravel projects but on a totally different new level. This is important video. On Saturday, I woke up to this tweet, the attack on Laravel Lang, a few packages, but I think many developers would underestimate and don't understand how serious it is. So, this video will have two parts. First, I will explain what actually happened and why it is so serious for any Laravel or PHP developer. doesn't matter if you use that package because similar things may happen and probably will happen with other packages unfortunately in the AI attack era. So that will be the first part the explanation and then the second part I will give practical tips what to do with composer packages to be on the safe side. So from that Saturday morning I worked on weekend to prepare you the summarized version and this video will be about composer packages but also I quickly published a textbased course 43 minutes read about deeper things not only composer but about how to secure your keys and how to rotate them how to protect your local machine your computer and in a minute you will find out why you need that and then the checklist what to do if you're actually affected by similar breach so That 43minut textbased course is for premium members on Laravel Daily. And by the way, that 43 minutes is already packed and shortened to like the main things that you need to know. But in this video, I will focus on composer things. So when running composer update or before running composer update, what do you need to know? The first thing you need to understand is the seriousness of the situation. That would be already a step forward. So when we were talking about Laravel security from the early days of Laravel, we were mostly emphasizing SQL injection XSS vulnerabilities. So someone would put malicious parameters or JavaScript somewhere on your page and then execute malicious code when that page is executed. So yeah, in comparison, this thing is much worse and much more impactful. Let me show you. Here's the report by Iikido Security and I will emphasize some parts of that. So those packages were attacked in a very sneaky way. So the repository seemed clean. There were no new versions or new code in the main branch. It was done via git tags on forks. So many developers wouldn't even notice anything suspicious and just run composer update as usual. And then this was the main problem that payload runs at autoload time. What does it mean? If you take a look at any default Laravel project, there's public index.php which contains this line and on the autoload of that malicious package version malicious tag. That's when the malware was executed which means you wouldn't even have to use any functions of that package of Laravel lang any loading of the website any artisan command any Q job they all go through public index which all go through this and then executes the malware and again many developers wouldn't even notice because of course there's no notification there's no red page of attack or something it just silently executes in other words what you need to understand that this is not about specific package of Laravel lang and this is not a GitHub vulnerability or security breach on GitHub side. This is kind of a legitimate way to put something into the package which developers would download via regular composer update. For that to be executed the attacker should have had of course some access to GitHub repositories of the vendor of the Laravel maintainer. So probably something was compromised some GitHub token or key or something like that on developer machine or somewhere in their environment which gave the attacker access to push get tags. So that's the underlying kind of entry point which is unclear at this point but this is another kind of reminder for us to protect our systems because through our systems malicious things could be spread via GitHub to basically anywhere. Next we can take a look at what this malicious script actually did but so you would understand it could do anything. So basically someone puts some PHP script inside of that composer updated repository and then the code is executed. In this case the code was kind of two parts. First it downloaded a specific another script the stealer and then the stealer went allin searching your environment for whatever keys it could find. And this is the most dangerous part. So this is not about executing malicious code on your server for your website. It's not about dropping your production database or something like that. It's about this list or this is the list for this specific case. But it could be different. Basically, it was trying to get all the credentials, all secret keys, whatever it could find on your machine or on the machine where composer update was executed. So see that list the script was trying to get not only credentials fromv files from Laravel that's alone a huge thing but also private keys SSH credentials to external systems. So the damage with those keys could be huge. So this is one of the messages of this video. Do you realize how serious it is? I will repeat it's not about Laravel package or your Laravel website or your production database. It's about stealing credentials from anywhere where that script could find them. Luckily, the attack was stopped by Iikido Security quite quickly. They reported that to packages which removed all the versions and unlisted the package itself and of course they reported to the maintainer as well. So you would be affected if you run composer update during that window of when those tags were active. So this is the new reality. Before running composer update, you need to doublech checkck and triple think all the dependencies that you have in your project. In theory, technically any of them could be compromised. In fact, this was the reality all the time. But just with AI, the amount of attacks and their sophistication is on the next level. So someone for example could break into a computer of an employee of a company who releases packages and then the whole Pandora box can be opened. So yeah, I don't want to scare you too much, but I kind of hope I did a little. So I hope you do get my attention for what I will talk about next, what you can do about it. So let's talk about kind of best practices to be on the safe side. How to run things with composer to avoid or minimize the risk of things to happen. Number one is composer.log should be pushed to the repository all the time. It should not be get ignored because composer log contains specific versions that need to be in the project because usually what happens all the other environments production testing and other developer computers to install the latest version they run composer install not composer update. So for example this is the deployment script on Laravel forge on one of my demo project and you see this composer install which means that after new changes locally every developer pushes the changes with new packages version to GitHub. So locally developer runs composer update then the new version of composer log is generated and that composer log is pushed to the server and then everyone else gets the versions from composer lock. But if composer log doesn't exist, if it's get ignored or for whatever other reason, then composer install will trigger automatically composer update or in other words, it would reinstall all the packages with their latest versions according to composer JSON constraints which may include malicious tags or malicious versions. So all that long explanation just for you to understand that composer log is needed in the repository. Next thing, how to run composer update. If you want to upgrade some versions of some packages, quite often we were kind of lazy and we were running composer update just to update everything to latest versions just to be the cool guys and stay protected from all the security updates which kind of meant the latest versions of all the packages. But I would say this is not safe anymore. So if you run composer update, it will update all the packages in your composer JSON. In my case, I just installed that project. So, nothing was updated. But basically, it would go to your require and update the dependencies and the dependencies of the dependencies, which means that the malicious code could be in the dependency of second or third level. So, that's why for example, if you see something on the news that something is happening with some package and you have specific versions, you need to install or update specific package with specific version. So for example, you could run composer update Laravel framework something like that and then it would try to update only Laravel framework or even better to have specific versions in composer JSON. So instead of these you could be locking that to 13.8.0 for example. I'm not sure what is the latest one but you could then increase the version here in composer JSON and then run composer update. I know it's a bit inconvenient and more work, but I mean, we're talking about security here, right? Extra security always requires a little bit more work to be on the safe side, but as usual, everyone should choose their level of paranoia, so to speak, or the risk depending on the project and of course depending on the packages. Next, before running any composer operation with composer update, you could run composer audit, which looks for vulnerabilities. In this case, for new project, nothing was found. But here's composer audit on my older project. It was a demo project roughly a year ago. Look what happens. So it reports all the known security issues that were in some versions of some packages like in this case symfony until version 8.0.12. Also what else do we have here? Symfony process symfony mime mailer. So symfony which was patched by the way quite recently and this is the reported date. So it was quite a long time ago but then we have more league common mark in March we have filament again in March and it was fixed at the time but yeah the thing is that this demo project still contains some of those versions and that's why composer audit would flag all the vulnerabilities in those versions that you have. So from that point of view, you do need to run composer update. Just make sure which version do you update to. But probably the most fundamental thing that you could do with composer packages is ask yourself, do I really need that external package every time you install something new or update to newer version? So in my tweet recently, I emphasized this. Consider not using packages when it's not necessary. So if I open random composer JSON from random open source project this is composer require and some of those packages may be small for a specific feature or specific convenience like HTML to markdown is pretty small like Laravel actions potentially could be replaced with just Laravel well action classes PHP classes and don't get me wrong I'm not saying that those packages are bad or malicious or whatever but you need to lower the possibility of damage. So ask yourself two questions before installing any package. First question, is there any specific function or class from that package that you specifically want to use? For example, HTML to markdown may be just one function of converting which may be one class of that package. So could you just copy the code of that class with a few related helpers into local service to do the same thing? And yes, again, I know it's extra work and I know it's not convenient and I know you will not get new versions when the package releases new versions, but for some cases, you just need that part of the big package. And if it's a bigger package, another question, could you ask your AI agent to reproduce again specific part of the package which may be too big for you to just copy paste, but AI agents could reproduce the same things. I've tried multiple times and AI agents are very good at going to vendor or even to GitHub readme analyzing the patterns and extracting the things. So by avoiding extra external dependency you lower the potential risk and damage and also on top of that you will have fewer problems when new Laravel version is released or new PHP version or something like that. you would have all the code controlled in your repository and for whatever update you would be able to update it yourself without waiting for the author to release a new version of the package. So that's kind of a side benefit because I know every Laravel version update is not about Laravel update. It's about update for all the packages, all the dependencies which may take months. Some packages may be abandoned. So it's a whole separate story. Not even about security but about convenience. So yeah, question every package dependency. Do you need that? And do you trust the vendor? If it's a first-party package, Laravel something, of course, it should be on the safe side. But even then you don't know what is inside of Symfony for example because Laravel depends on some Symfony classes and Symfony packages. So basically whenever you run composer update or composer requires something new you install not just for example Laravel Fortify but all the dependencies of Laravel Fortify. So if we take a look at Laravel Fortify and open composer JSON of Fortify what do we have here? Illuminate and Laravel are first party so it should be safe but then we have this one and that one for QR code and Google two-factor authentication. So with composer update those would be updated as well with all the consequences. And the final kind of weird tip about composer before running any composer update check Twitter. I'm kind of half joking but also pretty serious. Whenever I launch Twitter homepage, if something is actively happening in Laravel world or in web world, it will be on the top of first tweets. And if it isn't, you can search for security and see things like this. So, Twitter algorithm or probably just general audience with likes and retweets puts these things on top with thousands of likes including that Laravel Lang story and others including tweets by Fabian, founder of Symphony. So yeah, just double check on social media. Twitter is probably the fastest to report those, but maybe you have some other alternatives. Just check if there's nothing actively happening around your text tag and framework and packages. So yeah, these were most probably practical tips about composer and how to handle dependencies. But of course, there's more. There's things like require dev. There's things like CI/CD and composer inside of that. There's also a question about the user that you're running composer with. So is it root or not? Does it have permissions? And this is where I go a bit deeper in that course that I mentioned in the beginning. So 43 minutes read and this is already shortened from like a few hours that were planned. And this is the table of contents. So in addition to composer habits, I talk about how to rotate and what to rotate in terms of secret and keys and passwords. Then how to secure your local machine and environment and basically what to do if you know that you're attacked and you're affected. There's a emergency response checklist I called it and also how to check if you're affected if you know that this package or that package is harmful now and you use that package but did you have the malicious code inside? So how to check and what to do also in that course. So I will link the full course in the description below for premium members of Laraveville Daily. I was trying to put it out as early as possible after that big breach so you would get prepared for what's unfortunately I think to come in the future with general packages PHP Laravel and others. So stay on the safe side, be prepared, know what to do if something goes wrong and if you have any questions of course let's discuss in the comments below. That's it for this time and see you guys in other videos.