T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:37- Finding
Agent-Triggered Access to Stored Authentication Credentials
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 37-44
Vulnerability Type: Agent-triggered credential access without an explicit consent checkpoint
Risk Level: MediumVulnerable Code Snippet
markdown ## Auto-Login for AI Agents ```bash # Check session status info-auth check # Auto-login (reads credentials from OS keyring, no password needed) campuscard login -ptext ### Technical Analysis The skill explicitly directs AI agents to execute `campuscard login -p`, which reads authentication credentials from the operating system keyring without requesting a password. No instruction requires the agent to obtain explicit, immediate user approval before accessing those credentials or creating an authenticated session. Keyring access may be legitimate for an authentication command, but automatically initiating it from an agent crosses a sensitive permission boundary. The resulting session is especially consequential because the documented CLI includes account information, transaction history, payment QR generation, recharge operations, and OTP management. The project contains only `SKILL.md`; the referenced Rust implementation is absent. Consequently, the audit could not verify whether the executable limits authentication requests to trusted PKU HTTPS hosts, protects credentials and tokens from logs, or requires additional authorization for financial operations. ### Attack Path 1. A user request activates the campus-card skill. 2. The agent follows the documented auto-login workflow and executes `info-auth check`. 3. If authentication is required, the agent runs `campuscard login -p` without a separate user-consent checkpoint. 4. The command retrieves stored credentials from the operating system keyring. 5. The authentication flow exchanges those credentials for a JWT or another authenticated session. 6. The authenticated session can potentially be used to access card details, transa ...[truncated 757 chars]- Remediation
View remediation
Remediation Suggestions
- Require explicit user confirmation immediately before any OS-keyring access, even when the user has previously requested a campus-card operation.
- Clearly state which credential entry will be accessed, why it is needed, and which authenticated account and service will receive it.
- Require separate confirmation before generating payment credentials, recharging funds, changing OTP configuration, or performing any other security-sensitive operation.
- Restrict authentication traffic to an explicit allowlist of validated PKU HTTPS origins and reject redirects to untrusted hosts.
- Ensure credentials, JWTs, session cookies, OTP secrets, and authorization headers are never written to logs, terminal output, error messages, or subprocess arguments.
- Store persisted sessions with least-privilege filesystem permissions and provide clear logout and session-revocation mechanisms.
- Add the referenced Rust source code to the review scope so credential handling, TLS validation, redirect behavior, token storage, and transaction authorization controls can be independently audited.
