Erick Rudiak. Songwriter. Singer. Human.

Can they still call it that?

Sat, 30 Jan 2010 23:26:00 -0500

The first thing I noticed when I walked into the Safari Cup open mic was that there was no mic. I must have looked like a deer caught in the headlights of a Hummer H3 SUV because Jim, the host, came over and welcomed me in. I emailed him that morning asking about the venue, and he'd saved me a spot on the list. That was, in retrospect, pretty typical of the Safari Cup experience.

There's a lot to like about this open mic, and it begins with the absence of a mic. Having paid my dues at many a pub (Bird's Nest) and packed-to-the-gills coffee house (Kafein, Uncommon Ground), the chance to really connect with the audience and see how my songs do on a fair playing field — i.e. not competing for attention with a violent break of a billiards match, Rob Thomas and Santana on the juke box in the next room, or a hive of overstimulated social butterflies — is a welcome change. Nowadays, it's actually what I consider ideal; I think back to all the performing situations I've been in, and the ones where there's no mic (or stage) to insulate the artist's and audience's spaces from each other have been the most fun, be it someone's living room, the basement at Old Town School, or Yosemite.

While public rehearsal can be good for its own sake, the opportunity to connect with an audience is really the #1 ROI differentiator for an open mic. In Safari Cup's case, the folks I've met have been extremely gracious and have listened and interacted with literally every performer that I've seen come through, even the one who was probably looking for the pub next door, and another unforgettable patron who had an unhealthy scatological obsession that was coupled with an equally unfortunate outlet in song (yes, he handed out CDs when he was done). Getting to hear Andi C's R&B-over-acoustic-guitar covers is a treat, too; NWA and Beyonce never sounded so sweet.

I definitely plan to be back to Safari Cup. Until then, here's the story-behind-the-story of Terminal Love, as performed at Safari Cup on 27 January, 2010. Since there's no mic, you will notice that I pro-rated my 'facing the audience' time in any given radial direction based on how many people were sitting there. That night, they were mostly to my right... except for Nate M. (who was outstanding by the way), who was to my left for all but the briefest of moments.

P.S. This blog post was made possible by HandBrake and mp4box. Who knew a digicam that small could generate a file that large!

one stone, many birds

Tue, 19 Jan 2010 00:27:49 -0500

In addition to making up for a ridiculous gap between posts, and ringing in the new year with a new photo gallery feature, this post should also serve the additional purpose of knocking post #50 off the front page, which means no more funny errors for Internet Explorer users (thanks, TG, for the pro bono website QA).

Things I learned at Camp Marmot this year.

Sat, 1 Aug 2009 09:06:00 -0400

Another year, another great camping trip with Ian, Zotzie, and the SYMG High Sierra Songwriters Adventure crew. Stuff I learned:

The full story of Smokey Joe
That Fred Van Vactor is even better than I remembered
Marmots prefer Gibsons
Testosterone can be used sweetly in a song (Listen)

I'd claim to have learned that the Ansel Adams Wilderness is beautiful, but I already knew that!
| | | | |

Here are two of the other songs that were born on the mountain:

Elspeth Veronica MP3
I Don't Watch The News MP3

Story time on 7/30

Sun, 19 Jul 2009 21:39:30 -0400

Raining Gravel MP3 Metahpor MP3
I'm getting ready to head out to Yosemite again. In past years, those trips have yielded some great songs - Raining Gravel, Metaphor, and a half dozen others. They've also yielded plenty of great stories. Martin was written after Steve Poltz suggested there might be reason to be jealous of my guitar as it was being passed from camper to camper for fondling and plucking. I'm looking forward to having some more great songs, and stories to accompany them, to premiere at Brothers K on Thursday, July 30th. Show starts at 7:00 PM. Steve will be there too, and will surely tell a few tales. Odds are at least one will outdo the three-parter that was captured at his Halifax show in '07. See part of it here (where Steve explains how writing You Were Meant For Me influenced television), or follow the youtube link to all three as a playlist.

YWMFM 1-3.

Ray Davies: early HIPS user?

Thu, 16 Jul 2009 23:12:20 -0400

The Kinks: Tired of Waiting For You

