James Kovacs' Weblog

What is SecurityKicks.com?

SecurityKicks.com is a community-based news site edited by our members. It specialises in security information for developers, including writing secure code, authentication and authorization techniques, cryptography, and related topics.

Individual users of the site submit and review stories, the most popular of which make it to the homepage. Users are encouraged to ‘kick’ stories that they would like to appear on the homepage. If a story receives enough kicks, it will be promoted.

What is a kick?

Kicks are votes of approval from our members. If a story has 16 kicks, that means 16 users liked it. The more kicks a story receives, the more likely that it will appear on the homepage. If you don’t like a story, don’t give it a kick.

How do I submit stories?

You simply need to register for a new account. With an account you can submit stories by clicking the ‘Submit a story’ link on the right menu of the homepage.

How do I find stories?

To find stories that have not been promoted, click the ‘Find stories‘ link on the right menu of the homepage. You can also click the ‘find’ link beside each category in the list of categories.

Who are the brains behind this operation?

The original idea for the site was mine, but Gavin Joyce, creator of DotNetKicks.com, deserves the bulk of the credit. He not only set up the site, but is also hosting it. Hats off to Gavin!

I hope you find SecurityKicks.com to be a useful resource for finding developer-related security information. Welcome and enjoy!

Ryan Byington (BCLTeam Blog) just posted some great information on how to query performance counters as a non-admin on Windows Server 2003, Windows XP x64 Edition, and Vista:

How to Read Performance Counters Without Administrator Privileges

You are running as a non-admin, aren’t you?

Fellow plumber, Bil Simser, asks the question how the heck does someone debug SharePoint as a non-admin. Elementary, my dear Simser, elementary…

The fundamental problem that Bil is experiencing occurs with SharePoint, ASP.NET, or any app that runs under a different security context than your own. A normal user can only debug applications running under his/her own security context.* Administrators have the SeDebug privilege, which allows them to debug processes running under any security context. Granting your user the SeDebug privilege gives them tremendous power, which is exactly what you’re trying to avoid. (With SeDebug, you can open any process, including system processes with full permissions. If you can do that, you own the box. I leave it as an exercise to the reader to figure out how, given only SeDebug, to elevate your normal user to be a member of the local administrators group.) I know of a few solutions to allow debugging of server processes:

1. Develop server apps in an isolated virtual machine and use an admin account.
2. Run as admin when debugging server apps, but run as a normal user while developing them. (This can be done using MakeMeAdmin and then running devenv.)
3. Run the server app under your user account, though this may mean placing your username/password in clear text, which is non-ideal. (This is the strategy used by the Visual Web Developer Web Server – aka Cassini – that ships with VS 2005.)

* Note that although you don’t require any special privileges to debug a process running under your own security context, Visual Studio does enforce that you need to be a member of the Debugger Users group.

EDIT: Additional information added below related to Bil’s comment.

Bil is correct. If you run Visual Studio as a non-admin when developing server apps and you want to debug, you need to break stride and launch another copy of Visual Studio using MakeMeAdmin or runas. This is highly non-ideal. Is it a huge security risk to run Visual Studio under an admin account while the rest of your log-in session is running as a normal user? Somewhat, but it’s a lot better than running your entire log-in session as an admin.

Also remember one of the main reasons for developing apps as a non-admin – to ensure that you are running/debugging with credentials similar to what your end users will be using. (i.e. Your app isn’t writing to protected regions of the file system or registry to which normal users don’t have access.) With server apps, the story is a bit different. You want your server app to be running with different credentials – the credentials of the account that the application will be running under in production – NETWORK SERVICE or other service account. The safest solution is #1 above. Develop server apps as an admin in an isolated virtual machine. Second would be running only Visual Studio under elevated privileges using technique #2. Although technique #3 above works, you run the risk of developing your server code under unrealistic conditions – for instance, you’ll have a logged in user with a loaded HKCU hive. If you want to try option #3, you’ll have to configure your application pool and/or ASP.NET application to run as your current (non-admin) user. For the app pool identity, you can configure that using the IIS Manager MMC. For ASP.NET, you have to modify the following in machine.config:

