Page 1 of 7 123 ... LastLast
Results 1 to 10 of 63
  1. #1
    Untangler
    Join Date
    Apr 2016
    Posts
    30

    Exclamation Log4Shell l0g4j vulnerability CVE-2021-44228

    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
    Last edited by atothek; 12-10-2021 at 02:05 PM.

  2. #2
    Newbie
    Join Date
    Aug 2020
    Posts
    4

    Default

    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.
    Last edited by Angstroli; 12-10-2021 at 11:16 PM.

  3. #3
    Newbie
    Join Date
    Oct 2018
    Posts
    8

    Default

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

  4. #4
    Untangler
    Join Date
    Mar 2018
    Location
    Toronto, Ontario
    Posts
    82

    Default

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

  5. #5
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,510

    Default

    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.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  6. #6
    Newbie
    Join Date
    Dec 2021
    Posts
    1

    Default

    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)
    Last edited by deags; 12-11-2021 at 06:11 PM.
    donhwyo and hdukes like this.

  7. #7
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,510

    Default

    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.
    Last edited by sky-knight; 12-12-2021 at 12:08 AM.
    junglechuck and dashpuppy like this.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  8. #8
    Untangler
    Join Date
    May 2008
    Posts
    572

    Default

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

  9. #9
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,510

    Default

    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.
    donhwyo likes this.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  10. #10
    Untangler
    Join Date
    Nov 2017
    Posts
    45

    Default

    Quote Originally Posted by donhwyo View Post
    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.

Page 1 of 7 123 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2