Skip navigation

I posted a link to Twitter earlier on a recent discovery of the ability to clone RSA SecurID soft tokens:

https://twitter.com/hrbrmstr/status/204908233645764609

It (rightfully so) received some critical responses by @wh1t3rabbit & @wikidsystems since, apart from what the hypesters may say, this is a low-risk weakness.

Think about it. Just looking at the two most likely threat actors & actions: an insider trying to siphon off soft tokens and an external attacker using crafted malware to grab soft tokens. The former (most likely) knows your organization is using soft tokens (and probably has one herself). The latter is unlikely to just try to blanket siphon off soft tokens so they’ll have to do some research to target an organization (which costs time/money).

Once a victim (or set of victims) is identified, the cloning steps would have to be perfectly executed (and, I’m not convinced that’s a given). Let’s say that this is a given, though. Now both the insider and external agent have access to the bits to clone a token. It is easier for the insider to get that data, but the external attacker has to exfiltrate successfully it somehow (more complexity/time/cost).

To be useful, the attacker needs the user id, PIN and – in most implementations – a password. An insider would (most likely) know the user id (since she probably has one herself) but that data would require more time/effort/cost to the external attacker (think opportunistic keylogger/screenscraper with successful exfiltration). For both attackers, getting the password requires either social engineering or the use of a keylogger. Even then, there’s a time-limit of 90 days or less (since, if you’re using soft tokens, you probably have a 90 day password policy). That shrinks the amount of time the attack can be successful.

Now, both attackers need to know where this soft token can be used and have direct access to those systems. Again, probably easier for an insider and fairly costly for an external attacker.

Looking at this, there’s definitely a greater risk associated with an insider from this weakness than there is from an external party (as pointed out by the aforementioned twitter commentators). As @wikidsystems further pointed out, this also shows the inherent positives of multi-factor authentication :: you need far more component parts to execute a successful attack, making the whole thing very costly to obtain. Security economics FTW!

My comment has been that if using the TPM store for Windows-based SecurID soft token implementations negates this weakness, then why not do it? Does the added deployment & management complexity really cost that much?

In the end, I would categorize this weakness as a low risk to most organizations using soft tokens with a non-TPM storage configuration. Unless you know you’re a nation-state target (my opine for the origin of the attacker) – and, even then, you’re probably using hard tokens – far too many celestial bodies need to align for this weakness to be exploited successfully.

NOTE: This post was not meant to be a comprehensive risk assessment of the weakness and does not cover all attack scenarios. I left out many, including Windows desktop administrators and privileged script access. I was merely trying to do my part to counter whatever hype ensues from this weakness. Comments on those vectors or the analysis in general are most welcome.

I recently finished watching “Japan: Memoirs of a Secret Empire” [ Netflix | PBS | Amazon ]. It’s a three-part documentary that centers around the 16th & 17th centuries (where a vast majority of my favorite samurai movies are set).

In the third part there is a segment on the four-tier class system. It goes into some detail on how the decline of the samurai (due to a time of significant peace) and the increase in trade facilitated the erosion of societal taboos that previously prevented classes from mingling. Apart from the creation of a new merchant-inspired class and an increase in the frequenting of courtesans there was also the mention of “haiku clubs” where (quoting from the documentary) “members chose pen names to obscure their social rank. That way, the classes could mingle freely“.

In a similar way, Twitter (and many forums before it) is the great equalizer with the added similarity of brevity (and often a gravity well for some modern day haiku fanatics). I don’t have any statistics, but I do wonder if Twitter is having a more equalizing impact on societies where class and overt discrimination are still wildly prevalent (think India or Saudi Arabia).

as avatars tweet
modern words become equal
history repeats

I’ve been wanting to post this entry for a while, but I didn’t have the opportunity to compel an extra pair of hands to assist with some necessary, salient portions of it until tonight.

For those who were hoping Mountain Lion’s AirPlay would be a revolutionary step in the “your content, wherever you want it” battle, I fear you may be in for a bit of a disappointment. Quite by accident, I stumbled upon some eerie signs that location-aware video DRM will be alive and well as an integrated part of Apple’s forthcoming release of Mountain Lion.

