Alik Levin's : Authentication

Security Code Review – String Search Patterns For Authentication Vulnerabilities

alikl — Mon, 21 Jul 2008 15:39:59 GMT

This post contains string search patterns that can help identifying authentication vulnerabilities during security code inspection for your ASP.NET application. Most common vulnerability is about insecurely manipulating credentials in the code. The question we want to actually ask is:

Are you passing clear text credentials?

The associated threat is identity theft or identity spoof that can be achieved by disclosing the credentials or/and tampering it.

What to Search for and Why

Credentials are usually required when accessing a down stream resource – database, web service, active directory, MQSeries, or any other. This information can be easily obtained from the architecture document. Following are possible searches that can lead you to the hotspots to nail potential authentication vulnerabilities:

DB Connections

findstr /S /I ".Open( " *.cs

Web Services

findstr /S /I ".Credentials =" *.cs

LogonUser API – usually used for impersonation

findstr /S /I "LogonUser" *.cs

IIdentity usage

This one is my favorite. This search pattern is actually trying to spot the anti-pattern of identifying end user. The assumption here is that when there is no matches for that search then the solution either does not identifies the requests or uses home grown solution which might be potential vulnerability in both cases.

findstr /S /I “.Identity" *.cs

Other than above searches it is good idea to review the web.config file for potential clear text credentials.

Got more suggestions for search patters to identify potential authentication vulnerabilities? - Please, share!

Avoid Manipulating Passwords In Memory - It Is Easy To Reveal

alikl — Sat, 08 Dec 2007 08:55:40 GMT

Revealing clear text passwords in memory seems to be a trivial task. This post describes how to reveal clear text passwords and what countermeasures to apply.

Summary of steps:

Install WinDbg
Attach to process or open dump file
Load SOS .Net extensions for WinDbg
Enumerate threads
Enumerate objects in thread
Dump object's values
Countermeasures and guidelines

Install WinDbg

Download and install WinDbg as described in How to install Windbg and get your first memory dump.

Attach to process or open dump file

WinDbg can analyze both running processes and memory dumps which conveniently can be taken offsite for further investigation. I've created simple console application that accepts user name and password pair as its parameters and stores in local variables in memory:

static void Main(string[] args)
{
string userName = Console.ReadLine();
string password = Console.ReadLine();

Console.ReadLine();
}

Compile and run the application. I called it SecretsInMemory. This is how it looks when running:

Attach WinDbg to the running application by opening File->Attach to a Process:

and press Ok.

Alternatively, we can create dump file - for detailed how-to refer to How to install Windbg and get your first memory dump.

To Investigate resulting dump file in WinDbg open File->Open Crash Dump

Load SOS .Net extensions for WinDbg

To analyze .Net assemblies we need to load .Net extensions by typing .load sos and hitting Enter:

Enumerate threads

Run !threads command to enlist available threads:

and then choose specific thread - use left most column for thread identification as follows ~[thread number goes here]s:

Enumerate objects in thread

Use !dso command to dump all objects in the thread:

Dump object's values

Use !do <object address> to dump specific object's values. Object address is a second column in the list generated by !dso command, the column named "Object" - just copy and paste it:

The password is revealed either by attaching to the process or analyzing a crash file that was taken offsite.

Countermeasures and guidelines

As rule of thumb avoid using custom built identification and authentication mechanisms and leverage those that the infrastructure offers - preferably Windows Integrated authentication. In case where all options exhausted and there is no other way but accept end user credentials, refer to the following article - Using Credential Management in Windows XP and Windows Server 2003. Techniques described in the article allow to leverage built in mechanism of accepting credentials from end user in more secure manner. It also keeps common familiar look and feel across custom application and built in Windows mechanisms leaving less room for end user confusion.

My related posts:

Authentication Hub

Other resources:

Authentication And Identity Flow When ASP Page Consumes ASP.NET Web Service

alikl — Wed, 05 Sep 2007 19:04:00 GMT

"Classic" ASP has application isolation that is different from ASP.NET. Here is one of the real world scenarios where it might matter.

There is a legacy web application written in ASP and hosted on Win2K3 box (IIS 6.0). It is of course in the process of migration to ASP.NET. As part of the migration process there were several ASP.NET web services factored out of the classic ASP app. These web services are hosted on another Win2K3 box and require windows authentication. Classic ASP must consume these web services while satisfying the requirement of windows authentication. ASP page consumes the web service via .Net COM interop invoking .Net component:

The question here is what is this account that ASP page authenticates to ASP.NET web service on another machine?

