Another lesson from the MD5 / SSL CA hack: We’re now stronger for the issue being exposed.

Someone could have exploited this weakness already, or someone could have exposed it in a year of five from now. But because this has been exposed to the public, we’re now collectively stronger and more informed for it.

This is an agnostic approach where I don’t have to say we should be throwing exploits out full disclosure-style without giving anyone a chance to fix or mitigate the issue. But rather, simply exposing the issue to the public with enough detail to be actionable is what I want. If that involves partial disclosure or even full disclosure with POCs, I’m fine with that.

Would I sing the same tune if the researchers had released their rogue CA? Yes, although it might be tainted with a, “That’s pretty short-sighted of you to do that.” But being able to react to what is disclosed is part of the lifestyle, even if we don’t agree with the actions. (Gosh, if only attackers would disclose to us their tools first before they go on the offensive! That would be the professional thing to do, right?)

I’ve seen plenty of talk these days about audits, compliance, pen-testing, and security-reviewers and how they are canned or unskilled or unknowledgable. (Auditors who understand they lack understanding are exempted as there is a place for checklist checkers.)

To me, it is pretty simple to tell when someone or some group knows what they’re talking about and are qualified to help with security. There are two traits:

1) Ability to discuss (accurately!) a scan or pen-test report. Don’t just hand the report back and/or quote it verbatim in a meeting. Be able to casually talk about the issues, and if necessary, be able to reword them for understanding by managers and techies alike. Being a fellow geek, I can usually quickly figure out when someone’s knowledge is limited or outright bullshit.

2) Ability to discuss the pros and cons of security measures. This takes practical knowledge on how business and IT works, including practical knowledge in implementing protections or workarounds. Is it responsible to demand an entire web application be wrapped in SSL? In a way, empathize with the IT manager, the techs, and the business as a whole.

The bottom line: Be able to add something beyond just the deliverable report! The unfortunate reality of this is the need for security persons to have some practical implementation experience in business. The more you can basically make decisions for a manger, the more she will like you!

In the long term, there are two more traits one can evaluate sec geeks/groups by.

3) Ability to learn new techniques and tools. This ability still leaves open the option to use automated tools, but forces testers to be open and able to learning new things, including code, other automated tools, or manual options. I’m not one to rag on people who run automated scanners,* but I would rag on someone whose entire repetoire is an automated scanner.

4) The depth and breadth of their knowledge. It is hard to be both deep and broad in security, but the more you can be both, the more value you have. Practice, practice, practice! (And for god’s sake, manage expectations properly and admit when you are in over your head rather than flounder and deliver less value.) As an alternative, be extremely deep in your chosen area.

* It is my observation that there are three main phases to automated tools use. First phase is developmental where automated tools are fun and awe-inspiring. Then there’s the in-between phase which is where people start crying and yelling at “script kiddies” because they use automated tools. Then there is the third phase where realization sinks in that automated tools, even skiddie tools, can have value. Strive for phase 3!

More information about recent MD5/CA Root attacks (links from SANS):

in the authors’ words
powerpoint slide deck
microsoft advisory (…ok)

Very few entities can actually do anything about this, and it takes quite the effort and knowledge on behalf of an attacker (not surprising for a weakness pointed out in part by academics). But the impact seems pretty big, if I’m reading the details correctly (I’ll be the first to admit PKI and cert signing and trusting makes my head spin). All an attacker needs to do is collide and forge one rogue CA, and everything crumbles after that.

From my brief look there is one objective from this attack: Be able to MITM SSL connections using a rogue CA cert that the browser will trust because it matches what comes with the browsers (this assumes you can MITM the traffic in the first place).

From my brief look, this is the impact: You can potentially not trust every SSL cert out there. The holy grail, if I may call it that, of browser SSL/cert security lies in the strength of the root CAs that are shipped with the browser. Even a single weak one means any SSL can be forged and then implicitly trusted by that browser. Combine that fake trust with the ability to redirect and MITM traffic and you break down SSL trust.

Biggest issues for consumers #1: Phishing sites would probably love to get their hands on a rogue but trusted CA because that would mean they could forge their own certs and avoid that annoying popup about a cert being untrusted. Governments might want to pocket this information for cyberwarfare purposes. If you can redirect all traffic from a hostile entity to your servers, you can then MITM SSL quietly. I bet China would pay dearly for a trusted rogue CA…

Biggest issues for consumers #2: In limited situations like a small network or wireless hotspot, an attacker can redirect all traffic to his server. If he has a trusted CA with which to sign his own certs, he can actually MITM the banking domain you know, and host a cert that your browser will trust. The old habits still hold true: do not do sensitive things on a wireless network or a network you do not trust.

