blocks|key|1354136|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

TL;DR - You can trivially brute-force the DES keys used in the challenge/response mechanism. In order to reverse the challenge/response mechanism you only have to brute-force two DES iterations that have a 56-bit key.
In order to obtain the NT hash, you will need to concatenate the challenge &amp; the first two-thirds of your response and K3 as Base64.
<hr />
NTLM is a <a href="https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication" rel="nofollow noreferrer">challenge-response authentication protocol</a> essentially what this means is, one party will present a challenge and the other party must provide a valid response - if this doesn't happen then authentication will not take place.
A good way of picturing this would be a security question - imagine if to unlock your account you had to provide the correct answer to the following security question; What was the name of your childhood pet? While this is not exactly what this would look like it's a nice way of picturing it.
<hr />
High-Level Overview
NTLM has three messages to authenticate a client, these messages are defined in the following Microsoft document <a href="https://msdn.microsoft.com/en-us/library/cc236640.aspx" rel="nofollow noreferrer">NTLM Messages</a>
<ul>
<li><code>NEGOTIATE_MESSAGE</code></li>
<li><code>CHALLENGE_MESSAGE</code></li>
<li><code>AUTHENTICATE_MESSAGE</code></li>
</ul>
These messages are sent in the order they are listed in, we will change the notation of these messages to be <code>NM</code>, <code>CM</code> and <code>AM</code>.
Firstly the client will send the <code>NM</code> to the server this will allow the client to inform the server what NTLM options it supports, upon negotiating this the server will then send a <code>CM</code> to the client. The idea behind the <code>CM</code> is so that the client can prove it's identity to the server. Finally, the client will send an <code>AM</code> back to the server after the <code>CM</code> has been processed by the client.
<hr />
Hashing
NTLM uses two hashed passwords which are stored on the server and while they are salted before they are sent over the wire they are not salted in the machine's memory, this is an issue because if you obtain the hash value from the server you can use it to authenticate without even needing the password.
The first hash is known as the <code>LM</code> and the other is known as the <code>NT</code>. The LM uses a DES-Based function and the <code>NT</code> uses MD4.
LM
The <a href="https://i.stack.imgur.com/hZwxv.png" rel="nofollow noreferrer">linked diagram</a> shows how the <code>LM</code> hash is calculated using the example of &quot;napier&quot; alternatively the below steps follows the same premise.
<ol>
<li>Convert user's password to uppercase, then pad the provided password up to 14 bytes using NULL-padding</li>
<li>Split the 14 byte password into two 7-byte halves</li>
<li>Create two 64-bit DES keys using the 7-byte halves (with the addition of a parity bit for every seven bits)</li>
<li>Each key is used to encrypt the string <code>KGS!+#$%</code> which returns two 8-byte cipher values.</li>
<li>The resulting two values are concatenated to give a 16-byte hash.</li>
</ol>
It is not certain why &quot;KGS!+#$%&quot; is chosen however as per the below on the <a href="https://en.wikipedia.org/wiki/LAN_Manager" rel="nofollow noreferrer">LAN Manager</a> Wikipedia page it would seem the reason is related to the writers of <a href="https://www.rfc-editor.org/rfc/rfc2433" rel="nofollow noreferrer">RFC 2443</a>.
<blockquote>
The string “KGS!+#$%” could possibly mean Key of Glen and Steve and then the combination of Shift + 12345. Glen Zorn and Steve Cobb are the authors of RFC 2433 (Microsoft PPP CHAP Extensions). - <a href="https://en.wikipedia.org/wiki/LAN_Manager#cite_note-8" rel="nofollow noreferrer">LAN Manager Note 2.</a>
</blockquote>
NT
With the NT hash each character is converted into UTF-16 and uses a <a href="https://en.wikipedia.org/wiki/Endianness" rel="nofollow noreferrer">Little Endian</a> format, I am not going to go into detail about Endianness here so, unfortunately, it will require research if you're unsure of what that means.
Lets look at another diagram using the &quot;napier&quot; example again in the following <a href="https://asecuritysite.com/public/ntlm.png" rel="nofollow noreferrer">diagram</a> you can see we take the word napier and after every character we have a null-byte for example &quot;napier&quot; becomes <code>'n' 0 'a' 0 'p' 0 'i' 0 'e' 0 'r' 0</code> as shown in the linked diagram, this is the result of encoding &quot;napier&quot; with UTF-16-LE. Then we use an MD4 signature taken from the string which returns a 128-bit code that in our example would be <code>307E40814E7D4E103F6A69B04EA78F3D</code> you can try this out yourself using this <a href="https://asecuritysite.com/encryption/md2" rel="nofollow noreferrer">MD2/MD4 encryption site</a>. In essence, the function would look like this to get the NT hash: <code>MD4(UTF-16-LE(password))</code>
<hr />
Low-Level Overview
Now that we have discussed the hashing and a high-level overview of the challenge/response authentication method we will look at the low-level overview of how this works.
Both of the hashes above produce a 16-byte value, 5-bytes of 0s are appended to reach 21-bytes. Those 21 bytes are separated into three 7-byte values. Each 7-byte value is used as a key to DES encrypt the 8-byte challenge we send to the client. The three encryptions are then used to form the 24-byte response.
<ol>
<li>The server will authenticate by sending an 8-byte random number
known as the challenge. (See above)</li>
<li>The client will perform an operation involving the challenge and a
secret which is shared between the client and the server, this secret will be one of the two password hashes we described previously.</li>
<li>The client then returns a 24-byte result from the computation. It's
typical in NTLMV1 that both hashes will be used for the computation and thus both 24-byte results are sent back.</li>
<li>The server will then verify that the client has computed the correct
result, if they have the server will infer possession of the secret
and hence the client's authenticity.</li>
</ol>
In essence, the below code-block shows how the steps performed look with the mathematical notation.
<pre><code>C = 8-byte server challenge, random
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
Response = DES(K1,C) | DES(K2,C) | DES(K3,C)
</code></pre>
<hr />
Hashing/Encryption weaknesses
NTLM is a very old protocol - usually, older protocols don't survive (if there are issues with them). NTLM is one of those older protocols that didn't survive the test of time. Firstly the functions that are used are too weak/cheap for modern day hardware.
Let's look at DES, DES was first published in 1975, it's a very old protocol, one of the main issues with DES is how weak it is against brute-force attacks, especially in the modern age. In fact as per <a href="https://crypto.stackexchange.com/questions/43544/des-strength-and-weakness">DES Strengths and Weaknesses</a> it would seem that even in 1977 with enough money it would be possible to brute-force DES.
<blockquote>
In 1977, Diffie and Hellman proposed a machine costing an estimated US$20 million which could find a DES key in a single day.
So it is arguable that DES was never strong against brute force
attacks (the standardized post-NSA consultation version anyways -
originally the designers did propose a &quot;real&quot; key size).
</blockquote>
If you're wondering about the maths behind how long it would take to find a DES key compared to an AES key see: <a href="https://crypto.stackexchange.com/questions/752/how-long-does-it-take-to-crack-des-and-aes">How long does it take to crack DES and AES?</a>, the top answer clearly presents the length of time it would take, just be aware post is from '11, things do change and so does computing power so that is something to factor in, see that answer as a guideline rather than an exact figure.
In essence, the time it would take to brute-force a DES key (especially with today's computing) is way too short for it to be considered up to the modern standards and thus it's become obsolete.
<hr />
What about MD4? Let's take a look at Message Digest 4. As you may be aware we now have MD5 which like MD4 is still pretty weak for things such as password-hashing due to its speed.
Whilst MD4 is a relatively &quot;new&quot; hashing function, it is still weak. It was first published in 1990 by <a href="https://en.wikipedia.org/wiki/Ron_Rivest" rel="nofollow noreferrer">Ronald Rivest</a> who is incredibly well-versed in Cryptography and well-known to Cryptographers.
MD4's problem (and MD5's in-fact) is how cheap it is to compute collisions; in short, a collision is where a function maps two distinct inputs to the same output, a collision-attack describes the process of attempting to find two inputs that produce the same output. Computing collisions in MD4 is really fast &amp; incredibly cheap. In-fact there was a <a href="https://www.iacr.org/archive/fse2007/45930331/45930331.pdf" rel="nofollow noreferrer">collision attack published in 2007</a> that could find a collision in less than two hash operations.
<hr />
Other Weaknesses
One distinct issue is the ability to perform a relay attack fairly trivially see: <a href="https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html" rel="nofollow noreferrer">Practical guide to NTLM Relaying</a>
I won't go into it here for the sake of post length however the above linked should have more than sufficient detail.
<hr />
Weaknesses in MSCHAPV2
As for weaknesses in MS-CHAPV2, in step four of the process because the NT hash is not salted as an attacker you can reuse it, this means the NTHash is used as the password, meaning that we can use it to authenticate as the user; to add to that we can also impersonate the AS and authenticate the user. Because there is no salt being used this allows us to use rainbow tables.
Another blatant issue is in step six where you can easily perform a brute-force attack on each key fairly trivially see: <a href="https://www.cs.ru.nl/bachelorscripties/2016/Matthias_Ghering___4395727___Evil_Twin_Vulnerabilities_in_Wi-Fi_Networks.pdf" rel="nofollow noreferrer">Evil Twin Vulnerabilities in Wi-Fi Networks</a>
<hr />
Further Reading
<a href="https://en.wikipedia.org/wiki/MD4" rel="nofollow noreferrer">MD4</a>
<a href="http://cs-exhibitions.uni-klu.ac.at/index.php?id=263" rel="nofollow noreferrer">DES Challenges</a>
<a href="https://en.wikipedia.org/wiki/Data_Encryption_Standard" rel="nofollow noreferrer">DES</a>
<a href="https://asecuritysite.com/encryption/lmhash" rel="nofollow noreferrer">NT &amp; LM Hash</a>
<a href="https://blogs.technet.microsoft.com/miriamxyra/2017/11/07/stop-using-lan-manager-and-ntlmv1/" rel="nofollow noreferrer">Stop using NTLMV1</a>
<a href="https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4" rel="nofollow noreferrer">LM, NTLM, Net-NTLMv2, oh my!</a>

