Microsoft Addresses NTLM Bugs That Facilitate Credential Relay Attacks

Microsoft Addresses NTLM Bugs That Facilitate Credential Relay Attacks

NTLM has a long history of serious vulnerabilities and of causing anxiety for Windows and UNIX server admins.Their collective angst is unlikely to les

Fresh Approach to Wi-Fi Cracking Uses Packet-Sniffing
Threatpost News Wrap, Oct. 20, 2017
ThreatList: Tax Scammers Launch a Raft of Fake Mobile Apps

NTLM has a long history of serious vulnerabilities and of causing anxiety for Windows and UNIX server admins.

Their collective angst is unlikely to lessen today with the disclosure of a pair of new vulnerabilities in the protocol suite. Microsoft today was expected to patch one of the issues among its Patch Tuesday updates, and recommends configuration changes to ensure both are addressed.

In the meantime, vulnerable servers with NT LAN Manager enabled need to patch immediately, and either consider turning it off or require that incoming LDAP and SMB packets are digitally signed in order to thwart credential relay attacks at the heart of this threat.

Researchers at Preempt Security said today that an attacker would already have to be present on the local network in order to exploit these flaws. A remote attack is unlikely given that a number of uncommon browser and internet setting configurations would have to be in place enabling a malicious site to ultimately access a domain controller, the researchers said.

NTLM are a suite of Microsoft security protocols used for authentication and are managed through Group Policy in Active Directory. The two vulnerabilities discovered by Preempt and privately disclosed in early April enable credential relay attacks where an attacker is able to steal negotiated NTLM credentials and forward them to a server in order to successfully authenticate to the box.

In one instance discovered by Preempt, LDAP is not protected from such a relay. The protocol allows an attacker who has SYSTEM privileges to use incoming NTLM sessions and perform LDAP operations, such as updating domain objects, on behalf of the admin.

“If there is a machine that’s compromised on an enterprise network, and you have a domain admin account connected to it, without getting access to those credentials themselves, we can relay them instead to the domain controller and have the controller do things for us like create a domain account as the attacker,” said Ajit Sancheti, cofounder and CEO. “We’re not actually compromising credentials of the account, but using them to do things on the domain controller itself.”

With that kind of access, an attacker can load malware on endpoints or carry out exploits of other known vulnerabilities on the network.

All versions of Windows going back to Vista, released in 2007, are impacted, Preempt said. NTLM runs on some UNIX systems and those could be affected as well under certain circumstances.

“It depends on the LDAP server,” said Yaron Ziner, senior rResearcher. “If it is an MS LDAP server (i.e. Active Directory)) then Unix machines that respect NTLM are vulnerable. If they’re using a Unix LDAP server (e.g. Samba) then it depends on the implementation of that server.”

The second vulnerability is with RDP Restricted-Admin mode in Windows, which has been abused in the past in pass-the-hash attacks. The new vulnerability, however, compromises a user in a RDP session to an already compromised endpoint. The vulnerability occurs because RDP Restricted-Admin mode allows for a downgrade to NTLM in the authentication negotiation. And since RDP is generally kept to privileged users, those credentials are at risk meaning they can be similarly relayed as in the LDAP attack to create rogue domain accounts, Preempt said.

Ziner said that it’s likely that the patch alone won’t be enough to fully secure Windows machines from these types of attacks. He suggests adding SMB and LDAP packet signing through Group Policy as a secondary precautionary measure. Admins should also monitor NTLM traffic for anomalies.

“The attack is relatively easy to detect,” Ziner said. “You would see a new domain admin or privileged account being created that wasn’t created by [an admin]. With some applications, it would require comparing logs of the systems that provision new users and the Active Directory log that monitors the actual user creation. But I think the first thing you need to detect is whether you have a domain admin that connects to multiple machines to begin with. In 99 percent of cases, the users who connects to multiple endpoints doesn’t need high domain-wide privileges create new users.”

Go to Source