No, this time it is not Microsoft - it is NetGear that is not providing an x64-capable version of their software. The very latest VPN client software for a ProSafe router (FVS338) doesn't work (install) on Vista x64: 

I think it is needless to say that I am not amused. Who are you kidding in late 2008?

A friend of mine lent me his copy of Crypto (by Steven Levy) last week, today I got around to finish reading it (been pretty busy lately as you can tell from close to zero new posts on this blog).

What's especially interesting about this book is the history, the background. In the past, I have read a couple of technical-level books, even attended Crypto conference in Santa Barbara in 1997. What this book highlights are the connections between the acting persons (mathematicans may forgive me) as well as the whole shenanigans of trying to put the genie back in the bottle. I do remember some of those (PGP, low international key strengths, Clipper), but never read about them in such detail.

If you have some time to spare, definitely worth your time to understand how cryptography went public.

Yesterday, we found ourselves at the receiving end of an attack against one of our German Wikis that are running the ScrewTurn Wiki software. Turns out that it was a security issue even with the then latest version 2.0.23. Dario Solera - the maintainer of ScrewTurn - acted real fast when I informed him about the root cause of the attack and released v2.0.24 yesterday night.

Please download and upgrade immediately! The issue is being actively exploited (zero day if you so will).

XSSDetect is a static code analysis tool that helps identify Cross-Site Scripting security flaws found within Web applications. It is able to scan compiled managed assemblies (C#, Visual Basic .NET, J#) and analyze dataflow paths from sources of user-controlled input to vulnerable outputs. It also detects whether proper encoding or filtering has been applied to the data and will ignore such "sanitized" paths. Download

Been on holidays, at conferences (eg last week Ask The Experts @ XTOPIA in Berlin), and worked on various projects - a couple of reasons it was rather quiet lately in this blog.

Yesterday I decided I needed a simple guestbook application for a to-be-developed private Web site, and because I didn't find anything that fit my needs I decided to write one myself with the goal of (ab)using XLinq in the course of this endeavour:

Guestbook_XLINQ.zip (7.09 KB)

Caveat emptor: I am no designer (surprise!). But thanks to no design it should be easy for you to add your own design. However, as this month's MSDN magazine is all about security, I decided to make the application production-ready security-wise. You'll find a lot of parsing plus XSRF protection (note: this version does not check for integer overflow in calculating the start row).

Missing features: this guestbook is not prepared for localization, nor does it use a control-based approach (where you drop those in your pages and get an in-place guestbook).

Update a version of this application for VS2008 RTM is available here.

I set aside the entire day for reading the book Writing Secure Code for Windows Vista. And I was already able to put it back into the bookshelf thanks to its concise nature. The authors only tell the reader about "What's new and changed", without having people wade through tons of stuff they already know. I really greatly appreciate that the authors did not do a third edition of Writing Secure Code just for bringing developers up to speed on Vista security.

Hint to book publishers: other areas would also benefit from this approach. There is only so much time to read books, and I don't want to skim through information I already know. Please consider catering to non-noobs by offering more of these "What's new and changed" types of books to us old dogs.

PS: Way cool to be mentioned in a security book! (p27)

I got myself an eval kit for RSA SecurID tokens to see how easy / hard this would be to deploy via AD. Well, I didn't get very far, that is, installation failed spectacularly in the early stages:

After this "helpful" message box setup decided to be more specific:

Ohh-Kay. Let's go to RSA and their support center (it takes roughly five clicks to get to online support, but that's another usability story) - sign in required. Hmmm. How about creating an account?

The eligibility is a real joke: "RSA customers who have a trial product (This does not include two user demos)". Excuse moi? On the Web site you told me that I was ordering a trial and in actuality it turned out to be a "2-User Promo Kit" (the moment I needed support I looked more closely on the package...) without support.

Maybe it's the Microsoft Windows Server 2003 R2 Enterprise Edition VHD I am using?

A default install of Windows Server 2003 ships with a locked-down Internet Explorer, in a so-called enhanced security configuration. Getting rid of it was done via configuring the Windows components. Not so on Windows Server 2008. At first of course I looked in all the wrong places (after all who reads a text they "know"?), until I found it in Server Manager:

You can turn it on / off separately for administrator or users:

Why did I turn it off? Because when it is on, you cannot view IIS7 FREB log files - the XSL has code in it that won't run in any browser but IE. At least at Beta 3 of Longhorn, that is.

A couple of notes to self:

• Creating a CSR (the short version)
• How do I generate a certificate request? (more detailed if you want to change RSA key lengths which I would recommend)
• Contents of .pem file for Stunnel

The latter is especially important if one fails to grasp how to turn the private key plus the certificate into the .pem for Stunnel. By the way, I was using CAcert. That works just fine for internal email servers.

Fiddler is a HTTP debugging proxy. Although it is easy to use (a very good thing!), it is also very powerful. Point in case and why I am writing about it today is that I stumbled across a drive-by-download site (stumble is the wrong word, the URL came with what seemed like a phishing mail and that piqued my interest):

That site is actually quite clever though: when you go there the second time, it detects that it tried to infect you before and tells you that your IP is blocked. And it doesn't send a peep to a browser other than IE. Plus - and that takes the biscuit - it also verifies the referer.

But I still wanted the code, so I reset my router and started Fiddler:

Although Fiddler has tons more features, this did the trick for me in this case (if you want to learn what Fiddler can do, look here).

So what's the obfuscated script about? The short version: it is a variant of the ASUS download server drive-by download incident. The actual code can be found in a discussion on our German .NET community site here.

This is v2 of the Vista UAC development requirements document. From the TOC:

• Why User Account Control?
• How UAC Works
• Will UAC Affect Your Application?
• Designing Applications for Windows Vista
• Deploying and Patching Applications for Standard Users
• Troubleshooting Common Issues
• References

