T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/msg-sapconet.sh:9
- Finding
- Remote Command Injection Through Unsafely Interpolated Message<![CDATA[ ## Vulnerability Details **File Location**: `scripts/msg-sapconet.sh`, lines 9–13 **Vulnerability Type**: Remote shell command injection **Risk Level**: High ### Vulnerable Code ```bash SAPCONET_TARGET="${SAPCONET_TARGET:-neill@100.110.24.44}" MESSAGE="$1" # Placeholder: replace with actual SAPCONET inbox command # Keep NO_REPLY discipline for automated messages. ssh "${SAPCONET_TARGET}" "echo 'TODO: send inbox message: ${MESSAGE}'" ``` ### Technical Analysis The first command-line argument is assigned to `MESSAGE` and directly interpolated into a command sent to the remote SSH server. Although the local expansion is enclosed in double quotes, the resulting string is interpreted again by a shell on the remote host. The script attempts to place the message inside single quotes in the remote command. An attacker can supply a single quote to terminate that quoted section and then append shell operators and arbitrary commands. No validation or shell-safe argument serialization is applied before the remote shell evaluates the command. For example, the following message escapes the intended `echo` argument: ```text '; id; # ``` This produces an effective remote command equivalent to: ```bash echo 'TODO: send inbox message: '; id; #' ``` The remote shell therefore executes `id` as a separate command. Other commands could be substituted based on the privileges and available tools of the configured SSH account. ### Attack Path 1. An attacker obtains the ability to invoke `scripts/msg-sapconet.sh` or influence the message passed to it. 2. The attacker supplies a message containing a closing single quote, a shell separator, an arbitrary command, and a comment marker: ```bash bash scripts/msg-sapconet.sh "'; id; #" ``` 3. The local script interpolates the payload into the SSH command without safe encoding. 4. SSH sends the resulting command string to SAPCONET. 5. The remote login shell parses the injected shell syntax. 6. The injected com ...[truncated 866 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Do not construct a remotely evaluated shell command by interpolating untrusted input. 1. Send message content through standard input to a fixed remote command rather than embedding it in the remote command string. 2. Ensure the eventual inbox utility reads the message from standard input or another non-shell data channel. 3. If positional arguments are unavoidable, use a rigorously tested shell-escaping mechanism and pass data separately from executable syntax. 4. Validate message length and permitted content according to the inbox protocol, but do not rely on validation alone to prevent command injection. 5. Restrict the SSH account using least privilege, such as a forced command, a dedicated account, and an allowlisted server-side wrapper. 6. Add regression tests with quotes, semicolons, command substitutions, newlines, and shell redirection characters. For the current placeholder, a safer standard-input pattern is: ```bash printf '%s\n' "$MESSAGE" | ssh -- "${SAPCONET_TARGET}" \ 'IFS= read -r message; printf "%s\n" "TODO: send inbox message: $message"' ``` For production use, replace the placeholder with a fixed remote wrapper that accepts message data through standard input and does not evaluate that data as shell syntax. ]]>