Somebody had to be the one to write the first post on our new nCircle VERT weblog.

at least for today. figure i'd post my own "me too hey it's just a test is this thing on" message.

Next week, I'll be in San Francisco at RSA - I'll be blogging some of the highlites of the show, including our event with Gartner and our cocktail reception.

We're also going to have an OVAL Board get-together at some point - should be interesting to meet a lot of those people in person, especially now that we're kicking off the development of the unauthenticated side of the OVAL schema.

I was talking to a reporter yesterday about RSA - he said that he had never seen so many security companies contacting him about a show before. It's interesting to see the growth in this industry. I think it's mostly due to the fact that security is a relatively big buzzword these days - there are a million people peddaling all sorts of interesting security solutions. And there's a lot of snake-oil out there, too.

It's great to be at a company that actually has satisfied customers and a product that genuinely makes people smarter about their security - we're not perfect, but I'm sure that there are going to be products we see at RSA that don't actually make life easier for the security departments out there.

I'll blog more from RSA next week - I'm sure there's going to be lots of good, bad and ugly out there.

I just finished reading Michael Bauer's new post on the O'Reilly Network entitled "Fear and Loathing in Information Security". And I found myself shaking my head.

As long as I've been in information security, I've listened to people in the community complain about the misappropriation of the word "hacker" by the mainstream to mean "criminal". We tried to get them to call the criminals "crackers". We whined. We complained. We protested. We like the word and we wanted everyone else to like it too.

But it's 2005. And Mr. Bauer is just plain wrong.

To put it very simply: there are two very distinct understandings of the word "hacker". One of those is understood by our peers in the infosec and software community - it's a compliment about the way someone approaches ingenious problems. If someone in that community calls me a hacker, I take it as a compliment.

The other meaning of "hacker" is the one understood in the mainstream - my mom's (and probably your mom's) definition of the word. In that world, a hacker is a person who breaks into things. The public doesn't view "hacker" as a term implying skill - only a term implying a pest who breaks into their computers and steals their information. And, the people talked about in the speech he was quoting were exactly those types of peopele - we'd call them script kiddies or some equally derogatory term. And my mom (and probably your mom) would call them "hackers".

That isn't going to change. It's time to get over it.

We can feel free to use the word as we see fit amongst ourselves - it's jargon for our community. However, the rest of the world won't ever change to use the word that way.

And we can revel in that fact - we have a word that the rest of the world doesn't need to understand. It's something that means a different thing to our peers than to outsiders of our little club. It differentiates the person who got their CISSP as a checkbox on their resume and studied only from "CISSPs for Dummies" from the person who got it because they felt like reading the Rainbow series and academic papers on crypto and decided that it was a convenient reason to do so.

We also have to learn to use the word in appropriate senses at the appropriate time. Or when to use it and when not to.

Of course, Mr. Bauer doesn't need to address these issues - he's writing on the O'Reilly Network. They understand that meaning of the word.

One can be incredibly self-righteous when he knows that he's preaching to the choir.

For the perfect illustration of my last post, read the comment trail on Mr. Bauer's post.

Seems that there were some non-choir members in the audience after all. ;)

strolled around the vendor exhibits at rsa today. all i can say is, what a bunch of snake oil.

ZDNet today posted this article about the newly designed vulnerability scoring system that Qualys is announcing at RSA today. I found one line particularly interesting:

"[The system] is designed to provide the first systematic grading of flaws that can be used by companies to assess damage to their vulnerable systems and to prioritize patching.

Well, not quite the first. We've been doing that with nCircle's scoring system for over 5 years. With exactly the same criteria for evaluation. I imagine that they've made some changes - it'll be interesting to see what they've done and if they've run into some of the same flaws as our early versions. I'll post more on that once I've read the paper describing the metric.

I think that this is an excellent thing for the industry - there's no doubt that all of the products need to have a granular metric to assist their customers. Our customers see the benefits of the system on a daily basis - it's good that others in the industry are finally catching up to that view of the world.

It's one that we've had for 5 years now.

Our own Mike Murray gets quoted again, this time, its a new MyDoom worm. Putting the mechanics of the worm aside, how many times do we tell people "don't open attachments"? This worm and a few previous have preyed on the user's eagerness to open email from what they think is their friendly tech support team. The question of the day is "when are we going to make non-repudiation part of the norm?" Reading email is second nature, but obviously something about email lures us into assuming the From field is always accurate. Technology, like MTV, has tricked us. We buy P Diddy clothes at 10,000 times the markup and continue our failure to adopt non-repudiation into our every day lives.

NIAC presented their previously described new vulnerability scoring system at RSA today. I wasn't in the room myself, but have heard a couple of first-hand accounts so far - also, I had seen one of the earlier NIAC drafts.

The scoring system definitely has a couple of good points - they made the good choice of differentiating authenticated and un-authenticated vulnerabilities as well as the acknowledgement of different attack vectors as a key point of severity. They also made many of the same choices we made 5 years ago: being aware of the complexity of the attack as an important factor, being aware of depth of access as the fundamental component of risk, and so on.

However, I believe that they made a fundamental error when it comes to the temporal component of their metric: they forgot the audience. The temporal component of the new scoring system works to reduce the score from day #1 until day #n - that is, the vulnerability gets less severe as time marches forward.

This is true in a very global sense: as the enterprises patch vulnerabilities, they become less severe. Thus, the vulnerability (from a global perspective) becomes less wide-spread.

However, this metric isn't designed to talk about the global severity of the vulnerability - it's designed to assist end-users in their decisions on how to patch. Because of this, the thinking above is absolutely backwards.

While a vulnerability may be globally less severe with time because the number of instances grows fewer, the number of available tools and exploit vectors continues to grow (albeit at a slower rate) with each additional day that the vulnerability is publically accessible. This should be obvious to anyone who has ever done a penetration test: the brand new Solaris vulnerability is less likely to have an exploit than the 4-year old Solaris RPC vulnerability. I always loved it when I found a box that was unpatched to older exploits - it made my life easier.

Just like it makes the life of any attacker easier.

This metric (much as our scoring system) is designed to prioritize patching - as I see it, the vulnerabilities that make it easier for an attacker to compromise YOUR network are the ones that have the highest priority, regardless of their global significance.

That will always be the oldest, best known ones.

Because of that, the new CVSS (Common Vulnerability Scoring System) is doomed to fail to actually do what it's supposed to do best - allow customers to protect their networks from attackers.

On Tue, 8 Feb 2005, Dave Aitel wrote:

