mojoPortal 2.3.5.2 is now available on our download page.
This is an important security and bug fix release. All users of mojoPortal are urged to upgrade as soon as possible.
Yesterday a security exploit bulletin identifying 2 security vulnerabilities in mojoPortal 2.3.4.3 was posted on the internet. I was able to verify the issues still exist as of version 2.3.5.1, so I immediately began working on a fix. You can see the information on this page: http://www.exploit-db.com/exploits/15018/ however it might be wise to disable javascript or use the NoScript Firefox plugin when visiting that page just out of respect for what these guys are capable of. When I view the source of the exploit information page it seems to have a lot of javascript. Possibly there is nothing malicious about the page but better to use caution just in case.
Issue #1
The first issue listed in the exploit bulletin was an issue in the file manager service where it was possible to target an admin with a social engineering attack to make him visit a malicious web site specifically targeting his site while he was logged in as admin and this would allow the attacker to run some javascript which would call the file service on the ADMIN user's mojoPortal site using the move command to rename the user.config file. If the attack was successful then the site would stop working the next time the application pool recycles because the user.config file is no longer there so it would not be able to find the connection string. From this it is described as a DOS (Denial of Service) attack because it could take the site offline. By renaming the user.config to something with an unprotected file extension like user.config.aaa the attacker could then download the user.config file and capture the database connection string and potentially other sensitive data that might be stored in user.config.
Mitigating Factors
-
if the site is configured as recommended with only the /App_Data and /Data folders being writable by the web process, this attack would not work because the web process would not be able to rename the user.config file in the root. So the site would have to be mis-configured for this exploit to work.
-
this requires a targeted social attack against a specific admin user and a specific site. The admin user would have to be tricked into visiting a malicious site while logged in as admin in his mojoPortal site for it to work, and the malicious site would have to be coded to target the specific mojoPortal site belonging to the user. Also javascript would have to be enabled. When I visit random sites from internet searches or links people send to me, I use Firefox with NoScript plugin, and I recommend you do the same.
-
if the site is actively monitored the Denial of Service would be corrected quickly
Issue # 2
There was a cross site scripting vulnerability on the public profile page /ProfileView.aspx where we were appending the user name/id into the page title without sanitizing it first. Since we were not enforcing any rules on user name/id by default other than it must be unique, a user could register with a specially crafted string to add an external script to the page. The script could be used for malicious purposes such as stealing the authentication cookie of a user who visited the infected user profile page. The fix for this involved both sanitizing the user name/id before we append it to the title and also adding some validation of user names /id when the user registers to prevent characters that can be used for this kind of exploit such as angle brackets.
Mitigating Factors
-
The user name/id is shown on the member list and is html encoded there so that no exploit is possible. It would be easy to spot a malicious user name/id on the member list and then edit the user profile and lock the account.
-
For several versions now we have had an optional config setting for entering a regular expression for user name/id validation. Sites that were already using this would not be affected since the user would not be able to enter the malicious user name.
Potential Issue # 3
This one was not from this exploit bulletin, and is not specific to mojoPortal, but could potentially affect millions of ASP.NET sites. This article was brought to my attention by a community member, George Birbilis.
http://visualstudiomagazine.com/articles/2010/09/14/aspnet-security-hack.aspx
The full details of the vulnerability have not been posted yet so I'm not 100% sure whether it will affect mojoPortal or not. I will have to review it once the full details are posted. However from what I gathered so far, it sounds like a real issue that will affect a lot of sites. When I first read the article, I thought it was saying that the hacker would use error messages received from the server to crack the machine key and then they could forge a cookie to get administrative access to a site. If that is true then it is not as bad because by default no error details are sent from the server, there would only be sent the 500 status code which indicates an error. However from reading comments on a few other places it sounds like they do not in fact need any error details but can gradually decipher the machine key through a lot of requests just using the response status codes 200 (success) 404 (not found) and 500 (error). I took steps in this release in case that is how it works to help protect against this attack. Basically what I did was make it always return a 404 if there is a cryptography error. So if the theory is true that they need to see the 500 status code this solution may protect against it. We will have to wait for the full details to know for sure. As I understand it the full details will be released today at a security conference.
UPDATE 2010-09-18
Microsoft has posted a Security Advisory 2416728 on TechNet which says they are investigating this problem to provide an update. They also provide a workaround. The workaround is basically to use a custom error page so that no error details are returned from the server. We already have that by default in mojoPortal where we use error.htm as the default error page. The only difference in their workaround suggestion, is that they use a custom.aspx page to show the generic error instead of plain html, and they use some logic to make a random amount of time for the thread to sleep so that timing of the 500 status code cannot easily be used as an alternate to error details. I recommend that you copy the C# version of the error page they provide into a text file named ErrorPage.aspx, put it in the root of your web site, and edit the web.config as follows (this is also shown in the Microsoft article):
-
wrap the entire <system.web section inside a location element <location allowOverride="false"></location> - this might cause an error in some installations, if it does just skip it and follow step 2.
-
find this in your Web.config file:
<customErrors mode="RemoteOnly" defaultRedirect="Error.htm">
<error statusCode="413" redirect="~/NeatUpload/Error413.aspx"/>
</customErrors>
and change it like this:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/ErrorPage.aspx">
</customErrors>
That should help defend against possible attacks until an update is available from Microsoft. For more details to understand this problem, see http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx
You should also review the post installation check list to make sure you have configured your site securely.
UPDATE 2010-09-25
Scott Guthrie of Microsoft just posted about an additional protection that can and should be applied at the server level. If you have control of your own server you should take the additional step of installing UrlScan and configuring a rule as indicated in the article.
http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx
UPDATE 2010-10-04
The fix for the ASP.NET security bug is now available in windows update. However, the change has a negative side effect for the current release of mojoPortal which may cause authenticated users to experience an error on your site. The error occurs when trying to decrypt the role cookie which was encrypted before the update was applied. Previously, if there was an error decrypting a role cookie, it was throwing a System.Security.Cryptography.CrypotgraphicException (which we were handling so the user would not experience any error). After the windows update it now throws a more generic HttpException which the current release does not handle so the user will see the error page, and the only way to solve it is to clear the cookie. I have added handling for the changed error for the next release of mojoPortal. There is one workaround you can do right away to solve this problem, you can add code to the ErrorPage.aspx in the root to clear the role cookie so that at least the user will only see the error page one time. To do this, edit the ErrorPage.aspx file with a text editor. At the top add this:
<%@ Import Namespace="mojoPortal.Business" %>
<%@ Import Namespace="mojoPortal.Business.WebHelpers" %>
<%@ Import Namespace="mojoPortal.Web" %>
then add this code to the bottom of the Page_Load event:
try
{
SiteSettings siteSettings = CacheHelper.GetCurrentSiteSettings();
if (siteSettings != null)
{
string roleCookieName = SiteUtils.GetRoleCookieName(siteSettings);
HttpCookie roleCookie = new HttpCookie(roleCookieName, string.Empty);
roleCookie.HttpOnly = true;
roleCookie.Path = "/";
HttpContext.Current.Response.Cookies.Add(roleCookie);
}
}
catch{}
Other Non Security Bug Fixes
-
fixed a long standing issue in the VirtualPathProvider that we use to serve the theme.skin file from the skin folder. For a long time this problem was not very noticeable because most skins did not have much variation in the theme.skin files, but more recently with our support for Artisteer we use settings in the them.skin file to control how markup is rendered so that we can add the needed markup for Artisteer and also the newer jQueryUI skin. The problem was that whatever skin was used first after the application startup, would have its theme.skin file cached and when pages with other skins were used it was getting the copy from the cache because the cache key was identical. Since the one in the cache may not have the correct settings then it could cause it to render incorrectly. The fix was to make sure they are uniquely cached. Note however that VirtualPathProvider does not work under medium trust in .NET 3.5 (it does work in 4.0), in that case all skins use the theme.skin file from App_Themes/default. For those in full trust or in .NET 4 hosting, you should see things work better in this release when using multiple skins or allowing user skins.
-
fixed an issue in folder based child sites where the canonical url rendered in the head was not correct, it was doubling the folder name.
-
fixed a bug where if using related sites mode, newly created sites were not correctly inheriting security settings from the parent site unitl you saved the parent site again and then it would propagate to the child sites.
-
fixed a bug where if using related sites mode, the admin and edit links were not shown consistently to site editors in child sites
-
fixed a bug where jquery script was disabled if you set the StyleSheetCombiner to not load jQuery UI
-
fixed a bug where the Superfish menu was not rendering the mouse over effects in .NET 4 - Thanks to Benedict for the solution!
-
fixed a bug where if FirstName and LastName were used as custom profile properties it was not loading them correctly
-
fixed a pgsql data layer error in the forums feature
-
fixed a SQL CE data layer error in the image gallery
-
added error handling to the feed manager so that if a feed is missing the required channel element it does not crash the page
Follow us on twitter or become a fan on Facebook
