Log4J vulnerability concerns

ABDUL SAHAD 11

Hi Team,

As there is a Log4J vulnerability trending recently. May I get clarifications for the below points.

1) How the Log4J vulnerability impacting my Windows hosts?

2) How can I prevent or take precautions from getting affected by Log4J?

3) Microsoft released any patches for mitigating this vulnerability?

4) does it affect any other applications released by Microsoft like MSSQL, SCCM or IIS etc.

Kindly provide the updates on this.

Ulrich O Kirkegaard 6 Reputation points

2021-12-16T04:25:09.16+00:00

I'm seeing this in Windows Servers that run Remote Web Access or even Exchange Servers OWA; the Jar stuff is in there, its old, its being flagged as vulnerabilities; and attempts being made to exploit it. We have only MS IIS, RWA, OWA etc. installed no other 3rd party web server tools; so I can conclude that Microsoft application servers are using the L4j in Inetpub logging;

Example;
SUSP_JDNIExploit_Indicators_Dec21 C:\inetpub\logs\LogFiles\W3SVC1\u_ex211210.log
0x1710:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/
0x1829:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/
0x1c1a:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/
0x1d33:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/

Created a support case with Microsoft but response leads to their generic response page; so I'm replying back with these specific details.

To be continued.....

6 answers

Vadims Podāns 8,866 Reputation points MVP

2021-12-14T07:28:41.297+00:00

How the Log4J vulnerability impacting my Windows hosts?

if your applications use Log4J, you are vulnerable. If not -- you are not vulnerable.

How can I prevent or take precautions from getting affected by Log4J?

patch corresponding applications that use Log4J

Microsoft released any patches for mitigating this vulnerability?

no, Microsoft doesn't own Log4J, so they are not responsible for patching a 3rd party library. Log4J is owned by Apache.

does it affect any other applications released by Microsoft like MSSQL, SCCM or IIS etc.

no Microsoft applications use Log4J. Only 3rd party applications (mostly, Java-based) may use this library. And every single 3rd party application should be evaluated if they use this library. If they do -- contact application vendor and request patch from that vendor. Microsoft is not responsible for that.
Please sign in to rate this answer.

2 people found this answer helpful.
E. Rottier 41 Reputation points

2021-12-14T16:33:25.79+00:00

Well, I found a very old version in MS SQL. Probably not specifically Microsoft, but still. I did NOT try to find out where it came from yet, got other stuff to do first.

"C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar"

P.S. log4j 1.2 is a very old version with ALSO has a critical flaw of 9.8 on the CCS3 scale.

Coy Meeks (NC) 11 Reputation points

2021-12-14T18:30:32.07+00:00

I've got a SQL Server 2019 Standard installed on several servers that have these l4j jars

"C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar"
"C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\slf4j-api-1.7.5.jar"
"C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\slf4j-log4j12-1.7.5.jar"

Additionally, downloading the SSIS extension in Visual Studio 2019, these same jars are installed:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars\log4j-1.2.17.jar"
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars\slf4j-api-1.7.5.jar"
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars\slf4j-log4j12-1.7.5.jar"

I've been looking for remediation steps for these but have not found any.

Vadims Podāns 8,866 Reputation points MVP

2021-12-14T19:51:26.77+00:00

these are connectors/drivers only.

Michael Long 6 Reputation points

2021-12-23T18:48:32.637+00:00

Your information is not completely accurate. Microsoft distributes 15 products which are affected by the Log4j vulnerability.

Apache Log4j Remote Code Execution Vulnerability
CVE-2021-44228
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-44228

Luke Morey 1 Reputation point

2022-01-18T09:23:45.017+00:00

Right, so if someone sends data through the connector with the same JNDI string...?

Ian V 21 Reputation points

2022-08-24T05:19:09.223+00:00

Sorry for raising a 'dead' thread. Doesn't matter. These Microsoft products include older Log4J versions, so it is up to Microsoft to release newer versions of their products (SQL Server) that include the updated version of Log4J, regardless of it being a connector, driver, or otherwise.
These kind of files ("C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar") show up in Vulnerability Management platforms, and need to be attended to.
I did not enjoy your statements of "no, Microsoft doesn't own Log4J, so they are not responsible for patching a 3rd party library" and "no Microsoft applications use Log4J".
Sign in to comment
Jelongpark 6 Reputation points