I continue to have a love/hate relationship with Host-based Intrusion Prevention System (HIPS) technology. On the love side, I have a bias towards any security system that remediates new risks without installing new code. In order of preference, optimal vulnerability management ought to start with doing nothing because you're already invulnerable, reconfiguring what you have to be protected, and finally -- a last resort -- installing some sort of software patch. HIPS, in theory, allows you to hit the "do nothing" sweet spot for vulnerability management by gracefully handling the outcome of an attack (overflowing a buffer, for example) rather than trying to identify all possible variations of the attack itself. The latter has proven incredibly difficult over the years.

On the hate part, there's the waiting: while HIPS makes grand promises of zero-effort protection against zero-day threats, there is an unfortunate and unpleasant waiting game involved. To illustrate, let's look at the latest out-of-cycle (7/13/09) warning from Microsoft: "code execution is remote and may not require any user intervention." Visit the wrong web page with the wrong browser, presto, you're a statistic. Sounds pretty bad. If I'm going down my decision tree of (1) do nothing, (2) reconfigure, or (3) patch, I'd love to know right then, on 7/13/09, if I can stop at step (1) because my HIPS suite is protecting me. Is it? Let's check....

As of this writing, it has been a little over 72 hours since this particular vulnerability became public. Depending on my organization's vulnerability management policy, I may have had to make a decision by now on whether or not I need to take invasive action to protect my enterprise. It may turn out, after a few more days, that my HIPS suite had me covered all along. The link above gets updated periodically with the latest protection data. To my chagrin, I'm finding lately that the decision-enabling information that allows me to choose not to take invasive action to counteract a vulnerability is either absent or confirmed too late to help. HIPS: love it in principle, still waiting for the big payoff in practice.

Web application security étude.

Mon, 13 Jul 2009 01:02:00 -0400

A few weeks back, jullrich posted "My Top 6 Honeytokens" to his web application security blog. I began thinking about how his suggestions could be implemented in mod_security -- not just because I have some weird caveman-ish wiring that leads me to think about technical solutions to other people's problems, but because governance is often a lot more effective if you can speak the language of the governed. In my case, the governed include our intrepid information technology group, the folks who run our web servers and whom I task with defending our systems against attack.

After enabling mod_security and mod_unique_id on my test server, and reading up on prior art (especially this blog post by Ryan Barnett), here is the Apache configuration (httpd.conf, etc.) I wound up creating:

# honeytoken suggestions from https://blogs.sans.org/appsecstreetfighter/2009/06/04/my-top-6-honeytokens/
# the following rules should inherit SecDefaultAction from above

# 2. Add fake admin pages to robots.txt
SecRule REQUEST_FILENAME "^/secretadmin" \
"phase:3,id:10000002,t:none,setenv:modsec_honey=true,pass,log,auditlog,msg:'Honeypot: set cookie for fake robots.txt entry',setsid:%{ENV.UNIQUE_ID},setvar:session.score=+10"

# Fortunately, since I'm writing this for a blog post, I can put blog comments inside httpd.conf comments. More after the jump...# 3. Add fake admin cookies
SecRule REQUEST_COOKIES:SiteAdmin "!^$" \
"phase:3,id:10000003,t:none,setenv:modsec_honey=true,pass,log,auditlog,msg:'Honeypot: set cookie for fake admin cookie',setsid:%{ENV.UNIQUE_ID},setvar:session.score=+10"
# 5. Add fake hidden passwords in HTML elements \
SecRule ARGS "^234kwj$" \
"phase:3,id:10000005,t:none,setenv:modsec_honey=true,pass,log,auditlog,msg:'Honeypot: set cookie for fake hidden password',setsid:%{ENV.UNIQUE_ID},setvar:session.score=+10"
# 6. "Hidden" form fields
SecRule ARGS:BackDoorDoNotUse "!Do_Not_Use" \
"phase:3,id:10000006,t:none,setenv:modsec_honey=true,pass,log,auditlog,msg:'Honeypot: set cookie for fake hidden field',setsid:%{ENV.UNIQUE_ID},setvar:session.score=+10"

# 4. Add "spider" loops
RewriteEngine On
RewriteRule /secretadmin/[0-9]+ /secretadmin.php [L]

# honeytoken work block: Header looks for modsec_honey env and sends cookie;
# SecRule looks for return cookie, blocks subsequent requests
Header set Set-Cookie "ESESSIONID=%{UNIQUE_ID}e; path=/;" env=modsec_honey
SecRule REQUEST_COOKIES:ESESSIONID !^$ \
"phase:3,t:none,deny,log,auditlog,msg:'Honeypot cookie found'"

