BlogEngine.NET - Serious Security Issue!

A fellow BlogEngine.NET user (who's name I do not know unfortunately) alerted me to an issue on my website where you could retrieve my site's user credentials by accessing the JavaScript HttpHandler via a browser and requesting my users.xml file as seen in the following screenshot.  Now I would not label myself as a "security expert" by any means, but I think this issue falls under the Crazy Bad category. 

Response Screenshot

I took a look at the code in the BlogEngine.Core project and found out that the issue is with the RetrieveLocalScript() method.  Here's the code from BlogEngine.NET Version 1.3:

 

   1: /// <summary>
   2: /// Retrieves the local script from the disk
   3: /// </summary>
   4: private static string RetrieveLocalScript(string file)
   5: {
   6:     string path = HttpContext.Current.Server.MapPath(file);
   7:     string script = null;
   8:     
   9:     using (StreamReader reader = new StreamReader(path))
  10:     {
  11:         script = reader.ReadToEnd();
  12:         HttpContext.Current.Cache.Insert(file, script, new CacheDependency(path));
  13:     }
  14:  
  15:     return script;
  16: }

 

After adding a temporarily fix to not allow my user credentials to be served to the browser (I know - I am a stickler), I decided to do a little research. I attempted to access Mads Kristensens blog's users.xml file (in no way to be malicious) to see if his website handled this issue.  Sure enough, I received a "no access" security exception - see that error here.  If you follow Mads' blog you would also know that he is running the latest beta code of BlogEngine.NET.  I decided to search around in the BlogEngine.NET CodePlex project site for a discussion/fix and what I found is that the JavaScriptHandler.cs file received a bug fix today at 9:30am (1.3.029) - check it out here.  Below is the fixed RetrieveLocalScript() method.  You will notice that only JavaScript files are served now in lines 6-9.

 

   1: /// <summary>
   2: /// Retrieves the local script from the disk
   3: /// </summary>
   4: private static string RetrieveLocalScript(string file)
   5: {
   6:     if( !file.EndsWith( ".js", StringComparison.OrdinalIgnoreCase ) )
   7:     {
   8:         throw new System.Security.SecurityException( "No access" );
   9:     }
  10:  
  11:     string path = HttpContext.Current.Server.MapPath(file);
  12:     string script = null;
  13:     
  14:     using (StreamReader reader = new StreamReader(path))
  15:     {
  16:         script = reader.ReadToEnd();
  17:         HttpContext.Current.Cache.Insert(file, script, new CacheDependency(path));
  18:     }
  19:  
  20:     return script;
  21: }
 

 

Well I would say that is a fairly simple fix for users that have downloaded the full-source code edition of BlogEngine.NET.  What about the users that do not have access to their BlogEngine.Core project?!  I am glad you asked!  I'm offering a clean version (no other changes except this bug fix from version 1.3) of the BlogEngine.Core DLL.  Troy Goode is utilizing this DLL on his live site over at http://squaredroot.com in case you would like to see it in action first!

Update: The patched downloads are available over at BlogEngine.NET - http://dotnetblogengine.net/post/Critical-Security-Patch-Available.aspx.

Hope that helps!

[dnk:http://dannydouglass.com/post/2008/04/BlogEngine-and-the-JavaScript-HttpHandler-Serious-Security-Issue.aspx]

$DNK$

  • Permanent link to this post Permalink 
  • Share this post! Share It! 
  • View this post's comments Comments (42) 
  • RSS Feed for this post's comments Comment RSS
  •    


Comments

Posted on 04.13.2008 22:41 PM #

Troy Goode

Troy Goode us
Thanks for pointing this out and providing a quick fix. Bullet dodged!

Posted on 04.14.2008 00:29 AM #

spence

spence us
Aye! Great heads up! thanks tons!

Posted on 04.14.2008 01:20 AM #

Chris

Chris us
I'd suggest removing the URL of the exploit from the first image.

Makes it very easy for people to reproduce if they get an easy example.

Posted on 04.14.2008 01:52 AM #

Chris

Chris us
I'm not really sure why the check for the .js extension was done on the RetrieveLocalScript function when it would save time by placing it at the top of the ProcessRequest function?

public void ProcessRequest(HttpContext context)
{
string path = context.Request.QueryString["path"];
string script = null;

if (!string.IsNullOrEmpty(path))
{
if (!path.EndsWith("js", StringComparison.OrdinalIgnoreCase))
{ throw new System.Security.SecurityException( "No access" ); }

Posted on 04.14.2008 03:44 AM #

Anastasiosyal

Anastasiosyal gb
Good find. Bad idea to keep the exploit url in the image though...

Posted on 04.14.2008 03:47 AM #

Anonymous

Anonymous us
This doesn't surprise me at all - I've been reading Mad's blog for a couple of years and security always seems to be the last thing on his mind.

Posted on 04.14.2008 04:14 AM #

Ian Suttle

Ian Suttle us
Thank you for the quick heads up. The fix worked like a charm!

Posted on 04.14.2008 05:36 AM #

.nLL

.nLL
i#m glad you have fixed the issue.

Posted on 04.14.2008 08:35 AM #

Justin Etheredge

Justin Etheredge us
Nice catch! Patched!

Posted on 04.14.2008 09:00 AM #

Matt

Matt us
Thanks for the heads up!

Posted on 04.14.2008 09:01 AM #

Will

Will us
Patched.

A better fix would be to rename all files that should never be sent to the client something that ASPNET or IIS blocks itself, such as .config or .cs, .vb, etc.

Posted on 04.14.2008 09:25 AM #

Troy Goode

Troy Goode us
Will, I don't think renaming the files would help in that case though, because the file being served is *technically* js.axd (the HttpHandler). The axd is just outputting the text of the file you specify in the querystring into its response stream.

It does seem to me that perhaps the handlers (are other handlers at risk? file.axd seems a likely culprit...) should specifically forbid serving anything from '~/App_Data/'. Perhaps that would be a better solution?

Posted on 04.14.2008 09:35 AM #

Danny

Danny us
Let me clarify that we should not throw Mads or anyone working on BlogEngine.NET under a train here. It took the community this long to even identify that this security hole existed. In Mads' defense, he fixed this issue in the 1.4 code as soon as it was reported.

Personally I like this fix better because it explicitly denies any files that are not JS files from being served. That just seems like the appropriate way to eliminate risk in the JavaScript HttpHandler. However, I do agree with Troy that an additional global check to forbid anything from the 'App_Data' directory should be made on all the handlers.

Posted on 04.14.2008 11:28 AM #

Hagrin

Hagrin us
While I agree this isn't something to start killing Mads about, this is the second major security flaw in code he "owns" (OpenID implementation being the other). It's just a good reminder that just copying Open Sourced code isn't enough - it still requires the consumer to review the code on their own.

Posted on 04.14.2008 12:39 PM #

Klaus

Klaus us
Thanks for the heads up.
I think security needs to be a major topic for the upcoming release.

Klaus

Posted on 04.14.2008 12:59 PM #

BJ

BJ ph
Thanks for the heads up

Posted on 04.14.2008 13:23 PM #

Korayem

Korayem eg
Whoow..thanx for the heads up.....

Posted on 04.14.2008 13:31 PM #

Tim B

Tim B us
I have a question for you and your readers:

I'm a hobby programmer, disheartened by this news. Even experts leave multiple security flaws, which their programmer users may not notice for quite a while.

Seriously, I've been through the Murach Asp.Net book Wrox "instant results" sample application book, etc. But even after all that, is it really possible for a hobby programmer to write an internet application, post it on the internet, and use it in relative safety?

Posted on 04.14.2008 14:28 PM #

Sean Blakemore

Sean Blakemore gb
Woah! Good catch...

Thanks for the heads up on this one, this kind of thing always reminds me of that feeling you have in a dream where you get up in the morning and go to work and it's not until lunch time that you realise you forgot to put any clothes on.

Posted on 04.14.2008 15:04 PM #

Paul

Paul ph
Darn! Just copied your dll and replaced mine but the problem is still there! grrr!

Posted on 04.14.2008 15:30 PM #

Robbert

Robbert nl
You can find a path for people using the MySQL provider for Blogengine.NET

www.hockblogs.net/.../...-with-MySQL-provider.aspx

gr.

Robbert

Posted on 04.14.2008 15:33 PM #

Troy Goode

Troy Goode us
@Tim B -- I absolutely think it is possible for hobby programmers to safely deploy and use applications that they have written. I would, however, advise that you follow a few simple rules of thumb:
1) Don't ever store passwords as clear text. Use a salt+hash scheme to provide some protection for the passwords in the event that your site is compromised (like this scenario). Take a look at this article here: http://www.obviex.com/samples/hash.aspx
2) Don't ever store credit card information, at all. I can't imagine any scenario where a hobby programmer would need to keep cc information indefinitely. Instead use a 3rd party payment gateway (such as Paypal) who have full-time staff ensuring the quality and safety of their service.
3) Beware of SQL Injection attacks. If you're storing data input by users into a SQL database, you need to make sure they can't use some trickiness to execute code against that database. Take a look at this article for more information: weblogs.asp.net/.../...-SQL-Injection-Attacks.aspx
4) Don't display user input without Html encoding it. You want to be careful that users don't do something like put javascript into their profile description that redirects other users to an illicit website. Make sure you Html encode anything that was entered by a user before outputting it to a webpage.

