ESC8 Identification is Incomplete

[Adonist]

Hi,

It seems that ESC8 identification is not accurate.
In my case I can confirm web enrollment is not installed and Windows authentication for CEP and CES is set to: Negoriate:Kerberos and Extended Protection is Required.
Still, running Locksmith comes up with "HTTP enrollment is enabled."

[Adonist]

Forgot to mention that the SSL Settings is also set to Require SSL

[TrimarcJake]

I've confirmed this! And I see what's causing it. Dang regex.

[TrimarcJake]

Hi, @Adonist

I just pushed changes to the fix-esc8-125 branch. Please test it and let me know if it works for you! (If you're unsure how to test with a specific branch, feel free to reach out for assistance.)

[Adonist]

I'll check it tomorrow and let you know. Thank you for the quick action on this!
Also, I see that the Fix for the issue for ESC8 is showing up as [TODO].
I would be happy to assist with remediation steps to fix things based on the findings.

Thanks

[TrimarcJake]

Thank you for the quick action on this!

No, thank you for testing and reporting! It helps to get reports from real users. Lab tests only go so far.

I would be happy to assist with remediation steps to fix things based on the findings.

I would love that. Feel free to submit a PR, or we can chat about it in a different space. Totally up to you.

[Adonist]

Apologies for the delay in testing it and getting back to you.
I've tested now and it picks up HTTPS which is good. However, this is not necessary an issue. Enforcing HTTPS is one of the mitigations for ESC8.

I think for ESC8 it should consider:

• Is web enrollment installed ?
• Is EPA required ?
• Is SSL required ?
• Is windows authentication set to Kerberos ?
• Is NTLM enabled ?

If using HTTPS, Kerberos AUthentication and EPA for CEP and CES, it shouldn't be vulnerable to ESC8 essentially.

The regex is picking up correctly though.

[TrimarcJake]

First: thank you for confirming the change now properly identifies the HTTPS endpoints as HTTPS!

As for the rest of your comment: we generally approach things from a defender's standpoint. The mitigations you listed reduce or eliminate the risk of NTLM relay if fully implemented, but in our opinion, the best solution is eliminating the endpoint altogether.

That's why this is a VERY basic check. If you find an HTTPS enrollment endpoint, it's low risk, but it's still a risk.

But we are aware of the limitations of this approach and have started discussing methods for improving this test. Assessing the actual risk of the HTTPS finding is simply impossible with the data we gather at the moment, so step one will be gathering additional data.

If you'd like to help build this check, we'd gladly accept a PR! You can even post PoC code in this Issue, and I'll keep it open until you're satisfied. :D