It is common mistake assuming that the account is the application pool's one. ASP does not run in the context of the application pool. In case of anonymous access It runs in the context of what defined for anonymous user:

Said that, in order to let ASP page authenticate to ASP.NET web service based on windows authentication one needs to define domain account in above property page for virtual directory where ASP resides. This is the account that will hit the ASP.NET web service.

Client Certificates Authentication - Dirty Trick To Disable CRL Check. For Demos Only!

alikl — Tue, 14 Aug 2007 18:12:55 GMT

My lab domain has MS CA installed in it so I am able to issue certificates to the left and to the right. Recently I spent some time to understand why client certificates authentication does not work. More precisely the certificates dialog box was offering no client certificate to chose, as depicted below:

I first thought it is something on the client machine but after some investigation it turned out that it is IIS' part. IIS was unable to verify CRL. I was not in the mood of deploying CRL's so I decided to look into how to disable this feature. Here it is:

http://forums.iis.net/t/1100044.aspx

   Set oWeb = GetObject("IIS://localhost/W3SVC")
   oWeb.CertCheckMode = 1
   oWeb.SetInfo
   Set oWeb = Nothing

Open notepad paste the code above and save with vbs extension. Run it by double clicking it. Your IIS now do not give a damn about CRL.

NOT THE BEST OPTION FOR PRODUCTION ENVIRONMENT.

Good enough for demos.

Enjoy.

Web Services Over SSL - Is It Really That Slow Like They Say?

alikl — Wed, 01 Aug 2007 17:35:18 GMT

My answer is "no".

I am working on solution where there is no Windows Active Directory Domain so we cannot utilize our beloved Kerberos and Windows Integrated Authentication saving big on configuration and management while taking advantage of increased security it offers.

Other technique that we thought that could give us a lots of benefits in terms of strong authentication, transport level protection, and interoperability was using Client Certificates.

Here is the scenario.

ASP.NET web page calls on ASP.NET Web Service on separate machine. Think of scenario where Internet facing ASP.NET web site calls on Web Service deployed in internal zone:

The other scenario would be so called B2B scenario where intranet facing ASP.NET web site calls on Web Service over the Internet:

Another scenario would be calling Java Web Service.

Not that friendly for Windows Integrated Authentication.

The question we asked ourselves was - will it be fast enough? The following post by my colleague Eddie - Fast and Secured: Performance Impact of SSL gave us a lots of hope. But it discussed SSL between Web Browser and the Web Server. Web Browser (IE) has nice feature of caching SSL state so what depicted below happens less thus improving performance (think of OLEDB Connection pooling and you got the idea):

Well, our beloved Internet Explorer does a great job, what about .Net?

After some research we happily discovered the following:

http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.aspx

Note:

The Framework caches SSL sessions as they are created and attempts to reuse a cached session for a new request, if possible. When attempting to reuse an SSL session, the Framework uses the first element of ClientCertificates (if there is one), or tries to reuse an anonymous sessions if ClientCertificates is empty.

That was encouraging and I decided I need to see it my eyes, so I set sample code and deployed to my lab domain. I also have used diagnostics technique described in Use Sysinternals DebugView To Diagnose The Application. When I fired up DebugView this is what I saw:

Each pair of records reflects on single Web page access telling me how many milliseconds was spent on each action to complete during the page processing.

Notice first two records - one for Web Service proxy creating and adding certificate to it:

//START STOPWATCH

Stopwatch stopwatch = new Stopwatch();

stopwatch.Start();

//GET HOLD ON CERT

X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);

store.Open(OpenFlags.ReadOnly);

X509Certificate2Collection certs = store.Certificates.Find(X509FindType.FindBySubjectName, "w3w1", true);

X509Certificate2 cert = certs[0];

//CREATE WEB SERVICE PROXY

Service1 proxy = new Service1();

proxy.ClientCertificates.Add(cert);

Debug.WriteLine("Web Service Proxy Created: " + stopwatch.ElapsedMilliseconds.ToString());

and the second one is actual Web Service call:

// CALL ON WEB SERVICE

string result = proxy.HelloWorld(cert.Subject);

Debug.WriteLine("Web Service Call Completed: " + stopwatch.ElapsedMilliseconds.ToString());

Notice that all subsequent calls are pretty fast. It should prove that SSL session caching is in place also with .Net as promised. Cool.

Conclusion

While these numbers have been taken on lab environment for super simple scenario it can serve as talking point when considering applying SSL to protect your sensitive data to its way to downstream servers. Also client certificate authentication should be considered as a strongest authentication available today when Kerberos is not available.

T-Shooting Kerberos

alikl — Thu, 05 Jul 2007 00:16:00 GMT

