more info on the tls/ssl mitm attack

Some more information is slowly getting out about the TLS/SSL MITM attack via an “authentication gap” that was disclosed yesterday. As I somewhat inferred from the original details, this has limited potential (usually against connections utilizing client certs) and does not result in snifing traffic. As I somewhat expect with what limited confirmed info is out there, this is not a big deal to most, but may be a big deal to smart card vendors. As mentioned in the linked article, SOAPs and other web service connections may also be susceptible.

Even without the huge public risk in this, those three mentioned issues at the end may still be pretty important, especially if someone weaponizes and scripts it out for easy use to usurp connections or inject Bad Things (inject, POST, follow-up with GETs?).

Props to the security community on Twitter for being such an insanely great way to spread news on issues quickly. The above link I saw from the Taosecurity tweets.


Mr Andy IT Guy has posted a great article about his recent unsatisfying experiences as a security guy and subsequent positive move onward!

I can’t say I fully agree when he says that security needs to be separate from IT and so on about the political structure of an organization. However, I don’t know exactly what the right answer should be, and suspect that it differs depending on the corporate/mgmt culture. I believe in an audit (test, QA, etc) function that does checks. I believe in a group that has the same access to the business and infrastructure as the IT teams (monitoring, investigative, SOC/NOC, etc), but only doing security tasks (and not waiting for IT to get a span port right for the security tools to work). I believe in baking security knowledge and practice into the IT roles themselves. Sadly, all of that often lives in an ideal world. Ideally, I believe there are many seurity professionals of such a high degree of integrity that if you made them roughly gods in the company, they would properly secure the shit out of it without all the political BS.

And, too often, I think some organizations just have no desire whatsoever to do security. They just don’t want to do the shit and they don’t want to do the shit right. Sadly, that also will be a reality and hopefully we don’t have too many truly gifted, hard-working, positive security geeks tied up in such organizations for too long. (Maybe this is why ‘security consultants’ are such a rising deal. Organizations don’t want security, but they want some quick answers…)

I really love the mention at the end that often we security geeks get worn down. This is true. We get worn down. We get negative. We need to vent. We sometimes think the tasks are impossible. We even get frustrated and angry and share our passioned war stories over beers and strippers (I’m listening to too much ExoticLiability!). That’s why this industry and culture we have is so cool! Because we’re not all negative at the same time, and understand that sometimes we have to vent and sometimes we have to support the venting from our peers. But hey, hopefully with hard work and an alignment of the corporate stars, we can effect some positive security change when we have the opportunities to do so. The long-term goal is education, and whether we see it reflected or not, we do slowly improve the education of those around us (even if it causes *them* to take up beer binging, too).

tls mitm attack initial thoughts

Saw this first shoot out on Twitter at the end of my workday, but without any details, I simply made a mental note to keep an eye out. Sooner than expected, further details on this TLS MITM attack have surfaced.

Is this a big deal? Possibly. Certainly big enough to keep on the *front* burner, especially since initial details are pretty technical.

Does this allow an attacker to intercept and sniff TLS-encrypted traffic? It doesn’t sound like it so far. If I’m reading this correctly, an attacker can inject data into the stream and influence what the browser (in a web client->server scenario) renders, with no visible warning to the client that bad data has been introduced. That or I’m seeing that the client can influence what the server sees in the requests being made, in which case this is an attack on the server? Either way, this appears to be an MITM injection attack and not necessarily a MITM sniffing.

I’m also unsure how this stands with TLS negotiations without client certificates, such as most people I imagine are familiar with in their web environs.

I wonder if this might be very important for anything using TLS and client certs for authentication, such as the smart cards mentioned in the advisory. Would it be possible for someone to usurp that authentication and re-use it such that the attacker can then access/view those protected areas on the server?

When I find out more, I’ll post a follow-up!

ramblings on evolving security

Evolving security. I’m coming again to a post by Josh Corman on FUDSec, which I mentioned last week.

I don’t disagree with the post Josh made, but it doesn’t necessarily leave me in a beautiful spot. There are three thoughts I have in response to the post.

First, sure, I’ll buy on a certain level that we need to change. But even if we all agree we need to, what next? That isn’t answered at all. This sort of discussion is something I’ll have in the bar over drinks with fellow geeks, but that doesn’t make it fruitful or useful.

Second, why do we need to change? I know, Josh went into this in detail as business always changes and attackers are ahead of us and we don’t retire security tools and so on. But he doesn’t sell me on why those situations are bad or how they are not supposed to be that way. Do we want to change just because we have attackers taking some wins? We (defense) can’t “win” security, so will this argument be a perpetually fueled one? By the very nature of things, insecurity will always be ahead of security as one follows the other. Fundamentally, this is not a new issue with PCI or even computers.

Third, that’s not to say I’m saying we’re doing the best we can. But I’m not going to go so far as to throw up my hands and start over or think some new evolution or innovation will save us.

Let me get a few statements made that I don’t think need fancy backing statements and proofs that kind of relate to my mindset on this topic after reading his post and the comments. Really, I tried really hard to make these quick, but sadly I still fail.

1. Change is inevitable in business. (the unknown)

2. A good portion of the infrastructure does not change (the known).

3. Security needs to manage…security…for both #1 and #2.

4. Security is a function of economics.

5. We get better at managing #2 given time and resources.

6. We get better at managing #1 given resources. Time turns #1 into #2.

7. #1 introduces uncertainty and new risks, challenges, security holes. Less knowledge; often more complexity.

8. Security is not necessarily against #1, but it puts pressure to be secure and yet be economical in the business and a non-barrier. A security guard will never speed up flow past a checkpoint, he will only ever slow it down.

9. There is no “security win” or “state of security” to security geeks, but that might exist for a narrower business perspective (compliance).

10. The culture and personality of executive mgmt (or stakeholders) will determine how everything above (#1-8) are handled and in what order/magnitude.

11. We will always be better at securing the known (#2) as opposed to securing the unknown (#1). Attackers will be unpredictable in their skill at attacking #1 and #2; 0days happen in both.

12. It is as difficult for business to put security up front on par with the pace of agile/forward-thinking and new business ventures and experiments (clouds, etc) as it is for a new programmer to build security before proving that her code actually works. Likewise, it is as difficult as a start-up company having a mature infrastructure (both tech and mgmt) before they know their ideas/products are economically viable. It doesn’t work any other way! This is very hard-wired in almost everything we do that is new and bleeding edge. You plug in the cable and test connectivity before you lock down that connectivity. You have a control group before you have an experiment group. You build Facebook before you secure it.

13. Business will always reward the agile risk-takers up front, for better or worse.

14. Again, if you move forward, you can’t come close to perfect security. Truly accept that.

15. And this gets back to detection, response, visibility, transparency, standards, identification/authorization, least privilege, monitoring, logging. Things that are ongoing and don’t necessarily care or change based on legacy or bleeding-edge infrastructure. It doesn’t take an “evolved security geek” to do those things well, regardless of the level of #1 and #2 in an organization.

16. And lastly for now, while mgmt and stakeholders control the weather of corporate culture, the level of passion and enthusiasm in security geeks will determine their course of actions as well. Not the least of which is their own happiness with their current state of security and effort.

this old brain works, just a bit slow sometimes

It took about a week, but I finally remembered the essay years back by Noam Eppel: Security Absurdity: The Complete, Unquestionable, and Total Failure of Information Security. The site is now defunct, but the essay was a pointed finger at how security was not working, with promises of a follow-up with suggestions on how to fix it. No satisfying follow-up emerged, however. I mentioned it here a while back. It came to my mind last week.