Dan Griffin's Blog

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

A new article and sample code set is now posted to MSDN as part of my Windows Vista Security series.  Check out “Building Plug-ins for Network Access Protection” at http://msdn2.microsoft.com/en-us/library/bb945062.aspx

Highlights:  the article provides a detailed walkthrough of how a Statement of Health is generated by the client (“System Health Agent”) code and evaluated by the server code (“System Health Validator,” running on Windows Server 2008 via its Network Policy Server role).  It also shows the code flow for auto-remediation (programmatically fixing a client that’s deemed un-healthy, and then letting it connect to the protected network resource).

The code shows a generic Registry SHA/SHV.  In other words, you can configure it to enforce NAP policy on an arbitrary registry key, or keys!

Any questions – find me at TechEd Developers in Barcelona next week (or just email me – that works too …).

 

Permalink | Comments (0)

Yes, there are some legitimate concerns about Vista being too hard to deploy.  It’s a memory hog in its default configuration, there were way too many driver compatibility problems at RTM, and the company did a terrible job of explaining controversial features like UAC. 

In light of those factors, it’s a good thing that customers have been slow to upgrade. 
But – Vista is likely the most secure general-purpose OS available.  And by the time SP1 is available, the issues above are either going to be moot or at least sufficiently well understood. 
And, per the WSJ link below, people haven’t stopped buying new PCs.  Nor are they switching away from Windows.

So, to all of the IHVs, ISVs, partners, and developers in the Windows ecosystem who have been taking a “wait-and-see” approach to Vista – you’re about to be caught with your pants down. 

Links:

Wall Street Journal, front page today - http://online.wsj.com/article/SB119264686055062256.html?mod=todays_us_nonsub_page_one Mary Jo Foley’s blog (is it just me, or is she way more pro-Microsoft than she used to be?  Kind of freaks me out …) - http://blogs.zdnet.com/microsoft/?p=873

 

 

 

Permalink | Comments (1)

A few updates in response to questions I received at my ToorCon 9 “Hacking Vista Security” talk this past Sunday:  first, the code links to all of the projects (that is, the Crypto, Firewall, and IPsec tools I showed) are all just that – code.  They’re self-extracting archives, not pre-built versions of the tools themselves. 

Second, I don’t yet have a link to the video of my ToorCon presentation, and I haven’t decided yet whether to post my slide deck.  In the meantime, however, you can get even more detail from the new demonstration videos that I’ve posted for each of the three projects.  Each video is around 5 – 8 minutes and shows how to build the tool in question, how to run it, and some of the interesting pieces of the code. 

All three code downloads include a ReadMe.html file, which I recommend checking out before trying to build the tools, since the instructions in the videos are still pretty terse.  The latter require Flash and JavaScript (no, I don’t really like having those technologies enabled either – sorry). 

Anyway, here’s a list of all of the links:  

Crypto Tool

Video = http://jwsecure.com/Videos/CNG_Demo2/CNG_Demo2.html

Article = http://blogs.msdn.com/onoj/archive/2007/05/10/windows-vista-security-series-adding-a-cipher-algorithm-to-windows-vista.aspx

Code = http://download.microsoft.com/download/f/1/2/f12dbbb5-d164-4e7c-b42d-aaca3efb85dc/CNGSample.EXE

Firewall Tool

Video = http://jwsecure.com/Videos/FW_Demo/FW_Demo.html

Article = http://blogs.msdn.com/onoj/archive/2007/05/09/windows-vista-security-series-programming-the-windows-vista-firewall.aspx

Code = http://download.microsoft.com/download/f/1/2/f12dbbb5-d164-4e7c-b42d-aaca3efb85dc/FirewallSample.exe 

IPsec Tool

Video = http://jwsecure.com/Videos/IPsec_Demo/IPsec_Demo.html

Code = http://download.microsoft.com/download/f/1/2/f12dbbb5-d164-4e7c-b42d-aaca3efb85dc/IPsecPingSample.EXE

 

 

Permalink | Comments (1)

ToorCon is just awesome

October 22, 2007

Just got back from ToorCon 9 in San Diego (as a side note – downtown SD already smelled like smoke when I left the hotel early this morning – freaky).  That city’s present brush fire woes aside, the Con’ was just fantastic – by far the best I’ve ever attended.

