-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Fix LM hash computation #1626
Fix LM hash computation #1626
Conversation
1f5c35a
to
318becb
Compare
This also fixes issues with the Related issues: |
hello, I've been checking the current cumpute lm hash implementation Line 742 in 9b4a139
Line 744 in 9b4a139
The code in this PR it's a workaround that makes impacket avoid crashing at the time of interpreting the password string. Bear in mind that LM hash is not even checked in the remote server, in most of the windows versions. So, I would say that, for now, for those invalid characters in the context of LM hashing, compute the fixed value 385359f4ebcc247b57a2ab140e714cd1 which is the standard value for LM hashes in most of the scenarios. The current algorithm should eventually (?) be tested against a target that enforces LM hash authentication though. |
I'll create a PR with this fix |
just created #1723 . If somebody could give it a go, it would be awesome |
Gonna try and test it later👍🏼 |
Honestly i can't get LM authentication to work based on only the LM Hash (Screenshot based on #1626): So neither with #1626 nor with #1723 i can get LM auth to be working (besides the fact that the DC does not store the LM hash if special characters are used). As this is an extrem edge case and both PRs are preventing normal password authentication from crashing either way is fine imo. |
@NeffIsBack interesting, from what I tested hashes for passwords with standard characters are correctly calculated in all versions. Differences appear when 'special characters' are processed. On the other hand looking at some implementations, they don't seem to be honoring the original specs https://doxygen.reactos.org/de/d62/dll_2win32_2advapi32_2wine_2crypt__lmhash_8c.html#a2801598865913a98bf3cfb0c2f5edf03 , https://github.com/dchest/historic-password-hashes/blob/master/winnt-owf.c , which makes all a bit more confusing. |
closing this one in favor of #1723. Thanks! |
For some reason, when performing NTLM connection, impacket always compute the LM hash of the provided password. However, this operation fails when using special characters ('µ') for example:
The documentation in the code states that it follows the RFC (https://datatracker.ietf.org/doc/rfc2433/). However, this RFC does not state how to handle special characters.
Google did not came up with anything related for handling these characters. However, I found an online LM hash calculator (https://tobtu.com/lmntlm.php) that calculated the same LM hash value that a Windows computer.
The JavaScript code of this website was converted for impacket.