>We recently came across a suspicious NPM package called `buildrunner-dev`. The package is deceptively simple, containing a package.json with a postinstall hook pointed at an `init.js` file, but that’s where things got interesting.
>The postinstall script was triggered upon package installation and dropped a batch file called `packageloader.bat`. At first glance it looked like pure noise due to thousands of characters that appear to be gibberish; nature-themed REM comments, and variable names that read like a cat walked across someone’s keyboard. But as we started peeling back layer after layer of obfuscation, we uncovered a remarkably well-engineered attack chain that hides its true payloads inside the RGB pixel values of PNG images hosted on a free image service.
Matthew Remacle (Remy) digs into the newly disclosed Apache Struts2 CVE-2023-50164 file upload vulnerability. This weakness allows an attacker to drop a web shell that can be called remotely through a public interface over defined routes.
Apache Struts2 is an open-source Java web application development framework used in various enterprise-grade applications and business use cases.
The vulnerability occurs when a multipart form request is used, and the constraints for path normalization are bypassed.
The attacker can inject a web shell (e.g., shell.jsp) into the file system, which can then be remotely called.
The exploitation of this vulnerability depends on the specific implementation of Apache Struts2 in a vendor's product and the defined actions' path.
Check out Bugcrowd.com - we can manage the whole thing for you and we can even give your dev team remediation advice/information so that they can fix it.
We've been doing this stuff for several years, so we'll be able to help you get everything setup and ready to go no problem :)
There are a ton of different directions that you can head in and focus on. I encourage you to start/look at stuff that you're genuinely interested in and excited about.
Right but the cost differential between staffing it yourself and paying someone else to do it is substantial. Doing it yourself will cost you 3-5x more than paying someone else who is able to do it at scale.
(Disclosure: I work for Bugcrowd) That's why we suggest going with a 'managed' bounty. That's where Bugcrowd triages all of the incoming bugs and then passes along the valid bugs for you to prioritize and reward. It cuts out all of the noise and only gives you the results.
Agreed with others that it's worth considering a small private program. You can do time boxed bounties with a capped cost, that way you're getting results without committing to a huge budget. Check out Bugcrowd's "on demand" bounty: https://bugcrowd.com/solutions
New programs are launching all the time or the scope of current programs is expanding out to include new products or features. It's never too late to get started, there's actually more work than researchers at the moment and it will be like that for many, many years to come.
In terms of how to get started, I definitely suggest monitoring the various bug bounty sites to see what's new and if a bounty's scope has expanded.
Yeah,running a public program and are handling a lot of submissions (pretty typical), handling the volume of bugs and evaluating them quickly can be quite tricky. Not only is it important for the company because you want to make sure you're aware of what's out there, but you also want to make sure the security researchers have a great experience.
>The postinstall script was triggered upon package installation and dropped a batch file called `packageloader.bat`. At first glance it looked like pure noise due to thousands of characters that appear to be gibberish; nature-themed REM comments, and variable names that read like a cat walked across someone’s keyboard. But as we started peeling back layer after layer of obfuscation, we uncovered a remarkably well-engineered attack chain that hides its true payloads inside the RGB pixel values of PNG images hosted on a free image service.