Since I have a shiny, new 1080p Apple TV and a device capable of running Mountain Lion, I’ve been experimenting with the awesomeness that is AirPlay. Despite claims to the contrary, most of the time routing MacBook Pro Desktop video & system audio to the tiny black box of happiness works flawlessly (even more so since the recent Apple TV update). It’s been a treat to be able to play owned-backup copies of my favorite samurai videos (I should buy stock in Criterion) with subtitles via VLC.

However, on a lark I tried to play one of my Avengers : Earth’s Mightiest Heroes episodes (we subscribe via iTunes) using QuickTime Player and, much to my chagrin, discovered that there lies within the heart of the tame Mountain Lion, a DRM beast.

The easiest way to show this is with what happens when I try to take a fullscreen snapshot with Skitch as I’m playing the DRM-laden episode:

I managed to get #3 to help me record a video (albeit crappy) of what happens when I try to route the Desktop video to the living room TV via AirPlay: (youtube link)

In case it’s not obvious, the video plays fine on the Desktop (in QuickTime) prior to the AirPlay route, but goes equally as blank when the AirPlay device is chosen, yet reverts to playing when AirPlay is disabled.

This means the API hooks are there to prevent DRM-laden content from being used with AirPlay (or snapped via screen capture) and that, in turn, means your hopes of AirPlaying Hulu, Netflix and Amazon Video content may be dashed despite all of those services working now (in the betas).

