google/tsunami-security-scanner-plugins

PRP: Request CVE-2021-44228 Apache Log4j2 <=2.14.1 JNDI RCE

hh-hunter opened this issue · 7 comments

hh-hunter commented

Hello,
I would like to start the implementation for a plugin that detects Apache Log4j2 RCE vulnerability,
The vulnerability should be relatively new and it is a serious problem.
Apache log4j2 is affected from 2.0 to 2.14.1.
The vulnerability has been fixed, but there is no CVE number yet.

Please let me know if this is in scope to start with its development.

magl0 commented

Hi @hh-hunter ,

Thanks for your request! This vulnerability is in scope for the reward program. Please submit our participation form and you can start working on the development.

Thanks!

magl0 commented

Hi @hh-hunter, we'll prioritize this detector over the other accepted PR from you so that this freshly release vuln gets supported by our scanner.

hh-hunter commented

@magl0
This vulnerability may require a crawler to cooperate, is there a crawler function currently? For specific applications, I think you can accept #220 first, by the way, can I develop this vulnerability check plugin now, or do I need to wait for #216 to complete Continue after MR?

hh-hunter commented

This loophole requires parameters, and if it is covered by a crawler, a lot of it may be missed. But if the utilization check of a specific application is completed first, the crawler can only be used as an aid.

magl0 commented

There is a crawler in the fingerprinting plugin, which is not for general use yet. I haven't checked the full details of the vulnerability, so may I know the detection logic you'll be implementing and how the crawler helps in detection?

You don't need to wait for #216 to finish, the scanner team will prioritize this issue first then move on with #216.

hh-hunter commented

hi @magl0 ,If I use crawling techniques to achieve this, then I need to crawl all get and post links for request information, including parameters, and then replace the values in the parameters with payload, and then use a third-party OOB interactive collection server, such as app.interactsh.com/#, for tsunami-scanner's current s progress, the miss rate is probably greater. So I would prefer to complete #220 first (this vulnerability is generally too large a coverage to check, and should know that many applications are or have developed their own systems using Log4j, but not limited to a particular portal), which do you have a better suggestion for?

This vulnerability is triggered, again, by using methods like logger.info in the app, which also logs the request when it causes the trigger.

hh-hunter commented

@magl0 About the previous plug-in submission bonus some questions, I currently received two approved and given bonus plug-in email, but when I logged in https://bughunters.google.com/, I can only see a gitlab plug-in information, an earlier submitted nacos plug-in did not see, there is an email convenient to communicate this? I haven't received any payment information yet.