How to disable WPS on the Netgear N600 router

Recently a vulnerability in the WPS wireless network setup was discovered. I will not go into great detail on that vulnerability here, but will simply show you how to turn this off on the Netgear N600:

  1. Start the Netgear maintenance tool by going to http://www.routerlogin.net. This takes you into the setup tool installed during initial setup.
  2. Locate the Advanced Wireless settings
  3. Make sure the check box next to “WPS disabled” is checked.

Normally the “WPS disabled” option is checked when the router detects an intrusion attempt, and you can clear it here. In this case, we do the opposite – we disable the WPS by telling the router it is getting hacked.

It’s not too late to change your Facebook password – is it?

For the last several years, ever since Facebook allowed third-party access to your data, your account with Facebook could have been taken over.

Not by Firesheep (although the principal is similar), but because of the third-party application actually leaking an access token outside of the conversation between you, Facebook and the third-party.

In a nutshell, the sequence of events allowing this are as follows:

  1. You’re logged in to Facebook, and want to play a game (start up a third-party application)
  2. The third-party application presents a permission dialog page, where you allow the application access to your friends, your personal information, and posting on your wall.
  3. The third-party application gets an access token from Facebook, which allows it to do all these things without you having to explicitly give them permission every time.
  4. That token is exchanged with Facebook every time the third-party issues requests.

So far it is very similar to the Firesheep issue. However, the twist here comes if the third-party application uses a legacy Facebook API:

  1. The access token is sent as part of the URL
  2. The application requests resources from another site (such as an advertiser).
  3. The advertiser receives the referring URL, which contains the access token.

Now the advertiser has the access token that the third-party application uses, and can use that to do the same actions you allowed that application. Best case it now has a list of your friends, worst case you’ve just given the advertiser the right to post on your wall.

And since requests are normally logged, it is even possible that when the advertiser’s site gets hacked, the hacker finds the log, containing these access tokens, and can do these same actions.

Symantec has identified this issue back in late April, and Facebook has since then taken steps to remedy this problem. However, none of these steps completely remedy the problem until September 1st, when the legacy API calls that allow this venue of attack are disabled, and replaced by OAuth.

So what can you do to prevent your account being used as a beach head of attack?

  1. Review what rights you’ve given to what applications, and delete rights you no longer use or think are unnecessary. This is done in Facebook under Account, Privacy Settings, Apps and Websites, Apps You Use.
  2. Insist on using HTTPS wherever you can, and think twice about third-party applications that do not support it.
  3. Change your password. Changing your password invalidates the previous security tokens.

Symantec states that to their knowledge no Facebook users were impacted by this issue. However, this is a definite possibility of attack, and a few good security principles can keep your account safe (or safer) from attacks.

Nagios – how to determine the name of a service in Windows

I’ve recently set up Nagios on one of our test servers, and the Windows client for Nagios allows you to monitor services (whether they started, stopped, etc.). However, the name of the service to monitor isn’t always the same as the name in the Services application in Administrative Tools.

To find out the name of the service, you’ll have to look at the registry:

  1. Open up regedit (Run, regedit)
  2. Navigate to HKEY_LOCAL_MACHINE
  3. Navigate to SYSTEM
  4. Navigate to CurrentControlSet
  5. Navigate to Services
  6. Find the service you plan on monitoring. The name of the node is the name you need to enter on the Nagios server as the name of the service.

Firefox and NoScript to the rescue

I’ve been an avid listener of the Security Now podcast for a couple of years now, and learned a lot of interesting things concerning cryptography, possible avenues of attack on your home network, etc. But two recent episodes of SN showed me that the Internet is a dark and dangerous place, and that you need all the protection you can get. In this case, Firefox with the NoScript plug-in.

Before the two episodes aired, Steve Gibson had stressed the danger of having JavaScript executing in your browser when visiting an unknown site. This was my first encounter with NoScript, which, as the name implies, prevents Javascript from executing. The advantage above just turning off Javascript all together, is that you can allow certain sites, and block certain others. It can be a hassle sometimes to figure out which site you need to turn on to allow your webpage to display properly, but the added security is IMHO worth it.

The first episode that peeked my interest was episode 166, “Cross-Site Request Forgery“. Steve does a much better job in explaining this, but in a nutshell it is the technique that one site uses your cookies for another site to issue a GET request on a form, by displaying an “image”. Much to my surprise, NoScript was mentioned as a plugin for Firefox to prevent this.

The second episode was even more sinister. Episode 168, “ClickJacking“, describes how a page can use an Iframe to display another page behind innocent looking content, and trick you into clicking on a button in the hidden page instead of on the displayed page. This can be used to activate your camera and microphone in Flash, or change your password on MySpace to something only the owner of the malicious website knows. Once again, NoScript was suggested as the way to prevent this from happening to you.

So, Firefox with NoScript comes to the rescue of the beleagured Internet user. And I’m impressed with the development done on NoScript: starting out as a “simple” tool to turn JavaScript on and off for sites, it has now grown into the armor that is added to Firefox to protect you from most malicious websites.

Unless, of course, you turn off the script protection, as both Steve Gibson and Leo LaPorte confessed to in the latest Q&A episode…. :-)

Revision3 suffered Denial of Service attack from… MediaDefender?

Revision3, host of such video podcasts as Diggnation, Systm and TekZilla, suffered a Denial of Service attack over the Memorial Day weekend. The interesting twist in this is that Revision3 says MediaDefender was the one causing the DoS attack.

Why is this interesting? Because for years discussions have been going on about the moral and legal issues of remotely trying to patch a machine that is part of a zombie network. The strategy is using a similar technique as the controllers of the network use to tell their zombies what to do, but in this case it tells the zombies to patch themselves and “revive” them from zombiness. The main point of discussion is whether or not it is morally and legally correct to control someone else’s machine, even if the purpose of that control is to fix a problem.

And here is MediaDefender doing that exact thing, with the disastrous end result that prevents anti-virus companies from employing the remote patch strategy. According to Jim Louderback’s blog post (CEO of Revision3), MediaDefender readily admits to using Revision3 servers for what they believe a good cause (distributing fake torrents to identify and neutralize illegal file sharing websites). The problem is, they never informed Revision3, who noticed the unknown torrents, identified them, and blocked access to them. At that point, the MediaDefender servers went postal, believing that some distributor had blocked them, and started a SYN flood on the Revision3 servers.

When Revision3 traced all this back to MediaDefender, there was no apology or anything. Just a statement saying that they now added a policy to prevent this from happening again. Which is perfectly fine, but what about the thought behind the original policy? What if this DoS was targeted against something more critical than Revision3′s video distribution (not belittling Revision3), like a hospital, power plant or EMS station?

I hope Revision3 follows up on this. Apparently the FBI is involved (a DoS attack is illegal), and hopefully this will result in something more than a slap on the hand.

Update: Wired has blogged about this as well.

Technorati Tags: , , , ,