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

[hh-hunter]

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.

• Restrict LDAP access via JNDI apache/logging-log4j2#608
• https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1
• https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3201?filter=allissues

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

[magl0]

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]

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]

@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]

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]

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]

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]

@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.