Java log4j vulnerability - Is pfSense affected ?
-
@bmeeks said
It would depend on exactly what the triggering rule is looking for. Could be the rule is just looking for anything
log4j2related. That would mean the potential for false positives exists.If your logging server is well isolated and protected on your LAN or other more secure subnet, I would not immediately suspect any malicious activity in that scenario. I would investigate with maybe a few packet captures and use Google research to validate if the alerts are something that can be suppressed for the IP of your remote logging server. And obviously you would want to get any
log4j2utility on there patched up.I believe I partly figured out what's going on.
To recap, I have suricata running on two interfaces (LAN and DMZ).
LAN hosts an Elastic/log server.
DMZ hosts a public facing webserver (NAT), with filebeat sending nginx logs to the LAN based log server.
A rule allows this specific traffic from DMZ hosts to LAN log server.To cut down the noise I temporarily disabled payload logging.
A log4j http uri arrives at the DMZ interface and is detected/blocked by suricata (legacy mode). However, at least some log4j uris make their way to the webserver. Suricata, on the LAN interface, then detects those log4j signatures in the filebeat http logging crossing the LAN interface to the logserver.
What I haven't determined is why some log4j traffic reaches the webserver. Is this becasue they are not matched. Is it because some packets make their way through due to suricata running in legacy mode. Or are they obfuscated by https (I think I can rule this out since at least some of the requests appear not https). AISI if no log4j traffic hit the webserver, I would never see log4j alerts on the LAN.I'm 99% certain the webserver is not vulnerable to the log4j vulnerability and it is only configured to serve static pages. But I'm intrigued and want to understand what is happening.
-
@nimrod said in Java log4j vulnerability - Is pfSense affected ?:
you learn so much during that process
You certainly do. I keep thinking that I should do it again to see how the project has changed.
It is possible to just copy and paste and learn nothing so you do have to take the time to understand the commands and how things are linking together. -
@bingo600 said in Java log4j vulnerability - Is pfSense affected ?:
How do you get informed of new releases - e-mail subscription or ??
I follow the release threads over on their forums - they send an email whenever a update comes out. So yeah I get an email whenever firmware for AP or Controller comes out.
edit: BTW just got email that controller 7.0.15 is out.. And one of the things is
"Update log4j version to 2.17.0 (CVE-2021-45105)."
-
@johnpoz said in Java log4j vulnerability - Is pfSense affected ?:
edit: BTW just got email that controller 7.0.15 is out.. And one of the things is
"Update log4j version to 2.17.0 (CVE-2021-45105)."
Still not in the unifi debian repos , checked twice today.
/Bingo
-
@bingo600 I don't use the repo's I manually download from their site the package..
https://dl.ui.com/unifi/7.0.15-aa76488648/unifi_sysvinit_all.deb
-
@johnpoz said in Java log4j vulnerability - Is pfSense affected ?:
https://dl.ui.com/unifi/
Still no repos update for me , but i'm on 6.5.??
Seems like there ought to come a new version soon , Apache released 2.17.1 today.
https://dlcdn.apache.org/logging/log4j/
How's the 7.x.x version ?
-
@bingo600 said in Java log4j vulnerability - Is pfSense affected ?:
How's the 7.x.x version ?
I haven't had any issues with it. I haven't seen an update for the 2.17.1 yet for the controller - will keep an eye on my emails.
-
I'm using the 7.0.15 version, it's running perfectly on my RPI 4b @ ubuntu server 20.04.3 LTS (GNU/Linux 5.4.0-1047-raspi aarch64)
-
New fix - 2.17.1
https://thehackernews.com/2021/12/new-apache-log4j-update-released-to.html
The Apache Software Foundation (ASF) on Tuesday rolled out fresh patches to contain an arbitrary code execution flaw in Log4j that could be abused by threat actors to run malicious code on affected systems, making it the fifth security shortcoming to be discovered in the tool in the span of a month.
Tracked as CVE-2021-44832, the vulnerability is rated 6.6 in severity on a scale of 10 and impacts all versions of the logging library from 2.0-alpha7 to 2.17.0 with the exception of 2.3.2 and 2.12.4. While Log4j versions 1.x are not affected, users are recommended to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
"Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code," the ASF said in an advisory. "This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2."
-
from what we see across various products and devops environments most often the devs are unaware of it until shown.. log4j can be buried deep so i'm about to scan my local pfsense using latest openvas plugins.. .although im not aware of it,.. it could still be behind something else.
~If i see any hits i will return them here. -
@shinobi said in Java log4j vulnerability - Is pfSense affected ?:
from what we see across various products and devops environments most often the devs are unaware of it until shown.. log4j can be buried deep so i'm about to scan my local pfsense using latest openvas plugins.. .although im not aware of it,.. it could still be behind something else.
~If i see any hits i will return them here.pfSense is open source software. If there was log4j module used, it would have been found / exposed and fixed by now. There are thousands of people out there checking the code. Not just Netgate. What im trying to say is, you are wasting your time.
