log4j exploit - what to do??

[fabilau]

Hello!

As some of you may have heard, a huge security hole has been found in the Java package "log4j".
(https://www.bleepingcomputer.com/ne...og4j-java-library-is-an-enterprise-nightmare/)

So my question is, does Proxmox also use this package?
Do we admins have to do something?

Many thanks in advance &
kind regards,
Fabian

 

[binaryanomaly]

I'd like to have some information here as well. Thx.

 

[aaron]

So my question is, does Proxmox also use this package?

There is no Java used on the Proxmox VE side of things.
Proxmox VE is mostly written in Perl, with some daemons in C and Rust. The same goes for the Mail Gateway. The Proxmox Backup Server is written primarily in Rust.

Since our products are all open source, feel free to check out the source code at https://git.proxmox.com/

This is of course only valid for a standard installation. If you did install some 3rd party software that is using Java, you might be affected. A first step to figure that out would be to check for any java processes running. I think

ps auxwf | grep java

should do the trick.
Edit: Though that would also give results if you have some java running inside a container. Check who the owner is.

 

[binaryanomaly]

There is no Java used on the Proxmox VE side of things.
Proxmox VE is mostly written in Perl, with some daemons in C and Rust. The same goes for the Mail Gateway. The Proxmox Backup Server is written primarily in Rust.

Since our products are all open source, feel free to check out the source code at https://git.proxmox.com/

This is of course only valid for a standard installation. If you did install some 3rd party software that is using Java, you might be affected. A first step to figure that out would be to check for any java processes running. I think

ps auxwf | grep java

should do the trick.
Edit: Though that would also give results if you have some java running inside a container. Check who the owner is.

Great, thanks for the swift response @aaron

XenForo might be impacted though:
https://xenforo.com/community/threa...h-and-more-via-apache-log4j-log4shell.201145/

 

[tom]

XenForo might be impacted though:

thanks, we run xenforo, but no elasticsearch.

 

[crally]

Hi,

there is a good command to proof, if your machines are affected:

sudo find / -name log4j-core-*.jar

Sometimes the lib is packed into a *.jar file. To proof this you can use:

sudo find / -name \*.jar -exec sh -c "if zipinfo {} | grep JndiLookup.class; then echo -e '{}\n'; fi" \; 2>/dev/null

put the commands into the proxmox shell. This will proof your containers, too. For the virtual machines you need to put the commands into there shells.
As you can see, my unifi controller (CT 106) was affected. A simple apt update && apt upgrade did the trick for this. It's now at version 2.15

 

[mmhx]

Where would I check for possible attacks (on CTs /VMs) ?
Is there some default log active, that I would check, and what would I look out for?

(I really dont think what I administrate was attacked inside VPN and with only neo4j using log4j, but I'm curious)

 

[crally]

I think that would be difficult. You could search all log files for the attackers command (don't know if I am allowed to post it). But since it could be, that the attacker deleted the log entry's you cannot be sure if your system is injected with something....
But maybe someone else has an idea.

 

[oguz]

Where would I check for possible attacks (on CTs /VMs) ?
Is there some default log active, that I would check, and what would I look out for?

in your web logs mainly. most exploit attempts are sending HTTP requests with the malicious payload inside some header (User-Agent is common, along with some other ones).

if you search online you can find fail2ban filter rules [0]

just look out for common signs of compromise if you have doubts:
* new users on the system
* unfamiliar processes taking a lot of resources
* weird cron jobs
* missing/deleted logs
and the regular stuff.

although if you're not using any java you shouldn't have to worry about it

from our stack there's nothing we use java with, so default installations are safe as mentioned before...

[0]: https://github.com/atnetws/fail2ban-log4j/blob/main/apache-jndi.conf