Skip to main content

The story of ZeroLogon

This is the story of a vulnerability that was brought about by the incorrect use of an encryption technique. After it was discovered by researchers, the vulnerability was patched and that should have been the end of the story. Unfortunately the patch caused problems of its own, which made it very unpopular. Cybercriminals seized the opportunity to use the vulnerability for their own purposes. This is the story of ZeroLogon.

What is ZeroLogon?

The ZeroLogon vulnerability was discovered by researchers at Secura and is listed in the Common Vulnerabilities and Exposures (CVE) database under CVE-2020-1472:

"An elevation of privilege vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC), aka 'Netlogon Elevation of Privilege Vulnerability'."

This vulnerability exploits a cryptographic flaw in Microsoft's Active Directory Netlogon Remote Protocol (MS-NRPC), which allows users to log on to servers that are using NTLM (NT LAN Manager). Researchers explained that the issue stems from the incorrect use of AES-CFB8 encryption, which requires randomly generated initialization vectors for each authentication message. Sadly, Windows didn't take this requirement into consideration. An attacker can use zeros for the initialization vector, allowing them to take over a domain controller in a matter of seconds.

How bad is this vulnerability?

Very bad, is the short answer. ZeroLogon has been successfully weaponized by malware authors, who use it for the lateral infection of corporate endpoints. The sophisticated Trickbot Trojan uses ZeroLogon, which means that it can spread across a vulnerable network easily. Ryuk ransomware has also been seen using the ZeroLogon vulnerability.

Is there a patch?

Yes, but there's a "but". The vulnerability was actually patched in August 2020, and it wasn't until a researcher published a report about the vulnerability in September that we started to see it used in malicious activity.

In late October, Microsoft warned that threat actors were actively exploiting systems that were unpatched against ZeroLogon privilege escalation.

In November Microsoft also added detection rules to Microsoft Defender to "detect adversaries as they try to exploit this vulnerability against your domain controllers."

The general advice is to use Secure RPC to prevent these attacks. Secure RPC is an authentication method that authenticates both the host and the user who is making a request for a service. Secure RPC uses the Diffie-Hellman authentication mechanism, which uses DES encryption rather than AES-CFB8.

Why isn't everything patched against ZeroLogon by now?

The problem with the patch is that it is not enough to update the server side (Domain Controller), because clients also need to be updated for the protocol to work. And even though Microsoft took care to issue patches for Windows devices, it didn't provide a solution for legacy operating systems that are no longer supported, or for third-party products. This means that enforcing Secure RPC may break operations for these incompatible systems.

So, what's next?

Now, Microsoft has announced that it will enforce the use of Secure RPC .

"beginning with the February 9, 2021 Security Update release we will be enabling Domain Controller enforcement mode by default.  This will block vulnerable connections from non-compliant devices.  DC enforcement mode requires that all Windows and non-Windows devices use Secure RPC with Netlogon secure channel unless customers have explicitly allowed the account to be vulnerable by adding an exception for the non-compliant device."

Having read that you might be thinking: "But you said it might break incompatible systems!" True, so Microsoft has made a list of actions that will result in a detailed update plan.

The update plan outlined by Microsoft includes the following actions:

  • UPDATE your Domain Controllers with an update released August 11, 2020 or later.
  • FIND which devices are making vulnerable connections by monitoring event logs.
  • ADDRESS non-compliant devices making vulnerable connections.
  • ENABLE enforcement mode to address CVE-2020-1472 in your environment.

This probably means there is still no happy ending to this story. Addressing the non-complaint devices will not be as easy at it sounds, in many cases. In many cases it will end with sysadmins making an exception for such a device. It is advisable however to at least try and follow the steps. Because in the end it will pay off to remove (or at least limit) the vulnerable devices and machines on your network. The cybercriminals will not let go of this treasure so easily.

Stay safe, everyone!

The post The story of ZeroLogon appeared first on Malwarebytes Labs.



from Malwarebytes Labs full article here

Popular posts from this blog

Chaos in a cup: When ransomware creeps into your smart coffee maker

When the fledgling concept of the Internet of Things (IoT) was beginning to excite the world almost a decade ago, perhaps no coffee lover at that time would've imagined including the coffee machine in the roster of internet-connected devices—even in jest. True, the simple, utilitarian coffee machine may not be as popular now as it used to back in the day, but its continued availability within office premises and private home kitchens, plus inherent risks—much like any IoT device—may be in equal footing with your smart speaker , smart doorbell , or smart light bulb . Cybersecurity issues surrounding internet-connected coffee machines are further punctuated by the latest news about how Martin Hron, a reverse engineer from Avast, tinkered his Smarter coffee maker to not only beep and spew out hot water but also deprive you of a nice, morning brew and display a short ransom note. Courtesy of Dan Goodin, Ars Technica Yes, Hron turned his coffee maker into a ransomware mach...
Read more

A week in security (December 10 – 16)

Last week on Labs, we took a look at some new Mac malware , a collection of various scraped data dumps , the protection of power grids , and how bad actors are using SMB vulnerabilities .   Other cybersecurity news Millions affected by Facebook photo API bug: An issue granted third-party apps more access to photos than should normally be granted, including images uploaded but not published. (source: Facebook) Bomb threats may be a hoax: An email in circulation urging ransom payments in Bitcoin lest bombs across the US be detonated may well be a fake , according to US law enforcement. (source: The Register) Man jailed for fraud offenses: A man in the UK has been jailed for taking part in fraudulent activities. The main point of interest is surely the spectacular device he built. (source: Met Police) Another Google Plus bug: For six days, developer were able to access profile data not made public by the users. (source: Google) Windows 10 data collection: Reddit use...
Read more

Skimmer acts as payment service provider via rogue iframe

Criminals continue to target online stores to steal payment details from unaware customers at a rapid pace. There are many different ways to go about it, from hacking the shopping site itself, to compromising its supply-chain. A number of online merchants externalize the payment process to a payment service provider (PSP) for various reasons, including peace of mind that transactions will be handled securely. Since some stores will not process payments on their own site, one might think that even if they were compromised, attackers wouldn't be able to steal customers' credit card data. But this isn't always true. RiskIQ previously detailed how Magecart's Group 4 was using an overlay technique that would search for the active payment form on the page and replace it with one prepped for skimming. The one we are looking at today adds a bogus iframe that asks unsuspecting customers to enter their credit card information. The irony here is that the s...
Read more