If you run a client like kinit and ask for a principal with
REQUIRES_PRE_AUTH and a disabled/pw_expired/locked-out state, or request
a principal that doesn't exist, you aren't asked for a password and get
an immediate response with the status of the account. Is there a way to avoid this behavior? People have created hacking toolkits that try
every possible username to download the list of usernames in the
database and their state.
I know pre-auth is a special case where you'd need to provide a
plausible challenge for non-existent accounts. But is there maybe a
setting to treat unknown principals as if they had pre-auth disabled,
request a password, and just send back invalid password / encryption
failed no matter what?
We were trying to implement an authentication proxy module that uses Kerberos, and we wanted to only disclose an account was disabled if the
user typed in the correct password. But the only case we could make
work was if the account was expired (different from pw_expired).
--
Eric Hattemer
Engineer
Identity and Access Management
________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
On Tue, Jun 30, 2020 at 23:01 Eric Hattemer <ehatteme@usc.edu> wrote:
If you run a client like kinit and ask for a principal with
REQUIRES_PRE_AUTH and a disabled/pw_expired/locked-out state, or
request a principal that doesn't exist, you aren't asked for a
password and get an immediate response with the status of the
account. Is there a way to avoid this behavior? People have created
hacking toolkits that try every possible username to download the
list of usernames in the database and their state.
I know pre-auth is a special case where you'd need to provide a
plausible challenge for non-existent accounts. But is there maybe a
setting to treat unknown principals as if they had pre-auth disabled,
request a password, and just send back invalid password / encryption
failed no matter what?
We were trying to implement an authentication proxy module that uses
Kerberos, and we wanted to only disclose an account was disabled if
the user typed in the correct password. But the only case we could
make work was if the account was expired (different from pw_expired).
There are actually a bunch of places that leak information about valid princs, I wonder if there’s a todo item to clean those up at some
point? I can’t remember the one or two I found since it was a while
ago but I posted it to the list as well.
For example, if we treated single-component principals as users,anyone with a user/admin principal (or user/root, which has no status in
On 7/1/20 1:53 AM, Eric Hattemer wrote:
I know pre-auth is a special case where you'd need to provide a
plausible challenge for non-existent accounts. But is there maybe a setting to treat unknown principals as if they had pre-auth disabled, request a password, and just send back invalid password / encryption
failed no matter what?
We don't have a setting like that. The closest nod we have in the code
to this desire is a "vague errors" setting for the KDC, which can only
be turned on at compile time (or via ptrace, I guess) and causes the KDC
to yield generic errors instead of useful ones. But that setting still allows an attacker to easily distinguish between "client principal
requires preauth" and "client principal not found".
Because the Kerberos principal namespace isn't formally divided between
users and services, any obscurity feature would probably have some edge cases. 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. ________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
I know pre-auth is a special case where you'd need to provide a
plausible challenge for non-existent accounts. But is there maybe a
setting to treat unknown principals as if they had pre-auth disabled,
request a password, and just send back invalid password / encryption
failed no matter what?
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?
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 53:39:33 |
| Calls: | 6,650 |
| Calls today: | 2 |
| Files: | 12,200 |
| Messages: | 5,330,494 |