hunt-auth-bypass – skill Bảo mật cho agent AI

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> Mandatory confirmation gate

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Scope and evidence boundaries

Test only explicitly scoped portals and owned test accounts; discovering sibling hosts or legacy endpoints does not authorize them. Reachability, method lists, status differences or ten uniform failures do not prove bypass, unlimited guessing, absent MFA or account takeover. No credential stuffing, breached credentials, mass multicall guessing or real-user data extraction. Use minimal canary data and stop at the agreed proof boundary. Historical report counts, payouts and case details below are unverified imported claims; validate the primary disclosure and affected configuration before relying on them.

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.

---

SSH certificate-authority trust forgery (Git-hosting / enterprise platforms)

When an org or instance registers an SSH certificate authority, cert principals may not be bound server-side to the requesting identity — a member can mint a cert asserting another user's principal and authenticate as them (e.g. modify another user's resource given only its URL). Add SSH-CA trust to the auth-surface list on Git-hosting targets; niche/platform-specific. Disclosed: reports/1901040.

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:

// 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
• Use only assigned synthetic accounts and pre-approved credentials; no default-password guessing against arbitrary accounts
• 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 minimal authorized impact

• Check only agreed read-only canary resources under owned accounts.
• Do not change privileges, retrieve real users’ data or maximize impact without a separate approved test plan.

---

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

… (nội dung đầy đủ có trong gói tải về)