This is a quick announcement that the recent Microsoft patch (MS-05- has fixed a vulnerability I found a while back in SMB. [excerpted from http://lists.virus.org/dailydave-0502/msg00031.html]

Very convenient how these guys are like 'oh yeah we found that years ago but didn't do anything with it'. Seems to me they like holding on to their shit so they can talk themselves up and look cool, which isn't in keeping with an honourable way to carry one's self, if you ask me.

When I was younger I read, and subsequently became a huge fan of, Steven Levy's book 'Hackers'. I'm sure most people (of a hackish nature) are familar with the book and with the 'Hacker Ethic' that it takes care to promulgate. I thought it was a noble and beautiful creation. To wit, an excerpt from the the Hacker Ethic as listed in the book:

Access to computers -- and anything which might teach you something about how the world works -- should be unlimited and total. Always yield to the Hands-On Imperative! Hackers believe that essential lessons can be learned about the systems -- about the world -- from taking things apart, seeing how they work, and using this knowledge to create new and even more interesting things. They resent any person, physical barrier, or law that tries to keep them from doing this.... Rules which prevent you from taking matters like that into your own hands are too ridiculous to even consider abiding by.... All information should be free. [From Hackers: Heroes of the Computer Revolution by Stephen Levy. Anchor Press / Doubleday. New York, 1984.]

I recognize the need for trade secrets, and that the quality of our life is dependent on the ability to do business and aquire commodities that address our needs as human beings. But there has to be a middle ground and an honourable way to do it. I am aware of the hypocrisy in my own life; I don't live up to the hacker ethic all the time either.

Maybe he didn't want to share the information 'cos he had concerns someone would take it and claim it was theirs. So what? Let it all hang out man - karma will take care of the rest.

so, about maybe 2 months ago, one of my teeth become incredibly sensitive to hot and cold. it was awful. i'd grab a cold bottle of water, take a big drink of it and then i'd feel like someone was drilling into my jaw. horrible.

over the course of the last two months, it went from hot/cold sensitivity, to occasional pain, to pain whenever i touched it with my tongue, to just plain constant pain. so i had to call the dentist yesterday morning, have them take a look. because, as you probably know, mouth pain sucks.

it was my upper right side wisdom tooth. both of my wisdom teeth on the left side were removed in the early 90's by an oral surgery student at the university of the pacific dental school. it cost me only $400 for 2 local-only extractions. lots of cracking and bleeding later, i was less two painfully impacted molars. i never did get around to having the others removed. that is, until yesterday.

lucky for me, the dentist could see me immediately. when i got there they took some x-rays using some new tech i'd never seen before. it was a usb x-ray thing they stuck in my mouth which made me gag. x-rays always make me gag, but this one took the cake. good for me it was fast.

turns out the dentist also does rudimentary extractions right there in his office, and after seeing the x-rays, decided he could do it himself. so, much cracking and pinching later, my problematic wisdom tooth was out.

so what was causing all that pain? that particular tooth, on the side facing the tooth in front of it, had a giant cavity in it. a cavity so big it went down to the inside of the tooth. it was frightening. it was filled with unidentifiable organic matter. it was disgusting. glad it's gone.

so what, you ask, does this have to do with security? well, i'll tell you...

just because you can't see it from the outside, or can't get to it, doesn't mean it can't hurt you. badly. patch your boxes. no matter where they are. otherwise, you are going to be in a world of hurt when someone manages to stuff a couple hundred kbytes of kernel rootkit into that cavity and then twists it around a few hundred times. heh.

over the last 20 years, a lot has changed in information security: encryption technology is better and more widely deployed; trust models are being developed and deployed in various ways; system security is, for the most part, no longer on the honor system; various authentication technologies intended to improve on password based authentication are becoming more popular, bringing along their own slew of issues. biometrics, once the bailiwick of pulp sci-fi authors, are now widely deployed at businesses and government agencies all over the world. the romanticized image of "hacking" -- late night sessions basking in the green glow of a vt100 terminal connected at 300bps to your favorite underground bbs -- is all but dead. the security industry has gone mainstream, and with it have come a raft of technical solutions to technical problems. while a lot has changed, we still have a long way to go.

technical solutions for technical problems are wholly appropriate. technical solutions to social problems, however, aren't necessarily the best solution. one of the hardest things for IT groups is managing the impact of security on the primary business goals of the organization. security is important, but how much are you willing to impact your business in order to achieve an acceptable level of security? that's a hard question to answer because it involves not only implementing technical solutions, but also changing the behavior of users.

so, the question i pose is: how can we address the social issues involved in infosec? soylent green is made from people, and more often than not, so are many security issues that arise in enterprise environments.

So, I've finally spent some real time reading the NIAC CVSS report and I genuinely believe that they made a mistake with the temporal metric.

What's worse is that they should know that they made a mistake. From the report itself:

"As a vulnerability ages, certain intrinsic characteristics will change with time. In many cases, when first discovered, a set of vulnerable systems will be at or close to its peak, while the availability of exploit and remedial information will be at its lowest point. As time progresses, patch information will become more available and more systems will be fixed as more exploits occur, driving the need for the fix. Eventually, the set of vulnerable systems will reach its low point as remedial information reaches its high point."

In other words, the vulnerability is most wide-spread at day 0, and is most severe for a given system at day n (where n >> 0).

This suggests to me that there are two useful metrics for talking about the vulnerability's severity:

• When talking about the vulnerability's Global Severity (i.e. impact to all systems), the vulnerability is most severe in its early days.


• When talking about the vulnerability's Local Severity (i.e. impact on a single host), the vulnerability grows continuously more severe as time goes forward.

The CVSS team realized that. Unfortunately, the products using CVSS are going to be rating Local Severity more often than Global Severity - Qualys, Symantec, etc.

This leaves them in a problem spot, because the way that CVSS handles the temporal metric suggests that it is concerned only with Global Severity - it starts at its highest point, and reduces the severity over time. From the paper again: "the temporal metrics serve only to reduce the base score by a maximum of 25%."

Unfortunately, the product space and the authors of the paper aren't taking this into account. It's going to end up doing a great dis-service to the security of the products and their customers. They'll spend their time patching the least-likely to be exploited vulnerabilities while the oldest, most exploitable vulnerabilities will continuously have their scores reduced.

It's an attacker's dream. They won't find any 0-days, but Unicode, Sadmind and the Slammer vuln are going to be less likely to be patched based on the recommendation of tools using this new scoring system.

It seems like a small issue on the surface, but it's going to cause huge repercussions over the long term and ultimately make us all less secure than we should be.

Anybody who has lived in the security industry for a while has read articles like this one. I have to say that I'm somewhat fatiuged by it.

Before I rant a bit, I'll issue a caveat: I'm the first to argue that the majority of people don't take security seriously enough. It's the first thing to go on most budgets, and if it weren't for regulatory compliance issues, it'd be the easiest thing in the world to dismiss with the "it won't happen to me" excuse.

But it's time to have the conversation as though people are intelligent.

The thing that bothered me the most was this line:

"Trust is nearly gone for email", Perry declared. I suspect it is gone completely.

The author then goes on to show that only 1-3% of email is legitimate, and suggests (by implication) that email faces a slow death.

I hate to say it this way, but that is ridiculous. Email isn't going away because of spam and viruses any more than snail mail went away because of junk ads and mail-bombs.

The key is to solve the business problem around it, not to make it go away. Email is here to stay. And no amount of FUD like "EMAIL IS DEAD!!! SPAM KILLED THE EMAIL STAR!" will change that fact.

I understand that it makes good business sense for the speaker (VP at Trend Micro) to spread this - his business is around sanitizing email from threats. But the real question around spam and viruses is about business - specifically, how much time and money are you spending to combat the problem?

It's really a time/space problem (as TK likes to say): how much time/resource are you wasting because of the threat. If you can then counteract it at a cost less than that, it's sensible.

Example: I get a pile of spam (100-200/day). However, my mail filters are good enough that I only see about 10/day. The cost is so insignificant that I simply delete those 10 (or add them to my mail filters) manually. I don't go out and search for a product to handle them, because it's such a small resource requirement.

I certainly don't stop using email because of it. Nor will I ever.

Read an interesting link from the linking integrity blog this morning about a Canadian CEO who has proclaimed that security is about brand protection (which should justify your security spend).

The whole article is here and uses Choicepoint as the example of why security breaches are about brand protection. The CEO (Mary Kirwin of Headfry) then makes the leap that, if security is about branding, it can't be about technology.

Talk about a muddle.

First, let me say that she's right. Not in the way that she thinks that she is, but she's right: security is not about technology. But it's sure as hell not about branding, either.

Security is about business.

Let me say that again.

Security is about business.

Sure, protecting and enhancing your brand is part of doing business. But it's not the whole thing.

Security processes are designed to add value to your business processes. If they don't, you're wasting your money. The rest of the article succeeds in making that argument - however, all of the quotes are narrowly focused. The other people are talking about metrics - it's all small picture stuff.

We need to start looking at Security as a value add to the business proposition - not as "technology", or "metrics", and sure as heck not as "brand protection". Sure, it provides all of those things, but security is really about enhancing the way that you do business.

Laurent Bossavit was talking about risk on his blog.

He arrives at a final definition of:

"Risk consists of future consequences, arising from present causes or foreseeable events, which - if they materalize - will exceed our normal capacities for coping."

This actually forsees an interesting point: there are actually two ways to avoid risk.

The first is to avoid or transfer the future consequences. This is the standard plan - either attempt to manage the risk, or transfer it to another party (e.g. buy insurance).

Bossavit hits on an interesting ability, however, which is tightly coupled to the comments I made recently on this blog: risk can be averted by increasing your ability to cope. That is, by creating more value.

This is where one can look at security processes as a value creation engine. If the process of securing your business process can also implement process efficiency enhancement at the same time as it actually is used for loss prevention, you will create a situation whereby value is added at the same time.

In this way, you're not only avoiding loss, you're also enhancing the value of your process at the same time - you're creating a situation by which your ability to cope with future loss is enhanced by a better utilization of your current resources.

A little while ago I read an article entitled “A long winding road out of beta”. Initially after reading the article I began to wonder what happened to the logic behind a beta release. Originally, it was a period of testing that was performed before a piece of software was released to work out any final bugs. What has changed between then and now? Are users getting used to unstable software? From a personal perspective, it has been disheartening to watch the general public come to accept “rebooting” a computer as a solution to a problem. To me, that is equivalent to buying a new bedroom set because the dresser handle has a loose screw.

As frustrating as it is, this general decrease in software quality also creates opportunities. As people get used to crappy software, a company with a quality product that is competitively priced stands to win huge Market share. This winning product may (and probably will) have fewer features than its competition. As long as it does what it was intended to do reliably, consistently and correctly, people will begin to see just how bad some of the other offerings are and switch.

I then pondered on what causes such a lack of quality. The short list of answers I came up with is: Lack of pride in a product, lack of peer-review, human error and compressed timelines. The list can grow indefinitely, but those were some of the major ones that stuck out to me.

How does one combat these confounding factors? For a lack of pride in a product, one must have people who have a personal stake in their work. By this, I don’t mean giving bonus’ based on achievements, I am referring to people that work for the enjoyment of the work itself and not the pay cheque that accompanies it. Happy employees do good work. Lack of peer review can be resolved by having people work cohesively in groups. The kind of group that sits in a room together actively discussing all aspects of their daily work, not one that meets a few times a week to give status updates to each other. Human error? Automation I say. Automate those tasks which do not require thought. Computers are good at doing. People are good at thinking. Lastly, compression of timelines must be defeated in the scoping stage. Every project has a momentum life-cycle. It is built slowly at the beginning, constantly increasing until a peak is reached and then rapidly decays. If a project is properly scoped, this peak happens about ¾ of the way through, which leaves time for final tweaking and wind down before project completion.

In the end, it all comes down to that “good” feeling you get when you complete a project. If it isn’t present, odds are, the final product is really a beta.

How do you develop a safer web browser?

1. stay on top of newly discovered vulnerabilities
2. maintain an open disclosure policy and well organized bug tracking system
3. notify end users of updates
4. make updates transparent and painless

Mozilla Firefox fails on step 4.

Vulnerable users are more likely to update their software when the process is automated and easy. Every complicated dialogue box that you present a user reduces the likelihood that they will complete the update.

Internet Explorer can be updated (cumulatively no less) in an average download of 600K and usually one reboot. In contrast Firefox displays a helpful little red arrow in the corner of your browser window until you update. Once the user clicks on this subtle little icon, they begin the long process of downloading the update. Once that step completes they are greeted with the fact they downloaded a whole new copy of their browser and now have to reinstall the whole thing. This gets a little tricky on multi-user systems, not to mention the novice users whole get freaked out when presented with file system install paths. As a final little insult, Firefox leaves its installation executable lying on your desktop.

Firefox's awkward update process is going to leave a large number of people running vulnerable copies of Firefox 1.0

Mozilla should reward its loyal fan base with an upgrade procedure they can brag about instead of having to make excuses for. The Mozilla development team places an admirable amount of effort on security, now they just need to start delivering it to the people they are trying to protect.

Earlier this week, I went back to my alma mater to give a talk about buffer overflows. Michigan Tech is a unique school located in an abandoned mining town called Houghton in the otherwise untouched wilderness of Michigan's upper peninsula. The nearest city is Minneapolis -- an unreasonable 7 hour 41 minute drive away. The rest is nothing but small towns, abandoned mines, and snow.. lots of snow.. With 300 - 400 inches of snow a year, some days it felt like planet Hoth. At the Minneapolis airport, I recalled the isolation of the region while boarding a 30 seat propeller plane -- the only way to fly into the tiny airport near Houghton.

I was picked up from the airport by a senior who also knew first hand about the region's harsh climate. "Why the hell did you come back here?", he joked with me. While the solitude of the back country does have its certain charm, I distinctly remembered just wanting to get the hell out of there by the time I was a senior. Why the hell did I come back here?

Well, there is some history that makes this too funny to pass up. Eight years ago, when I was a sophomore I used to play around with the world-writable utmps and mess with people using flawed Xauth implementations. Soon one of the lab admins challenged me to get root on the main CS file server. It was easy to find a publicly known buffer overflow vulnerability in one of the many suidroot binaries on that system. After figuring out the proper offsets, I show the exploit to the lab admin. "Holy shit!", he exclaimed at the sight of the root shell prompt. "That's a big problem", he continued, "Someone should fix it." I agreed with him, so I e-mailed the necessary patches to the system admin along with an explanation of how I got root -- only to get my account shutdown the next day for violating the school's computer use policy. The lab admin who challenged me was only a student and the policy is the policy. I was threatened with expulsion and put on probation. The administration made it clear that if anything else happened, I would be out of there. I focused on my course work, did what they told me, and got my degree in the end. There were some good teachers there and I did feel a strange connection with this odd college in the middle of nowhere. But yeah.. a big reason was just the irony of giving a talk about buffer overflows at the same school I was reprimanded for the exact same issue.

it seems that in recent years, nay, the last decade, there has been a tendency for vulnerabilities and policy violations to be lumped together. is having an insecure password, running non-encrypted services such as telnet, or writeable directories via ftpd more of a vulnerability than a violation of policy, or of bad policy?

all of these things, while able to be potentially leveraged to compromise a system, can easily be addressed by applying best practices. wouldn't it be better to call these types of scenarios out in the policy arena?

comments, thoughts, etc.

Kurt Godel, a logician, mathematician and philosopher of mathematics had many interesting things to say. For the purposes of this discussion I am going to restrict myself to one particular theorem of his. This theorem is his second incompleteness theorem which states:

No consistent system can be used to prove its own consistency.

It is important to note that the theorem truly and properly applies only to the field of mathematics. I am, however, going to abuse this notion because I think within it is a held a truth much larger than originally intended. Like Heisenberg's uncertainty principle (and alot of quantum physics) there are, to me, profound philosophic insights. Loosely and sanely applied I think they may have use outside of their original fields.

There has been alot of talk lately about vulnerabilities and security. To me the central point made is that problems still exist which have existed for a very long time. The evolution of human capability and thought should have long ago eliminated these problems.

I am not sure that is the case, nor am I certain that it is possible or even desireable.

If we look at the human body we can see an entity that is very imperfect. But this remarkable imperfection is capable of the greatest acts and accomplishments. We damage ourselves all the time, yet we heal. Despite the impurities we consume or the cuts and scrapes we receive we heal, often becoming stronger and wiser. Organic life is the ultimate fault tolerant system. We are the greatest RAID system ever implemented.

How much effort must we divert to try and make things perfect? At some point we will be putting in far more effort than is worth the results we achieve. We will become too focused on fixing problems before they happen, reducing the resources available to remediating the situation. I would say we are approaching that point now. Would it not be better to accept the inherent imperfection of the universe and instead strive to make our environment and our tools fault tolerant? As long as humans create machines the machines will be imperfect - and so will their products. Our software will be imperfect. As history bears out countless times, our security will be imperfect. This is all as it should be. In fact, I suspect this is the only way it can be.

I am not saying that we should abandon attempts to be secure. What I am saying is that we will never be secure - there is no way for us to prove that we are. You are most vulnerable when you think you are most secure. Just because you have a product, a system, or a methodology and it appears to provide accurate results consistent with your perception of a secure state does not mean that state is useful. Or accurate. To paraphrase the second incompleteness theorem, your secure systems cannot prove their own security. And in much the same vein, I am not sure that a system of accuracy can prove that it itself is accurate. The problem may very well prove intractable.

We cannot eliminate our true weaknesses, only manage them. Much like vulnerabilities.

In January of this year, nCircle hired a pair of co-op students, something we had never done before. Our experience was so positive that we were motivated to expand the program very aggressively; this semester, we will be hiring eight students altogether. Four of these students will be reporting directly to me, which means that my own private department has suddenly expanded into a regiment. Some ignoble wag dubbed it the "Army of Gauth"; naturally, the name has stuck.

As Technical Librarian, I was an information ronin, a (nearly) masterless samurai of sentences, with little more oversight than the occasional foam dart over the cubicle wall. I was permitted to wander my domain of responsibility without let or hindrance. But now I am a conscript commander, tugging at the unfamiliar collar of authority's mantle, and the duties of my new commission included recruitment.

That meant interviews. Lots of interviews.

Okay, so I admit it - I'm a total gadget whore.

I saw the preview of the new Palm "Lifedrive", and I'm in absolute technology love. But what got me thinking was the following marketing picture:

With 4GB of storage, anybody with one of these can very easily carry the entire contents of their desktop around with them. I know that my first thought was: "cool, I can do all of my work without pulling out my laptop".

Of course, that means all my work must be there. And I note that the marketing above doesn't say anything about file encryption.

This gets me wondering - as we face a more complete set of mobility, does security become even harder? These are the same questions that we asked when laptops came around, and laptop encryption has been slow on the uptake, for sure. (Although, I must say, Mac has made it really easy - FileVault rocks)

A laptop is a whole lot harder to misplace than a PDA. And a whole lot harder to steal.

As a gadget geek, this is damn cool. As a security guy, this makes me damn nervous. Where's the optimization point between those two?

Two recent events have got me thinking about encryption. First, SHA-1 was broken. Second, the 40th Anniversary of Moore's Law passed. When you put these two things together, it reminds you that encryption isn't static. Algorithms still get broken, still have problems. As computing systems get faster (and they certainly do), brute force attacks on encryption become faster as well.

At one point, not too long ago, it took days to crack a WEP key. This month, these FBI agents accomplished the task on a 128 bit WEP key in 3 minutes. The point here is that these attack vectors on encryption algorithms won't go away, ever. Systems for encrypting data have expiration dates. They may not be fixed dates and they may not be known dates, but they're out there somewhere.

Which brings us around to system design and architecture. If you design a system that relies on a particular encryption method, you better also consider how you're going to upgrade when that expiration date suddenly appears.

So, I'm not big on jumping on the FUD bandwagon around phishing and social engineering: it seems to me that enough people are writing about them these days that nobody really needs me weighing in on it. However, when I read about Winn Schwartau getting hit at home, I decided I had to post.

First, because it's certainly an interesting "anatomy of a scam" sort of post. And, second, because I think Winn rocks, and I really enjoy his writing style.

Definitely worth a read.

Anybody who knows me at all knows how many books I read. When I read Ross Mayfield's description of his recent airline screening where he was told you could only have 2 books on a plane at a time, I realized how much trouble I was in....

I carry at least two books with me on a normal day... on any flight of moderate (2-3 hours) length, I'm usually carrying 4 or 5.

That's not cool. Just out of curiosity, how could too many books pose a security threat? Any ideas?

I was reading Catspaw's blog today, and she was talking about how they take notes in class - pretty damn cool. Back in the day (8 years ago) when I went to school, we didn't have these new-fangled devices like laptops. Actually, I had a 486 laptop for a while, but vi doesn't exactly equate.

And she turned me on to this new tool: SubEthaEdit.

I'll let her describe the scene:

If you're standing in the front of a classroom, you're likely to notice that the Mac users are all doing the one-mind borgish thing. They all grin, then they all type, then they all listen. Chances are very high that they're all using SubEthaEdit to collaboratively take notes. One student types in the main content of what is being said. Another follows behind and corrects spelling mistakes while a third adds a few extra points. Perhaps another is ahead of the rest, creating structure for the rest of the document -- preparing HTML lists and section headings. Collaborative note taking doesn't just happen in the classroom. It's become a new fad for everything from conferences to meeting minutes to collaborative email composition and more.

Man, I wish we could have done that when I was in school. I may have actually gone to class in that case.

This got me thinking about the pair-writing that Johanna and Esther did last year. This is incredibly cool stuff - collaborative writing.

It also got me thinking that it would be REALLY cool to do over bluetooth - that's the next killer app in my opinion: sitting in a room, collaborating on a document via Bluetooth.

SubEthaEdit is now my default text editor on my Mac. Now, if only I can get someone to do some collaborative blogging with me.

So, as much as I like the Mac, I've come to realize and accept that I'm simply unable to continue my Mac life. I'll continue to be an evangelist for their design, but the fact is, some things simply don't work as well as they do on Windows.

The final straw was my Palm and Entourage - I live and die by the synchronization of those two items. (It's all David Allen's fault) Lately, each time I sync my Palm, the Entourage Palm conduit crashes. So, I only have 1/2 of my items. And none of my tasks. Fatal, I'm telling you - it raises my anxiety level by at least 10%, because I no longer trust any of my systems.

So, I'm going back to Windows. It's a somewhat sad day - I'm back to a far cooler looking laptop (though I like the Thinkpad). But I'll be more productive, which will let me sleep better at night.

Sometimes it is extremely fascinating where you can find strange parallels between two books that look like they should have no correlation with each other whatsoever.

One of my favourite books I read last year, being the mathematician that I am, is "Fooled By Randomness: The Hidden Role of Chance in Life and the Markets" by Nassim Nicholas Taleb. The book is about the role of chance and randomness in life (with a strong focus on the stock market itself). Essentially, the book theorizes that most successful/famous people in the stock market have made their money based on the luck of the draw and that the only real way to be successful when playing the markets is to control risk. (i.e Don't put all your eggs in one basket and don't risk more than you can afford to lose at one time). Taleb really focuses on the idea of the "Black Swan," which can be defined as an "outlier", or an event that one does not expect or has not planned for. These can be both good or bad. Winning the lottery or getting hit by lightning can be considered a "Black Swan." You will be successful if you can survive any "Black Swan" situation in the markets and possibly profit from them.

On mmurray's recommendation, I have just about finished the book "Blink" by Malcolm Gladwell. The book is essentially about the subconscious and its power in our daily lives. The beginning of the book focuses on the uncanny ability to lead us toward a solution before we are even conscious of the fact that we are making them.

At first glance, there doesn't seem to be a real correlation between them. In a stretch, you can consider them both to be business books. Fooled By Randomness with the focus on the stock market and Blink with the focus on the subconscious making quick decisions (e.g. First impressions when conducting an interview).

One of the examples given in Blink was an experiment conducted by the University of Iowa where the testers asked individuals to select cards from decks that differed in colour. If someone drew from one of the decks, they would either win or lose the amount on the card. Without giving too much away, one of the decks that an individual could choose from paid off handsomely, but was also very risky. One could not win by just picking cards from that deck. The other deck was more conservative. One would not win as much as choosing from the other deck, but one would lose even less. The conclusion was that the people taking the experiment could figure that one deck was safer than the other eventually. However, they would be able to determine this subconsciously way before they consciously knew it and would be drawn to the safer deck.

I thought about being "Fooled By Randomness" right after reading this section of "Blink". Taleb talks about how humans often see patterns in things (or believe they understand how things work) that are completely random. Taking the card example that is used in the Iowa Experiment (not exactly the same, they weren't drawing from a standard deck of cards, but using it as an example), if one is drawing from a deck of cards and get 12 red cards in a row, there is a strong chance that the next card will be black. However, even though the odds of getting a black card is much higher than getting a red one, you will be pushed into towards guessing that the next card is red. Even though you know it's a standard deck and logic will dictate that you should pick black, you'll stop for a second. What if this deck is different???
The same is true with flipping a coin. If you are able to flip heads 20 times in row, what are the odds of the next coin flip being heads? (As a note: The odds of anyone flipping heads 20 times in a row is ~1/1000000, or (1/2)^20).

As a math guy, this is messed. My background is numbers and logic. One source is telling you that your subconscious can lead you toward the right conclusion without you even knowing it. Another source is telling you that your subconscious can lie or lead you in the wrong direction depending on the input. (To be fair, Blink does talk about this in later chapters). So, in the end, I conclude this from both books. Trust your instincts, but only when they are not wrong. :)
But when is that? How do I ever know that my subconscious is not leading me in one direction based on a pattern that doesn't really exist?

I woke up around 6am for an early morning and got some work done prior to the CanSec West registration (which started around 9am). The registration procedure had some technical difficulties which halted the process for a little over an hour. After successfully registering I walked towards a glass wall and stared at a piano located on the floor beneath me while contemplating a few melodies.

The first presentation, "Mobile Workstations, mitigating the crawling trojans" presented by Cedric Blancher, was about to begin. I must admit the name sparked more curiosity and excitement then the presentation itself. The "Mobile Workstation" was essentially a laptop, as expected, and the "crawling trojans" simply meant the ever changing insecure network environment the laptop is subject too. Much like in "Independence Day" the Alien skiff kept at Area 51, piloted by... monkeys, invades the perimeter defence of the Alien mother ship undetected while carrying a deadly payload. The mother ship is damaged severely because the Alien's did not anticipate the skiff to be infected by... monkeys. So the morale of the story is not to treat a "Mobile Workstation" as if it were a trusted device (such as an office workstation) because you can not control it, only the monkeys do.

The second presentation, "0wn3d by an iPod: Firewire/1394 Issues" presented by Maximillian Dornseif, was easily my favourite. First introducing the history and some technical data of Firewire/1394, I mean FireWire/1394, I mean iLink... Mr. Dornseif then explained the potential to read and/or write to any physical memory address on a system through the Firewire port without authentication. I must admit I was sceptical at first as it seemed highly illogical that such capabilities would be so easily granted. My scepticism was quickly put to shame as Mr. Dornseif provided us with a demo. Two computers were first linked together using the Firewire port and then the video memory of one computer was read and modify by the other. Someone, somewhere, must be saying "Oops" right about now.

The third presentation, "0wn3d by everything else: USB/PCMCIA Issues" presented by "David Maynor", was particularly boring. At first the issue appeared to be the potential exploitation of device drivers, then DMA, then USB, then firmware, or hiding code in FPGA's that some video cards apparently use... FPGA's used by a consumer video card? Maybe if I was not an avid IDA user I would have enjoyed the IDA screenshots. The lack of consistency left me logging into my IRC client and talking with a few friends about... lack of consistency. I felt like the sky is falling... only it is not falling... but we can pretend it is.

The fourth presentation, "Everything is Vulnerable" presented by Brian Martin & Jake Kouns, started off well. They talked about known issues with vulnerability databases that have annoyed me and my fellow coworkers since the first day we started using them. A fine example entailed a vulnerability database claiming version "1.0" and "2.0" are vulnerable... but what about "0.9"? or "2.2"? The vulnerability is not thoroughly tested (if tested at all) and therefore should only be taken as a partial answer and not a final answer. Of course all the troubles of using a vulnerability database to determine the vulnerable instances of an application can be solved by simply checking for the existence of the vulnerability directly rather then writing peripheral version check. It was also pointed out that vulnerability databases have a tendency never to revisit and update past vulnerabilities. Therefore a vulnerability that claims to have no solution, according to the vulnerability database, may in fact have a solution.

The last presentation I am going to comment on was the sixth presentation, “ICMP Attacks” presented by Fernando Gont. The talk emphasised 3 ICMP attack methods against TCP sessions that can reduce TCP session throughput, increase TCP session latency, and reset a TCP session. Four vectors are required to perform each attack: The Source and Destination IP address, and the Source and Destination TCP port associated with the TCP stream being targeted. If you know your target Source and Destination IP address, and the Destination TCP port, the only vector you need to brute force is the Source TCP port. Therefore the brute force space is only 65536 possibilities. This brute force space can be reduced when considering deterministic port ranges assigned to Source TCP ports by most Operating Systems.

The presentation “Binary Difference Analysis”, presented by Halvar Flake, talked about three key elements of binary analysis: Comparing executable objects, porting information between executable objects, and navigating executable objects.

The tool known as “BinDiff” interfaces with IDA (Interactive Disassembler) and provides the capability to compare two executable objects and provide a set of code logic differences (not physical differences). This technique would be useful (and was designed for) finding undisclosed bugs in patched software when both vulnerable and non-vulnerable executables are available. We use this technique often during Microsoft Tuesday to write rules that directly detect the existence of the patch in a non-invasive manner.

Based on the analysis of the two executable objects “BinDiff” is also capable of porting code comments, variable names, and function names between two executable objects based on code segments that are logically similar (not physically similar). This technique would be useful when you have fully documented and reverse engineered an application that is later patched, or a new version is released, modifying the originally documented executable. To complete the documentation process of the new executable you can use the previously described feature to find any differences in code logic and document them accordingly.

Navigating executable objects with “BinNavi” was very impressive. The application would associate itself with an active process of the executable object you wish to navigate and permit one to take snapshots of the functions called between two points in time. This greatly simplifies the process of determining how to execute certain segments of code (such as the vulnerable segment that was determined when detecting the difference between a vulnerable and non-vulnerable executable). This should also simplify the process of reverse engineering proprietary protocols by permitting one the ability to easily determine how an executable interprets the data it receives. The graphing present in “BinNavi” was amazing from both a usability perspective, narrowing down the amount of information to only important aspects of the graph based on function call analysis, and an eye candy perspective with graph rotations, fitting data onto a single screen (the ball of yarn), and providing graphs similar to “BinDiff”.

The presentation "Advances in Exploit Technology", presented by H D Moore & spoonm, talked about the future of exploits and how Metasploit was going to make things better... for the ones writing the exploit. They touched on comparisons of open source and closed source exploitation; dynamic vs. static addressing, return address bouncing, using the stack exception handler, polymorphic exploits to avoid detection (IDS/IPS) systems, and the concept of a multi-byte NOP sled.

The most interesting aspect of the presentation was polymorphic exploitation code. This would make the life of a passive detection system much more challenging. I would imagine that it would be possible to design algorithms capable of deciphering polymorphic code based on the same principles of "BinDiff"... look for common logic. It may also be possible to simply detect the polymorphic algorithm and completely avoid any code deciphering.

The multi-byte NOP sled was also very interesting. It appeared to be a concept for generating random OP codes that do not impact the process or shell code in a negative way. It is placed in the stack prior to the shell code when the return address is non-deterministic. The shell code must be placed in a location that is equal to or above the highest perceived return address. The multi-byte NOP sled generates random OP codes to obfuscate passive detection while simultaneously providing a clean path of execution to the shell code.

The presentation "Windows Internals", presented by Cesar Cerrudo, talked about the potential use for a shared "section" of memory associated with a privileged process. These memory regions can be found quite easily using "Process Explorer", a personal favourite Windows tool. Four additional tools were also cited during this presentation: "WinOBJ" which shows object manager namespace information, "ListSS" which lists shared section names, "DumpSS" which dumps shared section data, and "TestSS" which overwrites shared section data. A shared "section" of memory could permit a local unprivileged user the ability to view and/or alter content resulting in a potential crash, influence of functionality, unauthorized access to information, or execution of code at an elevated privilege.

Applications that use shared memory often do not verify integrity of data making it particularly easy to cause undesired conditions that may lead to a crash or execution of code with the privilege of the process. This is because applications tend to trust the content present in shared memory... and why should they not trust it? Access to shared memory should be assigned in a manner that grants an application trust regarding content.

This vulnerability is a serious issue that could easily permit spyware applications and viral software system privileges on a Windows workstation when executed in an unprivileged account. Three suggested solutions: "Set proper permission" (also pointed out above), "Use some synchronization mechanism", and "Validate the data before using it". I believe the appropriate solution is the proper definition of permission such that only trusted access is permitted. Validation of data should only be performed in situations were un-trusted access is a functional requirement. Synchronization would not solve this issue and would only provide unnecessary overhead... Windows has enough overhead.

I'll be blogging the next couple of days from the Security Leadership Conference put on by ISC2 in Washington, DC.

I'm speaking at the conference, so I'll post my slides up here tomorrow. In addition, I'll be posting updates and thoughts from within a session or two.

The first talk that I saw today was Adam Shostak's talk about patch management. His basic messages were somewhat common sense -
       - Patch unreliability presents a significant amount of risk.
       - Patching too quickly or without considering that risk is insane.
       - Consider the cost of capital and business risk before applying patches willy-nilly.

You know, while that seems pretty obvious, it's probably very much like a quote that I heard from Stephen Covey yesterday: Common sense is most often not common practice"

All in all, a decent message, especially for the audience here.

That was another quote from Mary-Ann from Oracle - that security should act as a business enabler. That's been a common position today - Adam Shostak mentioned it in his presentation as well. Basically, others are coming to the same argument I've been making on here for a couple of months now - security cannot survive as a cost center.

The real goal for Infosec needs to be to show business how we do (at least) one of the following two things:
      - Create revenue
      - Reduce costs

This can't be through sheer loss-reduction. If it is, the "it'll never happen to me" school of thought will always have a way out of making systems more secure.

Mary-Ann kept using the metaphor of bridge-building. To use similar terms, security can't just keep the bridge from falling down in an earthquake - it has to build a better bridge. If it's just about disaster avoidance and recovery, there's always going to be a reason to spend less money on it in difficult times.

"Those who learn and do not teach are thieves"

I wish I could remember where that quote is from as the elegance of that statement is pleasing, and it feels like truth to me.

I have said it before and I will say it again: people who hoard knowledge are unworthy of respect. I do not care how high up in 'the scene' you are, or if you work for a big company. I am not claiming to be a 'white hat' or a 'black hat' - I think those terms are stupid. They are labels, and as soon as you label somthing you lose the nuance that makes something what it is. I am just an explorer in this world. Nothing more, nothing less.

People who traffic in non-public exploits are morally reprehensible.

Should people who discover new medicines or treatment methods keep them to themselves? Should ways of reducing pollution and helping the environment be available only to those who sign up for some company's product? Should we only teach children if they can pay us? 'Of course not' you should say if you are a conscientious human being.

Then why keep your exploits to yourself? How can you justify that?

Here at nCircle we use stuff from Immunitysec. That bothers me because I do not care for how they do business and how they keep their goods close to their chest. I think it is dishonourable. People that do that are pimping knowledge.

Have people forgot what it means to be a real hacker? To explore and learn about the world. To create and reveal new knowledge. That is where respect should come from.

People who traffic in non-public exploits are morally reprehensible. Fact.

Analysts report that Firefox adoption is slowing.

They also mention that, "Late last month Firefox marked 50 million downloads of its browser since the Version 1.0 release in November."

50 M sounds like a large following – until you consider what a download is. All security updates count as 1 FULL download. As previously ranted, Firefox 'update' is actually a full reinstall. The current release is 1.0.4, for a total of 5 releases. So now we are talking about 10 M functioning installations – still a pretty big number.

Why else would Firefox adoption be slowing?
"The slackening of Firefox's growth could mean that the browser has converted a substantial proportion of its natural constituency, thought to be early adopters and the technically savvy."

Well if all of the early adopters and tech savvy elite have been running Firefox since November then the 10 M is actually 3.5 M – as all self respecting geeks own more than one computer.

Now here is the quote that justifies this entry on a Security Blog;
"It could also show that the browser's widely publicised security
flaws have begun to undermine the foundation's argument that people
should switch from IE to be safer."

Could it be? Could Mozilla have their shit together so tight that people are scared to run Firefox? Not possible! Just look at their awesome security advisory page. Not only is it organized in a really sensible way, but the colour coded severity labels are all pastel! When your most severe vulns are fuchsia, I know there is nothing to fear!

Maybe this whole security scare comes from the mixed messages surrounding Firefox security;

[May 7th]
2 Critical Vulns found in Firefox.

[May 10th]
"Two vulnerabilities in the popular Firefox browser have been rated "extremely critical" because exploit code is now available to take advantage of them."

[May 11th]
"Chris Hofmann, Mozilla's director of engineering, said: "We've had a few security updates, but they've been for potential vulnerabilities, for staying ahead of the curve of potential problems that might come down the road."

While the fact that you patched your software pretty quick reassures me, I just wish you would get your story straight ...

Now for some good news;
"One of the biggest difficulties that the Mozilla Foundation has encountered in the months following the Firefox 1.0 release has been managing the Software Update System for distributing updates to 1.0 users… Darin has figured out how to get binary patching working, and is working on a system for incremental background update download." -- Ben Goodger (lead engineer for Mozilla Firefox)

Now that is what I'm talking about! Mozilla, if you deliver on that comment then truly Firefox is the shit!

Firefox 1.1 (July 2005) will be downloaded by the current fan base of 3.5 M – and then never again. We can just expect our security updates to silently arrive and then prompt us to click OK.

Oh what will the Analysts think?

It’s a shame that getting security right will decrease your popularity in the eyes of analysts. Lets just keep that little secret between us and the User-Agent: strings - ok?

Analysts don’t get Firefox, which probably means you should.

I'm sitting at a car dealership right now. While my car is being worked on, they've courteously provided me with a desk and an ethernet cable. Seems like a good idea. This way, I'm not totally unproductive while my car is out of commission. I can't help, however, thinking of this from the perspective of IT security. There was a time when a corporate IT team could reasonably believe that they have control (in some measure) over the hosts for which they're responsible. In a world where access is available everywhere, and many employees carry laptops, that control isn't even an illusion any more.

The possibility of an unstructured compromise (virus/malware) is obvious in these public scenarios. All it takes is a single infected laptop and another vulnerable host. That's the obvious concern. Less obvious is the increased feasibility of structured, intentional compromise. If I, as an attacker, have identified an intended target, I can more easily launch an attack in a public location. If I find out that my target frequents a particular Starbucks, or has an open WAP at home, there is no need to obtain access to the corporate infrastructure to achieve a compromise.

It's not that this increased threat isn't understood by the InfoSec community, it's that it isn't understood by the average user. The ability to effectively manage the vulnerabilities on each host while they are within the corporate IT infrastructure is even more important when they will inevitably leave that protective environment.

The House passed two bills aimed at stopping spyware:

H.R.29 and H.R.744

While there's a lot of interesting stuff in these two pieces of legislation, there are just a couple of things that struck me in particular. In H.R.744 section 1030A there's an awful lot of the word 'intentionally.' To legislate based on intentions is an interesting concept.

One of the clauses in here states that whoever "intentionally impairs the security protection of the protected computer with the intent to defraud or injure a person or damage a protected computer" is in violation of this law. Now, if my intent in compromising the computer is, in fact, to expose a security risk such that it can be addressed, am I still in violation of this law?

But maybe all of this is moot, since a 'protected computer' is defined in USC 18 Section 1030 as:

(2) the term ''protected computer'' means a computer -
(A) exclusively for the use of a financial institution or the
United States Government, or, in the case of a computer not
exclusively for such use, used by or for a financial
institution or the United States Government and the conduct
constituting the offense affects that use by or for the
financial institution or the Government; or
(B) which is used in interstate or foreign commerce or
communication, including a computer located outside the United
States that is used in a manner that affects interstate or
foreign commerce or communication of the United States;

Based on that definition, most home users aren't really covered. Seems odd that congress would pass this anti-spyware legislation that fails to cover the majority of the victims of spyware. Did I miss something?

I was reading an interesting paper tonight called Overcoming Serious Indecisiveness. The paper's an excellent one which many others have blogged about, but there's a quote that I had to post here.

In The Histories, written in 450 B.C., Herodotus makes the following statement:
"If an important decision is to be made [the Persians] discuss the question when they are drunk and the following day the master of the house...submits their decision for reconsideration when they are sober. If they still approve it, it is adopted; if not, it is abandoned. Conversely, any decision they make when they are sober is reconsidered afterwards when they are drunk."

I wonder if that'd make more sense than some strategies I've seen people employ. It'd certainly be more amusing to watch.

Seriously, though... read the paper. It's interesting.

This rather sparse on details article is getting quite a lot of play. The article does not provide all the information necessary, but many people are willing to suggest that it sets a precedent for 'encryption software is evidence of criminal activity." Actually, if one thinks of encryption as a tool, like, say, a knife, then this decision may make some sense. If a murder occurred and there was a knife present, wouldn't it be relevant to the case? That decision doesn't mean it was relevant to the *verdict*, but only that the judge didn't allow the defense to remove it from the trial.

From the article:
"We find that evidence of appellant's Internet use and the existence of an encryption program on his computer was at least somewhat relevant to the state's case against him," Judge R.A. Randall wrote in an opinion dated May 3.

I'll wait for more information before drawing a conclusion on this one. "[A]t least somewhat relevant" to the case doesn't seem to quite the declaration that others are claiming.

In the end, however, isn't this type of decision a great reason for everyone to install gpg? I'm going to start encrypting my grocery list.

I'm not really an expert on Bluetooth - I enjoy using it, but I haven't spent enough time reading all of the incredibly interesting bluetooth hacking papers that have shown up lately.

The reason I thought about this - I was sitting with a new employee today, and he said: "Aren't you worried?!?!?" He looked incredulous.

Actually, I suppose that I am. A lot of my life is bluetooth enabled, and it definitely makes me nervous. However, for now, I'm following best practices - none of my devices are discoverable, everything is paired with pretty random PINs, and I turn Bluetooth off when I don't need it.

That said, it certainly puts together an entirely new threat model - I've been engaged in a bit of a debate with a couple of pepole about my new lifedrive. It can auto-lock after a certain period of inactivity, and encrypt all the contents. With 4GB, it takes a ridiculous amount of time to DECRYPT, however - from 5-20 minutes. So, what's the best timeframe for the auto-lock? I've currently got it set to 2 hours, but that's annoying. 8 hours seems too long. (Obviously, 4 hours is a nice compromise).

Anybody have any thoughts? And what's your favorite BT hacking paper?

No, that's not a personal opinion. It's the title of a new book that I'm reading which is making me laugh and cry at the same time.

The subtitle on this book is the best:

Why many enterprise-oriented human capital assets consistently utilize complex linguistic architectures and niche-centric jargon to articulate mission-critical messaging and action itmes to their companies' diverse global constituencies, resulting in discernible disenfranchisement and change resistance on the part of each and every value-added stakeholder, who is consequently required at the end of the day to deploy more bandwidth oward drilling down into the communication than might otherwise hvae been required to maintain his or her comprehension of same and how not to do that

What's even better? They have a blog. It's now in my "Daily Reading" group in my RSS reader.

If only there was a place to actually download the Bullfighter software - I remember trying it out when it first came out a couple of years ago. But at that point, I wasn't doing much with Powerpoint or Word - I wasn't needing to be careful.

Now, I'm commencing to be trepedatious with respect to the loquaciousness of the jargon that I may or may not use within daily enterprise-representative communications.

Or something like that.

So, 10 new vulns today on MS Tuesday - some interesting ones.

Vulnerability in SMB- this one's the serious vuln of the day. It looks, for all intents and purposes, that this one's an unauthenticated, network-based buffer overflow. If this one's exploitable, it'll make one heck of a worm. I expect we'll see exploits in the first 48 hours.

XSS in Outlook Web Access - this one was reported by our friends over at iDefense. What's interesting here isn't the vuln - it's not that severe in itself. However, it's a fun little vuln, and OWA is always amusing.

So, I've spent the last year thinking about starting a Toronto-area security group, whose purpose is to talk to engineers rather than the higher-end business people in the infosec industry. (We have ISSA to fill that need). Unfortunately, the past year has shown a dearth of time and an over-abundance of things to do.

So, imagine my overwhelming sense of "how cool is that?" when I first heard about the Toronto Area Security Klatch (TASK). I've yet to make a meeting, but it's exactly the group that I've been wanting to start. So, now I'm doing everything I can to support the group. I had a meeting a couple of weeks ago with Brian Bourne, one of the creators of the group, and it seems like the group is doing some incredibly cool stuff.

There's a particular working group that I need to mention - it's called "Buffer Education, Exploitation, & Research" (or BEER), and it's run by the newest member of Toronto's VERT group, Jeremy Richards. I urge you all to check out the forum - Jeremy is running a cool little group, and TASK is a pretty smart group of guys.

...because they apparently are engaging in some scary trust relationships. Did you know that in 2004, the FDIC issued a financial institution letter Risk Management of Free and Open Source Software? In the same year, Bank Of America announced migration plans to Linux.

Old news right? Well apparently financial institutions just aren’t getting it. The mere fact that in 2004 the FDIC needed to issue such a letter, points to the prevalence of open source code handling our every day financial transactions. But lets talk trust. Who in their right mind would trust a backup tape containing confidential information of 3.9 million customers to be shipped snail mail?

Where is the tracking number? Could Citigroup not afford the $100 for PGP commercial? I’m curious, did Citigroup check the credentials on the UPS delivery person before handing over this package? Funny, I doubt I could walk into a local bank branch and request even a $20 withdrawal without authenticating myself. On the same token, consumers should be curious about Citigroup’s and other bank’s security policies.

If our financial institutions are using open source code with such prevalence, I fear their security practices when it comes to the use of open source code and their software development practices. I couldn’t work for nCircle without a background check; I hope our banks perform the same for their developers. But wait a second, its open source! Are our banks performing background checks on every developer for OpenSSL, Apache, Linux, etc? So you wanna be a developer for Bank Of America’s infrastructure...just check in some source for an open source package.

I’m glad to see more and more people commenting on trust. Jim Tiller comments "many companies are crunchy on the outside and chewy on the inside. This has been the result of trust." Trust can enable situations which create an attractive risk/reward outcome, but can also be our doom. Fact is we rely on trust. We trust our friends, neighbors, family and even the car traveling 70MPH not to cross that magical white line, causing our cars to go crashing into a light pole. For some reason we trust the bank, they don’t trust us, but they do trust the guy driving the brown truck.

We’ll talk more about trust in the coming months, until then; go buy a van, a brown outfit and some brown paint.

It should be obvious how busy life at nCircle has been from the absolute and utter silence on here of late.

I have two quick pre-announcement announcements...

A quick newsbite: watch for a relatively big announcement on here in the next couple of weeks. We've been working on an incredibly cool project, and, like a kid on Christmas, I'm looking forward to unwrapping it for everyone to see.

Second: we're taking a bunch of VERT members to the Blackhat Briefings this year. I'm going to be there and I'm looking forward to the parties^H^H^H^H^H^H^H... uh, talks. As an aside, nCircle's going to be throwing one of the afforementioned parties. Stay tuned for more details.

We have all seen them; they are the 3rd party R2-D2-like ATMs that randomly pop out of the wall at a mom and pop diner. Many of us, speaking figuratively about humans in general, walk up to the machine, insert our card, agree to pay the outrageous service fee and most times walk away with a yuppie stamp or two. The level of trust just placed on this plastic money dispensing box purports to be enormous. How can we be sure that the proprietor of that system hasn’t modified it to collect our card and pin? What about this non-descript plastic box plugged into the wall invites you to give away the key to open your checking account?

How many of you go out of your way to find an ATM branded by a big name bank? Does the name Bank of America posted on the money wall provide any real assurance? It’s about trust. Even with the amount of identity fraud on the rise, seems to me people aren’t learning for our mistakes. I wish I could stop trusting that money wall. Fact is, as soon as you stop trusting, society begins to break down.

When dealing with security issues, there are generally two types of solutions: technical solutions that use systems to enforce, and social solutions that rely on policy alone to modify behaviour. Generally, there is a pretty clear understanding of what constitutes a need for a social solution versus a technical solution.

But sometimes we get it wrong. Let's use spam as a case in point. The spam problem is largely a social problem, one that technical solutions don't address in anything approaching an ideal manner. Spam filtering works, but it doesn't work all the time and it doesn't work very well. On the social side, spam policy has been largely innefective in curbing unwanted commercial email. Laws that have been passed are regional, with relatively mild punishments except for the most egregious offenders.

So that brings me to a question: can technical solutions to social problems, or social solutions to technical problems even work? What if a given problem has both social and technical components? Piracy is a social problem. Can rigid DRM controls reduce piracy? Access control is a technical problem. Can enforcing access control on the honor system be an effective way to protect critical systems? Obviously not.

Are social solutions to technical problems or technical solutions to social problems ever effective?

I've been thinking about this concept for a while now. In the technical world we authenticate ourselves to systems with explicit credentials. In the social world, authentication takes place with much less explicit means, often without any identification. Understanding this concept of 'soft authentication' is integral to social engineering attacks, but also to interacting with other people.

The examples for social engineering attacks are fairly straightforward. If you dial into a company's main receptionist in an attempt to elicit some information (say, a password or account name), you're much more likely to get the data if you use the right vocabulary. You need to know what their IT department is called (IT, tech services, IS, etc). You need to know, maybe, what they call their main corporate office (HQ, corporate, home office, a city name, etc). These kinds of subtle clues tell the person you're talking to that you're 'part of the system,' i.e. they authenticate you. If you use the wrong words, the person on the other end will immediately know something is wrong, though they may not be able to describe exactly what it is.

This is soft authentication, used to access a social system. In fact, the soft authentication may not even be verbal. Wearing the right uniform, for example, would be a physical example. Carrying the right type of bag, or equipment is another example.

The model applies, however, outside of social engineering as well. In fact, it's part of human culture. I'm thinking of this because I just sent an email to a customer service address for an order I'm waiting for. I re-read what I had written and realized that it didn't sound like me at all. In fact, it sounded like the marketing text on their website. I had, without thinking about it, adapted my speech to meet the cultural niche that they advertise themselves as being a part of. In other words, I attempted to authenticate myself to them in order to get better service.

Of course, this type of soft authentication is just part of interacting with other people. We are constantly assessing others based on both verbal and non-verbal clues to determine how to relate to them, what information to share, and what categories they fit into. Most of the time, this is not a conscious process, but the people who can pull it into their conscious minds can more successfully determine what the relevant authentication techniques are. They can then be more aware of when and how they are authenticating people, and ultimately more careful about what information they give out.

The other day during Blackhat, I was asked by a VERT team member what I thought of the recent announcement that Apple will be switching to Intel processors. The question surrounded security. Will this affect the relative security of OSX in a noticeable way? I didn't really have a good answer, but my initial thoughts were "it could".

Is OSX "relatively" secure because it is built on FreeBSD? Or is it because, compared to the x86 processor, there aren't a lot of people writing PPC exploits? Or is it for another reason entirely such as a small market share?

So 3COM is sporting their new 'ZDI'. I think it's kind of cheesy - they're trying to come off as if they're doing it for altruistic reasons. Please - does anyone believe this kind of line anymore?

Let's review some amusements and a couple steps from their site (http://www.zerodayinitiative.com/details.html):

"...with the altruistic aim of helping to secure a broader user base"

Let's contrast this with step #4:

"3COM verifies the vulnerability and decides whether to make an offer within a week on average"

As well as step #8:

"Later, 3COM shares advance notice of the vulnerability details to the other security vendors before public disclosure"

What the hell does 'later' mean? I'll tell you what I think it means: as soon as they've rolled it into their own/partner's product(s) giving themselves a healthy lead on the competition. Hmm... I don't see much altruism there.

What kind of time frame do they think qualifies as being altruistic for the community? Seems to me it's probably gonna take at least a couple weeks before 'other security vendors' are notified. A day might as well be a year in this industry.

3COM, I gotta say your ZDI sounds a little weak. If you were really 'altruistic' you'd send folks in the industry advance notice that someone had submitted a 'sploit with basic details, then followup immediately as soon you get more info or confirmation. And continue until a solution is found, if one exists.

Not to mention that paying for 'sploits is lame, lame, lame. As I've said before, the longer something is unknown, the more dangerous it becomes. I can accept arguments for responsible disclosure, but for a SHORT (1-2 week) time frame only. Really, I think the only solution is to publish 'sploits as soon as you find them to the public at large, with no warning to anyone at all. That way, everyone is on the same page and no one has a chance to strangle the flow of knowledge with stupid 'Zero Day Initiatives'.

Ok, the title is wonky. I'm in no way associated with CanSec West (or DefCon), though I've heard it was a great time. I'm hoping to go next year, Vancouver and environs are great. North Shore mountain biking kicks ass too, so there's a million reasons to head out west! East Hastings and all :)

But why isn't there something of this calibre in Toronto? Why don't we have something in the T-dot?

I used to think the main reason was that New York was so close it sucked the wind out of our sails. But I don't know anymore - there's an awfully large computer community in this town, many good universities aren't that far away, it's the most multicultural city on the planet, tons of good restaurants, and chock full of good old Canuck decency. We don't appear to have quite as many wacky anti-freedom laws as our brothers to the south (despite us having, as I've been told, the most secretive government in the commonwealth), and we're pretty damn liberal. We have ample convention centre space, and we have good telco infrastructure. We also have an assload of unsecure 802.11foo; I know as I've driven the whole core and mapped it. Which reminds me, I gotta update the map for this year.

