Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

July, 2007

  • Alik Levin's

    Man-In-The-Middle-Attack: Protecting Http Traffic With SSL Might Be Not Enough - Consider Protecting SQL Traffic Too

    • 1 Comments

    Think configuring SSL for your web site is enough to protect against prying eyes?

    Here is how the sensitive data can be exposed by sniffing your SQL traffic.

    Consider common simple 3 tier web architecture for data driven web site. The Web and DB server (it really does not matter what vendor it is) are physical separate machines as depicted below:

    image

    It is common practice to apply SSL for web traffic so that bad guy won't be able to easily see what runs on the wire. It is less common practice to apply network protection to the traffic that goes between the Web and DB server. In some cases it is possible to pretty easily sniff  that traffic, or as they call it to launch Man-In-The-Middle-Attack.

    One of techniques to sniff the traffic is first launch ARP poisoning attack and then just fire up any network protocol analyzer. For ARP poisoning the tools can be found freely here - www.insecure.org - and I used Cain and Abel. Linux friends will probably use Ettercap (what a nice "how to" they have ) and I used new shiny and freely available Microsoft Network Monitor for protocol analyzing.

    Here is how my web site looks (I just returned some sample data from AdventureWorks database over SSL):

    image

     

    And here is what I fished in my net using MS Netmon while sniffing the traffic between the Web and DB server:

     

    image

     

    And here is how it looks after pasting it into my favorite tool - Notepad:

    image

     

    Go back to the first image and compare.

    This is just email address, now think about a bit more sensitive data like your bank account balance or credentials. Is it secure on its way from the Web server to DB server?

     

    Conclusion and Countermeasures

    To build more secure system it is not enough to apply SSL or IPSEC here and there - it is about the holistic approach through the whole development process. Specifically for the case at hand consider the following resources when designing, building, and deploying your next system:

     

    This post was inspired after watching presentation by Marcus Murray he has given during Microsoft Tech·Ed 2007 in Orlando - Why I Can Hack Your Network in a Day! [A live demonstration of techniques and tools used by hackers to compromise your network].

    I am curious (or should I say I am freaked out) who else was inspired to do what after watching it?.....

    It is scary presentation - do not watch it before you go to sleep. Especially if you are responsible for your org's IT in some way...

  • Alik Levin's

    Use Sysinternals DebugView To Diagnose The Application

    • 7 Comments

    "Unspecified error", "Catastrophic failure", "Object reference not set to an instance of an object" and other "self explanatory" errors promise no easy debugging. Good instrumentation of the application  to the rescue! The techniques described in the paper explores on very often overlooked healthmonitoring feature of ASP.NET 2.0. It supports few providers - mechanisms that collect and log the events emitted by the application:

    • SimpleMailWebEventProvider. This provider sends e-mail for event notifications.
    • TemplatedMailWebEventProvider. This provider uses templates to define and format e-mail messages sent for event notifications.
    • SqlWebEventProvider. This provider logs event details to a SQL Server database. If you use this provider, you should encrypt the connection string in your Web.config file by using the Aspnet_regiis.exe tool.
    • EventLogWebEventProvider. This provider logs events to the Windows application event log.
    • TraceWebEventProvider. This provider logs events as ASP.NET trace messages.
    • WmiWebEventProvider. This provider maps ASP.NET health monitoring events to Windows Management Instrumentation (WMI) events.

    Nothing is to log into file or to show interactively though.

    Here is another way for quick and dirty understanding what happened in the app (assuming instrumentation is in place). Instrumentation mechanism is my old friend System.Diagnostics.Debug.WriteLine(string message). This command emits messages to OutputDebugString. The best tool that collects and shows the messages that I found so far is Sysinternal's Debugview.

    The following code:

        protected void Page_Load(object sender, EventArgs e)
        {
            Trace.WriteLine("Loading the page");

        }

    Would interactively look like this:

    image

    DebugView also offers logging the events into file - very handy.

     

    While healthmonitoring is great to log stuff for later analyzing, tracing with DebugView is great for interactive debugging. I can think of some wrapper class that is used by the application to log the messages, and the implementation uses both healthmonitoring custom events and Debug.WriteLine. Both then rely on the web.config stuff.

     

    Enjoy and happy debugging, tracing, instrumentation, and other veggies.

  • Alik Levin's

    WCF Security In Intranet Scenario : Thoughts On Cons and Pros

    • 3 Comments

    I am researching on best practices with WCF security in terms of "YOU SHOUD" vs "YOU CAN". While it is great to have "How to" stuff I am also interested in "Why" angle. I have common simple scenario of WinForms client consuming WCF service inside corp walls with Active Directory deployed. Here is what I came up with while looking at Hosting Services and Common Security Scenarios.

    I have built simple Hello World WCF service that accepts Person object/message and echoes back "Hello, " + Person.FirstName. I was using DataContract serialization. I think it really does not matter what it does in terms of biz logic. What really matters for me is how to host it, what binding to apply, and what security settings to configure.

    For my intranet scenario "Message Security with a Windows Client without Credential Negotiation" would fit most I think. It utilizes Active Directory for authentication and message protection in transit as well saving me from messing with certs, transport level protection SSL, IPSEC style and plain vanilla UserName and Passwords. I think it is great and apparently it is a pro part from security stand.

    Since it uses wsHttpBinding binding I thought it would be natural choice to host it in IIS rather self hosted as it shows up in the example. Here I earn what IIS has to offer vs what I can write in C#...

    I also implemented scenario where I used basicHttpBinding with security set to None...

    I fired up Fiddler2 to see what runs on the wire in both cases. The difference was pretty notable in terms of response time and payload size. Of course all these goodies that come from using Kerberos from my Active Directory friend - authentication and message protection - have their cost in terms of performance. I guess it is cons part from performance stand. I presume the time is spent for negotiation with Domain Controller and for cryptographic operations - encryption and signing - for message protection. The other cons part would be message size that naturally inflates when encrypted.

     All my experiments are done with my demo lab domain that is totally based on VPC 2007 so the numbers should be taken with caution but I presume that it can give some food for thoughts. Consider simple message as follows:

    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">

       <s:Body>

          <SayHello xmlns="http://tempuri.org/">

             <person xmlns:a="......." xmlns:i=".....">

                <a:FirstName>Alik</a:FirstName>

                <a:LastName>Levin</a:LastName>

            </person>

          </SayHello>

       </s:Body>

    </s:Envelope>

    Here is what I captured using Fiddler:

     

    basicHttpBinding

    wsHttpBinding

    Message Encryption

     

    V

    Message Signing

     

    V

    Bites sent

    584

    8,014

    Bites received

    420

    5,286

    Time to last byte

    20 ms

    231 ms

    Conclusion

    When designing my next WCF solution for intranet scenario I will sure try to utilize current IT investment like AD and IIS to provide first class security and hosting services while saving on maintenance costs. On other hand I must take into account performance part, this consideration should reflect on message size - for example, think twice when tempted to use DataSet as DTO. It should also reflect on hosting options - using IIS 6.0 allows me to utilize Http traffic only.

    Here is my take on intranet scenario where Windows 2003 Active Directory and IIS 6.0 deployed:

    • Utilize AD for message security and authentication.
    • Host WCF in IIS 6.0. If I had Windows Server 2008 with IIS7 I'd go for WAS hosting for sure since it allows binding other than Http and I presume this should improve performance.
    • Do not use DataSets for DTO rather carefully design custom most lightweight DTO (yes, invest as much time as needed for that one).
    • Use DataContract serialization with opt-in approach (allows fine tune what gets to the wires and what is not).

    You have better suggestion for me around intranet scenario? If so, do not hesitate and drop me a line.

    Here is even more food for thoughts A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies

    Bon appetite.

Page 1 of 3 (8 items) 123