CMS Made Simple Forums

One of our clients found this in their internal testing. The problem is that many site-altering functionalities, like posting news items, in the admin interface are operated through regular HTTP GETs, rather than e.g. POSTs authenticated in some way.

For example, if an attacker finds out that example.com is build on CMSMS, he can create a malicious site, having  e.g. an img element with link
"http://example.com/admin/moduleinterfac ... mit=Submit"
(sorry for the ugly overflowing long string) as its src attribute. If the attacker now is able to get a logged-in admin of example.com to go to his malicious page, an unwanted news item gets added in example.com.

While the above scenario might not be that realistic, the issue, in my opinion, is quite serious.

Hi Janne,
you can avoid this issue using a different name for "/admin" directory, and an creating an .htaccess inside it. (Take a look at this guide for reference).

regards
blast

Thanks for the info. I should've read the documentation more thoroughly. I guess that effectively solves the issue.

Hello all,

thank you for this feed back. If I understand well
-obfuscating the admin directory is easy and prevents this attack (by 404).
-not rendering third site content (img, frame, css...) in the admin browser prevents the attack but is practically rare.
-http auth (with .htaccess) to the admin directory doesn't prevent this attack. Ouch !-(

If I'm not wrong the breach is '/admin' here and I think the installer should randomly set the name of the admin directory to obfuscate it.
Or could moduleinterface.php check referer URL or so ? Would it work ? Would it rely too heavily on the admin browser ?

Pierre

Hi,

I have discussed about this with develpers at IRC. I was most likely the one, who originally found the problem.Obfuscating is really bad way to secure the system, but at the moment only way to do it. The real fix is much more complex. All links which are able modify any data should be secured with additional "CSRF-preventing" parameter. I have suggested, that there is always "vaidation" parameter which is tied to session id, but is not the same as session id. For example md5 sum from the session id is unique enough. That kind of solution is for example at Joomla. (but it's not exactly same.)

(And this is not just "possible security issue". It is real security issue.)

Teme

Hello,

Teme wrote:All links which are able modify any data should be secured with additional "CSRF-preventing" parameter. I have suggested, that there is always "vaidation" parameter which is tied to session id, but is not the same as session id. For example md5 sum from the session id is unique enough.

Very interesting. If I understand well :
-Those links need a secure transaction id.
-This Txid is computed/given with the response to the authenticated user (like cookie thing)
-The third party (intruder) never generates a valid Txid (because it never see cookie thing)

I agree with you it seems an actual serious issue for admins browsing heavily on thrid sites while administring.

Pierre M.

Even with the local site there is real danger, if the local site has interactive components like discussion forums with img-tag. That is not exploiting the post-forms, but it still can cause plenty of problems.

Teme