Is this just a stupid idea, or has it's time perhaps come? Maybe we need just enough corporate support and cash to get the thing going... I know us up in the Toronto office have talked about this idea many times.

Thoughts, opinions or suggestions would be welcome.

I think 3Com's ZDI is an interesting idea. Sure, it's set up in such a way that it has direct benefit to the corporations involved, but that is to be expected. This is business. Altruism aside, giving incentive to the large pool of unpaid security researchers doing valid and neccessary work can do a lot for the industry. If getting paid is the difference between a 0-day vuln being leveraged by a worm and responsible disclosure, then great.

If everyone just released exploit code and vulns immediately after finding them, it *might* ultimately make things more secure in the long run, but in the short term it's going to hurt. Badly. I for one like it when companies I do business with are given the oppurtunity to correct security issues before some twelve year old with some perl code can muck up my personal life. Yours, too, for that matter.

-----Original Message-----
From: dailydave-bounces@lists.immunitysec.com
Sent: Wednesday, August 10, 2005 9:48 PM
Subject: [Dailydave] In soviet russia the telephone api calls YOU

So FELINE has come out and been patched, aka the Tapi stack overflow, courtesy of Kostya Kortchinsky. Sinan Eren also found it a while back while auditing random things on a plane somewhere, I believe.

Yet again, Immunitysec and posse discover something before everyone else, conveniently letting us know after the fact! Amazing! :|

i've been spending a bit of time following the blog entries on microsoft's security response center blog. lots of good timely info, especially in regards to the recent ms advisories and corresponding malware.

check it out:

http://blogs.technet.com/msrc/

props to our own mmurray for pointing this out to all of us here in vert.

while not directly related to infosec, i found this site to be an interesting juxtaposition of art, mathematics and culture. the basic idea is to collect, analyze, and visualize the "popularity" of various integers from 0 to 1 million. what is fascinating to me about this, aside from my fixation with mathematic visualization, are the patterns that emerge. some types of numbers are obviously more popular than others ("2000", "2100", "90210", "12345", "8888", etc), and show certain aspects of "the psychology of numbers", if you will.

anyway, while not directly related to security, this type of research/art does give us some insight into patterns and what they might mean. if you distill that idea down far enough, it's applicable to almost all disciplines involving problem solving.

check it out:
the secret lives of numbers

so we've been debating an interesting question here lately. does a vulnerable application have to actually be running before it is considered vulnerable?

say, for example, you have a system that came with apache preinstalled as part of the base os. in order to satisfy the requirements for your organizations web server, you install apache from source with your own configuration and modules. you leave the original apache install alone. while the running apache instance is not vulnerable, let's say the apache installed with the base os just so happens to be. in that situation are you truly vulnerable?

in my mind, the answer is yes. at any time that software can be inadvertently started. granted, one would hope that the wrong instance of some application being started would be quickly noticed. but sometimes that won't be the case. how often do applications under windows enable iis at install time, without adequetely informing the user that they are doing so? sounds dangerous to me.

imagine dynamite. now, a stick of dynamite and a book of matches are a dangerous combination. but if you don't have the matches, is the dynamite still dangerous? absolutely.

let the argument proceed.

Hey blog spammers - go pound sand, you jerks. May you awake to find yourselves in a Turkish prison.

And yes, I know that it's probably a bot and not a person. But it's still annoying.

Interesting article on responsible disclosure, via Slashdot:

http://www.zdnetasia.com/news/security/0,39044215,39252943-1,00.htm

Interesting article on programming language design and applicability to various problems. This was originally sent out internally by one of our development engineers, and I found it a rather interesting read. Good design and development decisions can definately lead to more secure code, so while thin, this does have some relevance to security.

http://www.paulgraham.com/power.html

There's an article over at Wired talking about a new browser built on top of the Mozilla core. It's called 'flock' and is touted as a 'social browser' with lots of blog and social networking support. Will this be yet another vector for exploitation? Is anyone playing with this yet?

What makes me nervous about this is the following statement from the article:

"The browser even promises to detect and authenticate all those user accounts automatically."

Is it just me, or is that not just a little bit sketchy?

http://www.wired.com/news/technology/0,1282,68823,00.html?tw=newsletter_topstories_ascii

Interesting editorial on anonymity.

Sure, it's MLP from SecurityFocus... but any article that starts out quoting 'True Names' by Vernor Vinge is worth the read, even if you don't agree. :)

http://www.securityfocus.com/columnists/356

So, it's certainly been a long time since I've posted. That's what I get for being busy.

So much is going on at nCircle that I don't even know where to start.

We're releasing IP360 6.5 this week - this one's going to have some incredibly cool new features that are pretty cool. (Especially the Topology Risk Analyzer)

Okay... this post is coming off too much like marketing.

This is mostly just a mindless bitching session, but it's been building for a while.

Why are sites with decent and well worn design and looks being changed? I'll pick the two most egregious examples that come to mind - securityfocus.com and theonion.com.

What the hell was wrong with the original site? The new one is hideous and crowded. It's not at all pleasing to the eye. In fact, I'm going to say they're shit. If something isn't broken, don't fix it. If it was changed 'cos people were bored of the old look, that's lame.

Especially for securityfocus.com's site - it's a useful tool (if you ignore the fact it seems they never update their vulns and contain alot of inaccuracies) and I spend alot of time there. Let's compare it to a screwdriver: it would be remarkably stupid to change the design of a screwdriver handle because people were bored with it. Maybe it's filthy Symantec money wanting to make it more exciting looking or something. Whatever the cause, the designers did an awful job.

If you want to change a site's look 'cos you're bored, then do it like packetstormsecurity.com did. Same basic layout, slightly different flavour. Or if you need to change the site functionality significantly, then do something like nessus.org did.

If it works, stick with it!

Also, I'm sick of jerks that make a whole site nothing but flash. Or that don't give you the option to skip a flash intro. Repeat after me: Flash is gimmicky crap. Flash is gimmicky crap!

I've noticed a significant ramping up in the number of emails I get from Sun and Cisco, despite the fact that I'm no longer SCSA or CCNA certified (I let the certs expire because, quite frankly, like all certs they are generally worthless). I wonder if that indicates financial difficulties that either company might be encountering. If there's one thing I've learned from reading Gibbon's "Decline And Fall Of The Roman Empire" it's that the more vociferous an entity is regarding something, the more ineffective they are at forcing or enticing people to do it.

Personally, I'll be surprised if Sun is still around in 10 years, but I can't imagine Cisco dying, as much as I think they could use some competition.

Source patching: It's fairly popular with many individuals and groups within the enterprise. But it has a lot of problems most people just never think about. Granted, given the nature of my particular job, I'm biased against source patching because it sometimes creates very difficult situations when writing vulnerability checks: no reliable or knowable vector to the exploit, unchanged banners, no detectable behavioral changes. Aside from the difficulties it creates for me personally, there are other more insidious problems that can affect an enterprise environment.

Here are a few things about source patching that not only make me nervous, they also piss me off:

1. Where did the backported patch come from?

Did it come from the vendor? If so, this is the best possible scenario. Someone familiar with the codeline backported the patch, making it relatively safe and well understood.

Did it come from the OS vendor? If the OS vendor backports patches themselves to be included in packages distributed with the operating system, did the person who created the patch understand the codeline well enough to not introduce new problems?

Did the patch come from a third party? This scares me. Random people creating patches for older versions of applications that may or may not understand the codeline is just asking for new problems to be introduced.

2. Problematic Change Control and Version Tracking

We all know that banners are just unreliable. But why? One of the major reasons is source patching. Sure the banner says it's version XYZ, but after applying patches, it's still version XYZ minus a particular vulnerable condition. So now we have a situation where the application binary reports version XYZ, but the package manager by neccessity must track this particular change. What's wrong with this picture? We now have version information tracked externally to a given application making it trivially easy to end up with bad data. What if someone decides to update the application outside of the package manager? Sure, development policy may preclude this from occuring but as we all know, policy only works when it is followed. It's relatively easy for the opposite to occur and realistically it happens more often then any of us would like to admit.

3. Security Through Obscurity

Removing banners and source patching is a form of security through obscurity. It creates a situation where the banners are out of sync with the actual released versions of the application. You don't know what you are really running. Are you running version XYZ or are you running version XYZ plus patches A, B and C? Obscuring the fact that patches are applied doesn't really result in much except an increase in potential exploit attempts because script kiddies see a banner that says "XYZ" instead of "XYZ and patches A, B, and C". So if the kiddie wants to exploit the vuln fixed by patch B, they are obviously going to make an attempt and annoy the admins of the system. So having accurate banners can potentially reduce the amount of fly swatting that occurs on a day to day basis. Sure, it can also be a neon sign pointing out that you are vulnerable to something, but it's hardly any worse than obfuscating banners. If you are still vulnerable, an obfuscated banner won't do much to thwart an attack against someone who is attempting to exploit the condition regardless of what the banners say.

Way back in history, security through obscurity was a valid form of protection. It came from a time when trust was largely social. If something was hidden, it was safe enough, because no one would look for it. Or something like that. Times have changed. Security isn't a fuzzy thing. Either you are vulnerable, or you are not vulnerable. If you are vulnerable, hiding it without correcting the problem doesn't do much if someone really wants to compromise your system.

With the increase in automated exploits such as worms and point-and-click root-a-matic applications floating around, obfuscating banners becomes moot.

4. Recompilation and Application Stability

So, you say, source patching is a good thing when you want to maintain the stability of your application and only fix potential security issues. Sure, I can buy that. But it is no panacea. When you source patch, you need to rebuild the application. Did the compiler change since the last time you did a build? This has the potential to introduce subtle problems in the application that might not necessarily be an issue if updating to a newer release that includes the fixes in question.

5. It Makes My Life Difficult (and I really hate that)

No one likes crappy vulnerability checks. What I like even less is being put in to a position where I have to write a crappy vuln check because there is no other way to do it. Don't get me wrong, banners suck. Banner checks suck. They are unreliable and just plain ugly. But they don't have to be unreliable. Their unreliability is not security. It offers no protection. All it does is obscure some information about an application that can potentially backfire, especially when what the package manager says doesn't match what is actually installed or when the application doesn't give a system administrator a way to easily determine via that application proper that certain patches are installed.

So, to summarize: Source patching sucks when it doesn't include identifiable changes in the application, incorrect banners are no protection (and they just suck), and tracking version information outside the application proper is just suckage waiting to suck. Don't do it. Or better yet, application developers, you should have source patches that modify version information in the application. It makes life easier for everyone. Doing it any other way just doesn't make sense. Oh, and it sucks.

I'm sure there are many other points I'm missing here, for and against source patching. So let's talk about this... because right now it sucks, and all I want is to try and make it better. So it stops sucking.

Came across a link on kerneltrap regarding Linus's opinions of specs (http://kerneltrap.org/node/5725). The salient points he made are (and I quote):

"So there's two MAJOR reasons to avoid specs:

- they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None.

It's like real science: if you have a theory that doesn't match experiments, it doesn't matter _how_ much you like that theory. It's wrong. You can use it as an approximation, but you MUST keep in mind that it's an approximation.

- specs have an inevitably tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP.

The classic example of this is the OSI network model protocols. Classic spec-design, which had absolutely _zero_ relevance for the real world. We still talk about the seven layers model, because it's a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it's a way to _talk_ about things, not to implement them.

And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software."

I happen to agree with these points. Evolutionary design and just making shit up as you go along isn't always so bad. It's the prime technique employed by Mother Nature herself and as we are an output of this process I don't see that fundamentally we, and what we do as humans, can be all that different.

Of course it can be argued that there will be many wrong turns, backwards stances and abortive ideas, but that's not important. The process itself falls prey to the law of large numbers. On a small scale we'll screw up, but over time if we work hard and smart, we'll get there. It gives us as people agility.

As Patton said "A good plan executed right now is better then the perfect plan executed next week."

And I include myself in that group. This is a problem we all cause and suffer from.

I was reading through a blog entry by Anton Chuvakin over at O'Reilly (http://www.oreillynet.com/pub/wlg/7749#thread) and followed a link (http://www.misterpoll.com/1895245195.html) to where, at time of writing, 87% of people voted the vendors as being the most responsible for software vulns.

I understand that sentiment, but it's misplaced. It does very little to get vendors to fix things. It's similar to what I and my wife call 'Toronto Disease'. If you don't live in Toronto, then you may not have witnessed that when Torontonians see something that pisses them off, rather than do anything about it, we glare and bitch to each other about what a jackass the person is being. We seldom, if ever, actually go up to the person and talk to them about what they're doing and where/what the fault is, nor do we remove ourselves from the situation. In other words, we complain and do very little to fix it and make our lot better. Then again, we don't start imbroglios based on specious intelligence either. It's good to hold back sometimes ;)

It's the same with software. Let's take the crap that Microsoft, Oracle and others publish. Yeah it's riddled full of holes that they try to hide while giving the customer the Patch Tuesday reach-around so they feel good. But does anyone really think the situation is improving? I'm sure numbers could be trotted out to say things are getting better, but c'mon - are your days substantially better with their glorified new security initiatives?

If I may lame out and reuse a quote from a blog comment I left, it's that "You can't blame the butcher for selling what people are buying". You aren't doing anything to change the world and make it a better place by yelling "Oh poor me! The vendors make crap! They're so evil - damn them!". Well guess what - YOU, THE HORDES OF COMPLAINERS, are the ones to blame.

Until we learn to suffer and do without, rather than buy the crap for sale, the situation is not gonna change. Until you learn that some stuff you should do yourself rather than fork out cash, it's not gonna change. Here's one area where Open Source shines. Until you vote with your feet and your dollars, THINGS ARE NOT GONNA CHANGE. Take responsibility for yourself.

AKA "Microsoft Patch Tuesday Blows"