I'm trying to understand the dynamics of the authentication process in the MS-CHAPV2 protocol. In particular, if I implement an <a href="https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)" rel="nofollow noreferrer">Evil Twin attack</a> I can't understand how it's possible that I can retrieve the NTLM v1 password. From the implementation of the MS-CHAPV2, it seems it is not possible.

This is the context: A hacker sets his notebook to perform an Evil Twin attack on a WPA2-Enterprise network. He will impersonate the correct Access Point and the correct Authentication Server, waiting for some clients to connect to his notebook in order to steal their credentials and to impersonate them in the enterprise network.

The network uses MS-CHAPV2 as the inner authentication protocol.

When the client starts the EAPOL process to access to this fake network, we arrive at the inner authentication process (of the client at the server):

<a href="https://i.stack.imgur.com/Iu8Bi.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/Iu8Bi.jpg" alt="enter image description here"></a>

This process follows these steps:

<ol>
<li>The client starts the protocol with a “hello" message.</li>
<li>The authentication server answers with a 16 Byte ServerChallenge.</li>
<li>The client combines the ServerChallenge, a 16 Byte random ClientChallenge, and the username to create the ChallengeHash.</li>
<li>The client then calculates the NTHash which is the MD4 hash of the user’s password and pads this with zeros to 21 bytes.</li>
<li>Client splits the 21 Byte long NTHash in three 7 Byte long DES keys. A parity bit is added to each 7 bits to create a 8 Byte long DES key.</li>
<li>Each key is used to encrypt the ChallengeHash. The concatenation of these three ChallengeHashes forms the ChallengeResponse.</li>
<li>The 24 Byte ChallengeResponse, 16 Byte ChallengeHash and the UserName is sent to the AS.</li>
<li>The AS has to answer with an AuthenticationResponse which uses the md4 hash of the md4 hash of the user’s password combined with the ChallengeResponse sent by the user, two constant sentences and the ChallengeHash. This message is sent to verify that the server knows the password as well.</li>
</ol>

As an attacker, I can see all the information received by the client and all the information sent by the server. However, if the client uses the "MD4(UserPassword)" string as a key to encrypt the 3 different parts of the challenge response (see point 5), how can it be possible that I can obtain this MD4 password?

Why could I obtain, in my testing process, something like this (NTLMV1 hash)?
(I'm using <code>hostapd-wpe</code>)

<a href="https://i.stack.imgur.com/6gxgC.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/6gxgC.jpg" alt="enter image description here"></a>

MsChapV2 authentication and Evil Twin attack

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我试图了解MS 2协议中身份验证过程的动态。特别是，如果我实现了一个邪恶双击这就是背景:黑客将他的笔记本设置为在WPA2-Enterprise网络上执行邪恶的双重攻击。他将模拟正确的接入点和正确的身份验证服务器，等待一些客户端连接到他的笔记本，以便窃取他们的凭据并在企业网络中模拟他们。网络采用MS 2作为内部认证协议.当客户端启动EAPOL进程访问这个假网络时，我们到达内部身份验证进程(服务器上的

MsChapV2认证与邪恶双重攻击-腾讯云开发者社区-腾讯云

问MsChapV2认证与邪恶双重攻击
EN

回答 1

Security用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问MsChapV2认证与邪恶双重攻击EN