Fix challenge_hash when user starts with "domain\"

[Rogdham]

Some clients (e.g. with Windows) send domain\username as the user, but do the computations for the challenge/response with username only.

In freeradius, that was solved with the directive with_ntdomain_hack = yes.

Here, I did not see any directive that looks like it.

---

As a result, we obtain wrong NETNTLM output. For example, with domain abc, username def and password qwerty:

• Before the patch: NETNTLM: abc\def:$NETNTLM$b081024eca01be3f$ca96218159d29a8443506fc2b5e1a86e41eec71f7abe8119;
• After the patch: NETNTLM: abc\def:$NETNTLM$b71e3c37cd629d7d$dac787f9f3f721bb7a985c2f92f262c1668653f140f443c4.

There is no way to break the first one, the second one is found within seconds with John the Ripper.

---

I have a few questions though:

• Could it be possible that some clients do use the domain\ part to compute the challenge-response? In other words, will this patch will not work with those clients?
• If so, would it make sense to let the choice to the user, as a configuration option in hostapd-wpe.conf?

---

Finally, the code diff in this PR is quite simple, but as we see a diff of a diff, it starts to look confusing.

[phymod0]

Maybe add options for both hashes in the .conf? (log both if both options are set)

[Rogdham]

Maybe add options for both hashes in the .conf? (log both if both options are set)

That could be a possibility. However, I have yet to see a client which use the full domain\username as the user. If you have some in mind, please share!

[phymod0]

In RFC 2759 under section 4:

"When computing the NT-Response field contents, only the user name is used, without any associated Windows NT domain name. This is true regardless of whether a Windows NT domain name is present in the Name field..."

So I guess we can safely assume that no device should use the domain name?

[Rogdham]

Well done with the RFC pointer!

So I guess we can safely assume that no device should use the domain name?

I agree. So there is no need to have an option to log the non-RFC-compliant one, unless someone finds a client which uses the full domain\username as the user.

[phymod0]

So I wasn't aware that some devices may not comply to RFC standards. Sorry. What do you suggest in case some devices do use the domain to compute the hashes?

[Lexus89]

I have encountered a device where the domain was also used, i was able to crack the hash with FreeRADIUS-WPE and ntdomain hack, but not with HostAPD-WPE, which resulted in a different hash.

Since there does not seem to be any activity here from the author, perhaps a fork with these changes + the other pending pull requests would be a good idea?

[Rogdham]

I have encountered a device where the domain was also used, i was able to crack the hash with FreeRADIUS-WPE and ntdomain hack, but not with HostAPD-WPE, which resulted in a different hash.

Sorry, I am not sure I understand your message perfectly. Did you find a device which uses the domain to compute the challenge? If possible, could you share the following:

• The output of hostapd-wpe for such a challenge-response;
• The corresponding password (if you still have access to the device, try using something easy like 1234 as the password);
• The name and model of the device?

Since there does not seem to be any activity here from the author, perhaps a fork with these changes + the other pending pull requests would be a good idea?

I would recommend to go and look at mana, and more specifically at hostapd-mana. It seems that the pull request has been merged there (although incorrectly, I just made a pull request on their repo to fix it), and the project is maintained.

[Lexus89]

No you are right, i was mistaken and i indeed meant the opposite: your fix should indeed be enough, just the username is used and NOT the domain. I know about mana but never tried it before, i'll give it a better look and thnx alot for your fix!

[Rogdham]

No you are right, i was mistaken and i indeed meant the opposite: your fix should indeed be enough, just the username is used and NOT the domain.

That's good to hear, I was afraid that you found one device that behaved differently, and that we needed to handle that case as well.

I know about mana but never tried it before, i'll give it a better look

Same, I've just tried it a few days ago, seems to be the way to go now :-)

I also like the fact that they have different repositories, so you don't have to clone everything, you can just use hostapd-mona if you want!

and thnx alot for your fix!

It was really not much to code, the hardest part was to identify where the problem came from!

[Rogdham]

It seems that the pull request has been merged there (although incorrectly, I just made a pull request on their repo to fix it), and the project is maintained.

I can confirm that the mana project is well maintained: my pull request was merged within 24h 👍

[Lexus89]

@Rogdham I saw it indeed, thnx for the notification anyway. I'll be playing with it.

I can't seem to find some form of output file for hashes grabbed. It loads them off to the cracker directly and only if cracked then added to the eap user file. Cannot seem to find a parameter such as wpe_logfile= to regular cred logging. E.g.

[mschapv2]
...
[eap-md5]
...

etc. Did i miss something or would this indeed be a handy enhancement?

[Rogdham]

Rebased on current master for hostapd 2.6.

Fixes #19.

[Rogdham]

@brad-anton: could you give this PR a look?

[brad-anton]

thanks for the nudge @Rogdham!

[Rogdham]

Haha, my pleasure @brad-anton! Could you close #19 while you are at it?

[ama21n]

Hi folks,

Im seeing this issue again, perhaps a client update issue, as I my build has not changed. Comments under #19

Cheers - Rob