
CVE-2018-10933 - libssh Authentication Bypass
Proof-of-Concept implementation for CVE-2018-10933, a critical authentication bypass vulnerability affecting the server-side implementation of libssh.
Disclaimer
This repository is provided solely for educational purposes, vulnerability research, and authorized security testing. Never test systems without explicit permission.
CVE-2018-10933 is a critical authentication bypass vulnerability discovered in the server-side state machine of libssh.
Unlike traditional authentication flaws involving weak passwords or cryptographic weaknesses, this vulnerability exists because the server incorrectly trusts a protocol message that should only ever be sent from the server to the client.
An attacker can therefore convince a vulnerable libssh server that authentication has already completed successfully without supplying any credentials.
This allows an unauthenticated attacker to establish an authenticated SSH session against vulnerable applications using libssh in server mode.
| Field | Value |
|---|
| CVE | CVE-2018-10933 |
| Severity | Critical |
| CVSS v3 | 9.1 |
| CWE | CWE-287 (Improper Authentication) |
| Attack Vector | Network |
| User Interaction | None |
| Privileges Required | None |
The vulnerability affects libssh running in server mode.
Affected versions include:
Applications using libssh solely as an SSH client are not vulnerable.
The vulnerability originates from the authentication state machine implemented inside libssh's server code.
During a normal SSH authentication flow:
Client ----------------------> Server
SSH_MSG_USERAUTH_REQUEST
|
V
Server validates credentials
|
V
SSH_MSG_USERAUTH_SUCCESS
|
V
Authenticated Session
The protocol specifies that SSH_MSG_USERAUTH_SUCCESS is generated only by the server after successful authentication.
However, vulnerable versions of libssh fail to properly validate the origin of this message.
Instead of rejecting a client-supplied SSH_MSG_USERAUTH_SUCCESS, the server incorrectly transitions its internal authentication state directly to:
Authenticated = TRUE
without ever verifying credentials.
This is a classic example of Improper Authentication (CWE-287).
Client
|
| USERAUTH_REQUEST
|
V
Server
Validate Username
Validate Password
Validate Keys
|
V
USERAUTH_SUCCESS
Authenticated
Attacker
|
| USERAUTH_SUCCESS
|
V
Vulnerable Server
(No validation)
Authenticated
Successful exploitation allows an unauthenticated attacker to:
The actual impact depends on how the vulnerable application uses libssh after authentication.
The vulnerability exists because the authentication state machine incorrectly accepts the packet:
SSH2_MSG_USERAUTH_SUCCESS
from the client.
Instead of verifying that the packet originated from the server, libssh updates its internal session state as though authentication had completed successfully.
Because later authorization checks rely on this internal state, attackers can immediately open authenticated channels.
This vulnerability does not exploit:
Instead, it exploits a logic flaw in protocol state handling.
The attacker needs:
No:
are required.
Potential indicators include:
Network IDS signatures may also identify anomalous SSH2_MSG_USERAUTH_SUCCESS packets sent from clients.
Upgrade libssh to one of the patched releases:
If upgrading is not immediately possible:
No reliable workaround exists besides updating the affected software.
This repository demonstrates how authentication state machine vulnerabilities can arise from protocol implementation mistakes.
It is intended to assist:
The included Proof-of-Concept illustrates the vulnerability in controlled environments to improve understanding of secure protocol implementation.