I was delivering "Authentication Explained" session for Security User Group.

First off - thanks for attending the session!

The session was based on "Authentication Explained" workshop. During the session I was demoing the following topics:

During the preparation for the session I struggled a bit with our friend Kerberos and I stumbled on very nice resource on technet:

The articles are very comprehensive and detailed - very handy.

Happy Kerberos t-shooting (troubleshooting)

Enjoy

SOA, Strong Authentication, Standard Authorization - Cool Solution

alikl — Wed, 30 May 2007 15:45:00 GMT

reposted from here

I've previously blogged about SOA Security Inside Enterprise walls

This time I had couple of pretty interesting requirements from one customer that targeted B2B/Partners scenario. They had a web site that communicates to partner's web services. His concerns were sincere and pretty fair:

I want to manage my creds that I use to authenticate with the partner's web service in secure way
I want to pass it it over the wire in secure standard way
The partner won't do any major changes to his authorization schema inside the web service
Authorization schema must be easy to managed and standard

Without any hesitation I've gone to the following topic -

How To: Call a Web Service Using Client Certificates from ASP.NET 1.1

and implemented step by step what was described. In the code you see that one needs to export client certs. Customer's concern was about how safe the cert is, no worries - it is getting exported without private keys:

Last thing what I needed to do is Web Service authorization, so what I've done is I mapped the client cert to windows account on the web service machine like this:

Then in the web service code I've applied standard Role demands (well specifically here I demand specific user, but it could be group too like "...Demand, Role =@"myServer\Group8"")

And when the app was calling the web service method it was picking the client cert and sending it over to the web service which in turn was mapping it to windows account and the principal permission was applied to this account. When I was calling HelloWorld1() everything was fine since it was protected by user demand to which the cert is mapped to, on other hand HelloWorld2() was rejected since the cert I was sending is NOT mapped to that user. Man, these are those rare moments that I am happy to see exceptions :)

Conclusion:

Using minimal of coding (client side - couple of lines, server side - one line for each method) and standard configurations of the infrastructure I've achieved:

On caller's side the creds are managed in standard secure way - the client cert sits in User Store
Client certs authentication is considered one of the strongest authentication mechanisms
All the data goes over secure communications - SSL3
Web Service utilizes standard .Net authorization mechanisms which required no coding (almost)

Now tell me why it is not COOL :)

Cheers

Adding Shared SNK File In Visual Studio 2005

alikl — Mon, 16 Apr 2007 17:24:15 GMT

“Prior to Microsoft Visual C# 2005, you specified the key file using CLR attributes in source code. These attributes are now deprecated.

Beginning in Microsoft Visual C# 2005, you should use the Signing Page of the Project Designer or the Assembly Linker to specify the key file.”, more here

Creating SNK file in VS2005 is handy using nice UI:

Most of times the solution is built of multiple projects and I'd like to share the same SNK file with all my projects.

If I create SNK file and then add it to my projects it copies local copy to each project - having multiple copies is a mess.

Here is the solution.

Create one SNK file, either using SN utility or using VS2005.
Right click on project you want to sign it with and choose to add existing item.
Browse to the SNK file and add it as link:

Go to the project's prop's page - SNK file should be listed in the drop list:

If you are not afraid of directly messing with SLN files then notepad or some scripting magic (Scriptomania - Scripting Tools and Utilities) are your friends (NOTE - there are multiple places SNK is referenced in it):

there may be more places...

One master SNK - no mess :) - so far.

Enjoy

Authentication Hub

alikl — Wed, 11 Apr 2007 23:04:00 GMT

Windows Authentication

Certificates

CardSpace

Basic Steps To Make ASP.NET Web Site CardSpace Aware

WCF

Identity and Access Developer

Identity Flow Through Physical Tiers - Protocol Transition

alikl — Tue, 10 Apr 2007 15:27:35 GMT

If these articles:

are your friends then do not waste your time on this post, please.

The scenario is the same where user sits behind her machine A and access simple ASPX page on box B that access file on share on box C, like this:

What I have so far is:

Identity Flow Through Physical Tiers - works fine, network resource (the file on network share) accessed by app pool account
Identity Flow Through Physical Tiers - Impersonation - does not work
Identity Flow Through Physical Tiers - Delegation- works great and the network resource is accessed by end sure's account

Now I have scenario where employee that tries to access corporate web site she used to use while inside corp walls but this time over Internet.

Another scenario would be where my customers access my web site from Internet and I manage customers identity store using Active Directory (not as just LDAP store rather full blown AD Domain, for LDAP store use ADAM - free download).

