--- name: hunt-auth-bypass description: Hunting skill for auth bypass vulnerabilities. Built from 4 public bug bounty reports. Use when hunting auth bypass on any target. sources: github report_count: 4 --- ## Crown Jewel Targets Auth bypass is consistently one of the highest-paying vulnerability classes in bug bounty because it directly violates the most fundamental security control. High-value targets include: - **SSO/SAML implementations** at enterprise SaaS companies (Slack, Okta, OneLogin integrations) — payouts regularly in the $5K–$25K+ range - **Admin panels and partner/internal portals** — subdomain-separated admin surfaces like `partners.shopify.com`, `admin.company.com` - **Third-party auth plugin integrations** — WordPress plugins (OneLogin, WP-SAML-Auth), Drupal SSO modules, any CMS with pluggable auth - **XMLRPC endpoints** on WordPress — often forgotten, bypasses standard WP auth flows entirely - **OAuth callback flows** — state parameter mishandling, redirect_uri mismatches - **API authentication layers** — especially where auth was bolted on after the fact **Asset priority:** Targets with federated identity (SAML, OAuth, OIDC) connected to large user populations. Partner/reseller portals are particularly juicy because they often have elevated permissions and less security scrutiny than the main product. --- ## Attack Surface Signals **URL patterns to hunt:** ``` /xmlrpc.php /wp-login.php /saml/ /sso/ /auth/saml/callback /oauth/callback /partners.* /admin.* /?wc-api= /api/v*/auth /login?redirect= /accounts/login ``` **Response headers signaling SSO:** ``` X-Frame-Options: SAMEORIGIN (common on SSO portals) Set-Cookie: SAMLResponse= Location: https://idp.company.com/saml WWW-Authenticate: Bearer realm="partners" ``` **JS patterns indicating federated auth:** ```javascript // Look for in page source samlRequest RelayState SAMLResponse onelogin shibboleth okta passport.js authenticate ``` **Tech stack signals:** - WordPress + any SSO plugin → check XMLRPC separately - Shopify Partner API exposure → cross-tenant privilege escalation risk - Any app advertising "SSO enabled" or "Login with [Enterprise IdP]" - Separate subdomains for admin/partner that share session cookies with main domain - Applications using `SimpleSAMLphp`, `ruby-saml`, `python-saml` **Burp passive scan triggers:** - `SAMLResponse` in any POST body - `openid_connect` or `id_token` in responses - Cookie domains set to `.company.com` (wildcard) --- ## Step-by-Step Hunting Methodology 1. **Map all authentication entry points** - spider the target for every login surface: main login, admin login, API login, partner portal, mobile API endpoints - check `robots.txt`, JS files, and the wayback machine for forgotten endpoints like `/xmlrpc.php` 2. **Identify the auth mechanism per entry point** - Is it forms-based, SAML, OAuth, API key, session token? - For WordPress: always probe `/xmlrpc.php` even if the main login is SSO-protected 3. **Test XMLRPC independently of SSO** - If site uses SSO (e.g., OneLogin), manually POST to `/xmlrpc.php` - XMLRPC uses WordPress-native credentials, not SSO — test with `system.listMethods` first, then `wp.getUsersBlogs` 4. **Enumerate SAML implementation** - Capture a valid SAMLResponse via Burp - Decode the Base64 payload, inspect the XML - Test signature stripping, comment injection, and XML wrapping attacks - Test if SP validates the signature at all (send unsigned assertion) 5. **Test cross-portal session/token reuse** - Log into `partners.shopify.com` type portals - Attempt to use the issued token/cookie against the main admin portal - Look for shared cookie domains, shared JWT secrets, or API tokens that work across contexts 6. **Fuzz auth parameters** - Null/empty passwords, `password[]=array`, SQL in username field - Try `admin`/`admin`, `test`/`test` on staging subdomains - Modify `role`, `is_admin`, `user_type` in JWTs (none algorithm, weak secret) 7. **Check redirect and state parameters** - Does removing `state` from OAuth break anything? - Can you change `redirect_uri` to an open redirect target? - Does the `RelayState` in SAML get validated? 8. **Verify impact by escalating privileges** - Don't stop at login — prove you can access admin functions, other users' data, or sensitive configuration - Screenshot the highest-privilege action you can perform --- ## Legacy-Protocol Matrix (Probe These First on Any Custom-Branded Login) When a target has a custom, branded login UI (e.g. `customlogin.aspx`, `/auth/signin`, `/account/login`), **always probe the platform's legacy protocol endpoints with native credentials** in parallel. These endpoints frequently outlive the custom UI's protections and accept native credentials with NO rate limit, NO MFA challenge, NO CAPTCHA, NO anti-automation. This is the WordPress XMLRPC pattern generalised across CMS / portal / framework stacks. | Target tech | Legacy endpoint(s) to probe | Native-cred bypass surface | |---|---|---| | **WordPress** | `/xmlrpc.php` (`system.listMethods`, `wp.getUsersBlogs`, `system.multicall`) | Native WP user/pass; bypasses SSO, MFA, IP-allow rules on `/wp-login.php` | | **WordPress (REST)** | `/?rest_route=/wp/v2/users`, `/wp-json/wp/v2/users` | User enumeration anonymously even when login page is hardened | | **SharePoint (any version)** | `/_vti_bin/Authentication.asmx` (`Mode` + `Login` SOAP ops) | Native Forms-auth credential; FedAuth cookie returned; no rate limit on this endpoint observed on SP2013 farms — **this is the canonical SP equivalent of the WP XMLRPC bypass** | | **SharePoint legacy** | `/_vti_bin/_vti_aut/author.dll`, `/_vti_bin/_vti_adm/admin.dll`, `/_vti_bin/owssvr.dll` | FrontPage RPC; sometimes still wired to credential validators | | **SharePoint REST** | `/_api/contextinfo` (POST), `/_api/$metadata` | Anonymous FormDigest issuance; full API surface enumeration | | **Atlassian (Jira / Confluence)** | `/rest/auth/1/session` (basic-auth), `/rest/api/2/myself`, legacy `/rest/api/1.0/` | Native credentials accepted on `/rest/auth/1/session` even when Atlassian Crowd / Atlassian Access SSO is enforced on the UI | | **Drupal** | `/jsonapi/`, `/user/login?_format=json` | JSON POST endpoint that accepts native passwords; separate from SSO middleware | | **Drupal (D7 legacy)** | `/?q=user/login`, `/services/`, `/rest/` | Older REST modules with independent auth | | **Joomla** | `/administrator/index.php?option=com_login`, `/api/index.php/v1/users` | Native Joomla credentials accepted on admin entry independent of any front-site SSO | | **Exchange / OWA** | `/EWS/Exchange.asmx`, `/Autodiscover/Autodiscover.xml`, `/Microsoft-Server-ActiveSync` | NTLM / Basic; bypasses OWA UI restrictions (MFA, IP-allow). The classic CVE-2020-0688 / CVE-2021-26855 surface | | **Citrix NetScaler** | `/vpn/index.html`, `/cgi/login`, `/nf/auth/doAuthentication.do` | Native AD credentials; independent of MFA wrappers | | **F5 BIG-IP** | `/mgmt/tm/util/bash`, `/tmui/login.jsp` | Native admin credentials | | **Generic ASP.NET app** | `*.asmx?WSDL`, `*.svc?WSDL`, `trace.axd`, `elmah.axd`, `.disco` | Find every web service; many take credentials independently of the WebForms login | | **Spring Boot** | `/actuator/*`, `/management/*`, `/api/v1/auth/login`, `/api/v1/swagger-ui` | Actuator endpoints sometimes anonymously enumerable | | **Jenkins** | `/jnlpJars/jenkins-cli.jar`, `/script`, `/manage`, `/computer/(master)/script` | API tokens + native auth | | **GitLab** | `/api/v3/*` (deprecated but still on old installs), `/api/v4/users`, `/api/v4/projects` | Personal Access Tokens with looser scoping than UI session | | **TeamCity** | `/app/rest/users`, `/login.html?username=&password=` (GET-form-login) | Native admin credentials | | **Apache Tomcat** | `/manager/html`, `/host-manager/html`, `/manager/text/list` | Native Tomcat realm credentials independent of any front auth | | **WebLogic** | `/console/login/LoginForm.jsp`, `/wls-wsat/*` | Native admin | | **Oracle EBS / PeopleSoft** | `/OA_HTML/AppsLogin`, `/psp/*/?cmd=login` | Native ERP credentials | **How to use:** 1. Identify the tech stack from headers + paths (use `hunt-misc` Attack Surface Signals). 2. Find the row above that matches. 3. Probe the legacy endpoint anonymously to confirm it's reachable and not 403/404. 4. Test with synthetic credentials to confirm it accepts native credential format and returns differential responses (success vs failure). 5. Verify there is no rate limit, no lockout, no CAPTCHA — burst 10 requests at the same user, confirm uniform timing. 6. Report as **Critical / High** depending on chain to ATO: an anonymous + unlimited credential brute-force endpoint is consistently Critical on bug-bounty programs. **Lesson from a authorized engagement:** A an enterprise dealer portal on SharePoint 2013 had a custom branded `customlogin.aspx`. The hunt-auth-bypass skill was loaded but the matrix above did not exist in this document — and the WordPress XMLRPC pattern was not connected to the SharePoint equivalent. `/_vti_bin/Authentication.asmx` was reachable anonymously, accepted unlimited credential attempts with no rate limit and no lockout, and was the highest-impact finding in the engagement. Walking this matrix on the first pass would have surfaced it immediately. --- ## Payload & Detection Patterns **XMLRPC auth probe (bypasses SSO):** ```bash curl -s -X POST https://target.com/xmlrpc.php \ -H "Content-Type: text/xml" \ -d ' system.listMethods ' # If 200 with method list → XMLRPC is enabled, test auth: curl -s -X POST https://target.com/xmlrpc.php \ -H "Content-Type: text/xml" \ -d ' wp.getUsersBlogs admin password ' ``` **SAML signature stripping (send unsigned assertion):** ```python import base64, re # Decode captured SAMLResponse saml_b64 = "BASE64_FROM_BURP" saml_xml = base64.b64decode(saml_b64).decode() # Strip the Signature element entirely stripped = re.sub(r'', '', saml_xml, flags=re.DOTALL) # Re-encode and submit print(base64.b64encode(stripped.encode()).decode()) ``` **SAML XML comment injection (username confusion):** ```xml attacker@evil.com attacker@evil.com.victim@company.com victim@company.com ``` **Partner/cross-portal token reuse test:** ```bash # Get token from partner portal TOKEN=$(curl -s -X POST https://partners.target.com/login \ -d 'email=attacker@test.com&password=pass' \ -c cookies.txt | grep -o 'token=[^;]*') # Replay against admin portal curl -s https://admin.target.com/dashboard \ -H "Authorization: Bearer $TOKEN" \ -H "Cookie: $TOKEN" ``` **JWT none algorithm attack:** ```python import base64, json header = base64.b64encode(json.dumps({"alg":"none","typ":"JWT"}).encode()).decode().rstrip('=') payload = base64.b64encode(json.dumps({"user_id":1,"role":"admin","email":"victim@company.com"}).encode()).decode().rstrip('=') token = f"{header}.{payload}." print(token) ``` **Grep patterns for auth bypass surface:** ```bash # Find XMLRPC in scope grep -r "xmlrpc" scope_urls.txt # Find SSO indicators in JS grep -rE "(SAMLResponse|samlRequest|RelayState|onelogin|shibboleth)" *.js # Find partner/admin subdomains subfinder -d target.com | grep -E "(admin|partner|internal|sso|auth|login)" ``` --- ## Common Root Causes 1. **SSO bypasses local auth entirely at the UI layer, but not at the API layer** — developers disable the login form but forget that API endpoints (`/xmlrpc.php`, REST API, mobile API) have their own auth handlers that still accept native credentials. 2. **SAML signature validation is skipped or optional** — library defaults often don't enforce signature checking; developers use `wantAssertionsSigned: false` or fail to configure the IdP certificate correctly. 3. **Shared session infrastructure across different trust levels** — partner portals and admin portals reuse the same session cookie or JWT secret because they're built on the same internal framework, assuming access control at the application layer is sufficient. 4. **Trust inheritance in multi-tenant architectures** — a token issued in a lower-privilege context (partner, reseller) is accepted in a higher-privilege context because the verification only checks signature validity, not the issuance context. 5. **Plugin/module auth is independent of application auth** — every WordPress plugin that handles auth (contact forms, REST API extensions, WooCommerce) may implement its own auth handler inconsistently with the main site's SSO. 6. **XML parsing inconsistencies** — different XML parsers (used by SP vs. IdP) handle comments, namespaces, and whitespace differently, enabling confusion attacks where the signed content differs from the evaluated content. --- ## Bypass Techniques | Defense | Bypass | |---|---| | SSO enforced on login page | Probe alternate entry points: XMLRPC, REST API, mobile API, legacy endpoints | | SAML signature validation | XML comment injection, namespace wrapping, signature wrapping (XSW), remove signature entirely | | IP allowlisting on admin portal | Use partner portal token if it shares auth backend | | Rate limiting on login | XMLRPC allows credential stuffing via `system.multicall` — batches hundreds of auth attempts in one request | | CSRF token on login form | SAML flow is POST-based cross-origin by design; no CSRF token needed on `/saml/callback` | | JWT signature validation | `alg: none`, key confusion (RS256 → HS256 with public key as secret), brute-force weak secrets | | Separate session stores per portal | Check if cookie domain is `.target.com` (wildcard) — cookie bleeds between subdomains | | MFA on primary login | If SAML SP doesn't enforce MFA at the assertion level and accepts pre-auth assertions, MFA can be skipped | **XMLRPC multicall for mass auth bypass:** ```xml system.multicall methodNamewp.getUsersBlogs params admin password1 ``` --- ## Gate 0 Validation Before writing any report, answer these three questions: 1. **What can the attacker DO right now?** Must be: authenticate as another user OR authenticate without valid credentials OR elevate to admin/privileged role. "Partial information disclosure" is not auth bypass. 2. **What does the victim LOSE?** Must identify a concrete asset: account takeover of specific user, access to all admin functions, ability to read/modify other tenants' data, or access to privileged APIs. Abstract "security control bypass" without impact is not sufficient. 3. **Can it be reproduced in 10 minutes from scratch?** You must be able to: (a) start from a fresh browser/session, (b) follow your exact steps, and (c) arrive at authenticated access to a protected resource. If reproduction requires special preconditions you can't re-create (a specific victim's active session, timing windows), the report needs more work. --- ## Real Impact Examples **Scenario 1 — SSO Enforcement Bypassed via Forgotten Protocol Endpoint** A large ride-sharing company enforced SSO (via OneLogin) on all WordPress-based internal/public properties. The XMLRPC endpoint (`/xmlrpc.php`) remained active and accepted WordPress-native credentials entirely independent of the SSO flow. An attacker with any valid WP-native credentials (obtained via credential stuffing or from a previous breach) could authenticate directly through XMLRPC, bypassing MFA, SSO policies, and IP restrictions enforced on the main login form. Impact: Full authenticated access to all WordPress functions available to that user role, including content management and potentially admin functions. **Scenario 2 — SAML Assertion Forgery via Signature Validation Failure** A major enterprise communication platform's SAML SP implementation failed to properly validate assertion signatures in specific edge cases. By manipulating the XML structure of a captured SAMLResponse (specifically through comment injection or namespace prefix attacks), an attacker could modify the `NameID` value to impersonate any user in an organization — including workspace administrators — without possessing that user's credentials or private key material. Impact: Complete account takeover of any user within a SAML-enabled organization; attacker gains access to all messages, files, and integrations in the workspace. **Scenario 3 — Cross-Portal Privilege Escalation via Shared Auth Backend** An e-commerce platform's partner/reseller portal issued authentication tokens that were validated by the same backend service as the merchant admin portal. A partner-level account (lower trust, external-facing) could use its issued credentials or tokens to authenticate directly against admin-tier API endpoints, bypassing the merchant onboarding and permission assignment flow. Impact: A malicious partner could access any merchant's admin panel, modify store configurations, exfiltrate customer PII and payment data, or install malicious scripts — affecting thousands of merchant storefronts. --- ## Related Skills & Chains - **`hunt-idor`** — Auth bypass without object-level access is half a finding; pair them. Chain primitive: legacy `/v1/users/{id}` route missing both auth middleware AND ownership check = unauthenticated cross-tenant data read via direct ID substitution → full PII dump from "I am nobody" starting position. - **`hunt-ato`** — Auth-bypass primitives feed the ATO funnel. Chain primitive: XMLRPC native-cred acceptance + no rate limit on `wp.getUsersBlogs` → credential-stuff with breach corpus from `hunt-misc` recon → `system.multicall` batches 1000 cred pairs per request → one valid pair = ATO bypassing the SSO + MFA the UI enforces. - **`hunt-sharepoint`** — The SP equivalent of the WordPress XMLRPC pattern lives here. Chain primitive: `/_vti_bin/Authentication.asmx` anonymous reachable + native Forms-auth credential accepted + zero rate limit = unlimited credential brute-force endpoint bypassing custom-branded `customlogin.aspx` protections → FedAuth cookie → full SharePoint farm access. - **`security-arsenal`** — Pull the JWT-attack payloads section (alg=none, kid path-traversal, JWK injection, RS256→HS256 key confusion) when JWT validation is the auth wall; pull the SAML signature-stripping section when the SP accepts unsigned assertions. - **`triage-validation`** — Run the Pre-Severity Gate before claiming Critical on an "auth bypass" that only enumerates usernames or only reveals a 401-vs-403 differential. Username enumeration alone without lockout-amplification is consistently N/A or Informational on H1.

hunt-auth-bypass

Install this skill

Comments