Log4j2 on 5.0.19

Still nothing from support here and it is very disappointing.

I managed to run that tool and got these results

This command will remove JndiLookup.class from log4j2-core binaries. Are you sure [y/N]? y
scan error: invalid END header (bad central directory offset)
scan error: invalid END header (bad central directory offset)
scan error: invalid END header (bad central directory offset)

Scanned 297 directories and 2616 files
Found 0 vulnerable files
Fixed 0 vulnerable files
Completed in 0.08 seconds

Yes. Same here and we have several remote work customers that we now need to get going some other way. Very sad with this level of exploit there is no response. Very concerning.

I wonder what type if risk it would be to bring up the server and restrict access using firewall rules to a handful of customers who need remote access. Get their ips and add them to the firewall rules. I think this might work but I am damn worried about doing it. If not we will need to setup some splashtop licenses. Any thoughts?

The issue was just noticed. There is a chance it had already been compromised before the last few days. With the potential of key or TCP loggers, etc being placed on the server, I’d hesitate. Although, I have the reputation of being the ‘admin from hell’ :wink: with my users.

There is a new version (1.2) up at the github logpresso page. Seems a touch more in-depth. Ran with the same results as before.

Thanks. The risk reward is just not worth it. Gonna back off on this idea.

For myself, I’m pinning my hopes on the time zone differential. We’re UTC-5, so hopefully they have a few hour head start on our business day to address this. I know they don’t usually follow community posts. I’ve filled out one of the support contact forms. Has everyone posting in this thread done the same?

I have too have sent emails to support this weekend and also via the support contact forms. I would have to imagine they are aware of this issue. Anyone in IT has to be aware of it.

I’m on the latest version and I’ve run the tool:

PS C:\Windows\system32> S:\temp\log4j2-scan.exe "C:\Program Files\SimpleHelp"
scan error: invalid END header (bad central directory offset)
scan error: invalid END header (bad central directory offset)
scan error: invalid END header (bad central directory offset)

Scanned 507 directories and 8318 files
Found 0 vulnerable files
Completed in 2.34 seconds
PS C:\Windows\system32>

One would think, wouldn’t one

As Evan mentioned further up this thread it the log4 stuff is baked into SH so I am wondering if tools like logpresso would pick up the vulnerabilities

strings /opt/SimpleHelp/lib/commons-logging.jar | grep -i log4j
org/apache/commons/logging/impl/Log4JCategoryLog.class
org/apache/commons/logging/impl/Log4JLogger.class
org/apache/commons/logging/impl/Log4jFactory.class
org/apache/commons/logging/impl/Log4JCategoryLog.classPK
org/apache/commons/logging/impl/Log4JLogger.classPK
org/apache/commons/logging/impl/Log4jFactory.classPK

I wonder about the software on end user machines.

So… not ideal but i rely on SH at the moment.

I have setup firewall rules to only allow the IP addresses of our hosts and computers to access the server.

Not ideal, and a pain for dynamic IP users (home users). You just have to ask for their IP to allow list before supporting them if you need to.

Also theres nothing to say it cant be attacked from a users machine. Seems unlikely, but possible.

Hopefully my week wont be a nightmare as this is the only Java based product we use.

Hopefully SH will confirm or deny vulnerability and release a patch if needed soon.

1 Like

I presume you have no WAN ports pointed to it.

Be careful btw, don’t lock yourself out.

So far the agent installed on user systems has not popped up in any scans from services like crowdstrike, huntress, sophos, etc. So I am really hoping the software is not vulnerable. It would be a nightmare.

1 Like

I just heard from support. See below

“SimpleHelp does not utilise Log4J so its not vulnerable to exploit (CVE-2021-44228). We do not expect any version of SimpleHelp to be affected in any way.”

3 Likes

That’s a little bit of good news :slight_smile:

Thank you for all the communication, and especially for posting the confirmation that SH isn’t affected. Right after making this thread, my account was temporarily suspended, so I couldn’t reply to anyone. But I’ve been following the discussion all weekend, Thanks, all.

Just to clarify - those are the apache commons logging interfaces to log4j. Not log4j itself. SH has posted a new thread on this topic and have confirmed that the product is not susceptible to (CVE-2021-44228) - Log4J Vulnerability (CVE-2021-44228) and SimpleHelp

1 Like