Avoiding Pre-Auth/Auth Principal State Disclosure

[Greg Hudson]

On 7/1/20 3:55 PM, Chris Hecker wrote:
>> For example, if we treated single-component principals as users,
> anyone with a user/admin principal (or user/root, which has no status in
> the code but is a common convention for elevated access) would probably
> still be detectable by an attacker.
> 
> Not sure I follow this, why wouldn’t they be treated like a normal princ
> if we had this obscurity feature?

The difficulty is in making a "normal princ" look identical to an actual
normal princ.

Let's say we added this obscurity setting to the KDC in the following
naive way: if an unauthenticated AS request comes in and the client
principal isn't found in the DB, we send PREAUTH_REQUIRED.  If the
request contains preauth (of a recognizable "real" preauth type) then we
send PREAUTH_FAILED.

Service principals can (and frequently do) authenticate as clients.
Because they have random keys, they don't generally require preauth
(partly because preauth would be a waste of round trips when the key is
random, and partly because PREAUTH_REQUIRED has undesirable legacy
semantics when applied to service principals).  So without first
authenticating as a legitimate client, the attacker can distinguish
between a dummy response and a real response for a service principal.
Perhaps we don't care about obscuring valid service principals, but if
we do, we have to instead respond to AS requests for service-principal
clients with a dummy ticket (of a size indistinguishable from a
legitimate ticket) encrypted in a random key, instead of a
PREAUTH_REQUIRED.  And because there is no formal distinction between
user principals and service principals, we can't trivially determine
whether the client principal (if it existed) would be for a user or for
a service.

Additionally, in a PREAUTH_REQUIRED error, we have to send etype-info
based on the request's enctype preference order and the client and
server principals' supported enctypes.  There's no client principal
entry, so what enctypes do we assume are supported by the client?
Perhaps we consult supported_enctypes.  What if the administrator just
recently began a transition from aes-sha1 to aes-sha2 enctypes?  Most
real principals will only have aes-sha1 keys, but supported_enctypes
lists the aes-sha2 enctypes.  In this situation it's easy to distinguish
dummy responses from those for most real principals.

The use of more advanced preauth mechanisms might further muddy things;
for instance, principals intended to authenticate with PKINIT might have
no keys, and therefore no etype-info.  Perhaps we allow the
administrator to create a template principal which has similar metadata
to the majority of user principals, and use that for dummy responses.
Now we're asking a lot from the administrator, and any kind of enctype
or preauth transition would still create classes of users who are
distinguishable from the template.

We'd also have to consider whether to include TGS requests in the threat
model.  If the attacker is an insider or has compromised just one client
account, they can try to build their valid principal list using TGS
requests instead of AS requests.  If we're just trying to obscure user
principals this might not be too hard, assuming users have DISALLOW_SVR
set.  We'd have to send back S_PRINCIPAL_UNKNOWN instead of
MUST_USE_USER2USER when the service principal has that flag.
(Additional attention might need to be given to the user-to-user code
path, as the attacker could try user-to-user with a bogus TGT.)  If
we're also trying to obscure service principals, the problem becomes
much harder; we'd have to issue dummy service tickets for invalid
services, again making sure the ticket size isn't distinguishable, and
making the choice of ticket session key enctype indistinguishable from a
normal service principal.  Issuing dummy service tickets would create
many problems for legitimate users, such as breaking
dns_canonicalize_hostname=fallback.

Finally, none of the above analysis considers side channels.  If a dummy
response takes a measurably different amount of time for the KDC to
synthesize than a normal response, an attacker still might be able to
distinguish valid from invalid principal names.