Java log4j vulnerability - Is pfSense affected ?

NollipfSense

@bmeeks said in Java log4j vulnerability - Is pfSense affected ?:

The Snort and Suricata packages are two great examples that I am familiar with since I maintain both of them and created one of them as well.

I knew you were hardcore to the max...had to go off topic to give you a shout-out.

ramtech

@bmeeks said in Java log4j vulnerability - Is pfSense affected ?:

The Snort and Suricata packages are two great examples that I am familiar with since I maintain both of them and created one of them as well.

Sorry for the off-topic, but RESPECT @bmeeks ! Great rant, and couldn't agree more. (maybe something to do with us probably being similar vintage and background )

bmeeks

@ramtech said in Java log4j vulnerability - Is pfSense affected ?:

@bmeeks said in Java log4j vulnerability - Is pfSense affected ?:

The Snort and Suricata packages are two great examples that I am familiar with since I maintain both of them and created one of them as well.

Sorry for the off-topic, but RESPECT @bmeeks ! Great rant, and couldn't agree more. (maybe something to do with us probably being similar vintage and background )

Ha-ha! !

And all you damn kids get off our lawns! ...

ramtech

@bmeeks said in Java log4j vulnerability - Is pfSense affected ?:

Ha-ha! !

And all you damn kids get off our lawns! ...

darcey

I saw alot! of this CVE in my suricata (IDS mode) log from earlier today:

ET HUNTING Possible Apache log4j RCE Attempt - Any Protocol lower Bypass (CVE-2021-44228)
ET HUNTING Possible Apache log4j RCE Attempt - Any Protocol upper Bypass (CVE-2021-44228)
ET EXPLOIT Apache log4j RCE Attempt - 2021/12/12 Obfuscation Observed M1 (CVE-2021-44228)
ET EXPLOIT Apache log4j RCE Attempt - lower/upper TCP Bypass (CVE-2021-44228)
ET EXPLOIT Apache log4j RCE Attempt (http dns) (CVE-2021-44228)
ET EXPLOIT Apache log4j RCE Attempt (tcp dns) (CVE-2021-44228)
ET HUNTING Possible Apache log4j RCE Attempt - Any Protocol (CVE-2021-44228)

From the reported src/dst addresses/ports, these alerts seem to be associated with the following traffic:

syslog-ng on pfsense sending eve log to logstash on a local elastic server.
filebeat on a webserver sending nginx logs to elasticsearch on that same elastic server.

AIUI this particular pfsense installation and syslog-ng aren't vulnerable to the exploit. However the various elastic components involved may be.

This shows the distribution of these alerts:

Screenshot at 2021-12-13 13-25-48.png

From this, I'm guessing the rules appeared in my ruleset with a midnight update. Suricata then began furiously detecting and logging (no blocking on the firewall interface concerned). What interests me is how the alerts peak and decay. Then stop altogether despite the fact the same sort of traffic is almost certainly still crossing that interface.

Re log4j, it seems a very popular library. Several netwrok enabled applications I use daily make use of it. Elastic stack being one of them.

darcey

It's just occurred to me, the logging of these alerts triggers more of the very same alerts! Is it the case suricata rolls off alerting/logging, hence the pattern seen in the logging volume?
I'm guessing I need to disable my remote syslogging of suricata eve to logstash or disable some of those CVE-2021-44228 rules.

bmeeks

@darcey said in Java log4j vulnerability - Is pfSense affected ?:

It's just occurred to me, the logging of these alerts triggers more of the very same alerts! Is it the case suricata rolls off alerting/logging, hence the pattern seen in the logging volume?
I'm guessing I need to disable my remote syslogging of suricata eve to logstash or disable some of those CVE-2021-44228 rules.

It would depend on exactly what the triggering rule is looking for. Could be the rule is just looking for anything log4j2 related. 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 log4j2 utility on there patched up.

bingo600

While NOT pfSense related

There's a list of possible vulnerable products here.
https://github.com/YfryTchsGD/Log4jAttackSurface

I have two of these installed , on "Other servers"

And have "patched/updated both"

None of these are exposed to the "Outside" , but fixed anyway.

I know a few others here are using Unifi ...

/Bingo

johnpoz

@bingo600 said in Java log4j vulnerability - Is pfSense affected ?:

I know a few others here are using Unifi

Yeah I updated to 6.5.54 from .53 as soon as it came out. I normally do anyway.

bmeeks

@bingo600 said in Java log4j vulnerability - Is pfSense affected ?:

While NOT pfSense related
I know a few others here are using Unifi ...

/Bingo

Yes, the latest 6.5.54 version of the Unifi Network Application (a.ka. "Controller") is patched. Just installed it on my system this morning. It was released on December 11th, I believe.

mer

@bingo600
Another list, seems comprehensive from teh Dutch Cyber Security folks.

https://github.com/NCSC-NL/log4shell/tree/main/software

bingo600

@mer said in Java log4j vulnerability - Is pfSense affected ?:

@bingo600
Another list, seems comprehensive from teh Dutch Cyber Security folks.

https://github.com/NCSC-NL/log4shell/tree/main/software

Thanx .. looks good

andrew-netgate

@nimrod Thank you for your question. The recent log4j Java library vulnerability does not affect pfSense software. Neither pfSense Plus nor CE software use Java. Additionally, neither Java nor log4j are available to install manually on pfSense software from Netgate package servers.

Tleary

Sense Project
@pfsense
The recent log4j Java library vulnerability does not affect pfSense software. Neither pfSense Plus nor CE software use Java.
5:03 PM · Dec 13, 2021
[https://twitter.com/pfsense/status/1470514844717699080](link url)

KevinK

Just to make sure, and verify this is not in anything on my pFsense I ran the below command, if you have a lot of packages on yours you could do the same.
find -L / -iname 'log4j'
Nothing was found, thankfully. At my work, that is another story, it is EVERYWHERE :(.

johnpoz

@bmeeks said in Java log4j vulnerability - Is pfSense affected ?:

the latest 6.5.54 version of the Unifi Network Application (a.ka. "Controller") is patched.

They just released a 6.5.55 which has updated version of log4j
"Update log4j version to 2.16.0 (CVE-2021-45046)."

qctech

@bmeeks said in Java log4j vulnerability - Is pfSense affected ?:

I could possibly be properly called a "curmudgeon"

I feel that I'm in good company. I'm not quite at retirement age yet but totally agree about the current state of adding module on top of module on top of module without any real knowledge of where it's all coming from.

At some point, you have to trust other peoples code but it's getting a bit out of hand.

I built Linux From Scratch systems 20 years ago when I had more time and inclination but really don't have time for it now.

It's great that we have got lots of confirmation from both the knowledgeable members of the community and from Netgate direct. Times like these show the good that open source and community can give.

nimrod

@qctech

I moved to FreeBSD, but im still tempted to start building LFS because you learn so much during that process.

bingo600

@johnpoz said in Java log4j vulnerability - Is pfSense affected ?:

@bmeeks said in Java log4j vulnerability - Is pfSense affected ?:

the latest 6.5.54 version of the Unifi Network Application (a.ka. "Controller") is patched.

They just released a 6.5.55 which has updated version of log4j
"Update log4j version to 2.16.0 (CVE-2021-45046)."

Apache released a 2.17 , so i guess we should keep an eye on unifi updates.

How do you get informed of new releases - e-mail subscription or ??

/Bingo

darcey

@bmeeks said

It would depend on exactly what the triggering rule is looking for. Could be the rule is just looking for anything log4j2 related. 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 log4j2 utility 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.