I’ve been wanting to write this earlier today but it was a typical busy Monday. It’s about the recently published vulnerability in ASP.NET. I was looking at my twitter feeds this past Sunday to see what people I’m following are up to. I came across Tom Resing’s tweet about Security Advisory 2416728. The advisory came out Friday night (September 17) but I didn’t read about it till yesterday. I looked into it and was troubled by what was described in the article. In the article, it says;

At this time we are not aware of any attacks using this vulnerability and we encourage customers to review the advisory for mitigations and workarounds.

Oh yeah, add the fact that the article starts with:

Today we released Security Advisory 2416728 describing a publicly disclosed vulnerability in ASP.NET that affects all versions of the .NET Framework.

If those lines don’t get your attention, I don’t know what will!

A detection script was made available also at the TechNet article “Understanding the ASP.NET Vulnerability”. The script is ran as a VBScript and will report all Web app configurations that are vulnerable. If your apps are not vulnerable, the script will report “OK” on the app. The report looks like the following:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Enumerating possible paths with ASP.Net configuration that have custom errors turned off.

C:\inetpub\wwwroot\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp1\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\2639\wpresources\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\4444\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp2\web.config: ok

If your app shows “Vulnerable configuration found”, then the Security Advisory is applicable for that app. You want to see “ok” like in the last line of the example above.

The vulnerability is called “Padding Oracle Exploit”. The attacker will attempt to send tampered data to the web server and the web server will generate error messages. As more error codes get returned to the attacker for the tampered requests, the attacker can learn what the encryption is. Once the encryption is compromised, the exploit beings. This vulnerability will allow an attacker to read data, even encrypted ones such as data stored in the View State, and even download files such as the web.config file from the target server. (But requests for web.config files cannot be served by IIS, right???) Scott Guthrie explains in his blog how this vulnerability works. Scott also explains how to workaround this issue. Before a patch or security update appears, this is the best tool against the exploit provided by Microsoft.

You say “But I never store sensitive information in the View State!” Well, read on. In the Microsoft TechNet Security Advisory (and even Scott’s blog post), the workaround’s main theme is homogenizing the error page. The TechNet security advisory says “Homogenizing errors is a crucial component to help protect against this attack.” This means turning customErrors to “On” and explicitly specifying the defaultRedirect page. For full details, please read Scott Guthrie’s blog post.

Now, you might say, this is just another over-hyped, exaggerated propaganda by the Microsoft haters. Well you can throw that argument out the window since it is Microsoft itself that is telling its customers about the vulnerability. There is also a Common Vulnerabilities and Exposure entry for this. The CVE entry says it just has a “candidate” status on it right now and may even be “rejected in the future”.  Is that grounds for ignoring it because it’s just a “candidate” CVE entry? Is it really worth ignoring because the probability and severity of the exploit has not been fully established yet? For public-facing sites, I recommend you implement the workaround as soon as possible. The workaround is fairly cheap to implement—just do it! There will be many apps that will be fine and no workarounds would be necessary (their customErrors configuration is already protected against this exploit). But if the detection tool above says “vulnerable” on your site, and the site is public facing, all I can say is “Wow!” should you decide to ignore it.

I was viewing my blog today and noticed the tag cloud on my sidebar. The most prominent tags are “SharePoint”, “Developers”, and “Administrators”. SharePoint. Developers. Administrators.

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!

It’s been a while since I’ve worked with WSS 2.0. I have a customer (a friend of mine) who is still running a WSS 2.0 in his business. He runs a small shop and doesn’t have a full-time person to take care of this network and applications. Well, one time he had a FT person but that person left and he’s managing this servers with some help from a PT person.

The WSS 2.0 environment has “moved around” a lot. The front-end and SQL backend has been toasted at least once and the environments had to be recreated from scratch. The only backups they had were SQL backups. The SQL backups were okay.

Now, he wants that WSS 2.0 upgraded to WSS 3.0. I thought, well, this should be easy–only one Web front-end and one SQL server. Also, he had no intention of keeping WSS 2.0. So, just do an in-place upgrade, and it should be done, right?

Well, I ran into problems when I did the pre-upgrade scan prior to running the WSS 3.0 Configuration Wizard. You’re supposed to run the pre-upgrade scan tool prior to upgrading WSS 2.0 sites to WSS 3.0. Otherwise, if you run the Configuration Wizard without running the prescan tool, you will get:

Configuration Failed.
One or more configuration settings failed. Completed configuration settings will not be rolled back. Resolve the problem and run this configuration wizard again.

To run the prescan tool, go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin and execute the following command:

prescan.exe /all

(For more details, see the Microsoft KB article 938216. )

When I ran the prescan tool, I encountered errors and it says on the log file:

Upgrade has encountered one or more lists that were not updated by Prescan.exe and must exit. The most likely reasons for Prescan to skip a list are covered in the Knowledge Base article at: http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409 (http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409) For more information about the lists that are not upgraded, see the upgrade log file.

It seemed like there were orphaned objects. I told you, this WSS 2.0 had been recreated a few times and they used SQL backups to restore the contents. Things have been orphaned or convoluted along the way. Oh yeah, the Web front-end server also had several (non-WSS) virtual sites that were running on port 80; they were differentiated only via the use of host-headers. I couldn’t find the orphaned objects to drop and realized that the I’m stuck and couldn’t proceed with the upgrade. I spent an hour performing the recommendations on how to repair/remove orphaned lists and then I stopped.

So here’s what I did instead:

1. Backed up the WSS 2.0 site collection using stsadm
2. I restored the WSS 2.0 site collection in a different environment/farm. I used my home lab environment for this.
3. I then upgraded my home lab WSS 2.0 to WSS 3.0.
4. I backed up the WSS 3.0 site collection using stsadm. Now I have the site upgraded to WSS 3.0.

Only thing I have left to do is cleanup the Web front end server at my customer’s site and re-install WSS 3.0 without the upgrade option. Once WSS 3.0 is installed and configured, I can restore the site collection. I’ll do that tomorrow.

Sometimes, you just have to do what you have to do to get the job done.