Archive for the ‘Security’ Category

Open Source Risks

It’s really surprising to me than a widely reported recent WordPress plugin hack was mostly brushed off as just another system getting hacked. I really see this as a much bigger issue. While the WordPress team did a good job of detecting and handling the situation, they still forced password resets on everyone using the system. As a developer, it looks like they were not 100% sure they had closed all the loopholes or found all the malicious code.

How did the hack actually happen? The hackers managed to impersonate developers on the project and check in a very few lines of code that created a back door for the hackers to get in through. At some point this was caught by the team reviewing check-ins, but the across-the-board password reset makes me wary. This post makes it seem like the code made it into the repository and was available to some users for a short period of time.

The bigger issue here is that hackers are actively targeting open source projects. This problem is much bigger than the hack itself, and no one is talking about it in the online conversation (that I have found). Large companies already prohibit the use of open source for this very reason, and are being proved right. Enterprise developers are forced into building sub-optimal solutions since they can’t use open source.

In this instance the project team was diligent enough to catch it before it got too far. What about other projects? Are there back doors out there now. I’m certain there are. As a developer, what is the quantifiable risk of using an open source library? We need to address this situation without killing the collaboration and openness of open source.

The large companies are addressing this by getting smaller companies to indemnify the open source project and take on the risk of being sued if a hack gets through. While this is working on some fronts, it certainly doesn’t scale. There are thousands of open source projects, most of which will never see indemnification by a third party.

I don’t have the solution in hand, but it seems to me the conversation needs to get moving.

Posted on:
Posted in Security | Comments Off on Open Source Risks

Why you should care about password length

Jeff Atwood shows us why we should consider better password policies when developing applications or setting company policy.  

As we know, the biggest threat to security is not hackers, but the users themselves making it easy for someone to gain access to protected resources by having ridiculously easy to guess passwords. As developers we are as much at fault for building applications that allow this behavior.  Jeff recommends using pass phrases instead of passwords. A phrase is longer (and thus more resistant to brute force) and easier to remember than a mixed up jumble of nonsensical characters. By adding an unusual word or character pass phrases are very difficult to break with dictionary attacks as well.  Pass phrases are controversial as well, see:

The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3

The Great Debates: Pass Phrases vs. Passwords. Part 2 of 3

The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3

Personally, I think the hard part is convincing users and business owners of an application that longer or more complicated is better. From my own experience I understand users want the simplest password policy possible. Often the business owners of an app don’t feel the information being protected is all that important to justify such an imposition for the users, or feel that it becomes a support expense because users can’t manage their own data or password very well (a great argument for using something like Windows CardSpace). I think they forget that users re-use the same password everywhere possible: a free e-mail account, network access at work, bank web sites, a blog, a MySpace account, etc. I would not want to be responsible for a malicious person to gain a password from my system and then use that password to systematically destroy someone else’s life. Be strong, insist on good password policy.

Posted on:
Posted in Security | Comments Off on Why you should care about password length

Web Services Authentication Gotcha

We had code in an ASP.NET page trying to call the Commerce Server Profiles web service that resides on the same physical box. The credentials we used were appropriately configured for Commerce Server using AzMan. For some reason, the code was failing with a 401: Unauthorized error. No matter what credentials we used, no luck. But if you ran the code from another box, it worked fine. Same credentials pointing to the service on that box, no errors.

Turns out the hosts file had an entry for the DNS name we were using, and mapped that name to 127.0.0.1, the loopback address. This was the gotcha. Apparently there is a loopback security feature that causes this behavior. There is a support article describing the effect. Essentially it is a security check to keep certain kinds of attacks at bay. The article suggests registry changes to disable it, but we took a different route.  In the short term, if the calling code accessed the web service via IP address (NOT 127.0.0.1) instead of DNS name the problem was circumvented. Meanwhile the network guru is working to get the actual DNS resolution to work.

More SelfSSL Issues

I blogged previously about some issues with SelfSSL and multiple web sites. A colleague of mine, Charles Medcoff, blogs about a related problem with SelfSSL and SQL Server.

Posted on:
Posted in Security, SQL Server | Comments Off on More SelfSSL Issues

ASP.Net Single Sign On – Same Domain

This post in the ASP.Net forums has been the best method for me to make a single-sign on work across different sites in the same domain.

You have to set the machine key in the web.config of all sites even on the same physical box.

Posted on:
Posted in ASP.NET, Security | Comments Off on ASP.Net Single Sign On – Same Domain

Don’t Re-Invent the Wheel – The .NET Developer’s Guide to Identity

Learn how to leverage Active Directory in your .Net apps:

The .NET Developer’s Guide to Identity

Posted on:
Posted in Security | Comments Off on Don’t Re-Invent the Wheel – The .NET Developer’s Guide to Identity

ASP.Net Windows Authentication and 401.2 Errors

I am working on an ASP.Net app that usesWindows authentication for users. I have a certain section of the app, the “Administration” set of pages that I want to exclude from certain roles of users. This is easy using a web.config file, but the unauthorized users get an ugly default 401.2 error page. I would like to have a custom page for that, and surpisingly there was not a ton of information out there on how to do it. In fact, more often than not the answer was “It can’t be done.”

I did find an acceptable answer in the forums at aspfree.com. Essentially the solution is to handle the Application_EndRequest event in the global.asax and check the status code and authentication of the user. Here is my version:

