Research

If you have read my overviews of Oracle database patches long enough, you probably are aware of my bias against the CVSS scoring system. It’s a yardstick to measure the relative risk of the vulnerability, but it’s a generic measure, and a confusing one at that. You have to start somewhere, but it’s just a single indicator, and you do need to take the time to understand how the threats apply (or don’t) to your environment. In cases where I have had complete understanding of the nature of a database threat, and felt that the urgency was great enough to disrupt patching cycles to rush the fix into production, CVSS has only jibed with my opinion around 60% of the time. This is because access conditions typically push the score down, and most developers have pre-conceived notions about how a vulnerability would be exploited. They fail to understand how attackers turn all of your assumptions upside down, and are far more creative in finding avenues to exploit than developers anticipate. CVSS scores reflect this overconfidence. Oracle announced the July 2009 “Critical Patch Update Advisory” today. There are three fairly serious database security fixes, and two more for serious issues for secure backup. The problem with this advisory (for me, anyway) is that none of my contacts know the specifics behind CVE-2009-1020, CVE-2009-1019 or CVE-2009-1963. Further, NIST, CERT, and Mitre have not published any details at this time. The best information I have seen in Eric Maurice’s blog post, but it’s little more than the security advisory itself. Most of us are in the dark on these, so meaningful analysis is really not possible at this time. Still, remotely exploitable vulnerabilities that bypass authentication are very high on my list of things to patch immediately. And compromise of the TNS service in the foundation layer, which two of the three database vulnerabilities appear to be, provides an attacker both a method of probing for available databases and also exploitation of peer database trust relationships. I hate to make the recommendation without a more complete understanding of the attack vectors, but I have to recommend that you patch now. Share:

I am kind of a car nut. Have been since I was little when my dad took me to my first auto race at the age of four (It was at Laguna Seca, a Can-Am race. Amazing!). I tend to get emotionally attached to my vehicles. I buy them based upon how they perform, how they look, and how they drive. I am fascinated by the technology of everything from tires to turbos. I am a tinkerer, and I do weird things like change bushings that don’t need to be changed, rebuild a perfectly good motor or tweak engine management computer settings just because I can make them better. I have heavily modified every vehicle I have ever owned except the current one. I acknowledge it’s not rational, but I like cars, and this has been a hobby now for many years. My wife is the opposite. She drives a truck. For her, it’s a tool she uses to get her job done. Like a drill press or a skill saw, it’s just a mechanical device on a depreciation curve. Any minute of attention it requires above filling the tank with gasoline is too many. It’s stock except for the simple modifications I made to it, and is fabulously maintained, both facts she is willfully unaware of. Don’t get me wrong, she really likes her truck because it’s comfortable, with good air and plenty of power, but that’s it. After all, it’s just a vehicle. As a CTO, I was very much in the former camp when it came to security and technology. Love technology and I get very excited about the possibilities of how we might use new products, and the philosophical advantages new developments may bring. It’s common, and I think that is why so many CTOs become evangelists. But things are different as an analyst. I have been working with Rich for a little over a year now and it dawned on me how much my opinion on technology has changed, and how differently I now approach discussing technology with others. We had a conference call with an email security vendor a couple weeks ago, and they have some really cool new technology that I think will make their products better. But I kept my mouth shut about how cool I think it is because, as an analyst, that’s not really the point. I kept my mouth shut because most of their customers are not going to care. They are not going to care because they don’t want to spend a minute more considering email security and anti-spam than they have to. They want to set policies and forget about it. They want to spend a couple hours a month remediating missing email, or investigating complaints of misuse, but that’s it. It’s a tool used to get their job done and they completely lack any emotional attachment their vendor might have. Cool technology is irrelevant. It has been one of my challenges in this role to subjugate enthusiasm to practicality, and what is possible for just what is needed. Share:

While Microsoft releases patches for various vulnerabilities, including the two active zero day attacks, Firefox is being actively exploited. According to the Mozilla Security Blog, there is a flaw in how Firefox handles JavaScript. We suggest you follow the instructions in that post to mitigate the flaw until they release a patch (which should be soon). Not that we plan to post every time some piece of software is exploited or patched, but this series seems to… bring some balance to the Force. Share:

Microsoft released an advisory today that an unpatched vulnerability in the Office Web Components ActiveX control allows an attacker to run arbitrary code as the logged-in user. Worse yet, this is being actively exploited in the wild. Fortunately it is easy to protect against. For the technical details, please see the SANS Internet Storm Center post, and the official Microsoft advisory. Here’s the short version and how to protect yourself: This is a flaw in the spreadsheet ActiveX control that comes with Office. It only works if you visit a malicious link with Internet Explorer, and have a vulnerable version of Office installed (if you have Office, it’s safest to assume you are vulnerable). This does not affect Outlook, unless you click on an email link that opens Internet Explorer. It is actively being exploited by bad guys on the Internet, and Microsoft is working on a patch. If you switch to another browser, you are safe. If you still need to use IE, you can click on this link for a tool that will help disable the control. Don’t try this if you are on a work computer without talking to IT. And that’s it – no reason to panic, with plenty of ways to protect yourself. You can now safely ignore all the scary emails you’ll be getting any moment from various security vendors… (This is unrelated to the other ActiveX 0day that popped up last week and is also being actively exploited). Share:

Encrypting data within a database doesn’t always present a clear-cut value proposition. Many of the features/functions of database encryption are also available through external tools, creating confusion as to why (or even whether) database encryption is needed. In many cases, past implementations have left DBAs and IT staff with fears of degraded performance and broken applications – creating legitimate wariness the moment some security manager mentions encryption. Finally, there is often a blanket assumption that database encryption disrupts business processes and mandates costly changes to applications (which isn’t necessarily the case). To make good database encryption decisions, you’ll first need to drill down into the details of what threats you want to address, and how your data is used. Going back to our decision tree from Part 2, look at the two basic options for database encryption, as well the value of each variation, and apply that to your situation to see what you need. Only then can you make an educated decision on which database encryption best suits your situation, if you even need it at all. Use the following use cases to illustrate where and how problems are addressed with database encryption, and to walk you through the decision-making process. Use Case 1: Real Data, Virtual Database Company B is a telephony provider with several million customers, and services user accounts through their web site. The company is considering virtualizing their server environment to reduce maintenance costs, adapt to fluctuations in peak usage, and provide more options for disaster recovery. The database is used directly by customers through a web application portal, as well as by customer support representatives through a customer care application; it’s periodically updated by the billing department through week-end batch jobs. Company B is worried that if virtual images of the database are exported to other sites within the company or to partner sites, those images could be copied and restored outside the company environment and control. The principal threat they are worried about is off-site data inspection or tampering with the virtual images. As secondary goals they would like to keep key management simple, avoid introducing additional complexity to the disaster recovery process, and avoid an increased burden for day-to-day database management. In this scenario, a variant of transparent encryption would be appropriate. Since the threat is non-database users accessing data by examining backups or virtual images, transparent encryption protects against viewing or altering data through the OS, file system, or image recovery tools. Which variant to choose – external or internal – depends on how the customer would like to deploy the database. The deciding factors in this case are two-fold: Company B wants separation of duties between the OS administrative user and the database users, and in the virtualized environment the availability of disk encryption cannot be ensured. Native database encryption is the best fit for them: it inherently protects data from non-credentialed users, and removes any reliance on the underlying OS or hardware. Further, additional computational overhead for encryption can be mitigated by allocation of more virtual resources. While the data would not be retrievable simply by examining the media, a determined attacker in control of the virtual machine images could launch many copies of the database, and has an indefinite period to guess DBA passwords to obtain the decryption keys stored within the database, but using current techniques this isn’t a significant risk (assuming no one uses default or easy to guess passwords). Regardless, native transparent encryption is a cost-effective method to address the company’s primary concerns, without interfering with IT operations. Use Case 2: Near Miss Company A is a very large technology vendor, concerned about the loss of sensitive company information. During an investigation of missing test equipment from one of their QA labs, a scan of public auction sites revealed that not only had their stolen equipment been recently auctioned off, but several servers from the lab were actively listed for sale. With the help of law enforcement they discovered and arrested the responsible employee, but that was just the beginning of their concern. As the quality assurance teams habitually restored production data provided to them by DBAs and IT admins onto test servers to improve the realism of their test scenarios, a forensic investigation showed that most of their customer data was on the QA servers up for auction. The data in this case was not leaked to the public, but the executive team was shocked to learn they had very narrowly avoided a major data breach, and decided to take proactive steps against sensitive data escaping the company. Company A has a standing policy regarding the use of sensitive information, but understands the difficulty of enforcing of this policy across the entire organization and forever. The direct misuse of the data was not malicious – the QA staff were working to improve the quality of their simulations and indirectly benefiting end users by projecting demand – but had the data been leaked this fine distinction would be irrelevant. To help secure data at rest in the event of accidental or intentional disregard for data security policy, the management team has decided to encrypt sensitive content within these databases. The question becomes which option would be appropriate: user or transparent encryption. The primary goal here is to protect data at rest, and secondary is to provide some protection from misuse by internal users. In this particular case, the company decided to use user-based encryption with key management internal to the database. Encrypted tables protect against data breach in the case that should servers, backup tapes, or disks leave the company; they also address the concern of internal groups importing and using data in non-secured databases. At the time this analysis took place, the customer’s databases were older versions that did not support separation of roles for database admin accounts. Further, the databases were installed under domain administration accounts – providing full access to both application developers and IT personnel; this access is integral to the