<configuration>
  <system.web>
    <processModel username="" password=""/>
  </system.web>
</configuration>

Although you can store this in cleartext, I would recommend against it for obvious reasons. Take a look at aspnet_setreg.exe and the following KB article on how to store this information securely:

How to use the ASP.NET utility to encrypt credentials and session state connection strings

We’ve just released Episode 3: Powered by Infinite Improbability Drive. So that we can get you, our loyal listeners, the episodes more quickly, we’ll be hosting on both MSDN Canada Community Radio as well as on the Plumbers @ Work site. You can find the show notes here, photos here, and podcast here. It will be posted to MSDN Canada Community Radio shortly.

Show Notes

• Introduction
• Around the Horn with the Plumbers
• Security March with Dan Sellers
• Microsoft Blacklisted C++ Libraries
• SHA-1 Discussion
• Team Foundation Server (TFS) Release Candidate (RC) 1
• Public Release of Internet Explorer (IE) 7.0 Beta 2
• Various Issues with IE 7.0 Beta 2
• Development of IE versus Development of Firefox
• The Browser as a User Experience (i.e. AJAX)
• Really Simple Syndication (RSS) in IE 7.0 and Outlook (AKA, The Ultimate Pull Application)
• Information Overload (AKA, Organizing Information)
• Upcoming Canadian Conferences: VSLive! and DevTeach
• Half-Time
• .NET Framework 2.0 Adoption
• ASP.NET 2.0 Adoption
• PetShop 4.0 Discussion and Highlights
• .NET Nuke 4.0
• Old Microsoft Reference Applications (AKA, “Different Strokes” or “ALF”)
• Enterprise Library 2.0 Highlights
• Windows “Live” Highlights (i.e. Domains, Favorites, and Messenger)
• Other “Live” Projects (Office “Live” and Visual Studio “Live”)
• Windows OneCare Beta
• The Realities of a “Secure” Operating System
• Windows Vista Favourite Features
• Running as Standard User/Non-Admin on Windows Vista
• Event Viewer in Windows Vista
• Windows Calendar (WinCal) in Windows Vista
• What’s Coming Up for the Plumbers
• Upgrading to Community Server 2.0
• John Still Doesn’t Have a Xbox 360

Show References

Rory Blyth and the Ewok
The SharePoint Show
Alberta .NET User Group
Calgary .NET User Group
Dan Sellers’ Blog
MSDN WebCasts
Saying Goodbye to an Old Friend (Michael Howard)
Bruce Schneier
SHA-1 Broken (Bruce Schneier)
KeyLength.com
Michael Howard’s Blog
Team Foundation Server (TFS) Release Candidate (RC) 1 (via Jeff Beehler)
Rob Caron’s Blog
Jeff Beehler’s Blog
Team Foundation Server (TFS) Go-Live License
TFS Blog
Internet Explorer (IE) 7.0 Beta 2
Scott Hanselman’s “Running Internet Explorer 7.0 Beta 2 without installing it.” Post
DevConnections
VSLive! Toronto
DevTeach
MSDN Article for Petshop Migration
.NET Nuke
Enterprise Library 2.0
Windows “Live”
Microsoft Gadgets
Windows “Live” Domains
Windows “Live” Favorites
Tuscany (AKA, Visual Studio “Live”)
Windows OneCare Beta
Windows OneCare Pricing Announcement
TopDesk
UntitledNet (Xbox 360 Locator Application)

You can post comments in the forums. As always, feedback is more than welcome.

