Silent Leaks: Harvesting Secrets from Shared Linux Environments

Silent Leaks: Harvesting Secrets from Shared Linux Environments

Speakers: Cernica Ionut Cosmin

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=ig8ZMiPwrAw

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Cernica%20Ionut%20Cosmin%20-%20Silent%20Leaks%20Harvesting%20Secrets%20from%20Shared%20Linux%20Environments.pdf

Overview

Cernica Ionut Cosmin, an application security engineer and bug bounty hunter, presents a systematic examination of information leakage vectors in shared Linux environments — hosting panels, development servers, educational labs, VPS providers, and CTF infrastructure where multiple unprivileged users share the same underlying system. The talk covers how process argument leakage through ps, temporary file handling weaknesses, and insufficient isolation configurations allow a low-privileged attacker to harvest database credentials, API keys, passwords, and other secrets from co-tenants without any privilege escalation. The research is practical and grounded in real deployments encountered through bug bounty work.

Background

▶ Watch: You can do both both ways. (3:40)

The multi-user Linux threat model. Shared Linux environments are ubiquitous. Web hosting control panels (cPanel, Plesk, DirectAdmin), budget VPS providers, developer platforms, university shell servers, and CTF infrastructure all place multiple unprivileged users on the same machine. The security assumption is simple: each user has access to their own files and processes, and Linux's user/group permission model prevents one user from reading another's sensitive data.

This assumption is correct for filesystem access — with properly set permissions, User A cannot read User B's files. But the assumption breaks down for process metadata, /proc filesystem exposure, IPC mechanisms, and temporary directory behavior. These are the attack vectors Cosmin documents.

Attacker starting position. The threat model for this talk explicitly excludes local privilege escalation. The attacker has only a basic unprivileged shell — either SSH access or a web shell — and no root privileges. The goal is to collect secrets belonging to other users or the system itself from this position. This is a realistic starting position for a shared hosting compromise or a misconfigured multi-user environment.

Why this matters for bug bounty and pentesting. Cosmin notes this research comes directly from bug bounty work. Shared environments are common in startup and SMB infrastructure, and the ability to harvest credentials from adjacent tenants can turn a limited low-privilege foothold into a significant credential compromise without any traditional exploitation.

Key Findings

▶ Watch: Uh processor arguments leaks most of the time are uh are leaked through this ... (4:57)

ps leaks process arguments system-wide by default. The ps command — installed by default on essentially every Linux distribution — shows all running processes and, critically, their full command-line arguments. Command-line arguments frequently contain credentials: database connection strings with passwords, API keys passed as --api-key flags, configuration values passed as environment variables in some invocation styles. Any unprivileged user on the system can run ps aux and read the arguments of every process owned by every other user.

/proc directory access varies but often leaks. The /proc pseudo-filesystem exposes per-process information. On many systems, /proc/[pid]/cmdline is readable by other users, providing the same argument leakage as ps. /proc/[pid]/environ — which contains the process's environment variables — has more restricted permissions by default but is readable by the process owner and sometimes misconfigured to broader access.

Temporary file handling creates cross-user leakage. Applications that write temporary files to world-readable directories (most commonly /tmp) without proper permissions create secret leakage opportunities. Web applications that write session tokens, database credentials, or API keys to temp files in /tmp — even briefly — expose them to any user who can read /tmp. The window of exposure may be short, but race conditions or slow cleanup create windows for collection.

Jailing and isolation misconfigurations. Shared hosting environments use various isolation mechanisms: chroot jails, Linux namespaces, container runtimes. Cosmin documents misconfigurations in these isolation layers that allow escape or cross-tenant visibility. Particularly in legacy control panel setups, isolation is often incomplete — processes may run in separate chroots but share a process namespace, meaning ps still shows cross-jail processes.

Fingerprinting co-tenants. Before targeted secret harvesting, an attacker needs to understand the environment: which users exist, what applications they run, what their processes look like. Cosmin covers how to fingerprint the environment from a low-privilege shell — extracting usernames, application types, framework versions, and technology stack from process listings, partial filesystem access, and network listening port enumeration.

Lateral movement potential. Database credentials harvested from one tenant's process arguments can be used to connect to a shared database server, access multiple tenants' databases if the server is not properly access-controlled, or leverage credential reuse against other services.

Technical Deep Dive

▶ Watch: Shared Linux environment threats: how secrets leak in multi-tenant systems (6:25)

ps exploitation details. Running ps aux or ps -ef on a standard Linux system shows all processes with their full argument vectors. Credentials commonly found here include:

• MySQL/PostgreSQL connection strings: mysql -u dbuser -pSECRETPASSWORD dbname
• Python/PHP scripts invoked with secrets as arguments
• Curl/wget invocations with --header "Authorization: Bearer TOKEN"
• PHP CLI processes with configuration paths that, when read, contain credentials

Cosmin documents a systematic approach: ps aux | grep -E '(password|key|secret|token|credential)' -i as a starting point, followed by more targeted searches based on the identified application stack.

