Jump to content

PrintNightmare


Recommended Posts

Note the current best recommended mitigation:

Quote

CISA encourages administrators to disable the Windows Print spooler service in Domain Controllers and systems that do not print.

 

Link to comment
Share on other sites

Was looking around and think it can attempt to infect desktops, attacker creates a  share and then tells the remote computer to install the driver, which the remote computer does despite the user not having privileges to do so and the dll runs as system.

https://doublepulsar.com/zero-day-for-every-supported-windows-os-version-in-the-wild-printnightmare-b3fdb82f840c

Quote

Or in English, any authenticated user can remotely add any ‘print driver’ to Windows — you don’t need to be an administrator or have permission.

Scope of the problem

Windows runs Print Spooler by default — including on Domain Controllers (by design) and Windows 7, 10 etc. It is also enabled on many Windows Server installations

 

Link to comment
Share on other sites

Posted (edited)
1 hour ago, robg said:

Was looking around and think it can attempt to infect desktops, attacker creates a  share and then tells the remote computer to install the driver, which the remote computer does despite the user not having privileges to do so and the dll runs as system.

This is very interesting.

For some time, I have observed periodic attempts to install a printer driver on my device. I am sure this isn't originating from HP since they haven't updated my Laser printer driver in ages. The driver install fails due to its not being "package aware" which I guess is one mitigation against this.

HP_Driver.thumb.png.38cbbef593682cf71d2623ac16a813a6.png

Also, I see occasional Win Event log entries about dynamic code execution being blocked from spoolsv.exe:

Spool_Mit.png.be9ce8aa313a891a000d5035f912b07e.png

Edited by itman
Link to comment
Share on other sites

I wonder if something can be done with HIPS rules to prevent the exploit? similar to the ACL (deny System modify on the spooler/drivers folder) workaround that is being suggested?

Link to comment
Share on other sites

Posted (edited)
21 minutes ago, jdashn said:

I wonder if something can be done with HIPS rules to prevent the exploit? similar to the ACL (deny System modify on the spooler/drivers folder) workaround that is being suggested?

Maybe. Per posted Github link:

Quote

An generic way to hunt for Print Spooler exploitation is looking for error generated by print spooler due to loading of the payload DLL. This can be done either through looking for spawning of WerFault.exe by spoolsv.exe or generation of Event ID 7031 showing unexpected termination of print spooler service.

This will only notify about spoolsv.exe exploiting and does not address modification activities.

Edited by itman
Link to comment
Share on other sites

We think that ESET can add detection of this kind of attacks in IDS ( as like as detection of Zerologon attacks )

Can we have this detection in futures updates ?

Link to comment
Share on other sites

5 minutes ago, kamiran.asia said:

We think that ESET can add detection of this kind of attacks in IDS

Difficult I would think.

When spoolsv.exe starts, the printer injects its .dll driver, plus usually .dll monitor, into it. This exploit allows anyone to remotely download a malicious printer driver to accomplish this. Microsoft in their "infinite dis-security wisdom" allows virtually any status user to install a printer driver.

Also this is a remote execution attack and there are established mitigations against that.

Link to comment
Share on other sites

16 hours ago, itman said:

This is very interesting.

For some time, I have observed periodic attempts to install a printer driver on my device. I am sure this isn't originating from HP since they haven't updated my Laser printer driver in ages. The driver install fails due to its not being "package aware" which I guess is one mitigation against this.

 

Also, I see occasional Win Event log entries about dynamic code execution being blocked from spoolsv.exe:

 

Not seen any attempts yet that I can find, biggest risk for us would be someone inside the organisation deciding to try it as an elevation of their domain authenticated account so will have a look for that.

Link to comment
Share on other sites

Posted (edited)

Per the ZDNet.com article:

Quote

So due to a different attack vector, Microsoft has broken out a second CVE. The suggested workaround is to disable the print spooler service or disable inbound remote printing through group policy.

"This policy will block the remote attack vector by preventing inbound remote printing operations. The system will no longer function as a print server, but local printing to a directly attached device will still be possible," the warning attached to the workarounds state.

 

Edited by itman
Link to comment
Share on other sites

Posted (edited)
Quote

Free micropatches addressing the actively exploited PrintNightmare zero-day vulnerability in the Windows Print Spooler service are now available through the 0patch platform.

Even though no security updates are available to address the PrintNightmare security flaw at the moment, Microsoft has shared mitigation measures to block attackers from compromising vulnerable systems and is working on a fix.

This is where the 0patch micropatching service comes in, with free micropatches for Windows Server versions 2019, 2016, 2012 (updated with June 2021 Updates) and 2008 R2 (with January 2020 Updates installed and no Extended Security Updates).