2022-04-25T18:32:05.12+00:00

The latest patch CU16 has the solution to this issue.

KB5011644 - Cumulative Update 16 for SQL Server 2019

14669019

"Removes log4j2 used by SQL Server 2019 Integration Services (SSIS) to avoid any potential security issues."

https://support.microsoft.com/en-us/topic/kb5011644-cumulative-update-16-for-sql-server-2019-74377be1-4340-4445-93a7-ff843d346896
Please sign in to rate this answer.

1 person found this answer helpful.
BFos 26 Reputation points

2022-04-26T17:50:33.347+00:00

Thanks for the tip. On a SQL Server 2019 installation, my Nessus vulnerability scanner showed an alert because of the following file : C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar

I just installed CU16 on that machine, and the update seems to have removed the offending file. Another file "slf4j-log4j12-1.7.5.jar" is also now gone.
Sign in to comment
TJ 31 Reputation points

2021-12-14T17:48:14.73+00:00

ERottier is correct. SQL put it there when installing SQL 2019 Ent. I'm assuming it's for Java check box when installing sql 2019? Anyway, can this be safely removed from the directory? In fact, can the whole JARS folder be removed?
Please sign in to rate this answer.
Ilkka 11 Reputation points

2021-12-14T17:57:34.807+00:00

Yes, SQL (Express) 2019 does install old log4j. I also like to know why (is it used). Even is't so old that this current vulnerability is not in that version, there are others vulnerabilites in 1.2.17

TJ 31 Reputation points

2021-12-14T19:25:22.937+00:00

I'm opening a case with MS Support and will let everyone know when I get the answer to this.

TJ 31 Reputation points

2021-12-14T19:53:24.413+00:00

Here's what MS said,

Microsoft is aware of active exploitation of a critical Log4j Remote Code Execution vulnerability affecting various industry-wide Apache products. This vulnerability is in the open source Java component Log4J versions 2.0 through 2.14.1 (inclusive) and is documented in Apache CVE-2021-44228.

We are taking steps to keep customers safe and protected - including performing a cross-company assessment to identify and remediate any impacted Microsoft services. We are also investigating for potential customer/partner impact in SQL Server. If we identify any customer/partner impact in SQL Server, we will publish the updated information.

E. Rottier 41 Reputation points

2021-12-15T06:54:01.843+00:00

Yeah we know they are aware that the 2 - 2.14.1 version is affected, but what they did NOT say is that they use an even OLDER version (think pre-2012) which also has a critical of ccs 9.8 in there!

This old library stuff is idiotic, all timebombs waiting to happen. This surely is not the only one. Just the one getting much attention.

Simon Phillips 6 Reputation points

2021-12-16T13:50:21.167+00:00

Erottier is right - Even though the current issues with the 2.* libraries there are still outstanding issues with the unsupported v1 libs I think the 'current' score on the doors is around a 6

pdbars 11 Reputation points

2022-02-11T16:03:52.107+00:00

I opened a case with Microsoft recently asking about this. They gave reasons why I shouldn't be concerned about potential vulnerabilities we are warned of by our security scanning software. They also mentioned that a 'fix' removing the log4j .jar file is planned for a future SQL2019 CU (no specific date given).

Up until now I have renamed the file which gets rid of the noise in our scans, however Microsoft (as expected) do not approve/support this as mitigation.

I would suggest waiting for this upcoming patch is probably the best approach.

tcr49 1 Reputation point

2022-03-03T06:41:40.533+00:00

We asked MS about this as well; the initial response was https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-44228 which discusses various vulns in log4j v2 binaries.

That article ignores that a stock install of SQL Server 2019 with only "Database Engine Services" feature installed will still drop C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar which has at least one vulnerability mentioned in CVE-2021-4104.