In my last blog entry UAC Elevation in Managed Code: A .NET COM Component Elevated I showed how to get up and running with an all-managed code solution for UAC and COM elevation. Today I want close out my series on UAC with some information on how to properly organize the project plus present a library you can reuse to get up and running quickly - without many of the manual and tedious steps from the previous proof of concept example.

Speaking of the previous sample: it is still the basis for this best practice, so the following directory layout will look familiar to you:

Before diving into code, I want to start out with the SampleSetup directory, which contains the executables. As you can guess, the starting point is Step1Register. It contains register.bat, which you have to execute:

Note that on machines without the .NET Framework SDK, there is no gacutil.exe. In that case, you have to drag & drop ManagedElevator.dll to c:\windows\assembly.

And in case you have been wondering from this screenshot, yes, the application now also plays nicely on Windows XP:

Of course, there is no consent UI popping up, nor is there a shield icon like there is on Windows Vista:

The magic for this cross-platform functionality is hidden in the UACHelper project - which brings us to the source section of this blog post:

All the necessary COM elevation magic is now moved to this neat little library - including the adapted UAC bits of VistaBridgeLibrary (no longer necessary). The names already give away the purpose of each class and where they are used:

• COMRegistration Used by the elevated component to automatically register the necessary registry keys.
• ShieldButton Used by the client to display a button with a shield icon (on Vista). For XP, no shield is rendered.
• COMElevation Starts the requested component with admin privileges.
• ElevatedProcess If you want to start a simple process elevated. Not used in this guidance.

The first customer of this library is the elevated component, so we start discussing this guy next:

At first glance, this is similar to the previous POC implementation. The main difference now is that I have broken down the functionality by feature area into namespaces:

• The "main" namespace
• The .Components namespace
• The .Guids namespace
• The .InterOp namespace

Let's look at these one by one.

The "main" namespace

Here, we have one class only:

class RegisterFunctions
{
  [ComRegisterFunction]
  publicstaticvoid CustomRegister(Type t)
  {
    COMRegistration.RegisterForElevation(Assembly.GetExecutingAssembly().Location,
       SampleComponent.ClassToElevate,
       Global.AppId,
       100);

    // add additional "for elevation" components here by duplicating the above
  }

  [ComUnregisterFunction]
  publicstaticvoid CustomUnregister(Type t)
  {
    COMRegistration.UnRegisterFromElevation(Assembly.GetExecutingAssembly().Location,
        Global.AppId);
  }
}

It is called when the assembly is regasm'ed, and it is here where you call into COMRegistration.RegisterForElevation to add all the necessary registry keys for elevation:

public static void RegisterForElevation(string assemblyLocation,
    string classToElevate,
    string appId,
    int localizedStringId)
{
 if (!UACHelperFunctions.IsUACEnabledOS()) return;

 // [HKEY_CLASSES_ROOT\CLSID\{71E050A7-AF7F-42dd-BE00-BF955DDD13D4}]
 // "AppID"="{75AB90B0-8B9C-45c9-AC55-C53A9D718E1A}"
 // "LocalizedString"="@E:\\Daten\\Firma\\Konferenzen und Talks\\..."
 RegistryKey classKey = Registry.ClassesRoot.OpenSubKey(@"CLSID\{"+ classToElevate +"}", true);
 classKey.SetValue("AppId", "{"+ appId +"}", RegistryValueKind.String);
 classKey.SetValue("LocalizedString", "@"+ assemblyLocation +",-"+ localizedStringId.ToString(), RegistryValueKind.String);

 // [HKEY_CLASSES_ROOT\CLSID\{71E050A7-AF7F-42dd-BE00-BF955DDD13D4}\Elevation]
 // "Enabled"=dword:00000001
 RegistryKey elevationKey = classKey.CreateSubKey("Elevation");
 elevationKey.SetValue("Enabled", 1, RegistryValueKind.DWord);
 elevationKey.Close();

 classKey.Close();

 // [HKEY_CLASSES_ROOT\AppID\{75AB90B0-8B9C-45c9-AC55-C53A9D718E1A}]
 // @="ManagedElevator"
 // "DllSurrogate"=""
 RegistryKey hkcrappId = Registry.ClassesRoot.OpenSubKey("AppID", true);
 RegistryKey appIdKey = hkcrappId.CreateSubKey("{"+ appId +"}");
 appIdKey.SetValue(null, Path.GetFileNameWithoutExtension(assemblyLocation));
 appIdKey.SetValue("DllSurrogate", "", RegistryValueKind.String);
 appIdKey.Close();

 // [HKEY_CLASSES_ROOT\AppID\ManagedElevator.dll]
 // "AppID"="{75AB90B0-8B9C-45c9-AC55-C53A9D718E1A}"
 RegistryKey asmKey = hkcrappId.CreateSubKey(Path.GetFileName(assemblyLocation));
 asmKey.SetValue("AppID", "{"+ appId +"}", RegistryValueKind.String);
 asmKey.Close();

 hkcrappId.Close();
}

Please take note that when the component is registered on eg Windows XP, no registry entries are written. After all, they are not needed.

The .Components namespace

Not much of a change - it contains the administrative component(s).

The .Guids namespace

The guids have been moved to a separate namespace. The reason? That way you can reference the assembly in the client project and use the guids directly - no magic strings anywhere any more.

The .InterOp namespace

This is the most important change with regards to the POC project - defining the correct ComImport'ed interface is now the responsibility of the implementer of the elevated component. That way, anyone needing access to this component only needs to reference the assembly and they are good to go. It is a bad idea to have this interface part of the client codebase!

Speaking of the client... here is the button code for DemoForm.cs:

private void cmdLaunch_Click(object sender, EventArgs e)
{
 if (UACHelperFunctions.IsUACEnabledOS())
 {
   IHelloWorld ihw = COMElevation.Start<IHelloWorld>(
        SampleComponent.ClassToElevate, SampleComponent.IHelloWorld);
   ihw.SayHello();
   COMElevation.Release(ihw);
 }
 else
 {
   ManagedElevator.Components.ClassToElevate c =new ManagedElevator.Components.ClassToElevate();
   c.SayHello();
 }
}

What looks interesting at first is COMElevation.Start as well as Release:

public class COMElevation
{
 publicstatic TIFace Start<TIFace>(string IID_Class, string IID_Interface)
 {
  return Start<TIFace>(new Guid(IID_Class), new Guid(IID_Interface));
 }

 publicstatic TIFace Start<TIFace>(Guid IID_Class, Guid IID_Interface)
 {
  object o = UACManager.LaunchElevatedCOMObject(IID_Class, IID_Interface);
  return (TIFace)o;
 }

 publicstaticvoid Release(object o)
 {
  Marshal.ReleaseComObject(o);
 }
}

Actually all it does is encapsulate the necessary calls to UACManager and Marshal. Why is there no if / else using IsUACEnabledOS here? Well, at first I thought I'd build such a switch, but then I thought again: why would I use COM InterOp if I don't have to? I already referenced the assembly for the component (for the guids and interop interface), so why not use managed all the way and save time? That's what I did in the cmdLaunch_Click event handler.

That's it for the code folks, now a little discussion at the end on why in the world would you even think about doing this in a cross-platform way, or why it is a stupid idea all along:

This approach is only sensible if your application runs as administrative user on XP, otherwise all the calls in the administrative component will fail. However, the cross-platform part is only there to make it a complete best practice, there is no "you must use it cross-platform" - if you build applications for Windows Vista with the eventual need to elevate a task, then UACHelper is definitely for you! (and forget about that it would even work on XP)

Oh, and I almost forgot - here is the complete download, source code included of course (my code is BSD licensed):

AutomaticRegistration.zip (91.92 KB)

I admit it: UAC Elevation in Managed Code: "Talking" to an Elevated Process via WCF is a kludge. The reason why I dabbled with this approach at all is that I failed to implement COM elevation with managed code (not elevating a COM component, but the COM component itself). However, at long last, I succeeded in that respect too: I now present you the all-managed code solution to UAC elevation!

Once again I built myself a small demo frontend application:

As you can guess, the first button does plain vanilla COM InterOp without any UAC elevation. Thus its code is rather simple:

private void simpleCallButton_Click(object sender, EventArgs e)
{
  Type t = Type.GetTypeFromCLSID(new Guid("71E050A7-AF7F-42dd-BE00-BF955DDD13D4"));
  object o = Activator.CreateInstance(t);
  t.InvokeMember("SayHello", BindingFlags.InvokeMethod, null, o, null);
}

Why this reflection magic? Well, the COM component I am calling here is implemented in .NET - and both VS as well as tlbimp balk at reimporting the exported type library.

The COM component in question has been regasm'ed & gacutil'ed (ManagedElevator project in the download). Although the name implies that I am after elevation, it is pretty much a standard COM component written using C#:

public class TheGuids
{
  publicconststring IHelloWorld ="B8CD5C09-9ACD-49b0-BF6F-C7B0F29795F9";
  publicconststring ClassToElevate ="71E050A7-AF7F-42dd-BE00-BF955DDD13D4";
  publicconststring AppId ="75AB90B0-8B9C-45c9-AC55-C53A9D718E1A";
}

[Guid(TheGuids.IHelloWorld)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
publicinterface IHelloWorld
{
  [ComVisible(true)]
  void SayHello();
}

[Guid(TheGuids.ClassToElevate)]
[ClassInterface(ClassInterfaceType.None)]
publicclass ClassToElevate : IHelloWorld
{
 public ClassToElevate()
 {
 }

 [ComVisible(true)]
 publicvoid SayHello()
 {
  MessageBox.Show("Hello World");
 }
}

So how do you go from "standard" "plain-vanilla" COM component to COM elevation? The part that stumped me for so long was the ClassInterface attribute - if you forget this guy, you'll end up with an InvalidCastException thrown by UACManager.LaunchElevatedCOMObject.

But that's not quite all to get up and running with COM elevation: in addition, you need to modify the default registration for this component - specifically, you need to configure the DllSurrogate. This is where the AppId GUID comes into play: it isn't used in code (kept there for documentation purposes only), but in registryadditions.reg. It binds the various registry keys. And speaking of this .reg file, please take note of the LocalizedString value: it contains the text for the UAC prompt (also check out UACPrompts.rc, resource.h, compilerc.bat as well as the properties of the ManagedElevator project where the compiled .res file is referenced).

Note Before importing the .reg file into the registry make sure to fix the file path contained in LocalizedString! And if you create your own elevated COM component DO NOT reuse any of my three GUIDs - use guidgen.exe to create your personal ones.

From there, UAC elevation is smooth sailing. The Reflection version of COM elevation looks very similar to non-elevated calls:

private void managedElevation_Click(object sender, EventArgs e)
{
  // CLSID
  Guid classId =new Guid("71E050A7-AF7F-42dd-BE00-BF955DDD13D4");

  // Interface ID
  Guid interfaceId =new Guid("B8CD5C09-9ACD-49b0-BF6F-C7B0F29795F9");

  object o = UACManager.LaunchElevatedCOMObject(classId, interfaceId);

  Type t = o.GetType();
  t.InvokeMember("SayHello", BindingFlags.InvokeMethod, null, o, null);

  Marshal.ReleaseComObject(o);
}

Of course this is not really a good solution (late binding). So instead I manually imported the IHelloWorld interface:

[
ComImport(),
Guid("B8CD5C09-9ACD-49b0-BF6F-C7B0F29795F9"),
InterfaceType(ComInterfaceType.InterfaceIsDual)
]
  interface IHelloWorld
  {
   [
   MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime),
   PreserveSig
   ]
    void SayHello();
  }