Our patches will be free until Microsoft has issued an official fix. If you want to use them, create a free account at https://t.co/wayCdhpc38, then install®ister 0patch Agent from https://t.co/UMXoQqpLQh. Everything else will happen automatically. No restarts needed.

— 0patch (@0patch) July 2, 2021

According to 0patch, "some of the above patches may not be issued yet at the time of this writing, but will be within next hours."

https://www.bleepingcomputer.com/news/security/actively-exploited-printnightmare-zero-day-gets-unofficial-patch/

Also and of note from the 0patch web article is the following:

Quote

However, non-DC servers and Windows 10 systems with June 2021 updates can also be vulnerable in at least these cases:

  • UAC (User Account Control) is completely disabled [source], or
  • PointAndPrint NoWarningNoElevationOnInstall is enabled [source].

Nevertheless, our remote attacks on Windows 10 were so far not successful against domain-joined Windows 10 machines, where the attack would be most worrisome. We were so far only able to launch the exploit using credentials of a local user on a non-domain Windows 10 machine, and such credentials are likely not known to an attacker. So these tests so far only confirm a possible local privilege escalation (a local user exploiting PrintNightmare to gain local System privileges).

Q: How about Windows systems without June 2021 Windows Updates?

It is possible that without June 2021 Windows Updates, all supported Windows systems, i.e., all servers from 2012 up and all Windows 10 systems, are affected [source].

https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.html

Edited by itman
Link to comment
Share on other sites

Posted (edited)

TRUSEC also has a mitigation that involves restricting ACL permissions:

Quote

While we still recommend that the print spooler service should be disabled on any system that does not need it, we also want to provide a temporary workaround to make the exploit ineffective, while allowing you to keep your print servers running, until a patch is available.

The exploit works by dropping a DLL in a subdirectory under C:\Windows\System32\spool\drivers

By restricting the ACLs on this directory (and subdirectories) we can prevent malicious DLLs to be introduced by the print spooler service.

https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/

Edited by itman
Link to comment
Share on other sites

We've checked with Spiceworks forum and here, currently we're seeing the following:

Checked through most of our systems here and have found a pattern that EventID: 808 tend to be the error that the PowerShell Script everyone is looking at. Most of the errors so far are legitimate Printer driver issues due to remote connection of some kind.

Knowing that IT Admins utilize specific Print Drivers for systems, could ESET get the hash of the files (DLL et al) that's used and have that as a check on servers to verify that it's something we've said are okay? I know we have some VPN users, but normally we don't allow printing to them anyway so blocking them wouldn't be an issue for us here, though I could see it being an issue for others. To that, I'd say have a Print-to-file that they can have emailed to their email or similar.

Not sure if this would stop it, but it could be a start for now.

Link to comment
Share on other sites

Microsoft is currently rolling out KB5004945 to fix these vulnerabilities via Win Updates . Patch your devices pronto!

Link to comment
Share on other sites

Posted (edited)

So much for the patches to this vulnerability:

Quote

Researchers have bypassed Microsoft's emergency patch for the PrintNightmare vulnerability to achieve remote code execution and local privilege escalation with the official fix installed.

Last night, Microsoft released an out-of-band KB5004945 security update that was supposed to fix the PrintNightmare vulnerability that researchers disclosed by accident last month.

After the update was released, security researchers Matthew Hickey, co-founder of Hacker House, and Will Dormann, a vulnerability analyst for CERT/CC, determined that Microsoft only fixed the remote code execution component of the vulnerability.

However, malware and threat actors could still use the local privilege escalation component to gain SYSTEM privileges on vulnerable systems for older Windows versions, and for newer versions if the Point and Print policy was enabled.

The Microsoft fix released for recent #PrintNightmare vulnerability addresses the remote vector - however the LPE variations still function. These work out of the box on Windows 7, 8, 8.1, 2008 and 2012 but require Point&Print configured for Windows 2016,2019,10 & 11(?).  https://t.co/PRO3p99CFo

— Hacker Fantastic (@hackerfantastic) July 6, 2021

Today, as more researchers began modifying their exploits and testing the patch, it was determined that exploits could bypass the entire patch entirely to achieve both local privilege escalation (LPE) and remote code execution (RCE).

According to Mimikatz creator Benjamin Delpy, the patch could be bypassed to achieve Remote Code Execution when the Point and Print policy is enabled.

Dealing with strings & filenames is hard
New function in #mimikatz to normalize filenames (bypassing checks by using UNC instead of \\server\share format)

