Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KrbOfferedEncryptionTypes setting isn't always respected #19126

Open
smashery opened this issue Apr 24, 2024 · 1 comment
Open

KrbOfferedEncryptionTypes setting isn't always respected #19126

smashery opened this issue Apr 24, 2024 · 1 comment
Labels

Comments

@smashery
Copy link
Contributor

The KrbOfferedEncryptionTypes setting isn't respected if there's already a "matching" ticket in the kerberos cache.

Steps to reproduce

  • Setup: clear the kerberos cache (klist -d)
  • Use a kerberos-supported module
  • Run the module with kerberos auth (should default to AES256)
  • Observe the communications in wireshark - will likely be AES256
  • Note that the kerberos cache now has tickets (klist)
  • Re-run the module, forcibly setting krbofferedencryptiontypes to RC4-HMAC
  • Observe the communications in wireshark - should be RC4-HMAC, but is actually AES256
  • Delete kerberos tickets: klist -d
  • Re-run the module, forcibly setting krbofferedencryptiontypes to RC4-HMAC
  • Observe the communications in wireshark - is now RC4-HMAC

Expected behaviour

  • If an encryption type is set that does not match tickets in the kerberos cache, it should re-request a Kerberos ticket OR warn the user about this edge case

Tested on metasploit commit: c9dfb7e

@smashery smashery added the bug label Apr 24, 2024
@smashery smashery mentioned this issue Apr 24, 2024
15 tasks
@Neustradamus
Copy link

To follow :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

2 participants