Log4Shell l0g4j vulnerability CVE-2021-44228

[atothek]

I see here you’re using log4j: https://wiki.untangle.com/index.php/Upstream_Projects

Can you please share if you’re using an impacted version of log4j (2.0beta9 through 2.14.1) per this vulnerability?

https://logging.apache.org/log4j/2.x/security.html

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.
Severity: Critical
Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected: all versions from 2.0-beta9 to 2.14.1
Descripton: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.
Mitigation: In previous releases (>=2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technolo...-relnotes.html) protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
References: https://issues.apache.org/jira/browse/LOG4J2-3201 and https://issues.apache.org/jira/browse/LOG4J2-3198

[Angstroli]

Yea considering my Untangle is literally my only outward facing device, I'd really like to know.

Log4Shell seems like an extinction-event level exploit

Edit: I tried searching for log4j files in a virtual machine disk installed with Untangle, and it turned up one result in /user/share/java/uvm/log4j-1.2.6.jar. (There were other results for slf4j-log4j but apparently that is something different that just ties in to log4j).

If that log4j file, being 1.2.6, is the only version being used, then it should not be vulnerable because it is too old. We'll have to wait for confirmation though because I'm not sure if it could be implemented somewhere else harder to see.

Also it looks like the upstream projects page does specifically say "log4j" and not "log4j2", so that would match up with the version I found. So assuming that all means it only uses v1 and not 2+, hopefully we should be good.

[omniscorp]

I've opened a support ticket. It's critical we get an answer on this asap.

[balrog]

* Assuming log4j is vulnerable in untangle(Think not since it says log4j 2.x is vulnerable where untangle looks like is using 1.x)
* enable untangle web GUI exposed to the WAN interface, then it's a problem when user supplied input is not first filtered.

However, default install of untangle web GUI is on the private LAN not WAN so we are good.

[sky-knight]

I wouldn't say good, but better. Direct exposure scanning from the public interface is mitigated if you do not accept HTTP or HTTPs on WANs. Which is default, and certainly the recommended configuration.

However, these services are exposed on the LAN side, and the nature of the vulnerability affords exploitation via a simply http post event. I've tried to exploit my HTTP and HTTPs services internally with several methods and so far nothing has worked. Note, LAN exposure could be completed with a script running on a browser within the walls, this is easily achieved and must be mitigated too.

https://www.crowdstrike.com/blog/log...commendations/

This blog indicates that the default configuration of JVMs from both Oracle and OpenJDK have been configured to prevent exploitation since 2019.

Untangle is based on Debian 10.11 currently, which was released Oct 9th 2021. So unless Untangle has explicitly changed com.sun.jndi.rmi.object.trustURLCodebase to True, it should be immune. Untangle relies on the Debian provided Java-common package to provide the JAVA environment it uses, which on a current install is version 0.71 which is also current for Debian Buster based installations.

I'm not proficient enough in Java to know how to manually check the above variable to verify its value at present.

[deags]

The intrusion prevention plugin already has rules for CVE-2021-44228

log4j.png

Just make sure to set those to block (default is just log)

[sky-knight]

Yep, I've got a rule that simply says, if message contains log4j then block.

I'm curious to see how that turns out.

I expected more to be impacting my RMM, but so far... it's quiet.

Going to have the kids help me test Minecraft with these rules in place tomorrow.

[donhwyo]

Would be nice to have a response from Untangle. No comment almost implies it might be bad.

[sky-knight]

TP-Link Omada controllers are vulnerable, no patch from TP-Link yet.

Unifi controllers are all vulnerable. Network is patched in version 6.5.54, Protect is patched in 1.20.1. I don't use Access, Talk, or IDentity, but I presume there are updates for those apps as well.

Cloudflare is making a huge deal out of their defensive measures for all of their clients, including apparently freely using their proxy service. So irrespective of Untangle's stance, that should be sufficient to keep the Command Center safe all on its own. Still need a response from Untangle on the risks associated with NGFW, SD-WAN, and WAF.

[MNTech68]

Would be nice to have a response from Untangle. No comment almost implies it might be bad.

Where the heck is the official response on this? Literally every other firewall and security company has updates being posted. I don't care if it's a weekend. We're all working to mitigate this, yet apparently Untangle can't be bothered?

I've tried POC on Untangle and been unsuccessful so far, but that's not the same as an official response.