If you follow the above rules of thumb, you'll cover 99% of the common "uh oh" scenarios programmers (both hobby and professional) commonly find themselves in.

Last, but not least, have fun! Everyone, in every industry, makes mistakes. I'm a professional software developer and make mistakes every day. As a hobby programmer cut yourself some slack and don't let yourself get disheartened; you're doing it for fun anyway, right?

If you ever need any help or have questions about the above suggestions, please don't hesitate to drop me a line: tgoode@squaredroot.com

Posted on 04.14.2008 15:38 PM #

Troy Goode

Troy Goode us
@Paul -- Are you sure the file wasn't just cached in your browser? Try clearing your temporary internet files and accessing that page again, I think you'll see that it is now blocking access to that path.

Posted on 04.14.2008 17:02 PM #

Ryan Lanciaux

Ryan Lanciaux us
Thanks for the heads up and your work on this -- Just as an FYI, at least for me your stylesheet is not showing up. I have had this happen to me before when I was getting some amount of traffic. It seemed that if I turned off the 'Trim stylesheets' option everything was fine.

frickinsweet.com/.../...pear-in-BlogEngineNET.aspx

Posted on 04.14.2008 17:40 PM #

Troy Goode

Troy Goode us
@Ryan Lanciaux -- Wow. I've been having that issue as well for a long time now. If that fixes it... I owe you a beer. =)

