Ars Technica‘s Eric Bangeman posted a pointer and commentary about a case in Illinois where a WiFi piggybacker got caught and fined. This is apparently the third conviction in the US (two in Florida and this one) in the last 9 months.  The Rockford Register reports:

In a prepared statement, Winnebago County State’s Attorney Paul Logli said, “With the increasing use of wireless computer equipment, the people of Winnebago County need to know that their computer systems are at risk. They need to use encryption or what are known as firewalls to protect their data, much the same way locks protect their homes.”

Firewall?  I guess they didn’t prepare the statement enough, but the intent is clear.  Still, it seems that the focus is on the consumer’s responsibility to lock down their network, ignoring the fact that the equipment that’s churned out by manufacturers is far too difficult to secure in the best of circumstances, let alone when you have legacy gear that won’t support WPA.  Eric seems to agree:

Personally, I keep my home network locked down, and with consumer-grade WAPs so easy to administer, there’s really no excuse for leaving them running with the default (open) settings.

“Easy” is very relative. It’s “easy” for guys like us, and probably a lot of the Ars audience, but try standing in the networking hardware aisle at Best Buy for about 15 minutes and listen to the questions most customers ask.  As I’ve touched on before, expecting them to secure their setups is just asking for trouble.

Well, we’re all pretty beat from this year’s Symposium, but things went off pretty well.  Along with lots of running around to make sure posters showed up and stuff, I was able to give a presentation called Web Application Security - The New Battlefront.  People must like ridiculous titles like that, because turnout was pretty good.  Anyway, I covered the current trend away from OS attacks/vandalism and towards application attacks for financial gain, which includes web apps.  We went over the major types of attacks, and I introduced a brief summary of what I feel needs to be done in the education, tool development, and app auditing areas to improve the rather poor state of affairs.  I’ll expand on these topics more in the future, but you can see my slides and watch the video for now:

• Slides (PDF Format)
• Video (Xvid AVI; requires Xvid or Divx playback codec)

Mozilla’s Firefox browser claims to provide a safer browsing experience out of the box, but some of the best security features of Firefox are only available as extensions.  Here’s a roundup of some of the more useful ones I’ve found.

• Add n’ Edit Cookies This might be more of a web developer tool, but being able to view in detail the cookies that various sites set on your visits can be an eye-opening experience.  This extension not only shows you all the details, but lets you modify them too.  You’ll be surprised at how many web apps do foolish things like saving your password in the cookie.
• Dr. Web Anti-Virus Link Checker This is an interesting idea—scanning files for viruses before you download them. Basically, this extension adds an option to the link context menu that allows you to pass the link to the Dr. Web AV service.  I haven’t rigorously tested this or anything, but it’s an interesting concept that could be part of an effective multilayer personal security model.
• FormFox This extension doesn’t do a whole lot, but what it does is important—showing a tooltip when you roll over a form submission button of the form action URL. Extending this further to visually differentiate submission buttons that submit to SSL URLs would be really nice (as suggested by Chris Shiflett).
• FlashBlock Flash hasn’t been quite as popular an attack vector as Javascript, but it still potentially could be a threat, and it’s often an annoyance.  This extension disables all embedded Flash elements by default (score one for securing things by default), allowing you to click to activate a particular one if you like.  It lacks the flexibility I’d like (things like whitelists would be very handy), and doesn’t give you much (any?) info about the Flash element before you run it, but it’s still a handy tool.
• LiveHTTPHeaders & Header Monitor LiveHTTPHeaders is an incredibly useful too for web developers, displaying all of the header traffic between the client and server.  Header Monitor is basically an add-on for LiveHTTPHeaders that displays a chosen header in Firefox’s status bar.  They’re not really specifically security tools, but they do offer a lot of info on what’s really going on when you’re browsing, and an educated user is a safer user.
• JavaScript Option This restores some of the granularity Firefox users used to have over what Javascript can and cannot do. I’d like to see this idea taken farther (see below), but it’s handy regardless.
• NoScript This extension is pretty smooth.  Of all the addons for Firefox covered here, this is the one to get.  NoScript is a powerful javascript execution whitelisting tool, allowing full user control over what domains allow scripts to run. Notifications of blocked execution and the allowed domain interface are nearly identical to the built-in Firefox popup blocker, so users should find it comfortable to work with.  NoScript can also block Flash, Java, and “other plugins;” forbid bookmarklets; block or allow the “ping” attribute of the tag; and attempt to rewrite links that execute javascript to go to their intended donation without triggering the script code. The one thing I’d really like to see from this extension would be more ganularity over what the Javascript engine can access.  Now it’s only “on” or “off,” but being able to disable things like cookie access would eliminate a lot of potential security issues while still letting JS power rich web app interfaces.  Also read Pascal Meunier’s take on NoScript.
• QuickJava Places handy little buttons in the status bar that let you quickly enable or disable Java or Javascript support. Note that this will not work with the latest stable Firefox (1.5.0.1).  Hopefully a new version will be available soon.
• ShowIP This is another tool that isn’t aimed at security per se, but offers a lot of useful information. ShowIP drops the IP address of the current site in your status bar.  Clicking on it brings up a menu of lookup options for the IP, like whois and DNS info.  You can add additional web lookups if you like, as well as passing the IP to a local program.  Handy stuff.
• SpoofStick The idea with this extension is to make it easier to catch spoofing attempts by displaying a very large, brightly colored “You’re on ” in the toolbar. For folks who know what they’re doing this isn’t wildly useful, but it could be just the ticket for less savvy users.  It requires a bit too much setup for them, though, and in the end I think this is something the browser itself should be handling.
• Tamper Data Much like LiveHTTPHeaders, Tamper Data is a very useful extension for web devs that lets the user view HTTP headers and POST data passed between the client and server. In addition, Tamper Data makes it easy for the user to alter the data being sent to the server, which is enormously useful for doing security testing against web apps. I also like how the data is presented in TD a bit better than LiveHTTPHeaders: it’s easier to see at a glance all of the traffic and get an overall feel of what’s going on, but you can still drill down and get as much detail as you like.

Got more Firefox security extensions?  Leave a comment and I’ll collect them in an upcoming post.

[tags]firefox, extensions, security, privacy, safe_browsing, browser, web, flash[/tags]

This story at the NYT web site (registration might be required—it seems kind of random to me) about the prevalence of “piggybacking” on open wireless networks.  Most of the article deals with the theft of bandwidth, although there are a couple quotes from David Cole of Symantec about other dangers of people getting into your LAN and accessing the Internet through it.  Something that really struck me, though, was the following section about a woman who approached a man with a laptop camped outside her condo building:

When Ms. Ramirez asked the man what he was doing, he said he was stealing a wireless Internet connection because he did not have one at home. She was amused but later had an unsettling thought: “Oh my God. He could be stealing my signal.”

Yet some six months later, Ms. Ramirez still has not secured her network.

There are two problems highlighted here, I think:

1. We haven’t done enough to make it clear why encrypting your wireless network is important.
2. More importantly, wireless routers need to be secure out of the box.  Users will not change their behavior unless the barrier for wireless network security is lowered as far as possible, and that includes shipping routers with:
• WPA encryption enabled
• a unique shared key
• a unique router admin password (the fact that millions of routers ship with the same default admin password is embarassing)
• a unique SSID
• SSID broadcast disabled

Think about it: if you purchased a car that came with non-functioning locks and keys, and it was your responsibility to get keys cut and locks programmed, would you be satisfied with purchase?  Would it be realistic to expect most consumers to do this on their own?  I think it’s not.  But that’s what the manufacturers of consumer wireless equipment (and related products, like operating systems) ask of the average consumer. With expectations like that, is it really a surprise that most users choose not to bother, even when they know better?

More: Hey Neighbor, Stop Piggybacking on My Wireless - New York Times »

As a web developer, Usability News from the Software Usability Research Lab at Wichita State is one of my favorite sites.  Design for web apps can seem pretty arbitrary, but UN presents hard numbers to identify best practices, which comes in handy when you’re trying to explain to your boss why the search box shouldn’t be stuck at the bottom of the page (not that this has ever happened at CERIAS, mind you).

The Feb 2006 issue has lots of good bits, but particularly interesting from an infosec perspective are the results of a study on the gulf between what online users know about good password practice, and what they practice.

“It would seem to be a logical assumption that the practices and behaviors users engage in would be related to what they think they should do in order to create secure passwords. This does not seem to be the case as participants in the current study were able to identify many of the recommended practices, despite the fact that they did not use the practices themselves.”

Some interesting points from the study:

• More than half of users do not vary the complexity of passwords depending on the nature of the data it protects
• More than half of users never change passwords if the system does not force them to do so.  Nearly 3/4 of the users stated that they should change their passwords every 3 to 6 months, though
• Half of users believe they should use “special” characters in their passwords (like “&” and “$”), but only 5% do so

More: Password Security: What Users Know and What They Actually Do

According to the National Vulnerability Database (http://nvd.nist.gov), the number of vulnerabilities found every year increases:  1253 in 2003, 2343 in 2004, and 4734 in 2005.  We take security risks not only by choosing a specific operating system, but also by installing applications and services.  We take risks by browsing the web, because web sites insist on running code on our systems:  JavaScript, Flash (ActionScript), Java, ActiveX, VBscript, QuickTime, and all the plug-ins and browser extensions imaginable.  Applications we pay for want to probe the network to make sure there isn’t another copy running on another computer, creating a vector by which malicious replies could attack us.

  Games refuse to install in unprivileged accounts, so they can run their own integrity checkers with spyware qualities with full privileges (e.g., WoW, but others do the same, e.g., Lineage II), that in turn can even deny you the capability to terminate (kill) the game if it hangs (e.g., Lineage II).  This is done supposedly to prevent cheating, but allows the game companies full access and control of your machine, which is objectionable.  On top of that those games are networked applications, meaning that any vulnerability in them could result in a complete (i.e., root, LocalSystem) compromise. 

  It is common knowledge that if a worm like MyTob compromises your system, you need to wipe the drive and reinstall everything.  This is in part because these worms are so hard to remove, as they attack security software and will prevent firewalls and virus scanners from functioning properly.  However there is also a trust issue—a rootkit could have been installed, so you can’t trust that computer anymore.  So, if you do any sensitive work or are just afraid of losing your work in progress, you need a dedicated gaming or internet PC.  Or do you?

  Company VMWare offers on their web site the free download of VMWare player, as well as a “browser appliance” based on Firefox and Ubuntu Linux.  The advantages are that you don’t need to install and *trust* Firefox.  Moreover, you don’t need to trust Internet Explorer or any other browser anymore.  If a worm compromises Firefox, or malicious JavaScripts change settings and take control of Firefox, you may simply trash the browser appliance and download a new copy.  I can’t overemphasize how much less work this is compared to reinstalling Windows XP for the nth time, possibly having to call the license validation phone line, and frantically trying to find a recent backup that works and isn’t infected too.  As long as VMWare player can contain the infection, your installation is preserved.  Also hosted on the VMWare site are various community-created images allowing you to test various software at essentially no risk, and no configuration work!

  After experiencing this, I am left to wonder, why aren’t all applications like a VMWare “appliance” image, and the operating system like VMWare player?  They should be.  Efforts to engineer software security have obviously failed to contain the growth of vulnerabilities and security problems.  Applying the same solutions the same problems will keep resulting in failures.  I’m not giving up on secure programming and secure software engineering, as I can see promising languages, development methods and technologies appearing, but at the same time I can’t trust my personal computers, and I need to compartmentalize by buying separate machines.  This is expensive and inconvenient.  Virtual machines provide us with an alternative.  In the past, storing entire images of operating systems for each application was unthinkable.  Nowadays, storage is so cheap and abundant that the size of “appliance” images is no longer an issue.  It is time to virtualize the entire machine;  all I now require from the base operating system is to manage a file system and be able to launch VMWare player, with at least a browser appliance to bootstrap…  Well, not quite.  Isolated appliances are not so useful;  I want to be able to transfer documents from appliance to appliance.  This is easily accomplished with a USB memory stick, or perhaps a virtual drive that I can mount when needed.  This shared storage could become a new propagation vector for viruses, but it would be very limited in scope.

  Virtual machine appliances, anyone?

Note (March13, 2006):  Virtual machines can’t defend against cross-site scripting vulnerabilities (XSS), so they are not a solution for all security problems.

We have had some success using domain name system lookups to block incoming mail messages that are likely to be junk mail.  While many people (including us) use DNS real-time black lists, the checks below are done against values returned by regular forward and reverse lookups on the connecting IP address.  We’ve stopped a large amount of traffic based on the name of the connecting host or due to “poorly” configured DNS without many complaints.  The number of false positives, while non-zero, have so far been at levels acceptable to us.

The first test is a sanity check of sorts on the name of the connecting host.  If no reverse lookup can be done on the IP address of the host, the message is blocked.  A forward lookup is then done on the just-returned host name.  If the forward and reverse lookups do not match, the message is blocked.

Then the hostname is checked against a regex that tries to match dial-up or home cable/DSL addresses.  If it matches that, the message is blocked.  The expectation is that this will help block the spam zombies on less than ideally maintained home machines out there.

These checks do generate false positives.  There are some domains where outgoing mail comes from hosts with no name in DNS or all hosts of the domain have names of the form ip-NNN-NNN-NNN-NNN.domain.  Some smaller companies or individuals are given addresses from their net providers of that form and are unable to change them.  Apparently many net providers think it’s a good idea to do a reverse lookup on an IP address but then not have a valid forward lookup for the just returned name.  To help with these cases, the SMTP rejection message includes a URL where one can request that their addresses be added to an exception list.

Now to numbers.  During the average day last week our SMTP server got 8719 connection requests.  The previously mentioned DNS tests resulted in the blocking of 4463 messages, or about 51% of all our incoming traffic.  Since this happens before any virus scanning or spam scanning on the content of the messages, it saves quite a bit of CPU and IO time on the server.  While this system isn’t perfect, it is so effective as a first pass filter that we put up with the few false positives that have been reported so far.

My s.o. and I watched WarGames last night, and I enjoyed it not only for the kitschy nostalgia of an 8-inch floppy disk, but for some of the lessons of good information security practices that we still have trouble remembering:

1. Don’t write down your password.  Matthew Broderick’s character is able to break into his high school’s computer system and alter his grades because he reads the password off the secretary’s desk every couple weeks.
2. Don’t make high-security systems publicly accessible.  The W.O.P.R. computer (wasn’t that a great name?) that controls the launch of the US nuclear arsenal is accessed over a public phone line.  Firewalls, anyone?  Bueller?

It does seem like folks are generally getting a lot better with #2, but #1 seems to be a tougher nut to crack.  It’s understandable, because it’s much more of a human behavior issue, but sometimes you just wonder, have we learned nothing in 20 years?

Christopher Kunz reports on the existence of another web app worm, this time exploiting in the widely used Mambo portal/CMS system.  Like the Santy worm that attacked phpBB, Elxbot identifies vulnerable installs via Google, but goes way beyond simple site defacement.

Jeff Moore discusses this as a good example of why web apps need better installation/update systems.  He’s absolutely right.  Wordpress, one of the most popular open-source web apps, has a fairly decent installer, but is a nightmare to upgrade.  The developers don’t even release “upgrades” per se, but give users some minimal instructions on what files to overwrite and what to skip.  Even though the XML-RPC vulnerability that hit Wordpress and many other PHP-based apps a few months ago was patched immediately, it seems likely that there are large numbers of Wordpress users that are unaware of the problem and have not installed (it’s difficult to find sources for stats on this, though).

Beyond that, this underlines the need for both educating developers on secure coding practices, and developing freely available tools to help developers audit their applications.  This is particularly important for the open-source web applications that drive a large portion (a majority?) of dynamic web sites.  An Information Week article from a couple weeks ago that discusses how malicious coders are now targeting applications (including web apps) quotes Howard Schmidt:

In an e-mail, Howard Schmidt, a noted cyber-security expert and former CSO for both Microsoft and eBay, said the SANS report highlights the utility of hardening the presentation and application layers as a means to reduce cyber security events. “The first stop on the way to fix this is through secure coding and better QA of development processes, penetration testing on compiled code as well as vulnerability testing of integrated deployed applications via Web front ends,” he wrote.

Hopefully more people will start to realize this before the problem gets worse.

  I am pleased to announce the availability of the first beta of my_cassandra.php, which can be downloaded from my home page
(change the extension from phps to php after you download it).

Because you get the source code and the custody of your profiles, this version of Cassandra should not generate the privacy concerns that the online version did.  As it is under your control you can also run it at the intervals you choose.  It is made available under an open source license so you can modify it.  It runs under PHP so it should run on almost any platform by changing the path to PHP (from “#!/usr/bin/php -q” for MacOS X).
Enjoy!

P.S.: I already received a patch from Benjamin Lewis from Purdue ITSP, improving robustness while reading a profile.  Thanks Ben!