void Application_EndRequest(object sender, EventArgs e)
{
    if (Response.StatusCode == 401 && Request.IsAuthenticated && Request.Url.AbsoluteUri.Contains(“Administration”))
    {
        Response.ClearContent();
        Server.Execute(“../NoAccess.aspx?id=Administration”);
    }
}

 

I don’t believe this method will work with Forms Authentication, I ran across plenty of posts saying that it works differently.

Posted on:
Posted in ASP.NET, Security | Comments Off on ASP.Net Windows Authentication and 401.2 Errors

SelfSSL and Site ID

SelfSSL is a tool found in the IIS 6.0 Resource Kit. It allows you to generate SSL certificates for a development environment. In all the instructions for using SelfSSL, it describes one of the parameters as “Site ID”, where the default value=1, which is the default web site installed on the computer. The Site Id parameter is essentially telling SelfSSL which web site to install the certificate into. Well, if you have multiple web sites, then the default site id is useless. You need the Site Id of the web site where you want the certificate installed. Of course the documentation does not spell this out, and as a non-Admin the Site Id was not an intuitive term for me. But I found that there is a script you can run from the command-line called iisweb.vbs using the /query switch. That will tell you the Site Id. Seeing that, then I realized that the IIS log file folders (in windir\System32\logfiles\) are named according to the Site Id.

Anyway, creating a second certificate for a different site on the same IIS using SelfSSL messes up the SSL cert of first site. This is a known issue apparently, and David Wang has a great post on this problem. The comment further down by Paul Carrig is most useful, as he points out there is a workaround for the SelfSSL and multiple site issue. So I actually found two workarounds:

  1. The technique described by in the aforementioned post:
    1. Install the cert in the first site
    2. Export it to a .pfx file
    3. Install the cert in the second site
    4. Remove the cert from the first site
    5. Re-Import the cert to the first site using the .pfx file

      or

  2. Install the cert in the first site, and export it to a .pfx file. Then import that to the other sites. The down side to this is that the certificate is even less valid for the second sites as now it has an untrusted publisher (me!) and the site name is not a match. The prompt is essentially the same, but in our case one site contains web services which will throw an error if the prompt comes up at all (as it should). The workaround for that is to install the certificate on the client computers as well, which is an acceptable problem for a development enviroment.
Posted on:
Posted in IIS, Security | Comments Off on SelfSSL and Site ID

Securing the Connection String with the Machine Key

d.code asks about securing connection strings. If you are willing to deal with a little unmanaged code, you can use the machine key or a user key via Data Protection API (DPAPI) functions instead of hiding your key somewhere. I first heard about the machine key at a Microsoft Security Summit that was touring around the country last spring. I based my work on this example, and a relevant MSDN article. The upside is that you do not need to maintain your own key somewhere, the downside is that any application run on the computer could decrypt your string, and that an encrypted string cannot be passed between computers (or users if you go that route), so you have to create the encrypted strings during deployment and have access to run an executeable on the production computer during deployment.

I created a small Winforms program that I run during deployment to encrypt my connection strings using the machine key. It just has two text boxes and two buttons for encrypting and decrypting strings. Once the deployment is done the exe is removed from the production machine. If someone compromised the box, they would have to know you used DPAPI (which they could only determine by spending the time to decompile your assembly) and have their own exe ready or create one to decrypt the strings. A little obfuscation on your code would contribute to the security in this situation.

Posted on:
Posted in ASP.NET, Security, Winforms | Comments Off on Securing the Connection String with the Machine Key

Custom Text File Publisher for Exception Management Application Block

I needed to create a publisher for exceptions to a text file (XML would be better but the requirement was for text…). I based my publisher on this article I found on C# Corner. But it has one problem associated with using files, that unfortunately loomed large. Concurrency. To a certain extent the code handled the problem by tossing the error into the Event Log if the provider threw an error, but this was not acceptable for my requriement. So I needed to modify the code to handle the issue. Essentially, I modified the overriden Publish procedure to trap the error related to the StreamWriter and then sleep for a set amount of time and try again. After too many failures at writing to the file the error eventually gets written to the event log (so it is not lost).

privateconst int WriteAttempts = 5;
private const int SleepTime = 500;

void IExceptionPublisher.Publish(Exception exception, NameValueCollection additionalInfo, NameValueCollection configSettings)
{

    // Read and set up configuration
    SetConfig(configSettings);

    // Create fileName
    string logFilePath = CreateLogFilePath();

    // Create Message
    string logMessage = CreateLogMessage(exception, additionalInfo);

    int attempts = 0;
    bool written = false;

    // Write the entry to the log file.
    while(!written && attempts <= WriteAttempts)
    {
       
try
       
{
            // Append to file if exists or create new file
           
using ( FileStream fs = File.Open(logFilePath, FileMode.Append,FileAccess.Write))
            {
               
using (StreamWriter sw = new StreamWriter(fs))
                {
                    sw.Write(logMessage);
                    written =
true;
                }
            }
        }
       
catch
       
{
            attempts++;
            Thread.Sleep(SleepTime);
         }
    }
    if(attempts > WriteAttempts)
    {
       
throw(exception);
    }

}

Posted on:
Posted in .Net 1.1, Security | Comments Off on Custom Text File Publisher for Exception Management Application Block