It's 21:09 EST (24 hour time and metric are superior systems, btw) and I'm headed for another cup of coffee. Probably be here into the wee hours, much like everyone else in VERT (after all, that's why our customers pay us!). And it's got me thinking that as much as I like the challenge, this kinda sucks. What really do we gain by 'bucketizing' patches and releasing them once a month? Could someone please remind me who the genius that thought of this was?

Reasons it sucks:

(A) It makes my life harder. Instead of somewhere between 8 and 20 hours that I'll be sitting here figuring things out, I'd rather do one at a time, every few days or weeks. Spread over the whole department, that means a modest increase in workload for the day, and thusly less stress.

(B) It makes for a bad testing procedure. Judging by the quality of Microsoft's OS offers, I don't put alot of faith in how well they test their patches. Especially since they've had to delay or re-release them later due to QA issues. When you're fixing things, you want to change one thing at a time. Having to apply an ungodly whack of patches at one time makes for a difficult situation - what patch was it that screwed up which system component?

(C) I bet you it makes for worse security. Given the hassle that dropping a shitload of patches on a box can be, maybe people would just forgo this. Whereas if it were a patch here, a few days later and another patch there, it might be easier.

(D) It's just plain stupid. Shouldn't things be fixed as soon as there is a patch for them? Why wait?

Feh... the Borg strikes again.

[update: There are some good things - it's a great hang out session working with cool people, and you often learn some really good stuff]

[03:01 EST update: Man, this MS Tuesday is a tough one. I really respect the folks who go from advisory to PoC/vuln check in just hours (provided that they don't have a man on the inside, that is). Mind you we're not allowed to write invasive rules, so that raises the bar]

[06:53 EST update: Gah! I'm going home to get some (more) sleep. And there's still other people here - I'd say this is a pretty dedicated team, eh? Or at least a stubborn one :) And with Cali 3 hours out, there's still folks hammering away at it.]

normally i'm not a fan of dvorak cause i don't really think he ever says anything yet he still manages to fill up a column with words related to the technology industry. this time it's a little better, although i'm still not sure what exactly his point is. the last bit is rather amusing.

http://www.pcmag.com/article2/0,1895,1869377,00.asp

Was doing the rounds checking news this morning, when a site I usually abhor (zdnn.com, heck they employ Dvorak) had something interesting to say. It was in regards to the MS05-051 causing some serious headaches: (http://news.zdnet.com/2100-1009_22-5896041.html)

"Installing the patch can cause serious problems, Microsoft said in an advisory posted to its Web site Friday. The patch could lock users out of their PC, prevent the Windows Firewall from starting, block certain applications from running or installing, and empty the network connections folder, among other things, the software maker said.

The trouble appears to occur only when default permission settings on a Windows directory have been changed, according to Microsoft. The software maker has received "limited reports" of problems from customers but is still investigating the issue, a representative said."

Patch tuesday isn't always about fixing problems - it's also about causing them too ;) And some people say that open source/free software has worse or more unreliable support than paid software? If that's you, then here's one for ya: http://www.fortunecity.com/bennyhills/gum/353/166d1f50.jpg

The Sony DRM rootkit installation has been adequately covered, I think. But there was one quote from Mark Russinovich that struck me:

"When something like this installs and doesn't advertise itself, you've lost control of your own computer," he said.

When you take someone like Russinovich, this may be true. He's got control of his computer, and so he can lose it. That's not true of many many people, and of many many organizations. The average user can't keep track of what they've installed, should install, and shouldn't install. When you have legitimate companies, like Sony, delivering software like this, the line between should and shouldn't becomes even more blurry.

When you expand this to the larger organizations, in which an individual has responsibility for multiple devices, instead of their one personal computer, the problem multiplies. If I can't control what's on my laptop, how can I control what's on my thousand devices that have multiple users?

There are simple answers, of course: limit the operations that are allowed on these devices. If people can't install things, then they, well, can't install things. Unfortunately, this type of prescriptive control often slams head first into operational reality. In the end, I suppose, you have to continuously monitor what is actually installed on said computing devices. And therein lies the difficulty...

Even though we as consumers bear the ultimate responsibility when things go wrong (buyer beware, after all... you gotta vote with your dollars) there's some devices that have been bugging me lately. Actually, for a while now ;)

These device are network printers, especially HP and Canon. However, there are far too many vendors out there that will network-enable just about anything and then sell it, letting you drop it on your wire and then find out that it's a POS, and not robust at all.

Just last week we 'worked' with a vendor who makes a certain device that allows you to aggregate the control of Cisco switch consoles. Single point of management, if you will. And this device was flaky. The vendor's response? Essentially, it was "Please exclude our devices from scans. There is a known issue that they crash." WTF?

If you're going to make products targetted towards enterprise level customers, then it's time you start making them so they can handle enterprise level abuse.

We don't want to crash people's printers - that's a bad thing, considering that we pride ourselves on being as non-invasive as humanly possible. Trust me on this one: run Nessus against a pile of boxes (servers, PCs, printers, modems, IP phones, etc), then run IP360 against them. Not to slag Nessus; I love it, but there's a ton of crap and weak-ass checks in there ("Port open! You might be vulnerable!" or my favourite: send a bunch of stuff, then check to see if you crashed it. It crashed? You're vulnerable!). Now that it's not open anymore, and there's the additional pay for play angles, maybe it will stop sucking - can't fall back on free as an excuse now ;) It's a handy tool, but certainly not enterprise worthy. No QA on many of their checks, it would appear.

So when IP360, Nessus and nmap both knock something over, then you know you got a problem. But when you can crash an HP printer with a JetDirect card in it by using nothing more then telnet, then something's seriously wrong. And in this case, what is wrong is that HP did a HORRIBLE job. Someone needs to go back to embedded network device programming school. Canon to some degree as well, but I've been through a living hell trying to sort out the HP printer crash problems. Firmware upgrades, both JetDirect and printer, do make somewhat of a difference. But not enough. This is a shame, because HP printers are generally the most unix friendly ones out there, so I'd like to personally support them as much as I can.

I think this whole problem is rooted in the old hippy era of networks, you know, back when people used rexec, rsh and rhosts files. When you could trust people. But these ain't the days anymore, folks.

How about doing up a good stack and building in some kind of packet filtering so that you can whisper in the same room as things like these and not crash them? What are they running, WinCE?

At least Oracle doesn't make embedded network devices. I can only imagine how awful those would be. Especially if they had Sun's attitude towards people that try to help them fix problems.

[edit: I would like it to be known that I worked at HP for over 3 years, so I know of what I talk. I've also used Nessus extensively in the past and attempted to contribute to it.]

So another MS Tuesday is over, and I was passed this gem:

"Retina was the first vulnerability assessment product to be updated to verify if this month's Microsoft patch is installed. Retina is also the first vulnerability assessment product that can not only remotely identify the critical metafile overflow vulnerabilities, but that can detect it without requiring administrative credentials on the system being scanned, and without being intrusive against the target system."

Speculation time:

The part that gets me is "without requiring administrative credentials". This is a rather content free statement. It doesn't say you don't need an account of some kind, just not an administrator account. Maybe you just need an account called 'retina' with almost admin privileges. Or guest, or a regular user. If this is the case, and they detect it by logging into the machine with a non-admin account, then I'd hardly say it's remote. To me, since you've logged into the machine to check, that's a local.

Sounds like propaganda to me, but I could be wrong. eEye does some killer stuff and I wouldn't be surprised if they did get a remote. I'm totally speculating on this one.

Gah... so Novell is cutting people and hurting my favourite bloated distro, SuSE. Been a happy SuSE & KDE user for years, mostly because I can't stand RedHat and the god awful Gnome desktop. Feels like crap, organized like crap, looks like crap. Retarded 'spatial views'.

Yeah I know, they'll support both desktops- but I think we know how that's gonna turn out. SuSE 10 has been the best version yet, but I think that the less german the distro gets, the worse off it's gonna be after this. The high point has been reached, I suspect.

In addition, I've always felt that SuSE's internationalization has been better than any other distro I've tried, probably because it started off non-American and consequently had to have a wider worldview and culture scope due to the inherent heterogeneity of Eurasia.

Gimme my stout teutonic code!

Not interested in starting a BSD vs Linux flamewar, I use both, but have found that Linux, SuSE in particular, supports my hardware and peripherals incredibly better than anything else. Your mileage may vary.

So, Novell: up yours. Hard.

We have to test against some pretty obscure stuff sometimes - alot of our customers have huge network spaces that are spread out all over the world. It's not an infrequent occasion to come across something you've never seen before, and that's a big part of what makes this job so cool. That and being able to wfh in the winter :)

When the new thing you're working on is software you have a great advantage: as hard as a source may be to locate there's at least the possibility that you can get it transferred to you electronically. Not so with hardware. ebay is great, a good social network is better, but often times neither is sufficient to track down that strange piece of hardware and put it in your hands. Sometimes virtualization products just don't cut it and you need the real thing.

We have the coolest collection of things I've ever seen. But you need space, power and bandwidth. And if you thought it was hard to track down and buy, it's going to be even harder to sell. If you get sick of it or need the space, that is. And throwing it out can be irresponsible sometimes (most times?), for either environmental, social or cultural reasons. This is our heritage too, folks!

What if all companies in this space started a collective of some kind whose purpose was to house and aquire and thusly be able to supply obscure and obsolete gear to member entities? It could handle maintenance and the logistics of shipping and handling too. We don't need to limit it to weird stuff either, it could lend a hand with the real pain in the ass stuff to ship. Yeah that e10k on ebay looks like a real deal 'till you figure the cross border duty into the occassion. Free trade my ass.

I can only imagine that our competitors have their equally cool labs with even more stuff I've never seen. I'm also sure that we all have stuff that each other doesn't.

If we all pooled our stuff, and came to an equitable and fair means by which we could all get ahold of said stuff, that would be great. Sure, your competitors are helped too, but it's all spread out and so the floor goes up for everyone and the overall balance stays the same. A quota system could be put on it so that you only get as much as you give. Whether that would prevent freeloaders or be contaminated by people wanting to keep all their marbles for themselves (out of greed or strategic business planning) I don't know. We can sort that out later.

If a collective won't work out, this could be a business opportunity for some enterprising folks, if it isn't already. Anyways, there's a cold bottle of Orangina calling my name that I can no longer ignore :)

Thanks Pat Buchanan in part for the title ;)

I don't know anyone who likes their government, but I'm starting to like mine even less. Looks like we got some more freedom-hating laws coming our way (please excuse the fat links):

http://www.parl.gc.ca/PDF/38/1/parlbus/chambus/house/bills/government/C-74_1.PDF
http://www.michaelgeist.ca/index.php?option=com_content&task=view&id=1009&Itemid=89&nsub=

A couple of choice quotes from the Geist article:

"...telephone and Internet service providers will be required to include an interception capability..."

And more frigteningly:

"Second, law enforcement will be able to compel ISPs to disclose subscriber information, including name, address, IP address, telephone number, and cellphone number. It would appear that such information can be compelled without judicial oversight. The so-called rigorous oversight is basically limited to recording the requests and creating the prospect for audits on the use of this power."

Osama must be laughing his ass off as we destroy more of our freedoms than he ever could. Maybe Sony's running things? ;)

I read alot of history, and I recently came across something marvelous. It was a society that had a novel approach to keeping the number of laws to a minimum. Basically, people would sponsor laws in the national or tribal assembly, but with a twist - if you proposed a law and it failed to be ratified, you were killed. I think it behooves our politicians to act like this were the case, after all, we are their bosses and they are our employees. Governments exist at our pleasure, not the other way around. Our current federal one isn't going to last much longer anyways (election time soon, w00t w00t! na na na na, hey hey hey), but the opposition parties are equally deplorable for one reason or another as well. Why do I feel like they'd all support the bill?

[edit: some chars in the second link don't get escaped properly. I'm too lazy to figure out how to fix this, but you can catch the same link off slashdot]

[2nd edit: and by 'governments' let me be clear I mean the politicos, not the heros who actually do the work. It's hard to have project discipline in public sector and tangential businessess when the top-down control changes every 4 or 5 years at election time. Some serious vision is needed]

If you've been reading this blog for any amount of time, you'll know that many of us, myself in particular, don't mince words when it comes to people, places and things that piss us off.

I'd like to take a different tack today, and thank the folks at Dameware (http://www.dameware.com/) for providing a cool enough environment that a dude doing tech support over there, Bryan Brinkman, graciously provided me with an old and obsolete version of some of their software. I needed to get ahold of this version in order to try and find deltas between versions for the purposes of writing a check for one of our customers. A mutual customer, as they want IP360 to have improved Dameware product detection.

This probably sounds like a small deal to most of you, but small acts like this can make a big difference to our jobs. It's hard to find stuff sometimes (google still fails on occasion, you know ;) and it's a real drag to hit bitchy vendors that don't want to help you out.

So thanks, Dameware and Bryan, for being cool and making my job a little easier this week.

Two studies were recently completed about the effects of customer data loss to the companies at fault. To get to the studies requires registration, etc, but there's a nice article that summarizes the findings.

The part that's most striking to me is the reaction of consumers who have been notified that a breach occured:

"According to the 'Consumer Survey on Data Security breach Notification,' 9,000 respondents said they had gotten a notification. 12% of this group had a strongly negative reaction to the situation. 20% of these terminated their relationship to the business that lost the data; another 40% were considering doing the same."

A loss of 20% of customers notified is significant. Obviously, the organizations that have already experienced this effect are well aware of the impact of failing to protect customer data. Having an actual, published number, however, might just produce some action in the organizations where action is most needed: those that haven't 'lost' customer data yet. When consumers talk with their money, corporations listen. The ability to do so is a direct result of disclosure laws recently put into place. What would that 20% be doing if they had never received those notifications? Not much, I bet.

Of course, not everyone can so effectively protest poor data protection by taking their business elsewhere.

Reading thegister.co.uk and saw some more idiocy today: (from http://www.theregister.co.uk/2005/11/25/symantec_l0phtcrack_export_controversy/)

A Reg reader who works for a large UK supermarket was this month unable to buy a copy of LC 5, a tool developed by @stake prior to its recent acquisition by Symantec. LC 5 is the commercial version of a password auditing / breaking tool better known as L0phtCrack.

Symantec's restrictions recall the dark days of the crypto wars when users outside the US were not entitled to buy products featuring strong ciphers. These rules, relaxed by the Clinton administration and following a long running campaign by cryptography experts and net activists, are once again rearing their head.

If anyone out there has problems getting the software, I'd be extremely tempted to break the law and help you get this software by ordering it myself (as I reside in Canada) and then shipping it to you. Provided you give me the cash that is.

If my memory serves me correctly, nCircle pays for a securityfocus feed so we can get the BIDs and use them in our product. Dunno how well it's working at the moment you're reading this, but at the moment I'm writing it securityfocus.com website is down. Again. As it is all too frequently.

This pains me. I use securityfocus nearly every day, it's a good tool (becoming less so, sadly), but the site is becoming unreliable and awfully formatted. Don't make me recursively wget you ;)

You rarely seem to update your vulns, your lists of affected application versions are unreliable, and you add very little to the overall equation anymore. If you're going to agglomerate all this info as a feed, at least do it right and do it well.

SecurityFocus, fix your stuff. You OWE it to us.

In the November issue of Information Security magazine, Diana Kelley from Burton Group collaborates with Ed Moyle to present “Aerial View”, an article addressing Vulnerability Management for the enterprise through the analogy of the skydiver.

http://informationsecurity.techtarget.com/magItem/0,291266,sid42_gci1137937,00.html

Let me start by saying that I have flown the friendly skies of BGA many times, and would recommend it for the right flight to the right destination. In my Identity Management days, Burton Group seemed to find the right balance between technology depth and business/industry insight. When they realigned their disciplines awhile ago to extend broader coverage of Security topics, I was cautiously optimistic that they would score another touchdown. After reviewing Aerial View, “touchdown” is the focus for today’s entry on the blog.

The article starts off on the right course: “Vulnerability management tools provide a realistic picture of the enterprise, where vulnerabilities are viewed in the context of the IT landscape”

Nicely said. A healthy dose of reality and context are crucial to managing security proactively. Particularly in enterprise environments, Vulnerability Management is clearly the right place to anchor these efforts.

Kelley and Moyle proceed to organize their thoughts under 4 essential pillars of Vulnerability Management: Asset Identification, Correlation, Validation, and Remediation.

Can’t argue with those-ations, so why the blog?

Aerial View is succinct … perhaps *too* succinct. The overall tone of the article is neither informative, nor inspiring. It just doesn’t dive deep enough.

After an encouraging introduction, the article begins with Asset Identification, and describes in general terms what VM tools do for detection. The authors mention that there is value here, but they don’t get into how essential it is to know about what is on YOUR network. The devil, as they say, is in the details.

Likewise, the article describes Correlation without scratching the surface of how crucial context is. The authors explain that correlation is moving from a laundry list to something more meaningful. They then stop short and move on to Validation.

Again, the article starts off Validation with the right message: “Not every post on Bugtraq is a reason to panic”. This assertion is followed by an explanation in no uncertain terms that you should disregard AIX vulnerabilities if you don’t have AIX in your environment. What about the environments that you *do* have? How should you go about prioritizing these?

Before diving into the conclusion, they exhaust 109 words to hint at the importance of remediation. All of this with no mention of how the preceding 3 steps drive effective remediation.

I’m not sure whether the authors are aiming for the runway or the end zone, but they can’t seem to bring this baby home for the touchdown. I have read the article four times, trying to figure out what message was intended for what audience.

Quite frankly, I still don't know.

If I am an enterprise customer who is ambivalent to the value of VM solutions, this article does not move me to action or deeper understanding. If I am an enterprise customer who realizes the value of VM, the article does not help me choose which tool, solution, vendor, or even approach is right for me and my organization. It doesn’t even offer a good list of questions to ask.

Burton Group has always been First Class in their treatment of Identity Management material. This article left me feeling like I was crammed into coach for a long haul flight with no apparent destination.

Overall, the authors attempt to send a very positive message – VM is essential, the current solutions add value, and here is a general overview of what they do. From this aerial view, however, you should help yourself to another danish ... we won't be touching down for awhile.

I suspect their skydiver opted instead to jump out of the plane and get to the details.

I try to keep an ear out for interesting and amusing things, and it seems like these folks (or someone acting in their name) are making some rumblings again. Yeah yeah, I'm slow to report this, whatever...

I'm not sure what to think of it: on one hand, this can be a pretty scuzzy industry and some people are in need of a proverbial beat down. On the other hand I feel that people should share knowledge of techniques and exploits, and not sell them. Everyone should be able to know everything. So I guess this would put me at odds with these guys.

Blackhats (stupid term) that hold onto 'sploits or techniques for their personal gain are as retarded as Whitehats (another stupid term) that don't publish the info or sell it for cash. I think as soon as you find something you should let the world know of it immediately. To heck with the vendors, to heck with the users, to heck with whatever colour 'hat' you wear. Don't even bother using the word 'greyhat' that's the stupidest one of all.

On the other hand, this could all be an elaborate joke, perhaps even with individuals acting completely seperately from each other, making it seem larger and more coordinated than it is. In which case, I find the chaos and turmoil all the more interesting and amusing.

What do you guys think?

[edit: some links, as requested: http://phrack.efnet.ru/phcisback.htm, http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/38734]

What the heck is "Web 2.0"? What marketing droid thought that idiotic term up?

Sounds like the same kind of tools that came up with the word 'blog' and feel that it represents a fundamental shift in technology and the way people do things. Guess what, it's been around for ages in one way or another... just 'cos you port ancient ideas to the internet doesn't mean that you get to claim a paradigm shift.

Being the first to give a name to something, or to do something, doesn't entitle you to claim visionary status. It takes more than that.

Other stupid acronyms and phrases: Client/Server, n-tier, B2B, B2C, SOA, P2P

I got to thinking the other day about load balancers. Is it fundamentally possible to reliably and robustly detect these devices? When it comes down to it, shouldn't a perfect load balancer be undetectable?

I'll name some common detection methods and why I think they're less than perfect:

1. Make multiple requests for the same resource, then check via hostname or IP if multiple unique entities are serving it up.

Problem is, one box can have multiple hostnames or IPs. The IP could be an alias to the same NIC, or there could be multiple NICs in the same machine. Hostnames are meaningless - you could have a million DNS records all pointing to the same box, in which case, 'round robin' isn't as 'round' as it was intended.

2. Make multiple requests for the same resource, then check via MAC address to determine if multiple unqiue entities are serving it up. This is weak for much the same reasons as above. MACs could be aliased to the same NIC. There could be multiple NICs in the same box.

3. Stack fingerprinting

Again, not a solid method. Load balancers could very well be proprietary boxes with unique stack fingerprints. So maybe we'd be able to nail a few, but not all. There's vendors out there that embed linux and don't tell you that's what's driving their gear. Doesn't do much for software load balancing either.

4. Idiosyncracies and/or artifacts in data

Sometimes data leaks out, or a signature is present in the data stream that differs from what the non-load-balanced target would normally present. This is weak, I think, because it could be a sporadic occurence. If it did occur regularly, it would probably be only for a single product or small group of products.

5. Statistical analysis

Augmenting the above techniques with statisitical analysis might help. The idea would be to collect large amounts of data. If one were to operate on a single packet/datagram basis all the devices might not be particularly distinguishable. Over time, however, patterns may be established that very strongly identify the device.

This idea is sub-optimal for many reasons. Most importantly, it's not practical for the size of customers we have. If you have 16 million nodes, and you need to hammer each one with alot of data in order to gather the information required for statistical analysis, you're gonna need alot of storage. Even more importantly, you'll probably need a healthy chunk of time, something that can't be purchased or traded for. I don't think it can be safely predicted how much space and time will be needed, much less that a result satisfactory to the customer will be obtained. Essentially we're doing the same kind of thing as TCP/IP stack fingerprinting, which can never be 100% accurate.

In short, it's my conjecture that the current state of load balancer detection (via 'black-boxing') is probably pitiful across all vendors and products. Is the industry really telling it's customers the whole story about the quality of load balancer detection?

What do you folks think?

I'll miss you, my brothers. Take care.

Reading Gregory Bateson this morning, I was reminded of the croquet game from Alice in Wonderland. The mallet is a flamingo, the ball is a hedgehog, the arches are soldiers, and the players' actions are absolutely chaotic. As Bateson’s writing always does, it got the rat in my brain turning the wheel at double-time. In particular, it got me thinking about Enterprise IT Risk Management.

Risk is about impact and likelihood.

Nail down the concepts of impact and likelihood, and you've got the building blocks for a risk management strategy ... at least a tactical one. Problem is, those concepts are not always easy to nail down. Now I understand why. In our space, risks have always been in the context of vulnerabilities - defects and associated threats. Sounds simple enough. This is not unique to Vulnerability Management - *everyone* has fallen into it. As Wiener said more than 1/2 a century ago, (paraphrased) our specialization is making us miss the bigger picture.

The story of Alice's croquet game shows that there is a disconnect between traditional risk methodologies and Network Security. There are human elements (specifically in the interactions between man and machine) that inevitably make the game seemingly unplayable. Most of us in various disciplines of Network Security treat the game as if we're dealing with a mallet, ball, and arch. I assure you, we're not.

What is on your network? What *is* your network?

As Cybernetics have been consuming most of my free cycles, I'm hyper-aware of the limitations of viewing the "network" as a collection of individual objects. Even if each object is analysed exhaustively, there are pieces of critical information that can't be found there. The same is true for the set of all sets of objects ... the information can't be found there either. If these pieces of information are not available to us through our current view, it follows that risk assessment based on this view will have downstream gaps. How can we possibly assess the true impact and likelihood of potential events while ignoring relevant facts? There has to be something better.

It's not the game it used to be ... and it never was.

Back to Alice. The object of croquet is to swing the mallet with sufficient precision to make the ball go through the arches, isn't it?

Given that the properties of the mallet, ball, and arches are relatively fixed, the variance is in the player. Good swing = good shot. Poor swing = poor shot. Not so for Alice. Should the flamingo bend its neck, should the hedgehog crawl forward, should the soldier walk to a different spot on the field, how on earth should we assess whether Alice's swing is a good one? How can she hope to improve her game?

Think *inside* the (expanded) box

So, what does all of this have to do with Risk Management? I’ve read many suggestions of what 2006 will hold for us. My opinion is that the coming year will bring *major* changes to the way that we look at Enterprise IT Risk Management. In particular, 2006 will see us looking at the entire ecosystem to redefine what the “network” is to us. In doing so, we will come to understand that our current silos of understanding do not provide us with ample information. We will begin to consider systems, humans, and the ties that bind them together. These ties lie in action as much as they lie in static attributes. 2006 will be the year of understanding through context and thinking inside a bigger box. We will redefine the game, and make our dent in the universe.

Happy holidays.

Just got back from a wonderful week in Paris; quite a lovely town. Very friendly people and great food (I still like Italian better though). My God is the Louvre a huge museum, and the best one I've ever been to in my life. The Egyptian collection is INSANE. As well, Europe, it seems, is noticeably more advanced in the use of technology to improve our day to day lives, all the more impressive as it is integrated into delightfully old cultures without any apparent clash. They just don't seem to endure the depth of struggle between technology and humanity that we have in North America. Probably 'cos they work to live and not live to work like many of us do. But I digress... I'm glad to be back!

So I check the news, which is old by now, about the WMF worm as mentioned by Jay Graver below. I would like to take this opportunity to say to all the windows folks who have been pushing Microsoft shite over the years, and the poor users, friends and family, stuck with the results of these awful decisions I've talked to and helped out over the years ...

"Haha! I told you so!"

Folks, for the love of whatever deity/deities you do or don't worship, it's time to get off your asses and switch to a new OS. Could be MacOS, I'd prefer you ran linux or bsd, but hey... as long as it's not Windows. Maybe now you'll listen to me when I tell you to ditch that Microsoft garbage? I doubt it, but I'm sure enjoying the pigeons coming home to roost. I know it's going to cause alot of people grief (I used to be an admin for the dark side too, ya know), but as it's said... you sow the wind, you reap the whirlwind.

To the people or persons who found the vector and coded up the exploit: Nicely done Sirs/Madams! I look forward to more of your good stuff in the future - keep on truckin'.

Bonne Annee/Happy New Year

One of the guys that runs our network here, Storms, pointed out that the OVAL pseudo code for the WMF check is rather amusing (I'll show just the XP case):

vulnerable software section:
Windows XP is installed
------------------------------------------------------
-- registry_test:
o the hive 'HKEY_LOCAL_MACHINE' exists
o the key 'SOFTWARE\Microsoft\Windows NT\CurrentVersion' exists
o the name 'CurrentVersion' exists
o the value equals '5.1'

While I was still in a good mood, I scrolled down and saw that the basis of the script/check/definition is XML:

<oval xmlns="http://oval.mitre.org/XMLSchema/oval" xmlns:oval="http://oval.mitre.org/XMLSchema/oval" xmlns:windows="http://oval.mitre.org/XMLSchema/oval#windows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval oval-schema.xsd " >

<generator >
<schema_version > 4.2 </schema_version>
<timestamp > 20051229114905 </timestamp>
</generator>

<definitions >
<definition id="OVAL1433" class="vulnerability" >
<affected family="windows" >
<windows:platform > Microsoft Windows XP </windows:platform>
<windows:platform > Microsoft Windows Server 2003 </windows:platform>
<product > Operating System </product>
</affected>
<dates >
<submitted date="2005-12-28-10:07" >
<contributor organization="ThreatGuard" > Robert L. Hollis </contributor>
</submitted>
<status_change date="2005-12-29-11:27" > DRAFT </status_change>
</dates>
<description >
'Microsoft Windows allows remote attackers to execute arbitrary code via a crafted Windows Metafile (WMF) format image, possibly related to the Windows Picture and Fax Viewer (SHIMGVW.DLL), a different vulnerability than CVE-2005-2123 and CVE-2005-2124, and as originally discovered in the wild on unionseek.com.'
</description>
<reference source="CVE" > CVE-2005-4560 </reference>
<status > DRAFT </status>
<version > 0 </version>
<criteria >
<software operation="OR" >
<criterion test_ref="wrt-2" comment="Windows XP is installed" negate="false" />
<criterion test_ref="wrt-61" comment="Windows Server 2003 isinstalled" negate="false" />
</software>
</criteria>
</definition>
</definitions>

<tests >
<registry_test id="wrt-61"comment="Windows Server 2003 is installed" check="at least one" xmlns="http://oval.mitre.org/XMLSchema/oval#windows" >
<object >
<hive > HKEY_LOCAL_MACHINE</hive>
<key > SOFTWARE\Microsoft\Windows NT\CurrentVersion </key>
<name > CurrentVersion </name>
</object>
<data operation="AND" >
<value operator="equals" > 5.2 </value>
</data>
</registry_test>
<registry_test id="wrt-2" comment="Windows XP is installed" check="at least one" xmlns="http://oval.mitre.org/XMLSchema/oval#windows" >
<object >
<hive > HKEY_LOCAL_MACHINE </hive>
<key > SOFTWARE\Microsoft\Windows NT\CurrentVersion </key>
<name > CurrentVersion </name>
</object>
<data operation="AND" >
<value operator="equals" > 5.1 </value>
</data>
</registry_test>
</tests>

What's the point? Isn't this the exact kind of thing that a well thought out custom scripting language would be better for? Or a file/stream containing key/value pairs (ie. "foo=123") like a conf or config.sys file?

XML is hideous, looks ugly, and complicates matters unecessarily in my opinion. It suffers from one of the same general issues that I see Java suffering: It's like using an RV when all you need is a bicycle. But I guess when you're an XML-head, everything looks like a problem in need of an XML solution. Gah.

[Edit: I felt bad about throwing around the words 'god' and 'retarded' so casually; I pulled them from the 2nd to last paragraph.]

some excerpts from midway down the article http://blogs.washingtonpost.com/securityfix/2006/01/a_timeline_of_m.html, yeah I copped it from slashdot, couldn't resist

"The data show that one area where Microsoft appears to be fixing problems more quickly is when the company learns of security holes in its products at the same time as everyone else."

Which is followed by:

"It is important to note, however, that in nearly all full-disclosure cases cited here, news of the vulnerability was also issued alongside computer code demonstrating how attackers might exploit the flaw."

Now that is delightful to hear - although, of course, it's just pragmatic, common sense.

Nobody every said NIST was a fast moving organization. After a long wait, OpenSSL has finally received FIPS 140-2 validation. Why is this important? Well, first off, it allows IP360 to implement a FIPS 140-2 certified cryptography module without having to pass along licensing costs for a commercial module to our customers. But that alone isn't worth a post here. It's worth a press release, but this isn't about marketing.

It's noteworthy that this is the first time NIST has certified source code for FIPS 140. All previous FIPS 140 certifications have been for compiled modules on specific platforms, often as part of a specific product. Take a look at the list for 2005. Most of the validations are specific products ("Juniper Networks NetScreen-5XT") rather than a software module.

It should be clear, though I'll say it anyway, that if NIST has never certified source code, then they have never certified an open-source cryptography module for FIPS 140-2. You can imagine, then, that the US government has been spending money on FIPS certified products. If you implement an Apache HTTP server and you need the SSL implementation to be FIPS compliant, you have to pay for a commercial module to get there. Oh, you can always take your product through NIST's validation process as an alternative. It's expensive and takes a significant amount of time, but might be worth it depending on the product.

With OpenSSL validated, that may change. The first change is that products like IP360 can implement a FIPS mode, allowing for greater distribution into government without increasing the cost by including a commercial cryptography module. It also means, however, that the barrier to entry for security products into the government space isn't quite as high anymore. Let's face it, the government can be a great customer for a small company. Often, however, they're a difficult customer to get, especially with security products, because of the number of certifications and regulations that must be met. All of this is good for taxpayers.

A side benefit I think we'll see is that FIPS validated cryptography will be used where it wasn't available before. This is interesting from a more general security standpoint. Standards are in place for a reason, but there are often exceptions for their implementation. By making FIPS 140-2 cryptography more accessible, it's likely to be more widely used, i.e. it becomes easier to implement it than to file for the exception. A general increase in the standardization and distribution of cryptography is good for security all around.

So kudos to NIST and kudos to the folks who dedicated so much time to getting this done.

Well, it's election time up here in the Great White North. As I wait for the election results to come in (our elections typically run very smoothly), I thought I'd kill some time by talking about Cisco IOS granularity.

First of all, please have a look at the following *excellent* diagrams; they are the Cisco IOS software roadmaps.

9.x -> 12.0: http://www.cisco.com/warp/public/620/roadmap.shtml
12.1 -> 12.2: http://www.cisco.com/warp/public/620/roadmap_b.shtml

Last but not least, I looked at this a fair bit too: http://idogan.istanbul.edu.tr/name.htm

Skimming through the links, the simplest IOS version string I saw was "11.0"; the most complicated, "11.3(4a)WA4(6.1)". Let's expand the range 'cos I think it's always cool to pick up old stuff too. If the roadmap sees fit to kick it off with IOS 9.x, then let's see if that's what the net thinks...

...after googling for Alfonso Ribeiro, I decided to get back to work. 10 minutes of searching here, searching there, and I was rewarded with a single tangible reference to a version 7. Saw a few references to a version 8, but more common still were those to a version 9. Similarly we see the map tops out at version 12, and an even lamer search than before turns up nothing in the v13 or v14 department. 12 is king.

So let's start to get a handle on the space. IOS version majors, with a fudge factor, going from v6 to v13. Number of possible fields in the version, with a fudge factor, going from 2 [# of fields in 11.0] to 9 [# of fields in 11.3(4a)WA4(6.1) plus 1]. There's the potential of manipulating alot of information dependent upon how you structure it or how, if at all, you handle slack space (product combinations that either can't exist, things very highly unlikely to occur, etc.).

Here's where it becomes a balancing act. Standard 'faster, better, cheaper: pick two' stuff.

Personally, I tend to like things that let me play with it all, to look at any bit of data sent back to me and then let me filter it out if that's what I want. Even if it's just an option - the system could default to a lightweight mode. Deals with alot of information and keeps a healthy chunk of state.

Or a lean process, purposely restricting our choices and abilities from the outset, slashing complexity too. Then we leverage the slack space and employ more clever optimizations. It's not as flexible, but it runs much faster, with all those implied advantages.

If it was asset management you wanted, then you'd want to know every single bit of version information. You can figure out alot of very useful information from the version such as product capabilities and as a result, maybe important topology information. But your concerns are going to be longer term; how often does this kind of info change? A couple hours, heck, a week or a month might not be time critical.

VM, on the other hand, is far more time sensitive. We've all heard stories about how quickly an unprotected Windows box dropped on the internet becomes compromised - minutes, folks. I'm sure that organizations with backbone nodes and people with honeypots/nets know the full score. Anyone in the military knows faster, more accurate intelligence is good. But there's gotta be a sweetspot - who cares about 11.0 vs 11.3(4a)WA4(6.1) when all you want to do is tell the difference between 11.0 and 11.3? Maybe those two fields and that one period is all that it's customary to care about, which is probably not a good excuse, although it wouldn't be a bad idea to find out why.

I'm interested to know what our customers think. And anyone else, of course.

p.s. Haven't thought about CatOS. That and whether any version string is telling the truth are subjects for another day ;)

Freedom fails because companies like Google and Microsoft, big companies, are more interested in money than in taking a stand. Yes, I've harped on this a million times before and probably sound like an alarmist nut, but it really bothers me. Not that censorship is a new issue, sadly.

Google: for a company that prides itself on being 'not evil' you sure have a strange way of expressing it. You should be ashamed of yourselves. I think we all know how I feel about Microsoft ;)

$20 says Google folds all the time and hands over information requested from your goverment and mine. As much as google is really useful and a good place to get a job (I hear), maybe it's worth some kind of protest action.

If I may borrow some lines of text from Martin Niemoller and the great Benjamin Franklin, it's these:

Then they came for me, and by that time there was no one left to speak up for me.

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.

We would do well to learn these lessons again that we have all too easily allowed ourselves to forget.

A bunch of us have been doing some work on Sendmail, and a side effect has been having to get ahold of old versions. We've done remarkably well - just when I think 'Ha, graver and dyn won't get to this vm today' I look at the spreadsheet and it's already done :)

Which reminds me, the other day I purchased a personal license for VMware 5.5.1. I'd hesitate to call it truly necessary in either work or personal contexts, but man.... our jobs would be... more interesting, to say the least, if it didn't exist. And at home I use some software for my rf scanner and gps units that I've purchased because even though it's windows based, the guys did a solid job and earned their keep, and the ancient copy of windows 95 that I still legally own happens to work ok if Wine won't cut it. Was windows 95 worth it? Well, I was into that at the time so I guess it was worth it, since it and NT introduced me to unix via FreeBSD, then to slackware ;) Ah shucks, definately worth it then!

I don't know if everybody would dig it, but now I've kind of developed a thing for old software. And we rescued a DG Aviion box that someone junked down the hallway, but it might need a new power supply. But anyways... someone pretty cool passed me this project link: http://www.mckusick.com/csrg/

It's probably something that a billion other people are aware of that I'm only just stumbling on now, but it certainly looks neat. It costs USD$99 which I don't have a problem with - hey Sheldon and Mike, let's pick up a copy - it's cost effective compared to us googling all day ;) Heck, there's one way to reduce dependence on google. Going to go grab one myself to play with at home!

Here's a list of what's on it:

CD-ROM #1 - Berkeley Systems 1978 - 1986
1bsd 2.9pucc 4.1.snap 4.2buglist
2.10 2bsd 4.1a 4.3
2.79 3bsd 4.1c.1 VM.snapshot.1
2.8 4.0 4.1c.2 pascal.2.0
2.9 4.1 4.2 pascal.2.10

CD-ROM #2 - Berkeley Systems 1987 - 1993
4.3reno 4.4BSD-Lite1 net.1
4.3tahoe VM.snapshot.2 net.2

CD-ROM #3 - Final Berkeley Releases
4.4 4.4BSD-Lite2

CD-ROM #4 - Final /usr/src including SCCS files
Contrib admin games local sys
Makefile bin include old usr.bin
README contrib lib sbin usr.sbin
SCCS etc libexec share

Well, in other unrelated matters, I have to get back to the process of making accomdations for dumping my ISP and cable TV provider (one and the same company). It's aggravating changing a personal email address that I've held for so long, but what can you do... once they dumped Usenet and I had to go with Giganews (and in a happy turn of events, totally worth it, Giganews has been great), it was the beginning of the end.

Now that I think of it, what we need is a blog entry from dyn about some of the binary reversing stuff I've seen him dabbling in and that he's talked to me about... that'd be cool and worth it too ;)

Anyone who's been to Defcon has seen the tables full of lock-picks and guides. I had ordered a set online a few years ago from an unrelated vendor, and was happily surprised to see that they passed customs and I wasn't carted off to our arctic gitmo or wherever. Listed on the manifest as, if memory serves me correctly, "hand tools" which although both legal and accurate, was amusing nonetheless.

Here's the secret of lock-picking: there is no secret.

Seriously. Everyone I passed my set to could pull it off in a reasonably short amount of time. My first serious lock took 40 minutes, it was the Schlage that locks the door from my house to the garage. A pretty good lock. My 2nd time: 20 minutes. 3rd time was 5 minutes.

I thought I was pretty bloody good! Until I passed it to my brother who halved the duration of the learning curve. Jen, a friend of ours, turned out to be some kind of a prodigy. Never having tried it before, she was cracking locks in 5-10 minutes (more often closer to 5 minutes) that sometimes took me an hour or two, and I had a significant head start on her.

There's a bunch of locks purchased from the local Home Depot that are kept around the office for anyone looking for a puzzle to do. Everyone that has tried, I believe, has succeeded with at least one. I like seeing other people have fun as well as seeing the knowledge spread that most security, physical or computer, is weak and elusive. Possibly most important of all, I now have almost everyone else's prints on the tools. Hah!

If a man can make it, a man can break it. That the man in this case is proverbial and can be of any sort (or gender!) is pretty sweet, eh? I love equalizing factors like that.

Sure is a nice tough looking lock and chain securing your bike, my friend... too bad it gives it up quicker than an Oracle database installation! (cut me some slack, Google and Microsoft are easy targets lately :)

[Before anyone wonders about lockpick legality, Federal law has this to say:

Canadian Criminal Code, [R.S. 1985, c. C-46]
PART IX OFFENCES AGAINST RIGHTS OF PROPERTY
Breaking and Entering
Possession of break-in instrument
351. (1) Every one who, without lawful excuse, the proof of which lies on him, has in his possession any instrument suitable for the purpose of breaking into any place, motor vehicle, vault or safe under circumstances that give rise to a reasonable inference that the instrument has been used or is or was intended to be used for any such purpose, is guilty of an indictable offence and liable to imprisonment for a term not exceeding ten years.

R.S., 1985, c. C-46, s. 351; R.S., 1985, c. 27 (1st Supp.), s. 48.]

Sometimes we spend so much time worrying about the protection of sensitive data from intentional disclosure that we forget about unintentional disclosure. All those layers of defense can, however, be circumvented by the simple human tendency to error on something like a fax number.

In this case, health care providers have been faxing patient information, banking details, medical histories to the wrong fax number. Instead of Prudential receiving this information, a company called "North Regent RX" got them. They don't want the data, but it just keeps coming. Prudential is in a tough spot because they aren't doing anything to *cause* this disclosure.

Maybe it's time to phase out the fax as a means of transmitting sensitive data. Old habits die hard, but sending patient data unencrypted should just plain be illegal these days.

Even though we work very, very hard to eliminate any unwanted intrusiveness of our product, nothing's perfect. I haven't done a bake-off of our product, but I'm willing to bet that we're as good if not better than most of our competition in this regard. That statement is irrelevant though - everyone suffers from this problem, and (jam your theory) I don't think it's anything that anyone will ever solve 100%.

As you can tell by a previous post of mine (http://blog.ncircle.com/archives/2005/11/vendors_please.htm#comments), I think there's alot of non-robust network stuff out there. In fact, let's scratch the 'I think' part; I'm happy stating it as a near fact. For whatever reason, people cram a stack into their product, test it within some too-restricted non-real-world parameters, sell it to you, and you hang it off your wire and hope for the best.

Do you think any of these companies deeply considered how it might have reacted in the wild? In a large enterprise environment, or on a net that sees tons of relatively demented traffic? I don't think they did.

Rather then blaming these folks for doing a half-assed job, let's try and find a solution. Obviously the most important thing they need to do is to strengthen and evolve their QA procedures. But we can't expect a relatively small 3rd party company to have a crazy lab to test this all in, can we? That's overhead they could do without.

What if we all created some kind of new 'Enterprise VM Tested' mark or designation that could be applied to products to let people know it's robust? Kind of like the 'Intel Inside' and 'Designed for Windows' warning stickers you see on computers.

What I propose is that we start up a vendor-neutral qualification company or foundation. We get as many VM type vendors and related tool producers as possible (nCircle, Qualys, eEye, Foundstone, Tenable, Rapid7, nmap, amap, etc) to front software and (where applicable) some gear. Then it all gets pooled and racked. A net is setup where vendors can come in and setup their equipment, and then using all this gear, we scan the living shit out of the vendor's device to see how it holds up. The key is *everyone's* gear; I don't want this to degenerate into a 3rd party bake-off company that becomes abused by any one company and perverted into a competitive sales tool.

Depending on how robust the vendor device is, then perhaps we assign a grade. Stats and metrics (pruned of info some VM folks might not want made public, though I think not being totally open is silly) could be supplied to assist them in fixing their product. Then they resubmit, etc, and hopefully get a passing grade.

I fail to see how this could be a bad idea; it sounds like everyone wins - customers, device vendors, and us.

I think those of us with the inclination should start learning Chinese, because when it's finally IPv6's time, I think it's going to be China leading the way. The USA might be the spiritual home of the internet, but the population and growth potential of China (politics and human rights issues aside) will be the strongest force to be dealt with, especially when they're pushing a new technology.

I'm sure some western countries have IPv6 initiatives, but we're at a disadvantage. We have tons of infrastructure already in place. We're well developed, and we have all the inertia that entails. I don't think China is quite as encumbered in that respect. Then I thought about Africa, and if it could finally heal itself and unite (and if we truly helped them out for a change) there is an even more enourmous potential there.

There is also something to the idea that the more internetworked the world becomes, the more we'll trade goods and ideas. Maybe when folks around the globe mellow out a little and smarten up, some of those ideas will take root a little more firmly. But if we can't even communicate, then we'll never have that chance.

Then there's the argument that hey, IPv6 is a probably a superior technical solution.

This all means that we need to start giving more serious thought to IPv6 capabilities, whatever your product is. Yes, give me wrappers and gateways so I don't need to ditch all my IPv4 stuff, but don't half-mile on the real IPv6 stuff. If we're gonna do IPv6 vuln management, then it's gonna have to be native anyways if we're gonna do it right.

This isn't something for far in the future folks... I was doing the rounds tonight and saw a post with the subject 'IPv6 capable Security Scanner' (http://archives.neohapsis.com/archives/sf/ids/2006-q1/0134.html) on the focus-ids@securityfocus.com list, of which I'll post the following snippet here:

I'm looking for a scanning tool that is capable of scanning IPv6 addresses for vulnerabilities. I briefly googled "IPv6 Security Scanner" and also checked out nessus.org to see if they had any documentation as to whether they supported vulnerability scanning for IPv6 devices, but didn't find anything other than a few IPv6 port scanners. I don't want tools that are just port scanners. I know nmap now supports IPv6, but I'm looking for something a little deeper than port scanning.

Only a matter of time.

[Edit: TK turned me on to this paper, very much related to the topic and quite interesting: http://www.cs.columbia.edu/~smb/papers/v6worms.pdf]

I have no idea who Bob Parsons is, but after reading http://www.bobparsons.com/dotcomscam.html I was just *steaming* mad. Yet again, Verisign are acting in a disgusting fashion. You should be ashamed of yourselves too, ICANN - why would you be a party to this kind of foul behaviour?

Some snippets from the article (I really hope this isn't true):

VeriSign wants to control the .COM registry forever.
VeriSign has somehow persuaded ICANN to propose a new contract where VeriSign will be the permanent and unregulated controller of the .COM registry. VeriSign would also get the right of presumptive renewal. This means when the new contract for the .COM registry comes up for renewal in 2012, it won’t be put out for bid – like the .NET contract was in 2005 – instead it will simply renew in VeriSign’s favor.

Plus VeriSign gets to raise prices without oversight!
But wait! There’s more. Not only will the .COM registry contract never again be put out for bid, but VeriSign will also have the right to raise prices, in its sole discretion, up to 7% per year in four of the next six years. So they can raise prices by up to 28% over the next six years.

What the heck is this? How can companies be allowed to get away with this, and more importantly, why do we let them get away with it? We need to stand up for what's right.

Seeing as I'm a Canuck, there's less I can do about this... but my American friends, you can do alot more than me! Go hit the link above, Mr. Parson's has provided a letter than you can use/sign and send to your governmental representative.

Let's give it to Verisign - they need a whoopin'! And while you're at it, write ICANN and tell them you're not happy with their role in this.

[On another note, this is the *exact* kind of reason why the internet should not remain under US control. The rest of the world has little or no input - it should be under international control of some kind, and it's infrastucture controls, technical and policy bodies should all be not-for-profit, and have open boards that anyone can be elected to serve on.]

I don't want to get into a political battle about voting technology, but there is a valuable infosec lesson to be learned by some recent conclusions. Basically, the group "Black Box Voting" sued Palm Beach county in FL to get the logs from their voting machines for the 2004 presidential election. They have now obtained said logs. There are numerous anomolies in the logs, which bring into question the validity of the vote.

The lesson here is two-fold. First, it is imperative that one have visibility into the operations of any system performing mission critical work. This is illustrated especially clearly in the case of public systems, but applies to enterprise networks. If your system is being managed by someone else, someone who is getting paid for the operation of that system, then they have no motivation ot advertise potential problems to you.

The second lesson is about understanding error messages. Some of the messages received from these machines ranged were:

SyErr 23: RC/AT Verify
Simulation not sim task
Card encryption bad
EEPROM failure
"Card Stuck" error

Some of these errors are fairly obvious. We can all imagine what "Card Stuck" means, but I'm just not clear what "RC/AT Verify" might be. It's a simple lesson: data is not information. In order to act upon any of these error conditions, you must both know about them, and know what they mean.

Tools cannot replace expertise, especially when something goes wrong.

I imagine it's obvious to most people by now that I don't like Microsoft. I have reasons for this aside from their illegal and immoral/unethical behaviours, and one of these is their approach to security.

So far, as a practictioner in the VM space (gah - now I've become infected with marketing-speak!) I don't see any practical difference in my day-to-day work as a result of this initiative. With the exception of XP SP2 of course, when people actually turn their firewall on. Which more people need to do, by the way, even though it will make our jobs harder. Nothing worthwhile comes easy.

Case in point: I'm currently (on my other monitor) looking at an instance of Windows Server 2003 Enterprise Edition running in VMWare. I've browsed through the menus to All Programs\Accesories\Entertainment...

Why is there even an 'Entertainment' menu section in a product described as 'Server' and 'Enterprise'?

Let's see what's in it... 'sound recorder', 'volume control' and 'Windows Media Player'.

Why is there a Media Player in a product described as 'Server' and 'Enterprise'?

Windows Media Player, as I'm sure you know, has had it's fair share of exploits. Let's say an admin or contractor is working late one night and decides to stream some music on your w2k3 Enterprise Server - and that you have an attacker who's been patiently waiting for this, who hijacks or attacks it somehow leading to control of your system.

Furthermore, since internal threats are almost always more dangerous, let's say you have a user who has limited access to the system. They craft a music CD that seems innocuous (especially if they're also packing a CD player), very easy to get into the data centre, and proceed to play it on your server, except it's a specially engineered 'song' that crashes Windows Media Player and elevates their privlieges. Or skip the whole CD bit - instead they have specially crafted MP3s on that USB dongle they always wear...

You see where I'm going with this, right? I don't care how good you are with managing the lock down of desktops and user policies. Sometime you'll miss something somewhere, like the best of us do. And really, how often have you seen windows policies applied to servers and server desktops getting locked down? Admins, at least the most senior ones, *need* full unrestricted access to boxes to fix certain problems.

What other tons of crud are there on this box that don't need to be there? How many of these are active, or for that matter, latent exploitation vectors?

Microsoft certainly needs to revaluate their architecture (divorce your GUI from the OS, you fools) and coding methods, as everyone does, but you've got to wonder if they're even capable of getting themselves into the right headspace to address the problem on the deeper levels it requires.

Two of the most important rules of security have clearly been forgotten by Microsoft:

1. A server should do as few things as possible, preferably only one.
2. Nothing should exist on a server except for what is needed to perform the tasks it is assigned.

Sure some *nix boxen come loaded down with tons of crap you don't need. But you can uninstall it. If you want a decent example of small footprint size and minimal software installation, check out OpenBSD. And if that's not good enough for you, you can always roll your own *nix distro. Take it to an extreme, and remove any dangerous binaries to a USB key that you mount on the box when you need to work on it.

I don't want to play the contrarian, but given a recent post, I think some balance is in order. Let me start off with a disclaimer: Microsoft is not perfect. In fact, I'm not a big fan. Of the 4 boxes I have within 5 feet of me right now, 1 of them is Windows.

On the other hand, of the millions of computers in the world, a very large (and somewhat unknown) number of them are Windows. They're not just Windows XP, or even 2000, but many Win98 and the fabulously frustrating WindowME. When looking at Microsoft's security strategy and progress, one must account for this context. They have the biggest marketshare in many markets, and they are a for-profit business. Part of the reason that MS products continue to be the realization of serious security incidents is that consumers continue to use them past an appropriate date. Part of the reason that MS takes so much of the blame is that they make so many products. Finally, they can't undue history. Thus, the introduction of automatic updates. Consumers can now set their system to update itself when updates are available. My FreeBSD box could do this, but only with significant work on my part to set it up. Then again, I don't want it being updated automatically...too many things break in the process.

There are other actions that MS has taken to improve security:

- Internal Security Focus

Ok, we can't see this one externally, except in the results. That's probably an argument for Open-Source. What's more, the data about reported vulnerabilities in products is hard to get and even harder to validate.

- MS Anti-Spyware Product

It's a free tool. In order to give it away, they have to understand at some level the effect that spyware can have on their business overall.

- Malicious Software Removal Tool

This is another free tool that MS has put out there to help customers keep their PCs secure.

- WSUS

For the enterprise, MS has improved the way that software updates are managed. Helping customers deploy patches is critical to preventing worm outbreaks.

I'm sure there's more to be said about how MS has improved the security of their products. Moreover, I'm quite sure that MS still has serious problems. They have tried, and continue to try, to find the right balance between usability and security because, of course, if the security functions aren't usable, then no one will use them. If the product isn't usable, then they go out of business.

I'd have to say this job is probably the coolest job in the world, with the possible exception of being a full-time mountain-bike tester or professional wine & cheese taster. And I'm not just posting this to brown-nose a better wage review for myself, as much as the reviews are indeed coming up ;) In no particular order:

1. It's almost always something new every couple of days. I'm guaranteed in the space of a month to have dealings with things I've never dealt with before. I can't stand being bored, and so coming to work can be like an art appreciator touring the Louvre. Via our customers, I get to see stuff that I've only ever read about in books or online. Sure, the idea of an Eniac that someone managed to hookup to their cat5 sounds far fetched, but I half expect to come across that some day.

2. Our customer's techs are smart. This means they often give us feedback containing very useful information, and sometimes it contains things I never saw before. Anyone who's ever manned a help desk knows the frustration that comes from people who can't adequately describe their problem. The higher the quality of an initial diagnosis, the less frustration all around and the faster it gets solved. The corollary is that we can't bullshit these folks either, so you find out pretty quickly when you don't know something... forcing you to then go and learn it, and you improve.

3. Hard problems. They're good because they're interesting, and I have a hard time learning things without a practical reason to learn them. Like my PIC programming adventure when I was unemployed - I had the chips, the eval board, all kinds of things... except a good project to build, and so it just sat there collecting dust waiting for me to do something with it. Today? I had to investigate reliable ways of DNS fingerprinting without relying on banners. Other times I've been forced to fire up IDA and reverse patches looking for ideas, and my Assembly is *way* rusty. One time I spent a whole two weeks troubleshooting HP printer crashes. Whatever doesn't kill you makes you stronger, hehe.

4. We have some big customers. HUGE numbers of nodes, and with that comes a whole other order of problems. I like small networks, don't get me wrong, but working on a product used for big nets is neat. Another great side effect of this is the opportunity for travel, since big companies are frequently located all around the world. I don't think you'd have this opportunity as someone who writes point-and-click tools for a /24.

5. The people. Everyone at work is cool. As for 'the scene', if you don't know some reknowned hacker yourself, you know someone that knows them. However feeble the connection might be, you're rarely more than one degree of seperation away from the best and brightest minds in the industry.

6. Could you imagine the kind of legal trouble one could get in if they wanted to play with these kinds of things at home, without being employed in the industry, and without any other course of legitimate access? This job is a chance to delve into these peaceful exploratory desires (the true nature of the word 'Hacker') without the risk of getting in trouble.

7. Bragging rights! I'm not as altruistic as I come across (pardon the arrogance of that statement), and it sure is nice to be able to shut up annoying intellectual types at parties when it comes to the "What do you do for a living?" question and you have a job that (a) sounds wicked cool and (b) implies you're probably pretty smart :) It really is hard to top! I was already married when I landed this job, so I can't comment on if it's a chick/dude/hermaphrodite magnet or not. Anyone?

I couln't resist borrowing the Fark headline for this story. McAfee released a virus dat file that matched a number of executables as the W95/CTX virus, and consequently deleted a number of quite useful files. Aside from being a relatively major mistake on McAfee's part, there are several interesting things about this story.

If you were running AV set to delete files automatically, then it's recommended that you restore from backup. Those would be *your* backups that you run. You do run regular backups, right? Despite the many, many lessons about backups that have been learned over the years, many, many organizations/people continue to stare potential disaster in the face every day. Maybe it's a display of courage, or a deep philosophical committment to the transitory nature of material objects. Maybe not.

Now, we all run agents. We trust these agents, and we give them extensive permissions to automate tasks that are tedious to perform manually, like complex pattern matching on large sets of data. This situation is a reminder, however, that trust must be verified. Even in an industry as mature as anti-virus, problems can still occur. I can't help wondering, along with some very upset customers, why McAfee didn't catch this dat file problem in pre-release testing. And I'm sure there's some admin out there who diligently tests new dat files before deployment rightfully patting herself on the back.

But perhaps there's a more interesting point here about ubiquity of complex computing devices. Here come some reckless generalizations; hang in there with me, ok? The computers need an agent because they are prone to viruses. They are prone to viruses because they contain applications with serious bugs. Viruses get written for these bugs because there is a target surface of sufficient size to make it worthwhile. What I'm getting at is that the need for agent based controls on these devices is predicated on the risk they exhibit. <insert plug for vulnerability management here>. Taking this beyond VM, though, one can ask the question: do all these computing devices need all this software? The connection between patching and reducing target surface is pretty clear, but there is also a connection between eliminating applications and reducing target surface. It's gotten to the point that one is hard pressed to really know for what purpose each application on a host exists.

There are a few interesting options out there for implementing multi-user systems. There's the somewhat old-skool approach of *nix and remote X. There are corporations like Citrix that offer somewhat less efficient, but MS Windows(!) based, options. One can also look to the whole *sigh* "Web 2.0" trend for interesting solutions. Imagine if all the average workstation needed to run was a browser. Eliminating office applications, email clients, media players, instant messaging, etc, etc from each individual desktop substantially decreases the target surface. Centralization of such applications would, of course, dramatically increase the impact of a compromise, but it also reduces the cost of administration by centralizing patching and maintenance. Of course, all of these solutions require ubiquitous, abundant, and reliable network connectivity. Nonetheless, interesting possibilities abound, much to the agent-vendors' disappointment.

What exactly do Consultancy and Analyst firms offer when it comes to security? It seems to me the main purpose of these organizations is to either tell people what everyone else thinks, or to help people make up their minds for them. And by 'people' I mean the higher ups in companies, probably the ones in control of budgets. No one I know that's 'down in the trenches' pays attention to consultancy firms. The firms, it seems, either tell you what you already know, or are hyping something for reasons that I feel are of a profit-motivated, and therefore questionable and non-trustworthy nature.

I think consultancy firms are a blight on security for several reasons. Let me list my thoughts here:

1. Your in-house people are your best resource and usually know the most about what you really need to do anyways. Why spend money outside of your business when you can leverage your own people? You might have a guy working your helpdesk right now who could be a single-sign-on or security guru on the side and you'd never know. It's like bringing in someone from another town to study the quality of life in your own village... why not talk to the people that already live there and are intimately familiar with it?

Result: You ignore the incredibly valuable resources already at your finger tips. You spend money you don't need to. You risk losing valuable people that you should keep in your company.

2. They're no doubt beholden to larger businesses that supply the products they're asked to consult upon. Why would you trust a company to tell you about a free software product when they make far more money selling studies on Windows? Why trust a Linux company to tell you about Linux? Drug dealers aren't going to tell you that drugs are bad, ya know.

Result: They're more interested in selling you their services than they care about your security.

3. By relying on 3rd party 'experts' you are reinforcing the habit of not educating yourself. I think you are lacking the requisite sense if you don't read up and educate yourself on the the topics you'd be approaching these 'experts' on. If you're going to be asking people questions, you need to know how to understand the answer enough to know if you're getting played.

Result: They're more interested in keeping you dumb so they can keep making money from you.

4. What does a consultancy care about your business? You pay them and they leave. And you probably pay them too much as well. Perhaps outsiders do offer the advantage of a disinterested 3rd party free of politics, but chances are they're being brought in because someone higher up the corporate chain knows someone in the company or has used them before, or is using them because that's what everyone else does. Or because this person hopes that the consultant will pass their or the company's name around to other companies.

Result: The 'old boy network' grows and stifles useful and less expensive innovation. You effectively outsource some control of your company.

4. What does a consultant know about your network? They don't work with it every day. They don't know it like you do. A good admin knows their servers and network like they were a family member. Would you bring a consultant in to tell you about your spouse/life-partner and how to improve them? If yes, then you got some problems.

Result: You ignore your inside people (your best resource) and you spend money you don't need to.

6. Consultancy and Analyst firms help breed a culture of expertise-for-pay and information hoarding. I don't like this; everyone has a right to knowledge and if we're going to make the world a more secure (and better) place, everyone needs to know something and everyone needs to do their little bit. To do this, advanced knowledge needs to be distributed as deeply and as widely as possible across as many people as possible.

Result: People know less, and become less capable of taking care of themselves and their business, and security degenerates.

Here's what I suggest:

1. Before going to a consultancy or analyst, whether you're a helpdesk dude/dudette or a CIO, RESEARCH IT YOURSELF. Either that or find someone who looks like they don't have enough work to do and ask them to look into it.

2. When you research something, do the following:
A) First off, search the net for community mailing lists or where users of the product/service you're investigating hang out and see what they have to say.
B) Ignore anything from a Consultancy firm, Analyst firm, or any media site owned by a big company.
C) Use multiple sources, preferably more than 3.
D) Do the "google + bad" and "google + s**t" tests (you know the s-word I'm talking about!)... for instance, if you were thinking of buying a Foomatic widget from XYZ Company, head to google and search on "XYZ foomatic bad experience" and "XYZ foomatic s**t". Don't trust these results right away, but read them over and keep them in mind. This makes for a quick check to help develop your critical eye.
E) Then consult the vendor site for information. Make sure you consult their competitor's sites as well.

3. If you absolutely have to go to a Consultancy or Analyst firm (and you never do) talk to your own people first. Always talk to your own people first. Did I mention you should talk to your own people first?

Well, that's it for me... remember "Those who can't do, teach... and those who can't teach, consult" ;)

[edit: I censored a couple swear words]

If you're part of a business that has anything to do with financial data, you should pay attention to this law. The "Financial Data Protection Act of 2005" just passed the House Financial Services Committee yesterday in a 48-16 vote. Now I usually find these kinds of legislative discussions tedious. I've already referenced a bill by number, quoted a vote count, and mentioned a specific committee. This is about the point at which I usually start to drift off, but I promise fun and excitement in the next paragraph, or maybe the one after that.

We're all familiar with state laws around disclosing breaches that affect consumer data, like California's SB 1386. H.R. 3997 is a federal bill that aims to unite the disparate disclosure laws into a uniform standard. Everyone in infosec likes standards, as long as they're good standards. This bill is not, in my opinion, a good standard. It suffers from what I will call "The IDS Syndrome."

When IDS was introduced, it was looked upon as a wonderful new technology that would allow us to see when bad people attacked us and stop them. The problems started when organizations began to realize that attacks were occurring all the time, at fantastic rates far greater than our capability to react to them. The IDS delightfully delivered this over abundance of data as we, the security industry, tried to figure out how to turn it into actual information. Ultimately, most organizations (and IDS vendors) began a process called 'tuning' in which one tries to make data useful by not collecting some portion of it. To some extent, this works, as long as the selection of data to not collect, i.e. signatures to turn off, is made with great care and some luck. The minute a successful attack occurs for which one is not looking, the strategy falls apart. Of course, the strategy also falls apart if one can't effectively respond to the events that are being collected. Hello rock, meet hard place. As the tuning becomes more severe, the IDS becomes at once more usable and less useful.

And this is where we come to data breaches. They are, in many ways, both literally and figuratively, just like IDS events. It seems like a reasonable idea to require businesses to report all breaches, until you realize how frequently breaches occur, and that many of these breaches don't constitute harm. And so begins the process of 'tuning' the legislative requirements for disclosure. Consumer advocates argue that any breach which compromises data about even a single person constitutes harm and should be disclosed. Businesses argue that such requirements aren't feasible, can't be supported, and cause harm to the business itself. Hello hard place, meet rock. In the meantime, we all become de-sensitized to the number and frequency of breaches.

The de-sensitization has the same affect here that it had with IDS events. We no longer consider a data breach a significant event. We get used to the idea that they happen all the time. We *decide* that serious harm rarely results. We continue to increase our threshold for disclosure of said events. But this is not how things should be!

The problem here is that the legislation requiring disclosure is being used as negative motivation to reduce the number of breaches (i.e. improve data security). This approach simply won't work, and results in legislation like H.R. 3997 where consumers lose out. If information about my bank account is stolen, I want to know about it. I don't care how many other accounts were compromised and I don't particularly trust the business in question to determine if the breach is "reasonably likely to result in substantial harm or inconvenience" to me.

A better approach, and one that is also taking place, is to regulate the storage, use, and communication of data. Legislation like HIPAA and standards like PCI go much further, flawed though they may be, towards having a concrete effect on the frequency of data breaches.

Ultimately, we come back to the IDS comparison, adding in Vulnerability Management. IDS, like disclosure laws, will always be reactive. By nature, they must wait for the event, either an attack packet or breach, to both occur and be detected. HIPAA, PCI, and the like get ahead of the event curve, as does Vulnerability Management, to reduce the target surface and therefore the likelyhood of bad things happening.

I've been seeing a fair bit of buzz about Web 2.0 applications. Some examples are things like Basecamp and Backpack from 37signals. There are others, like the recent google acquisition, Writely.

People *love* these applications. They're lightweight, usually free/cheap, and well-designed. The 'well-designed' part is really important to their success. Here's the thing, though. I think people are confused about the difference between content in their browser and an application on their computer. People can explain the difference well enough, but cognitively, they don't behave as if there's a difference. And the more these web-based applications (and that's what they really are) move closer to the functionality of local applications, the less that distinction is apparent.

Why am I worried about this? Isn't this the new Internet, where you don't have to install applications anymore and all your important data persists even if your laptop doesn't? While that is appealing, I can't help worrying about privacy, and I worry more about it as businesses consider more 'Web 2.0' applications. There are some recent events that have brought these concerns to the forefront of my mind.

Citibank has been dealing with a PIN theft problem lately. It's been called the "Worst Hack Evar!!!11!!1" or some thing close to that. The issue, it seems, is that some software for processing ATM transactions has been storing PIN and account numbers when it shouldn't. Lesson: your data is not yours. Whenever you perform an action online, you give away that data. Send an email, make a web request, buy something; all of these actions give some data to another entity. You may still be the owner of that data, but you're not the custodian. Now, imagine if that paradigm extended to every document you created (writely), to do lists (ta-da lists), projects (basecamp), development plans (backpack).

But what if you trust the company that has become the custodian of your data? Well, clearly, theft is not about trusting the custodian. There's a longer chain of trust there, and it starts with your ISP and continues through the custodian's offsite backup partner. That's one problem. But there are also ways in which your data may become the government's data. Thankfully, Google was able to avoid turning over a substantial chunk of search data to the government, but they're not the only providers subject to government supoena. "The government already has received an undisclosed number of search requests from three other major search engines that complied with a subpoena issued last summer."

Again, back to the web-based application and your data. Both writely and 37signals address security in their respective web sites, but text is only text, not assurance. How do I remove my data from their services? What about from their backups? If they offer the option, how do I *know* it works? Unfortunately, I don't have the answer here. I'm not sure how an online, on-demand type service can provide adequate assurance for the paranoi...er...concerned consumer and the average business.

So Microsoft is planning on releasing "a pre-patch advisory with workarounds for a 'highly critical' vulnerability" as per http://www.eweek.com/article2/0,1895,1941507,00.asp

Way to go on your total security initiative, Microsoft.

I've said this before... what's the point in having monthly releases? It should be obvious to everyone with a good understanding of security that patches and fixes should be released the second they are ready. Yes it might make people's lives easier, but that's not a good enough reason. Not at all.

Any kind of delay is bad, and Microsoft has effectively admitted it by this intended forthcoming patch release. So I say it's time to give up this once a month nonsense. Things should be fixed as soon as they can be. Bunching up all your fixes and releasing them in one big wad once a month is silly and a denial of reality.

Whenever you subvert security for convenience, you increase your risk.

[Edit: I want to clarify something... I'm saying that MS should release patches as soon as MS has a fix for them... let the end-user/Enterprise decide when to apply them. I don't want to wait 30 days for a fix if they found it on day one, just 'cos of some arbitrary once-a-month schedule. Put the fix out ASAP, and let people decide when to apply. After all, it's not like 'sploits get batched up for a monthly release...]

It's a common practice for customers to perform what we call 'bake-offs'. A bake-off consists of a side-by-side comparison of competing products. Generally a pretty good idea, but it's just one piece of the puzzle. While it seems like it's an apples-to-apples comparison, that's not particularly meaningful - are you comparing 'eating' apples, or 'baking' apples? Silly comparsion, yes, but when you've ruined a few apple pies as I have, you come to understand that these differences are important. And to continue the metaphor, if you've already bought a truckload of the wrong kind of apples, you've got problems.

We've won some deals and lost some deals based exclusively on bake-off results. When we win we win on precision, when we lose it's usually because of coverage that relates to a "maybe" result.

Of course, we've set ourselves up to take this kind of a hit because we believe it's important to know whether you ARE VULN or are NOT VULN. Try stacking that up against another product where they report "You're vuln to X, not vuln to Y, and Maybe vuln to Z". If you're a customer, isn't it all about confidence in the results?

Guess what happens after you're stuck with all these hidden "maybes"? You now have to manually remediate them, or worse, turn them right off, which goes against the whole purpose of purchasing the product.

nCircle isn't perfect, but we've put our hearts and souls into philosophically providing customers with information they can use. You buy our stuff and want confidence in the results. Do we mess up sometimes? Yes. It is fundamentally impossible to be perfect and/or completely secure - anyone who says so is just plain wrong.

Don't play this bake-off numbers game nonsense. Demand a quality of information that gives you the confidence you need. If that means you wind up buying a competitors product, then so be it. You've made an educated decision and you know what you'll be getting for your money.

[Edit: I rewrote the entry based on constructive feedback from a team member who's been taking some writing courses. I think it sounds better. Also corrected the abominable grammar of the title.]

I don't care much for spam and phishing scams, but I've pretty much given up on the notion of seeing either eliminated during my lifetime. I'm focusing on mitigation now, and for sometime I've been pretty satisfied with the spam filtering in Thunderbird. Especially on days like these where I'm catching up on what seems like thousands upon thousands of messages.

Today, however, I got an email of a format and tone remarkably similar to the archetypal Nigerian money-laundering scam. Having slipped through, it caught my attention. Looking deeper it turned out to be of a much higher calibre.

It was addressed to me personally, which is surprisingly rare, but what shocked me was that it appears they performed a genealogy lookup on my last name and worked details of it into the body text. Now granted they wound up picking a branch of the family unrelated to ours, but it could've been closer, I think. Much like the info I turned up during searches on my family myself; it appears they weren't making stuff up.

Now the phishers could be getting smarter for multiple reasons; foremost to get through spam filters, but increasingly to improve their chances of luring a sucker. Perhaps they did a manual search, putting details into a data file that in turn was used to generated the emails. But I'd prefer to think they're smarter (never underestimate your enemy!) and have coded up all kinds of data mining and spamming tools. It never occurred to me that they'd leverage genealogy information to improve their chances, but it seems obvious now. I thought they'd stick to the "250 million emails a day and even a blind squirrel can find a nut" shotgun approach for alot longer.

There's alot of info about you and me on the internet, and probably just as many shady and corrupt businesses that'd be happy to fork over the details of your life for cash. Looks like the phishers are starting to get smarter sooner than I thought :/

Some folks out there might not be aware of something called the 'Antisec' movement. I don't know enough about it to state the size of it or the organizational structure, but I suspect it's not particularly large or well organized. If I had to guess I would say it is a mirror image of the hacker culture that it is a part of; loosely organized, chaotic, and flexible.

But it appears to be unlike hacker culture in a very important respect: they want to keep information secret. Without digressing into the problems of defining the word 'hacker', suffice it to say that I'm using it in its first, proper and pure sense: a person who loves exploring and gaining new knowledge.

I've been trying to figure out the motivations of the Antisec movement. It's not as simple as it might seem because the issue boils down to philosophy. And when you get that low level, minor variance in thought can be a world of difference (Look up the Athanasian and Arian schism in the early Catholic church if you want an illustrative example).

I admit at first I wanted to get on this topic because the whole idea of the Antisec movement bothers me. I believe (with some exceptions for personal information) that information should be free. Especially anything of a scientific and technical nature. I don't respect people that discover info and keep it 'close to their chest'; 0 days should be put out as soon as you find them. Embarrassing people into action is a function of a free press, I think - so when you take information and confine it to a small cabal of people, you're slowing the progress of the human race, whether you like it or not.

Then I read the "Stop aiding an industry which just hurts humanity" article at this url: http://antisec.wordpress.com. I don't agree with all of it, but they did make an interesting point. Security can be used for oppression. We can see it in totalitarian regimes such as China, and too many other places. Sadly, North America seems to be creeping ever closer towards a corporate driven police state so it does bear heavily upon us to keep this issue in mind if we want to preserve our shrinking freedoms. The author wasn't necessarily writing about something in a far-away land.

Otherwise, I think the author is wrong. Security, in my mind, can be treated as a tool. It is neither good nor bad in and of itself. It is the motivation of the human wielding it that makes the difference, and the results that human achieves. Much like people that that say silly things such as knives and guns being bad. No, they're not. They are impotent lumps of matter that do nothing until someone picks them up. Security is similar. That same encryption that lets people hide sick trash like child porn is the same encryption that lets political dissidents in countries fight for freedom and smuggle their families to safety. Just like a gun that kills someone during a robbery could be a gun that helped bring the USA it's independence.

As for people that bemoan the commercialization of the security field, I'm still rolling that one over in my mind - not entirely sure what to think. I can see why people might think it sucks, but it's also been good in some ways. There's alot more people in the field now which means that there's alot more friends to be made. Alot more knowledge to be produced. And alot more stuff to be hacked and challenges to be had! Now that there's more and more cash in this space, look at it as a new Golden Age! There's going to more tech coming, faster than ever. More exploration to be done - how is that a bad thing?

Sometimes I think the whiners in the Antisec movement might be the criminals bemoaning the loss of tools and information that made it easy to steal and behave in a dishonourable fashion. I guess if my identity and/or income were derived from lameness such as selling 'sploits for cash I'd be upset. I guess if I defined my whole sense of cool by having more 31337 info than some other dude in IRC, I'd be upset. But that's juvenille. If you really care about Antisec from an honourable and philisophical perspective, why aren't you making tools that fight against oppression? Why aren't you breaking into networks and securing them? Why aren't you making the world a better place? Pretending to be one of the authors of CANVAS and posting to our blog as an agent provocateur, to discredit someone or start a fight is weak, dude. You can do better.

Antisec folks, please stop attacking people personally. It's weak and cheesy, and only makes people want to fight harder against you.

... at http://www.ncircle-users.org/forum which is not under our contol nor affiliated with us. It's a great place to talk tech with other users and ask questions. Check it out.

Came across this article about one of the more awful pieces of anti-freedom legislation (other than the Patriot act) I've seen in my lifetime...

http://www.eff.org/IP/DMCA/?f=unintended_consequences.html

A snippet from the article's conclusion paragraph:

Years of experience with the "anti-circumvention" provisions of the DMCA demonstrate that the statute reaches too far, chilling a wide variety of legitimate activities in ways Congress did not intend. As an increasing number of copyright works are wrapped in technological protection measures, it is likely that the DMCA's anti-circumvention provisions will be applied in further unforeseen contexts, hindering the legitimate activities of innovators, researchers, the press, and the public at large.

Please give the article a read, and if you can spare some cash, considering donating to the EFF. More importantly, start taking folks seriously who protest against these kinds of laws and the all too likely abuses that will follow. They're usually right. The world doesn't need more laws.

Being the man of peace, moderation and reconciliation that I am, I thought I'd kick off a small debate.

I hereby submit that writing vulnerability checks is not the same as finding exploits, that the skillsets (while overlapping) are not the same, and that a person well suited for one task is not necessarily good at the other.

First off, let me state my personal bias. I think, all things being equal, it's harder work to discover vulnerabilities and write good, effective exploits for them. At the same time I must confess that it can be quite a challenge to write checks for vulnerabilities, specifically non-invasive ones that revolve around fragile daemons or services. Realistically, invasiveness isn't a boolean quantity; I would submit that it more properly exists along a continuum. And in my world, I define invasiveness as the degree of manipulation of the target's memory space.

When you write exploits, you're not as concerned with knocking over or crashing things - in fact, that might be the first vector you discover that begins the whole process of writing an exploit. Contrast this with writing a check for a VM appliance or program, where an invasive check could well crash a pile of machines and cost a company uptime and money. I would think that this inculcates in the vuln check writer a tendency to prefer techniques based on inference. Contrast this with exploit writers, where the work is just about as direct as can be, and thusly more suited to brute-forcing techniques.

I would liken it to the skills of a Doctor versus those of a Surgeon. Both are highly skilled. When you go to your GP and tell them you aren't feeling well, they don't slice you open looking to see what's going on. They ask questions and attempt to collect and correlate symptomatic information to determine your condition. At the same time, when you know that something is totally broken and you want a specific outcome, you go to a surgeon who gets right into your guts and manipulates them.

Or, in other terms, vuln check writing is more of a 'strategic' pursuit, whereas exploit writing is more 'tactical'. If we (for the purposes of argument) associate 'exploit' writing with attacks, and 'vuln checks' with defence, then this premise is backed up by the empirical observation that an attacker only needs to be succesful once, whereas a defender needs to be successful *all* the time to avoid security breaches.

I've never been a big fan of certifications. I have several reasons, the prime one being that I've seen too many clowns hired that have certifications and who didn't work out. What exactly does a piece of paper mean anyways? To me, it means you're good at passing tests, and that's about it. People tend to hide behind their certifications far too often.

When I worked for Compaq/HP on contract to the UHN hospitals in downtown Toronto, we hired a contractor one time who had an MCSE (I'm not purposely singling out this certification for ridicule; everyone knows about it). Now this was a very heterogenous environment; windows, netware and unix. So we sat the guy down at a console, he browsed the network, and the next question he asked was "What domain are your Netware servers in?". Needless to say, he didn't last long.

Therein lies the problem: certifications are about as far from holistic as possible. They train you for specific tasks and that's it. But that just doesn't work - the world, and technology, is an incredibly fluid place. In my opinion, we don't need to teach people technical skills as much as we need to teach people how to learn. I'm not sure it's something that can be taught to everyone either. Some people are just hopeless. I would suppose you either have it, or you don't.

I realize that a large part of the problem stems from the need to have an objective way to measure a persons suitability for hiring. But that's a nonsense goal; it sounds good, sure, but it denies reality. There's no effective way to tell how someone will work out when you hire them. The best you can rely on is indicators, and an extensive interview process. When we've hired people here, the ones that work out the best are the ones who have a passion for this kind of work, who run hobby systems at home and hack code for fun on their free time. Tell me: how would you certify this? You can't, and you shouldn't even bother.

Certifications make people lazy; both the applicants and the folks that hire them. There's just too much nuance when it comes to technical positions, the personalities of people vary too widely, for the process to be made the responsibility of HR departments. If it is, then people become boxes in search of checkmarks. You will lose good people just because someone lesser had one more arbitrary box with a checkmark in it. Maybe for large companies it might work (for no other reason than issues of sheer volume), but even then, I'm sure that old school hiring procedures account for the bloat and monetary sinkholes that their labour pools become.

Looks like other people might finally be waking up to this:
http://www.eweek.com/article2/0,1895,1954198,00.asp?kc=ewnws042706dtx1k0000599

I love this quote "Perhaps more to the point, they are finding other qualities of IT professionals more critical to their businesses going forward, and they are willing to pay more for those.".

Duh.

[Edit: replaced 'Novell' with 'Netware' to make it clearer]

..the hackers and crackers are busy writing code and working on new techniques. Folks are putting up botnets and spammers are working on evading filters. Sony/BMG and other media firms are working on more DRM tech, proving how much they disrespect you, their customers. Google, Microsoft and Yahoo are busy folding like cheap suits over human rights in China, and our governments are busy mining data and chipping away, ever steadily, at the rights we enjoy. And we are letting them :(

Like any kind of media, blogs are better at propagating the same old information that everyone's talking about rather than new, cutting edge information. How many people are reading and writing blogs, and how many people are actually going out and doing something? How much could have been done had I never wrote, and you never read, these entries?

Stop watching TV and go secure your systems. Go help someone who needs it, then go and do some coding. Go out there and make a difference, do it with your own money, and do it without expecting payment or the accolades of your peers. Do it for a stranger who will never know who you are.

..is something that lets me plug in a UUID and tells me exactly what it represents. Without the HUGE list of UUIDs we've compiled here it would be slow going. Still, it's not uncommon to find a UUID that isn't listed anywhere in google, on the MS site, or in the registry.

Especially when they're present in information exposed via RPC... Is there some reason for avoiding annotation for these, or did someone just get lazy?

A gentleman of the handle 'Batz' (not sure if he wants his real name used) that used to work here at the nCircle Toronto office talked about this idea a year and a bit ago. I thought it was brilliant, and was a nice fusion of ideas. I would have talked about it a long time ago, but I wanted to give him time to develop the idea. Oh, and I guess we had no blog then either.

Another dude by the name of Marshall Beddoe put out a PDF entitled "Network Protocol Analysis using Bioinformatics Algorithms" some time ago. You can dig up an HTML cache of the PDF here: http://www.google.com/search?q=cache:gc6fEO_vyJgJ:www.baselineresearch.net/PI/pi.pdf+pi.pdf+beddoe

If I may presume to copy in his paper's abstract:

Network protocol analysis is currently performed by hand using only intuition and a protocol analyzer tool such as tcpdump [6] or Ethereal [7]. This paper presents Protocol Informatics, a method for automating network protocol reverse engineering by utilizing algorithms found in the bioinformatics field. In order to determine fields in protocol packets, samples are aligned using multiple string alignment algorithms and their consensus sequences are analyzed to understand the beginning and the end of fields in the packet. For illustrative purposes, this paper uses the common HTTP protocol as an example of a “blackbox”protocol as it is comprehensive and easy to follow. While HTTP is a plaintext protocol, the same principle applies to any byte stream that contains structure.

This is an exceptionally cool idea, and the paper gets more in depth. If I remember correctly, when his site was up (www.baselineresearch.net/PI) he had some code as well.

Now consider the idea of covert back channel communications. One example might be hiding a communications stream in the payloads of ICMP packets. People looking for common communications protocols might only be keeping an eye out for irc, http, or various IM clients, thus letting ICMP sneak by. There's a number of tools out there that implement this technique here (not specifically in ICMP, mind you) http://www2.packetstormsecurity.org/cgi-bin/search/search.cgi?searchvalue=covert+channel&type=archives&%5Bsearch%5D.x=0&%5Bsearch%5D.y=0

The hypothesis, in a nutshell, is this: by putting data streams through analysis techniques employing bioinformatic algorithms, covert communications channels may be revealed.

For instance, if we put a bunch of ICMP traffic through the analysis and we see structures where there shouldn't be any, that might be a covert channel. Imagine you are a financial house or trader and seeing structures indicative of an IM protocol in areas where they shouldn't be... perhaps payloads, sequence numbers, whatever. The nice thing about this is that it would appear to work on just about any structure; you don't need to specifcally keep an eye out for one protocol. Of course the interpretation is still up to the user.

Now what if someone created a gateway appliance of some kind that compared everything going through it, looking for what it SHOULD be carrying with what it is ACTUALLY carrying. How often might we see something interesting? I wonder...

When I think about security I find it hard to divorce from it the concept of control. In other words, how can you secure that which you do not have control over? The answer is Trust, something without which the world wouldn't function... but I see it being taken to extremes that bother me.

To be perfectly clear: I fully believe in and love the idea of being able to trust people. It's a beautiful thing. And I mean flesh-and-blood people, not the entities of corporate personhood. True and proper trust, in my mind, can only exist between real people.

So it amazes me that the control of sensitive information is farmed out to 3rd parties. I would never let a security company take responsibility for the offsite scanning and storage of my vulnerability and security data. Clearly other people are comfortable with this. Still, the thought that I've given a 3rd party a vector into some of my most sensitive areas would bother me. Even if I did trust them, what's to say that someone might not infiltrate the company and sell off the data? Or behave like phone companies in the USA that are falling over themselves to give data about you and your communications to the NSA without oversight... who knows where and how this will end up being used?

I see another product in use that just baffles me... it's a sales and support tool that is accessed over the web. It can contain information about sales in progress, bookings, and money made. Not to mention customer bugs and issues. I really can't believe people are so motivated for quick and easy management of these resources that they would let a 3rd party provide and maintain the infrastructure for this. What if their servers or network goes down? How do you get to your data? How do they back it up? You're taking their word for it, although I'm sure they offer a guarantee. But guarantees are USELESS - all a guarantee means is that someone will offer you cash if they mess up. Not good enough.

I don't want cash, I want my information whenever I want it however I want it.

If you want real security, then you need to start moving your stuff back in-house, where you can pay your own people to take care of your own data. It's not perfect, but it's better than farming it out and ceding what little control you do have to someone else. Put your data in a place where it has only one master.

Wonder how Matsano will disagree with this, hehe :)

Look, I'm thinking out loud here, as I do in all my posts. I don't sit down for days planning what I'm going to say and I wear my heart on my sleeve proudly. This means that I'm allowed to engage in hyperbole, as is evinced by the topic of this post :) Read past the words and think about what I'm saying... for instance, this post obviously isn't just about Microsoft, and I don't believe in a red skinned dude with cloven hoofs carrying a pitchfork either. Yeesh - too many of you take me more seriously than I take myself.

So why is it the devil? because it's EASY. Making things 'easy' sounds like a great idea. Why shouldn't things be easy - why can't my grandparents just sit down and send an email without learning all kinds of stuff not directly related to the task at hand? Things must be easy or no-one will buy them, I guess. Sad really, as people are intelligent adaptable creatures designed for learning new tasks. Your grandparents might have problems using a computer, but try going back decades upon decades ago and using something your grandparents thought simple, like a sliderule. It's kind of nasty at first, but quite easy to adapt to after a short while. All it takes is time.

What the heck does 'easy' mean? It's too often employed as a subjective adjective... there's no universal 'easy' scale by which to rate computer use tasks. Redefining 'easy' as 'has a low entry barrier' doesn't help either - meet the new boss, same as the old boss. I think since no one can define what 'easy' means, people go out there and try to make things as easy as possible. Stupidly easy. Dangerously easy. Dangerous in this case meaning doing things you didn't want to do (whether you knew it or not) and not being able to revert to a safe or comfortable state afterwards. Guess what happens when you design an OS and applications for users that are computer illiterate...

Why aren't I ragging on Apple and the Mac? Well, honestly... it's market share is insignificant as far as I'm concerned - it simply doesn't possess the critical mass to do the damage that Windows has done and continues to do (although most Mac people I've encountered are still not educated enough to know that 'PC' doesn't have to mean 'Windows'). When Macs are 90% of people's computers, then I'll devote more thought to them. Not to mention that there's alot less people writing crappy software for Macs than write crappy software for Windows.

Windows has made it too easy for clueless incompetent people to advance themselves into areas where they have no business being, as there are no effective entry barriers to its use.

Microsoft has insisted on making complicated matters very easy for users to do. They have their usability lab (or whatever it's called), which sounds like a good idea but is part of the problem since it gets paid too much attention. They're letting their users teach them too much, and I don't think they're doing enough to teach their users in return. They have slowly, but surely, been breeding a generation of incompetent computer users, and not necessarily by design. It's the same problem I see with driver's licenses up here... people are driving cars and they seem to have a poorly formed idea of how to be a good guy and share the roads nicely with other folk, much less how their car works. They won't change as penalties for these behaviours are not not strong enough nor visited on their heads nearly as often as is needed to drive *real* change.

Some stupid GUI util or a screen that pops up telling you "You shouldn't do this!" is NOT good enough. The problems are far, far deeper than this. Windows needs better users more than it needs better code.

This is how I see it, simplistically:
-Knowledge is Power
-Power is the ability to shape your environment to your will
-You need knowledge to address security issues
-Therefore anything that hides knowledge from you reduces your power, reduces your ability to shape your environment to your will, and reduces the ability to address security issues.

When things are made simple and easy, it's only because you've forfeited your own power... but this same power is what you need to fix things. Guess what? There's no way out of this until people learn how to operate things and fix them themselves, for themselves. Either that or they'll have to resort to exchanging goods, services or money in exchange for said expertise. Either way, people need to stop whining about security being difficult and hard for users, because they put themselves in that position by their own action. It is hard (in the simplest of ways), it should be, and it's not going to change. Suck it up and deal with it people.

Just watch - Microsoft is fixing all kinds of security issues and has wonderful ways of solving security problems, but these will be perverted, weakened or turned off outright because it bothers the users too much, and makes life hard, and means the company won't make as much money. Of course, Microsoft will fold when it comes to this and then it's back to the same old same old.

I should really be blaming the end users... it's hard to blame the butcher for selling what people are buying.

This is my first post to the VERT blog. Actually it's my first blog post ever, anywhere. So to kick off, I wanted to share something interesting and thought that describing the evolution of a fairly complex vulnerability detection rule and the things I discovered while writing it would be a good start.

Let me preface this by saying that I learned a lot while writing this rule. It was my first remote using DCE/RPC over SMB and part of why it took as long as it did (a week or so, total) was that I was refining my research and development skills while tackling this problem.

So, that said, the vuln in question is the infamous LSASS weakness exploited by the SASSER worm and others. For anyone who doesn't know, credit for discovering the vulnerability belongs to the research team at eEye Digital Security. This discovery was a watershed moment in patch management due to the short time elapsed between vulnerability discovery, patch release, and subsequent exploitation.

A bit of history:
- eEye reported the vuln to Microsoft on Oct 8, 2003
- MS patched with MS04-011 on April 13, 2004.
- houseofdabus released source code to exploit the vuln on Windows 2000 and XP machines on April 28, 2003.
- the SASSER worm and variants followed within days.

Of course, we had local patch detection for this vuln a long time ago. And we even had a remote rule. But the problem was that MS04-011 addressed 14 vulnerabilities and we were inferring the patched state by remotely checking for the patch in a different module. So, to improve our detection of this case, VERT was tasked with coming up with something that could definitively tell the difference between unpatched and patched machines.

So Jer and I sat down to figure this out. We started digging by going over houseofdabus' "lsass.c", compiled it, and then used ethereal to capture it hammering a few windows VMs into the ground. Great! A starting point. But with the limited understanding of SMB DCE-RPC we had at the time we were kind of fumbling in the dark with a loaded gun. We took the captures and translated them into a rule. Which gave us a rule that would crash unpatched boxes really well. Not so hot, but it was progress. Then we tried to "defang" the rule. We started by taking all shellcode and replacing it with A's, B's and C's and paring down the size of the overflow. Somewhere along the way we noticed that unpatched boxes were responding with a DSSETUP response ending with "48 05 00 00" while what patched boxes came back with ended in "00 05 00 00". Around that time boxes stopped crashing. Great! That's a rule.

However, our testing process revealed that this rule was way too dangerous to use, we were still overflowing a buffer, and if we sent the rule 5 times to an unpatched Windows 2K server the "server" service would die. At this point Jer had to move on to other work so I took over and tried to slice the rule down to a point where it would not crash boxes but could still detect the patch, but no luck. We could crash boxes and detect the vulnerable condition, or we had nothing. Maybe there were changes that could have been made to make that approach work, but I never found them.

So I went back to the drawing board, did some more research and looked for some other way to test for the patch. Since my work on this bug started I had learned a few other things about DCERPC so I went about writing the rule by setting up a SMB null session connection and then binding to the \lsarpc named pipe. I then figured out how to put together the sequence of packets to bind to the DSSETUP interface.

I then wrote a script to iterate through the different DSSETUP command options and immediately noticed something. After a DSSETUP bind request was made the 4th to last byte pair in the response to all subsequent DSSETUP requests was no longer "00", it was consistent, and it differed from my patched and unpatched VMs. Great! I thought I had something there and went home happy for the weekend thinking I had solved the problem.

Came in Monday morning, booted my VMs... so much for that warm glow of success. The 4th to last byte pair was still different between patched and unpatched, but every time the machine was rebooted they changed without any pattern (as far as I could see) . At that point I must confess I almost gave up again, I really didn’t know where to take the next step. What I did instead was go back and re-read some of the information I had dug up earlier about the vuln, hoping that the light of my new understanding of the DSSETUP interface would illuminate something I had previously overlooked.

Doing this lead me to an article which hinted that although the exploit involved a buffer overflow in the logging module called when a DSSETUP DSROLEUPGRADEDOWNLEVELSERVER request is made, when MS patched DSSETUP they removed not only the DSROLEUPGRADEDOWNLEVELSERVER function handle but the handles for a couple of other DSSETUP calls, including DSROLEDNSNAMETOFLATNAME. Bingo!

I hacked together a DSROLEDNSNAMETOFLATNAME request packet (and in doing so found further support for what I had just learned on an ethereal wiki page) and sure enough. Patched and later versions either respond to a DSROLEDNSNAMETOFLATNAME request with OP_NOT_SUPPORTED or a success message with nothing returned, unpatched versions either come back with a failure message indicating the name was not found, or a slightly different success message with nothing returned message.

The rule itself comprises several sends of data to set up the SMB null session, bind to the lsarpc named pipe and hit the target function. The first data sent is an NTLM protocol negotiation, we check for successful response and continue with a Null session. The second send is a Session Setup AndX Request, we check for a success response and parse out the TreeID, ProcessID, and UserID from the response. At this point the TreeID is actually null, but I grabbed it anyways so that I could use a single function and variable to hold the data when I reread it after the TreeID has been populated on the next send.

The third send is a Tree connect request (containing the PID and UID) to connect to the IPC$ share. The response includes a populated TreeID which I parse out along with the repeated ProcessID and UserID. The fourth send now includes the PID, UID, and TID and is a request for the \lsarpc named pipe. Once we get a successful response we send a bind request for the DSSETUP interface (with the P/U/TIDs and an incremented multiplex ID). The target host should come back with a DSSETUP response success message.

Once we get that back I send a DSROLENSNAMETOFLATNAME request for a host name containing some illegal characters and from the response we determine the patched or unpatched state. Match conditions are an "unknown host error" from a domain member or an empty success message followed by some unique bytes from a workgroup computer. Most of the time the no match condition will be either "op_not_supported" or a success message followed by a generic error code and no data is returned.

And that's that, a week's worth of digging and a nicely non-invasive way to infer the patched state through the presence of a peripheral condition. Hope you found it interesting.

Security, at least the flavour of it that nCircle and ilk engages in, is an interesting business. There's grey areas, and I've been bit by a few of them (censored blog posts for understandable reasons)... then again, I'm the kinda guy that would stuff a steak down his pants and then go thumb his nose at a Pitbull Breeder's convention, so I guess I have it coming :) Still, if we don't get around to talking about them, they might stay that way... and I suspect that many people, the industry over, big and small, have a vested interest in keeping it that way. Perhaps because they reap gains from the confusion.

So what are these grey areas? Well, honestly, I'm bored and now maybe a little scared (of getting stressed out) talking about the ones that I know of. I'd like to hear stories from other people that I might not have heard about. I don't feel like being the one that opens the door, but if someone else does it, maybe the rest of us can walk through it.

[Edit: the goal is to seek a way that grey areas can be safely explored and resolved for the good of all, and for once I have to begrudingly admit, in a fashion perhaps restricted to a subset of people; a group that everyone agrees are trustworthy. But by doing this, how can we ensure equal participation of individuals who don't work for corporations, such as the many independent security researchers out there?]

For those who don't know, a couple of years ago I invested a bunch of time in becoming certified as a clinical hypnotherapist. Beyond the fun of having C.Ht. on my business card and the interesting party tricks, I have found the skills learned particularly useful in management and observing the world around me.

Because of those skills, I have to report a particularly interesting vulnerability that I've enjoyed exploiting of late.

Title: Starbucks Barrista Iced Tea Buffer Overflow
Type: Denial of Service
Details:

Starbucks barristas are particularly skilled at handling detailed orders for coffee beverages - an order for a "half-decafinated non-fat mocha frappucino" is handled without much difficulty.

However, there are other less exercised code paths that have significant input validation errors. My personal favorite is the "iced tea" overflow. Barristas are used to only a two variables of input when taking an order for iced tea - "sweetened/unsweetened", and "lemonade/no lemonade".

If an order is given to an unpatched barrista containing extended variables, a buffer overflow occurs and the results of service delivery are extremely unpredictable.

Proof of Concept

Go to a Starbucks with an unpatched (i.e. not previously exploited) Barrista behind the counter. Order some variant of iced tea - my current favorite is:

Venti, Half-Black, Half-Passion, Unsweetened Iced Tea.

The results are unpredictable, leading the vulnerable barrista to return anything from the wrong sized beverage to a beverage containing both sweetener and lemonade, to an iced tea containing nothing but the iced-tea concentrate that they use to generate the beverage.

Workaround

The efficacy of the proof of concept is geographically dependent, as cultures where iced tea is normally unsweetened are less suceptible to this attack. (In that case, order a sweetened tea or lemondae).

Additionally, once a Barrista has been exploited (and had to re-make the beverage two or three times), the Barrista becomes innoculated to the effects of the attack.

Credits:
Shoutz to Melina who has watched far too many barristas become confused, and a big thanks to anyone else who has ever visited Starbucks with me and had to wait while barristas remade my order. Major props to the Barrista at the Starbucks where I'm writing this entry, who had to re-make my drink 3 times (and who refrained from throwing it at me).

I've whined and complained in the past about vendors making flaky network products, and however true and/or tactless that statement might be, it's kind of useless. I should at least offer a decent solution to a problem, otherwise it's just moaning. I'd like to get around to that now. If you don't like long rambling blocks of text, here's your cue, hehe :)

Patch Tuesday looms over us once again. 9 Windows patches, 2 Office, and 1 Exchange, and a wide range of severity levels. More details here:

Looks like the same functionality change that was rolled into MS06-019 is going to be in the new exchange one. While some might read something malicious into MS' persistence in forcing admins to choose between breaking compatibility with 3rd party mobility extensions and patching their exchange boxes, I do not. I think it would be ludicrous for them to maintain a separate stream of patches for external functionality, especially functionality that was based on what was essentially a bug. Now why does that sound so familiar?

Predictions for this Tuesday:
- MS will be late again with the release. Technically they say 10am PST, but it's often more like 10:30 before the bulletins and patches are available. This is a pet peeve of mine, why can't they release this stuff at 9am EST, so that at least half the planet has a full working day to test and patch?
- The office vuln will branch in more ways then you could ever believe. If you have previously applied patch 9743573 download patch 22113344, but if you have not applied patch 9743573 then download patch 22113345, unless you're using the Korean version then ...

Either way, the sure thing is that we are going to be here well into Wednesday. Wish us luck.

In his blog (which is one of the few on my "Daily Reading" list), Adam Shostack has a really interesting post entitled "The New Transparency Imperative". He makes the point that the new disclosure laws are going to do a great service.

And, while I agree with him, I think we really need to talk about the dark-side of the point. Everyone's running around touting the benefits of SB-1386 and laws like it, but we're forgetting the very real damage that disclosure can cause.

We've had a "responsible disclosure" debate in the vulnerability research community for a whole lot of years - the point is simply that, while disclosure forces everyone to be responsible, sometimes, you can have too much of a good thing.

The recent VA compromise is a great example. The analyst whose laptop was stolen obviously potentially compromised a large amount of personal data. However, the average domestic laptop theft isn't a targeted act - the purpose isn't to steal data, but to steal a laptop. However, with the amount of disclosure that happened in this case, it's a safe bet that, if the thieves didn't know what they had stolen (and the value of the data on the laptop), there's no question that they do now.

We likely won't ever know if the thieves stole the laptop for the sake of the laptop, or for the sake of the data. But, if the disclosure had been a little more discreet, it's at least possible that they wouldn't have known what they stole.

I'm not suggesting that we shouldn't disclose - I'm only saying the same thing that has been said about exploits and vulnerabilities for the past 10 years: we need to find a way to be responsible about it.

I've been doing paid security work for roughly 4 years now, and had an interest in it since my dad built our first Apple ][+. I'm starting to wonder if I've seen it all. I'm referring to archetypal scenarios of course; I fully realize you can never 'step in the same river twice'. Having said that, anyone who has enjoyed a few good Danish Christmas dinners knows that even though every rice pudding is a little different, there's not alot of room for significant variation :)

Technology changes, there's new attacks, new defenses... but is that really true? Personally all this stuff I'm seeing seems to be variations on a few basic themes. People implement it, other people attack it. Buffer Overflows *big yawn* shellcode *yawn* Crappy Software *yawn* lazy users *yawn* Businesses making hardware and software for money and skimping on security *yawn*. Crypto created, crypto broken *yawn* fuzzing *yawn* IPS and firewalls *yawn* automated exploit frameworks *yawn*... Viruses, worms and trojans *super big yawn*...

Sometimes I think it's like being a cop... at first you're all excited to be making a difference. You're going to save lives, make the world a safer place. Fast forward 10 years later, and you're probably well jaded after busting the same junkies 1000 times, the same person that beats his family and never learns, the same thieves that keep getting in trouble. In short, people rarely learn and they keep making the same mistakes.

Security is starting to look the same way. Sure, every now and then something comes out that sounds new and revolutionary... but there's *always* a precedent to some kind of attack in the past. There's nothing truly, radically new. Maybe with all the younger folks coming into the field, being exposed to computers and doing security stuff, it all seems new to them and so they think they're doing something incredible. And I suppose they are, but that doesn't mean it's new. Stop re-inveting the wheels guys, and know your history or you're doomed to repeat it.

Perhaps the field is maturing and that's why we're not seeing anything truly, radically new. I will make a bet that in the next several months, no one out there will be able to produce, and show to me, anything 'truly, radically new' - I'm confident that I'll be able to show you where and when someone has touched on this before, and if I can't do that, why what you're showing me is nothing more than a variation on a theme already extant.

Came across this today, don't remember where, but I found it interesting: http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396

If I may purloin a couple of paragraphs for the ADD afflicted folks who don't want to read the whole article:

Today, CORBA is used mostly to wire together components that run inside companies' networks, where communication is protected from the outside world by a firewall. It is also used for realtime and embedded systems development, a sector in which CORBA is actually growing. Overall, however, CORBA's use is in decline and it cannot be called anything but a niche technology now.

Given that only a few years ago, CORBA was considered the cutting edge of middleware that promised to revolutionize e-commerce, it is surprising to see how quickly the technology was marginalized, and it is instructive to examine some of the deeper reasons for the decline.

There's a few reasons I found the article interesting:

First off, we have customers that use CORBA and so I've had to deal with it... it can be challenging stuff :) Kinda of like Java in that it's big and tries to do alot, maybe too much.

Secondly, it demonstrates the downside of standards bodies. Death by comittee, and how politics, economics and business motivations affect the security 'ecosphere', if I may use such a poncy term. You can be as smart, productive and visionary as John Postel, but it's the suits that will ultimately try to define the shape of the future; sometimes they succeed and sometimes they fail.

Thirdly, it amazes me all over again that folks like the OMG exist, to create standards and technologies. And then license them at exhorbitant costs? Stupid idea. In my book, any standards bodies that exist such that the products of their efforts are designed as a revenue stream are completely retarded. It's as bad as getting your news from CNN.

http://irrepressible.info/

Please show your support. Freedom is more important than security.

At this point, most everyone is familiar with Skype, a nifty VoIP/IM/Video/Etc client from the makers of Kazaa, now owned by eBay. Skype is pretty cool, and not just because of their supported operating systems. Skype is also a pain for security folks at most enterprises. If you're interested in the Skype protocol, read this doc. Turns out, though, that Skype is also a pain for Skype. Because of the evasion techniques that it implements, which make it hard to detect on a network, Skype has cut itself largely out of the enterprise business market. Businesses are hesitant, quite understandably, to endorse a tool they can't secure, and that allows for the unfettered transit of data out of their network. This leaves Skype with no path up-market.

Those who make these kinds of decisions have seen the light, it seems. Skype has "just appointed someone to oversee the creation of security guides that would set out how to use and manage it securely." It will be interesting to see if they can make this transition.

Normally, I really try to avoid reposting things from Slashdot here. I figure, if it's on Slashdot, this community has probably already seen it or doesn't want to. Occasionally, something seems like it could use a few additional comments. This article walks through a pen test, starting with physical security:

"Without having an "official" magnetic access card to duplicate, I pulled every card with a magnetic stripe from my wallet, including my bank ATM card, a credit card, and a shopping card from a major grocery store. To my surprise, the first swipe from the shopping card opened the door."

So it seems that this magnetic swipe system simply accepts *any* magnetic stripe? Or maybe there's something about this particular frequent shopper card that works with this particular system. In any case, it's a nice simple reminder why *two* factor authentication is still relevant.

As a side note, this sort of article reminds me of the narrative of a DDoS against grc.com from Steve Gibson back in 2001. Note not only the use of language, but also the use of color, font, size and indentation.

I was at the gym this morning and a fellow gym-goer left his bag sitting atop the lockers while he went to work out. This is a common occurence, despite the fact there are signs warning about theft in the locker rooms and the fact that there are, in fact, lockers readily available. I started thinking about what might be in his bag for which the risk of theft was more acceptable than the $.25 for a locker. "Probably nothing of value, maybe his gym ID card," I thought to myself. The gym ID card contains a magnetic strip, your name, your membership number, and a rather blurry 'funhouse mirror' kind of image of you. I can only assume the image that appears on the monitor when the staff swipe the card is somewhat more recognizable as a person.

I imagine that many people would happily make the same tradeoff. The information on their gym card isn't worth a quarter, given the perceived risk of theft. But it got me thinking about what one *could* do with such information. Identity theft is not about the wholesale usurping of someone's life, but the subtle use of their external identity for financial gain. I wonder if I could call up the gym, give them a name and account number and ask them to verify 'my' bank details or home address or social security number. With those pieces of information, I could probably do quite a bit more damage, maybe open a line of credit.

This kind of targeted identity theft is pretty rare, I'm guessing. It's tedious, requires work for each person, and the profit is likely minimal. I'm not saying it doesn't happen, but that it's not prevalent. It does, however, illustrate a point about how identity theft is about starting with minimally valuable information and escalating it to profit. It's like the one red paperclip guy, only with information.

The issue here is that large scale commerce makes large scale identity theft possible. If I steal 10000 social security numbers, then find an automated way to open 10000 lines of credit, then use online banking to draw on all of them to fill up a numbered Swiss account, the profit potential escalates significantly. What if I steal those SSNs from the gym? I'm guessing their computer systems aren't that well protected.

Data theft and data loss are fairly commonplace events at this point. We probably don't go a month without some company reporting the disclosure or loss of customer's or employee's data. There are a lot of places one could put the blame for the rise of the incidents (alternatively arguing that the rise is in reporting, not actual incidents): companies themselves, government for not regulating them, the criminals who actually steal the data. When it comes down to it, however, the blame, or rather the responsbility, should lie squarely on the shoulders of the consumer. The more we put our data out there for commerce, the more connections there are by which this sort of data escalation can take place. Right now, your SSN is a key to more data that you can imagine, given an access path. At the same time, it's not easy to avoid giving it out.

Next time someone asks for your SSN, or your zip code, or your home address, try saying 'is that necessary?' The answer is likely going to be yes, but asking the question is just one way to communicate that you're aware of just what information you're giving out.

As far back as I can remember, DEFCON has had the 'spot the fed' contest. Essentially, if you could spot the person at the con who was from the Secret Service or FBI, you win. I raise this relationship between law enforcements and the hacker community because attitudes are changing, at least that is what the FBI says about their attitude.

The Keynote for Blackhat was given by an FBI dude named Dan Larkin. I was disappointed that the Secret Service did not deliver this content because they really understood this partnering concept many years ago. When you are small, you learn quickly that you can't do it all yourself and develop non-zero-sum relationships as a survival skill. :-)

In my opinion, the main message the FBI had for the Black Hat audience was "we need a stronger partnership". 'Spot the Fed' becomes 'Partner with a Fed*'. In the past it was all about getting intelligence out of the hackers but the benefit seemed very one-sided. He said that the FBI would like to make it more of a two way street. They want to give back to the hacker community but did not go in to detail on what form this would take other than mentioning Infragard (FBI). The big message was : Team up and be better partners against cybercrime in the 21st centry.

He rightfully points out that as much as technology advances, it is all about the people. It is about the people executing the criminal networks via technological advancement. I sure hope this did not surprise anyone in the room.

When making reference to what was once referred to as CyberCrime, the FBI is just calling it organized crime. When they do their work internationally, everyone understands the term organized crime. He points out that organized crime is using technology to be quicker and widen their scope. He spoke about the notion of "packaging" and that cybercrime is just another packaging of organized crime. I fully agree and from a gaming perspective, crime is just a community that is playing another game that has a negative impact on your game. (or a violation of your game that works to increase their payoff) The gaming analysis is worth an entire posting itself so I'll stop here. :-)

As you would expect, he did a very good job in making the point that intelligence is key. The advantage goes to the one who has better intelligence, better observation, and better orientation.

In summary, his main position was that we cannot forget human reasoning. It is what I have been saying for a while now: all of this is a game being played between two or more opponents. We need to stop being so focused on the game technology and focus on the mind of the opponent. Is winning a card game really about the chips, cards, and table? Like it or not, you've been dealt in to the game and it is your turn. :-)

I don't know about you but when I think of a powerful keynote address, I think about a message and a speaker that really starts my engine and inspire me for months after the show. With all due respect, this was not one of those.

The attendance was so overwelming this year at Blackhat that the entire auditorium was standing-room-only. I had to go to another room to be confortable and watch it over a video feed. The only problem was that the slides he was speaking to did not get covered on the remote monitors. Oh well, what do I know. Does great attendance mean success? I would say so.

I absolutely cherish the hallway conversations and the people. BlackHat for myself and many means a chance to get to see friends you only see once a year and hang out. When I think of the partnerships, partnerships between people, I think about a great deal of mutual respect and understanding. IMHO, there is still a lot of work to be done between law enforcement and that culture that is Blackhat/DEFCON.

There was a day when we could all be safe in ridiculing the tinfoil hat crowd. When I saw Adam Shostack with a piece of the shiny stuff wrapped around his badge at RSA this year, I thought that times may have changed. It's not quite the same concern. The foil headgear is intended to protect one from mind control, alien influences, and the MLB satellite. I'm not so much talking about keeping others out, as keeping my information in. As RFID creeps up in more and more places, perhaps it's time to start worrying about what information you might be leaking. Enter the RFID blocking wallet!

Tinfoil hat of the future or the next ubiquitous personal tech?

Reading murray's blog this morning, I was interested to see his post on good bosses and bad bosses. As usual, Mike had great insight objectively and a healthy dose of self awareness. As soon as I read the title, I expected no less. :)

Also as usual, our thinking was very similar, but I do see one part of his post in a very different light:

"I have always believed that management is a responsibility that can be measured by a single factor: staff retention."

I think there's some truth in that statement - untimely and/or unexpected attrition is a bad thing - but I don't believe that staff retention is a powerful enough measurement to capture the success of management as a single factor. One of the most important things that you can do as a manager is to support the growth of your people. Behavioral growth, skills growth, creativity growth. In many cases, this leads to your most talented staff being capable of more than the job they're in. For those who evolve with the team, retention becomes much easier. For those who don't, attrition is not always a bad thing.

There is an impressive list of *extremely* talented people who have worked with the VERT team over the years, and in most of those cases the decision to move to a new challenge has come on the heels of *good* management (myself excluded perhaps?). Staff retention is one of the highest priorities for me as a manager; keeping my team energized and happy is the most rewarding part of what I do.

For the record, Mike is one of the best coaches I have ever worked with. He does a phenomenal job of promoting growth in his staff. Maybe he doesn't give himself enough credit when thinking about his former staff who have moved on.

Perhaps that's a sign of a good boss.

Jaron Lanier’s recent essay “DIGITAL MAOISM” casts users of online collaborative systems like Wikipedia and Digg into slaves of the faceless mob; each of us a subservient to the rejection of individuality and creativity.

For both the attacker and defender security engineer, its generally believed that being unpredictable and diverse provide an upper hand. Conversely, supporting n+2 operating systems and identity tools equates to n+10 support and integration issues. As such, IT departments have historically relied upon the Common Operating Environment. For the sake of interoperability, the Internet as a whole relies on RFCs and bodies like the IETF. These organizations provide a like-minded outcome and each of us develop tools based upon the standard.

Lanier would have us believe that at some point in time, collaboration falls on its own sword and creates a reversal. From that climatic point going forward it’s a down turn, nose-snubbing smear to creativity and individual thought. Turing this supposition into serious thought regarding security practices proves to be both tough and interesting. If every organization were to look the same, be the same, act the same then a single defector could 0wn us all. I relish in the day when every person reads email in plain text and changes their password regularly. There is a natural life cycle of the hive mind and for security; we are still at the infancy stage of “security awareness”. For the time being, our skills are probably still desired.

Can Lanier’s essay hold water outside of Wikipedia and Digg?

Microsoft has released an Out-of-Band Update for the VML issue in IE. I would suggest that everyone visit http://www.microsoft.com/technet/security/Bulletin/MS06-055.mspx to obtain this update and download it as soon as possible.

The Seattle FIre Department produces a web page that lists where all of their emergency aid and fire vehicles are deployed in the city. A guy name John Eberly used Google maps to produce a mashup that displayed all these points on a map. Nifty, huh. The SFD heard about this, or received some complaint and they very quickly stopped publishing the text feed. They didn't remove the data, they just started publishing it as a jpeg instead of text. You can read an article about it and some of the interaction between Eberly and the SFD as well.

We can all argue about the logic of the SFDs decision or more significantly their justification of the decision. Ultimately they chose to keep the data available, but make it harder to process in useful ways. This is an interesting conversation, but the topic of apparently illogical security decisions is well worn in this day and age.

This incident got me thinking, however, about thinking and about acting, and about the difference between the two in information security. The SFD was put in a position where they felt they could not let the status quo stand, i.e. they had to *do* something. One can imagine that they evaluated the choices, looked at the impact of each and balanced it against the *reduction* in risk they would achieve. This compromise turned out to be the best choice. For whatever reason, the option to remove the data entirely, which would have reduced the risk to zero, was not viable. Perhaps there are other people who rely on that data being available, and so its removal would have been detrimental to their business.

This decision making process mirrors the risk mitigation choices that infosec professionals are required to make all the time. Let me outline the process:

recognition of risk --> evaluation of solutions --> action (acceptance, mitigation)

It's interesting to lay it out this way because it demonstrates that action is at the end of the line, so to speak. Often, those who are not responsible for the 'action' piece of the process, can easily criticize the action taken. Often, such criticisms are perfectly valid, especially if the person isn't time-constrained by the requirement to move to the 'action' step. But, sometimes those criticisms aren't valid because the individual doesn't have all the information. To bring this around to infosec again, the right actions are predicated upon having the right information. Recognition of risk requires full information about the nature of that risk. Evaluation of solutions requires full consideration of *all* the potential options. Without the right information, bad decisions are the result. If this process if fundamentally time-constrained, and it usually is, then it's key that the gathering of relevant information exist outside the time constraint of the process itself.

When you work in InfoSec, there's a definite tendency to define risk within the context of what you control: technology. Of course, technical controls, or the failure thereof, are not the only context in which risk exists. There's a whole world of physical security that, usually, but not always, is divorced from information security. Some of the really smart criminals understand that this rift exists and exploit it. But this post isn't about social engineering. It's about credit card fraud. The NY Times has a good article about technical attacks that are possible against new rfid credit card readers. Guess what, people can use the same technology that allows for transmitting of card data to the reader for stealing the card data. Are you surprised?

I bring this up not because the technology is flawed, but because the article illustrates how the credit card companies manage risk. Let's lay out the objections from the credit card companies as illustrated in the article:

1. “This is an interesting technical exercise,” said Brian Triplett, senior vice president for emerging-product development for Visa, “but as a real threat to a consumer — that threat really doesn’t exist.”

2. “It’s a small sample,” said Art Kranzley, an executive with MasterCard. “This is almost akin to somebody standing up in the theater and yelling, ‘Fire!’ because somebody lit a cigarette.”

3. “It’s basically useless information,” said David Bonalle, vice president and general manager for advanced payments at American Express. “You can’t steal that data and just play it back and expect that transaction to work.”

4. "Beyond the security on the cards themselves, the companies said, they have deployed fraud detection and prevention measures that block suspect purchases. And each company stressed that cardholders were not liable for fraud."

5. "Tom O’Donnell, a senior vice president at Chase, the largest issuer of the new cards, said that the attacks described in the paper would be too cumbersome in the real world. And the researchers said that other kinds of fraud, like so-called phishing scams in which criminals trick people into revealing credit card information through misleading e-mail messages and Web sites, were currently more effective."

4 of the 5 statements don't actually deny the technical results of the research, but address instead the likelyhood of exploit. In other words, they're largely saying that their risk analysis has determined that the likelyhood of exploit is not large enough to warrant addressing the technical capability. In most organizations, this is a perfectly reasonable conclusion. There are some other points in these objections about compensating controls and cardholder liability.

It's important to keep in mind that the primary goal of the credit card companies is not consumer protection, but profit. In that sense, the primary motivation for consumer protection is its affect on profit. That's what makes the end of the article interesting. Despite the results of the risk analysis that the companies have clearly done, "[a]ll of the card companies said that they were in the process of deleting names from the stream of data transmitted to the card readers." Why would they do this? If the likelyhood of actual loss is fairly minor, why spend the resources to change the data that's transmitted? The answer is simple, risk can come from consumer confidence as well. Even if a loss never occurred via this attack vector, the perception of impropriety on the part of the credit card companies would have a detrimental affect on profit.

In order to arrive at this conclusion, the credit card companies had to perform risk analysis that combined marketing, sociology, and technology. Perhaps they even went so far as to assume that some information disclosure would be discovered and to build in some information they could then remove from the data stream to demonstrate responsiveness. One might ask, why would they have included the credit card holder's name in the first place? Maybe I'm just paranoid.

How does the DoS work?

When the Additional RRs (aka Additional Information) section of the DNS Datagram contains two null bytes an error occurs at the instruction "mov dl,byte ptr [eax]". This causes the service and it's host process (svchost.exe) to die. One thing to remember is that the ICS service is tied to the Firewall service. If ICS dies so does your firewall.

Vulnerable Function Name:

Via WinDbg with Symbols: DnsProcessQueryMessage
Via WinDbg without Symbols: NatCreateRedirect

What are the attack vectors?

Current research leads me to believe that this only affects Windows XP with ICS... I haven't been able to recreate the problem under Server 2003 with ICS enabled. It also only affects the "non-Shared" connection... Other Users --- Shared PC -- Internet.. THe attack must come from the "Other Users" side of the network.

How does ICS work?

When you share an internet connection the computer with the shared connection creates pseudo DHCP and DNS servers (Proxy DNS). I call them pseudo for a number of reasons. First, they aren't managed... Unlike your standard DNS and DHCP servers you can't specify options, settings and configurations. Second, they're tied only to the interface that is not being shared, you can't make them listen on the other ports. When the DHCP lease is offered to the client computers, they are given an address on the 192.168.0.0/24 network with the gateway as the shared computer (192.168.0.1)... The DNS server is also set to this IP.

Am I vulnerable Checklist:

1) Are you running Windows XP
2) Are you sharing your internet connection?

If the answer is yes to both of those, then you are vulnerable.

Mitigation:

1) Disable Internet Connection Sharing.
2) Block UDP port 53 (DNS) on the computer that is sharing the internet, manually set the DNS Server to your ISPs DNS address.

Is exploit code available?

Currently there's a remote DoS PoC available.

According Postini and Sophos, the spam storm has analogously increased to hurricane levels recently. So yes, you aren’t imagining it. The amount of “ViHya7ra” and “Its me, Natalie” emails are on the rise. Sophos released some interested data about this on November 6th, showing that the US tops the countries in spam relays, followed by China. Security professionals should take note. US based machines are being turned into botnets, zombies if you will. We may not be able to inoculate every zombie, but we do have some nice free tools to counteract their cancer.

Top twelve spam-relaying countries*

*Source: http://www.sophos.com/pressoffice/news/articles/2006/11/dirtydozq306.html

Aside from SpamAssassin, these two tools top my list for stopping spam.

Blacklists

Here, some central authority maintains a list of known “bad guys”. As a subscriber, you setup your MTA to query the list. Not unlike the “bad check writer” list you may see at a local mom and pop grocery. If you are on the list, sorry.
To setup, configure your MTA with a DNSBL feature. If you are like me and still fond of Sendmail, go read about the FEATURE(dnsbl). There are plenty of good docs and sites out there on this so. So do some research for the nitty gritty details.

Note: if you have multiple public MX hosts, you’ll need to apply this to all of them.

Grey Listing

The concept here is if the sending MTA is legitimate, it will retry. If you are calling into your favorite radio station to win those Rolling Stone tickets and you really do know the pop quiz answer, then you will keep hitting redial. Grey listing code; run as a milter (go search on milter-greylist) returns a temporary error to a connecting MTA. If the MTA returns and attempts again, then let it pass. Generally, you’ll want to also setup a whitelist to allow all the good guys to pass without delay.

If you’ve got other ingenious, new or just nifty spam fighting tricks, I’d love to hear.

--S

Cisco has produced a somewhat interesting study on changing security trends in the federal space. Carolyn Duffy Marsan has kindly written an article at Network World to tell us about it. Let me offer first a favorite criticism of mine: if you are producing a story about some survey, another story, a press release, legislation, etc, please please please provide a link to the original item! Now, maybe this survey isn't publically available, but I don't know that. I can research it and find out, I'm sure, but part of the value the article brings should be to make that task easier.

One thing in particular caught my attention in these survey results. "More than half of the survey respondents cited funding, existing architectures and the lack of standards as significant barriers to improving network security." Funding is certainly no surprise as a barrier. I think there's probably something wrong with the market if vendors arent' pushing the budgetary envelope, and there's definitely something wrong with the purchasing process if the agencies aren't pushing back. The other two barriers mentioned are more interesting, and actually related. The 'existing architecures' as a barrier indicates that vendors aren't delivering on the promise of integration into existing systems. Alternatively, it demonstrates how the lack of standards in the past has developed into a problem. A good standard, like XCCDF, can make integration easier. On the other hand, standards create commoditization in the market, and that means vendors have to work harder to differentiate themselves from their competitors.

Interestingly, google happily remembers last year's survey as well. Last year, "The most significant barriers (referred to as "mountains versus molehills" in the survey) to improving an agency's network security capabilities include funding and budget, and other projects getting higher priority." So funding is a constant. No surprise there, but the priorities have shifted so that integration is key, but project priority is no longer a problem. Also, no mention of standards at all.

There are other juicy tidbits in the article as well, but I'll let the interested pursue them on their own.

I just wanted to toss everyone a quick heads up… This just came across ISC and I wanted to inform my readers. It seems that Microsoft is investigating a possible 0-day in Word, they have issued an advisory on the subject. A user must actively open a document in order to be exploited.
Affected Software List:

* Microsoft Word 2000
* Microsoft Word 2002
* Microsoft Office Word 2003
* Microsoft Word Viewer 2003
* Microsoft Word 2004 for Mac
* Microsoft Word 2004 v. X for Mac
* Microsoft Works 2004
* Microsoft Works 2005
* Microsoft Works 2006

This is a good time to remind your colleagues and friends… your users or your managers that they shouldn’t open attachments from people they don’t know… and even better advice would be to never open unsolicited attachments.

CVE-2006-5994

Tim Callan has written an article over at NetworkWorld explaining the value of the recently released Extended Validation SSL Certificate standard. This effort, a product of the CA/Browser Forum, is a definite step in the right direction. Living on the technical side of Information Security, I clearly understand the requirements for cryptographic assurance of identity in online transactions. This effort recognizes, quite rightly, the additional requirement of usability in the consumer space. It makes no difference how solid the certificate process is if the user happily clicks through invalid certificates. So perhaps the more important aspect of the EV SSL project is not the Certificate Authority side of it, but the browser functionality. With IE 7, users get more than the little lock in the bottom right corner, they get the green address bar and they get the organization's name, validated by the EV CA process in the address bar as well (screenshot). This move, to make the status of the certificate and the organization's name more obvious to the user, is a simple design concept that could reap big benefits in terms of user awareness.

Of course, nothing is perfect. I can't help wondering how hard it would be to force IE to display every address as green, and how many users aren't on IE7 in the first place. I also can't help wondering how many warning signs users will ignore when they really want purchase that rare member of the 'original 9.'