Last night Mark Kruger, aka. ColdFusion Muse alerted me to something he found about a Mura CMS take over vulnerability. This is the link that I was sent There's a link to a PDF with exact steps to take over and control any Mura CMS site and server. (Note: At the time I was working on this post there wasn't a fix and the above site wasn't updated with a link pointing to the fix.)

A Quick Summary:
Essentially the attacker knows how Mura CMS works and knows the various URL variables. By appending "?display=editprofile" to the URL they can force Mura to show the user registration form. The attacker needs a proxy that can catch the POST of this form so they can edit the form that is submitted. This can be done with many proxy plugins in FireFox or Google Chrome. Again this attack requires knowing the Mura CMS form values that are passed to create an Admin account.

They alter the form fields like this:

ADD - "s2" value 1
ADD - "type" value 2
ADD - "isPrimary" value 1
CHANGE - "isPublic" value 0

Now they have a Mura CMS System Administrator account. Now all they have to do is login by appending this to the URL "?display=login". From here its up to the attacker as to how much mayhem they want to cause. The mayhem can include uploading a "web shell" which then can allow and and all arbitrary file uploads/downloads.

A Quick and Dirty Fix:
So after figuring out we had Mura CMS sites and the above method would work I took the fastest most direct route to prevent the attack from gaining access to the front door. Using IIS 7+ RequestFiltering I added a DENY Filter for the query string "EditProfile". This prevents anyone from gaining access to the form. I did check the source of the form and it does appear to post to with a "doaction" of "createprofile". It might be a good idea to restrict "createprofile" too in order to prevent a remote form posting or to prevent the attacker using another form via proxy to create a new user profile. As I see it if the form fields can be altered via a proxy and the form action is defined in the form fields then any form post can be hijacked and altered to create a new profile with admin privileges.

If your Mura CMS site regularly allows new users to sign up then this quick fix will break that functionality. If this isn't needed then you should be okay. Otherwise there isn't a fix if a site regularly needs to use the EditProfile feature. Mura would need a fix under the hood that would restrict creating admin accounts to admin users that are logged in.

For IIS versions 5.1 and 6.0 you can use the Microsoft UrlScan Extension for IIS to apply the same RequestFilter on the query string.

With Apache the fastest way may be with "mod_rewite" to detect the query strings and redirect to the home page without any query strings.

Mura CMS just released a security fix as I was writing this post.

Even after applying the Mura CMS patch you may want to still restrict access to the "editProfile" page via requestFiltering. If there is no need to create new users then there's no need to have that option available. It would be nice if that was a feature you could turn off in Mura.

And I do agree with blueRiver that it would have been really nice if the security researcher had NOTIFIED blueRiver about the flaw BEFORE releasing it to the world. And blueRiver only "wasted" 2 hours getting this fixed from the time they were notified. That's a phenomenal response time! Congrats on that!