Research

Really amusing considering our current discussions: How to Handle Security Problems in Your Products This is from Thomas H. Ptacek who’s blogging at matasano.com. I’m not sure how old it is. Ptacek seems to think I’m smart (which I’ll never argue with) but have nothing new to say on disclosure. He’s probably right, but since we still don’t have industry consensus around disclosure there’s still words to be written, and old thoughts to be repackaged in new ways. This is a pretty old debate; one where I don’t expect resolution just because Pete Lindstrom, Ptacek, myself, or anyone else drops some blog posts. There’s just too many competing interests… Share:

Last Friday I was packing up for a weekend trip with my wife to Tuscon when my faithful RSS reader chased me down with the latest post on Daring Fireball. I ignored it over the weekend, but think it’s time for a response. John Gruber, ever the poker player (his words, not mine) issued an open challenge to Dave Maynor and John Ellch to crack a stock MacBook. If they win, they keep it. If they can’t break in, they pay Gruber the retail price. Today John Gruber followed up with this post, upping the ante a bit and explaining why he feels this is a fair challenge. Adding to the data stream, John Ellch broke silence and released some details of a similar exploit using Centrino drivers (now patched) to the Daily Dave security mailing list. First some full disclosure of my own. I’ve been a fan of Daring Fireball for some time, John and I share a mutual friend, and we’ve traded a few emails over this. But I really wish he had handled this situation differently. I respect John, and hope this post isn’t taken out of context and used for flame bait. Now, why do I think Gruber is making a mistake? Because his challenge is putting good people in bad positions, it isn’t necessarily good for security, and he isn’t playing for the right stakes. Maynor, Ellch, and the security community in general should just ignore the challenge. Check out the original post, but John challenges Maynor and Ellch to take a stock MacBook with a basic configuration and delete a file off the desktop via remote exploit. John’s reason for the challenge? As for the earlier analogy to poker, I’m no fool. I don’t expect to lose this particular bet — but I don’t expect to win it, either. I expect to be ignored. I don’t think Maynor and Ellch have discovered such a vulnerability in the default MacBook AirPort card and driver, and so, if I’m right, they certainly won’t accept this challenge. I think what they’ve discovered — if they’ve in fact discovered anything useful at all — is a class of potential Wi-Fi-based exploit, which they demonstrated on a rigged MacBook to generate publicity at the expense of the Mac’s renowned reputation for security, but that they have not found an actual exploit based on this technique that works against the MacBook’s built-in AirPort. If I’m wrong, and they have discovered such a vulnerability, they may or may not choose to accept this challenge. But it’s a bet that they’ll only accept if they can win. It comes down to this. If I’m wrong, it’d be worth $1099 to know that MacBook users are in fact at risk. And if I’m right, someone needs to call Maynor and Ellch on their bullshit. John’s challenge is misplaced and he should drop it. Why? I know the demonstration from Black Hat is real. Why? Aside from being at the presentation I had a personal demo (over live video) or exactly what they showed in the video. I got to ask detailed questions and walk through each step. Maynor and Ellch haven’t bullshitted anyone- their demo, as shown in the video and discussed in their presentation, is absolutely real. End of story. Want to see for yourself? Read to the end and you’ll have your own opportunity. Using the third-party card for the demo is responsible: Why? Because their goal was to show a class of attack across multiple platforms without disclosing an unpatched vulnerability. By using an anonymous card no single platform is exposed. Why the Mac? Because it demonstrates that a poorly written device driver can expose even a secure system to exploit. The third-party card highlights device drivers, not the OS, as the point of weakness. They could have shown this on Windows but everyone would have assumed it was just another Windows vulnerability. But the Mac? Time to pay attention and demand more from device manufacturers. Responsible disclosure encourages staying silent until a patch is released, or an exploit appears. Why? If responsibility, protecting good guys, or potential legal issues aren’t good enough for you just understand it’s the accepted security industry practice. Some vendors and independent researchers might be willing to act irresponsibly, but I respect Maynor and Ellch for only discussing known, patched vulnerabilities. I won’t pretend there’s full consensus around disclosure; I’ve even covered it here, but a significant portion of the industry supports staying silent on vulnerabilities while working with the vendor to get a patch. The goal is to best protect users. Some vendors abuse this (to control image), as do some researchers (to gain attention), but Maynor and Ellch staying silent is very reasonable to many security experts. Remember- the demonstration was only a small part of their overall presentation and probably wouldn’t have ga ered nearly as much attention if it weren’t for Brian Krebs’ sensationalist headline. That article quickly spun events out of control and is at the root of most of the current coverage and criticism. Just confirming an exploit could hurt Maynor and Ellch: Two words: Mike Lynn. This is between Maynor, Ellch, SecureWorks, and any vendors (including Apple) they may or may not be working with. I like Daring Fireball, but SecureWorks has a history of responsible disclosure and working with affected vendors, and I see no reason for them to change that policy to satisfy the curiosity of bloggers, reporters, or any other outsider. John’s stakes are too low. He’s asking Maynor and Ellch to bet their careers against MacBooks? If John puts Daring Fireball up as his ante the bet might be fair. Besides, Maynor already has a MacBook. This challenge doesn’t help anyone. At all. Is my MacBook Pro vulnerable? I don’t know, but even if it is there’s not a damn thing I can do about it until Apple issues a patch. It’s not like I’m turning off my wireless until I hear there’s some

