0day vulnerability in SMBv1/SMBv2 in Windows OS products (including 7) has been released. While this sounds like other recent similar vulns (MS09-050, MS08-067), there are differences. First, this latest one sounds like a response attack from a malicious server rather than a direct attack (meaning yes, your web browser can be tricked to making an outbound call to a malicious SMB server if your egress filters suck). Second, so far the result is “just a DoS.” Best to keep an eye on this one.

Philosecurity makes a good point about the role of airport security identification checks during inter-state travel. Does showing a “valid” ID while traveling inside the country add any security at all? My opinion is summed up by saying this whole modern concept (post 9/11) of airport security is stupid. The reasonably preventable problem from 9/11 is the taking of the cockpit (or more accurately, the taking over of flight pathing) on large aircraft. That should never have happened. That cockpit needs to be absolutely secured long enough to make emergency landings. Sure, you can still concoct film-script scenarios, but all of them are far more involved than bashing through a door by force.

Rich Mogull has two pieces that are great to read together. First, about getting tried of the “security is failing” chants. Second, about the problem of the anonymization of [cyber] losses. There are no big answers here, and some of his points are arguable, but the end conclusions I feel are sound: we’re not dying, our bank accounts are not empty, and economics plays a huge role in security. I feel a lot of the activity in metrics and risk management of the last couple years are geared towards reducing the stress of the first article, and removing the anonymity of the second article (thus paving the way for more resources for security), as opposed to many of the activities that are trying to play catch-up and stop-all directly against insecurity.

Via Twitter I see someone has taken the SSL/TLS renegotiation vulnerability and was able to inject enough to get the target to display unencrypted Twitter username/passwd combinations.

This still has some limitations, I imagine. For instance, you’d have to inject into a stream that could post or somehow redirect the unencrypted data, otherwise you’re really not getting anything or going to be able to see anything. Perhaps you can inject something that will affect the user’s browser, but I see that less as the whole attack, and rather more like a way to get in and start doing Bad Things. It’s still only half a big deal. And I’m not even talking yet that you have to be in the middle of the traffic stream.

The article says critics were somewhat dismissive of the bug initially. While that can be true to some degree, I expected it to be somewhat shunned because it is a highly technical bug and not easy to either explain to a journalist or have a journalist properly regurgitate back out for their pub. This is especially true since no one put into layman’s terms what all the techspeak meant.

UCSniff 3.0 has been released. UCSniff is a VOIP/IP Video sniffer.

Thierry Zoller discusses the recent SSL/TLS authentication gap issue (pdf). Pass this up if you want easy summaries and less technical coverage.

Nickerson mentioned this presentation on ExoticLiability 39. This is how a technical talk should go. A couple slides saying web security is a big deal, WAFs try to prevent it, and then spend the vast majority on deep details on how to bypass WAFs. If I can find the audio/video of this presentation, I think that would be even more effective than just the slides.

OWASP Top 10 RC1 (pdf) has been released. What I like about a list like this is they don’t just present the knowledge-based issues, but they also address the need for actually planning development smarter. Solving things like SQLi and XSS often comes down to being an expert coder (beyond just a functional 2+2=4 coder). There are still plenty of bonehead mistakes made in the planning and architectural stages.

You have to look out for user-supplied content, but you also have to look out for unattended user-supplied administration of things like groups: Facebook Groups can be hijacked.

I missed it, but the 60 Minutes feature on cybersecurity this weekend sparked others talking. Sounds like they prominently used the example of hackers taking down part of the Brazil power grid a couple years ago. Robert Graham at ErrataSec’s blog has posted a far more believable theory.

Via the attrition.org Twitter account comes a link comparing new media’s (TechCrunch) coverage of FaceBook ad scams versus old media’s (NY Times) coverage of the same topic. Talk about a perfect way to make a great point (not that the reverse couldn’t also be true…).

Skype in the enterprise continues to have hurdles to climb, not the least of which is the ability to easily ensure your employees are not leaking confidential information through it. If you trust the integrity of the Skype IM log files, you can work on understanding the Skype chat log file format.

MoW’s The Powershell Guy site has a nice post on how to use Powershell to convert Unix timestamps to a more readable format. My need the other day was to correlate some log entries in my IPS against my web proxy access logs.

I’ve long made it a practice to add commentary to many links I give, and not spew out too many, or make lengthy posts filled with, “go elsewhere” bits. Too often I read other blogs with lists of links and I’ll think, “I like #8 and want to check it later.”” Then I end up with orphaned browser windows/tabs/bookmarks waiting for attention or RSS reader items unread where I really have read it and only want to revisit 5% of the content.

But over time I get lots of little links stuck around here and there that I really have nothing to add to, but would like to save or point out for future or community reference. I really like Kevin’s format over at InfosecRamblings; not too long, gives some context to what I’m clicking to, and I find that they’re not always the same links as I see everywhere else. I also like to avoid posting the 14th mention or something and making it sound like my link to it is a big deal that no one else has. Those are the ones I tend to mention in one line, or not mention at all since everyone else does. I certainly hope that anyone who reads my blog here also reads many of the other great sec blogs out there that are in my reader as well (or at least people should, since my blog is geared to me more than any audience).

Anyway, long story short, I’m going to try out an irregular format of spitting out a couple links every so often to see if I like it or not. I may find it offers me nothing new…

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).

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!

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.

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.

