Another vulnerability was recently found in IIS server NTLM protocol, exposing the targeted server to a relay attack. This vulnerability joins several other vulnerabilities discovered by the Preempt research team.

Given the importance of IIS servers in most enterprises, this vulnerability should be taken seriously. In fact, without taking any measures for mitigation, this vulnerability can be easily exploited, but when applying mitigation activities, it becomes nearly impossible to exploit.

Similarly to some of the former vulnerabilities discovered, the source to these vulnerabilities lies in the Message Integrity Code (MIC).

Mitigating NTLM relay remote code execution

Technical details:

The vulnerability allows attackers to bypass the Message Integrity Code (MIC), that supposed to ensure that the NTLM messages don't get tampered with. Bypassing the MIC will eventually allow modifying any field in the NTLM message flow. When modifying the signing requirements, attackers can relay successful authentications to another server, while making the server to ignore any signing requirements, thereby moving laterally in the infrastructure.

The MIC is an optional feature, therefore, it can be bypassed. Up until now, the only known way NTLM servers can validate that the MIC is present is by inspecting the flags in the 'msvAvFlag' field. Because the 'msvAvFlag' is signed by a hash password, there is no way to modify it. However, a new way to trick the server into believing the message does not include a MIC was found by Preempt research team. This new bypass allows attackers to modify any stage of the NTLM authentication flow.

The key for this MIC bypass lies in a known EPA bypass vulnerability, that allows attackers to inject a 'msvAvFlag' field in the TargetInfo field of the NTLM_CHALLENGE. this field is the echoed back in the NTLM_AUTHNTICATION message. When the attacker sets the 'msvAvFlag' to zero, it would be injected into the authenticated message along with the correct 'msvAvFlag' value (calculated by the client). The attacker is using the fact that when the attacked server receives NTLM_AUTHENTICATION with two different 'msvAvFlag' values, it will only consider the first field- the one injected by the attacker indicating that the MIC is not present in the message.

 

Mitigation:

  1. Enable SMBv2 on all relevant servers. It is highly important that SMBv1 will be disabled and only SMBv2 will be used due to major vulnerabilities in the first version.
  2. Make sure your system is fully protected with the latest security patches.
  3. Stop using NTLM! NTLM is fairly old and has better options nowadays, as it poses some severe security concerns.

NTLMv1 or NTLMv2? Does it even matter?

How can CalCom help?

SMBv1 and NTLM are still too commonly used by enterprises, mainly because of the painful process required to neglect them. Trying to disable such fundamental old timers may cause damages if done recklessly. Disabling those protocols is a labor and time-consuming task often preferred to be put a said by IT teams. CHS by CalCom can make it effortless by completely automating this process. CHS learning abilities will forecast the potential damage in disabling those vulnerable protocols, projecting which can be hardened hassle free and which needs to be reconsidered. After deciding your course of action, CHS will automatically implement it on the entire system. with CHS there's no need for lab testing and no need to worry about server outages.

 

Disable SMBv1 to Mitigate Wannacry

You might be interested