📄 redteam-domain-dns-ops.md 6,717 bytes Apr 27, 2026 📋 Raw

🔴 Red Team Assessment: steipete/domain-dns-ops

Skill: Domain/DNS Ops
Author: steipete (Peter Steinberger, PSPDFKit founder)
Source: https://clawhub.ai/steipete/domain-dns-ops
Version: v1.0.0
License: MIT-0 (public domain, zero conditions)

Executive Summary

Risk Level: MEDIUM-HIGH — Skill is legitimately useful for its stated purpose (DNS/Cloudflare ops), but the metadata omits critical security declarations that the instructions depend on. This creates an approval gap: an agent could autonomously access API tokens, run repo scripts, and modify DNS without the user understanding what's about to happen.

Verdict: Not malicious. But poorly declared. Requires human-in-the-loop for any destructive operation.

Threat Model

What It Claims to Do

  • Onboard domains to Cloudflare
  • Flip nameservers (Namecheap → Cloudflare)
  • Set redirects (Page Rules, Rulesets, Workers)
  • Verify DNS/HTTP with dig/curl
  • Source of truth: ~/Projects/manager (user's personal repo)

What It Actually Does (Red Team Analysis)

✅ Benign Intent

  • Author is a known developer (Peter Steinberger, PSPDFKit)
  • Skill is a thin router — delegates to user's own repo scripts
  • No install spec = no code written to disk by the skill itself
  • always: false = requires explicit user invocation
  • "Push only when explicitly asked" guardrail in SKILL.md
  • "Don't touch .md lore domains" guardrail

⚠️ Risk Vectors

# Risk Severity Details
1 Missing credential declarations 🔴 High SKILL.md references CLOUDFLARE_API_TOKEN / CF_API_TOKEN and Namecheap/DNSimple creds in ~/Projects/manager/profile, but metadata lists zero required env vars. Agent won't request approval before reading these.
2 Unbounded file system access 🔴 High Instructions read ~/Projects/manager/*, ~/.profile, source shell profiles, execute bin/* scripts. No path restrictions declared.
3 Autonomous invocation enabled 🟡 Medium always: false is good, but platform default allows autonomous invocation. Combined with unbounded FS access, an agent could run DNS-altering commands without fresh human approval.
4 Git push capability 🟡 Medium SKILL.md includes commit/push instructions. While it says "push only when explicitly asked," an agent with autonomous rights might skip this.
5 No binary declarations 🟡 Medium Uses cli4, rg, dig, curl, git — none declared in metadata. Agent might install or fail silently.
6 No network scope 🟡 Medium Calls Cloudflare API, Namecheap API, DNSimple API, makes DNS queries. No network restrictions declared.

Attack Scenarios

Scenario 1: Token Exposure (Most Likely)

Agent reads ~/Projects/manager/profile containing CLOUDFLARE_API_TOKEN, echoes it in a debug message or logs it. Token now in chat history / logs.

Mitigation: Agent should never echo or log tokens. SKILL.md doesn't mention this.

Scenario 2: Unauthorized Nameserver Flip

Autonomous agent decides to "fix" DNS, runs bin/namecheap-set-ns, flips nameservers for a domain. Site goes down.

Mitigation: Always require human confirmation for nameserver changes.

Scenario 3: Scope Creep via Shell Profile

source ~/.profile loads arbitrary environment variables and functions. If profile has side effects, agent inherits them.

Mitigation: Agent should not source user profiles without understanding contents.

Scenario 4: Git Push Without Approval

Agent commits and pushes to ~/Projects/manager. If profile has git aliases or hooks, unintended changes propagate.

Mitigation: SKILL.md has "push only when explicitly asked" but no enforcement mechanism.

Clean Room Recommendation

Do you need it? If you manage domains via Cloudflare/Namecheap/DNSimple and have a ~/Projects/manager repo with scripts — yes, this is useful. But it needs hardening.

If installing, apply these controls:

1. Pre-Install Review (REQUIRED)

  • [ ] Confirm ~/Projects/manager exists
  • [ ] Review every script in bin/* — what do they do? What secrets do they read?
  • [ ] Review ~/Projects/manager/profile — what env vars does it set?
  • [ ] Check DOMAINS.md for domains you don't want touched

2. Metadata Hardening (REQUEST FROM AUTHOR)

# What should be in the skill manifest:
required_binaries: [cli4, rg, dig, curl, git]
required_env_vars: [CLOUDFLARE_API_TOKEN, CF_API_TOKEN]
required_paths: [~/Projects/manager]
network_scope: [api.cloudflare.com, api.dnsimple.com, api.namecheap.com]

3. Runtime Controls

  • [ ] Disable autonomous invocation for this skill (require explicit /invoke or similar)
  • [ ] Set approval gate for: nameserver changes, zone deletion, git push
  • [ ] Log all cli4 commands and bin/* script invocations
  • [ ] Never allow git push without explicit human confirmation

4. Token Hygiene

  • [ ] Use least-privilege Cloudflare tokens (zone:read, zone:edit for specific zones only)
  • [ ] Rotate tokens after testing
  • [ ] Don't store tokens in ~/.profile — use pass, 1password, or dedicated env file

Comparison to Our Architecture

Principle Our Standard This Skill Gap
Zero-trust secrets App passwords, ~/.openclaw/.env (chmod 600) Reads from ~/Projects/manager/profile No declared secret management
Least privilege Tokens scoped to specific operations Full Cloudflare API access via token Token scope not discussed
Approval gates Destructive ops require /approve "Push only when explicitly asked" (advisory) No enforcement
Path isolation Skills run in scoped workspace Reads arbitrary ~/Projects/manager/* No path restrictions
Network isolation localhost/Tailscale only Calls external APIs Expected for DNS ops, but undeclared

Bottom Line

Not a backdoor. Not malicious. But sloppy metadata that expands blast radius.

Peter built a useful tool for his own workflow. If you have a similar setup (personal domain manager repo), it could save time. But treat it like a power tool — useful, but disable autonomous mode and keep your fingers clear of the blade.

My recommendation:
1. Review your ~/Projects/manager repo first
2. Install only if the scripts are clean and you understand them
3. Never enable autonomous invocation
4. Require explicit approval for any git push, nameserver change, or zone deletion
5. Consider writing your own thin wrapper instead (it's mostly a router)

Assessment by Socrates 🧠 | 2026-04-27

← Back