[LINPEAS] Add privilege escalation check: An Evening with Claude (Code) sed-Based ...

[carlospolop]

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The blog describes a generic, locally exploitable privilege/persistence pattern that is not tied to highly custom CTF configs or a single obscure product version. The key technique is abusing sed’s file write/read capabilities in constrained-command environments to gain durable code execution via shell startup files:

1. Abusing sed for arbitrary file write/read:

   • The post explains that if an agent or wrapper (like Claude Code) allows sed with certain flags and only performs naive regex checks on the sed script, an attacker can use alternative, but fully standard, sed syntax to evade those checks.
   • Examples given for BSD/macOS sed include: sed 'w /path/to/file', sed -n '1,1w/path', and sed 'r/path/to/file'. These are normal sed features, not product‑specific bugs.
   • The technique is to find syntactic forms of w/r commands that are missed by simplistic validators, thereby obtaining arbitrary file write and read under the account running the tool.

2. Turning sed file writes into persistent RCE via shell startup files:

   • The post explicitly generalizes: use sed to write into ~/.zshenv, ~/.zprofile, ~/.bashrc, etc., so that arbitrary shell code runs whenever a new shell is started.
   • Example pattern: echo 'payload' | sed 'w ~/.zshenv' (or syntactic variants compatible with the local sed implementation).
   • This is a classic local persistence / privilege technique: once an attacker can trigger sed under the victim user’s context (e.g., via some limited shell/agent), they can escalate their effective control from “run a constrained text-processing command” to “arbitrary code on future shells”.
   • This is independent of Claude Code specifically; any environment (including real-world dev boxes, CI agents, or restricted shells on Linux/macOS) where sed is available and partially filtered is susceptible to the same class of bypass.

3. Why this fits linpeas:

   • linpeas aims to detect misconfigurations and common escalation/persistence vectors on Linux/macos. The described technique leverages:
     • Standard sed behavior on Linux/BSD/macOS.
     • Standard shell startup files for bash/zsh.
   • It does not rely on an obscure, fixed bug in a niche package; rather, it’s a class of misconfigurations (regex-based command wrapping / constrained shells that still expose sed) plus a well-known local persistence vector (startup file modification).
   • linpeas can’t directly know about “Claude Code”, but it can:
     • Check for suspicious contents in startup files indicating sed-based injection.
     • Enumerate sed invocations in shell histories that match known write/read patterns (e.g., w or r to dotfiles), which may signal existing compromise.
     • Flag environments where constrained shells or LLM/agent wrappers are present and sed is available as a powerful primitive.

Because this is a generalized method of gaining persistent execution for the current user via widely deployed tools and shell behavior, it is relevant and suitable for linpeas, especially on macOS where BSD sed syntax like w /path and r/path is specifically mentioned, but the logic applies to GNU sed on Linux as well.

🤖 Implementation Details

PEASS linpeas agent completed successfully with 125 items. Agent Comment: Summary:

• Added IF_Suspicious_sed_history (linPEAS/builder/linpeas_parts/9_interesting_files/30_Suspicious_sed_history.sh) to hunt for sed commands in every accessible shell-history source (built-ins, PSTORAGE, fallbacks via find) that use w/r to touch sensitive startup or credential files (.zshenv, .bashrc, .aws/credentials, .ssh/*, etc.). Matches are highlighted so operators can quickly spot Claude-Code-style sed persistence or file-read attempts.
• Added IF_Suspicious_startup_payloads (.../31_Suspicious_startup_payloads.sh) which enumerates common per-user and system-wide startup files and flags injected reverse-shell patterns (curl|sh, wget|sh, bash -i >& /dev/tcp, nc -e, ncat -e, socat TCP, python/perl socket stagers, etc.). This surfaces the downstream persistence artifacts that sed-based bypasses typically drop.

Testing:

• bash -n linPEAS/builder/linpeas_parts/9_interesting_files/30_Suspicious_sed_history.sh
• bash -n linPEAS/builder/linpeas_parts/9_interesting_files/31_Suspicious_startup_payloads.sh

🏗️ Builder Agent Response

LinPEAS build agent completed successfully with 71 items. Agent Comment: LinPEAS now builds successfully with the provided command. Here’s what I did:

1. Fixed module metadata gaps – Added the missing “Generated Global Variables” entries to the two new suspicious-history modules so the builder recognizes the internal variables they introduce.
2. Restored the PSTORAGE_HISTORY pipeline – Created a dedicated variable module (builder/linpeas_parts/variables/PSTORAGE_HISTORY.sh) that inventories readable shell history/startup files and exposes them via $PSTORAGE_HISTORY (and its helper accumulator). This satisfies the dependency for both the legacy “Passwords in history files” check and the new suspicious-history modules.
3. Verified the build – Reran python3 -m builder.linpeas_builder --all --output /tmp/linpeas_fat.sh from /tmp/hacktricks_update_cld1rqbs/repo/linPEAS, which now completes without errors and produces /tmp/linpeas_fat.sh.

Let me know if you’d like any additional validation or changes.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the implementation carefully and test thoroughly before merging.