[tags]viruses,OpenOffice,Word,Microsoft,Office,Powerpoint,Excel[/tags]
In my last post, I ranted about a government site making documents available only in Word.  A few people have said to me “Get over it—use OpenOffice instead of the Microsoft products.”  The problem is that those are potentially dangerous too—there is too much functionality (some of it may be undocumented, too) in Word (and Office) documents.

Now, we have a virus specific to OpenOffice.  We’ve had viruses that run in emulators, too.  Trying to be compatible with something fundamentally flawed is not a security solution.  That’s also my objection to virtualization as a “solution” to malware.

I don’t mean to be unduly pejorative, but as the saying goes, even if you put lipstick on a pig, it is still a pig.

Word and the other Office components are useful programs, but if MS really cared about security, they would include a transport encoding that didn’t include macros and potentially executable attachments—and encourage its use!  RTF is probably that encoding for text documents, but it is not obvious to the average user that it should be used instead of .doc format for exchanging files.  And what is there for Excel, Powerpoint, etc?

[tags]DHS,MS Word,threats[/tags]
Earlier, I wrote about the security risks of using Microsoft Word documents as a presentation and encoding format for sending files via email (see posts here and here).  Files in “.doc” format contain macros, among other things, that could be executable.  They also have metadata fields that might give away sensitive information, and a lot of undocumented cruft that may be used in the process of exploiting security.  It is no wonder that exotic exploits are showing up for Word documents.  And only today it was revealed that the latest version of Office 2007 may not have even gotten the most recent patch set.

Want to find some vulnerabilities in Word?  Then take a look at the list of US-CERT alerts on that software; my search returns almost 400 hits.  Some of these are not yet patched, and there are likely many as-yet unpatched flaws still in there.

Clearly, the use of Word as a document exchange medium is Bad (that’s with a definite capital B).  People who understand good security practices do not exchange Word files unless they are doing collaborative editing, and even then it is better to use RTF (if one continues to be beholden to Microsoft formats).  Good security hygiene means warning others, and setting a good example.

Now, consider that DHS has released BAA07-09 to solicit research and prototypes to get fixes for current cyber infrastructure vulnerabilities.  I could rant about how they claim it is for R&D but is really a BAA for further product development for fundamentally flawed software that cannot be fixed.  But that isn’t the worst part.  No, the BAA is only available as Word documents!

Can you say “irony”?  This is the agency charged with helping guide us to a more secure infrastructure?  If so, electronically KYAG.

Update: A response from Dr. Douglas Maughn at DHS points out that the site I indicated for the BAA is actually FedBizOps rather than DHS.  The DHS posting site actually has it in PDF…although the FedBizOps link is the one I’ve seen in several articles (and in a posting in SANS NewsBites).

Of course, it would be great if DHS could get the folks at FedBizOps to clean up their act, but at least in this case, DHS—or rather, DHSARPA—got it right.  I stand corrected.

CERIAS Reports & Papers

• "Defense Science Study Group 2004-2005 Papers 1-11"
  30 April 2007, 7:00 pm
• "Using artificial neural networks for forensic file type identification"
  29 April 2007, 7:00 pm
• "Enabling Confidentiality of Data Delivery in an Overlay Broadcasting System"
  28 April 2007, 7:00 pm
• "Feasibility of DDoS attacks using P2P Systems and Prevention through Robust Membership ...
  28 April 2007, 7:00 pm

CERIAS Weblogs

• “Verified by VISA” Issues
  3 May 2007, 3:10 pm
• More on passwords
  1 May 2007, 1:11 pm
• Quicktime flaw on Macs brings out the crazies
  27 April 2007, 1:27 pm

The premise of the “Verified by VISA” program seems fine:  request a password to allow the use of a credit card online, to lower credit card fraud (besides the problem of having to manage yet another password).  However, there were several problems with how I was introduced to the program:

• I was unexpectedly requested to register my card after doing some shopping online on a site that allowed customer comments, and had forced me to turn on JavaScript.
• I knew nothing about this program, and the request was presented in an authoritative manner, implying that I *had* to register or else my purchase would be denied.  (Bull!  Even though I closed my browser without completing the registration, my purchase went through)
• I was asked for the last 4 digits of my SSN as proof of identity (!), along with information I had just provided to the online merchant (CC number, phone number, etc…)
• There was no explanation or link to an explanation of what was going on, why VISA would want me to register my card and what was this program.

That appeared to me more like a phishing attempt, exploiting a XSS vulnerability, than anything else.  After contacting my bank, I was assured that the program was legitimate.  Visa actually has a web site where you can register your card for the program: 
https://usa.visa.com/personal/security/vbv/index.html

On that site, you will find that most links to explanations are broken.  I get a “Sorry! The page you’ve requested cannot be found.” when clicking almost all of them (I found out later that it works if you activate JavaScript).  Another issue is that you need to activate JavaScript in order to provide that sensitive information, therefore exposing your browser to exploits against the browser and to any XSS exploits (I’m not worried as much about the VISA site, which doesn’t have user-submitted content, as much as the shopping sites).  If you are not using NoScript or forget to disable JavaScript afterwards, then you expose yourself to exploits from all the future sites you will visit.  It’s irresponsible and unnecessary:  there was nothing in the JavaScript-activated forms (or in the explanations) that couldn’t have been done with regular HTML.  It’s all in the name of security…

A fundamental issue I have with this process is that commands (the registration) to reach a higher level of security are issued in-band, using the very medium and means (browser) that are semi-trusted and part of the problem we’re trying to solve (I realize that this program addresses other threats, such as the vulnerability of CC numbers stored by merchants).  Moreover, doing this exposes more sensitive credentials.  It is almost like hiring a thief as a courier for the new keys to the building, while giving him as well the key to the safe where all the keys are stored.

The Visa program also enables a new kind of attack against credit cards.  If criminals get their hands on your last 4 SSN digits (or if they guess it, it’s only 9999 brute force attempts) and your credit card number, they could register it themselves, denying you its use!  The motivation for this attack wouldn’t necessarily be financial gain, but causing you grief.  I also bet that you will have a harder time proving that fraud occurred, and may get stuck with any charges made by the criminals.

The correct way of registering for this program would be by using a trusted channel, such as showing up at your bank in person to choose a password for your credit card, or through registered mail with signatures.  However, these are not available options for me (I wonder if some banks offer this service, and if so, whether they are not simply using the above web site).  There should also be a way to decline participation in the program, and block the future registration of the card. 

In conclusion, this poorly executed program had a reverse effect on me:  I now distrust my Visa card, and Visa itself, a little bit more.

Update:  There doesn’t seem to be a limit on the number of times you can try to register a card, enabling the brute force finding of someone’s last 4 SSN digits (I tried 20 times.  At the end I entered the correct number and it worked, proving that it still accepted attempts after 20 times).  An attacker can then use the last 4 digits of your SSN elsewhere!  Let’s say, your retirement accounts with Fidelity and others that accept SSNs as user IDs. 

For more fun, I attempted to register my credit card again.  I received a message stating that the card was already registered, but I was offered the chance to re-register it anyway and erase my previously entered password simply by entering my name, the complete SSN and phone number.  Isn’t that great, now attackers could validate my entire SSN!

It gets worse.  I entered an incorrect SSN, and the system accepted it.  I was then prompted to enter new passwords.  The system accepted the new passwords without blinking…  Not only is the design flawed, but the implementation fails to properly perform the checks!

[tags]Passwords[/tags]
I’ve previously written about passwords in this blog (here, here and here).

I saw this post today—I think it is great!  I’m sure they will adopt this here at Purdue sometime soon.

[tags]Windows,MacOS, security flaws, patches, press coverage[/tags]
There’s been a lot of froth in the press about a vulnerability discovered in a “Hack the Mac” contest conducted recently.  (Example stories here and here.)  I’m not really sure where this mini-hysteria is coming from—there isn’t really anything shocking here.

First of all, people shouldn’t be surprised that there are security flaws in Apple products.  After all, those are complex software artifacts, and the more code and functionality present, the more likely it is the case that there will be flaws present—including serious flaws leading to security problems.  Unless special care is taken in design and construction (not evident in any widely-used system) vulnerabilities are likely to be present.

Given that, the discovery of one serious flaw doesn’t necessarily mean there are hundreds more lurking beneath the surface and that MacOS X is as bad (or worse) than some other systems.  Those bloggers and journalists who have some vulture genomes seem particularly prone to making sweeping announcements after each Apple-based flaw (and each Linux bug) is disclosed or a story about vulnerabilities is published.  Yes, there are some problems, and there are undoubtedly more yet to be found.  That doesn’t mean that those systems are inherently dangerous or even as buggy and difficult to protect as, for example, Windows XP.  Drawing such conclusions based on one or two data points is not appropriate; these same people should likewise conclude that eating at restaurants anywhere in the US is dangerous because someone got food poisoning at a roadside stand in Mexico last year!

To date, there appear to be fewer flaws in Apple products than we have seen in some other software.  Apple MacOS X is built on a sturdy base (BSD Unix) and doesn’t have a huge number of backwards compatibility features, which is often a source of flaws in other vendors’ products.  Apple engineers, too, seem to be a little more careful and savvy about software quality issues than other vendors, as least as evidenced by the relative number of crashes and “blue screen” events in their products.  The result is that MacOS X is pretty good right out of the box.

Of course, this particular flaw is not with MacOS X, but with Java code that is part of the Quicktime package for WWW browsers.  The good news is that it is not really a MacOS problem; the bad news is that it is a serious bug that got widely distributed; and the worse news is that it potentially affects other browsers and operating systems.

I have been troubled by the fact that we (CERIAS, and before that COAST) have been rebuffed on every attempt over the last dozen years to make any contact with security personnel inside Apple.  I haven’t seen evidence that they are really focused on information security in the way that other major companies such as Sun, HP and Microsoft are, although the steady patching of flaws that have not yet been widely reported outside the company does seem to indicate some expertise and activity somewhere inside Apple.  Problems such as this Quicktime flaw don’t give warm fuzzy feelings about that, however.

Apple users should not be complacent.  There are flaws yet to be discovered, and users are often the weakest link.  Malware, including viruses, can get into MacOS X and cause problems, although they are unlikely to ever be of the number and magnitude as bedevil Windows boxes (one recent article noted that vendors are getting around 125 new malware signatures a day—the majority are undoubtedly for Windows platforms).  And, of course, Mac machines (and Linux and….) also host browsers and other software that execute scripts and enable attacks.  Those who use MS Word have yet more concerns. 

The bottom line. No system is immune to attacks.  All users should be cautious and informed.  Apple systems still appear to be safer than their counterparts running Windows XP (the jury is out on Vista so far), and are definitely easier to maintain and use than similarly secured systems running Linux.  You should continue to use the system that is most appropriate for your needs and abilities, and that includes your abilities to understand and configure security features to meet your security needs.  For now, my personal systems continue to be a MacBook Pro (with XP and Vista running under Parallels) and a Sun Solaris machine.  Your own milage should—and probably will—vary.

[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]

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]

Note: I’ve updated this article after getting some feedback from Alexander Limi.

A colleague of mine who is dealing with Plone, a CMS system built atop Zope, pointed me to a rather disturbing document in the Plone Documentation system, one that I feel is indicative of a much larger problem in the web app dev community.

The first describes a hole (subsequently patched) in Plone that allowed users to upload arbitrary JavaScript.  Apparently no input or output filtering was being done.  Certainly anyone familiar with XSS attacks can see the potential for stealing cookie data, but the article seems to imply this is simply a spam issue:

Clean up link spam

Is this a security hole?
No. This is somebody logging in to your site (if you allow them to create their own users) and adding content that can redirect people to a different web site. Your server, site and content security is not compromised in any way. It’s just a slightly more sophisticated version of comment spam. If you open up your site to untrusted users, there will always be a certain risk that people add content that is not approved. It’s annoying, but it’s not a security hole.

Well, yes, actually, it is a security hole.  If one can place JavaScript on your site that redirects the user to another page, they can certainly place JavaScript on your site that grabs a user’s cookie data and redirects that to another site.  Whether or not they’ll get something useful from the data varies from app to app, of course. What’s worrisome is that it appears as if one of Plone’s founders (the byline on this document is for Alexander Limi, whose user page describes him as “one of Plone’s original founders.”) doesn’t seem to think this is a security issue. After getting feedback from Alexander Limi, it seems clear that he does understand the user-level security implications of the vulnerability, but was trying to make the distinction that there was no security risk to the Plone site itself.  Still, the language of the document is (unintentionally) misleading, and it’s very reminiscent of the kinds of misunderstandings and excuses I see all the time in open-source web app development.

The point here is (believe it or not) not to pick on Plone.  This is a problem prevalent in most open source development (and in closed source dev, from my experience).  People who simply shouldn’t be doing coding are doing the coding—and the implementation and maintenance.

Let’s be blunt: A web developer is not qualified to do the job if he or she does not have a good understanding of web application security concepts and techniques.  Leaders of development teams must stop allowing developers who are weak on security techniques to contribute to their products, and managers need to stop hiring candidates who do not demonstrate a solid secure programming background.  If they continue to do so, they demonstrate a lack of concern for the safety of their customers.

Educational initiatives must be stepped up to address this, both on the traditional academic level and in continuing education/training programs.  Students in web development curriculums at the undergrad level need to be taught the importance of security and effective secure programming techniques.  Developers in the workforce today need to have access to materials and programs that will do the same.  And the managerial level needs to be brought up to speed on what to look for in the developers they hire, so that under-qualifed and unqualified developers are no longer the norm on most web dev teams.

The newest version of PHPSecInfo, version 0.2, is now available.  Here are the major changes:

• Added link to “more info” in output.  These lead to pages on the phpsec.org site giving more details on the test and what to do if you have a problem
• Modified CSS to improve readability and avoid license issue with PHP (the old CSS was derived from the output of phpinfo())
• New test: PhpSecInfo_Test_Session_Save_Path
• Added display of “current” and “recommended” settings in test result output
• Various minor changes and bug fixes; see the CHANGELOG for details

-Download now

-Join the mailing list