Lesson: MD5 collisions were discovered years ago, and while theoretical, only required massive amounts of time and computational power to make reliable collisions. While MD5 was and is still useful, you can’t pile trust on top of a broken process and still trust it.

There is a bit of chatter today about an undisclosed weakness in something that potentially affects all netizens. Yeah, I can only guess as well right now, but I expect it to be a routing or network infrastructure issue. I guess we’ll find out tomorrow from the CCC. Read HD Moore’s related post about it, including the far bottom with the preso schedule and links to video streams.

Their research combined a known weakness in one area with a massive resource investment in another to show that a third party was vulnerable to a practical attack that affects the security of all Internet users.

This post from Scott at SecurityViews got me thinking. Here is a snippet:

People desperately need help in sorting out what security information is relevant to them. Which vendors and technologies to trust, which browsers to use, which updates are important, which sites to give personal information to… it’s not getting any easier.

Weighty, but true. How do you get and/or give the best information out there when you have some knowledge to give?

As Scott points out without quite saying as much, it is about interaction.

It is not about blogs, wikis, written policies, Google searching on a topic, papers, research, etc. It is about grabbing an expert, asking the question, and getting a response back. And in a broader community, getting 5 answers back which can be of differing degrees of correctness which collectively improves everyone.

And that expert needs to be willing to answer the same question 20 times (which web browser should I choose) along with the whole argument to explain the decision. Ask the question, get an answer..

I wonder how many individuals or businesses are out there that would readily ask questions to an expert if they had a few moments to do so? And I’m not talking about, “What would you ask Schneier at dinner,” but common questions that nag like, “Should I worry about IE in my enterprise?” “How bad is vulnerability X?” “Is cloud computing a big deal to me right now?”

What sorts of interaction is there?
– In person; i.e. allow people to ask you questions, even stupid ones.
– forums
– mailing lists
– IRC
– social community sites (ExpertsExchange, ITToolbox types of places)

Blogs are a one-shot deal and then they move on. Wikis are only as good as they are kept updated, kept in scope, searchable, and chunkable…

Via Dan Morrill I learned that the Google Hacking Database on johnny.ihackstuff.com is possibly no more, replaced instead by a video? Undeterred, I threw my own Google search at the topic and came up with this page that takes you back into the Google Hacking Database. If it really is going away, might want to copy stuff now?

SynJunkie has recently written an excellent security story on his blog. It is written in 3 parts (with an Intro) and includes not just security topics, but actual tools, screenshots, commands, and scripts used as props. I find this sort of an approach amazingly awesome. I really hope he writes more of these, since they are useful on many levels!* Who needs a boring tutorial when you have faux-case studies?

intro
part 1
part 2
part 3

* I’m also bookmarking this for myself as an example on why I strongly believe admins and security analysts need “free time” to pursue issues like this, rather than follow the knee-jerk reaction of lowering security to get the immediate monkeys off our backs.

SharePoint RegEx Search is a tool that reportedly will take regular expressions to search a Sharepoint site for information that maybe shouldn’t be posted to Sharepoint (or should be locked down properly). I think this tool needs to run from a system with Sharepoint installed.

You don’t have to wait long when visiting Bejtlich’s blog to see thought-provoking posts. He’s dropped several more nice thought-bombs recently, asking tough questions (that may not have universal answers).

First, he talks about defining what “winning” means to security teams. I agree with the underlying assumption that security is an eventual fail for us mortals. So how do you define when you’re winning or have won (at least for a while)? I think point #4 is an interesting idea to keep in mind: when incident responders can anticipate the adversary’s next target.. That alone packs in the idea that you have informed, talented, and empowered staff. Ranum chimes in the comments that we have a problem with long-term vs short-term security strategies. Sounds like a good essay thesis right there!

Second, Bejtlich listed some things he sees as the future of digital security; basically trends we need to be dealing with either now, or we will be eventually. I had a long comment for him a week or two ago, but I think my session timed out as I composed it over a work day. I understand where he is coming from on most of those items, but that doesn’t mean I fully agree that they will become a reality. It would take me some time thinking and reading his post again to get back into my mindset, but I don’t feel that we’re moving towards having systems be stand alone secure machines. We can’t even get the OS right yet, without lots of bandaids, let alone getting all teams in IT (desktop, engineers, networkers, developers) to work together for that common goal. Instead, I think economics keeps us boxed into our own little worlds, patching and bandaging each other in our sphere of control. (Like I said, it would take some time to get back into what I was thinking in my lost comments…)

Bejtlich has no shortage of thought-provoking topics!

Michael Zalewski has released a web browser security handbook to the public. As expected from someone of Zalewski’s technical knowledge and depth, this handbook is not for the feint of heart and gets very deep into describing browser behaviors amongst all the major players. Printing the main sections out takes just over 50 pages, to give some scope to the work.