The spider loop for #4 proved to be a tougher challenge. My initial foray, in php, looked like this:

Administration Form.

User:
Pass:

While I was able to trick Paros and Burp into getting past the rewritten URL, it didn't yield the infinte loop I'd hoped to induce. At first I thought perhaps a more expensive tool would do better, but looking at the logs confirmed that the spidering feature was working as expected (loading up unique pages as it found them), as was the form (generating unique URLs after /secretadmin/).... as was mod_security, which was picking up on the presence of the ESESSIONID cookie it had previously created and denying the scanner, which was dutifully sending back the cookie it had previously received.

Looking back at the overall process, I had briefly considered using mod_rewrite for this entire exercise but ultimately decide mod_security was the better tool for this task, primarily because of the ease of getting into POST name/value pairs in mod_security; it can be done in mod_rewrite but requires far more code-level gymnastics (i.e. reading POST parameters and using them to fake a GET with the same values). I also toyed with the idea of a negative security model, as suggested in mod_security's documentation for the SESSION collection, but ultimately decided that it was both less predictable in terms of behavior and less scalable, since I had yet to see mod_security's session store shared between load-balanced server instances. Load-balanced servers were also one reason why I ultimately used a cookie to trigger the deny rule, rather than the individual signatures themselves: once set, cookies will be present for all requests coming from the attacker irrespective of what happened in the network to route the request to its final fulfillment host. That is, unless the attacker goes out of their way to ignore or reset my ESESSIONID cookie. Since the intent of this exercise was to detect attacker behavior (mod_security would, of course, have to be configured separately to protect any actual, vulnerable applications I might have been running), evasion turned out to be less of a concern this time.

All in all, a fun little diversion back to my caveman roots, an étude of sorts. Perhaps most of all, a reminder to appreciate the complex world the governed have to navigate every day.

Marcus Ranum may not have built my hotrod, but he did help me buy my sedan

Thu, 9 Jul 2009 07:15:40 -0400

When I was first getting started in network security (back in the late '90s), I attended a SANS conference where Marcus Ranum spoke about firewalls. Of all the things he talked about that day, the one that made the most lasting impression wasn't about firewalls themselves but about finding interesting events in your logs. He called it "artificial ignorance": since you don't know in advance what an interesting event might look like, by eliminating uninteresting log items (known false positives, informational entries about benign events, etc.), you inherently highlight the interesting ones as a result. This eventually informed the basic design I used in writing a security event management solution for our network perimeter devices (it was cool for 2000, albeit thoroughly needing retirement by 2004).

Fast forward to this spring, when I began looking to replace my '99 built-from-jets sedan with something a bit newer. I could quickly tell from checking the dealer ads on craigslist and cross-referencing them against carfax that there were going to be few, if any, good deals available: anything that was being sold close to Kelly Blue Book value -- and especially below -- was previously in a collision or otherwise had a troubled, potentially haunted history. That's where an ounce of artificial ignorance (and a kilo of Yahoo Pipes) came in handy.

I wound up creating a pipe that took craigslist search results as input and eliminated all ads matching regular expressions that were likely to be dealer ads. Were it a command-line regex, it would have looked something like this:

visit our website|internet sales|stock (\#|number)

I eventually added a couple of other search terms that matched the dealer names that were most consistently posting the models I was interested in, tested and re-tested, and eventually wound up with a pipe I was happy with. Several days later, I had my new-to-me sedan. Now my biggest problem, besides the car having a manual transmission and my commute being in Chicago, is that I am no longer driving any car mentioned in I Will Rule Your World. I'll have to update the live version for the next show (7/30 with Steve Poltz).

Blockbuster summer tour announced

Tue, 9 Jun 2009 22:19:21 -0400

Like U2, The Eagles, and the Jonas Brothers, I'm looking forward to spending my summer seeing America. Check below to see if I'm coming to your town and, if I am, get tickets, FAST!

July 22 Bass Lake, CA 8:00 PM
July 23 Yosemite, CA 8:00 PM
July 24 Yosemite, CA 8:00 PM
July 25 Yosemite, CA 8:00 PM
July 30 Evanston, IL 7:00 PM

Tickets for July 22-25 are $1395 and worth every penny. July 30 is a pay-what-you-think-it's-worth show with Steve Poltz at Brothers K Cofee in Evanston. Steve and I will be fresh from a weekend of songwriting, communing with nature, and taste-testing different kinds of rainbows. It'll be the first time either of us plays our new songs at sea level. In other words, it'll be good times.

It worked for Darwin

Thu, 9 Apr 2009 07:38:00 -0400

I often introduce Good In Bed by telling the story that inspired it: the ex-girlfriend who literally wrote out a pros/cons list to determine the fate of our relationship. The cons won, though I'll maintain some mystery by leaving the details of what carefully-chosen words were in each column for my live show and not for Google's cache. Things worked out for the best for each of us, and I hope she will be buoyed to learn, as I did today, that the same method was used by none other than Charles Darwin, albeit arriving ultimately at a different conclusion.

On lightning strikes.

Sat, 13 Sep 2008 07:09:00 -0400

Last week, Microsoft announced some changes to its monthly patch notification mechanism. What caught my eye the most was this:

In addition, as part of the company's ongoing effort to improve its guidance for customers, Microsoft announced its new Exploitability Index. Developed based on customer feedback, the Exploitability Index will provide customers with guidance on the likelihood of functional exploits being developed for vulnerabilities addressed by Microsoft security updates. This additional information helps customers better assess their unique risks and better prioritize deployment of the monthly security update.

I certainly commend Microsoft (and Oracle) for taking the bull by the horns with their approach to vulnerability patching. It's a difficult problem to tackle and the element of predictability they have brought to the table helps their customers. Delivering an "exploitability index" is another story, on the other hand.

It's attempting to answer an interesting and difficult question: "will this happen to me?" To make the example more real, let's ask "will lightning strike me?" To answer this question, we can look at some data that can shed real light on the question. The National Weather Service tracks lightning strikes. You can look at a map of the US and immediately tell what the likelihood of being struck by lightning is for your location; if you dig deeper, you can figure it out for time of year, trends in strike density, etc.

map from lightningsafety.noaa.gov

This data is considered reliable because it uses verifiable historical and geological information about the threat (lightning). Information security, unfortunately, does not conform to the same rules. While Microsoft certainly can make predictions about exploitability of an issue based on their undisputed expert knowledge on the subject, we simply don't have the luxury of looking back on years (or centuries) of data to support those assertions. This is not to knock Microsoft; it's simply that the threat changes so rapidly:

It's not the same threat every time: buffer overflows in Windows Metafile Format this month, insufficient randomness in DNS query sequence numbers the next, etc.;
"Unknown unknowns": the customer wants to know "will lightning strike me, here and now ?" and to answer that, Microsoft has to understand a staggering number of combinations of software (always), hardware (sometimes), and other mitigating controls (occasionally firewalls, device configurations, etc.); just recently, MS08-037 was revised several times after its initial publication in early July as more details about the interaction of the exploit and the fix itself became known; (updated 12 Sep 2008) the September 2008 bulletin was updated four days after release "to add Microsoft Office Project 2002 Service Pack 2, all Office Viewer software for Microsoft Office 2003, and all Office Viewer software for 2007 Microsoft Office System as Affected Software."
Exploitability inevitably changes over time. It only takes one lucky attacker to take a vulnerability from theoretical exploit to weaponized worm. ASLR protection in Windows Vista has been considered a great mitigating control against a variety of overflow attacks, yet at Blackhat 2008, a paper was presented showing how ASLR can be bypassed -- this fundamentally changes the "likelihood of exploitation" equation for an entire class of vulnerabilities, both past and future;
For most vulnerabilities, the fact that there's a patch pretty much guarantees that someone has (or is working on) an exploit. Microsoft says it themselves:

Along with the predictability of Microsoft's monthly security update process is the emergence of an undesirable cycle: the release of exploit code, related to those updates, sometimes within hours of release.

As a customer trying to decide whether or not to patch every month, I continue to applaud Microsoft's efforts to give me decision-enabling information. Alas, the Exploitability Index is a piece of trivia isn't tipping the scales on the decision for me. If I'm at the ol' swimming hole and I see a thunderstorm approaching, I'm going to get out of the water -- not so much because I've been reading the lightning strike density maps for my neck of the woods, but because I know that -if- I get struck, it's going to hurt. Similarly, as I decide whether or not to patch a given vulnerability immediately, I'm going to make that decision on the same factor: if when an exploit for that vulnerability is released, I want to know which data it's going to hit and how hard. I want to know how much it's going to hurt.

Stay tuned next week when I wax rhapsodic on "The Firestone tire recall of 2000 and why I don't care how long that SQL injection issue has been around."