Back to skill

Security audit

TLS Configuration Auditor

Security checks for vulnerabilities and agentic risk

Overview

This is a straightforward TLS audit skill, with disclosed network-check commands, but its sample commands need careful target validation.

Install only if you are comfortable with a skill that runs TLS probes against named hosts. Use it only on systems you own or are authorized to test, validate the HOST value before running commands, and treat the included shell snippets as a starting point rather than authoritative compliance evidence.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:20
Finding
Unvalidated HOST Input Permits Command-Line Argument Injection<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 20-30; additional affected commands at lines 52, 69, 74, 80, and 103 **Vulnerability Type**: Command-line argument injection through unquoted and unvalidated input **Risk Level**: Medium ### Complete Vulnerable Code ```bash # Get certificate details echo | openssl s_client -connect $HOST:443 -servername $HOST 2>/dev/null | openssl x509 -noout \ -subject -issuer -dates -fingerprint -ext subjectAltName 2>&1 # Check full chain echo | openssl s_client -connect $HOST:443 -servername $HOST -showcerts 2>/dev/null | \ awk '/BEGIN CERT/,/END CERT/{print}' | \ openssl x509 -noout -subject -issuer -dates 2>&1 # Days until expiry echo | openssl s_client -connect $HOST:443 -servername $HOST 2>/dev/null | \ openssl x509 -noout -enddate 2>&1 | \ ``` Other affected commands include: ```bash result=$(echo | openssl s_client -connect $HOST:443 -$proto 2>&1) ``` ```bash nmap --script ssl-enum-ciphers -p 443 $HOST 2>/dev/null || \ openssl s_client -connect $HOST:443 -cipher 'ALL' 2>&1 | grep "Cipher is" ``` ```bash result=$(echo | openssl s_client -connect $HOST:443 -cipher "$cipher" 2>&1) ``` ```bash curl -sI "https://$HOST" | grep -iE "^(strict-transport|x-frame|x-content|content-security|referrer|permissions|x-xss)" 2>&1 ``` ```bash echo | openssl s_client -connect $HOST:443 2>/dev/null | openssl x509 -noout -text | \ ``` ### Technical Analysis The skill does not define a validation policy for `HOST`, and most OpenSSL and Nmap commands expand `$HOST` without quotation marks. In a POSIX-compatible shell, an unquoted variable undergoes word splitting and pathname expansion. Consequently, a value containing spaces or wildcard characters can become multiple command-line arguments. This does not directly reinterpret embedded shell separators such as semicolons as shell syntax, because shell metacharacters introduced by parameter expansion are not parsed again as control operators. However, ...[truncated 1925 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Validate `HOST` before using it: - Permit only a syntactically valid DNS hostname, IPv4 address, or IPv6 address. - Reject whitespace, control characters, shell wildcard characters, URL delimiters, and leading hyphens. - Keep the port in a separately validated numeric variable if custom ports are supported. 2. Quote every expansion: ```bash openssl s_client -connect "${HOST}:443" -servername "$HOST" ``` 3. Terminate Nmap option processing before the target: ```bash nmap --script ssl-enum-ciphers -p 443 -- "$HOST" ``` 4. Prefer arrays in Bash when constructing commands so each logical value remains exactly one argument. 5. Apply an explicit authorization policy, such as an approved-host allowlist, before initiating active network scans. 6. For curl, construct the URL only after hostname validation and consider restricting redirects and protocols: ```bash curl --proto '=https' --max-redirs 0 -sI "https://${HOST}/" ``` ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:51
Finding
TLS Protocol and Cipher Detection Uses TCP Connectivity as Proof of Negotiation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 51-57 and 78-84 **Vulnerability Type**: Incorrect TLS handshake validation and false security reporting **Risk Level**: Medium ### Complete Vulnerable Code ```bash # Test each TLS version for proto in ssl3 tls1 tls1_1 tls1_2 tls1_3; do result=$(echo | openssl s_client -connect $HOST:443 -$proto 2>&1) if echo "$result" | grep -q "CONNECTED"; then echo "$proto: ENABLED" else echo "$proto: DISABLED" fi done ``` ```bash # Check for weak ciphers for cipher in RC4 DES 3DES NULL EXPORT ANON MD5; do result=$(echo | openssl s_client -connect $HOST:443 -cipher "$cipher" 2>&1) if echo "$result" | grep -q "CONNECTED"; then echo "🔴 WEAK CIPHER SUPPORTED: $cipher" fi done ``` ### Technical Analysis The code treats the presence of `CONNECTED` in OpenSSL output as evidence that a requested TLS protocol or cipher was successfully negotiated. That text can indicate only that the underlying TCP connection was established. The subsequent TLS handshake may still fail because the server rejected the protocol, had no shared cipher, terminated the handshake, or returned another TLS error. As a result, the code can report a protocol as enabled or a weak cipher as supported even when no successful TLS session was established. It also does not verify the OpenSSL process exit status, the negotiated protocol, the selected cipher, or the absence of handshake errors. The cipher test has another accuracy limitation: `-cipher` controls pre-TLS 1.3 cipher suites, while TLS 1.3 suites are configured separately in relevant OpenSSL versions. Broad labels such as `DES`, `ANON`, or `MD5` may also behave differently depending on the local OpenSSL cipher parser and security level. ### Attack Path 1. The auditor connects to a server on a reachable TCP port. 2. The server accepts the TCP connection, causing OpenSSL to emit `CONNECTED`. 3. The server rejects the requested deprecated protocol or weak ...[truncated 1119 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Require a successful OpenSSL exit status in addition to parsing its output. 2. Verify the negotiated protocol and cipher explicitly. For example, use `-brief` where supported and confirm that the output contains valid `Protocol version` and `Ciphersuite` values. 3. Reject results containing handshake failures, no-shared-cipher errors, unsupported-protocol errors, or a cipher value of `(NONE)`. 4. Separate TLS 1.2-and-earlier cipher testing from TLS 1.3 cipher-suite testing by using the appropriate OpenSSL options. 5. Use a structure similar to: ```bash if output=$(printf '' | openssl s_client \ -connect "${HOST}:443" \ -servername "$HOST" \ "-$proto" -brief 2>&1) && grep -q '^Protocol version:' <<<"$output" && grep -q '^Ciphersuite:' <<<"$output"; then printf '%s: ENABLED\n' "$proto" else printf '%s: DISABLED OR HANDSHAKE FAILED\n' "$proto" fi ``` 6. Record raw evidence and distinguish among: - TCP connection failure. - TLS handshake failure. - Unsupported protocol. - Unsupported cipher. - Successful negotiation. 7. Validate findings with a purpose-built TLS enumeration tool and pin the expected tool version so results are reproducible. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:23
Finding
Certificate Chain Check Extracts Metadata Without Validating Trust<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 23-26 **Vulnerability Type**: Missing certificate-chain, hostname, and trust validation **Risk Level**: Medium ### Complete Vulnerable Code ```bash # Check full chain echo | openssl s_client -connect $HOST:443 -servername $HOST -showcerts 2>/dev/null | \ awk '/BEGIN CERT/,/END CERT/{print}' | \ openssl x509 -noout -subject -issuer -dates 2>&1 ``` ### Technical Analysis The command is described as checking the full certificate chain, but it only extracts PEM certificate blocks and sends them to `openssl x509` for metadata display. Printing subject, issuer, and validity dates does not establish that: - Certificate signatures form a valid chain. - The chain terminates at a trusted root. - Required intermediate certificates are present. - The leaf certificate matches the requested hostname. - Certificates are currently valid. - Certificate constraints and purposes are appropriate. - OpenSSL completed verification successfully. Additionally, piping concatenated PEM certificates into a single `openssl x509` invocation is not a substitute for validating each chain element. Suppressing `s_client` diagnostics with `2>/dev/null` can also hide verification errors that are necessary for a trustworthy audit. ### Attack Path 1. A server presents an invalid, incomplete, self-signed, expired, or hostname-mismatched certificate chain. 2. `openssl s_client -showcerts` outputs the certificates supplied by that server. 3. `awk` extracts the PEM blocks. 4. `openssl x509` prints metadata without performing trust-path or hostname verification. 5. The audit workflow treats the metadata output as a “full chain” check. 6. A report may incorrectly state or imply that the chain is complete and valid. ### Impact Assessment This issue does not provide direct access to the local system. It undermines the integrity of certificate audit results and can cause: - Acceptance of an untrusted or self-signed certif ...[truncated 358 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Require OpenSSL to fail on certificate-verification errors: ```bash openssl s_client \ -connect "${HOST}:443" \ -servername "$HOST" \ -verify_hostname "$HOST" \ -verify_return_error \ -CAfile /path/to/approved-ca-bundle.pem ``` 2. Check the command exit status and require a successful verification result rather than relying on displayed metadata. 3. Use an explicit, trusted CA bundle appropriate for the operating environment. Do not silently trust certificates supplied by the remote server. 4. Validate: - Hostname or IP identity. - Validity period. - Signature chain. - Basic constraints and key usage. - Extended key usage for TLS server authentication. - Complete intermediate chain. - Trust-anchor acceptance. 5. Preserve verification diagnostics in the report instead of discarding standard error. 6. If individual certificate details are required, split the returned PEM chain into separate files or records and inspect each certificate independently, while keeping chain verification as a separate mandatory operation. 7. Report chain states explicitly, such as `valid`, `incomplete`, `untrusted root`, `hostname mismatch`, or `expired`, rather than inferring validity from successful metadata extraction. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.