Which makes calls into the elevated COM object much easier and cleaner:

private void managedElevationInterface_Click(object sender, EventArgs e)
{
  Guid classId =new Guid("71E050A7-AF7F-42dd-BE00-BF955DDD13D4");
  Guid interfaceId =new Guid("B8CD5C09-9ACD-49b0-BF6F-C7B0F29795F9");

  object o = UACManager.LaunchElevatedCOMObject(classId, interfaceId);

  IHelloWorld ihw = (IHelloWorld)o;
  ihw.SayHello();

  Marshal.ReleaseComObject(o);
}

So why should you use the COM elevation solution instead of starting the process? Well, there are a couple of reasons:

• You can package more than one component into a DLL and still have custom UAC prompts thanks to LocalizedString
• Your users don't get "an unidentified program..." warnings. Thank you COM registration
• If you ever need to talk more extensively with the elevated process then this approach can be adapted more easily

The source code

ConsumeMyElevatedCOM.zip (97.56 KB)

You will find a file aptly named notes.txt in the ManagedElevator project that describes all the necessary steps to get up and running.

I hope you find this sample useful and not have to spend as much time as I did. Cheers!

In the blog post UAC Elevation in Managed Code: Starting Elevated Processes I talked about how to start an elevated process. However, just starting a process might not cut the mustard, for example if you need to hand over data to the elevated process. You could achieve this by passing, let's say, some data as command line arguments to ProcessInfo before starting the elevated process. But that seriously limits communication.

So how can you perform communication with an elevated process? My first idea was to use .NET Remoting. Once I thought through the multi-instance scenario, I quickly realized that this meant the server had to be running in the non-elevated application, because only it could properly choose a port. And because I am not a fan of Remoting anyways, I decided to give WCF (Windows Communication Foundation, a pillar of .NET 3.0) a try.

It looked like smooth sailing at first, but then I realized that with WCF too I needed to implement the service inside the non-elevated application. This time, however, the reason was "How do I know when the elevated application has initialized before I can actually start communicating with it?". Back to the drawing board.

The final solution now looks like this: the non-elevated application starts a service. The operations contract specifies a callback, which, once the elevated application has signalled its readiness, can be used by the non-elevated application to "talk" with the elevated application. I didn't intend to go duplex, but hey, if there's no other way I am willing to take plunge. Speaking of tricks of the trade: I am using imperative binding to a named pipe. Reason? Well, WS bindings won't work (see here and here), and the TCP channel would pop up a firewall warning. That's why.

Let's look at the applications - first the non-elevated one:

This time I forfeited eye candy (the shield button). Same (missing eye candy) goes for the elevated application as it is a console application only:

Solution-wise, this simple two-application scenario is split into four projects:

So where do we start? With the easy part inside ElevationContract:

[ServiceContract(Namespace ="http://Christoph.Wille.Samples",
CallbackContract =typeof(IElevatedProcess))]
publicinterface IWaitForElevatedProcess
{
  [OperationContract(IsOneWay =false)]
  void ElevatedProcessStarted();
}

[ServiceContract(Namespace ="http://Christoph.Wille.Samples")]
publicinterface IElevatedProcess
{
  [OperationContract(IsOneWay =false)]
  void SayHello(string message);
}

The interface IWaitForElevatedProcess is implemented in StandardUserApp. It is the service endpoint that is initialized before the elevated process is started - and once the elevated application is up and running, it calls into ElevatedProcessStarted. And we are in business for using the IElevatedProcess callback that is implemented in the ElevatedProcess console application.

So how is the service endpoint intialized - let's take a look inside:

private const string theProcess =@"..\..\..\ElevatedProcess\bin\Debug\ElevatedProcess.exe";

privatevoid tryitButton_Click(object sender, EventArgs e)
{
  string channelIdentifier = MiscHelpers.CreateRandomString(64);
  MyUACServiceHost.StartService(channelIdentifier);

  // starting it modal doesn't work (obviously - unless we have more threads, of course)
  ElevatedProcess.Start(theProcess, channelIdentifier);
}

Interesting tidbit #1 is CreateRandomString: it creates a random string to use for the address. Why? Well, if multiple instances of our application are running and trying to elevate a process, we are in trouble. Which brings me to StartService:

internal static void StartService(string pipeEndPoint)
{
  NetNamedPipeBinding binding =new NetNamedPipeBinding();
  binding.Name ="uacbinding";
  binding.Security.Mode = NetNamedPipeSecurityMode.Transport;

  Uri baseAddress =new Uri("net.pipe://localhost/uac/"+ pipeEndPoint);

  myServiceHost =new ServiceHost(typeof(SampleService), baseAddress);
  myServiceHost.AddServiceEndpoint(typeof(IWaitForElevatedProcess), binding, baseAddress);
  myServiceHost.Open();
}

As I said before, I am doing it imperatively (no configuration in app.config necessary). That's all there is to getting the service up and running.

Now let's switch to the console application's Main method:

static void Main(string[] args)
{
  if (args.Length != 1)
  {
    Console.WriteLine("One argument expected - the channel identifier");
    return;
  }

  NetNamedPipeBinding binding =new NetNamedPipeBinding();
  binding.Name ="uacbinding";
  binding.Security.Mode = NetNamedPipeSecurityMode.Transport;

  String url ="net.pipe://localhost/uac/"+ args[0];
  EndpointAddress address =new EndpointAddress(url);

  WaitForElevatedProcess client =new WaitForElevatedProcess(
      new InstanceContext(new SampleCallback()),
      binding,
      address);

  client.ElevatedProcessStarted();

  Console.WriteLine("The elevated process is now ready");
  Console.ReadLine();

  client.Close();
}

Similar to normal client WCF code, however, with the duplex twist hidden inside WaitForElevatedProcess:

public class WaitForElevatedProcess : DuplexClientBase<IWaitForElevatedProcess>, IWaitForElevatedProcess
{
  public WaitForElevatedProcess(System.ServiceModel.InstanceContext callbackInstance,  
    System.ServiceModel.Channels.Binding binding,
    System.ServiceModel.EndpointAddress remoteAddress)
       : base(callbackInstance, binding, remoteAddress)
  {
  }

  publicvoid ElevatedProcessStarted()
  {
    base.Channel.ElevatedProcessStarted();
  }
}

Once the channel is connected, this elevated process calls back into the service piece which lives in the non-elevated application, namely SampleService:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant,
      InstanceContextMode = InstanceContextMode.PerSession)]
publicclass SampleService : IWaitForElevatedProcess
{
  publicvoid ElevatedProcessStarted()
  {
    OperationContext.Current.GetCallbackChannel<IElevatedProcess>().SayHello("Chris");
  }
}

This method is the workhorse where I can talk to the elevated process - if only my callback interface had more as well as more serious methods ;-)

Speaking of talking, I owe you the code for the callee in the console application:

[CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
publicclass SampleCallback : IElevatedProcess
{
  publicvoid SayHello(string message)
  {
    Console.WriteLine("Hello world "+ message);
  }
}

That's it - to recap: first, we initialize the WCF service. Then elevate a process. This process, once initialized, calls into our service and leaves a callback. And then we are in business talking to the elevated process (setting data, being notified when the elevated application quits and why, ...).

Sample warnings before you download: MyUACServiceHost definitely should be instance instead of static. And, more restricting - starting the elevated process modal won't allow communication unless you start the service on a separate thread. For simplicity reasons I didn't do this for the POC.

ElevateProcessTalkWCF.zip (27 KB)

Before concluding I wanted to add a few words: my ideal implementation for UAC would be COM elevation. That way, one can put more than one component into a single DLL, and still get a meaningful UAC prompt thanks to the LocalizedString registry key - which is per component, and not per executable (which is the case for this solution if you add multiple actions). If you need differing prompts for each administrative action, there is only one course of action you can take with processes: create multiple executables. Not very pretty, but I failed with writing an elevatable (not a word, I am sure) managed (C#) COM component.

The previous installment UAC Elevation in Managed Code: Starting Elevated Processes dealt with starting executables with the "real" administrative token. In this blog post, we deal with starting a COM component with elevated privileges. For in-depth background information, please consult Kenny Kerr's absolutely excellent post on Windows Vista for Developers – Part 4 – User Account Control.

To start with, we need a COM component. Instead of writing an ATL C++ COM component from scratch, I took the MyElevateCom sample from CoCreateInstanceAsAdmin or CreateElevatedComObject sample from the Vista Compatibility Team Blog. Note that for building it, check out my post Visual Studio on Vista: Not so Fast!

Assuming that you built and successfully registered the COM component (it is built to the instuctions from Kenny's post), you can go about and write the managed caller. First, we need a reference to the component:

Then comes the tricky part - actually instantiating the COM component. When you take a look at the C++ example, you see that quite some "moniker magic" is involved that cannot be replicated by simply newing up the component. So how to mimic this behavior in managed code? The Microsoft® Windows® Software Development Kit for Windows Vista™ and .NET Framework 3.0 Runtime Components comes to the rescue: inside, you find C:\Program Files\Microsoft SDKs\Windows\v6.0\Samples\CrossTechnologySamples.zip, which contains the VistaBridge sample.

From that, I took the VistaBridgeLibary, and modified the static UACManager.LaunchElevatedCOMObject method a bit:

[return: MarshalAs(UnmanagedType.Interface)]
publicstaticobject LaunchElevatedCOMObject(Guid Clsid, Guid InterfaceID)
{
  string CLSID = Clsid.ToString("B");
  string monikerName ="Elevation:Administrator!new:"+ CLSID;

  NativeMethods.BIND_OPTS3 bo =new NativeMethods.BIND_OPTS3();
  bo.cbStruct = (uint)Marshal.SizeOf(bo);
  bo.hwnd = IntPtr.Zero;
  bo.dwClassContext = (int)NativeMethods.CLSCTX.CLSCTX_LOCAL_SERVER;

  object retVal = UnsafeNativeMethods.CoGetObject(monikerName, ref bo, InterfaceID);

  return (retVal);
}

Modifications: the method is now public instead of internal, and CLSCTX changed to local server (otherwise it wouldn't work).

Next, we need a UI:

This button is the CommandLinkWinForms control from VistaBridgeLibary, with the ShieldIcon property set to true.

Let's hook up the event code:

private void tryItButton_Click(object sender, EventArgs e)
{
 Guid IID_ITheElevated =
  new Guid(0x5EFC3EFB, 0xC7D3, 0x4D00, 0xB7, 0x2E, 0x2F, 0x86, 0x4A, 0x1E, 0xAD, 0x06);

 Guid CLSID_TheElevated =
  new Guid(0x253E7696, 0xA524, 0x4E49, 0x9E, 0x50, 0xBF, 0xCC, 0x29, 0x91, 0x31, 0x23);

 object o = UACManager.LaunchElevatedCOMObject(CLSID_TheElevated, IID_ITheElevated);

 ITheElevated iface = (ITheElevated)o;

 // Call the method on the interface just like in the C++ example
 iface.ShowMe();

 // Release the object
 Marshal.ReleaseComObject(o);
}

The interface ID as well as class ID guids come directly from the C++ project (it is always a good idea to "speak" more than one language), but you could obtain those from the type library or registry as well if you don't have the source code of the component handy.

Object creation is handled via LaunchElevatedCOMObject, and the resultant object is cast to the interface from the imported type library. Noteable (and important) is the last line: because the object wasn't created by the runtime, we have to take care of its destruction (the created interface doesn't have a Release() method, so we use Marshal.ReleaseComObject).

That's it - your managed code is now instantiating an elevated COM object that has full reign over the system.

ElevateCOMComponentSample.zip (117.07 KB)

When you are working with Windows Vista, you know that even the administrative users are stripped ("filtered") of their privileges for normal operations, and that when you have to perform tasks requiring administrative privileges, you are presented with an UAC elevation prompt. The idea of this blog post series is to provide you with working samples on how to work with elevation from inside managed applications (you might also want to read Windows Vista Application Development Requirements for User Account Control Compatibility).

I want to side-step the really easy part - providing a manifest to start the entire application elevated (a good idea if the application makes no sense at all unless it has administrative rights, like regedit.exe). You can find information on those topics in Adding a UAC Manifest to Managed Code and Vista: User Account Control.

Now back to the topic of this post: App A needs to start App B with administrative rights (because App B e.g. needs to write to HKLM or Program Files). Therefore, we somehow must run App B as an administrative user (or with the non-filtered token of the current user). So how do we go about it?

First, some eye candy. You definitely already saw those nice shield icons before:

Those shield icons are stock on Windows Vista and indicate to the user that the action that hides behind the button requires elevation. I didn't create a button control myself - instead, I reused one that is readily available on the Web: Add a UAC Shield to your Winforms buttons in C#.

All I had to do myself was to start the Process ("App B"):

private void startProcess_Click(object sender, EventArgs e)
{
  ProcessStartInfo psi =new ProcessStartInfo();
  psi.FileName = theProcess;
  psi.Verb ="runas";
  Process.Start(psi);
}

The ticket (so to speak) for the elevation prompt is setting the Verb to "runas" in the ProcessStartInfo instance - this will pop up the elevation prompt if necessary when Process.Start is called.

This simplistic approach has a problem though - once App B is started, users can switch back to App A, because it App B isn't "modal" for App A. To solve this problem, I incorporated the approach from Daniel Moth outlined in his post Launch elevated and modal too:

private void launchModal_Click(object sender, EventArgs e)
{
  ProcessStartInfo psi =new ProcessStartInfo();
  psi.FileName = theProcess;
  psi.Verb ="runas";

  psi.ErrorDialog =true;
  psi.ErrorDialogParentHandle =this.Handle;

  try
  {
    Process p = Process.Start(psi);
    p.WaitForExit();
  }
  catch (Exception ex)
  {
    MessageBox.Show(ex.ToString());
  }
}

And that's it - App B is now modal. Once App B quits, control is relinquished to App A (which still doesn't run with administrative rights).

ElevateProcessSample.zip (21.1 KB)

Got a developer question on how Windows Vista security affects your application? Then the MSDN Forum Security for Applications in Windows Vista is the right place to go.

I don't recommend turning off UAC (User Account Control) on Windows Vista, but there might be valid reasons to shut it off once in a while for testing purposes (like in a VM). That is where TweakUAC comes in handy:

Michael Howard has all the links in this blog entry Online Security Sessions from TechEd IT Forum Available. Topics include: malware cleaning, UAC internals, social engineering, Vista kernel changes, Vista firewall and IPSec enhancements. Which reminds me that the post-conference DVDs should tip up in my mailbox rsn.

This is the firewall settings dialog - much the same as we know it from Windows XP already:

However, once you fire up the management console (mmc.exe), you can add snapins for advanced firewall configuration (ok, IPSec is one of my personal favorites and not necessary to configure the firewall per se...):

Once you have done this, you can now configure the firewall like, well, an administrator would expect - rule based:

I have been promoting this tool more than once on this blog, so this time just the download link for version 2.1.

I admit it: I am a regular reader of the event log. In doing so, I came across an error message last week that I rarely get to see - invalid Viewstate:

Now, that wouldn't be a problem, usually at least. However, in this special case I went WTF? when I looked at the description more closely, especially at the PersistedState information:

PersistedState: a

Content-Transfer-Encoding: 8bit

Content-Type: text/plain

X-Mailer: EMUmail 4.5

Subject: jam n

bcc: <list of addresse removed by me />

comes from the loin in the middle of the back of the pig. t is a lean meaty 


cut of bacon, with relatively less fat compared to other cuts. iddle bacon 


is much like back bacon

daa6c5071189f202ceb370d0e9d38c33

.

Come again - spam in Viewstate? What would be the point of this? After some research together with Alex I came across this article: Interesting Crack Attempt to Relay Spam (a more detailed article is available too: Form Post Hijacking). How did I manage to not take notice of this attack vector any earlier I don't know, but I have to admit that the idea is pretty clever.

Counter-measures in general? Well, either don't allow users input in the headers at all, or vet the form fields for carriage return / line feeds. Note that I did not verify if any of the available mail components for .NET would be actually susceptible to this kind of attack.

At next year's VSone in Munich (a German developer conference taking place in February), I will be doing three talks:

• Visual Studio 2005 Team Edition for Database Professionals
• User Account Control (UAC) in Your Applications
• Advanced Code Access Security (CAS)

Two security topics, one team-development focused. See you in Munich!

I already talked about the virtualization features of Windows Vista in a previous blog post entitled UAC Redirection 4 Fun & Profit. Today, I want to tackle the file redirection that happens when UAC virtualizes your application and you try to write to a location it monitors - like the Program Files directory:

This command prompt was started with Run as Administrator (the window title hints at that). I was UAC-prompted, and then could go about my business. Not so if I would be running it unelevated:

It tells me that I don't have access. Right, not a big surprise, but why didn't virtualization kick in for cmd.exe? Because it is off by default for the command line. How can I turn it on? Well, easy. Go to Windows Task Manager

Add the Virtualization column

After a bit drag & drop magic I made it the second column and I can see which application is virtualized or not. And sure enough, cmd.exe isn't. Right-clicking allows you to change that:

You will be warned that this will possibly affect the running application, but go ahead. And then try again to write to the Program Files location:

This time I can write to Program Files - wait a second, really? No, it of course went to the virtual store for this user account:

As you can see, it lives next to files from a heck a lot of applications that wanted to write to somewhere (like system32) where they didn't have access to - but virtualization (on by default for applications except those opting out explicitly) took care of the disk operations and redirected them to the virtual store. Note that a well-written application (ie one that doesn't require administrative rights) wouldn't show up here...

This Q&A item is part of the current MSDN magazine's Security Brief's column by Keith Brown. I am pretty sure that this problem will rear its head sooner or later on every developers machine, that's why I am 'pinning' the link in my blog for my own reference too.

The Windows Vista Security Guide provides recommendations and tools to further harden Windows Vista. Well, go get it.

The November 2006 issue has lots of good security articles, which are available online too. Check out Security Habits, Threat Modeling (STRIDE approach), Extending SDL or SQL Security to name a few.

Last Tuesday, I held the talk "Advanced Code Access Security" at UG Styria in Graz. This talk was originally part of the MSDN Security Briefings held in Austria earlier this year, for which MS Austria had asked MVPs to help create and deliver security content. Advanced CAS seemed an interesting enough developer topic to re-run at user groups, and Mario (the author of this session) has allowed me to publish the slide deck and demos for the general public.

AdvancedCodeAccessSecurity.pdf (4542 KB)

AdvancedCAS.zip (599.6 KB)

Please note that I have published only demos four (setting CAS via setup) and six (using CAS in addin application) - those are the "completed" versions of the demos.

This is a whitepaper published by MS (download here). From the download page:

Gain valuable information about the concepts of social engineering within the IT security workspace. In section one, the guide provides a working definition of social engineering that can be used within a company's security policies and is meaningful to non-IT security staff. The guide describes the aims and objectives of an attacker and shows how social engineering, like hacking, is a threat to all businesses, not just enterprise or government institutions. The guide will also cover:

• Social engineering and the defense-in-depth layered model
• Social engineering threats and defense
• Online, telephone-based, and waste management threats
• Personal approaches
• Reverse social engineering
• Designing and implementing defenses against social engineering threats
• Developing a security management framework
• Risk management
• Social engineering in the organizational security policy
• Awareness
• Managing incidents
• Operational considerations
• Security policy for social engineering threat checklists

Get it here

Currently reading: The Security Development Lifecycle

When you run an application that needs administrative rights (in this specific case via a manifest file), you are prompted with an UAC dialog to allow this operation:

This is the dialog you get for the "default" user, the one you create during setup that is a member of the Administrators group. Contrast that to the dialog a standard user is presented with:

Now, I am fine with prompting the user to enter administrative credentials. However, I am not fine with providing the user with the name of the administrative user(s) on that machine. In my opinion, this is giving away security-related information without need.

Update Of course you can always use net localgroup Administrators to get a list of the members of the Administrators group (Markus pinged me on that one). This feature has been available for ages, true. However, I am not convinced that the UAC convenience of providing the administrative accounts on a silver platter is really necessary.

Michael Howard plugged his latest book The Security Development Lifecycle in his blog back in April (A New Book: The Security Development Lifecycle). It isn't yet available in stores, but I decided to preorder because I'm really looking forward to this book. Why? Because it describes a security process in development that works - the SDL @ Microsoft.

A /. article pointed me to the blog post Reporting Vulnerabilities is for the Brave. Sounds familiar. Been there, done that. A customer had a Web site, and I told them about a problem. They told their vendor. And the vendor went after me - probably because, like most security-unconscious companies they felt threatened in one way or another.

Therefore I wholeheartedly agree with the instructions outlined, plus: lean back, and enjoy when the bad guys whack that company. Yes, this is controversial, but as long as companies don't "get it" that there are people that want to help them when reporting vulnerabilities, it is definitely better to keep your trap shut.

Aside from the cynical advice in the above paragraph, here is something to consider for your company: establish a policy - and publish it! - that you welcome security reports by security researchers (and Joe Average for that matter). This goes a long way to getting the threats mitigated before they are exploited.

The TAM tool is now available as release candidate 1. If you don't know it (already), here is the quick scoop from the download page: Microsoft Threat Analysis & Modeling tool allows non-security subject matter experts to enter already known information including business requirements and application architecture which is then used to produce a feature-rich threat model. Along with automatically identifying threats, the tool can produce valuable security artifacts such as:

• Data access control matrix
• Component access control matrix
• Subject-object matrix
• Data Flow
• Call Flow
• Trust Flow
• Attack Surface
• Focused reports

By the way, use this link to search for the video series on threat modeling in the Download Center!

Tracking down the URL for the Webcast Detecting and Debugging Common Application Issues Using the Windows Application Verifier really turned into a scavenger hunt today... if you don't know what AppVerifier is, download it here, and read more here.

On Tuesday I was presenting a Windows Vista security session, which included UAC (user account control) and respective demos. One part was showing UAC data redirection, and for this blog post I will stick with the registry side of things.

Why this redirection in the first place? Well, old legacy applications do tend to assume that you are running as admin on your box. Thus, those apps simply store "stuff" in the HKLM hive of the registry, instead of HKCU. To allow such misguided apps to run on Vista smoothly, UAC automagically redirects write operations from the actual HKLM location to a VirtualStore branch of the current user's profile.

Let's look at an example of a classic no-no:

try
{
  RegistryKey MyTest = Registry.LocalMachine.OpenSubKey("Software\\Microsoft\\Microsoft SDKs\\.NETFramework\\v2.0", true);
  MyTest.SetValue("InstallationFolder", ContentsText.Text, RegistryValueKind.String);
  MyTest.Close();
  ResultsLabel.Text ="Successfully written to registry!";
}
catch (Exception ex)
{
  ResultsLabel.Text ="Unable to write to registry: "+ ex.Message;
}

On XP, being non-admin, you would end up in the catch block. Not so on Vista. With Vista, this will work out ok, and the data will be stored like this:

Nice indeed. Or is it actually nice? Let's look at the code for reading the value again:

try
{
  RegistryKey MyTest = Registry.LocalMachine.OpenSubKey("Software\\Microsoft\\Microsoft SDKs\\.NETFramework\\v2.0", true);
  ContentsText.Text = MyTest.GetValue("InstallationFolder") asstring;
  ResultsLabel.Text ="Successfully read from registry!";
}
catch (Exception ex)
{
  ResultsLabel.Text ="Unable to read from registry: "+ ex.Message;
}

So what's your guess where the value will come from - the original HKLM location or the redirected HKCU VirtualStore location? Right, the VirtualStore is the winner.

Now, I intentionally picked an existing value in the registry to "overwrite". Imagine somebody writing a "fuzzer" to go over every single value in HKLM and write back gibberish for every value it finds. The original application will now too see this gibberish instead of the original good values.

Time will tell whether virtualizing based on user and not application will create more havoc than do good. Because thanks to UAC malware needs no extra rights to botch up your registry...

Update Yes, sure, you can turn off this virtualization. Check out the blog entry User Account Control Windows Vista Policies.

Next week, I am doing the first in a series of security on-site briefings for Microsoft Austria. Mario has blogged about our TTT event in two entries Security Technical Briefings - Train-The-Trainer... a looong evening (Part 1) and Security Technical Briefings - Part 2. Thanks to the workshop character, no two briefings will be alike.

The process of threat modeling is built on a simple principle: To build a feasibly secure system, one must understand all the threats in that system. The challenge, however, is in making threat modeling more accessible to non-specialists. Microsoft has developed a process through which minimal input can produce a feature-rich threat model that identifies a wide range of critical information including contextual threats, trust boundaries, fracture points, attack surfaces, and direct and transitive access control. This podcast describes and demonstrates this threat modeling process, outlines its benefits, and shows how threat modeling fits into the Microsoft Security Development Lifecycle.

Download & Listen

Found this on Alex' blog (he posted it in German last week): Microsoft UK has released a document (PDF) titled "The Developer Highway Code" (The drive for safer coding), which covers the following topics:

• Integrating Security into the Lifecycle
• Security Objectives
• Web Application Security Design Guidelines 
• Threat Modelling
• Security Architecture and Design
• Security Code Review
• Security Deployment Review

The document covers v1 and v2 of the .NET Framework, and it does contain useful checklists. Be sure to grab it!

During the MVP Open Day in Munich last week (Friday & Saturday), we had a presentation by Talhah Mir (ACE Team, Threat Modeling blogs) on threat modeling - which (I hope) everyone is familiar by now. During the talk, he pointed us to an interesting resource: A Chronology of Data Breaches from the Privacy Rights Clearinghouse. Quite an interesting list of incidents, which gives you an idea of the ratio of actual hacking vs dishonest insider, as well as other types of security breaches.

Aside from disabling UAP, I also went back to THE Administrator account. Doing so can get quite messy unless you join your Vista box to a domain, as outlined in the blog entry Trouble signing on as THE Administrator on 5308? Now I have access to applicationHost.config again. Good security does get in the way, but this is just way too onerous.

After 'killing' three Vista installations yesterday, laziness got the better of me. I launched msconfig.exe, went to the Tools tab, and did this:

A reboot later I am a happy (and no longer annoyed) camper. Security obviously went out the window, however, I don't think this installation will live long enough either for this to be an issue.

If you need to find out just what devices are running Web services in your network (aside from the obvious Web servers, this includes nowadays printers, access points and many more), then you should check out httprint. It doesn't rely on server banners or fall for other obfuscation techniques, so it is quite handy to find out just what software is running on that box.

In case you need it too: Configuring SSL Host Headers shows you how to get up and running with one IP, port and certificate but multiple host headers. All you need is a wildcard certificate (learn more here) and some CLI magic because there is no UI for it. Basically, it boils down to (for example):

adsutil.vbs set w3svc/siteid/SecureBindings ":443:host.wildcarddomain.com"

Don't know how this one could slip by me - Windows Server 2003 Service Pack 1 (SP1) shipped a rather important update: you can run SSL in kernel mode (http.sys) instead of user mode. There are restrictions which are detailed here (most B2C SSL sites will do just fine), and the procedure to enable kernel-mode SSL shows how to get up and running in no time. Mostly you are only dealing with the registry key HKLM\System\CurrentControlSet\Services\HTTP\Parameters\EnableKernelSSL.

Six short & modular security training modules have been launched:

• Canonicalization Lab
• Cookies Lab
• Cross Site Scripting Lab
• Regular Expressions Lab
• SQL Injection Lab
• Validation Controls Lab

Brought to you by MSDN TV: Watch the White Hats and the Black Hats battle for the security of Las Vegas, Nevada. Jessi Knapp and Microsoft Security Guru Joe Stagner narrate as the Hackers try to gain control of The Plaza's online money management system and our Security Team tries to stay one step ahead.Watch

On my flight to Seattle today (or yesterday, depending on the time zone) I started to read Professional ASP.NET 2.0 Security, Membership, and Role Management by Stefan Schackow. The book definitely is a must-have for every ASP.NET developer, even if you decide to read one chapter only: A Matter of Trust (#3). This one will save you loads of time when you have to deploy an application into non-full trust environments. However, the other chapters are worthwhile too, like #2 which details exactly which identity is used when by what part of the engine. Bottomline: highly recommended reading.

THE security scanner has been made available in version 4.0. Nmap is a tool you should not miss out on when you are in need of scanning networks and hosts.