https://www.bleepingcomputer.com/news/microsoft/microsofts-incomplete-printnightmare-patch-fails-to-fix-vulnerability/

The details of the patch bypass:

Quote

To bypass the PrintNightmare patch and achieve RCE and LPE, a Windows policy called 'Point and Print Restrictions' must be enabled, and the "When installing drivers for a new connection" setting configured as "Do not show warning on elevation prompt."

Specifically:

Quote

This policy is located under Computer Configuration > Administrative Templates > Printers > Point and Print Restrictions.

When enabled, the 'NoWarningNoElevationOnInstall' value will be set to 1 under the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint key.

Appears an Eset HIPS rule to prevent modification of the reg. key should do the trick with the understanding it could "hose" a legit printer driver installation I would think.

Edited by itman
Link to comment
Share on other sites

Posted (edited)

Today's latest status:

Quote

Microsoft says the emergency security updates released at the start of the week correctly patch the PrintNightmare Print Spooler vulnerability for all supported Windows versions and urges users to start applying the updates as soon as possible.

This clarified guidance comes after security researchers tagged the patches as incomplete after finding that the OOB security updates could be bypassed in specific scenarios.

"Our investigation has shown that the OOB security update is working as designed and is effective against the known printer spooling exploits and other public reports collectively being referred to as PrintNightmare," the Microsoft Security Response Center explains.

"All reports we have investigated have relied on the changing of default registry setting related to Point and Print to an insecure configuration."

Err ..... since the "malware world" now knows what these Point and Print registry settings are, my advice is to create an Eset HIPS rule to ensure they can't be modified; e.g.  write activity against HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\*.

Edited by itman
Link to comment
Share on other sites

Hi dears.

We test this PrintNightmare-CVE-2021-34527 exploit : https://www.thedutchhacker.com/how-to-exploit-the-printnightmare-cve-2021-34527/  in our test lab at a unpached win2016 and ESET FileSecurity IDS detect it as

7/9/2021 1:52:59 PM;Web threat;Blocked;192.168.235.161:50426;192.168.235.176:445;TCP;SMB/RiskWare.Generik.A;System;0000000000000000000000000000000000000000;

If you disable IDS in this kind of exploit , reverse.dll will be detect as a variant of Win64/Injector.EO trojan by ESET.

If there is any other Exploit , We can test it and publish the result.

 

ESET_PrintNightmare.jpg

Link to comment
Share on other sites

17 hours ago, kamiran.asia said:

We test this PrintNightmare-CVE-2021-34527 exploit : https://www.thedutchhacker.com/how-to-exploit-the-printnightmare-cve-2021-34527/  in our test lab at a unpached win2016 and ESET FileSecurity IDS detect it as

Appears to me this is an exploit attempt simulation from a network share via SMB. Eset IDS should have been already detecting this type of activity.

An RPC exploit which is what this vulnerability is about would be using port 135. In other words, Eset detected SMB based malware activity and the actual RPC exploiting activity never was attempted. Note that anything that could deploy a reverse shell; i.e. backdoor, on one of your network devices could be deployed to perform exploiting.

Note also that there are multiple vulnerabilities that exist in regards to spoolsv.exe. The first of those were patched in the June cumulative updates. The patch for CVE-2021-34527 only addresses the RCE and LRCE issue. The prior patches still need to be applied for full protection against all current known spoolsv.exe vulnerabilities.

It really is time you upgrade your Win server OSes to supported versions.

Edited by itman
Link to comment
Share on other sites

6 hours ago, itman said:

An RPC exploit which is what this vulnerability is about would be using port 135

Thank u dear ,

Do you have that exploite code to test ?

Link to comment
Share on other sites

3 hours ago, kamiran.asia said:

Do you have that exploite code to test ?

Only thing I could find is this https://github.com/JumpsecLabs/PrintNightmare which appears to be similar the web site you previously linked is using but employing PowerShell. Eset doesn't detect this .dll on download currently.

Also check this out which tests the previous known vulnerabilities: https://github.com/cube0x0/CVE-2021-1675

Note the following:

Quote

Microsoft has released a patch to mitigate against these attacks but if these values below are present on a machine, then the machine will still be vulnerable

REG QUERY "HKLM\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint"

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint

RestrictDriverInstallationToAdministrators REG_DWORD 0x0

NoWarningNoElevationOnInstall REG_DWORD 0x1

You can also download the source code for the .dll used in this test, add some additional code, recompile it, and see it Eset detects it. Also use your modified .dll in the Powershell attack version.

Finally and noted previously, there is nothing to prevent an attacker with admin privileges from modifying this reg. key to the above values.

Edited by itman
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...