This guide should be useful to security-conscious web developers, researchers, browser developers, web attackers, web pentesters, application defenders/analysts, and anyone wanting to get into the guts of how browsers try to keep you secure. Don’t expect, however, to see all the differences browser have like how IE does padding one way and Firefox does it another; rather, all the topics are related to security issues or potential security issues.

Microsoft continues to lose market share, and more people have gotten interested in Linux alternatives, dramatically driving distros like Ubuntu to prominence (well, as far as Linux gets anyway). So let’s say you have an interest in trying out this silly Ubuntu thing, where do I recommend you start?

First of all, download and install Ubuntu 8.04 (?), which is the latest long-term support release. This means: it’ll be good for 3 years or longer. Don’t dual-boot unless you absolutely need to do something on Windows and don’t have extra systems. The most well-meaning people will still gravitate over and just keep using Windows. Go all in if you can and make it your primary system and OS!

I’m all for books, so for newbie Linux users I’d recommend a newbie book: Ubuntu for Non-Geeks: A Pain-Free, Project-Based, Get-Things-Done Guidebook from No Starch. Even for Windows-savvy geeks, there are many basic things in Linux that need to be understood to move on. I have not read this book, but it looks promising!

Avoid books that are just search-and-replace Linux books like the Unleashed series or the Beginning Ubuntu Linux or the Ubuntu Bible. These are just books that come out in all the major flavors of Linux and search-and-replace based on the distro (yes, I bought one or two and can point out where Yum didn’t get properly replaced with Synaptic…). They may be useful, but I feel dirty being used that like.

If you have some (even minor) Linux experience, graduate to better books that are more task/tip oriented like Ubuntu Kung Fu (I am currently reading this excellent book) or Ubuntu Hacks. Ubuntu Hacks has several workarounds for various things, which means not only does it get outdated quickly, it is in fact already outdated, but it might hold some interesting nuggets that help in the world of Ubuntu.

And once you have your feet wet with Linux and you’re moving about with relative grace, you can dive into the more generic Linux “get things done” books like Linux Cookbook or A Practical Guide to Linux Commands, Editors, and Shell Programming or Linux Networking Cookbook.

Mogull has posted 2009 predictions over on CSOOnline. I wanted to react!

1. Shrinking security budgets.
Yeah, ouch. This goes back to one thing I hold dear: Know how to provide security without the expensive tools. Paying a commercial tool to do a tracert or analysis of a 1MB log is added bloat. Be able to use the open source tools and basic skills to get things done. Yes it takes timemoney, but it often is easier on paper to cut tools than it is to cut staff. Like we always say, tools only go so far, but staff is where your value is. And keep metrics to justify the staff…

4. Database security market collapse.
Did this take off? I must have missed it. But I think it gets missed frequently because there are few things so buried in a business than the database servers and how things are stored and/or accessed. I’m not surprised this is underappreciated. I’ll consider this market a victim of the stupidly large cost of working in a technology-driven world. You want a database, and you also have to pay for this companion tool and that companion tool and this one over here for compliance…? And that’s only if you do things the right way, which is not how us humans are built (we live in the gray world of risk and gambling!). These needs to be built in just like Microsoft needed to build in a firewall and AV, with apologies to those markets.

5. Data Loss Prevention goes mainstream.
I still don’t buy it, unless you essentially have it part of the re-branding lifecycle of antivirus->antispyware->antimalware->host firewall->HIPS->DLP. Sure, then it works, but otherwise on its own I don’t see this as that lucrative. There are still too many ways to lose (or steal) data that tailoring a product to prevent it seems destined for futility in all but the most basic of operations. (e.g. Alert Alert! Someone stuck in a USB key and copied a file over! omg! Alert!) To me, “Data Loss Prevention” is more of a security program than a single tool. Besides, it is yet another thing that won’t manage or configure itself; it needs staff to give it love.

7. The PCI effect. PCI will drive WAF sales, but customers will still be dissatisfied with their performance. …[Need to] make them more useful out of the box.
WAFs take effort. That or they are so bare-bones they only protect against the most basic of universal attacks (signatures). I think the dissatisfaction grows as buyers are told they need to give their WAFs more love from their network and developer staffs than just, “set it up and forget it.” Too many bought WAFs just to throw them in, turn them on, and have them protect the world…and that’s just not realistic. But they need good rules and people to watch those good rules.

PacketLife is hosting a bunch of technical “cheat sheets” on various topics like BGP, EIGRP, Wireshark display filters (yay!), QoS, etc. Hell, there is even one for MediaWiki, which I don’t use enough so I always have to look things up whenever I make an update.

Basically this is one of the best links I’ve followed in months. Snagged this from Andrew Hay.