Keyboard-Interactive — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/keyboard-interactive/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 03 Jul 2024 12:00:00 +0000russh Keyboard-Interactive Authentication Denial-of-Servicehttps://feed.craftedsignal.io/briefs/2024-07-03-russh-dos/Wed, 03 Jul 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-07-03-russh-dos/A denial-of-service vulnerability exists in the russh crate, where a malicious client can crash any russh-based server implementing keyboard-interactive authentication by sending a crafted SSH_MSG_USERAUTH_INFO_RESPONSE message with a large response count, leading to excessive memory allocation and an out-of-memory crash without requiring any credentials.A pre-authentication denial-of-service vulnerability exists in the russh crate, specifically affecting servers that implement keyboard-interactive authentication. This vulnerability allows a malicious client to crash a russh-based server by sending a malformed packet, without needing any valid credentials. The vulnerability resides in the read_userauth_info_response function within russh/src/server/encrypted.rs, where an unbounded u32 count from the client’s SSH_MSG_USERAUTH_INFO_RESPONSE message is used directly to allocate memory via Vec::with_capacity(). An attacker can exploit this by sending a large value for ’n’ (e.g., 0x10000000), leading to a massive memory allocation attempt and subsequent out-of-memory crash. This affects servers using keyboard-interactive for multi-step authentication such as TOTP or 2FA. The vulnerability exists in russh versions prior to 0.60.1.

Attack Chain

  1. Attacker establishes a TCP connection to the russh server.
  2. The attacker performs the initial SSH key exchange (anonymous DH handshake).
  3. The attacker sends a USERAUTH_REQUEST message with the authentication method set to keyboard-interactive.
  4. The server responds with Auth::Partial, indicating that keyboard-interactive authentication is in progress and prompts are required.
  5. The attacker sends a USERAUTH_INFO_RESPONSE message with a crafted u32 value for ’n’ set to a large number, such as 0x10000000 (268435456), indicating the number of responses.
  6. The attacker intentionally does not include any response data in the USERAUTH_INFO_RESPONSE message, to maximize the memory allocation attempt.
  7. The server attempts to allocate memory using Vec::with_capacity(n), where n is the attacker-controlled large value, triggering excessive memory allocation.
  8. The server exhausts available memory, leading to an out-of-memory (OOM) condition, and the server process crashes, causing a denial of service.

Impact

A successful attack results in a denial of service, crashing the russh server and affecting all active SSH sessions. Because the attack occurs before authentication, it can be executed repeatedly and quickly, preventing legitimate users from accessing the server. This can disrupt services relying on the SSH server, leading to downtime and potential data loss. An end-to-end Proof of Concept demonstrates that a russh server within a container with a 512MB memory limit can be OOM-killed by this vulnerability.

Recommendation

  • Upgrade to russh version 0.60.1 or later to incorporate the fix that limits the Vec::with_capacity allocation based on the remaining packet data.
  • Monitor network traffic for SSH USERAUTH_INFO_RESPONSE messages with unusually large response counts using the provided Sigma rule “Detect Excessive SSH Keyboard-Interactive Responses”.
  • Implement rate limiting or connection limits to mitigate the impact of rapid connection attempts from malicious clients.
  • Review and audit implementations of Handler::auth_keyboard_interactive to ensure proper input validation and resource management, especially where Auth::Partial is returned.
]]>mediumadvisorydenial-of-servicerusshkeyboard-interactive