Hunting for Vulnerabilities that are ignored by most of the Bug Bounty Hunters — Part 1

3 months ago 61

BOOK THIS SPACE FOR AD

ARTICLE AD

Hey Guys! Hope y’all doing well.

I hope you read my previous write-ups and if you haven’t, check them out as it may add something to your Infosec knowledge.

Today we are going to learn a couple of vulnerabilities that are not discussed much, we’d learn how to identify them, exploit them and we’d also discuss the remediation. Instead of focusing on the theory part, I’ll try to focus more on the practical part so that you guys can comfortability test for these vulnerabilities during your bug hunting/ penetration testing activities.

So lets get started:

We all have heard about XSS but have you ever heard about XSSI?

It is a vulnerability that allows leakage of sensitive data from one domain to another domain. This data could include login information such as tokens, cookies, sessionIDs etc or user’s personal information such as mobile number, credit card/ debit card information, email, address etc.

To understand this vulnerability we have to understand two things, Same Origin Policy and Dynamic Javascript.

Same Origin Policy ensures that websites are only allowed to access data if they are from the same origin. But the irony is HTML <script> tags are not covered by this policy which is an absolute necessity as without it the websites won’t be able to consume third party services, perform traffic analysis or use Ad-Platforms.

Dynamic Javascript code expects session token to fetch certain data. For example there is a JS function called info.js hosted at https://testsite.com/info.js. Request-1 is sent to https://testsite.com/info.js using authenticated sessions cookies of a user to get Response-1. Now Request-2 is sent without any session cookies and a Response-2 was received.

If Response-1 and Response-2 are different, then info.js is a Dynamic Javascript code. ( It can be automatically detected using burp plugin DetectDynamicJS, but in order to ignore false positives and missing out juicy endpoints, I’d suggest also checking the same manually).

Now, XSSI attack happens when sensitive information is being stored in the Dynamic JS files or in JSONP files( Regular JSON follows the Same Origin Policy so does HTML however, JSONP loads the script element hence the SOP is bypassed). Note that JS and JSONP are most common file types for XSSI however XSSI is not only limited to JavaScript it may occur in other file types for example CSV.

Lets understand XSSI Attack with an example.

Suppose there is a url https://vulnsite.com/p/?showinfo=abc which can only be accessed through authenticated users. Hitting the url gives reponse like this:

{ “name”:”vflexo” , “mobno”:”9876543210”, “email”:”redacted@gmail.com”, “address”:”101 Alien Apartments, Dacoit Streets, Pandora”}

An authenticated user can check in the new tab in the same browser if the https://vulnsite.com/p/?showinfo=abc is giving him the above response.

Now, the attacker can host a site let’s assume attacker.com and add the below code on it’s index.html or any other page.

<html>
<script>
function aaabc(s)
{
alert(JSON.stringify(s));
}
</script>

</html>

When the attacker delivers the url https://attacker.com/index.html to an authenticated victim, the victim data gets fetched and attacker can check it on his log server(of attacker.com).

The below data:

{ “name”:”vflexo” , “mobno”:”9876543210”, “email”:”redacted@gmail.com”, “address”:”101 Alien Apartments, Dacoit Streets, Pandora”}

Gets stolen.

Similarly, this vulnerability can lead to exposure of even more critical data depending on the endpoint and the application.

Remediation:

To avoid XSSI attacks, don’t interpolate sensitive data in JavaScript filesuse JSON URLs instead (Not JSONP), or encode the data in the HTML of page itself. JSON and HTML content types are subject to the browser’s same-origin policy, so they can’t be used in XSSI attacks.

Due to HTTP response splitting, the site may allow returning two HTTP responses for a single request.

Let’s understand this with an example site https://vulnerablesite.com. Asssume the page parameter in the url https://vulnerablesite.com/redir.php?page= is if supplied with %0d%0a (%0d%0a => URL encoded form for new line) then it is going to start the new line in the response hence it will breaking the current line in response and start a new line.

Now observe the below request and responses:

Request:

https://vulnerablesite.com/redir.php?page=http://other.vulnerablesite.com%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>deface</html

Response 1:

HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 15:26:41 GMT
Location: http://vulnerablesite.com/redir.php?page=http://other.vulnerablesite.com
Content-Length: 0

Response 2:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Deface</html>

It can be observed that the vulnerable application gave two responses for a single request due to failure of validation of CR and LF and header misconfiguration. Hence, an attacker can use the vulnerability to deliver malcious content to it victim by tricking them to click the malicious URLs containing the exploit payloads.

Remediation: The below mentioned remediation steps are required in order to prevent and mitigate the vulnerability.

A) Validation of the input data (CR and LF).
B) Forbid HTTP headers nesting in one header’s field.

This vulnerability occurs when manipulation of certain parameters in a web application leads to unexpected behaviour like authorization bypass or information disclosure or business logic errors.

Suppose we have an edit profile page on https://vulnsite.com/editprofile.php

