Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

Exploit Marketplace

September 30, 2007

I recently learned about this interesting company – WabiSabiLabi, http://www.wslabi.com – which provides an online marketplace for zero-day software exploits.  The company claims to offer anonymity to both buyers and sellers (researchers), and to ensure that the efforts of the latter are rewarded by market-based pricing.  And they’re hiring!

 

Permalink | Comments (0)

Hotel door lock override

September 21, 2007

I recently made a vacation trip to the southwestern United States, and stayed in a nice resort.  As is common in combination villa/hotel lodging located in warm climates, all doors were exterior facing.  And the resort made no attempt at securing the grounds – anyone could walk right up to my door from either the beach or the street.  Hence, being a paranoid guy, I got to thinking about the physical security of that door.

Now, in addition to a mag stripe reader for the room key, virtually every hotel door I’ve stayed behind during business trips in the past 10 years has offered both a deadbolt and a chain (or similar manual catch attached to the jamb).  And I’ll immediately stipulate that a dedicated/determined attempt to compromise any such door, including by physical force, is bound to succeed.

However, what first caught my attention about the exterior doors at the resort this past weekend was that they didn’t have one of those little security chains.  But then I thought, “that’s okay, it’s got a deadbolt.”  With that set, I’m at least guaranteed privacy while in the room, right?

No – silly me.  My first clue was when I tried to open the door (from the outside) with my mag stripe key after the deadbolt had been set (from the inside).  I noticed that the click made by the lock is different in that situation, and thus realized that the key reader and deadbolt are electronically connected.  And then the inevitable conclusion that there’s only one good reason for them to be connected – the deadbolt can be electronically overridden from the outside! 

I don’t know why that never occurred to me before, and in retrospect I shouldn’t be surprised.  And yet – having an exterior facing hotel door on unsecured grounds that is impossible to truly lock from the inside is kind of creepy.  I mean, the override card is probably just sitting in the manager’s desk drawer, right?

Anyway, based on some very brief internet research, this feature is called “Emergency Card” support in the industry.  Here’s an example of a commercial lock product spec that references this - http://www.tycosafetyproducts-europe.com/English/Products/Access/hotellocking.asp.  And here’s another one that mentions it slightly more obliquely - http://www.kaba.co.uk/products/e760-hotel-lock.asp.

 

 

Permalink | Comments (0)

I’ve recently been provisioning a new dev machine.  While searching for the download point for the CNG (Crypto API: Next Generation) SDK, I stumbled upon some new CNG-related sample code offered by Microsoft separately from the SDK.  The new sample can be downloaded here - http://www.microsoft.com/downloads/details.aspx?familyid=34C59FA0-E265-4E44-9A3B-9370EECDC5A9&displaylang=en.  Here’s what I found:

1.       By default, the sample CAB wants to install itself to the user profile.  While that’s nice from a UAC point of view, I figured I’d rather stick that code in place I’m more likely to be able to find it later.  So I installed it under c:\Program Files\Microsoft CNG Development Kit\DemoCode.
2.       Open the CNGLibrary.sln file and Build.
3.       In Solution Explorer in Visual Studio 2005, right-click on CNGTestApp and select Set as StartUp Project
4.       Press F5 to start debugging

I was surprised to discover that the sample includes a managed (C#) WinForm!  The form consists  of four primary controls:  an Input edit box, a Hash Type multi-select, an Output edit box, and a Generate Hash button.  The overall purpose of the sample is apparently to demonstrate the use of PInvoke to exercise the CNG hashing routines from managed code. 


Cool – but then again, the .NET Framework already supports all of the SHA-2 algorithms natively, so exposing a more complex CNG scenario via PInvoke would have been preferable.  Like how about ECDH (Elliptic Curve Diffie-Hellman) key agreement?  Anyway – there it is.

Permalink | Comments (0)

New Smart Card Whitepaper

September 11, 2007

This whitepaper describes the overall support of smart cards in Windows Vista and goes into quite a bit of technical detail - http://www.microsoft.com/downloads/details.aspx?FamilyID=ac201438-3317-44d3-9638-07625fe397b9&displaylang=en.

Recommended reading if you work with smart cards or strong authentication on Windows.

Permalink | Comments (0)

Blog - Facebook Security

September 9, 2007

Been doing some research lately into this interesting social networking experiment called "Facebook". Maybe you’ve heard of it …?

Somewhat seriously, I think I’ve been remiss by not becoming more familiar with sites such as facebook and myspace, primarily because they raise tons of privacy and security questions. Questions on those topics are already being publicly debated, which is a good thing.

However, regarding facebook specifically, one topic that doesn’t seem to be getting much attention is security from an integration and software development perspective. Third party applications are proliferating like nobody’s business! Each such app - and they integrate tightly with facebook - is likely to have a different privacy and usage model, and each is granted access to a great deal of user information which is then stored … somewhere.

On one hand, it’s all well and good for technically savvy people to say that net users shouldn’t put any information online that they don’t consider to be public. And that, therefore, if that data happens to be stolen from some data center, no big deal since it’s public anyway, right? But I’ll wager that the majority of online users either don’t think that way, or at least don’t consider what the aggregate of all readily availble information about them could imply. I mean, if a bad guy can get a database of all of the shared data for 10,000 facebook users, wouldn’t that be a convenient springboard for him to launch other attacks - phishing, indentity theft?

Links for current dialog on this subject:

* When users first join facebook, they are prompted for the their email account passwords. Facebook will then login to the user’s email account and upload all of their contacts. This happens by default! Awesome. See http://elronsviewfromtheedge.wordpress.com/2007/04/13/the-modern-facebook-of-security/.

* JavaScript holes that have reportedly been patched - http://ajaxian.com/archives/facebook-javascript-and-security.* This looks like such an urban legend, but here’s a story about a student who’s facebook data came back to bite him during a job interview -

http://www.lsus.edu/career/announcements_details.asp?ID=43.

* Facebook recently leaked some PHP source code, although references to it appear to have been removed from all domestic web sites on account of legal DMCA notices. That apparently doesn’t work outside of the good old US of A, though - http://fenikss.yeahost.com/?p=61.

* Facebook recently exposed supposedly private user inboxes - http://www.theregister.co.uk/2007/07/31/facebook/.

Permalink | Comments (0)

You know what would be cool? In my Windows server / Active Directory environment, I’d like to have a network encryption policy button on the Domain Controller that says "Just Do It". The result of pressing the "Just Do It" button would be that a best-effort IPsec policy would get pushed out to every compatible machine in the domain.

For mixed environments, it wouldn’t even need to require IPsec: just make an attempt to negotiate encryption, and if that fails, fall back to plaintext. Yes that would be susceptible to man-in-the-middle attacks, but the primary purpose of this solution wouldn’t be a bullet-proof network. The purpose would instead be - find the greatest common denominator (encryption-wise) between peers while still maintaining compatibility. Create a log when the negotiation is unsuccessful. And allow me to fine-tune and gradually lock the policy down based on that information.

Wouldn’t that be cool?

Permalink | Comments (0)