I presume in these scenarios the web site would be accessible only over port 443 (default SSL port) - no chance for Windows integrated authentication (which only supported by limited number of browsers... I mean authentication, not SSL).

Here comes in Protocol Transition (PT). Windows 2003 has cool feature - creating windows security context out of thin air - no password and LogonUser WIN API call required....

Keith Brown goes really deep while Exploring S4U Kerberos Extensions in Windows Server 2003

I go for it, here some additions to what was already done in Identity Flow Through Physical Tiers - Delegation:

Get rid of all or nothing impersonation in web.config:

Configure both app pool account and the server to support constrained delegation for non-Kerberos authentication using Active Directory users and Computers MMC (CIFS stands for the Common Internet File System, the name of the Microsoft^® file server - from Using Protocol Transition—Tips from the Trenches)

That's scary a bit one - define app pool account to "Act as part of OS" using Local Security Policy MMC on web server (why it is scare and how to handle it - see Using Protocol Transition—Tips from the Trenches)

Add code that actually utilize Protocol Transition creating WindowsIdentity based on UPN (user principal name) that came in after custom authentication and explicitly impersonate the thread before accessing network resource - our file on share:

string upn = txtCustomUPN.Text;//CAN COME FROM ANY PLACE
//DO INPUT VALIDATION HERE!!!!!

WindowsIdentity wi = new WindowsIdentity(upn);

WindowsPrincipal wp = new WindowsPrincipal(wi);

HttpContext.Current.User = wp;

WindowsImpersonationContext wic = wi.Impersonate();

// ACCESS NETWORK RESOURCE

wic.Undo();

No when I ran my app here is what I get (no impersonation):

Now I simulate passing UPN that came from custom authentication (xacker@demo.lab is valid AD account):

the code above is ran after pressing "Protocol Transition" button

and here is the result of access audit:

Techniques for file access audit are here:

Enjoy

Basic Steps To Make ASP.NET Web Site CardSpace Aware

alikl — Mon, 09 Apr 2007 15:26:35 GMT

From short investigation and a lot of information from Richard Turner's screencasts

Here is what I get. To make my ASP.NET app I need:

Write ASP.NET server side code to validate the token that holds end user's data, further processing might include checking against membership provider - CardSpace Simple Demo screencast on Channel9
Add client script code to specify CardSpace object and its properties, like required claims. This will trigger CardSpace UI to show up for the end user - CardSpace Simple Demo screencast on Channel9
Configure IIS to require SSL connection - New Screencast: How to configure IIS7 for Windows CardSpace sites
Give application pool account read access to private key for the server cert that actually gives SSL support. This is needed for decrypting the XML token in the server code for its further deserialization - Secure your private keys more easily with Vista

I got it right? Forgetting something?

Identity Flow Through Physical Tiers - Delegation

alikl — Sun, 08 Apr 2007 19:53:17 GMT

If these articles:

are your friends then do not waste your time on this post, please.

I have still the same scenario - user sits behind her machine A and access simple ASPX page on box B that access file on share on box C

In previous posts:

Identity Flow Through Physical Tiers - Impersonation - access failed.
Identity Flow Through Physical Tiers - the network resource was accessed under App process account.

This time I really want to access the file on share (box C) under end user's account, e.g. flow end user's identity 2 hops - from end user's machine A to web server B and then to the file share - box C.

That is Delegation.

To enable delegation there is a need to accomplish the following:

1. Everything that was needed for impersonation (configure IIS and web.config for windows authentication).

2. Mess a bit with Active directory using Active Directory Users and Computers MMC:

Configure both App pool account and the Web Server to support delegation:

Since I run my App pool under custom domain account I need to create SPN for it. Keith Brown explains it perfectly in his Credentials and Delegation

iisreset can help sometimes :)

kerbtray (Win2k, Win2k3) can help too to purge Kerberos tickets instead logging off and on.

Also AuthDiag tool is handy too to diagnose Kerberos issues, for example to make sure that my app pool account has SPN defined in AD.

After accessing the page again here is what I have (meaning impersonation works fine):

And the file on the share (box C) is accessed by end user's identity - DEMO\Administrator:

I think it is cool.

How to analyze who access my files - see:

Next post is even cooler - I will walk through Protocol Transition - very similar to Delegation but the end user's security context is created out of thin air without authentication against Active Directory

Huh? Sounds absurd? It did to me when I first discovered it...

Enjoy

Identity Flow Through Physical Tiers - Impersonation

alikl — Fri, 06 Apr 2007 21:54:00 GMT

