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:




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.


Or


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.