Friday, July 25, 2008

Smart Cards, Common Access Card (CAC), HSPD-12 and you...

I was searching the Internets for a sensible article, post, anything on the practical application of smart cards and came up with a lot of technical jargon and solutions but not much practical information for the everyday Joe security guy or admin.  Why should I care?  Well, as logical and physical security technologies evolve, the use of a smart card (and a RFID or GPS one at that) seems quite useful as an access replacement to current technologies.  It would only follow that governments and big business will be soon to follow suit in implementing this technology... so why not start making it simple to understand?  

What are smart cards?

OS Insecurity:  How does your favorite OS deal with these scenarios when CAC authentication is enabled?
  • Remote administration
  • Non-Kerberos or non-PKI authentication
  • Services running as users instead of system
  • Emergency root-level access

Microsoft Windows and Smart Cards
  • A user receives an "Unable to log you on because it is required that you use a smart card" message when the user tries to log on to your Windows XP-based computer by using Remote Assistance
    http://support.microsoft.com/kb/893226

  • How to access a network resource that requires username and password authentication when your user account requires a smart card for interactive logon
    http://support.microsoft.com/kb/834432

  • After you use a smart card to unlock a Windows XP-based computer, you are prompted for authentication when you access resources that require NTLM authentication
    http://support.microsoft.com/kb/939850

  • "Local Policy of This System Requires You to Logon Using a Smart Card" Message Appears When You Try to Log On to the Server
    http://support.microsoft.com/kb/832026

  • A scheduled task that is running under a specific account cannot access a shared network resource in Windows XP
    http://support.microsoft.com/kb/887572

  • Services and scheduled tasks cannot log on if a smart card is not present in Windows Server 2003
    http://support.microsoft.com/kb/889505

  • Dell Identity Management Solutions
    http://www.dell.com/downloads/global/power/ps4q06-20070155-IdentiPHI.pdf

These are some initial thoughts... more to follow...
 
Dan Kaminsky's DNS In-Bailiwick Spoofing Vulnerability Find

First off, good on Dan for finding yet another way to break DNS.  By combining previously known loopholes with a new twist, a truly lethal and rather trivial exploit has been found to attack the soft underbelly of recursive DNS servers.  More information on the find below:

Dan's Black Hat Talk (Archived)

US-CERT - Multiple DNS implementations vulnerable to cache poisoning

The Workaround:
There really isn't one.  Non-Internet facing DNS servers talking to non-recursive (authoritative) DNS servers is the closest thing you got to being anywhere near a safe situation.  In simple terms... you are screwed if you use a large ISP to connect to the Internet from home; if you are at a small company that has sharp administrators you might have a fighting chance.

The Problem:
Sure cache poisoning is bad.  However, I'm more interested in what can be done with this exploit... I mean what really can be done.  If I was going to change a DNS server entry, the last thing I would do would be direct www.Google.com to my own website saying, "PWN'T!"  If I were really evil, I would take a DNS entry for a bank and proxy the traffic through a botnet.  In other words, real-world information gathering (and subsequent use) would be my main goal.  Actually, if I were pure evil, this exploit would be used to ends having to do more with the Estonian hack than for my own purposes.  Whatever the case, these scenarios are something I think is fundamental to the problem (improper browser use, email insecurity, and shabby OS and application configuration holes so large you could drive a truck through).

The Fix:
There is a fine line between full-disclosure and stomping on a story.  Here again I would commend Dan.  He kept the problem under wraps so the fix could get organized.  In the end, the cat got out anyway (some say it was 6 months, some say 13 days).  Regardless, this exploit is fundamental to the function of DNS and any suggested fix to the problem only leads to slowing down an attack (days instead of seconds) and does not actually stop it.  To date the only true fix proposed has been DNSSEC.  If I know anything about the Internet, implementing a new protocol only takes... (cough: IPv6) forever.  Anyway, hell if I know what that DNSSEC does.  Sadly, I just know the name... and there in lies my final point.