You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -5,59 +5,187 @@ Affected Software: Microsoft Telnet Server (Windows 2000 to Windows Server 2008
5
5
Severity: Low (Non-Exploitable)
6
6
CVE ID: None Assigned
7
7
Vendor: Microsoft Corporation
8
-
Status: Unpatched, non-exploitable.
8
+
Status: Unpatched, non-exploitable.
9
9
10
10
Summary
11
11
=======
12
-
The Microsoft Telnet Server’s NTLM authentication over MS-TNAP uses SECPKG_CRED_BOTH in AcquireCredentialsHandle and ASC_REQ_MUTUAL_AUTH/ASC_REQ_DELEGATE in AcceptSecurityContext. These settings suggest a potential vulnerability where an attacker could invert authentication, forcing the server to authenticate to the client. Testing with a modified PoC tool (telnet_token.exe, based on updated netio.c and security.c) alongside auditing of the server behaviors has confirmed the issue is not exploitable. The server never initiates authentication with an NTLM Type 1 message, rendering these flags ineffective for exploitation uses by the client. Administrators should disable Telnet due to its plaintext transmission, but no specific action is required for this issue. The server implementation should, however, explicitly specify SECPKG_CRED_INBOUND and not support ASC_REQ_MUTUAL and ASC_REQ_DELEGATE if mutual authentication is not required.
12
+
The Microsoft Telnet Server’s NTLM authentication over MS-TNAP uses
13
+
SECPKG_CRED_BOTH in AcquireCredentialsHandle and ASC_REQ_MUTUAL_AUTH/ASC_REQ_DELEGATE in
14
+
AcceptSecurityContext. These settings suggest a potential vulnerability where an attacker
15
+
could invert authentication, forcing the server to authenticate to the client. Testing
16
+
with a modified telnet client (telnet_token.exe, based on updated netio.c and security.c)
17
+
alongside auditing of the server behaviors has confirmed the issue is not exploitable. The
18
+
server never initiates authentication with an NTLM Type 1 message, rendering these flags
19
+
ineffective for exploitation uses by the client. Administrators should disable
20
+
Telnet due to its plaintext transmission, but no specific action is required for
21
+
this issue. The server implementation should, however, explicitly specify
22
+
SECPKG_CRED_INBOUND and not support ASC_REQ_MUTUAL and ASC_REQ_DELEGATE if mutual
23
+
authentication is not required.
13
24
14
25
Technical Details
15
26
=================
16
27
The server’s SSPI implementation includes:
17
28
18
-
- SECPKG_CRED_BOTH in AcquireCredentialsHandle: Allows the server to act as both authenticator and authenticatee, unexpected for a server role.
19
-
- ASC_REQ_MUTUAL_AUTH and ASC_REQ_DELEGATE in AcceptSecurityContext: Supports mutual authentication and credential delegation, potentially enabling an authentication bypass.
29
+
- SECPKG_CRED_BOTH in AcquireCredentialsHandle: Allows the server to act as both
30
+
authenticator and authenticatee, unexpected for a server role.
31
+
- ASC_REQ_MUTUAL_AUTH and ASC_REQ_DELEGATE in AcceptSecurityContext: Supports
32
+
mutual authentication and credential delegation, potentially enabling an
33
+
authentication bypass.
20
34
21
-
A practical attack would require the server to send a Type 1 (NEGOTIATE) message, allowing the client to process server credentials via AcceptSecurityContext. We updated security.c in a telnet client and attempted this by using SECPKG_CRED_INBOUND and AcceptSecurityContext to handle a server Type 1 message whilst sending the MS-TNAP direction flags AUTH_SERVER_TO_CLIENT | AUTH_HOW_MUTUAL. The server ignores these flags and it appears Telnet mutual authentication was a feature that Microsoft abandoned during development.
35
+
A practical attack would require the server to send a Type 1 (NEGOTIATE) message,
36
+
allowing the client to process server credentials via AcceptSecurityContext. We
37
+
updated security.c in a telnet client and attempted this by using
38
+
SECPKG_CRED_INBOUND and AcceptSecurityContext to handle a server Type 1 message
39
+
whilst sending the MS-TNAP direction flags AUTH_SERVER_TO_CLIENT |
40
+
AUTH_HOW_MUTUAL. The server ignores these flags and it appears Telnet mutual
41
+
authentication was a feature that Microsoft abandoned during development.
22
42
23
43
PoC Testing
24
44
===========
25
-
The PoC tool (telnet_token.exe), built using a modified netio.c and security.c to exploit the logic flaws and establish mutual authentication was developed and tested against a Windows Server 2008 R2 Telnet Server. Key findings:
45
+
The PoC tool (telnet_token.exe), built using a modified netio.c and security.c to
46
+
exploit the logic flaws and establish mutual authentication was developed and
47
+
tested against a Windows Server 2008 R2 Telnet Server. Key findings:
26
48
27
-
- Standard Flow: The client sent a Type 1 message with AUTH_SERVER_TO_CLIENT | AUTH_HOW_MUTUAL. The server responded with a Type 2 (CHALLENGE) message, using AUTH_HOW_ONE_WAY | AUTH_CLIENT_TO_SERVER, ignoring the mutual authentication request. No server authentication data was included.
28
-
- Reversed Authentication: Using SECPKG_CRED_INBOUND and AcceptSecurityContext caused a crash with SEC_E_INVALID_TOKEN (0x80090308) when processing the server’s Type 2 message, as it was not a valid input token for AcceptSecurityContext. The server never sent a Type 1 message.
29
-
- Type 2 Analysis: The Type 2 message contained standard NTLM fields (challenge, target name, flags: 0xe28a8215) with no server authentication token, adhering to RFC 4559. Our PoC tool will output any server token that maybe sent by a Type 2 message in the event the servers Type 1 requests for mutual authentication are used. However NTLMSSP only includes authentication material and cryptographic data in a type 3 message making this issue non-exploitable.
49
+
- Standard Flow: The client sent a Type 1 message with
50
+
AUTH_SERVER_TO_CLIENT | AUTH_HOW_MUTUAL. The server responded with a Type 2
51
+
(CHALLENGE) message, using AUTH_HOW_ONE_WAY | AUTH_CLIENT_TO_SERVER, ignoring
52
+
the mutual authentication request. No server authentication data was included.
53
+
- Reversed Authentication: Using SECPKG_CRED_INBOUND and AcceptSecurityContext
54
+
caused a crash with SEC_E_INVALID_TOKEN (0x80090308) when processing the
55
+
server’s Type 2 message, as it was not a valid input token for
56
+
AcceptSecurityContext. The server never sent a Type 1 message.
57
+
- Type 2 Analysis: The Type 2 message contained standard NTLM fields (challenge,
58
+
target name, flags: 0xe28a8215) with no server authentication token, adhering to
59
+
RFC 4559. Our PoC tool will output any server token that maybe sent by a Type 2
60
+
message in the event the servers Type 1 requests for mutual authentication are
61
+
used. However NTLMSSP only includes authentication material and cryptographic
62
+
data in a type 3 message making this issue non-exploitable.
30
63
31
64
Why It’s Not Exploitable
32
65
========================
33
-
- Fixed Server Role: The server exclusively only acts as an NTLM authenticator, sending Type 2 messages and never initiating with Type 1. SECPKG_CRED_BOTH is unused even when sending the appropriate flags in the client.
- No Server Credentials: Type 2 messages lack authentication data, and mutual authentication occurs only in the client’s Type 3 response, which the server verifies.
66
+
- Fixed Server Role: The server exclusively only acts as an NTLM authenticator,
67
+
sending Type 2 messages and never initiating with Type 1. SECPKG_CRED_BOTH is
68
+
unused even when sending the appropriate flags in the client.
69
+
- Protocol Limitation: MS-TNAP ignores AUTH_SERVER_TO_CLIENT and AUTH_HOW_MUTUAL,
- No Server Credentials: Type 2 messages lack authentication data, and mutual
72
+
authentication occurs only in the client’s Type 3 response, which the server
73
+
verifies.
36
74
37
75
Impact
38
76
======
39
-
None. The configuration does not expose credentials, tokens, allow bypass, or weaken NTLM authentication. A separate vulnerability that allows for Guest access restriction bypass through MS-TNAP is described elsewhere in this repo.
77
+
None. The configuration does not expose credentials, tokens, allow bypass, or
78
+
weaken NTLM authentication. A separate vulnerability that allows for Guest access
79
+
restriction bypass through MS-TNAP is described elsewhere in this repo.
40
80
41
81
Mitigation
42
82
==========
43
83
- No Patch Needed: The issue is not exploitable.
44
84
- Disable Telnet: Use SSH to avoid Telnet’s plaintext transmission.
45
-
- Monitor Updates: Re-evaluate if future server changes enable Type 1 message initiation.
85
+
- Monitor Updates: Re-evaluate if future server changes enable Type 1 message
86
+
initiation.
46
87
47
-
PoC Tool
48
-
========
49
-
A telnet_token.exe is encoded in this file (built from updated netio.c and security.c):
88
+
Testing
89
+
=======
90
+
A telnet_token.exe is encoded in this file (built from patched netio.c and
91
+
security.c) which can be used to inspect telnet traffic and verify the server
92
+
behavior:
50
93
51
-
- Functionality: Parses NTLM messages, attempts reversed authentication with SECPKG_CRED_INBOUND, and dumps message details.
94
+
- Functionality: Parses NTLM messages, attempts reversed authentication with
95
+
SECPKG_CRED_INBOUND, and dumps message details.
52
96
- Usage: telnet_token.exe <ip> <port>
53
-
- Output: Displays hex dumps, flags (e.g., NEGOTIATE_EXTENDED_SESSIONSECURITY), and fields (e.g., target name). Exits with SEC_E_INVALID_TOKEN on reversed authentication attempts.
97
+
- Output: Displays hex dumps, flags (e.g., NEGOTIATE_EXTENDED_SESSIONSECURITY), and
98
+
fields (e.g., target name). Exits with SEC_E_INVALID_TOKEN on reversed
99
+
authentication attempts.
100
+
101
+
The tool is designed to print any authentication token it receives from the server
102
+
in a type 2 response when forcing mutual authentication, however these are only
103
+
expected to be sent in type 3 messages, should you find a token with this tool - it
104
+
is likely due to a modified NTLMSSP implementation.
The NTLM configuration issue in the Microsoft Telnet Server stems from the intended support for mutual authentication within the MS-TNAP protocol and the server’s SSPI configuration, specifically the use of SECPKG_CRED_BOTH and ASC_REQ_MUTUAL_AUTH flags. These settings suggest the server could act as an authenticatee, initiating authentication with a Type 1 message, which could allow an attacker to invert the authentication flow. However, this vulnerability is not exploitable due to explicit server-side logic that ignores the AUTH_SERVER_TO_CLIENT and AUTH_HOW_MUTUAL flags in MS-TNAP, enforcing a client-driven authentication model. The server’s implementation lacks the necessary code to handle these flags or send a Type 1 message, effectively abandoning mutual authentication functionality during development. As a result, the server remains strictly an NTLM authenticator, rendering the configuration a non-exploitable oddity. Administrators should disable Telnet for general security due to its inherent weaknesses, but no specific action is required for this issue.
175
+
The NTLM configuration issue in the Microsoft Telnet Server stems from the intended
176
+
support for mutual authentication within the MS-TNAP protocol and the server’s SSPI
177
+
configuration, specifically the use of SECPKG_CRED_BOTH and ASC_REQ_MUTUAL_AUTH
178
+
flags. These settings suggest the server could act as an authenticatee, initiating
179
+
authentication with a Type 1 message, which could allow an attacker to invert the
180
+
authentication flow. However, this vulnerability is not exploitable due to explicit
181
+
server-side logic that ignores the AUTH_SERVER_TO_CLIENT and AUTH_HOW_MUTUAL flags
182
+
in MS-TNAP, enforcing a client-driven authentication model. The server’s
183
+
implementation lacks the necessary code to handle these flags or send a Type 1
184
+
message, effectively abandoning mutual authentication functionality during
185
+
development. As a result, the server remains strictly an NTLM authenticator,
186
+
rendering the configuration a non-exploitable oddity. Administrators should disable
187
+
Telnet for general security due to its inherent weaknesses, but no specific action
188
+
is required for this issue.
61
189
62
190
Disclosure Timeline
63
191
===================
@@ -70,8 +198,8 @@ Credits
70
198
=======
71
199
Discovered by Hacker Fantastic (https://hacker.house)
0 commit comments