Cross-Site Leaks/XS-Leaks is a less explored security issue that usually comes from Side-Channel Attacks. I found this an interesting vector but unusual.
(2/n)
This basically utilizes the web's core principle of composability in order to determine & extract useful information.
XS-Leaks take advantage of small pieces of information that are exposed during interactions between websites.
(3/n)
Cross-Site Oracle.
This can be considered as a querying mechanism. The information used for this attack is of binary form and called Oracles. It usually has an answer of "Yes" or "No". You can say True or False.
(4/n)
For Example: Does User Harsh Exists in the Application. Yes, means that the user is there in the application.
- An attacker requires to smartly form queries in order to successfully execute this attack and gain hold of sensitive information.
(5/n)
Some of the Attacks using Cross-Site leaks are:
1. XS-Search: An attacker try to abuse the query mechanism such as search functionality to leak and get hold of the user's information.
Remediation
- Same Site Lax Cookies
(6/n)
Usual Exploitation Workflow:
1. Define a timeline when there is a Hit vs Miss 2. Start attacking the Querying Endpoint. 3. For Example: ?search=h (Throws a Hit)
search for the next word appended to `h` i.e. ?search=ha otherwise change the word i.e. ?search=b
(7/n) 2. Error Events
Based on the Error Message returned by the application, it may be possible to enumerate sensitive information. This is similar to user enumeration techniques.
(8/n) 3. Frame Counting
The window.length provides the number of frames in the window. This attribute can provide valuable information about a page to an attacker.
6. Post Message Broadcasts
a. Sharing Sensitive message with untrusted origins
b. Leaking information based on varying content or on the presence of a broadcast
#Learn365 Day-5: Client-Side Template Injection (CSTI) 1. This occurs at the client-side like other JS attacks such as XSS. 2. This is mainly seen in the various JS libraries like AngularJS, VueJS etc which utilize the template engines at the client-side.
(1/n) #bugbountytips
(2/n) 3. The presence of "ng-app" in the page source identifies the use of templates. 4. If the application directly accepts the input and process it without any validation, it may be vulnerable to CSTI. 5. CSTI leads to perform cross-site scripting attacks by escaping...
(3/n) 6. Testing this issue is similar to Server-Side Template Injection. 7. Steps:
a. In the suspected field, provide a payload like {{11*5}}
b. If the response reflected is 55, this tells that there is the use of the template and further you can try performing CSTI to XSS
There are multiple security vulnerabilities associated with the various versions of JIRA software which are exploited in wild and is one of my personal favourite 3rd Party apps to hunt.
(2/n) 1. CVE-2020-14179 (Information Disclosure)
a. Navigate to <JIRA_URL>/secure/QueryComponent!Default.jspa
b. It leaks information about custom fields, custom SLA, etc.
2. CVE-2020-14181 (User Enumeration)
a. Navigate to <JIRA_URL>/secure/ViewUserHover.jspa?username=<uname>
(3/n) 3. CVE-2020-14178 (Project Key Enumeration)
a. Navigate to <JIRA_URL>/browse.<project_key>
b. Observe the error message on valid vs. invalid project key. Apart from the Enumeration, you can often get unauthenticated access to the project if the protections are not in place.
#learn365 Day-3 SAML Vulns
SAML (Security Assertion Markup Language) is widely used for authentication. It uses XML schema and is prone to multiple security vulnerabilities. Some of the common security issues are:
1. XML Signature Wrapping (XSW) Attacks:
(1/n) #bugbountytips
(2/n)
.. XSW Attacks happen when the XML Digital Signature (XML DSig) is not validated which is used to establish a trust b/w IDPs & Service Providers.
This attack can lead to situations like Privilege Escalation, Authentication Abuse & Denial of Service as well.
(3/n)
Good Resource on SAML Signature Attacks: research.aurainfosec.io/bypassing-saml…
Burp Extensions: SAML Raider
There are multiple variants of XSW attacks from XSW1 to XSW8 (Way of exploitation varies a bit). You can read more about them here in little details: github.com/swisskyrepo/Pa…
#learn365 Day-2: Regular Expression Denial of Service (ReDoS)
Due to weakly implemented RegEx Sometimes it is possible to perform a DoS attack by making this expression to evaluate an expression which will make the application work relatively slow. (1/n)
(2/n) Usually, this attack is explored and exploited when the source code is available and you can figure out what regular expressions are used in the code at what fields. For example, at the mobile no input field, what is the regex that validates the mobile no input field.
(3/n) However, you can also try to find this in Black/Gray Box engagements.
Method: Open the JavaScript files and search for the "RegExp(" function and try to figure out what function utilize that particular Regex.
Evaluation: github.com/2bdenny/ReScue This is a good tool...
#learn365 Day-1: 2FA Bypass Techniques 1. Response Manipulation - In response if "success":false, change it to "success":true 2. Status Code Manipulation - If Status Code is 4xx, try to change it to 200 OK and see if it bypass restrictions.
(2/n) 3. 2FA Code Leakage in Response: Check the response of the 2FA Code Triggering Request to see if the code is leaked. 4. JS File Analysis: Rare but some JS Files may contain info about the 2FA Code, worth giving a shot. 5. 2FA Code Reusability: Same code can be reused.
(3/n) 6. Lack of Brute-Force Protection: Possible to brute-force any length 2FA Code. 7. Missing 2FA Code Integrity Validation: Code for any user acc can be used to bypass the 2FA 8. CSRF on 2FA Disabling: No CSRF Protection on disabling 2FA, also there is no auth confirmation.
Before wrapping up 2020, I would like to thank each and every one of you to make this year really amazing. This year has been an amazing journey and completed almost all milestones. Looking forward to more contribution and collaboration with the community. Special Thanks to (1/n)