Log4J Vulnerability - CVE-2021-44228 (2024)

Hello,

Can we get a statement from 3CX on CVE-2021-44228? Is the system affected by this vulnerability? If not, great! If so, is a patch coming and will action be required on the part of Administrators.

Thanks,
Ian

jcostlow said:

I believe that plugin is only for Apache. 3CX uses nginx so it shouldn't be affected.

Click to expand...

I would say it is the wrong time to just believe jcostlow!

As ckrammer said we need a clear and official statement.
Our security tools already went on alarm that the nginx.exe is communicating with malicious IPs.

Examples:
23.129.64.131
185.220.100.253

virustotal also classifies these addresses as vulnerable.

So to me it clearly looks like nginx.exe is using the log4j functionality and is affected!

jcostlow said:

I believe that plugin is only for Apache. 3CX uses nginx so it shouldn't be affected.

Click to expand...

This is absolutely false information. Log4j has nothing to do with Apache httpd (web server).

That being said, 3CX doesn't seem to use any Java at least in our local Debian-based appliance and I found no traces of Log4J being installed on it.

Hello all,
Thanks for raising concerns, let's clear this out: we are indeed not using any Java in the 3cx System and confirmed with our Product team that we have no dependencies with Log4j library so aren't affected by this vulnerability.

@Bucher Admin this means your 3cx HTTPS port was contacted by those IP addresses that are probably scanning for vulnerable hosts to hack but it's a dead end in our case.

pj3cx said:

Hello all,
Thanks for raising concerns, let's clear this out: we are indeed not using any Java in the 3cx System and confirmed with our Product team that we have no dependencies with Log4j library so aren't affected by this vulnerability.

@Bucher Admin this means your 3cx HTTPS port was contacted by those IP addresses that are probably scanning for vulnerable hosts to hack but it's a dead end in our case.

Click to expand...

Thank you very much for this official information.

Have a good day Pierre.

Kind regards,
Christian

pj3cx said:

Hello all,
Thanks for raising concerns, let's clear this out: we are indeed not using any Java in the 3cx System and confirmed with our Product team that we have no dependencies with Log4j library so aren't affected by this vulnerability.

@Bucher Admin this means your 3cx HTTPS port was contacted by those IP addresses that are probably scanning for vulnerable hosts to hack but it's a dead end in our case.

Click to expand...

Hi thanks for the "official" statement.
Now let us clarify if ghis is applicable to 3cx windows client(ver.16, ver1.8), mobile apps(Android/iOS) as well?

pj3cx said:

@HiroNikuyama we've checked also the 3cx windows client, Desktop application, Android app, iOS app and they don't have any dependency to this library, so all are safe.

Click to expand...

Good! thanks for the detailed info!

I made some analysis today and found traces of log4j in the File /usr/lib/3cxpbx/NLog.dll

log4jDateBase
log4jxmlevent

tnib_brainy said:

I made some analysis today and found traces of log4j in the File /usr/lib/3cxpbx/NLog.dll

log4jDateBase
log4jxmlevent

Click to expand...

I'm not an expert but I believe this is so that Nlog can send and receive messages to a remote log4J application. Again, this is just a guess!

Hi @pj3cx

what is the result of your check with @Tanner Chartier ?

BR,
Daniel

Hello,
I have not received any reply from the gentleman but our internal checks confirms that there is no such vulnerability in the products. In particular, nothing happens when throwing java strings to our ports...

@tnib_brainy about NLog.dll, it's a standard .NET library used for logging, it does have 2 "Log4j" strings in it which are functions names meant to format some outputs in the same manner for interoperability purposes, but in no way this means the vulnerable Log4j library is statically or dynamically loaded in it. The two libraries are not related. You can also refer to their site or github for more info.

pj3cx said:

Hello,
I have not received any reply from the gentleman but our internal checks confirms that there is no such vulnerability in the products. In particular, nothing happens when throwing java strings to our ports...

@tnib_brainy about NLog.dll, it's a standard .NET library used for logging, it does have 2 "Log4j" strings in it which are functions names meant to format some outputs in the same manner for interoperability purposes, but in no way this means the vulnerable Log4j library is statically or dynamically loaded in it. The two libraries are not related. You can also refer to their site or github for more info.

Click to expand...

Just to underline this via a simple github search -> https://github.com/NLog/NLog/search?q=log4j

Most occurrences of "log4j" are in comment lines. "log4j is commonly used" and not "log4j is everywhere"