Interestingly, some of the people I met this weekend said their favorite Con had been the Seattle Beta (http://seattle.toorcon.org) earlier in the year.  While I attended – and presented at – that one, I enjoyed San Diego a lot more because I had numerous chances to party with new folks.  I guess my take is this – if you crave radically cutting-edge hacker info from a broad spectrum of topics, all while sitting in a cool bar downtown, the Seattle one rocked.  But if you wanted to take advantage of a full weekend of hard core networking with the top haxors, San Diego could not be beat.

Most surreal conversation I had this weekend – seeing a certain well-known hard core haxor, who shall remain unnamed, boot up his Vista laptop and proceed to discuss with me how brilliant Microsoft’s BlueHat (http://www.microsoft.com/technet/security/bluehat/default.mspx) Security Briefings series is.  I must agree!

 

Permalink | Comments (0)

I recently received some welcome/solicited feedback on my MSDN magazine fuzzing article (http://msdn.microsoft.com/msdnmag/issues/07/11/FUZZTesting). This is from Charlie Miller, who gave an in-depth fuzzing seminar at ToorCon this past Friday:

"So in the MS word file fuzzer example, you describe creating random files to parse. If you do this, I guarantee that 100% of them will fail to open, as they will not contain any structure of a word file. You should describe the mutation based fuzzing I described, i.e. start with a valid file and make some random changes to it."

The blurb for Charlie’s talk is here - http://www.toorcon.org/2007/event.php?id=60.

Thanks!

Permalink | Comments (0)
I enjoyed Rodney Thayer’s ToorCon crypto seminar yesterday.  (Current link is here - http://www.toorcon.org/2007/event.php?id=21.  As I understand it, video of the talks will all be online shortly.)

He hammered home one point which I agree with in principal:  don’t implement your own crypto.  However, from a practical standpoint, that’s misleading.  The message should be:  don’t implement your own protocols. 

What do I mean by that?  Suppose I’m designing a new authentication scheme and I naively choose DES as my encryption algorithm.  As a result, an attacker could conceivably sniff my traffic and brute-force the key.  But suppose further that, in designing my authentication protocol, I forgot to guard against replay attacks (which have nothing to do with my choice of crypto algorithm).  Now, instead of brute-forcing the key, the attacker can simply resend the packets to achieve a successful authentication.  The latter attack is way easier.

The weakest link in the security of a given security system is almost never the choice of crypto algorithm, but rather some other overlooked detail.  The benefit of using existing systems (PGP, Kerberos, TLS, IPsec, etc) is not that they’re flawless, or even that they always use the strongest crypto (neither is true), but rather that all those other details have been reviewed by experts over an extended period of time.
Permalink | Comments (0)
Ever used Outlook Web Access?  There’s a Security radio button control at the bottom of the logon screen that provides two options:  “Public or shared computer” which is selected by default, and “Private computer.”

 

 

Selecting the latter brings up some red bold text warning you, basically, that you better be sure that your client computer is secure from your employer’s perspective.  But that is so misleading.  I mean, suppose I leave the “Public …” one selected and just login to my email that way.  Since I don’t get the security warning, does that mean it doesn’t matter if my client machine is running spyware?  Or that it’s got a key logger?

 

 

Don’t be fooled – if you login to OWA from a public computer or kiosk, assume that your password is compromised (by a key logger) and that some hacker is reading your email (via spyware or an ActiveX control).  The “Public or shared computer” setting doesn’t protect you!

 

Permalink | Comments (0)
Interesting article in the Seattle Post-Intelligencer yesterday regarding Microsoft’s Unified Messaging plans - http://seattlepi.nwsource.com/business/335701_msft17.html.  However, some of the UM systems that I’ve seen raise questions about the ability for users to contact emergency personnel in critical situations.
 

The article talks about integrating phone features with the PC, and using the latter to control the former.  I’ve heard rumors, though, about systems that require you to be logged into your PC in order to use the desk phone.  The question this raises in my mind is, what if I’m visiting a customer site and they’ve deployed such a system.  I’m walking down the hallway and I encounter a situation that requires the police or an ambulance.  I reach for an office phone and … I’m stuck because I don’t have a password?

All UM systems should allow ‘unauthenticated’ emergency calls to be routed directly to the outside.

 

 

Permalink | Comments (0)

New Fuzz Testing Article

October 12, 2007

I’m ecstatic (yes, that’s really the only way to describe it) that my third feature article is in this month’s MSDN magazine - http://msdn.microsoft.com/msdnmag/issues/07/11/FUZZTesting/default.aspx.  Why?  Well, for one thing, getting anything published is a huge privilege, but especially in a publication like that.  For another thing, MSDN’s yearly security issue always rocks, and this one is no exception.  And – I received some excellent feedback on this article while writing it, and so it’s better than I could have accomplished otherwise, and that’s cool.  Finally, the topic is timely.

The topic is extending Visual Studio Team Edition for Testers to perform security fuzz testing.  I show how to write a Test Interface Provider and demonstrate one approach to “fuzzing”. 

Relevant links:

Other peoples’ definition of fuzzing - http://en.wikipedia.org/wiki/Fuzz_testing

Permalink | Comments (0)

Another good security blog that I’ve belatedly discovered - http://www.unmitigatedrisk.com.  Ryan’s a bit of a digital media fan as well, which I respect …

 

Permalink | Comments (0)
Newer Posts »