nCircle VERT Blog: May 2010 Archives

If you happen to visit one of my favourite blogs from Google Reader, you'll come across a page that simply says 'Invalid GET Data' (e.g. Google Reader link to Is Twitter Making Us Dumb? Bloggers, Please Come Back [working link]) . That's it. It seems that Google Reader, like so many other places today, is making use of Google Analytics Campaign Tracking. This means that every link suddenly has 'utm_source', 'utm_content', 'utm_medium', and 'utm_campaign' appended to it. I find this annoying with most sites because I end up trimming the URL before I email it to people or save it as a bookmark. I find it particularly annoying when visiting Securosis because it triggers what I would call a good security measure. It makes perfect sense for a server to send you an error page when it gets unexpected GET or POST data. That would sure make websites a lot more secure... and would be an added counter measure for when people use $_REQUEST instead of $_POST. I became so annoyed that I did a quick Google search and it turns out that quite a few people complain about campaign tracking and look for plugins to manually remove the extraneous data. I don't have a lot to rant about here... just wanted to point out my current annoyance.

There's been a lot of discussion lately around Steve Jobs' Thoughts on Flash. I read it, laughed and then stopped. In reality, I can't fault Apple for not allowing Flash on the iPad, if you're going to accepted an application that is restricted in as many ways as the iPad is and not having Flash is your biggest problem, then you're having a good day. Flash, like most Adobe products these days, increases the risk to any system it's installed on, not only because Adobe doesn't seem to have grasped security but because everything you add on increases the attack surface and therefore increases the risk.

That being said, I don't really want to be involved in this discussion because both Apple and Adobe have way too many fanboys and that's just a bad place to go. I do, however, have to share something that made me laugh.

After Mr. Jobs went on and on about supporting HTML5 and embracing it as the new standard, I decided to take it for a drive on my iPad. The HTML5 Gmail interface rocked, and HTML5 Youtube was pretty nice as well but that's where the good times stopped. Next I tried to visit the APIRocks HTML5 presentation and was rather surprised when safari crashed. No messages, no pop-ups, and no additional iPad problems... simply Safari closed and I was returned to the home screen. This seems like a bit of an 'oopsie' given how strongly Apple is pushing the "HTML5 instead of Flash" argument.

Check out the video of it happening:

