Remote Support
Remote Access
Monitoring and Management
Presentation
Remote Work
Standard
Business
EnterpriseI 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.
Iām on 5.3.4, and it appears log4j is baked into SHā¦
ā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
ā
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ā 
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?