hi,

here's a feature wish: would be great to have a collection of environment variables which get scrapped by attackers like it's partly done here: https://twitter.com/Laughing_Mantis/status/1469789508535087104?s=20

there will probably be more juicy targets and it helps to know where the great reset has to be done after patching.

regards
arnim

https://www.arubanetworks.com/website/techdocs/sdwan/docs/advisories/media/security_advisory_notice_apache_log4j2_cve_2021_44228.pdf

Add Awingu to the list (https://www.awingu.com/)

Awingu update on CVE-2021-44228 (Log4j) today:

We are reaching out in light of the recent disclosure of CVE-2021-44228. This vulnerability impacts Apache Log4j 2 which is a Java logging library developed by the Apache Foundation. Awingu makes use of Java, including Log4j.

Our teams have been working on and investigating the vulnerability since it was identified last week.

Here is the status:
• A maintenance release (5.2.4) will be issued in the 2nd half of this week which will fix the possible vulnerability. We recommend all our customers and partners to upgrade to this last version once available. In the meanwhile we recommend everyone to already upgrade their platform to the latest version (Awingu 5.2.3).
• Our experts are investigating the risk and exploit for Awingu specifically. At this point, the risk and impact is assessed to be low.

More information will be made available via the Awingu support portal (available via https://my.awingu.com).

Zabbix Monitoring has posted that the software is not affected by the exploit.

https://blog.zabbix.com/zabbix-not-affected-by-the-log4j-exploit/17873/

There seems to be some misleading information when combining version and status field, e.g.

That could be interpreted at any log4j < 2.15.0 if fixed which is wrong...

https://kb.vmware.com/s/article/87068?lang=en_US

Add items from this pull request which contain more scanning tools:
#18

@pbeij I added the following items. It was in the pull request not in the comments. See PR 18.

Can you still add the following tools?

| Northwave Log4j checker | Scans specified url with a `GET` with payload in url or *User Agent* | [source](https://github.com/NorthwaveSecurity/log4jcheck) |
| log4jcheck | Scans a list of URLs with `GET` or `POST` request in combination with user defined parameters | [source](https://github.com/OlafHaalstra/log4jcheck) |
| log4j_rce_check | Scans specified host with payload in the *User Agent* | [source](https://gist.github.com/byt3bl33d3r/46661bc206d323e6770907d259e009b6) |
| Canary Tokens | Amongst other a Log4Shell JNDI string with URL can be generated for which the DNS queries are logged and presented in an overview with caller information. | [source](https://canarytokens.org/generate) |

NetApp PowerShell Toolkit contains log4net.dll in the Modules\DataONTAP directory.

Hello,
Thanks for this comprehensive list,

Please correct the entries for Check Point Software Technologies, currently listed as Checkpoint, which is a different company, as either Check Point or Check Point Software Technologies.
This will make it easier for actual Check Point customers to easily check your information.

Thanks
Eric
aka ericb(at)checkpoint(dot)com

Script to find & fix:

#!/bin/bash
TIMESPTAMP=$(date "+%Y.%m.%d-%H.%M.%S")
echo "Running CVE-2021-44228 mitigation on $(pwd)"
echo "WSO2 Log4j 2 Zero-day mitigation script (CVE-2021-44228)" | tee -a "log4j_mitigation_$TIMESPTAMP.log"
JAR_FILES=$(find . -name '*.jar')
for JAR_FILE in $JAR_FILES
do
echo "[-] Checking: $JAR_FILE" >> "log4j_mitigation_$TIMESPTAMP.log"
CONTAINS_JNDI_LOOKUP=$(unzip -l "$JAR_FILE" | grep "org/apache/logging/log4j/core/lookup/JndiLookup.class")
if [ -n "$CONTAINS_JNDI_LOOKUP" ]; then
echo "Found org/apache/logging/log4j/core/lookup/JndiLookup in: $JAR_FILE" >> "log4j_mitigation_$TIMESPTAMP.log"
echo "Removing org/apache/logging/log4j/core/lookup/JndiLookup from $JAR_FILE" | tee -a "log4j_mitigation_$TIMESPTAMP.log"
zip -d "$JAR_FILE" org/apache/logging/log4j/core/lookup/JndiLookup.class >> "log4j_mitigation_$TIMESPTAMP.log" 2>&1
fi
done

Qnap has released a statement that they are currently investigating QTS and QuTS Hero
https://www.qnap.com/en-uk/security-advisory/qsa-21-58

Just spoted te request for a PR.
I will try to create one.

Chef Infra Server is in this list due to an issue I opened to track the log4j issue. We depend on Elasticsearch and at the time Elastic had not determined if ES was vulnerable or not. They have since published a statement that Elasticsearch is not vulnerable. Chef Infra Server is not vulnerable and should be listed here..

Tim Smith
Product Manager - Chef Infra Server

I found that SmartSVN and SmartGit are linking Log4j:

Not checked if vulnerability is exploitable within SmartSVN and SmartGit.
Not contacted Syntevo right now.

Product links:

• https://www.smartsvn.com/
• https://www.syntevo.com/smartgit/

Please file a PR instead of an issue if you can. See https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files#editing-files-in-another-users-repository. Thanks for your contribution!

Below a screenshot of their statement in the support portal which is behind a login

Hi there,

Dont have time right now for a pull request, but it seems that there are a lot of good sources here (including this github repo):

https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/

Rapid7 has released an authenticated vulnerability check with identifier apache-log4j-core-cve-2021-44228 via a content update on December 12, 2021. The check uses the find command on Unix-like systems to identify vulnerable versions of the Log4j JAR files. This new check requires the Security Console and Scan Engine to be updated to version 6.6.118 and restarted.

Dell has published a list of vulnerable products at the following page:

https://www.dell.com/support/kbdoc/nl-nl/printview/000194414/30/en

Hopefully this can be used to update the list of affected products.

A vulnerability has been reported on 10 December 2021 in the Java logging library (log4j). Log4j-core versions between 2.0 and 2.14.1 are subject to a remote code execution system exploit via the ldap JNDI parser.

The system exploit has been reported with CVE-2021-44228 against the log4j-core jar and has been fixed in Log4J v2.15.0.

Teams across Ivanti mobilized against this threat upon learning of it. After a thorough review of all our products we have found that this vulnerability impacts the following MobileIron products:

MobileIron Core
MobileIron Sentry
Core Connector
Reporting Database (RDB)

MobileIron Cloud is not impacted by the vulnerability.

We strongly recommend that you immediately apply the mitigations outlined in this Knowledge Base article to protect your environment. Please follow the article to receive notification of further updates. You can also find Ivanti’s full impact assessment in this Knowledge Base article.

The mitigations will not have any impact on product or logging functionality. The workaround needs to be applied in a maintenance window. You will not be able to access the admin portal during the procedure, however, end user devices will continue to function.

If you have any questions, please log a case with Support via this LINK.

Thank you,

Your Ivanti Team

Links achter inlogscherm:
http://gslinki.ivanti.com/ls/click?upn=0R6QHCxgSZb4Tenj5dFRzSTwTT5Q3SUzX-2FAr2byGHLh-2BJkeRUmHPArGa-2FFUb1EQqYkhI1EjoLczzrmX7IfgTnOC4kYhnUH1LyhfNz6cTaXpl0a-2BUkxTdXa-2B9M3-2FIiX-2B6JQJxuzl5C-2Bg9M4Ok791rTQ-3D-3Dm7PE_MPaZZwqO9vZyR2b-2BPyntnUc5xTyqOQZKTxBtgRxh9q-2BXyK5nfQ2kpzHukTdbMqfoni1584gvJIAlaWfczd19drsNvfvGgv7-2FOsJWXT2l1yTeGVAufrBhx4PzyRPO8tqaOxxLofkbHEaKxrTgzffQ2UDXYujXU0vxYd-2F-2FC22DmZZ3A-2BYhrf5wnp4VQw8gChjiExXQetRpaVBclMQ7T7Nk4BcXNou3ikhTznIn3-2BaGl5VfMD-2FEm-2BgX4je4JJNZrtKHRbAR0KP0wVsLuhkAe-2BrfkqSGQxua2G2xLJVH2e28Lwl6iHXCRyH9NXcwLlvxPJv2OsH92Pgjfin-2FBNXwFY6dnreqH5-2Bjaw9wG1c6d1-2BHdinyyQeg0l3jNFgc57WQMIovhiUJN3mc5oYaGXM2M12-2Bcr9xdX7bPuxmaCnAHwDuyZSAHAb3TsmRqnMM18xjQkb3tB03IijGfP2oQOmU1LimtCeS4jjgd3JbettM2-2BmAGw0-3D

http://gslinki.ivanti.com/ls/click?upn=0R6QHCxgSZb4Tenj5dFRzSTwTT5Q3SUzX-2FAr2byGHLjvBg5k3a2eHRjpqwO112EKT7M3-2F-2F-2BcbvF91YJNAK853B0CzGYYvbuEabIGhtJm8CbQJKnpXyw5jArJ7KIswyYQR5cCzojuj5AVP-2Bfq-2FsJGepzJYM91Xm331TLtLiEmLKkVVGBzUcpHOhepzjgJKtEU7qWl_MPaZZwqO9vZyR2b-2BPyntnUc5xTyqOQZKTxBtgRxh9q-2BXyK5nfQ2kpzHukTdbMqfoni1584gvJIAlaWfczd19drsNvfvGgv7-2FOsJWXT2l1yTeGVAufrBhx4PzyRPO8tqaOxxLofkbHEaKxrTgzffQ2UDXYujXU0vxYd-2F-2FC22DmZZ3A-2BYhrf5wnp4VQw8gChjiExXQetRpaVBclMQ7T7Nk4BcXNou3ikhTznIn3-2BaGl5VfMD-2FEm-2BgX4je4JJNZrtKHRbAR0KP0wVsLuhkAe-2BrfkqSGQxua2G2xLJVH2e28Lwl6iHXCRyH9NXcwLlvxPJv2OsH92Pgjfin-2FBNXwFY6dnliKGtXcChWnUl-2FPazQ2lPnhLOFAqL3QDOTnADtiPDHxx-2FaW0Tdq0c1mso6gvyLXFxXfbdi4gRQwCUoqgIC9aZqNqFxyzzFzPKvR2DnFd85UeQk1M4ksLUqecRwY0-2B4h-2FFpVdF6YrjhqLm6XC1aXVzs-3D

Vendor's write-up

Hi Team,
we wanted incorporate this regex in javascript based solution, could you please help with ECMA Script flavor of detection regex expression

https://support.forcepoint.com/s/article/Apache-log4j-Zero-Day-RCE-Vulnerability-CVE-2021-44228

Not Vulnerable

Forcepoint NGFW 
Forcepoint NGFW VPN Client
Forcepoint Sidewinder 
Forcepoint Sidewinder Control Center
Forcepoint Content Gateway
Forcepoint One Endpoint
    Forcepoint DLP Endpoint
    Forcepoint Web Proxy Connect Endpoint
    Forcepoint Web Direct Connect Endpoint
    Forcepoint NGFW ECA Agent
    Forcepoint CASB Agent
Forcepoint Bitglass SSE
Forcepoint Cloud Security Gateway (CSG)
    Forcepoint Web Cloud Security Gateway
    Forcepoint Email Security Cloud
Forcepoint User ID
Forcepoint Remote Browser Isolation
Forcepoint Private Access
Forcepoint Advanced Malware Detection

Products Under Review

Forcepoint CASB
Forcepoint Email Security
Forcepoint NEO Endpoint
Forcepoint Behavior Analytics (FBA)
Forcepoint Insider Threat
Forcepoint Dynamic User Protection (DUP)
Forcepoint Data Protection Service (DPS)

Affected Products

Forcepoint NGFW Security Management Center Software (see article 38989 and associated Tech Alert)

https://support.forcepoint.com/s/article/CVE-2021-44228-Java-log4j-vulnerability-mitigation-with-NGFW-Security-Management-Center

Forcepoint SMC Appliances (see article 38989 and associated Tech Alert)

https://support.forcepoint.com/s/article/CVE-2021-44228-Java-log4j-vulnerability-mitigation-with-NGFW-Security-Management-Center

Forcepoint Web Security (Investigation in Progress for Remediation or Mitigation)

Forcepoint DLP (see article 38992 and associated Tech Alert )

https://support.forcepoint.com/s/article/CVE-2021-44228-Java-log4j-vulnerability-mitigation-with-Forcepoint-DLP

Forcepoint Security Manager (see article 38991 and associated Tech Alert)

https://support.forcepoint.com/s/article/CVE-2021-44228-Java-log4j-vulnerability-mitigation-with-Forcepoint-Security-Manager

Forcepoint Behavior Analytics (FBA) (Investigation in Progress for Remediation or Mitigation)
Forcepoint CASB (Investigation in Progress for Remediation or Mitigation)
Forcepoint DDP (Investigation in Progress for Remediation or Mitigation)
Forcepoint Data Protection Service (DPS) 
    Note DPS has been updated to mitigate the issue identified in CVE-2021-4228 as of 4:30am Central Time, December 12th. No action is required by Forcepoint customers. 
Forcepoint Dynamic User Protection (DUP)
    Note DUP has been updated to mitigate the issue identified in CVE-2021-4228 as of 9:30am Central Time, December 13th. No action is required by Forcepoint customers. 

In the list it says Apache Tomcat is vulnerable. But looking at the source, Tomcat is not mentioned.

Log4j says that you need to add log4j2 to tomcat in order for it to work. So a default tomcat does not have log4j2.

This is also pointed out in the Tomcat documentation itself:

The internal logging for Apache Tomcat uses JULI, a packaged renamed fork of Apache Commons Logging that is hard-coded to use the java.util.logging framework. This ensures that Tomcat's internal logging and any web application logging will remain independent, even if a web application uses Apache Commons Logging.

Hey,
quick question:
Can you provide us with the software list as a CSV so that we can carry out a quick / automated comparison?

Parsing Markdown tables every update seems a bit much work...

Kind Regards
Appa

PS: Keep up the good work! ;)

I like to report that SonarQube is not vulnerable at the moment. It can be helpful if this is added to the list.

For more information: https://community.sonarsource.com/t/sonarqube-sonarcloud-and-the-log4j-vulnerability/54721

https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=hpesbgn04215en_us

Potential Security Impact: Remote: Code Execution

Source: Hewlett Packard Enterprise, HPE Product Security Response Team

VULNERABILITY SUMMARY
A potential security vulnerability has been identified in Apache Log4j2. Several HPE products use Apache Log4j2 and could be vulnerable.

References: CVE-2021-44228

SUPPORTED SOFTWARE VERSIONS*: ONLY impacted versions are listed.
HP XP Performance Advisor Software All versions
HPE SimpliVity 2600 All versions
HPE SimpliVity 2600 Gen10 All versions
HPE SimpliVity 325 All versions
HPE SimpliVity 380 All versions
HPE SimpliVity 380 Gen10 All versions
HPE SimpliVity 380 Gen10 G All versions
HPE SimpliVity 380 Gen10 H All versions
HPE SimpliVity 380 Gen9 All versions
SimpliVity OmniCube All versions
HPE 3PAR Service Processor All versions
HPE 3PAR StoreServ Management and Core Software Media All versions
HPE SANnav Management Software All versions
HPE Intelligent Management Center (iMC) All versions

Vulnerable Forti products can be found at https://www.fortiguard.com/psirt/FG-IR-21-245

Yara detections for Log4J dependents.

AppDynamics provided their own Advisory on affected products here:
https://docs.appdynamics.com/display/PAA/Security+Advisory%3A+Apache+Log4j+Vulnerability

Cisco's page still shows as investigating yet AppDynamics have pushed out a patch already.

Ivanti Xtraction contains log4net.dll in two different locations, being used by the Web server.

Link to their statement: https://mijn.supportgemak.nl/csm?id=kb_article_view&sysparm_article=KB0279656

https://github.com/N-able/ScriptsAndAutomationPolicies/blob/master/Vulnerability%20-%20CVE-2021-44228%20(Log4j)/get-log4jrcevulnerability.ps1

this is a good script?

Hi,

Thank you for having referenced TheHive and Cortex. They are indeed not vulnerable: the source url is wrong and points to VMware. Please find the public announcement: https://blog.strangebee.com/apache-log4j-cve-2021-44228/
Supplier: StrangeBee

Not visible anything on their site yet:

C:\Program Files (x86)\APC\PowerChute Business Edition\agent\lib>dir | findstr log4j

10-12-2020 18:42 264,058 log4j-api-2.11.1.jar
10-12-2020 18:42 1,607,936 log4j-core-2.11.1.jar
10-12-2020 18:42 23,242 log4j-slf4j-impl-2.11.1.jar

PowerChute Business Edition - 10.0.2.301

https://www.hexagongeospatial.com/products/luciad-portfolio/luciadfusion

Should be on the list, possible vulnerable,, log4j-api-2.11.1.jar is used.

We applied the lookup fix

Please file a PR instead of an issue if you can. See https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files#editing-files-in-another-users-repository. Thanks for your contribution!

I'd like to report that Pentaho could be potentially vulnerable if it's configured: https://help.hitachivantara.com/Documentation/Pentaho/9.1/Setup/PDI_logging No further scans performed

I will submit a PR shortly.
Source: https://portal.microfocus.com/s/article/KM000003049?language=en_US

If you check the linked doc the CVE includes the hot-fix to remediate the issues on the affected system

https://documentation.commvault.com/v11/essential/146231_security_vulnerability_and_reporting.html

See changelog: https://download.unimus.net/unimus/Changelog.txt

2.1.4 has the fix.

COPADATA states Zenon not affected: https://www.copadata.com/en/support-services/knowledge-base-faq/pare-products-in-the-zenon-product-family-affect-4921/

Still uses log4j 1.2 https://issues.apache.org/jira/browse/ZOOKEEPER-4423

(But JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration)

https://kb.vmware.com/s/article/87068

The security advisory can be found here
https://www.splunk.com/en_us/blog/bulletins/splunk-security-advisory-for-apache-log4j-cve-2021-44228.html

Please file a PR instead of an issue if you can. See https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files#editing-files-in-another-users-repository. Thanks for your contribution!

https://wiki.ahsay.com/doku.php?id=public:announcement:cve-2021-44228_log4j

IGEL UMS is vulnerable
Fix/Mitigation possible
A fixed version of UMS is in preparation
Source: https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html

See https://tika.apache.org/2.0.0/index.html

Found CVE-2021-44228 vulnerability in \tomcat\webapps\ROOT\WEB-INF\lib\log4j-core-2.13.2.jar, log4j 2.13.2

Several riverbed devices are vulnerable and several still under investigation: https://supportkb.riverbed.com/support/index?page=content&id=S35645&actp=LIST_RECENT