Now assume that we have an member.php file which is responsible for managing application user. An example of such file would be like this:

When a user wants to edit their profile, they must use the “edit account” option in the “editprofile.php” page and enter their login information. However, using “|” as a parameter delimiter on email field followed by “admin”, the user could elevate their privileges to administrator. Example:

Username: Vishal Password: Demo@12345 Email: Vishal@vflexo.com |admin|

This information will be recorded in “mem.php” file like this:

In this case, the last parameter delimiter considered is “|admin|” and the user could elevate their privileges by assigning administrator profile.

Although this vulnerability doesn’t allow manipulation of other users’ profiles, it allows privilege escalation for application users.

Remediation: Input Validation should be properly implemented.

This vulnerability occurs in web applications when user controlled input is placed in email templated without proper sanitization allowing attacker to add additional header with arbitrary values.

Suppose we have an application that allow creating organisations and it has an “invite users” feature. Lets say user1@gmail.com is invited by user2@gmail.com to his organisation EvilCorp through the invite feature, the email through which invitation gets sent is invite@vulnsite.com and the subject of the email is “Invitation — EvilCorp” . Now it is clearly evident that EvilCorp is a user controllable input. An attempt can be made through this user controlled input for SMTP Header Injection by using \r\n and custom headers.

If the user1 changes the organisation name from EvilCorp to “Phishing\r\nContent-Type: text/html; charset=UTF-8\r\nContent-Transfer-Encoding: base64\r\n\r\nPGgxPkhleSB0aGVyZSEgVGhpcyBlbWFpbHMgY29udGFpbnMgPGk+SFRNTDwvaT4gbm93ITwvaDE+PCEtLQ==” and then the user2 is invited using invite users feature, the email content totally changed with subject as Phishing and ”Hey there! This emails contain HTML now!” as email content body.

( base64\r\n\r\nPGgxPkhleSB0aGVyZSEgVGhpcyBlbWFpbHMgY29udGFpbnMgPGk+SFRNTDwvaT4gbm93ITwvaDE+PCEtLQ== is base64 encoded form of <h1>Hey there! This emails contains <i>HTML</i> now!</h1><! — )

Example of SMTP Header Injection:

(Note: Assume that that there 200+ characters are allowed on organisation name or the length limit restriction has been bypassed)

Sometimes the email templates contains parameter values which are not controllable through UI, for such cases you can use burpsuite and see if the values reflecting in the email templates can be found in request parameters. If yes, you can manipulate parameter values and manipulate email content for mass users for the vulnerable sites.

Impact: This feature can be leveraged to perform large-scall phishing operations. Malicious users can use this flaw in order to send arbitrary emails to large amounts of recipients, all coming from a valid, signed email from the official email of the site.

Remediation: Validate that user input conforms to a whitelist of safe characters before placing it into email headers. In particular, input containing newlines and carriage returns should be rejected. Alternatively, consider switching to an email library that automatically prevents such attacks.

After a certain number of failed logins on a web application, the account lockout policy locks out the user for a certain amount of time which is a security feature. However, if the lockout is not configured properly , it can lead to a security vulnerability called Overly Restrictive Account Lockout that leads to denial of service for that particular user.

How to test for it?

Use your WiFi connection and make 50 unsucessful login attempts on a site using burpsuite intruder, lets assume that the username is vflexo, use a wordlist of 50 wrong passwords. If you see the error that your account has been locked then change your internet connection from WiFi to mobile hotspot and send a login request for the same user vflexo.

If the lockout error still persists even after changing the internet connection, it means that the lockout policy is only considering username in order to lockout login attempts.

Any attacker can launch infinite bruteforce againsts any user of the site and the user will never be able to login to the application due to misconfigured lockout policy. Even if the site-support unlocks the user account, it will be quickly locked again because an attacker is going to launch a bruteforce with wordlist of millions of passwords to make sure the user never logs in.

Below is the demonstration of this attack:

Step1: After multiple failed login attempts for user victimuser8@gmail.com through WiFi connection, account lockout was achieved.

Step2: Internet connection changed to Mobile Hotspot.

Step3: Request was repeated using WiFi but still it shows the lockout error.

Step4: Login attempt made for the user using UI through Mobile Hostpot connection still it shows lockout error confirming the vulnerability.

Now the lockout policy is also not expected to take consideration only on the basis of IP because the attacker can use IP Rotators to bruteforce a user.

Remediations:

Implement more intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name.Consider alternatives to account lockout that would still be effective against password brute force attacks, such as presenting the user machine with a puzzle to solve (makes it do some computation).

Thats all for today, I hope you enjoyed reading and I’ll be releasing the part 2 of this writeup to share information about a few more vulnerabilities which are usually ignored by the bounty hunters and penetration testers.

Till then, stay tuned.

And yes! Clap for me if you enjoyed reading ;)

See ya later!!!!!

-Vishal Aka vFlexo

Read Entire Article