There are very few genuine, passionate people in this world. Today, with the death of Steve Irwin, there is one less. http://www.cnn.com/2006/SHOWBIZ/TV/09/04/australia.irwin/index.html http://animal.discovery.com/fansites/crochunter/steve/statement.html?clik=www_wh_2 Steve was a personal hero of mine. Not because of any crazy stunts, but because of his integrity, honesty, and utter dedication to his family and what he believed in. This is just a terrible loss and the only ones that matter now are his family. Although I never met Steve I was fortunate enough to visit Australia Zoo twice over the past few years. There’s not a damn thing worth saying I can say on this so I’m just posting some pictures from our last trip to Australia Zoo after the jump. When a memorial fund is established we’ll post the information here. Note: Steve wasn’t there when we’ve visited, that’s his staff in the photos: Share:

I’d like to take a moment and introduce a new contributor to Securosis. Chris Pepper is a senior systems administrator at Rockefeller University in NYC and longtime contributor to TidBITS and various other publications. Chris is one of the most knowledgeable sysadmins I’ve ever known and the first person I turn to when I need command-line support on various *nix flavors or Mac. Chris and I have been friends since sometime near the end of high school (we went to different schools). I was insanely jealous of his Apple Newton and after years of debate he’s the one that finally convinced me to give Macs a shot (I mostly use Macs these days). He’s often reviewed my work before publication and his skills as an editor are frightening. I’ve asked Chris to join Securosis as a contributor due to his perspective as an end-user. He’s not a security vendor, out-of-date industry analyst (that’s me), full-time security professional, or even product vendor. Chris works at a major university dealing with security issues on a daily basis as an adminsrator. Over the years Chris has hosted my personal domains out of his apartment and his attention to detail with regards to security is far beyond most of the professional services I’ve used. He’s even discovered a few vulnerabilities in the course of his admin duties. Chris’ personal blog is located at http://www.reppep.com/weblog/pepper/ He’s here to keep us security pundits honest and bring a little bit of the real world into our discussions… Share:

