Research

Catching up from last week I saw this article in Techworld (from NetworkWorld) about an IETF meeting to discuss the impact of Dan Kaminsky’s DNS exploit and potential strategies for hardening DNS. The election season may be over, but it’s good to see politics still hard at work: One option is for the IETF to do nothing about the Kaminsky bug. Some participants at the DNS Extensions working group meeting this week referred to all of the proposals as a “hack” and argued against spending time developing one of them into a standard because it could delay DNSSEC deployment. Other participants said it was irresponsible for the IETF to do nothing about the Kaminsky bug because large sections of the DNS will never deploy DNSSEC. “We can do the hack and it might work in the short term, but when DNSSEC gets widely used, we’ll still be stuck with the hack,” said IETF participant Scott Rose, a DNSSEC expert with the US National Institute for Standards and Technology (NIST). Look, any change to DNS is huge and likely ugly, but it’s disappointing that there seems to be a large contingent that wants to use this situation to push the DNSSEC agenda without exploring other options. DNSSEC is massive, complex, ugly, and prone to its own failures. You can read more about DNSSEC problems at this older series over at Matasano (Part 1, Part 2, site currently experiencing some problems, should be back soon). The end of the article does offer some hope: The co-chairs of the DNS Extensions working group said they hope to make a decision on whether to change the DNS protocols in light of the Kaminsky bug before the group’s next meeting in March. ” We want to avoid creating a long-term problem that is caused by a hasty decision,” Sullivan said. “There are big reasons to be careful here. The DNS is a really old protocol and it is fundamental to the Internet. We’re not talking about patching software. We’re talking about patching a protocol. We want to make sure that whatever we do doesn’t break the Internet.” Good- at least the chairs understand that rushing headlong into DNSSEC may not be the answer. We might end up there anyway, but let’s make damn sure it’s the right thing to do first. Share:

Since I get asked this question a lot: Call yourself an analyst. Convince someone to call you an analyst. Business cards don’t hurt. (P.S.- Being a good analyst? Totally different story, although you still start the same way.) Share:

Experts: Cyber-crime as Destructive as Credit Crisis Bullshit. Share:

Last week the SBN died as Google decided to drop support for Feedburner groups during their transition of Feedburner to Google’s platform. Alan Shimel worked hard behind the scenes, and the new SBN is hosted over here at Lijit. Huge thanks to Alan and Lijit for saving the SBN, and please redirect your browsers and readers to http://security.lijitnetworks.com/. It’s a little rough right now, but more updates and fixes should be out soon. Share:

After this week, Rich and I are “Home for the Holidays”, with the last of the year’s travel behind us. We have started work on our Web Application Security Program, and in keeping with our dedication to transparency in our research, we will be posting research notes for comments here on the blog during the next couple of weeks. We’re the first to admit that more of our revenue comes from sponsors/vendors than end users, but we believe that total transparency in our research process can help weed out any overt or subconscious bias and keep us honest. And let’s face it- we want to give you free stuff, and this is the only way I can do that and keep all my dogs fed. Rich and I are looking forward to avoiding the airports during the holidays and we should be pumping out a ton of research to close out our year. Now on to the week’s security summary: Webcasts, Podcasts, Outside Writing, and Conferences: Rich was in Mi esota this week, meeting with clients and giving his DLP pitch, at a T-Wolves game before returning. (No, he didn’t wear a gorilla suit, and no flaming rings were involved). On the Network Security Podcast this week, Martin and Rich interviewed Glenn Fleishman on the recent WPA crack and more. CSO Magazine published seven of Rich’s predictions for 2009. Not one involves Hoff or SCADA. Rich wrote a TidBITS article on how the new anti-phishing features work (or don’t) in Safari. This one really isn’t Apple’s fault, he’s just not a fan of Extended Validation certificates, and hopes users don’t rely on a blacklist filter to completely protect themselves. Favorite Securosis Posts: Rich: Gives his perspective on the evolution of, and current challenges facing, Building a Web Application Security Program. Adrian: Rich’s post on Microsoft’s move to give AV away to Windows users. Favorite Outside Posts: Adrian: Amrit Williams’ humorous look at great Tech Failures. Rich: Gunnar Peterson’s lecture on security, economics, and breaches: The Economics of Finding and Fixing Vulnerabilities in Distributed Systems. I may not agree with all of it, but this is exactly the kind of perspective we need to develop more in security professionals. Top News: The big news all week has been the automobile manufacturers in Washington looking for bailout loans. The political game has been high drama, with both sides accusing each other of ineptitude. Oh yeah, that whole Stock Market bug-a-boo. Anyone think we will drop to 6k before this is all over? 5k? You didn’t own stocks, did you? Deja Vu all over again … IT functions being outsourced during tough economic conditions. What’s next, call centers in India? The Metasploit Framework, version 3.2 has been released. Not security related, but this parody of the real estate crisis is just too funny not to share. The Chinese Hacker Flowchart. Nothing new, but interesting anyway. Google is supporting OAuth for secure mashups. I’d like to dig into the model more and see if a malicious gadget can use this to compromise credentials. At a minimum, it will likely enable easier CSRF. We finally have users suspicious about installing desktop apps, but now we have to explain why online gadgets/widgets are also dangerous. Sigh. Massachusetts privacy law includes security standards. Most of which just require documentation, and other than encryption very little security. Blog Comment of the Week: From ‘ds’, on Building A Web Application Security Program: Looking forward to this series. I undertook this process last year with much success. It was something that benefited the business, with an ability to conduct testing more regularly than could be done with externals as well as more affordably. It also provided a nice career path for the technical team members and raised the profile of security as something more than just a specialized system administrator. We’ve gotten more “good press” with our business leadership on this than most anything else we’ve done. Share:

Well, they’ve finally done it. Microsoft announced they will be dropping OneCare and start providing antivirus for free to all Windows users late next year in a product called Morro. I consider this an extremely positive development, and no surprise at all. Back when Microsoft first acquired an AV company I told clients and reporters that Microsoft would first offer a commercial service, then eventually include it in Windows. Antivirus and other malware protections are really something that should be included as an option in the operating system, but due to past indiscretions (antitrust) Microsoft is extremely careful about adding major functionality that competes with third party products. The move to free AV for all Windows users helps on two fronts. First, it’s a good way to navigate the antitrust allegations that will likely surface from the consumer AV companies. By not including AV with the default installation of Windows, it keeps the competitive environment open and provides Microsoft a good defense for monopoly allegations. Second, I suspect this will only be available to legitimate, activated copies of Windows, which provides additional incentive to purchase a legal copy and stem a small part of the home piracy market. This won’t matter to the street vendors in China, but will encourage friends and family to buy their own damn copy of Windows. The major AV companies have long expected this move. Both McAfee and Symantec have been buffering themselves through diversification and acquisition for the past few years. My personal belief was that Symantec acquired Veritas in large part to prepare for the eventual dissolution of the consumer AV market when Microsoft eventually builds it into the OS. Will this hurt? Absolutely, but they probably won’t see any market erosion at all for 2 years, and the real pain will likely only start to hit in around 3 years. This gives them enough time to avoid suddenly losing 40% (don’t quote me on that, I’m on an airplane and just guessing) of profits over 12 months. The real losers will be the consumer-only AV companies with portfolio diversification or a larger enterprise base. I don’t expect to see material erosion of the enterprise AV market anytime soon. Major vendors like Symantec, McAfee, and Trend are including growing functionality in their endpoint products, and improving central management. These additional features will likely protect their enterprise client base, although there may be some price erosion. Any consumer oriented AV product will need to seriously innovate to survive once Morro is released. Users won’t be willing to pay the $70-$99 a year AV tax once a viable, easy to download and use, product appears. Microsoft already includes a good firewall in the OS, the Malicious Software Removal Tool, anti-phishing, and other security controls. Vista is much more secure than previous versions of the OS, and it sounds like Windows 7 will actually be usable. This combination means that any consumer “AV” company will need to either protect against new threats not covered by Windows, or offer materially better security than the built in tools. Both situations rely heavily on the threat environment, making accurate predictions difficult. My rough guess is that within 5-7 years most consumer-level Windows users won’t need third party desktop security. I’m not sure if it will be in WIndows 7, but it’s also clear that it’s inevitable that AV will be included in WIndows. In summary, this is good for users, will really hurt any consumer-only AV company, will only moderately hurt enterprise and diversified AV companies, and is an extremely positive step. Unless, of course, they screw it up or the product is crap. Those are always options. The flight attendant is giving me a nasty look, so it’s time to upload this and turn off my laptop… Share:

I realize this might shock our fair readers, but once upon a time I used to get my hands dirty with a little hands on web application development. Back in the heady early days of the mid-1990’s Internet I accidentally transitioned from a systems and network administrator to a web application developer and DBA at the University of Colorado’s Graduate School of Business. It all started when I made the mistake of making an incredibly ugly home page for the school, complete with a tiled background of my Photoslop-embossed version of the CU logo (but, thankfully, no BLINK tag). The University took note, and I slowly migrated out of keeping the network running into developing database driven web applications for a few thousand users. Eventually I ran my own department before setting off into the big bad world of private consulting. To this day I’m still proud of our online education tools that could totally kick Blackboard’s ass, but I think I developed my last application around 2001. I’ll be the first to admit that my skills are beyond stale, and the tools and techniques now available to web application developers are simply astounding. When I first started out in Boulder, Colorado I’d say the majority of web site developers I met were more focused on graphics skills than database design and proper user authentication. Today’s web application developers need a background in everything from structured programming, to application design, to a working knowledge of multiple frameworks and programming languages. Current web applications exist in an environment that is markedly different from the early days of businesses entering the Internet. They’ve become essential business tools interconnecting organizations in ways never anticipated when the first web browsers were designed. These changes have occurred so rapidly that, in many ways, we’ve failed to adapt our operational processes to meet current needs. This is especially apparent with web application security, where although most organizations have some security controls in place, few organizations have a comprehensive web application security program. This is a concern for two reasons. First, the lack of a complete program materially increases the chance of failure resulting in a loss-bearing security breach. Second, the lack of a coordinated program is likely to increase overall costs- not just losses from a breach, but the long term costs of maintaining an adequate security level (adequate being defined as meeting all compliance obligations and reducing losses to an acceptable level). This series of posts will show you how to build a pragmatic web application security program that constrains costs while still providing effective security. Rather than digging into the specific details of any particular technology, we’ll show you all the basic pieces and how to put them together. We’ll start with some background on how web applications are different than traditional enterprise applications or commercial off-the-shelf products. We’ll provide basic business justifications for investments in web application security you can use to gain management support (although we’ll be covering these in more depth in future research). The bulk of this series will then focus of the particular security needs of web applications, before delving into details on the major security components and how to pull them together into a complete program. Eventually we plan on releasing this as a white paper, and we already have one sponsor lined up (sponsors can redistribute the content and are acknowledged in the paper, but have no influence on content- it’s just an advertising spot within the larger paper). As with all of our research we rely on you, our readers, to keep us honest and accurate as we develop the research. Technically all analysts do that, but we actually admit it and prefer to engage you directly out in the open- so please comment away as we post. Since I’ve already wasted a ton of space setting up the series, today we’ll just cover the web application security problem. Our next post will provide business justifications for investing in a web application security program, and guidance on building a structured program. The Web Application Security Problem Enterprise web applications evolved in such a way that they’ve created a bit of a conundrum for security. Although we’ve always been aware of them, we initially treated them as low-risk endeavors almost fully under the control of the developers creating them. But before we knew it, they transitioned from experimental programs to critical business applications. Ask any web application developer and they can tell you the story of their small internal project that became an essential business application once they made the mistake of showing it off to a business unit or the outside world. We can break this general evolution down into some key trends creating the current security situation: Before web applications, few businesses exposed their internal transactional systems to the outside world. Even those businesses which did expose systems to business partners on a restricted basis rarely exposed them directly to customers. Web applications grew organically- starting from informational websites that were little more than online catalogs, through basic services, to robust online applications connected to back end systems. In many cases, this transition was the classic “frog in a frying pan” problem. Drop a frog into a hot frying pan, and it will hop right out. Slowly increase the heat, and it will fry to death without noticing or trying to escape. Our applications developed slowly over time, with increased functionality, leading to increased reliance, often without the oversight they might have gotten had they been scoped as massive projects from the beginning. Web application protocols were designed to be lightweight and flexible, and lacked privacy, integrity, and security checks. Web application development tools and techniques evolve rapidly, but we still rely on massive amounts of legacy code. Both internal and external systems, once deployed, are nearly impossible to simply shut down and migrate to new systems. Web application threats evolve as quickly as our applications, and apply to everything we’ve done in the past.

