Tip of the Day: Don't be a victim (well try to not be a victim) - security toolbars

Published: 2006-08-28
Last Updated: 2006-08-28 23:54:54 UTC
by Robert Danford (Version: 1)
0 comment(s)
A recent study (http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf) proved what we all don't like to admit.

That even as super human beings blessed with keen intellect and sage experience, human nature is undeniable.
Most anyone can be duped and most people tend to overestimate their chances of success and their skills
http://en.wikipedia.org/wiki/Overconfidence_effect

The study focused on phishing, but there are a number of other relevant examples.
This is what makes information security so hard. Its the humans! Just check out the list of all these other biases which have been researched experimentally (http://en.wikipedia.org/wiki/List_of_cognitive_biases) while thinking about security policies, social engineering, etc.

As security professionals we really can't just write off "everyone else on the planet" as dumb. (BOFH's everywhere will disagree). It is for this reason that insecurity can never be solved solely through technology. There is no silver bullet. (well if everyone followed this Tip of the Day http://isc.sans.org/diary.php?storyid=1530  and left them off maybe....)

There really is no silver bullet. User education is a must. So most of you out there know all of this. Which also means the future rests on each of you doing your part to educate those around you.

So we have gobs of busy people that might not know a lot about computers and security clicking and surfing all over the web (logged in as admin), but that think they know what they are doing. Sounds like a recipe for disaster or a great Monty Python episode involving loaded shotguns.

One disturbing finding of the report was that many users are not even looking at (and/or understanding) the indicators they have available in a browser that relate to their safety (SSL padlocks, location fields, status bars, etc). This is akin to getting off on the _wrong_ exit at 3am in an unfamiliar city holding a map. Not good.

There are some current tools out there which may help users make better choices (or block their bad choices). I'm just going to talk about browser toolbars. For the user class of not completely hopeless up to expert I really recommend McAfee's SiteAdvisor. This toolbar works with Firefox and IE and will provide more prominent and granular indicators that a site is dubious (or downright malicious). Users will need to keep an eye on their browser corner (which may require education) or optionally glance at the pretty red, yellow, green icons next to their google search results (RED means BAD)

SiteAdvisor
http://www.siteadvisor.com/ (IE and Firefox)

Also for those looking at getting involved in the community sign up to be a reviewer. Help SiteAdvisor catch and correctly flag all those bad sites that try oh so hard to look legit.

Netcraft Toolbar
So back to phishing. Netcraft has a really nice toolbar which can provide visual clues (YMMV) as well as speed bumps to doing something unsafe. It can actually block access to a site pending user verification (ok so we all know most users click OK on anything that pops up to get it out of the way)

http://toolbar.netcraft.com/ (IE and Firefox)

Expect this warning and popup trend to continue. Google is taking steps to prevent accidental wrong exits (see http://www.stopbadware.org/ for details on this initiative)

The next versions of IE and Firefox should have some of these protections built in. None of these will remove the need for user education (good luck explaining hostnames and mouse-overs to grandma). The criminals will figure out ways to circumvent these technologies and users will continue to ignore all the annoying popup warning windows and glaring red warning symbols. Its just human nature. If only it were as simple as just telling people to "only surf trusted sites". Right. uh huh.



Other cool stuff and links:
http://www.castlecops.com/t107217-Anti_Phishing_Toolbars.html
http://www.cerias.purdue.edu/weblogs/coj/secure-it-practices/post-22/
NoScript: https://addons.mozilla.org/firefox/722/
Spoofstick: http://www.spoofstick.com/
http://research.microsoft.com/displayArticle.aspx?id=1521
http://www.sandboxie.com/

Keywords: ToD
0 comment(s)

Notable Tidbits

Published: 2006-08-28
Last Updated: 2006-08-28 23:10:18 UTC
by Robert Danford (Version: 1)
0 comment(s)
Notable updates for today:
http://liveview.sourceforge.net/

"Live View is a Java-based graphical forensics tool that creates a VMware virtual machine out of a raw (dd-style) disk image or physical disk. This allows the forensic examiner to "boot up" the image or disk and gain an interactive, user-level perspective of the environment, all without modifying the underlying image or disk. Because all changes made to the disk are written to a separate file, the examiner can instantly revert all of his or her changes back to the original pristine state of the disk.
The end result is that one need not create extra "throw away" copies of the disk or image to create the virtual machine."

Live View is capable of booting

    * Full disk raw images
    * Bootable partition raw images
    * Physical Disks (attached via a USB or Firewire bridge)

Containing the following operating systems

    * Windows XP, 2000, 2003, NT, Me, 98
    * Linux (limited support)
[source: liveview site]

http://ssdeep.sourceforge.net/ (Came across while browsing Richard's excellent aggregate site http://www.bloglines.com/public/TaoSecurity)
Uh context triggered piecewise hashes. Makes my head hurt. But you'll like it if you need to compare closely related files (polymorphic malware samples maybe?)
Here's a greaqt interview. http://cyberspeak.libsyn.com/index.php?post_id=115142
This is way beyond me too http://dbacl.sourceforge.net/


Keywords:
0 comment(s)

J2SE Runtime Environment (JRE) & Java SE Developer Kit (JDK) Update 8

Published: 2006-08-28
Last Updated: 2006-08-28 23:06:15 UTC
by Tony Carothers (Version: 3)
0 comment(s)
Sun has released Update 8 to for JRE 5.0 for download.  As an earlier diary discussed, versions prior to 5.0, Release 6, allowed applets and/or applications to call earlier unpatched versions.  What is the risk to me?  Having the ability to call earlier, unpatched versions could potentially allow an attacker to run her/his code of choice along with it.  The Java Runtime Environment and Java Developer Kit both have release 8.0 available for download here.

Update: Here is a submission from one of our readers (who wishes to remain nameless). I am pasting it here verbatim. Just shows the quality of our readers that makes the ISC what it is. Thanks.

* If the previous versions of SunJRE aren't installed, and the user doesn't have local admin, it's pretty hard for an applet to successfully request a previous version!  When installing new versions of SunJRE, always uninstall the old one.

* That said, I have personally run into many situations where applets demand older versions of Java.  The main problem is internal corporate developers that want to ensure they get SunJRE even on machines where MSJVM is the default.  They generally tend to instantiate their Java applet using a CLSID, and they use the specific version CLSID (i.e. "{CAFEEFAC-0014-0002-0003-ABCDEFFEDCBA}"). 
Since I don't want to install old versions of Java, and I have absolutely no way of influencing the developers who maintain those websites, I have taken to subterfuge. 
What I do is add in CLSIDs for the earlier versions of SunJRE (the pattern is pretty obvious), but point them to the most recent patch level for SunJRE.  For instance, the following would point 1.4.2_06 to 1.4.2_12:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CAFEEFAC-0014-0002-0006-ABCDEFFEDCBA}]
@="Java Plug-in 1.4.2_06"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CAFEEFAC-0014-0002-0006-ABCDEFFEDCBA}\InprocServer32]
@="C:\\Program Files\\Java\\j2re1.4.2_12\\bin\\npjpi142_12.dll" "ThreadingModel"="Apartment"

That seems to work as most of these applications don't really care about the differences between patch levels, and the applets don't test once Java loads, so as long as the CLSID is populated, Java starts right up.

I don't know if 1.4.2_12 and 1.5.0_06 populate these older CLSIDs automatically or if Java applets using old CLSIDs will simply fail to run.


Keywords:
0 comment(s)

Comments


Diary Archives