Rich, It feels heretical, but I can agree that obscurity can provide some security. The problem comes when people count on secrecy as their only or primary security. Jim: “Oh, we don’t have to encrypt passwords. Sniffing is hard!” Bob: “Hey, thank you for those credit card numbers!” Jim: “What?” Bob: “Ha ha, my friend Joe got a job at your ISP about a year ago, and started looking for goodies.” Vendor: “Nobody will ever bother looking in the MySQL DB for the passwords.” Cracker: “0WNED! Thank you, and let’s see how many of your users use the same passwords for their electronic banking!” Vendor: “But nobody else has access to the server!” Cracker: “But I found a hole in your PHP bulletin board. Game over, man!” GeniousDood: “I just invented a perfect encryption algorithm! Nobody will ever break it!” Skeptic: “How do you know?” GeniousDood: “I checked. It’s unbeatable.” Skeptic: “Thanks, but I’ll stick with something at least one disinterested person has confidence in – preferably Schneier.” IT Droid: “Check out our new office webcam! It’s at http://camera.example.com ” Paranoid: “What’s the password?” IT Droid: “Password? No-one’s ever going to find it.” Paranoid: “Google did.” I can accept that obscurity makes cracking attempts more difficult. This additional difficulty in breaking into a system might be enough to discourage attackers. Remember – you don’t have to outrun the bear, just your slowest friend! Also, if you have a short period before the fix is available, during which there is a gaping hole in your defenses, obviously it’s going to be easier for people to exploit if they have full details, so it’s hard to see how full disclosure could ever look like a good thing to a commercial vendor. On the other hand, open source projects are more likely to benefit from full disclosure, as it substantially widens the pool of people who can provide a patch, and open source communities attract people who want to deal with security problems themselves (certainly many more Linux & FreeBSD admins want to patch Sendmail or BIND, than Windows users want to patch IE or their DLLs). Security companies are like this too – they want enough info to protect their customers. Restricted access information is fine, as long as the security companies are on the list – such access becomes another asset for the security vendor. But back to obscurity: it can be used as one component in a layered defense, or it can be used as the only defense. One is useful, the other is dumb. Alternatively, obscurity can be used as a temporary barrier: “It will take them a few days to figure out how to break IE, so we’ll get a chance to distribute the patch before they can start attacking our users.” This is a very different proposition than “permanent obscurity” as (hopefully part of) a defense. The problem, of course, is that not everybody gets the patch immediately. Some people don’t because they don’t know about it, others because they have important systems which they can’t change – perhaps because the risk of breakage is unacceptable, or the “fix” is unacceptable. This may last a few days, or forever. Some people don’t have the bandwidth (full dot upgrades for Mac OS, and Service Packs for Windows, are large downloads), and may or may not get the upgrades another way. Some just don’t want to be bothered, and believe they’re invulnerable. Others cannot afford the upgrades. So those people may have no defense aside from obscurity, and they are vulnerable; on the Windows side, they tend to get hacked. Obscurity is just not a good long-term defense, since most secrets leak eventually, and patches can be reverse-engineered to find the hole. This leads into the issue of vendors who don’t patch in a timely manner, but I have to leave something for Rich to rant about… Share:

I like to think Richard Stiennon and I are good friends. He was at my wedding in Mexico. I took him and his son skiing up at Copper Mountain where I used to patrol. For a time he even rented space in my condo in Boulder while I was slowly moving to Phoenix. We’d swap my car out at the airport parking lot; it was very convenient. But I never suspected he was so violent. Goes to show you that you can never really know someone. It all started with this post on his blog where he advocates smashing old hard drives rather than taking the risk of the data being later recovered. I thought, “okay, he’s just trying to make a point”. But yesterday, over at Emergent Chaos, he expanded his violent tendencies towards cell phones in this post. Now I’m worried. I mean this is a man I’ve left in my home, who spent evenings in Mexico drinking with my family members. I’ve even loaned him my cellphone for the occasional call! I feel lucky it came back in one piece. Maybe because I had it in silent mode or something. But here’s some food for thought. I was talking to a client a while back about old hard drives. They were considering encryption since their SAN (Storage Area Network) was managed by their reseller who frequently swapped out failed drives. They looked at degaussing or smashing the drives- just as RIchard suggested. The cost? $8,000,000.00 a year. $8M a year. Wow. That’s a fair amount of cash, even with the weakened dollar. And those cell phones? The pollutants in them are pretty potent and many recycled phones end up in needy hands. So Richard might want to consider other options. We estimated that client would only need to pay $100,000-$200,000 to encrypt that SAN. Keys are stored externally so the data is unrecoverable. And portable devices? If there’s something sensitive on them you should really be encrypting them anyway. People lose those things you know. Richard- I know a good anger management therapist. Call me, your friends are worried. Share:

I generally don’t discuss “industry” issues here since that’s what I get paid to do at my day job. And if I start offering for free here, what I get paid to do over there, I may find myself offered the opportunity to do it for free on a permanent basis. Mike Rothman runs one of the better industry-oriented blogs. He and I used to sit across the table when he ran marketing for one of the vendors I cover. I like Mike a lot better as an analyst. He’s running an interesting debate on the problems with the security market. The debate started with an article in Dark Reading, moves to Mike’s blog here, Alan Shimel responds, then Mike gets the last word (for now). At the crux of their debate is the honesty of vendors and the aggressiveness of their sales and marketing tactics. My opinion? I work with many excellent security vendors who are out to protect their customers and fairly make a little money on the way. But, every single day, either directly to me, or relayed by my clients, vendors misrepresent their products or outright lie about capabilities. Usually it’s the marketing or sales teams, not the product teams. Do all vendors lie? No, but the good vendors out there are frequently forced into bad positions by their less scrupulous competition. Yes, vendors lie. So does your Mom (remember the tooth fairy) but that doesn’t make her the embodiment of pure evil. Probably. And some of this is simply passion for their products. Everyone thinks their baby is the best looking, smartest, most talented in the world, but there are still a lot of dumb, ugly, couch potatoes. If you don’t believe in what you do you shouldn’t be doing it. So how do you cut through the crap? My self serving answer is use your friendly neighborhood analyst. The biggest part of our job, at least for those of us who are end user focused, is to help make appropriate buying decisions and separate hype from reality. Our testing lab is the production environment of our end user clients- if a product doesn’t work, we’ll eventually hear about it. But if you don’t trust or can’t afford an analyst firm just do what we do. Ask your vendors for customer references in production deployments; if a feature isn’t in production, with a reference-able client, it isn’t real. Then talk to your network and see what other companies like yours are doing and if any have deployed the product. Let’s be honest- most of you readers are either security-types, or at least have a passing interest in security. It’s not like we trust anyone anyway. Share:

I’ve been publishing for in various formats for nearly 10 years now, and I have to admit I’m really enjoying some of the features of blogging. Aside from writing in a more personal voice, I actually appreciate the near instant feedback- from anyone- anywhere- of the blogosphere. I actually enjoy having my ideas challenged and debated. A couple days ago I posted a somewhat lengthy rant on disclosure. Not that I think disclosure is bad, but that we aren’t always willing to discuss the deeper motivations of those involved, on all sides, and admit that in many cases the process can favor the bad guys. In the information security world we often state that “security through obscurity” never works and secrets always leak. I stated: But in the world of traditional security, obscurity sure as hell works. Not all bad guys are created equal, and the harder I make it for them to find the hole in my security system, the harder it is for a successful attack. Especially if I know where the hole is and fix it before they find it. Secrets can be good. And Martin Mckeay called me on it here. So did the ever-present Mike Rothman here. Martin stated: One more minor issue I have with the article is the use of security through obscurity: while this works for a while, security through obscurity is the most brittle of all types of security. All it takes is one hacker releasing his notes on your security vulnerability and what little security you had because of the lack of knowledge is gone. I sure don’t want my bank relying on security through obscurity to protect my bank account. Not that they’d get much right now, a couple of days before the end of the month I agree completely. Martin’s bank funds are running a little low Security through obscurity only works for a limited amount of time. Eventually someone will reverse engineer the patch or figure out the vulnerability on their own. Also while it might now be important for every sysadmin to know the details of a flaw, it’s sure important for security vendors to get a peek before the bad guys so the good guys can try and shield any attacks. Mike says, Since most of the bad guys would just as soon take the path of least resistance, obscuring information about vulnerabilities is a short term strategy that works. And that’s the point I meant to make. These days a few weeks can mean the difference between completely shielding and patching your environment, or getting nailed by the early exploits. This wasn’t true a few years ago, but it’s true today. Automated tools are making exploit development much easier and faster- we need to start dropping some obstacles. We’re just trying to slow down the mass exploits and the script kiddies long enough to give us a fighting chance. That said product vendors need to work more with security vendors on “staged disclosure” (I like to make up phrases, later I’ll make up an acronym just for the fun of it). Security vendors need more detailed vulnerability details to better tune their products before exploits appear. They shouldn’t have to reverse engineer product patches to do this. This also means those security vendors need to share vulnerability details instead of treating them like their own IP. Finally, product vendors need to provide their customers enough information for them to make an appropriate risk decision. Too much information helps the bad guys, but too little hurts the good guys. Then again, perhaps that’s just responsible disclosure… (edited 9/1 ) Just to clarify- I, in no way, think security through obscurity alone is a meaningful security control on its own. I think it can be a useful tool to buy us time, but we should never rely on it. It’s just too fragile. Share:

Guess where I spent the day? I’ll warn you now, I have a bad habit of taking metaphors too far. Security is like dentistry: It costs more than you think it should. It’s more painful than the providers ever tell you. If you don’t keep up with ongoing maintenance it costs A LOT more and is WAY more painful. It’s really hard to find a good provider. Most vendors prey on fear. Some vendors sell a pretty smile, not that their products actually work. If you make decisions based only on financial Return On Investment you’ll really screw things up. and finally, < p style=”text-indent:20pt;”>8. No matter how many times you strap someone to a chair, shine a light in their face, and poke them with sharp objects until they bleed you can’t make them any smarter. Time to go rinse… (edited 8/31 adding point 7) Share:

As a child one of the first signs of my budding geekness was a strange interest in professional “lingo”. Maybe it was an odd side effect of learning to walk at a volunteer ambulance headquarters in Jersey. Who knows what debilitating effects I suffered due to extended childhood exposure to radon, the air imbued with the random chemicals endemic to Jersey, and the staccato language of the early Emergency Medical Technicians whose ranks I would feel compelled to join later in life. But this interest wasn’t limited to the realm of lights and sirens; it extended to professional subcultures ranging from emergency services, to astronauts, to the military, to professional photographers. As I aged and even joined some of these groups I continued to relish the mechanical patois reserved for those earning expertise in a domain. Lingo is often a compression of language; a tool for condensing vast knowledge or concepts into a sound byte easily communicated to a trained recipient, slicing through the restrictive ambiguity of generic language. But lingo is also used as a tool of exclusion or to mask complexity. The world of technology in general, and information security in particular, is as guilty of lingo abuse as any doctor, lawyer, or sanitation specialist. Nowhere is this more apparent than in our discussions of “Disclosure”. A simple term evoking religious fervor among hackers, dread among vendors, and misunderstanding among normal citizens and the media who wonder if it’s just a euphemism for online dating (now with photos!). Disclosure is a complex issue worthy of full treatment; but today I’m going to focus on just 3 dirty little secrets. I’ll cut through the lingo to focus on the three problems of disclosure that I believe create most of the complexity. After the jump that is… “Disclosure” is a bizarre process nearly unique to the world of information technology. For those of you not in the industry, “disclosure” is the term we use to describe the process of releasing information about vulnerabilities (flaws in software and hardware that attackers use to hack your systems). These flaws aren’t always discovered by the vendors making the products. In fact, after a product is released they are usually discovered by outsiders who either accidentally or purposely find the vulnerabilities. Keeping with our theme of “lingo” they’re often described as “white hats”, “black hats”, and “agnostic transgender grey hats”. You can think of disclosure as a big-ass product recall where the vendor tells you “mistakes were made” and you need to fix your car with an updated part (except they don’t recall the product, you can only get the part if you have the right support contract and enough bandwidth, you have to pay all the costs of the mechanic (unless you do it yourself), you bear all responsibility for fixing your car the right way, if you don’t fix it or fix it wrong you’re responsible for any children killed, and the car manufacturer is in no way actually responsible for the car working before the fix, after the fix, or in any related dimensions where they may sell said product). It’s really all your fault you know. Conceptually “disclosure” is the process of releasing information about the flaw. The theory is consumers of the product have a right to know there’s a security problem, and with the right level of details can protect themselves. With “full disclosure” all information is released, sometimes before there’s a patch, sometimes after; sometimes the discoverer works with the vendor (not always), but always with intense technical detail. “Responsible disclosure” means the researcher has notified the vendor, provided them with details so they can build a fix, and doesn’t release any information to anyone until a patch is released or they find someone exploiting the flaw in the wild. Of course to some vendors use the concept of responsible disclosure as a tool to “manage” researchers looking at their products. “Graphic disclosure” refers to either full disclosure with extreme prejudice, or online dating (now with photos!). There’s a lot of confusion, even within the industry, as to what we really mean by disclosure and it it’s good or bad to make this information public. Unlike many other industries we seem to feel it’s wrong for a vendor to fix a flaw without making it public. Some vendors even buy flaws in other vendors products; just look at the controversy around yesterday’s announcement from TippingPoint. There was a great panel with all sides represented at the recent Black Hat conference. So what are the dirty little secrets? Full disclosure helps the bad guys It’s about ego, control, and competition We need the threat of full disclosure or vendors will ignore security There. I’ve said it. Full disclosure sucks, but many vendors would screw their customers and ignore security without it. Some of full disclosure originates with the concept that “security through obscurity” always fails. That if you keep a hole secret, the bad guys will always discover it eventually so it’s better to make it public so good guys can protect themselves. We find the roots of the security through obscurity concept in cryptography (early information security theory was dominated by cryptographers). Secret crypto techniques were bad, since they might not work; opening the mathematical equations to public scrutiny reduces the chances of flaws and improves security. As with many acts of creation it’s nearly impossible to accurately proof your own work [as my friend and unofficial editor Chris just pointed out]. But in the world of traditional security, obscurity sure as hell works. Not all bad guys are created equal, and the harder I make it for them to find the hole in my security system, the harder it is for a successful attack. Especially if I know where the hole is and fix it before they find it. Secrets can be good. The more we disclose, the easier we make life for the bad guys. “Full disclosure” means we release all the little details. It