Opera 9.0 released

Published: 2006-06-20
Last Updated: 2006-06-20 20:55:19 UTC
by Jim Clausing (Version: 1)
0 comment(s)
For those looking for an alternative browser, there is one that has been overlooked a little in the IE-Firefox wars.  Opera has been around for quite a while and works rather well.  Today, they have unveiled version 9.0.  Among the nice features touted in this release is the ability to control pop-ups and javascript on a site-by-site basis.  I haven't had a chance to give this one a thorough testing yet, but would welcome observations from our readers.  The other 2 big players are also scheduled to get new major versions this year, IE7 is in beta and the Mozilla folks are promising Firefox 2 later this year.

http://www.opera.com/index.dml
Keywords:
0 comment(s)

New Bagle in Encrypted Zip File Attachments

Published: 2006-06-20
Last Updated: 2006-06-20 20:45:31 UTC
by Kyle Haugsness (Version: 1)
0 comment(s)
 There is a new Bagle variant making the rounds.  Seems to be spreading slowly.  Email arrives with a .zip attachment that is encrypted with a password.  The password is stored in an image file that is also an attachment.  Anti-virus software that looks for the password in the text won't find it.  More details here: http://www.sophos.com/pressoffice/news/articles/2006/06/baglekl.html



Keywords:
0 comment(s)

Comments on 0day

Published: 2006-06-20
Last Updated: 2006-06-20 17:34:08 UTC
by Kyle Haugsness (Version: 1)
0 comment(s)
Given the recent rumors about 0day in IIS and confirmed 0day in several different Microsoft Office applications, these comments seem appropriate.

The first question I pose is: why the sudden increase in vulnerabilities that are published as 0day instead of responsibly disclosed?  This isn't intended to be a comment on full-disclosure.  But if you look over the past couple of years, almost all vulnerabilities that are discovered by actual researchers (not criminals) were disclosed responsibly to Microsoft.  Is the researching community becoming disenchanted with the long Microsoft patch cycle?  Is there more incentive (fame) for researchers to disclose full details to bugtraq or full-disclosure?  Is there more incentive (financial) to sell an exploit to iDefense, 3com, or the highest bidder on eBay?  If you are a software vendor, what are you doing to ensure that vulnerability researchers are kept happy and disclosing security bugs responsibly?

Now here is where I can feel people firing up their flamethrowers.  There has been lots of panic and rumors recently about 0day bugs.  And it isn't just focused on Microsoft products.  We occassionally get e-mail asking if we know about 0day in OpenSSH, Apache, and PHP.  The question shouldn't be whether 0day exists.  Because 0day exists and it will always exist.

The question is whether you or your organization would be the target of such an exploit?  The time is long gone for an exploit author to embed his nice 0day into a worm and let it run rampant through the Internet.  Today, 0day exploits are more likely to be used for military purposes, financial crime, and possibly terrorist activities (although, probably not).

So in reality, the organizations that really need to be concerned about 0day are the ones responsible for protecting military/government assets, financial institutions, and critical infrastructure agencies.  Since you know 0day exists and if you are a target, what are you doing to protect yourself?  How do you protect against, detect, and respond to unknown vulnerabilities?

For the rest of the folks out there (small/medium businesses, hobbyists)... Should you worry about 0day?  Usually not, but if you have all the other critical security components in place then go ahead.

I'm curious to know what kinds of 0day protection systems people have in place?  In the *NIX world, there are some fairly decent (and free) options for protection:  Grsecurity, NSA SE Linux, Systrace, LIDS, ProPolice GCC patch and others.  How about the Windows side?  There doesn't seem to be much for the folks without hardcore $$.  CORE security has something new called Force (http://force.coresecurity.com/) that looks quite promising.  There is also a good list of commercial products for Windows and some comments compiled by fellow handler Jason Lam here: http://isc.sans.org/diary.php?storyid=635

In summary, you should expect 0day to be alive and well for your favorite operating systems, daemons, and applications.  And if it concerns you, then do something about it instead of waiting to get smacked with it later.  You will sleep better at night and not be frustrated at your favorite software vendor when they take 6+ months to patch simple little vulnerabilities.

Keywords:
0 comment(s)

New Excel 0day (Are we evolving or going in circles?)

Published: 2006-06-20
Last Updated: 2006-06-20 16:05:34 UTC
by Kyle Haugsness (Version: 1)
0 comment(s)
(Now before I get hatemail from all the Microsoft fanboys out there, please note that these comments are not derogatory towards Microsoft.  Microsoft has like 110% market share according to their research, so that's why they get all the attention.)

Today there is news of another 0day vulnerability in Microsoft Office.  You can check your favorite vulnerability notification service for all the gory details.  Someone wrote asking for comments and honestly I don't have any step-by-step instructions for defending against this specific threat.  All of the general high-level recommendations from the MS Word 0day a couple of weeks ago still apply.  Perhaps we will have something more detailed later when the details are more clear.

Instead, here are some thoughts about the current state of vulnerability discoveries.  If you have followed along with the industry in the last couple of years, you have probably noticed that remote root/administrator type of bugs have slowly disappeared and now seem to be fairly rare.  Most vulnerability researchers that are publishing advisories now seem to focus on web applications and clients (web browsers, Office, etc).  I am honestly expecting to see a healthy stream of client vulnerabilities in Office applications over the next 2-3 years.  Several years ago, nobody cared too much about exploitable bugs in client side applications because remote bugs were still readily available.  Of course, given the recent media attention about the MS Word 0day exploit, alot of vulnerability researchers are now hitting Word with every available fuzzer that they have.

So now we have a scenario where there will be a good number of 0day vulnerabilities discovered in client-side applications like MS Office and OpenOffice.  Users will be advised not to open documents from unknown persons.  So have we evolved?  Or have we just jumped back in time ten years when every aspiring script kiddie was writing VBA Macro viruses?

Keep reading for another article about 0day...
Keywords:
0 comment(s)

The dangers of shared web hosts

Published: 2006-06-20
Last Updated: 2006-06-20 01:05:26 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
A reader alerted us today about yet another web server compromise, affecting a large number of domains. In this particular case, the server was hosted with iPowerWeb, a provider of low cost web space on shared servers.

Space on a shared server is ok for personal use. But you should think twice before using it for commercial, in particular business critical use. Your web sites security will depend on a few hundred other users on the same system doing the right thing. A bad php script on one virtual server could lead to a compromisse of all web sites hosted on the same system.

If you have to use a virtual host, try to follow these tips to make things "as secure as possible":
  • Don't go with the lowest bidder. You still rely on the hosting company to maintain the server and there is not much maintenance that can be done for $1/month.
  • Check references. Look at sites like zone-h.org for defacement history and netcraft.com for stats like uptime.
  • Keep solid backups of your files on a local system!
  • Avoid files and directories that are writeable by anybody but yourself. In particular, avoid files writable by the web server.
  • Do not rely on any access control provided by php/perl/cgi scripts. Other users may bypass it with their own scripts.
If you are providing shared web space, try to follow these rules:
  • know your customers. Avoid handing out accounts before billing details are validated. Try to verify credit card payments by phone.
  • consider virtual systems (xen, vmware...). While not perfect, its a lot better then housing all users on the same system.
  • chrooted user accounts can be almost as good as virtual hosts. But they can be hard to maintain, and they still use the same web server process which may cross over chrooted users.
  • monitor user activity carefully.
  • use a host based IDS to detect intrusions quickly.
  • got backups?
Keywords:
0 comment(s)

Comments


Diary Archives