We have a few Securosis news items that hopefully you will find useful. We get a lot of feedback and ideas from readers about how they want to use our site, or when and how they view the posts. It’s an amazingly diverse group of preferences, scattered like a shotgun blast across the spectrum of options. We hear you, so in our quest to deliver the blog content through every new media medium we think you might like, we have implemented a couple new ways to read the blog and the research library. Rich has been toiling away this past week to get an iPhone compatible site up and running. You can find it at www.securosis.com/iphone. You should consider this a beta release. There are a few bugs and behavioral issues to work out, but I don’t think Rich ever touched AJAX before this week, so he has done a pretty nice job at figuring it all out on his own. If you have comments or suggestions, or if you are an expert with AJAX and Expression Engine, by all means, please send us feedback and hints on what else you want to see. But be prepared as Rich may ask you some technical questions on debugging in return! We have also made Securosis available on the Kindle through Amazon. As you know we are not like other research firms, and we do not charge for the vast majority of our content. Rich and I had along debate on whether to do this as you have to pay for the subscription, and that’s not really our style. And heck, neither one of us even owns a Kindle, but we just plain like the idea. The Kindle is a very cool device. As far as the subscription goes, we figured you had a choice in the matter, and can visit the web site or subscribe to the RSS feed and still get all the free content. Speaking of RSS feeds, sometime in the near future, maybe even by the time you read this, we will have a dedicated Friday only RSS feed. Many of you have requested a weekly summary rather than the daily, so those who want the just the digest version, this is for you. There is also a sign up link to the right-hand menu. And now for the week in review: Webcasts, Podcasts, Outside Writing, and Conferences Rich was interviewed on Al Jazeera about the big DDoS attack that’s totally not cyberwar. Rich & Martin on the Network Security Podcast #157. Rich over at SC Magazine on Google Chrome security. Rich, again, on Chrome OS, this time at Dark Reading. And Rich’s Dark Reading column on Cloud Computing. (And no, those aren’t really security controls, sarcasm folks). Rich on dumping antivirus over at PC World. Favorite Securosis Posts Rich: The post on Creating a Standard for Data Breach Costs. Adrian: Rich’s post on how Data Labels Suck nails it for me. Other Securosis Posts The Securosis and Threatpost Black Hat Disaster Recovery Breakfast Dark Reading Column: Cloud Security Social Security Number Code Cracked Securosis: On Holiday Database Security: The Other First Steps Three Database Roles: Programmer, DBA, Architect Cracking a 200 Year Old Cipher Database Encryption, Part 5: Key Management Things To Do In Encryption When You’re Dead The Network Security Podcast, Episode 156 Project Quant Posts Mid-Project Update and Trip Report Project Quant: Document and Update Configuration Changes Project Quant: Clean Up Phase Favorite Outside Posts Adrian: James Urquhart on Three debates that will benefit Cloud Computing Rich: This isn’t just the blog post of the week, it’s the post of the year. Bow down before Shrdlu. Top News and Posts Goldman loses major source code, and possibly millions in the data theft of the year (it was an insider). Top 10 misconceptions about PCI. The DDoS attack that’s totally not cyberwar, and probably has nothing to do with North Korea. New attack on AES, but nothing to worry about. Facebook changes privacy… I hope it works out well this time, instead of that Beacon garbage. Microsoft 0day in DirectShow being exploited. Make sure you set that killbit until you can update. An 0day in Cold Fusion makes Rich sad, since he used to be a total Cold Fusion geek. JJ has a good post on NAC policies. Don’t trust her in a karaoke bar, but her NAC skills are solid. SSH 0day is probably a hoax. Apple releases an important Safari update. McAfee glitch fells PCs around the globe. More Metasploit goodness. Unisys Targets Cloud Security … it’s stealthy, all right. Blog Comment of the Week This week’s best comment comes from Patrick Florer in response to Creating a Standard for Data Breach Costs: I have been working on something similar. Distinguishing between those costs that make sense on a per record basis and those that make sense on a per incident basis is very important. Some breaches can be measured by records lost. Others, like IP theft, cannot be measured in that way, so it’s important to take that into consideration, too. As a guide, I am using the breakout of loss magnitude provided by FAIR – primary and secondary losses – and the various categories within each. Also, when talking about the “cost” of a data breach, it’s important to recognize that a number of parties might have costs – the breached entity, business partners, customers, individuals, law enforcement (hence the public at large), shareholders, etc. So it also becomes a question of whose costs we are talking about. Share:

Threatpost has an interesting article up on the latest disclosure slime-fest (originally from Educated Guesswork). It seems VoIPShield decided vendors should pay them for vulnerabilities – or else. While I personally think security researchers should disclose vulnerabilities to the affected vendors, I understand some make the choice to keep things to themselves. Others make the choice to disclose everything no matter what, and while I vehemently disagree with that approach, I at least understand the reasoning behind it. At other times, per reasonable disclosure, researchers should publicly disclose vulnerability details if the vendor is placing customers at risk through unresponsiveness. But VoIPShield? Oh my: “I wanted to inform you that VoIPshield is making significant changes to its Vulnerabilities Disclosure Policy to VoIP products vendors. Effective immediately, we will no longer make voluntary disclosures of vulnerabilities to Avaya or any other vendor. Instead, the results of the vulnerability research performed by VoIPshield Labs, including technical descriptions, exploit code and other elements necessary to recreate and test the vulnerabilities in your lab, is available to be licensed from VoIPshield for use by Avaya on an annual subscription basis. Later this month we plan to make this content available to the entire industry through an on-line subscription service, the working name of which is VoIPshield “V-Portal” Vulnerability Information Database. There will be four levels of access (casual observer; security professional; security products vendor; and VoIP products vendor), each with successively more detailed information about the vulnerabilities. The first level of access (summary vulnerability information, similar to what’s on our website presently) will be free. The other levels will be available for an annual subscription fee. Access to each level of content will be to qualified users only, and requests for subscription will be rigorously screened. If you require vendor payment for vulnerability details, but will release those details to others, that’s extortion. VoIPShield is saying, “We’ve found something bad, but you only get to see it if you pay us – of course so does anyone else who pays.” Guess what guys – you aren’t outsourced QA. You made the decision to research vulnerabilities in particular vendors’ products, and you made the decision to place those companies’ customers at risk by releasing information to parties other than the appropriate vendor. This is nothing more than blackmail. Is vulnerability research valuable? Heck yes, but you can’t force someone to pay you for it and still be considered ethical. If you demand vendor payment for vuln details, but never release them, that might be a little low but isn’t completely unethical. But demanding payment and releasing details to anyone other than the vendor? Any idiot knows what that’s called. * Image courtesy dotolearn.com. Share:

Hi folks, Sorry if I’m getting all corporate on you, but I wanted to highlight one of the new thingamajigs over here. We decided to create an email list for people who are interested in the Friday Summary. We know we pump out a ton of junk compelling content every week, but it might be a bit overwhelming in these constrained times. We try to focus on the week’s highlights every Friday and point out some of the more interesting content out there (as well as our own stuff, of course). This is a once-a-week only mailing, and we’ll never sell the list or use it for anything else. You can sign up here. We also have the Daily Digest for you gluttons who want all our posts on a daily basis. You can go back to your regularly scheduled browsing now… Share:

hold Share:

Sure, the RSA Recovery Breakfast was a huge hit, but let’s be honest – if there’s any conference that really needs a recovery breakfast it has to be Black Hat. So we decided to team up with our friends at Threatpost and throw down, Vegas style. Thus we are proud to officially announce the Securosis/Threatpost Black Hat Disaster Recovery Breakfast! We’ll be holding it Thursday morning from 8-11 at Cafe Lago in Caesar’s, which is right near the bottom of the main escalators heading up to the conference area. We’ve set it up so we get to use the main buffet, but have our own private seating area with beverage services. Just like RSA it’s an open event – drop in and out whenever you want. We realize some of you would prefer we ran it from 11 to sometime in the late evening, but some of us have to work the show and such. We’ll provide the breakfast, appropriate recovery beverages, and a fine selection of hangover recovery supplements (over the counter only). Since Vegas isn’t the cheapest place on the planet, we do have to ask that you actually RSVP this time. Please email rsvp@securosis.com with your name so we can put you on the list. (Please only RSVP if you think there’s a reasonable chance you’ll make it). Feel free to email with any questions, and we look forward to seeing you in Vegas… Share: