Threes

(I reference this so often that I figured I’d better post this here)
Threes, Rev 1.1
By Elms and L. Fish

Deep in Engineering down where mortals seldom go,
A manager and customer come looking for a show,
They pass amused among us and they sign in on the log,
They’ve come to see our pony, and they’ve come to see our dog.

Three things you should be wary of: a new kid in their prime,
Someone with all the answers, and the code that runs first time.

Summoned from our cubicles to conference rooms we go;
We bring our dog and pony cause we know they want a show.
Watching as we enter with a shifty routine eye,
The customer sits waiting in his pinstripe suit and tie.

Three things never trust in there: a vendor’s final bill,
The promises your boss makes, and the customer’s good will.

The pony kicks his heels up as the doggy does his trick,
And hands are waved with vigor as we lay it on — real thick.
The customer just watches as we do this song and dance,
Then reaches for his briefcase scarcely giving us a glance.

Three things see no end: a loop with exit code gone wrong,
A semaphore untested, and the verses of this song.

From briefcase then there comes a list of things we must revise,
All before within the room are taken by surprise.
And all but four are thinking of their last job with remorse:
The customer, the manager, the doggy and the horse.

Three things hold no secret: files that somehow hit the net,
Your boss’s secretary, and the third thing — I forget…

First thirty-seven changes that somehow we must add in,
Then twenty one new features show up much to our chagrin.
And this thing’s just inadequate, and that one’s just plain wrong,
And by the way, your schedule is about three months too long.

Three things it is better for that only you should know:
How much you’re paid, the schedule pad, and what is just for show.

The customer proceeds to go through each change line by line,
Excruciating detail that no logic can define.
When it ends there’s only four not sitting there aghaw:
The customer, the manager, the pony and the dog.

Three things never anger: first the one who runs your DEC,
The one who does your backups, and the one who signs your check.

Now we here all are software types who spend ours days and nights
Embedded in the system down among the bits and bytes,
And none but us can tell full well the damage done today,
It’s for what they do not know for which they’re gonna have to pay!

Three things are most perilous: connectors that corrode, new
Unproven algorithms, and self-modifying code.

The manager and customer are quick to leave our bunch,
They take the dog and pony and they all go out for lunch,
Now how will we revenge ourselves on those who raise our ire?
Self-destructive code that goes the day the warranties expire!

 

(Taken from http://www.netfunny.com/rhf/jokes/91q3/dogpony.html)

 

Once QA, always QA.

Before I launch into my sociotechnological observations, let me define some terms, and maybe fill you in a little on my background.

QA stands for Quality Assurance1 – in this particular context, Software Quality Assurance.  Infosec is short for Information Security, the people charged with protecting us all from (for example) having our iphone data or Sony accounts posted on the web.  IT of course stands for Information Technology.  And by the way, IT is more than just being the poor bastard who gets sent out to the desk of a wonky computer: it means infrastructure and phones and usually power and AC and sometimes fire suppression. It means the care and feeding of all the computers that keep the business running, not just the computer where the boss reads email.  Currently I work as a technologist of broad scope, encompassing both IT and Infosec and pretty much everything in between. 

I was very fortunate to start my career in Quality Assurance at Broderbund Software, along with a small army of incredibly wonderful people – almost all of whom still stay in touch, decades later2.  One of those wonderful people was a lead technician, and she had a favorite quote: “Once QA, always QA.”  She was usually referring to people who used QA as a launching pad to other tech jobs – R&D, product management, IT, or such.  The context was usually “You will always think like you do in QA, no matter what job you take in life, hahaaa welcome to our brain damage” – but, as I’ve discussed with her recently, it goes somewhat beyond that.

QA people – the ones who really have the brain damage, I mean, not just the checkbox-compulsive metricmonkeys – have this weird kind of perversion in their blood, where they like to dance on the heads of systems and break them.  The idea is to make those systems stronger, of course, but chasing down the holes in the plan is where all the fun is.

(Sound familiar at all?)

Back then in QA, the first thing we’d usually do to a new product was to run it as it was intended once or twice.  This would give us a rough set of expectations as to how the program should run in general.

From there, we’d usually move into doing silly things – trying to click everywhere all at once, typing random characters3, trying to run as many instances of the program as possible, and basically just doing things that would make the poor computer shed silicon tears of bewildered frustration.  I’d say it’s a short hop from that mentality into Infosec, particularly pentesting – well, either that, or to a white jacket in a rubber room. 

Of course, I’m not saying that mentality’s limited to QA.  Anyone in Infosec – or even IT/Desktop Support – or anyone whose account has gotten compromised – has had enough times on the phishing merry-go-round at least to mouse over a URL before clicking on it.

(And you’re doing that too, right?)

What I am saying, though, is that those of us with more inquisitive backgrounds tend to think that way already. It’s a comfort as we pursue our professions, but that philosophy soon bleeds into everything else we do, especially things that don’t have anything to do with personal computing.

For example: I automatically look for video cameras wherever I am.  It’s not really about being paranoid, so much as reflexively wondering where I would place them if I were the head of security, and looking to see if there’s a camera where I would place one.  After all, I used to play small-stakes dominoes in my local bar, which had cameras covering every corner.4

Now, I certainly don’t care whether or not I am on camera, but I do want to know where the cameras are.  What does interest me is where the cameras are looking, and why.  More to my point, by thinking this way I’m not usually looking where my attention is being directed.  Sure, I’ll look once – but that’s about all, just as as QA testers we ran the program once “normally”, just to get an idea of what everyone else is intended to see.

Here’s a more digital example – about a year ago, I watched someone in our company exploit a pretty major vulnerability on an internal webpage that actually sent the employee’s ID through a CGI GET process. It was tempting to keep playing with the information we got as part of this hack, but part of being good at Infosec involves hewing to a certain level of trustworthiness, and making a good-faith effort to report vulnerabilities to the people who can actually fix them, before getting all Jack Sparrow with the digital loot we find5

How did he find the vulnerability? By reading the URL of the internal link he had to click on for one reason or another.  And I mean the complete URL, not just the first few characters that confirms that he’s going to a trusted site.  He noticed his employee ID in the URL, and basically said “Hm, I wonder what happens if I change a particular digit or two in this URL.”  And voila, he was able to verify whatever the company was asking – not just for him, but for anyone whose employee ID was similar to his.  Or he could have just found out the employee ID of anyone he wanted, given an automated script and probably a good few hours or so.6

See what magic awaits us just behind the spotlight?

That’s one of the byproducts of a QA background: we don’t just click on a link like a lemming, we might just read the damn thing first. Check to see that where it goes is where you intend. 

From there we (the QA tester, the Infosec, and me) start to branch out from just URLs, or even computers in general, and start to really look around us, almost unconsciously, and start thinking about what we see.  If we see a set of floodlights in a corner of the ceiling, we’ll probably ask ourselves what might live behind them. Is there a camera posted behind those lights? Or perhaps a small set of speakers?  After all, why waste such a perfectly lovely hiding place?

That thought process is really how I see the main connection between QA and Infosec, and – in this example – between coming from such careers and knowing where to look for the cameras, and wondering why those cameras are there.

Once QA, always QA.  The complexity of the systems and the tests may have changed dramatically over the last two decades, but the underlying philosophy really hasn’t.

And the more you look behind the curtain, the harder it gets to pretend that you haven’t.


[1] As opposed to “QnA”, meaning “Questions and Answers.”  A QA department usually has more of the former than of the latter.

[2] In fact, we just had a reunion party a few days ago, at the time of this writing. We’ve had one every few years or so, and it’s been almost fifteen years since that company got bought out.

[3]This was well before the relevance of a SQL injection – hell, it was before any Internet game that I know of besides Nethack.

[4] They knew that we were gambling for money of course; they just didn’t care. That wasn’t what the cameras were there for and that absolutely wasn’t what they were worried about.

[5] Of course he made a report right away.  And, surprise!  The report went ignored. Not even an automated rejection letter.

[6] I want to make it very clear: he did none of this.  His ethics are strong.  But he could have.
(And while I’m here, yes: he’d started his career in QA as well.)

LinkedIn: Last Name Conceal, Account-Based. Swing And A Miss.

Dear LinkedIn:

I somewhat like the idea that you block viewing last names of third-degree contacts. It makes company-mining slightly more difficult, and is a cute way to upsell your account upgrades.

Trouble is, no one seems to have told the “Viewers of this profile also viewed…” widget, which goes right on ahead and blasts out the full names of those that viewers of a profile have also viewed.

Not that I care, really.  In fact, as regards myself, I honestly couldn’t care less.  If I didn’t want people to see my full name and title, I wouldn’t have a public profile on LinkedIn. 

But, it does seem to defeat the purpose of blocking last names on the main page, when the widget – just a quick scroll down on the exact same page – totally undermines this effort. 

(PS: thanks for leaving that bug in; it really does make data mining easier ; )

 

[Note: I’d like to put in screen shots, and will if I ever get around to creating a blank LinkedIn account.]

BSides LV Memory x2

Bsides_poolside

We’re having a little … discussion … over on the BSides group list, and Erin most appropriately started us off with the lovely memories.

Mostly so I don’t have to choke the thread with a 300K JPG, and also so it’s somewhere else, I post the picture here. 

For context, here’re two of my favorite BSides memories, in this case about LV #2:


– Track #2, the “game house”, was over capacity and overheated from the jump on day one.  Jack managed to miracle a 3-ton unit literally overnight. (I’ve pulled some huge honkin’ rabbits out of my ass before, but Jack wins the prize for this.  He must have been bleeding for months.)

– Track #2, end of day one.  As speaker wrangler, I noticed the last talk of the day in that overheated and under-oxygenated room was a panel, and (IIRC) my contact for that panel was Leigh Honeywell. I went to her and started to ask, “Since y’all are a panel, do you need A/V, or can we just leave the doors open for that hour?”

I got as far as “do you…” in that sentence, and Leigh finished that sentence for me with the words “… want to run it by the pool?”

I blinked for a few seconds, and said, “Give me 15 minutes.”  Went to Vyrus and Jack, and damn if within 15 minutes Vyrus hadn’t redirected all the necessary A/V to the poolside – in particular, the beach. Jack got the video camera set up on the walkway in about that time, and off we went.

That’s what I’m talkin’ ’bout.

But a picture’s worth 1000 words, as we know, so I’ll just STFU and leave you with this.

0-Day


0-day.mp3THIS IS ALL RYAN’S FAULT.

I am now going to wash my hands.  And probably my face.  And absolutely sterilize my microphone.

(Update: described by Vyrus as “Nerdcore Justin Timberlake.”)

(Update 2: Nominated for a pwnie award at Black Hat 2011, but lost to Geohot, which proves that there is still justice in the Universe. (Congratulations, cat.))


(At Ryan’s suggestion, the lyrics):

11 am, waking up, still morning
Gotta wake up, gotta get outside

Gotta get my first Hoffacino
Wi-fi tempting, target too easy
Day growin older, sun tryinna kill me
Gotta get my ass inside
Gotta hit twitter, gotta read my friends (talk shit)

Breakin in the front door
Slipping in the back door
Gotta make my mind up
Which door should i take?

It’s 0-day 0-day
Gotta get out my 0-day
Everybody’s puttin their guard on the wrong end, wrong end
(repeat)
0-day, RSA,
Every day, brand new way
H B Ga-ry
Getting’ out my name on slashdot

12:45, information highway
Typing’ so fast, my fingers fly
Host, boast, your servers are toast
Hackin’s never done
Dualcore got this so does vyrus
These cats all be tight
My man viss, he got this
Now you pwned, bitch

(chorus)

Yesterday was no day, slow day
Today i-is 0-day, 0-day
You-you-you so stoopi’
Or under-resourced
Or maybe just a lazy bastard

Tomorrow is 1-day
Defenses come after-wards
I don’t want this 0-day to end

C-P, Vyrus double-oh-1,
Ridin with Savant 4-2 and Banasidhe
In the next whip, MCKT
Fast cracks, from the l0phtcrack,
From the Spacerogue’s time
Storms and TK and Jerm killin worms
Talkin ’bout Herman it’s Blue Boar’s turn
Jeremiah G all the time
Shout out to DC 949
And word to all my folks in this rhyme

(chorus)

 

 

Four Great Ways to Fry your Identity

This is an old post (from 3/09) on BigFix(now an IBM company)’s blog site.  I recreate it here for posterity.  And I need to write more.

————–

The paper describing the hijacking of the Torpig botnet by the fine folks at UCSB is very engaging, even if one has technical training of less than Olympic caliber. Among the topics covered are the browsing patterns of an estimated 182,000 infected hosts.

While the technical details were of great interest — in particular, the concept of Domain Flux and the infrastructure of a botnet—as an IT engineer of a growing technical company, the browsing analysis jumped right off my page. I’d like to point out four very special points the paper raised.

Since these are browsing habits of people who are already infected, chances are that if you see anything familiar, you might rethink the way you – or your community – use the web.

1. The first thing that caught my attention in sec. 6.1 was the discussion of the number of financial accounts that were stolen. That was idly interesting, but the last sentence woke me up:

“38% of the credentials stolen by Torpig were obtained by the password manager of browsers, rather than by intercepting an actual login session.”

I can’t tell you how many times I’ve shoulder-surfed people “logging in” to data-sensitive sites with a single click. These metrics on its risk are sobering.

Personally, I have no use for a browser’s password manager, but if you do: think seriously about how much you do, or don’t, want be one of those 38%.

(In passing, I do have to admire the botnet’s approach on this topic: kind of the digital equivalent of hitting it with a wrench.)

2. In section 6.4, we are reminded again of the importance of having a good password policy:

“Our analysis found that almost 28% of the victims reused their credentials for accessing 368,501 web sites.”

There are ways to make a gaggle of passwords different, easy to remember, and yet not require a password manager. I would love to get into some ideas on how to do that, and welcome the discussion it would generate … but perhaps another time.

To paraphrase one of the popular metaphors in the paper’s conclusion: people understand the concepts of the security of a car but don’t bother to apply those same concepts to their computing environment.

Fundamentally, would you leave your car, house, and work keys all on the hood of your car every time you parked it? That’s the effective risk incurred by reusing passwords among such sites through a browser’s password manager. The only real difference is that not to see the risk usually means not to think about it*.

3. Section 6.5 of the paper glances at the infected computers themselves, and discusses the zeitgeist of peoples’ actual browsing activity. The highest single observable interest of Torpig-infected users is to seek jobs and submit resumes, at 14%.

Sure, in today’s economy, a pile of those are probably home users. But if I were to somehow sniff any company’s web traffic on any given day, I would fully expect to see non-manager-initiated job board HTTP requests. What I mean to say is that just because it’s a work computer doesn’t mean it’s inherently safe. Yes, it’s presumably being protected by the IT staff, but no security measures are foolproof, and they haven’t been since the first rooster crowed at the dawn of civilization.

4. Finally, the paper noted that:

“… online security is a concern of the infected population (almost 10% of [infected emails] mention phishing, viruses, and spyware), but only a few people seem to suspect that they are using an infected machine.”

Torpig in particular builds sophisticated phishing pages for common banks, eBay, and PayPal sites that are very devoted to passing surface authenticity tests (sane URLs, valid SSL certs, etc.), so it isn’t too surprising that once infected, the users would only have dug the machine deeper into the disease.

Still, standard rules apply – in a nutshell, if you think something’s suspicious, it probably is. Specifically, if you log in to a site that immediately asks for your bank account number or social security number – look to your computer’s health, it might well be running a temperature.

The constant war between security and convenience rages on like the climax of a John Woo movie. No one wants to go through all the work they need to in order to keep a secure and sane computing environment. I can’t blame them—I didn’t used to lock my car until after it got looted a few times**.

Managing risk is something that can’t be done only by your CI/SO, just like managing corporate costs can’t be done only by the CFO. At some point, on some level, everyone has to be involved.

You can park your car with the windows down with the keys in the ignition***, or you can take the keys and roll up your windows. You can keep using the same password that you’ve had for years, (your firstborn’s name, your favorite candy, what have you), and use that for everything you do online, or you can devise some memorable means of switching up your passwords that is unique to every site yet meaningful only to you, so you can wean off the training wheels of a browser’s password manager.

After all, it’s easier to replace your car than your identity.

Notes

*cf. “turn up the radio when the engine starts to make funny noises” and other such metaphors by Tim Keanini
** Yes, I’m a slow learner.
***Or, if you live in the San Francisco Bay Area, you can leave your laptop visible in the back seat of a locked car.