Video is the last content area to understand the need to be open. Amazon & Apple sell untainted music and even Tor is going DRM free (joining #spiffy folks like O’Reilly Media).

I own that episode of The Avengers yet am not able to do with it as I please. Yes, I could have streamed it over the Internet from iCloud to the Apple TV or even routed it via the local iTunes to the Apple TV, but I wanted to use QuickTime (though, just for a test). What’s to stop Apple or other companies from requiring a special streaming license if you want the ability to use AirPlay or just disabling it altogether in favor of forcing you to use something as horrific as Google TV (full disclosure, I own a Logitech Google TV box, too)?

Combine these restrictions with the inevitable “you will only be able to use Apple-authorized apps in Mac OS” in a post-Mountain Lion release and your hopes of using VLC (or any other player that will not conform to draconian rules) to bypass this silliness will be equally as dashed as your naive AirPlay ones. If there’s no guarantee you’ll be able to get your content to the screen of your choice, why would you choose to remain legal (moral arguments notwithstanding)?

I hope, in the long run, Apple manages to figure out an sane, amenable solution to this silliness. In the meantime, I’m going to pop in a DVD and crank through some Godzilla flicks. At least I can be fairly certain that should work for quite a while longer.

Street sign photo via jbonnain

I didn’t read through the Massachusetts 2011 Report on Data Breach Notifications [PDF] until recently, but once I went through the report my brain kept telling me “something is wrong”. Not something earth shattering, but more of a “something is off” signal. This happens more than I’d like as I tend to constantly background process what I intake visually.

As Twitter followers may lament, I have been known to transcribe useful tabular information from reports such as these, especially when I need to communicate them internally and I have done so with this report [gdocs] as well.

After working through the whole document, the last page of data is where I found the “off by one” error (see figure below). Someone performed “head math” vs copying & formatting from a spreadsheet. Never a good idea if you aren’t going to double-check the report thoroughly.

 

Off By One

My transcription (“Lost Stolen Misplaced” tab in the aforelinked workbook) assumes the “5” and “48” are correct and has the correct total (“53”). One of the problems when an error like this crops up is that you do not know where the error occurred, but since the sums of “12” and “277” are both correct in the spreadsheet and in the report, I think I’ve found the culprit. Unfortunately, a computational error such as this does foster suspicion on the accuracy of the rest of the report data.

It’s a lesson report writers should heed well: compute twice, publish once. Errant data can cut as deeply as a saw blade.

While I Have Your Attention

Since there aren’t many visualizations in  Massachusetts 2011 Report on Data Breach Notifications (3D numbers do not count), here are a few I made that I found helpful during my interpretation (2011 data unless otherwise specified):

# Residents Impacted By Breah Org

Number Of Breached By Org

Number of Breaches by Type 2008-2011

Residents Impacted By Breach Type

Lost/Stolen/Misplaced

Malicious/Non-Malicious

 

 

While the slides will be officially available from SIRA web site in the not-too-distant future—complete with video (for all the talks)—I figured it wouldn’t hurt to put them up here as well.

My sincere thanks, again, to @jayjacobs and the SIRA board for allowing me to have the privilege of being the first speaker at the first ever SIRA conference. If you didn’t go, you really missed some of the best thinking and content I’ve heard in this space. Every talk had useful, takeaways and the in-talk and hallway-exchanges were nothing short of amazing.

Mark your calendars for next year!

UPDATE: Fixed link to cached Obama image thx to notice from JB

While the two front-running candidates engaged in a bizarre, Klingon-esque ritual of hubris regarding which one was the better killer, their respective technical campaign staffers were failing to make the grade on security when it comes to taking your donations.

Earlier this week, I mentioned the most excellent Qualys SSL Certificate Tester and thought it would be interesting to try it on the two front-running US Presidential candidates online donation forms, especially since both candidates are focusing on how much they want to protect the American public.

Let’s just say that the results aren’t stellar, but they are better than I expected.

You can view the results directly from the SSL Labs site by hitting the following links:

While I’m not exactly hopeful either staff will end up fixing the SSL configurations, in the event they do, here are image-cached results of the scans I ran on Saturday, May 5, 2012:

But, you don’t want links, you want results, so here’s the top-level summary comparison:

Mitt Romney

Barack Obama

So, both candidates earn a “C” with Obama’s team scoring 10 total points higher than Romney, but let’s look at the details (only comparing the “bad” categories):

Candidate SSL Configuration Comparison

Romney
Obama
Issuer
USERTrust Legacy
Secure Server CA
Go Daddy Secure
Certification Authority
Supports Insecure SSL 2.0
Number Of Weak Cipher Suites
7
3
Vulnerable to the BEAST
Weak Ephemeral DH
Chart made with CompareNinja

While it’s somewhat ironic that Romney is vulnerable to the BEAST, both candidates show their true cipher weakness. Ultimately, though, I have to agree with the numerical results (Obama coming out the least bad of the two) if not solely based on Romney supporting insecure SSL 2.0 connections.

Given that the Trustworty Internet Movement‘s SSL Pulse Report made tech headlines just recently and that both the scan and the fixes take about 10 minutes to complete, these results are just, plain sad.

Hopefully no one decided to donate to either candidate while sipping their quad grande no-whip mocha macchiatos at Starbucks.

If you went to SOURCE Boston this year (2012), attended my security awareness talk and liked the Angry Birds theme to the slides, here’s a copy of the Keynote theme (it’s not really a true Keynote theme as there are divergent slides I’ve included). Here’s a sample:

You’re going to need the “Feast of Flesh BB” font (local source) by Blambot Comic Fonts & Lettering if you want to keep consistent with the Angry Birds lettering on various slides.

You can also grab my talk slides at the conference site or from my local archive.

BTW: In the event you’re also looking for a shortcut method of making some of the font-effects in the slides, I strongly suggest using some of the font manipulation tools in Microsoft Word if you don’t have more expensive tools like Adobe Acrobat kicking around. You can do some really cool things in Word, save as PDF, crop in Preview and import into Keynote or Photoshop with great results.

UPDATE: I forgot to include the MP3 of the theme song which I played as part of a transition from “blah” slides to the Angry Birds title slide. (Original files over at the Angry Birds Nest).

Just a quick post as I noticed that my nginx configuration was vulnerable to the BEAST attack thanks to the #spiffy SSL Certificate Tester from Qualys (I scored an “A”, btw :-).

The nginx docs show how to do this, now, and it’s pretty simple (very similar to the Apache configuration, in fact):

  1. ssl_ciphers RC4:HIGH:!aNULL:!MD5;
  2. ssl_prefer_server_ciphers on;

Set it to prefer RC4 ciphers and — BOOM! — you’re done.

Like many other system admins, I should have done this a long time ago. And, like many other system admins, I’ve got many other things going on. I let this slip (even though I’ve kept up on nginx patches) and I shouldn’t have. Thankfully, this was a low risk item as the site doesn’t perform truly critical transactions.

I definitely encourage folks to use the SSL Labs tool to help ensure you’ve got your site’s configuration up to snuff.

Also, make sure to follow @ivanristic on Twitter if you care at all about web app security.