Posts tagged vulnerabilities
Spaf Gets Interviewed
[tags]interview,certification[/tags]I was recently interviewed by Gary McGraw for his Silver Bullet interview series. He elicited my comments on a number of topics, including security testing, ethical hacking, and why security is difficult.If you like any of my blog postings, you might find the interview of some interest. But if not, you might some of the other interviews of interest – mine was #18 in the series.
8 Security Action Items to Beat “Learned Helplessness”
So, you watch for advisories, deploy countermeasures (e.g., change firewall and IDS rules) or shut down vulnerable services, patch applications, restore services. You detect compromises, limit damages, assess the damage, repair, recover, and attempt to prevent them again. Tomorrow you start again, and again, and again. Is it worth it? What difference does it make? Who cares anymore?
If you’re sick of it, you may just be getting fatigued.
If you don’t bother defending anymore because you think there’s no point to this endless threadmill, you may be suffering from learned helplessness. Some people even consider that if you only passively wait for patches to be delivered and applied by software update mechanisms, you’re already in the “learned helplessness category”. On the other hand, tracking every vulnerability in the software you use by reading BugTraq, Full Disclosure, etc..., the moment that they are announced, and running proof of concept code on your systems to test them isn’t for everyone; there are diminishing returns, and one has to balance risk vs energy expenditure, especially when that energy could produce better returns. Of course I believe that using Cassandra is an OK middle ground for many, but I’m biased.
The picture may certainly look bleak, with talk of “perpetual zero-days”. However, there are things you can do (of course, as in all lists not every item applies to everyone):
- Don’t be a victim; don’t surrender to helplessness. If you have limited energy to spend on security (and who doesn’t have limits?), budget a little bit of time on a systematic and regular basis to stay informed and make progress on tasks you identify as important; consider the ones listed below.
- Don’t be a target. Like or hate Windows, running it on a desktop and connecting to the internet is like having big red circles on your forehead and back. Alternatives I feel comfortable with for a laptop or desktop system are Ubuntu Linux and MacOS X (for now; MacOS X may become a greater target in time). If you’re stuck with Windows, consider upgrading to Vista if you haven’t already; the security effort poured into Vista should pay off in the long run. For servers, there is much more choice, and Windows isn’t such a dominant target.
- Reduce your exposure (attack surface) by:
- Browsing the web behind a NAT appliance when at home, in a small business, or whenever there’s no other firewall device to protect you. Don’t rely only on a software firewall; it can become disabled or get misconfigured by malware or bad software, or be too permissive by default (if you can’t or don’t know how to configure it).
- Using the NoScript extension for Firefox (if you’re not using Firefox, consider switching, if only for that reason). JavaScript is a vector of choice for desktop computer attacks (which is why I find the HoneyClient project so interesting, but I digress). JavaScript can be used to violate your privacy* or take control of your browser away from you, and give it to website authors, advertisers on those sites, or to the people who compromised those sites, and you can bet it’s not always done for your benefit (even though JavaScript enables better things as well). NoScript gives you a little control over browser plugins, and which sources are allowed to run scripts in your browser, and attempts to prevent XSS exploits.
- Turning off unneeded features and services (OK, this is old advice, but it’s still good).
- Browsing the web behind a NAT appliance when at home, in a small business, or whenever there’s no other firewall device to protect you. Don’t rely only on a software firewall; it can become disabled or get misconfigured by malware or bad software, or be too permissive by default (if you can’t or don’t know how to configure it).
- Use the CIS benchmarks, and if evaluation tools are available for your platform, run them. These tools give you a score, and even as silly as some people may think this score is (reducing the number of holes in a ship from 100 to 10 may still sink the ship!), it gives you positive feedback as you improve the security stance of your computers. It’s encouraging, and may lift the feeling that you are sinking into helplessness. If you are a Purdue employee, you have access to CIS Scoring Tools with specialized features (see this news release). Ask if your organization also has access and if not consider asking for it (note that this is not necessary to use the benchmarks).
- Use the NIST security checklists (hardening guides and templates). The NIST’s information technology laboratory site has many other interesting security papers to read as well.
- Consider using Thunderbird and the Enigmail plugin for GPG, which make handling signed or encrypted email almost painless. Do turn on SSL or TLS-only options to connect to your server (both SMTP and either IMAP or POP) if it supports it. If not, request these features from your provider. Remember, learned helplessness is not making any requests or any attempts because you believe it’s not ever going to change anything. If you can login to the server, you also have the option of SSH tunneling, but it’s more hassle.
- Watch CERIAS security seminars on subjects that interest you.
- If you’re a software developer or someone who needs to test software, consider using the ReAssure system as a test facility with configurable network environments and collections of VMware images (disclosure: ReAssure is my baby, with lots of help from other CERIAS people like Ed Cates).
Good luck! Feel free to add more ideas as comments.
*A small rant about privacy, which tends to be another area of learned helplessness: Why do they need to know? I tend to consider all information that people gather about me, that they don’t need to know for tasks I want them to do for me, a (perhaps very minor) violation of my privacy, even if it has no measurable effect on my life that I know about (that’s part of the problem—how do I know what effect it has on me?). I like the “on a need to know basis” principle, because you don’t know which selected (and possibly out of context) or outdated information is going to be used against you later. It’s one of the lessons of life that knowledge about you isn’t always used in legal ways, and even if it’s legal, not everything that’s legal is “Good” or ethical, and not all agents of good or legal causes are ethical and impartial or have integrity. I find the “you’ve got nothing to hide, do you?” argument extremely stupid and irritating—and it’s not something that can be explained in a sentence or two to someone saying that to you. I’m not against volunteering information for a good cause, though, and I have done so in the past, but it’s rude to just take it from me without asking and without any explanation, or to subvert my software and computer to do so.
I told you so
[tags]Windows, Office, malware, vulnerabilities[/tags]
This appeared in USA Today yesterday: Cyberspies exploit Microsoft Office. This is yet more support for my earlier post.
So, are you ready to join the movement—stop sending Word documents in email?
Update 4/28: And here is yet another story of how Word files are being used against victims.
[posted with ecto]
The PHP App Insecurity Top 20
I’ve spent some of my down time in the past couple weeks working with the NIST NVD data to get stats on PHP application vulnerabilities. What follows is a breakdown of the 20 PHP-based applications that had the highest aggregate vulnerability scores (NIST assigns a score from 1-10 for the severity of each entry), and the highest total number of vulnerabilities, over the past 12 months. Of the two, I feel that the aggregate score is a better indicator of security issues.
A few caveats:
- The data here covers the period between April 1 2006 and April 1 2007.
- This obviously only includes reported vulnerabilities. There are surely a lot more applications that are very insecure, but for one reason or another haven’t had as many reports.
- I chose 20 as the cutoff mainly for the sake of making the data a little easier to swallow (and chart nicely). There are about 1,800 distinct apps in the NIST NVD that are (as far as I could determine) PHP-based.
Without further ado, here are the tepid Excel charts:
A couple notes:
- There are 25 entries in the top “20” by vulnerability count, due to matching vulnerability counts.
- I’d never even heard of MyBulletinBoard, the top entry in both lists. It hasn’t had any vulnerabilities in the NVD since September of 2006, which says something about how numerous and severe the entries between April and September 2006 were. This appears to be the same product as “MyBB,” so perhaps the situation has improved, as MyBB only has one NVD entry in the entire period (CVE-2007-0544).
- Wordpress has had a bad start to 2007, with numerous vulnerabilities that significantly increased its ranking. March 2007 was particularly bad, with 7 new vulnerabilities reported.
- Bulletin board/forum software is by far the most common type of application in the top 20. A couple forum apps that have very low numbers of vulnerability reports: Vanilla and FUDForum.
I do intend to keep this data up-to-date if people find it interesting, so let me know if you’d like me to do so, or if you’d like to see other types of analysis.
[tags]php, security, application security, vulnerabilities, nist, nvd, statistics[/tags]
2007: The year of the 9,999 vulnerabilities?
A look at the National Vulnerability Database statistics will reveal that the number of vulnerabilities found yearly has greatly increased since 2003:
| Year | Vulnerabilities | %Increase |
|---|---|---|
| 2002 | 1959 | N/A |
| 2003 | 1281 | -35% |
| 2004 | 2367 | 85% |
| 2005 | 4876 | 106% |
| 2006 | 6605 | 35% |
Average yearly increase (including the 2002-2003 decline): 48%
6605*1.48= 9775
So, that’s not quite 9999, but fairly close. There’s enough variance that hitting 9999 in 2007 seems a plausible event. If not in 2007, then it seems likely that we’ll hit 9999 in 2008. So, what does it matter?
MITRE’s CVE effort uses a numbering scheme for vulnerabilities that can accomodate only 9999 vulnerabilities: CVE-YEAR-XXXX. Many products and vulnerability databases that are CVE-compatible (e.g., my own Cassandra service, CIRDB, etc...) use a field of fixed size just big enough for that format. We’re facing a problem similar, although much smaller in scope, to the year-2000 overflow. When the board of editors of the CVE was formed, the total number of vulnerabilities known, not those found yearly, was in the hundreds. A yearly number of 9999 seemed astronomical; I’m sure that anyone who would have brought up that as a concern back then would have been laughed at. I felt at the time that it would take a security apocalypse to reach that. Yet there we are, and a fair warning to everyone using or developing CVE-compatible products.
Kudos to the National Vulnerability Database and the MITRE CVE teams for keeping up under the onslaught. I’m impressed.
Vulnerability disclosure grace period needs to be short, too short for patches
One of the most convincing arguments for full disclosure is that while the polite security researcher is waiting for the vendor to issue a patch, that vulnerability MAY have been sold and used to exploit systems, so all individuals in charge of administering a system have a right to know ALL the details so that they can protect themselves, and that right trumps all other rights.
That argument rests upon the premise that if one person found the vulnerability, it is possible for others to find it as well. The key word here is “possible”, not “likely”, or so I thought when I started writing this post. After all, vulnerabilities can be hard to find, which is a reason why products are released with vulnerabilities. How likely is it that two security researchers will find the same vulnerability?
Mathematically speaking, the chance that two successful security researchers (malicious or not) will find the same flaw is similar to the birthday problem. Let’s assume that there are X security researchers, each finding a vulnerability out of N vulnerabilities to be found. In 2006, 6560 vulnerabilities were found, and 4876 in 2005 (according to the national vulnerability database). Let’s assume that the number of vulnerabilities available to be found in a year is about 10 000; this is most surely an underestimation. I’ll assume that all of these are equally likely to be found. An additional twist on the birthday problem is that people are entering and leaving the room; not all X are present at the same time. This is because we worry about two vulnerabilities being found within the grace period given to a vendor.
If there are more successful researchers in the room than vulnerabilities, then necessarily there has been a collision. Let’s say that the grace period given to a vendor is one month, so Y = X/12. Then, there would need to be 120,000 successful security researchers for collisions to be guaranteed. For fewer researchers, the likelihood of two vulnerabilities being the same is then 1- exp(-(Y(Y-1))/2N) (c.f. Wikipedia). Let’s assume that there are 5000 successful researchers in a given year, to match the average number of vulnerabilities reported in 2005 and 2006. The probability that two researchers can find the same vulnerability over a given time period is:
| Grace Period | Probability |
|---|---|
| 1 month | 0.9998 |
| 1 week | 0.37 |
| 1 day | 0.01 |
In other words, nowadays the grace period given to a vendor should be on the order of one or two days, if we only take this risk into account. Has it always been like this?
Let’s assume that in any given year, there are twice as many vulnerabilities to be found than there are reported vulnerabilities. If we make N = 2X and fix the grace period to one week, what was the probability of collision in different years? The formula becomes 1- exp(-(X/52(X/52-1))/4X), where we take the ceiling of X/52.
| Year | Vulnerabilities Reported | Probability |
|---|---|---|
| 1988-1996 | 0 | |
| 1997 | 252 | 0.02 |
| 1998 | 246 | 0.02 |
| 1999 | 918 | 0.08 |
| 2000 | 1018 | 0.09 |
| 2001 | 1672 | 0.15 |
| 2002 | 1959 | 0.16 |
| 2003 | 1281 | 0.11 |
| 2004 | 2363 | 0.20 |
| 2005 | 4876 | 0.36 |
| 2006 | 6560 | 0.46 |
So, according to this table, a grace period of one week would have seemed an acceptable policy before 2000, perhaps fair in 2000-2003, but is now unacceptably long. These calculations are of course very approximative, but they should be useful enough to serve as guidelines. They show, much to my chagrin, that people arguing for the full and immediate disclosure of vulnerabilities may have a point.
In any case, we can’t afford, as a matter of national and international cyber-security, to let vendors idly waste time before producing patches; vendors need to take responsibility, even if the vulnerability is not publicly known. This exercise also illustrates why a patch-it-later attitude could have seemed almost excusable years ago, but not now. These figures are a serious problem for managing security with patches, as opposed to secure coding from the start: I believe that it is not feasible anymore for traditional software development processes to issue patches before the threat of malicious disclosure and exploits becomes significant. Finally, the grace period that we can afford to give vendors may be too short for them to issue patches, but that doesn’t mean it should be zero.
Note: the astute reader will remark that the above statistics is for any two vulnerabilities to match, whereas for patching we are talking about a specific vulnerability being discovered independently. The odds of that specific ocurrence are much smaller. However, we need to consider all vulnerabilities in a systematic management by patches, which reverts to the above calculations.
Are You Still E-mailing Word documents?
[tags]vulnerabilities,microsoft word, email attachments[/tags]
So far this year, a number of vulnerabilities in Microsoft’s Word have been discovered. Three critical (“zero day”) vulnerabilities have been discovered—and as yet, unpatched—this month. (Vulnerability 1, Vulnerability 2, and Vulnerability 3.) These are hardly the first vulnerabilities reported for Word. There has actually been quite a history of problems associated with Word documents containing malformed (or maliciously formed) content.
For years now, I have had my mailer configured to reject Word documents when they are sent to me in email and also send back an explanatory “bounce” message. In part, this is because I have not had Word installed on my system, nor do I normally use it. As such, Word documents sent to me in email have largely been so much binary noise. Yes, I could install some converters that do a halfway reasonable job of converting Word documents, or I could install something like OpenOffice to read Word files without installing Word itself, but that would continue to (tacitly) encourage dangerous behavior by my correspondents.
People who send me Word documents tend to get a bounce message that points out that Word:
- Is not a document interchange format—it is not designed for document transport
- Is not installed on everyone’s machine, nor available for everyone’s machine
- Not all versions of Word are compatible with each other
- Results in huge, bloated, files for tiny content (such as memos)
- And of course, Word is commonly a vector of viruses and malicious hacks.
If you want more details on this, including links to other essays, see my explanatory bounce text, as cited above.
The US-CERT has warned that people shouldn’t open unexpected Word documents in email. As general policy, they actually warn not to open email with attachments such as Word documents appearing to be from people you know. This is because malicious software may have infected an acquaintance’s machine and is sending you something infected, or the return address is faked—it may not be from the user you think!
If there was a mad bomber sending out explosives in packages, and you got a box with your Aunt Sally’s name on it, would you possibly pause before opening it? Most people would, but inexplicably, those same people exhibit no hesitation in opening Word documents (and other executable content), thereby endangering their own machines—and often everyone in the same enterprise.
There is almost no reason to email Word documents!! They certainly should be used in email FAR LESS than they currently are.
If you need to send a simple memo or note in email, use plain text (or RichText or even HTML). It is more likely to be readable on most kinds of platform, is compact, and is not capable of carrying a malicious payload.
If you need to send something out that has special formatting or images, consider PDF. It may not be 100% safe (although I know of no current vulnerabilities), but it is historically far safer than Word is or has been. Putting it as an image or PDF on a local WWW site and mailing the URL is also reasonable.
If you must send Word documents back and forth (and there are other word processing systems than Word, btw), then consider sending plain RTF. Or arrange a protocol so all parties know what is being sent and received, and be sure to use an up-to-date antivirus scanner! (See the CERT recommendations.)
The new version of Word 2007 uses XML for encoding, and this promises to be safer than the current format. That remains to be seen, of course. And it may be quite some time before it is installed and commonplace on enough machines to make a difference.
You can help make the community safer—stop sending Word messages in email, and consider bouncing back any email sent to you in Word! If enough of us do it, we might actually be able to make the Internet a little bit safer.
An additional note
So, what do I use for word processing? For years, I have used TeX/LaTeX for papers. Before that I also used troff on Unix. I have used FrameMaker on both Mac and Unix, and wrote several books (including all three editions of Practical Unix Security et al.) with it. I used ClarisWorks on the Mac for some years, and now use Apple’s Pages for many of my papers and documents.
I have installed and used Word under two extraordinary circumstances. Once was for a large project proposal I was leading across 5 universities where there was no other good common alternative that we could all use—or that everyone was willing to use. The second case was when I was on the PITAC and was heavily involved in producing the Cyber Security report.
However, I am back to using Pages on the Mac (which can import RTF and, I am told, Word), and LaTeX. I’ve written over 100 professional articles, 5 books, and I don’t know how many memos and letters, and I have avoided Word. It can be done.
Note that I have nothing against Microsoft, per se. However, I am against getting locked into any single solution, and I am especially troubled at the long history of vulnerabilities in Word...which are continuing to occur after years and years of problems. That is not a good record for the future.
[posted with ecto]
