CERIAS Blog

Page Content

Illinois WiFi piggybacker busted

Share:

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.

Web App Security - The New Battlefront

Share:

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:

Useful Firefox Security Extensions

Share:

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]

Securing wireless networks is far too difficult

Share:

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 »

Password Security: What Users Know and What They Actually Do

Share:

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