Posted on 04.14.2008 18:42 PM #

Danny

Danny us
@Ryan Lanciaux - THANKS! I really appreciate the heads-up. Make that two beers!

Posted on 04.14.2008 18:44 PM #

Danny

Danny us
@Paul - I believe Troy's comment above explains the issue you are having. If you would like me to test the link (and no I won't steal your password or blog) I'd be glad to help. Shoot me an email if you want the verification.

Posted on 04.14.2008 18:50 PM #

Danny

Danny us
@Anastasiosyal - I removed the URL after reading the BlogEngine.NET post.

Posted on 04.14.2008 20:54 PM #

Ryan Lanciaux

Ryan Lanciaux us
Glad that worked out for you!

I haven't had a whole lot of time to look into it just yet and it's hard for me to replicate locally but I hope to figure out a way to fix it so that there can be compression AND working CSS Smile

Posted on 04.15.2008 10:33 AM #

Scott

Scott us
Good Find Danny. I would have blogged about it, but you beat me to it. Good hit and good fix. I think the credit goes to ha.ckers.org/.../ for they look like they are the ones who found it first, seeing his post is before yours.

Good job though on reporting it ASAP.

Posted on 04.15.2008 11:11 AM #

Danny

Danny us
Important Update
For anyone following this comment thread, please take the time to vote for the "Password Encryption in XML file" work item on BlogEngine.NET's Codeplex project page - www.codeplex.com/.../View.aspx

Posted on 04.15.2008 12:55 PM #

Morten

Morten us
The real question is why the hell the passwords are stored in cleartext??!?!?!?

Posted on 04.15.2008 18:29 PM #

Jesse

Jesse us
Does this effect people using Active Directory providers or just the default provider? I tried to download the patch but it just errors out

Posted on 04.15.2008 20:38 PM #

Troy Goode

Troy Goode us
Jesse, it should only affect people using BlogEngine's default xml provider. I wasn't even aware that there was an Active Directory provider for BlogEngine...

Posted on 04.17.2008 18:56 PM #

ModPack Mike

ModPack Mike nl
Oh boy, that's an ugly security hole and I'm glad you shared your useful ins and outs, Danny!

Wishing I discovered your info earlier, so the security hotfix for ModPack (based on BlogEngine.Core 1.3.0.5) would have been online faster.

It's available now anyway, so if bloggers on ModPack read this - make sure to patch your blog installation too with the ModPack version.

Cheers,
MikevZ

PS: voted for encrypted passwords and linked to it in my post

Posted on 04.18.2008 00:40 AM #

Danny

Danny us
Thanks Mike!

Posted on 04.18.2008 03:59 AM #

krishnan

krishnan in
It will be better that you remove the link which you pointed to the error of Mads Kristensens blog, Since that shows the URl and which will tell others how to do this.
Just a suggestion thats all.

Posted on 04.24.2008 18:48 PM #

Chris

Chris us
it should only affect people using BlogEngine's default xml provider.

That is absolutely incorrect. This vulnerability will allow access to almost, if not all, files in the website. The reference to the users.xml file was just an example of how serious this was. It is just as easy to access the web.config, sql.config, and anything else that exists in the web site. So even if you are not using the XML provider be sure to apply the patch!

Posted on 06.1.2008 22:48 PM #

Rice Blogger

Rice Blogger my
Hello,

i stumble across your blog searching for a blog platform for asp.

And I guess this is actually not good to find a security issue....how is it so far, have they updated?

Posted on 06.2.2008 08:38 AM #

Danny

Danny us
@Rice
Overall I am very happy with BlogEngine.NET. The extensibility, flexibility, and active community are three strong reasons to consider using this OS application. The security flaw received a patch very quickly from the BlogEngine.NET staff with the release of the minor version 1.3.1.

Feel free to email me if you have further questions - ddouglass@gmail.com.

Cheers.

Posted on 06.12.2008 14:54 PM #

Daniel

Daniel mx
gracias por su valiosa información

Posted on 06.12.2008 14:55 PM #

Daniel

Daniel mx
gracias por su valiosa información

Add comment


(Will show your Gravatar icon)  

  Country flag

[b][/b] - [i][/i] - [u][/u]- [quote][/quote]



Live preview

Posted on 07.4.2008 15:21 PM #


search


AddThis Feed Button

blog categories

blog tags

my pictures

Flickr Gallery Coming Soon!

recent comments   RSS Feed for this post's comments