Finally got my resume (pdf) updated with my CISSP status. The thing I hate most about resumes? Nope, it’s not the description of accomplishments. It’s the damned list of technical skills and programs I know. I try to use that as the part I tailor to job descriptions and the tools they list. Otherwise, a good IT tech simply has an aptitude to pick up and learn anything he or she doesn’t already know. I didn’t list Python? I’m confident I could pick it up quickly. But I hate feeling a little strange listing anything I’ve not professionally or extensively personally used, like Python. It’s silly how even old, stupid tools stay listed there for years…

It’s not really that often that I think user education is a solution (or close to it), as I think it is just a small sliver of a security posture in a company. One such situation is policing social networking for an organization.

I’m listening to Exotic Liability 37 and Ryan and Chris are having a great discussion on what organizations should do about social networking. I agree that companies need to have policies on social networking, but I’m sympathetic to the feeling that an organization shouldn’t be reading every post that every employee makes on their personal time, or that you have to disclose what your social networking identities are. That seems to be a huge effort for very little gain, especially as most people never post anything to do with the organization.

I agree that anything about the company should be addressed, and anything where someone may be miscontrued as speaking for the organization should be curbed. That should be done by policy and user education. As should any unauthorized use on business time when explicitly prohibited. Or maybe something like an exec making a comment on visiting Smegma, Florida, and someone knowing that a potentially bought acquired company is HQed there which could divulge big information.

But I’m not sure I can say employers should be inventorying your identities online and examining every post you make. Considering how much crap is posted to so many places compared to how much would actually damage a company, it seems like a waste of resources to watch it.

I like when the EL guys barely touched on the idea of following developers. That is one place where you really could get some information, for instance code snippets posted to a help forum. The problems here, though, are similar. How many thousands of such sites exist? And how often would those snippets and tidbits actually be useful?

I guess it all depends on the company and what their interest is in protecting information. Defense contractors, game companies, and Apple would be far different than a small business in Wichita that only serves local customers. I think a policy is necessary, user education is necessary (tailored to the level of employee), and some measure of monitoring for references to your company may be necessary. But I’m not sure monitoring individuals will offer good return for most cases.

I’ve long been somewhat anti-anti-perimeter. I understand the reason why groups of professionals will say there is no more perimeter, and I agree with most of their observations, I don’t really buy their conclusion that the perimeter is dead. I still feel there is a perimeter and there will continue to be a perimeter. It’s just not as hard and physical a stop as it used to be.

But, finally, the first real crack in the perimeter issue (at least to me) is coming from “cloud” services, like this Amazon RDS service. Basically, you want a database hosted by someone else? There you go, a MySQL instance at a third-party. Really, this is outsourcing your IT infrastructure piece by piece. This is like hooking me up to an external plasma or blood machine, and having it a critical part of my circulatory system. You’ll make me extremely nervous every time you get close to those delicate tubes and the power switch next to my bed! At least when it was inside my body, I certainly knew when something was wrong.

While I think this is a horrible approach for security (in light of our ever-increasing sensitivity to data flow, transmission, storage), I do recognize that it continues the destruction of “the perimeter.” Pretty soon we’ll have these golems out on the web where the web front-end is hosted at X, the database hosted at Y, with API calls to A-thru-M, and built with no security in mind. The silver lining? Continues the push for encryption when you’re outside the traditional perimeter. Is this bad? Who knows, maybe this will evolve into something awesome, but for now my initial feelings are quite cynical (if I were a web developer, I’d probably think the opposite!).

And like most outsourcing endeavors, I really think this will be a cool, trendy cost-saver in the very short term, but all the issues that come with “cloud” and outsourcing and trying to make a customized service into a one-size-fits-all product (study business strategy and economics to see why I make such a fuss about those two categories of product) are going to challenge this deeply beyond the next 12 months. At least with offering something narrow like a “database instance” you could maybe get away with calling this less a customized service and more a standard product. It’s definitely much better than saying something vague like, “we’ll massage data if you send it to us”. But still, it’s a very narrow piece that must rely on something else, and it is the stringing of those sorts of connections across untrusted networks that is sketchy.

Also via Chuvakin, I skimmed an article by Josh Corman on evolving security. Perusing the comments, I see good points about the vagueness on what we’re supposed to be evolving into.

This reminds me of a few years back when someone threw down a great essay on why security sucks, with the promise of a follow-up so they didn’t sound like someone just complaining. That follow-up never truly came. (Fine, it came, but it just opined about other people’s responses; hardly a half-assed fulfillment.) (I’m having a problem finding it or remembering enough specifics to search for it, but I will find it!) Update: It was Noam Eppel’s essay on the total failure of information security [now defunct] which I posted about years back

It’s one thing I’ve slowly learned (and am still learning) through my business/work experience is that you don’t often want to just rage without a plan of action. Not unless you’re aware that you’re just venting, in which case it’s ok. Otherwise the first question from anyone who helps determine your future is, “What do you suggest?” That pivotal, important question…like a knight challenging your queen on your side of the board…that if you don’t have an answer for, is the beginning of your endgame.

Especially in security, we need to step back and ask ourselves why we think security needs to evolve. Is it because we’re still insecure? If so, then you’ll rage forever because there’s no “win.” Unless we want to define “win,” which…yeah…that’s a good start. I feel this is an industry that can only define itself after the fact, rather than define some novel approach that is “oh my god” glorious and impacting. We’ll define our security methods and standards only after we try them out and see if they worked, or in what measure they worked. This is why I see ‘security’ more a science than a business discipline… *…now where’d I put my crack rock…*

On the lookout for “live” security distros? Then circle Oct 31st as the wide release date for Katana v1.0. Katana appears to be a multi-boot USB distro for security and linux geeks. From the install instructions, this seems on par with or slightly easier than those that use something like unetbootin to write a bootable image to a key.