Log4j2 on 5.0.19

I tried to audit as best as I could, but could not find that my version of SimpleHelp is using log4j2. Can anyone confirm this? I need to know if there is anything I need to do regarding the RCE in log4j2.

I am using the latest version and emailed support yesterday, still no update. Please let us know if you hear anything.

Edit: scratch what I said and check out @EvanF post below!

I’m on 5.3.4, and it appears log4j is baked into SH…

‘strings /opt/SimpleHelp/lib/commons-logging.jar | grep -i log4j

1 Like

Now that is scary. I too have emailed support with no response. I shut our server down until I get a response.

We did the same. We also have not received a response from support.

We have shutdown our server as well. Waiting on a response from support

I was able to find a Log4j2 vulnerability scanner to detect if our SimpleHelp server (5.2.17) had the vulnerability. After running the scanner it didn’t detect any vulnerabilities (see below). I have attached a link to the scanner that was used. Can anyone else confirm the same results?


GitHub - logpresso/CVE-2021-44228-Scanner: Vulnerability scanner for Log4j2 CVE-2021-44228

Thanks for the link. I had issues running it at first. I ended up changing directory to c:\program files\simplehelp\jre\bin and calling log4j2-scan “c:\program files\simplehelp”.

The run kicked 3 errors: error: invalid END header (bad central directory offset) 3 lines of that.
Then similar results to you, Mike: 0 vulnerable files. THe number of directories and files reported match the file/directory count.

Ok, I believe that this is encouraging news. Thanks Peter!

We’ll see. I think it will be good to hear from the developers. I also pinged in on a support request form.

1 Like

Great info Mike…Thanks…But I am going to wait for SH to reply before we bring our server back up. The risk is just too great.

1 Like

An interesting deep dive on the issue:

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?