*Poor video quality can be the Blackberry it was recorded with.
*The 20 seconds of sitting at the end of the video can be blamed on YouTube (they don't exist in the original)

In case my posts in the past haven't made this clear, I'm going to state it one more time, I don't see a difference between stability and security bugs. I consider denial of service to be a serious security issue and I know that I'm not alone in that belief. Microsoft even includes denial of service throughout the SDL Security Bug Bar. I used to get rather upset with every browser DoS but I've since accepted that since they'll never all be fixed, there's no use getting upset. This time, however, I want to gripe and I want to gripe about the importance of Email Client Availability.

If you read the bug bar link posted above and look at the client side section, you'll note the following line, "Normal, simple user actions, like previewing mail, viewing local folders, or file shares, are not extensive user interaction." This strikes me as meaning it's something people do on a regular basis and issues in this should be considered slightly more serious than issues in other components of the same product. For today, we're going to focus on previewing mail.

Like most of the business world, nCircle uses Exchange and, by extension, Outlook. Email is, in my opinion, business critical; so when I preview an email and Outlook crashes, I take it pretty seriously. Outlook restarts (minus the preview pane) and I'm good to go but that slight inconvenience can easily become more than an inconvenience if it happens more than once, primarily if an internal application can generate emails that trigger the issue.

I came across this issue by accident, because a piece of software was generating these emails. After it happened, I started digging around and discovered that the culprit was a chunk of HTML, and to be a little more precise that "chunk" is 33 characters long. Now code execution isn't possible, so that takes the issue down a few notches in severity but in my mind it's still an issue.

My mind went "denial of service that hinders my work" and I sent an email off to MSRC. The result of that email… "This is a stability issue; it will be addressed in the next service pack." I find it completely unacceptable that something that can easily interrupt my daily work flow is brushed aside and that I'm required to wait for a service pack release.

Does my little rant have a point? Only to say that if you're going to go out of the way to define "extensive" vs "not extensive" user interaction perhaps it should apply to all issues; that way my issue would be fixed appropriately and I wouldn't have to wait around for a service pack. The days of mail bombing may be long gone, but I fear what would happen if someone decided to target all the employees at a company with this "stability issue". The constant disruption could have serious impact on a business but I guess security isn't concerned with availability.

I've seen numerous blog posts, twitter comments and emails lately about "getting into security". It seems like they've been going on for the last year. Instead of posting my thoughts, I decided to just tell my story.

Before I started high school, I knew I wanted to work in IT. Before I finished high school, I learned I'd really wanted to work in IS. There's something exciting about IS that doesn't exist with run of the mill IT work. That's not to say IT isn't important... it's what keeps us running; but security has always held my fascination. I was your average computer geek in high school; sitting on IRC and forums, reading everything I could find and pissing off my parents by installing Linux on our family desktop. By the end of high school I'd played with robotics, learned a couple new programming languages and spent 2 years playing with Cisco gear and learning networking. I'd even managed to pick up a part-time gig as the administrator of an after school computer program. College brought a new beast; more networking, operating systems and a dash of security and programming. I was building systems and selling them in my free time, and also working 40 hours a week with the student support center where I mapped network drops, wrote some python and did laptop/desktop troubleshooting. Graduation came along, and I didn't know what to do... so I took a job as an "IT Services Manager" for a small marketing company. As the company's jack-of-all-trades, I did everything from printer maintenance to web and graphic design, desktop support to network re-architecture. It was fun (for a while) but not something I sought as a career.

A friend of mine pointed out that a company in Toronto (2 hours from where I was living) was hiring for a Security Research Engineer. I took a look at the website, and applied at 3am on a sleepless Monday morning. I was shocked when I received a call asking if I could come in for an interview. I woke up the morning of the interview (I had to take the 6am bus to make the interview) and decided I wasn't going to bother… they weren't going to hire me, so what was the point. My girlfriend forced me to go, coming along (and skipping class) to make sure I actually went. Here's the fun part of the story that I ended up telling numerous times in the interview that day. The bus I was on broke down midway between home and Toronto. Worried that I wouldn't make my interview, I called a cab to the middle of the highway and took a cab to the interview (to this date, it's still the priciest cab ride I've ever had).

The interview was amazing… I'd never spoken to so many people during a single interview or met so many people at once that spoke as many acronyms as I did. Even in college, I'd never had people around me that were serious about security (or even technology) at the level I was… but as soon as I started interviewing, I knew the people at nCircle were. After the first interview came a second interview (which I almost skipped because I didn't feel my first interview had gone well) and following that interview a job offer. I was also asked when I could start and being a small town country boy, I naively said "2 weeks". It's extremely difficult to tie up loose ends at your current employer, give notice on your apartment, pack, find a new apartment and get moved-in in only 2 weeks. Yet we managed… my girlfriend and I packed up and moved to Toronto (we moved to Toronto the day before I started work… it was crazy)

Yet I'd arrived. I was doing something that I loved and wanted to be doing. That's how I got into information security. Since then I've seen my name in articles (both online and in print). I've travelled further than I'd ever been before. I've spoken to management at Fortune 500 companies and presented research to rooms full of people. That being said, it hasn't been without its ups and downs, it's definitely been a wild ride.

A couple months back I celebrated my fourth anniversary with nCircle and over the course of 4 years I've moved from 'Security Research Engineer' to 'Lead Security Research Engineer'. I've made some incredible contacts and had more fun than work should probably be. I've also gotten to take part in some pretty amazing initiatives and product launches. All in all it's been a fun four years and I'm looking forward to plenty more.

So that's it… that's how I ended up in Information Security. These people that tell you that you need 42 certifications and a masters degree to get into security are steering you the wrong way… sure it's a valid path, but it's not the only one. Proof of that happened just 8 months ago when I was presented with an opportunity to teach a 6th semester security course at the college I attended. We ended up hiring one of my students as an intern and he was with us from January until last week in that capacity. This week he started with nCircle as a full time employee and in the near future will be blogging about his experiences.

Now for the interesting part… if I'd rolled over and turned off my alarm on that day of my first interview, I'd probably be crimping network cables or rebooting a mail server right now, our newest hire would probably be on the job hunt for a network administrator job and you wouldn't be reading this blog post. Amazing what one little decision can do eh?

I'm not sure… but I think that a lot of people might be confused about what a vulnerability is. It seems to me that some people think researchers that are discovering vulnerabilities are magicians, making the vuln appear out of thin air. This is not the case, it already exists… it's waiting there for somebody to stumble across, and yes, people do stumble across bugs that have a negative impact. People also simultaneously discover the same bug. If Person A reports the bug and the vendor does nothing while Person B starts exploiting the bug then there's going to be problems. Yet if Person A publishes the bug while Person B is exploiting it, the vendor will likely respond faster and the solution will be expedited.


There's another discussion point that seems to be causing some confusion. There are people that apparently believe that releasing a vulnerability increases risk by increasing the likelihood of attack. This isn't actually the case and I'm hoping to set people straight right now, once and for all. Let's take a look at the pros and cons of publicly disclosing a vulnerability.
• Pros

1. IDS/IPS, Vulnerability Management and Content Filtering vendors can ship protections and defenses to their customers much more quickly.


2. The vendor will have to respond more quickly and issue a patch sooner.


3. Enterprises and Individuals will know that the problem exists and can take precautions to prevent it from affecting their systems. Be it policy changes, software changes or applying mitigations.


4. Attackers who may have been using the code for nefarious activities are going to see the number of days in which their attack is effective decrease as user awareness increases and mitigations are released.

• Cons

1. Attackers MAY not have known about the vulnerability, so we may be sharing information with them.

The pros far outweigh the cons, so the only possible answer is that the benefits of public disclosure far exceed doing nothing. This doesn't mean I'm advocating for full disclosure… I actually prefer responsible disclosure but only if action is being taken and the vendor is working under an acceptable time frame (say 30 days). After those 30 days, public disclosure seems perfectly reasonable to me… and based on the pros and cons, logic agrees with me.