Brian Krebs posted a follow up article on the takedown of fraudulent hosting provider McColo (facilitated by his initial reporting last week). If you think all the nasties out there are hosted in Russia or China, you should really read his article. McColo’s servers weren’t sending out the actual spam; they functioned as the command and control infrastructure for some of the world’s biggest botnets. For those of you who don’t know, spam is rarely sent from static servers anymore; it originates from botnets scattered around the world that are directed by their control network to issue once in a lifetime offers for the best possible deals on male enhancement products. (It’s nice to know everyone has small weewees and lasts about 8 seconds, since otherwise this stuff wouldn’t be so profitable). Since the spam originates from tens of thousands of different systems, it makes it nearly impossible to blacklist based just on IP address. McColo hosted major components of the command infrastructure for spewing out your totally legitimate university diplomas (for a small fee). All those little bots are still out there, but no one is telling them what to do. As Krebs reports, it’s only a matter of time before the network owners reassert control and we can get back to purchasing discount medications and finding true love in former Soviet countries. But what if we took control ourselves and locked out the network? Those servers are still sitting in some building in California, and the ISPs still control the IP addresses. Imagine what we could do if we sent in a research team (or law enforcement) to commandeer all those bots and lock the bad guys out. Yes folks, this is just fantasy today. We don’t have the legal framework to execute such a project without creating risk for the good guys involved. Sure, we could use the botnet to patch all the compromised systems, but that’s effectively breaking into someone’s computer and making changes. I dream of a day when we can more effectively take the fight to the bad guys without worrying about going to jail ourselves. There’s absolutely no chance we can continue this fight indefinitely if we’re always on the defense. But we’re a long way off from having the legal framework and institutions to effectively stand up for ourselves. Share:

Edited: I stupidly credited Nate Lawson for Mark Dowd’s work with Sotirov. Dumb mistake, and I apologize. Since my travel is slowing down a bit, I’m finally able catch up a little on my reading. Two articles this week reminded me of something I’ve been meaning to talk about. First, Chris Wysopal talks about how we’ve reached an application security tipping point. How the OS vendors are doing such a (relatively) good job at hardening the operating system that it’s become easier and more lucrative for attackers to go after common applications. Since nearly everyone online has a reasonably common set of Internet-enabled desktop apps running, it’s nearly as effective as targeting the OS. Heck, in some cases these apps are cross platform, and in a few cases we even see cross platform exploits. To top it off, many of these applications do not activate or use anti-exploitation features like ASLR or DEP, even when it’s little more than a checkbox during the development process. Thus, as we saw during Alex Sotirov and Mark Dowd’s demo at Black Hat this year, you can use these applications to totally circumvent host operating system security, even through the web browser. As Chris states: Whoa. Millions of dollars spent on securing the most prevalent piece of software and it could be meaningless? Yes, it’s true. Since attackers typically only need one vulnerability, if it isn”t in the network, and it isn”t in the host configuration, and it isn”t in the OS, they will happily exploit a vulnerability in an application. Mike Andrews also nails it: They don’t just go away, they go to the next level of lowest hanging fruit. It might be other vendors (Apple, Adobe, Google for example) which may not have the focus that Microsoft has been forced to have, or even worse, smaller players like custom websites or things like WordPress, Movable Type, phpbb, vbulletin, etc — software that has a huge install base, but perhaps not the resources to deal with a full-frontal attack. …snip… Think of it security”s own Hydra — cut of one head (vulns in a major vendor), two grow back (vulns in smaller vendors), and that”s a worrying proposition. As I often say on this blog we have a term for this… it’s called job security. Share:

Here’s a valuable lesson for you college students out there, from Dave Meizlik: if your professor is married to one of the leads at a DLP vendor, think twice before plagiarizing a published dissertation. We talked generally for a while about the problem and then it hit me what if I downloaded a bunch of relevant dissertations, fingerprinted them with a DLP solution, and then sent the girls dissertation through the systems analysis engine for comparison? Would the DLP solution be able to detect plagiarism? It almost seemed too simple. … So when we got home from lunch I started up my laptop and RDP”d into my DLP system. I had my wife download a bunch of relevant dissertations from her school”s database, and within minutes I fingerprinted roughly 50 dissertation files, many of which were a couple hundred pages in length, and built a policy to block transmission of any of the data in those files. I then took her students dissertation and emailed it from a client station to my personal email. Now because the system was monitoring SMTP traffic it sent the email (with the student”s paper as an attachment) to the content analysis engine. I waited a second another and then I impatiently hit send receive and there it was, an automated notification telling me that my email had violated my new policy and had been blocked. I suspect that’s one grad student who’s going to be serving fries soon… Share: