SharpTLSScan v1.1

The v1.0 post is here.

A few minor improvements.

  • Caught a couple of previously unhandled exceptions.
  • Improved the certificate subject and issuer visualization to handle commas embedded within quotation marks.
  • Added a color-coded legend to the help text briefly describing what red, yellow and green text mean.
SharpTLSScanv1.1.zip (14.7KB)

SharpTLSScan v1.0

Update 08/13/2014: v1.1 is here.

SSL and TLS have been getting a lot of attention from me lately, and recently I found myself in want of a tool that would tell me precisely which protocol versions and cipher suites a given server supported.

Sure, there's SSLScan and SSLScan-Win, but those tools haven't been updated in 5 years, and thus don't support the newer versions of TLS, 1.1 and 1.2.  And of course there are nice websites like SSL Labs that do a fine job, but I wanted to use this tool to audit internal/private systems too, not just internet web servers.

So I created a new tool and called it SharpTLSScan.  It's pure C# and has no reliance on outside libraries (such as OpenSSL,) and I managed to avoid the pain of directly interfacing with the SChannel API as well.

SharpTLSScan comes with the "It works on my machine (tm)" guarantee.  It's free, and the source will probably show up on Github pretty soon.

Here are some screenshots:

Usage is simple - SharpTLSScan myhost:636

First, the server's certificate is inspected and validated.  Next, a default connection is negotiated, which is useful for seeing what kind of connection your system would negotiate on its own.  Then, all protocol versions and all cipher suites are tested to see what the server will support.  (This can take a couple of minutes.)  Things that are obviously good (such as the certificate validating) are highlighted in green, while things that are obviously bad (such as SSL v2 support) are highlighted in red.  Things that are fair, but not great, (such as MD5 hashes) are in yellow.


*Oh dear...*

The reason why the protocol versions seem interleaved is a side-effect of a the multithreading in the program.  I'll likely fix it in the next update.

Here you go:

SharpTLSScan.zip (14.3KB)

Disable RC4-HMAC (And Others) in Active Directory

My long-distance pal Mathias Jessen pointed out this article today on Twitter, in which the article's author attempts to make us all shudder in fright at the idea that Microsoft Active Directory has a terrifying security vulnerability that will cause the world's corporate infrastructure to crumble and shatter humanity's socio-political status quo as script-kiddies take over the now destabilized Earth.

OK, it's not all that bad...

Of the several encryption types that AD supports for Kerberos authentication, RC4-HMAC is among the oldest and the weakest.  The reason the algorithm is still supported?  You guessed it... backwards compatibility.  The problem is that in this (perhaps ill-conceived, but hindsight's 20/20) implementation of RC4-HMAC, as outlined in RFC 4757, the encryption key that is used is the user's NT/MD4 hash itself!  What this means is that all I need is the NT hash of another user, and by forcing an AD domain controller to negotiate down to RC4-HMAC, I can be granted a Kerberos ticket as that other user.  (Getting another user's NT hash means I've probably already owned some random domain-joined workstation, for instance.)

As you probably already know, an NT hash is essentially password-equivalent and should be treated with the same level of sensitivity as the password itself.  And if you didn't know that, then you should read my earlier blog post where I talk a lot more about this stuff.

This was a deliberate design decision - that is, Microsoft is not going to just patch this away.  The reason they chose to do it this way was to ease the transition from NTLM to Kerberos back around the release of Windows 2000.  Newer versions of Windows such as Vista, 2008, 2008 R2, etc., use newer, better algorithms such as AES256_HMAC_SHA1 that do not use an NT hash.  Newer versions of Windows on a domain will automatically use these newer encryption types by default, but the older types such as the dreaded RC4-HMAC are still supported and can be used by down-level clients... or malicious users pretending to be down-level domain members.

As an administrator, you're free to turn the encryption type off entirely if you do not need the backwards compatibility.  Which you probably don't unless you're still rockin' some NT 4.0 servers or some other legacy application from the '90s.

(Which probably means most companies...)

Edit the Default Domain Controllers (or equivalent) Group Policy and look for the setting:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Configure encryption types allowed for Kerberos.

This setting corresponds to the msDS-SupportedEncryptionTypes LDAP attribute on the domain controller computer objects in AD.  Enable the policy setting and uncheck the first three encryption types.

And of course, test in a lab first to ensure all your apps and equipment that uses AD authentication can deal with the new setting before applying it to production.

TechEd 2014

I have been wanting to attend TechEd for several years now, and finally I've attended my first one this year in Houston, Texas. Overall it was a great experience, although I was a little overwhelmed by having so much that I wanted to see and do and not enough time to do it all. I also feel disappointed that there was an emergency back home while I was at TechEd so I had to cut the trip short and miss an entire day of the conference. But, it's not the end of the world. I hope to be able to go back for TechEd 2015 next year.

Here are a few of my thoughts.

TechEd 2014 George R Brown Convention Center

I drove to Houston from Dallas, and arrived here at the George R Brown convention center on about 1 hour of sleep. Luckily I signed up as soon as registration opened, which meant that I was able to book a hotel room in the Hilton right across the street. All I had to do to get back and forth from my room to the convention center was cross the catwalk.


Monday's Keynote

It was extremely crowded. This conference was not for the agoraphobic. In fact, the conference was so congested, and the convention center so poorly designed to handle such a large crowd, it made it difficult to even move around at times. Many of the sessions (especially the Russinovich sessions) filled up 30 minutes before they were scheduled to begin. This was the first year Microsoft consolidated the MMS and TechEd conferences though, which did not help.

The conference center was a gigantic cuboid structure with no thought given to traffic flow, restroom layout, etc.

Endless hallway of TechEd conferences

That being said, the content was still great. Tons of cutting-edge System Center, Powershell Desired State Configuration, Azure stuff, and lots of security talks. (AKA "Trustworthy Computing") Lots, and lots of security talks. I almost lost count of how many times I got to see the presenters try to scare us by showing us Mimikatz to dump lsass.exe private memory, or export "non-exportable" private keys. And all the rockstars were there too; the guys that are essentially celebrities to me because of the awesome stuff they've done while at Microsoft.

Some of the other great content I saw:

  • Virtual Machine Manager Network Virtualization, which neatly solves the overlapping IP address situation in a multi-tenant environment.
  • Freaking Azure Pack which allows you to essentially deploy your very own private Azure inside your own organization.
  • Aaron Margosis trying to convince us to go up to Mark Russinovich and say to him, "Mr. Cogswell, I'm a huge fan of your work..."
  • Jeffrey Snover muttering "god damnit" to himself over and over again under his breath while trying to show us how to change the color of error text in our Powershell console.
  • Getting to pitch my idea to one of the Windows client security guys about LogonUI.exe performing a hash check on utilman.exe before launching it from the Accessibility button.
  • Etc.

Just another shot of the huge crowd
Just another shot of the endless sea of people.

High-tech signs
And an example of the high-tech digital signage.


Me and Ed Wilson
Me and Ed Wilson, AKA Dr. Scripto


Me and Mathias, whom I met on ServerFault, after a night of exploring the Tech Expo, drinking beer, walking, talking about the pathetic state of healthcare in the United States, and eating at the Cheesecake Factory.

Speaking of tech expo, this year it was all about SSDs, flash memory, ridiculous amounts of RAM for all your SQL 2014 In-Memory OLTP processing, and 56 gigabit Infiniband RoCE setups:





I hope to see you again next year, TechEd...

Redirecting HTTP to HTTPS with the IIS URL Rewrite Module

I should use TLS

Hi folks. I've been working on my HTTP web server the past couple of weeks. It's pretty good so far. It uses the managed thread pool, does asynchronous request handling, tokenization (like %CURRENTDATE%, etc.) server-side includes, SSL/TLS support, can run multiple websites simultaneously, etc. It seems really fast, but I haven't put it through any serious load tests yet.  My original goal was to use it to completely replace this blog and content management system (IIS and BlogEngine.NET,) but now I'm starting to think that won't happen. Mainly because I would need to convert years worth of content to a new format, and I would want to preserve the URLs so that if anyone on the internet had ever linked to any of my blog posts, they wouldn't all turn to 404s when I made the switch. That's actually more daunting to me than writing a server and a CMS.



So I'm taking a break from that and instead improving what I've already got here. One thing I've always wanted to do but never got around to was redirecting HTTP to HTTPS. We should be using SSL/TLS to encrypt our web traffic whenever possible. Especially when it's this simple:

First, open IIS Manager, and use Web Platform Installer to install the URL Rewrite 2.0 module:

Install URL Rewrite


Now at the server level, open URL Rewrite and add a new blank rule:

Add Blank Rule


Next you want to match (.*) regex pattern:

Edit the rule


And finally add the following condition:


Condition


And that's all there is to it!  This is of course assuming that you've got an SSL certificate bound to the website already, and that you're listening on both ports 80 and 443.

Note that you can also do this exact same thing by editing your web.config file by hand:


    
<system.WebServer>
   ...
   <rewrite>
      <globalrules>
        <rule name="Redirect to HTTPS" stopprocessing="true" enabled="true">
          <match url="(.*)"></match>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"></action>
          <conditions>
            <add pattern="^OFF$" input="{HTTPS}"></add>
          </conditions>
        </rule>
      </globalrules>
    </rewrite>
</system.WebServer>

And finally, a tip: Don't put resources such as images in your website that are sourced from HTTP, regardless if they're from your own server or someone else's. Use relative paths (or at least the https prefix) instead. Web browsers typically complain or even refuse to load "insecure" content on a secure page.