If you’re running as a non-admin (which you know you should be), you are used to Right click… Run as… if you need to execute an application that needs admin privileges. This is easy and good. This even works for installers that are packaged as EXE. The pain is when you want to install a MSI package. Right click… and there is no Run as… option. So you do what I do, which is launch a command prompt as an admin user, browse to the directory containing the MSI package, and then execute from the command line. Or if you’re Michael Willers, you hack the registry and add an Install as… option. Doh! Why hadn’t I thought of that? Great idea, Michael. His steps are reproduced below:

1. Run regedit.exe under an account with administrative privileges
   
2. Create the key HKEY_CLASSES_ROOT\Msi.Package\shell\runas\
   
3. Set the default value to Install &as…
   
4. Create the key HKEY_CLASSES_ROOT\Msi.Package\shell\runas\command\
   
5. Set the default value to msiexec /i “%1″

After months of preparation and much secrecy, Plumbers @ Work has been released into the wild by the .NET Plumbers. The regular podcast is part of MSDN Canada Radio and will be featuring John Bristowe, Dan Sellers, Bil Simser and myself. We’ll be talking about current and upcoming developments in .NET and Microsoft technologies. Our inaugaural episode will discuss hot topics like:

• Introducing the podcast
• VS 2005/SQL 2005/BizTalk 2006 - Here they come!
• SharePoint vNow and vNext
• Drinking from the .NET 2.0 firehose
• Half-time show
• Security – It’s a process not a technology
• Developing as a non-admin
• Microsoft hardware
• A walk down memory lane with Microsoft Bob
• Xbox 360 – Should I get one?

Without further ado, I present to you:

Plumbers @ Work – Episode 1 – Mostly Harmless

You can catch the RSS feed here. You can leave us feedback and suggestions on the podcasts at .NET Plumbers.

1. Make sure you know your COMPUTERNAME\Administrator password. If you don’t, change it to something you do know.
2. Add yourself to Users (not PowerUsers since PowerUsers have most of the rights of an admin), Debugger Users, VS Developers, Network Configuration Operators (optional), and Remote Desktop Users (optional).
3. Set the local security policy to assign ownership to Administrators rather than user if user is a member of the Administrators group. Launch Administrative Tools… Local Security Policy… In the Local Security Settings MMC, browse to Security Settings… Local Policies… Security Options… System objects: Default owner for objects created by members of the Administrators group. Set this to “Administrators group”.
4. Grant modify rights to your user to C:\Documents and Settings\All Users\Application Data\microsoft\Crypto\RSA\MachineKeys. If you do not do this, you will not be able to compile signed assemblies in Visual Studio .NET. (i.e. If you are signing your assemblies via assembly:AssemblyKeyFile and/or assembly:AssemblyKeyName in AssemblyInfo.cs or AssemblyInfo.vb, your compile will fail without the proper ACL on the MachineKeys subdirectory.)
5. Install PrivBar.dll from here.
6. Install MakeMeAdmin.cmd and MakeMePU.cmd from here. Also read Aaron’s follow-up.
7. Remove yourself from the COMPUTERNAME\Administrators group.
8. Log off and log back in again. You’re now running (and developing) as a non-administrator. Congrats!

• To run a single program from Windows Explorer as the COMPUTERNAME\Administrator, use Shift-Right-click “Run as…”
• To run a single program from the command line as the COMPUTERNAME\Administrator, use runas.exe.
• To use the administrative MMC consoles, launch from Administrative Tools using Shift-Right-click “Run as…”
• To set ACLs, change link properties, and other file system properties, run MakeMeAdmin.cmd, launch “c:\Program Files\Internet Explorer\iexplore.exe”, and type “c:\” into the address bar. Internet Explorer will work almost identically to Windows Explorer for modifying local file system properties. This only hiccup that I’ve discovered is that folders don’t automatically refresh themselves if you add/delete/modify files and folders.
• If you need to debug a program that opens ports or performs other adminstrator-only operations, run MakeMeAdmin.cmd and launch “c:\program files\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe”. Be careful as Visual Studio and any programs that it launches is now running as a local admin.