MS13-098 anyone?

Since the weekend, we have started seeing MS13-098 come up as a missing patch (check is looking for a specific key in registry - all Windows 2016 servers).

Has anyone also come across this situation?

2 Likes

same here, we see this for

  • Microsoft Windows Server 2019 SE
  • Microsoft Windows Server 2016 SE
    The vulnerability definition/logic was changed on Aug 24, 2022, and first detected around Aug 26, 2022 (probably first scheduled scan after update)

Microsoft rereleased this CVE with additional remediation suggestions

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900

R7 updated the detection according to this new suggested remediation.

What is different?
As far as I can tell, the remediation steps are exactly the same. For 64-bit OSs, the recommendations are still to set the same two reg keys as originally published in 2013. We have set these two reg keys accordingly & rebooted, but R7 is still reporting the systems as vulnerable. From the article you linked, “the information herein remains unchanged from the original text published on December 10, 2013.”

1 Like

I added the Reg keys to our 2016 and 2022 template machines, rebooted, and R7 still says they are missing the Reg entries when they are clearly there… Anyone else still having issues too, or what I may have done wrong?

I just noticed this as well. Are there any updates from Rapid7?

I’m not sure about six days ago, but as of right now the remediation recommended at Microsoft Security Advisory 2915720 | Microsoft Learn is working for me. The one caveat if you are creating the registry entries manually is that they need to be string (or REG_SZ) entries; originally I had incorrectly created them as DWORD and Rapid7 flagged it as not addressed.

1 Like

Yep, seeing the same thing; however, we just created the reg files and that took care of it. One of the sys admins is hoping to apply it through GPO for non-prod to test first. I’m not sure why it’s not working for some - unless it is now for you, hopefully.

@todd_cox, @aa-jcostner, @jmerchant - how is the situation now?
There has been no change from Rapid7 on this topic since last 20+ days that I can find.

1 Like

Hi @svakharia ,

On machines where I applied Microsoft’s recommended remediation, Rapid7 no longer finds the vulnerability. By all indications, Rapid7’s detection methodology is accurate.

Hope that answers your question,
jmerchant

Save as what @jmerchant is stating. Seems the vuln instance goes away when the reg key is updated. Still waiting on GPO to take care of the rest.

Could I just ask any of you remediating this one…did the Wintrust folder exist in the below two folders referenced by Microsoft?
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography]
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography]

I don’t see it so I’m unclear whether it still requires action ???

Hello Steven,

If you do not have the Wintrust key, then you will need to create it, plus Config underneath it, plus a new string value called EnableCertPaddingCheck with a value of 1, in order for Rapid7 to consider the vulnerability remediated. If you are hoping to import a REG file, then it will look like this:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Wintrust\Config]
"EnableCertPaddingCheck"="1"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Cryptography\Wintrust\Config]
"EnableCertPaddingCheck"="1"

or, if performing it through PowerShell:

if ($(Test-Path HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config) -ne $true)
{
    Write-Output "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config does not exist...creating it"
    New-Item HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config -Force
}

New-ItemProperty -Path HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config -Name EnableCertPaddingCheck -PropertyType String -Value 1 -Force

if ($(Test-Path HKLM:\Software\Microsoft\Cryptography\Wintrust\Config) -ne $true)
{
    Write-Output "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config does not exist...creating it"
    New-Item HKLM:\Software\Microsoft\Cryptography\Wintrust\Config -Force
}

New-ItemProperty -Path HKLM:\Software\Microsoft\Cryptography\Wintrust\Config -Name EnableCertPaddingCheck -PropertyType String -Value 1

There’s a few different ways to skin this cat; hopefully this provides you with the needed guidance.

1 Like

Hi thanks for your reply and confirmation.

Hey, I have some 2016 and 2019 Severs that flagged for this while others built from the same template and have the same latest patches don’t flag for it. Anyone else run into that? None of the them have the registry keys, so just trying to undestand why?

4 Likes

Following-up on this, the KB article https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900 says that Windows 2022 server core is vulnerable, but I have non server core Windows 2022 systems being flagged as vulnerable, any ideas as to why?

Hey gmendoza! MS13-098 is always a fun ride :melting_face:

So assuming that you meant non-Core version of Server 2022, both Windows Server 2022 (Server Core installation) and Windows Server 2022 are listed as affected in CVE-2013-3900, and our checks would be looking for both.

If you meant another operating system unrelated to Server 2022 (core or not), please let me know!