In this long-read post, we will discuss a critical security vulnerability present in JumpServer until recently, an open-source bastion host. The vulnerability, identified as CVE-2023-43652, could enable an attacker to authenticate to JumpServer's core API simply with a username and an SSH public key, bypassing the need for a password or the corresponding SSH private key. We will look into the exploit details and urge users to upgrade to versions 2.28.20 and 3.7.1 as these have already addressed the underlying problem.

JumpServer Overview

JumpServer is an open-source bastion host designed to help organizations manage their secure SSH access. It acts as an additional layer of security allowing users to authenticate and access remote servers without exposing their internal infrastructure directly to the outside world. JumpServer's official GitHub repository can be found here.

Code Snippet and Vulnerability Details

The issue lies in JumpServer's implementation of the API for the KoKo component. KoKo is responsible for validating user private key logins, and the authentication happens through an API that does not verify the source of requests, generating a personal authentication token in the process.

Below is a code snippet illustrating the problem

def authenticate(request):
    '''
    KoKo component user authentication
    '''
    public_key = request.data.get("public_key")
    username = request.data.get("username")

    user = authenticate(username=username, public_key=public_key)

    if user:
        token = generate_auth_token(user)
        return Response({"token": token})
    else:
        return Response(status=401)

As evident from the code, the authentication process does not implement any validation measures for verifying the request source, making it susceptible to attacks involving leaked public keys.

SSH public keys should never be considered as secure authentication secrets on their own, given that they are deemed public knowledge. After all, public keys are designed to be shared openly, while private keys remain confidential. However, due to the lax security measures in place, an attacker could exploit the leaked public key and username to authenticate and access the user's information and authorized actions.

[1] JumpServer GitHub Repository: https://github.com/jumpserver/jumpserver
[2] CVE-2023-43652 Advisory: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-43652
[3] JumpServer Version 2.28.20 Release Notes: https://docs.jumpserver.org/en-US/docs/releases/2_28_20.html
[4] JumpServer Version 3.7.1 Release Notes: https://docs.jumpserver.org/en-US/docs/releases/3_7_1.html

Mitigation and Workarounds

This vulnerability was addressed in JumpServer versions 2.28.20 and 3.7.1, where the authentication process was revised to eliminate the risk. Users are strongly advised to upgrade their JumpServer instances to the aforementioned versions or later to protect themselves from potential breaches. Unfortunately, there are no known workarounds available for this issue.

Timeline

Published on: 09/27/2023 19:15:12 UTC
Last modified on: 10/02/2023 18:37:17 UTC