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.
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.....
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.
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.
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.
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
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?
I'm opening a case with MS Support and will let everyone know when I get the answer to this.
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.
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.
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
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
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.
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
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?
you can safely delete them if you do not have any Java-based application that uses your SQL server
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.
1. Machine Learning (2019+)
2. Polybase
3. SQL Big Data Clusters
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.
I've been zipping the Jar folders and then deleting them. At least then we can recover them if needed.
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.
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?!
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"
Hello @ABDULSAHAD-5358
You can find Microsoft official guide and statements here:
Hope this helps with your query,
--If the reply is helpful, please Upvote and Accept as answer--
The latest patch CU16 has the solution to this issue.
KB5011644 - Cumulative Update 16 for SQL Server 2019
"Removes log4j2 used by SQL Server 2019 Integration Services (SSIS) to avoid any potential security issues."
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.
26 people are following this question.
