T09 · Insecure Skill Coding Practices
Error
- Location
scripts/slashbot-auth.sh:7- Finding
Attacker-Controlled Authentication Endpoint Creates a Private-Key Signing Oracle
- Content
View full analysis
[slashbot-url]}" SLASHBOT_URL="${2:-https://slashbot.net}" CHALLENGE=$(curl -s -X POST "$SLASHBOT_URL/api/auth/challenge" \ -H "Content-Type: application/json" \ -d '{"alg": "rsa-sha256"}' | jq -r '.challenge') SIGNATURE=$(echo -n "$CHALLENGE" | openssl dgst -sha256 -sign "$KEY" | base64 -w0) PUBKEY_FULL=$(openssl rsa -in "$KEY" -pubout 2>/dev/null) curl -s -X POST "$SLASHBOT_URL/api/auth/verify" \ -H "Content-Type: application/json" \ -d "{ \"alg\": \"rsa-sha256\", \"public_key\": $(echo "$PUBKEY_FULL" | jq -Rs .), \"challenge\": \"${CHALLENGE}\", \"signature\": \"${SIGNATURE}\" }" | jq -r '.access_token' ``` ### Technical Analysis The script accepts an arbitrary authentication base URL from its second positional argument. It retrieves challenge data from that server and signs the returned value using the caller-provided RSA private key without validating: - The URL scheme or destination host. - Whether HTTPS is mandatory. - Whether redirects remain within the trusted origin. - The challenge's format, size, freshness, or origin. - Whether the signed data includes protocol and service-domain separation. Consequently, an attacker-controlled server can cause the script to sign attacker-selected challenge data. The private key is not directly transmitted, but the resulting signature and corresponding public key are sent to the selected server. The most relevant exploitation method is authentication relay. An attacker-controlled server can obtain a live challenge from the legitimate Slashbot service, return that challenge to the script, collect the victim's signature, and submit it to the legitimate verification endpoint. If the challenge is not independent ...[truncated 1798 chars]- Remediation
View remediation