There are scenarios where actual windows identity of end user needs to be flowed to the server so that server can perform action on end user's behalf - that is in nutshell Impersonation. In previous post Identity Flow Through Physical Tiers - one might think that the end user identity flowed but in fact it was not. Although HttpContext held end user's account - DEMO\Administrator - and even identity's type was WindowsIdentity, the actual windows thread was ran under Application Pool's account - DEMO\W3WRUNNER1. That means that the resources were accessed under App Pool account - DEMO\W3WRUNNER1 - just as depicted in the post.

While scenario is the same where user sits behind her machine A and access simple ASPX page on box B that access file on share on box C, like this:

lets do some small changes, and define impersonation in web.config file:

Now lets access the aspx page:

Seems like impersonation works - both HttpContext and windows thread has the same, end user's identity - cool, good job.

But when the code reaches the line where the file on share (Box C) is accessed, something goes wrong:

Why? It worked in previous post...

The reason for such behavior is that I got my architecture confused...

On one hand I asked app process, sorry, specific request's thread to run under end user's account - Impersonation - by setting impersonate="true" in web.config. On other hand I ask this thread to go out to network resource - my file on file share. That is another Impersonation... In scenario where the resource sits on the same box, Web Server B, impersonation would work, but in our case - the resource sits on other machine C.

In other words I am trying to flow identity over two hops - from end user machine A to web server B and then to File share C - that is more than Impersonation, but Delegation which will be discussed in the next post.

Identity Flow Through Physical Tiers

alikl — Fri, 06 Apr 2007 00:23:01 GMT

Identity story with .Net really rocks, but along with great extensibility it also brings a lots of confusion (One Identity - Many Faces :IIdentity).

I am building now workshop for developers that concentrates on authentication only. It talks about concepts, implementation, scenarios, and of course a bit of hacking exposed - entertaining part never hurts :)

I plan to allocate some time for .Net identity implementation, based on IIdentity, in conjunction with what Windows System provides.

My first scenario is simple one where user sits behind her machine A access simple ASPX page on box B that access file on share on box C, like this:

Everything is managed by Windows 2003 Active Directory Domain - Demo.lab

User name is DEMO\Administrator.

Web application runs under DEMO\W3WRUNNER1 service account, specified in application pool configuration.

Web site is set to use Window authentication in web.config and IIS is configured for Windows authentication.

What user runs the app's security context?

Under what account the file on box C is accessed?

To answer the first question I echo back the following data (meaning there is no single answer for it)

lblHttpCoontextUser.Text = User.Identity.Name;

lblWindowsThreadUser.Text = WindowsIdentity.GetCurrent().Name;

lblAuthType.Text = User.Identity.AuthenticationType;

And to answer the second question I use techniques described in File Access Auditing - I Am Not Afraid Of GPO and Who Access My File?

and/or

Enjoy

Who Access My File?

alikl — Tue, 03 Apr 2007 21:02:32 GMT

In my post File Access Auditing - I Am Not Afraid Of GPO I've digested technet documentation on how to set Active Directory Group Policy Object (AD GP) to enable file access auditing as security measure to prevent repudiation. It is heavy weight techniques for scenarios where developer just needs to understand why she gets "Access denied" during development or while deploying in test environment - "Strange, it all worked on my machine...." :)

For that purpose I use two light weight tools from Sysinternals, the whole portal of Sysinternal's tools is here Windows Sysinternals loaded with free goodies.

First tool is file monitor (filemon) - it monitors file access activity and when double clicking on some line it shows the user accessed that file:

But when the file is accessed from other machine, filemon does not have this information:

Mark Russinovich kindly explained me why it is not there and suggested using another great tool - process monitor. The tool has details column which includes the data what I was looking for - Impersonating:<<account name>>:

Very cool, very usable, very light weight

Enjoy

Alik Levin's : Authentication

Security Code Review – String Search Patterns For Authentication Vulnerabilities

What to Search for and Why

Related posts

Avoid Manipulating Passwords In Memory - It Is Easy To Reveal

Authentication And Identity Flow When ASP Page Consumes ASP.NET Web Service

Client Certificates Authentication - Dirty Trick To Disable CRL Check. For Demos Only!

Web Services Over SSL - Is It Really That Slow Like They Say?

T-Shooting Kerberos

SOA, Strong Authentication, Standard Authorization - Cool Solution

Adding Shared SNK File In Visual Studio 2005

Authentication Hub

Identity Flow Through Physical Tiers - Protocol Transition

Basic Steps To Make ASP.NET Web Site CardSpace Aware

Identity Flow Through Physical Tiers - Delegation

Identity Flow Through Physical Tiers - Impersonation

Identity Flow Through Physical Tiers

Who Access My File?