
NTLM Hash Leaks: Ancient Microsoft Design Flaw - wolframio
https://dylankatz.com/NTLM-Hashes-Microsoft%27s-Ancient-Design-Flaw/
======
pinpeliponni
NTLM was deprecated in 1999, when Windows 2000 came out. You have been
supposed to use krb5 since then, and disabled the NTLM. Why is anything about
NTLM still news? You have to specifically enable it on newest Windows
platforms, because afaik it has been disabled by default for some 5+ years
now.

~~~
noinsight
> You have to specifically enable it on newest Windows platforms, because
> afaik it has been disabled by default for some 5+ years now.

No you don't have to specifically enable it, it's still enabled (by default).

Completely disabling NTLM on a network would be a large project and not even
Microsoft recommend that because the security gains are relatively small.

(See microsoft.com/pth for their comprehensive credential security guidance)

~~~
liso
By default, Kerberos will fail back to NTLM when:

* Authenticating against a pre-NT 4.0 server * Accessing a domain resource via IP * Accessing a resource on a non-domain member * Accessing a resource on a computer that does not support Kerberos (Windows 3.11, Windows 95, etc.)

It's trivial to force this downgrade on most domains.

------
noinsight
I get the feeling that the author doesn't actually have much experience with
production enterprise networks (where this issue occurs and is relevant).

It really isn't as simple as just flipping a switch and disabling NTLM:

> Microsoft made it very clear that they strongly recommended against
> disabling NTLM due to incompatibility issues. Instead, they created a system
> called NTLM Blocking, which requires users to edit their Windows security
> policies, track event logs, and whitelist applications that need access.
> This system, while effective if used correctly, is very complicated for
> normal users to configure and difficult to understand.

It _is_ a complicated affair to fully get your network into 100% Kerberos
mode. It will require prior auditing and fixing unless you want to suddenly
break things in production (because this configuration is binary).

As a sysadmin myself, I can confidently say that most IT people (I really
would say the majority) do not fully understand the authentication mechanisms
on an AD network and how authentication happens in the background because
Microsoft has actually succeeded in making it very transparent (except when
things really break).

Many times Kerberos is not configured correctly in which case thanks to the
NTLM fallback things still work and people will be none the wiser (which can
be a bad thing precisely because people don't realize it). If you were to
suddenly just disable that NTLM altogether, many things will suddenly just
stop working.

Kerberos requires manual configuration in many cases (Service Principal Names)
and its reliance on working DNS is absolute.

Some examples:

1) Need to connect to a system via IP address for whatever reason? Too bad,
without NTLM it's impossible.

2) re: above, what if someone configured a connection string (database
connection etc.) somewhere with an IP address? It won't be using Kerberos.
Disable NTLM and the connection will just stop working.

3) Want to connect to a laptop that moves around often? Your dynamic DNS
entries better be up to date. If the DNS name leads to a different device, you
will get an authentication failure regardless of access because you're trying
to authenticate with a Kerberos ticket for the wrong machine. See 1.

4) Set up a DNS CNAME (or anything that's not the server's actual hostname
where configuration is mostly automatic)? Did you remember to add a Kerberos
Service Principal Name for that name in AD? If not, you won't be using
Kerberos with those names.

5) Set up a server service (SQL, IIS, etc.)? Is it running under the computer
identity or a domain user account? That identity will need the proper Service
Principal Name. Did you add one? If not, it won't be using Kerberos. Disable
NTLM and the service will simply stop working.

6) Need to connect to a machine not on the domain? Need to connect to a
machine on another domain with which you don't have an AD trust in place? You
won't be using Kerberos.

To summarize, simply disabling NTLM willy-nilly on an enterprise network is
going to be an RGE (resumé generating event).

------
QAPereo
>However, even when this attack is blocked over the internet, it is very
rarely blocked over LAN, meaning it could be used as a method of pivoting
within networks.

That's frightening, and I wonder if there are any exploits in the wild which
do just that?

~~~
youdontknowtho
Most exploits don't actually need to be all that crafty. They just ask someone
to click a link and run some javascript. Could someone use this to pivot in a
network? Yes. Almost every large enterprise has bigger problems than this.
People need to be looking at the new model that they came up with for Windows
10 and Azure AD join if they want to stay on Windows clients. The traditional
domain model makes the potential impact of breach far too widespread. Windows
Server AD should be used as a server management technology with resources
being in resource domains that are just big enough to manage things that are
related as a unit. Everybody and everything in the same domain is an
antipattern now a days because of credential theft techniques. Most places
don't have the expertise to maintain AD. It's too complicated and the loss of
a single domain admin cred means that you have to rebuild it if you want to
get back to a trustworthy state.

Ehh. It's Friday and I want some cake.

~~~
EvanAnderson
Resource forests, if you want actual security boundaries. Domains aren't
security boundaries.

Having said that, some good old fashioned network segmentation would be a
"win", too. Default deny ACLs should be the norm, and hosts sshould only be
able to communicate with hosts they actually need to, full stop. (The
reactions I get from developers, however, are typically less than pleasant
when they learn that environments I administer have such policies, however.)

~~~
youdontknowtho
True dat. I've gotten where I use forest and domain interchangeably even
thought what you say is true. I only advise people build single forest single
domains these days. Complex forest topologies are also a bad thing.

------
adekok
ntlm is still used every day in WiFi authentication. PEAP authentication is
MS-CHAP over TLS over EAP. And the only way for non-MS products to
authenticate to Active Directory is via Samba and ntlm.

Things would arguably be _more secure_ if MS allowed for AD to export the
password hashes to other systems. Querying for an NT hash via LDAP over TLS
has essentially zero security problems. (Other than the NT hash itself)

~~~
spydum
Not sure what you mean about non-MS things using AD. sssd-ad is a fine client
and uses kerberos, not NTLM.

~~~
adekok
You can take a clear-text password and authenticate it to AD via kerberos.

If you have MS-CHAP data, you can't convert it to something which will be
accepted by kerberos. You MUST send it to AD as MS-CHAP data (i.e. ntlm), and
then AD returns "pass / fail"