/proc/[pid]/cmdline direct access. When iterating over /proc, each numeric directory is a PID. For each readable PID directory, /proc/[pid]/cmdline contains the null-byte-separated argument vector. A simple shell script can iterate over all readable PIDs and extract their arguments — achieving the same result as ps but sometimes covering cases where ps output is filtered or abbreviated.

/proc/[pid]/environ access. Environment variables — accessible via /proc/[pid]/environ where readable, or via /proc/self/environ for the current process — frequently contain credentials passed by deployment tools, CI/CD pipelines, and container orchestration that uses environment variable injection. The AWS_SECRET_ACCESS_KEY, DATABASE_URL, REDIS_PASSWORD, and similar standard environment variable names are common targets.

Temporary file enumeration. ls -la /tmp and ls -la /var/tmp from an unprivileged shell reveals filenames and modification times of temporary files. Filenames often indicate application types (session files, lock files, SQL dumps). Where files are world-readable, their contents are directly accessible. Even where content is not accessible, timing analysis can reveal application behavior.

Inotify-based collection. Linux's inotify mechanism allows monitoring filesystem events. An attacker with shell access can set up an inotify watch on /tmp to capture file creation events in real time — triggering collection immediately when a sensitive temp file is created, even if the application deletes it quickly.

Shared IPC mechanisms. Some applications use POSIX shared memory (/dev/shm), named pipes, or Unix domain sockets for inter-process communication. Where these are world-readable or accessible to other users, they can expose application state or credential material.

Countermeasures evasion. Cosmin discusses defenses commonly deployed in shared hosting — hidepid mount option on /proc, which restricts /proc visibility to process owners — and their limitations. hidepid=2 prevents other users from listing or reading /proc entries for processes they do not own, which is the correct mitigation. He notes that many providers have not deployed it because it can break monitoring tools and some administrative software.

Demo / Proof of Concept

▶ Watch: So they created light speeded for caching. (26:52)

The demo section of the talk shows the attack from a real low-privilege shell in a lab environment designed to mimic a hosting panel configuration:

1. Process enumeration: ps aux output from the low-privilege shell, showing other users' processes with credentials visible in arguments (sanitized for demo purposes but structurally real).

1. /proc iteration: A short shell one-liner iterating over /proc/*/cmdline entries and filtering for credential patterns, recovering the same information through a different path.

1. Temp file capture: An inotify-based script watching /tmp and capturing file contents as they are created, demonstrated against an application that briefly writes a session token to a temp file.

1. Credential use: The harvested credentials are used to authenticate to a database or API service as the victimized co-tenant, demonstrating the real-world impact.

Defensive Implications

▶ Watch: As you can see I trigger a backup copy on my of my database. (39:37)

Deploy hidepid=2 on /proc. This is the single most impactful mitigation for process argument leakage. Mounting /proc with hidepid=2 prevents users from viewing process metadata for processes they do not own. Administrators should test monitoring tool compatibility before deployment but should prioritize this configuration in any shared environment.

Never pass credentials as command-line arguments. Application deployment practices should use environment variables (passed via container secrets management or configuration files with restricted permissions), not command-line arguments, for credentials. Arguments are always visible in the process table.

Restrict /tmp permissions. The sticky bit on /tmp prevents file deletion by non-owners but not reading. Applications should create temporary files with 0600 permissions (tmpfile() in C, tempfile.NamedTemporaryFile in Python) to prevent world-readable temp files.

Use container or namespace isolation. Modern shared hosting should use Linux namespaces (via containers or systemd-nspawn) to provide PID namespace isolation, preventing cross-tenant process visibility regardless of /proc mount options.

Audit /proc mount options. Check current /proc mount options with cat /proc/mounts | grep proc. Deploy hidepid=2,gid=<proc-group> and add any processes that need visibility (monitoring daemons) to the proc group.

Review IPC and shared memory usage. Applications that use /dev/shm or world-accessible Unix sockets for IPC in shared environments should evaluate whether access controls are appropriately restrictive.

Key Takeaways

1. Shared Linux environments leak secrets through process argument visibility (ps), /proc filesystem access, temporary file handling, and IPC mechanisms without requiring any privilege escalation.
2. ps aux on a standard Linux system exposes every running process's command-line arguments to any local user — a trivial collection mechanism for credentials passed as CLI flags.
3. The hidepid=2 mount option on /proc is the primary mitigation and is underdeployed in shared hosting environments due to compatibility concerns.
4. Temporary file secrets are exploitable via inotify-based real-time collection, even when the application deletes files quickly.
5. These techniques are directly applicable in bug bounty and penetration testing contexts involving shared hosting platforms and multi-user development environments.
6. The attack chain (foothold → secret harvest → lateral movement) does not require exploiting any traditional vulnerability — it exploits default system behavior and deployment antipatterns.

About the Speaker(s)

▶ Watch: So don't make wrong assumptions about your system. (44:01)

Cernica Ionut Cosmin is an application security engineer at UiPath and an active bug bounty hunter with a background in AI security research and CTF competition. His research focus spans web application security, Linux system security, and cloud environments. The findings in this talk emerged from practical bug bounty work in real shared hosting and development environments.