Since there is no official patch from Microsoft as of today (March 3, 2022) (per pdbars-2511 that's pending) one remedy is to use logpresso [https://github.com/logpresso/CVE-2021-44228-Scanner] to rip out the offending classes from the jar itself.

To wire up a test env and mitigate using logpresso:

Install SQL Server 2019 choosing only "Database Engine Services" feature during setup.

Download latest version of log4j2-scan from https://github.com/logpresso/CVE-2021-44228-Scanner

Run log4j2-scan against "drive:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars" with --scan-log4j1 arg to verify log4j-1.2.17.jar exists and has classes vulnerable to CVE-2021-4104.

Optionally run log4j2-scan against the same path with --scan-log4j1 --fix args to actually mitigate.

SCAN ONLY:
[path]:\log4j2-scan.exe "[drive_letter]:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars" --scan-log4j1
SCAN AND MITIGATE:
[path]:\log4j2-scan.exe "[drive_letter]:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars" --scan-log4j1 --fix
Sign in to comment
Shaky 11 Reputation points

2021-12-14T18:54:06.317+00:00

Can confirm we are seeing the old version of Log4J in our SQL Server 2019 Standard DTS folder as well. Wondering what the best upgrade path would be, can it be deleted or just replaced?
Please sign in to rate this answer.
Vadims Podāns 8,866 Reputation points MVP

2021-12-14T19:52:16.333+00:00

you can safely delete them if you do not have any Java-based application that uses your SQL server

Greg Ota 11 Reputation points

2021-12-14T20:01:32.317+00:00

Here is a comment I received from Microsoft about the DTS folder:
Engineering has confirmed that the log4j used in SSIS is not vulnerable. The vulnerability only affects log4j version 2.x

There are only 3 features/configurations of SQL that leverage Java directly and still under investigation.
 

Machine Learning (2019+)

Polybase

SQL Big Data Clusters

Shaky 11 Reputation points

2021-12-14T20:22:13.66+00:00

Thanks for following up with Microsoft! Hopefully Microsoft just removes it from their installer in the near future. Log4J 1.2.17 went end of life like 5 years ago

Based on the articles from Apache they didn't check Log4J 1.x because it was end of life.

Per what Crypt32 has below, it likely is better just to remove it if your not using Java based apps.

Sherlock, Mike 1 Reputation point

2021-12-14T21:52:09.59+00:00

Hello GreOta, Is what the engineer stated in writing somewhere?

E. Rottier 41 Reputation points

2021-12-15T06:56:03.98+00:00

Haha, "The vulnerability only affects log4j version 2.x". Very true! Only what they didn't say was that they do use an even older version with another critical of 9.8 on the ccs3 scale.

Tom Vanharpen 16 Reputation points

2021-12-15T15:28:18.3+00:00

I've been zipping the Jar folders and then deleting them. At least then we can recover them if needed.
Sign in to comment
Ulrich O Kirkegaard 6 Reputation points

2021-12-16T18:09:27.193+00:00
We are seeing this in Windows Servers that run Remote Web Access or even Exchange Servers OWA; the Jar stuff is in there, its old, its being flagged as vulnerabilities; and attempts being made to exploit it - as per our Datto RMM. We have only installed MS IIS, RWA, OWA etc. no other 3rd party web server tools; so it seems to us that Microsoft application servers are using the L4j in Inetpub logging;

Example;
SUSP_JDNIExploit_Indicators_Dec21 C:\inetpub\logs\LogFiles\W3SVC1\u_ex211210.log
0x1710:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/
0x1829:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/
0x1c1a:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/
0x1d33:$xr1: ldap://45.155.205.233:12344/Basic/Command/Base64/

Through a support case with Microsoft their response is as follows;

"Anyone at all that has a Internet facing server is getting scanned since this became public. Seeing attempts in the IIS logs doesn’t necessarily indicate a compromise. It could just mean that someone is looking to fingerprint your machine to see if it is vulnerable.

The vulnerability is in an Open Source Java logging library so unless you added a 3rd party application that uses Log4J2 it is unlikely that you are vulnerable to this exploit.

It may be worth looking into a 3rd party vulnerability scanner the help determine your systems are vulnerable."

So I'm not sure if they are right; it seems that the stuff was written into the logs; and so we wonder if indeed thats possible that the above lines showing attempts to reach out to an odd IP address can end in the logs of Inetpub aka IIS without server being vulnerable?!
Please sign in to rate this answer.
Mark Pace 11 Reputation points

2021-12-22T02:04:35.027+00:00

We too running Datto RMM and seeing all our RDS Servers with this as well showing attacks as well and very concerned
No one seems to be able to give us an answer - nor Datto, MS or other except "unless you have lof4j youre safe"
Sign in to comment

Log4J vulnerability concerns

6 answers

14669019