This, along with bufferbloat [1], is why you run OpenWRT or another similarly modern, fully open source distro on your home routers.
Right now, the best supported devices are ath9k's, so things like the Buffalo WZR-* models are ideal.
The WNDR 4700 model specifically doesn't have good support for 3rd party firmware [2] due to it's use of NAND flash in an unsupported manner, so if you have that model you're kind of sunk at this point.
If you want a more hardened setup I recommend pfsense, a freeBSD based firewall/router disto [0]. It'll run on any number of mini/nano boards and several companies sell prebuilt boxes. It can run as a wifi AP as well but I find that a separate AP works best.
Pfsense is in no way more hardened than a OpenWRT box. Both are vastly superior to the stock firmware on any soho router available.
OpenWRT and pfsense come from different backgrounds, OpenWRT was intended as a replacement firmware for consumer wifi routers, while pfsense wanted to be a secure and easy to use firewall appliance on x86 hardware.
We use both, OpenWRT on cheap TPLink consumer routers as a VPN router in home and branch offices, and a bunch of virtualized pfsense firewalls for network security in our hq and datacenter rack.
If you're after real routers as in routing protocols like bgp and ospf and not security devices, both are not of much use. this is where vyatta, a open source Debian based router distribution is better suited.
Wireless performance of openwrt depends on the hardware it is running on, but It's generally not great compared to proprietary gear from ubiquity and mikrotik. Both make dirt cheap wireless gear and routers that can match and outperform Cisco routers that cost 10x more. Wireless ISPs everywhere rely on those vendors.
pfsense (as well as m0n0wall) runs great on ALIX and WRAP boards too, not just bigger hardware.
> If you're after real routers as in routing protocols like bgp and ospf
> and not security devices, both are not of much use. this is where vyatta,
> a open source Debian based router distribution is better suited.
I've found pfsense to be extremely quirky, though it works pretty well. If you can wrap your head around the weird way it's all presented, the CARP and XMLRPC sync between clusters works flawlessly.
That said, when you bring their strange "packages" into the mix, all hell can break loose. So be careful.
Anyone looking into prebuilt pfSense boxes would also do well to check out Ubiquiti's EdgeRouter Lite [0]. I was initially looking at getting an ALIX kit [1] for my home router, but the ERL offered much better performance for roughly half the price. I haven't ordered one yet, but I will as soon as I have a day or two to sit down and properly configure it.
What do you use as a separate AP? My cursory searching indicates there exist enterprise-grade APs requiring a controller device, overkill for my apartment, or I use your standard bestbuy device like we're wanting to be avoiding in this thread.
Most consumer routers actually work fairly well as APs. Once you've turned off all the routing functionality, which are the most complex and resource intensive bits, they seems to actually be pretty stable. I'm currently using an Asus RT-AC66U, which is complete overkill, but I wanted reliable AC wifi and it was the best option at the time. Prior to that I was using an Asus EA-N66R AP.
As for how this relates to the exploit discussed here, your only using it as an AP, you'll very rarely need to login after the first setup since it really isn't doing much, just Wifi <-> Ethernet bridging. If using a consumer router the WAN port isn't connected to anything, no outside access to worry about (unless you did some funky forwarding on the pfsense box). You should also disable management via Wifi. That limits any access to a wired connection to the network, meaning someone is already in your apartment to physically patch in with an ethernet cable. Any security bets are off at that point. If you want super extra special security you can setup firewall rules on the pfsense box that only make the AP's IP address accessible from a particular port.
As dumb as this exploit is on the part of netgear, remember that to exploit it the attacker had to have already broken the WPA2 security to access the wifi or physically plugged in with ethernet. The first vector can be avoided by simply turning off management via wifi.
As dumb as this exploit is on the part of netgear, remember that to exploit it the attacker had to have already broken the WPA2 security to access the wifi or physically plugged in with ethernet. The first vector can be avoided by simply turning off management via wifi.
Or accessed your router internally via JavaScript, img tag, or iframe hidden on a malicious or compromised page. XSRF is real.
Edit: granted, browsers limit what JavaScript can do across sites, but request-only access is enough to change DNS settings to something malicious, and if the attacker can inject unescaped content into the page in some way, then they can run JavaScript on the router page and send data back that way.
Edit2: I'm not certain, but I think the timing of image load events could be used to determine success/failure of router actions loaded through a hidden img tag.
You could use a Ubiquity Unifi. They're cheap ( US $69 ) and the control software is only needed to provision them (so long as you're willing to forgo the guest wifi captive portal feature - if you want that then you have to run the control software full time.)
I recently got a Unifi and I'm pretty happy with it. It's somewhere between enterprise and consumer-grade, with an administration interface and reliability / performance leaning towards the enterprise side, and price leaning towards consumer-grade :)
I've found pfSense really shines on old PC hardware since the embedded boxes I've tried it on tend to slow a bit. Something with a still functioning HD and at least 256Mb memory does pretty well with it.
I haven't tried it on an embedded platform, e.g. a Geode or Via CPU.
I'm using an old mini-ITX IPC board from Jetway with one of the first dual core Atom cpus, 1GB of ram (overkill) and 4 x Gbit ethernet ports. With a slim case / power supply I think it was ~$250 about 5 years ago when I bought it.
Other than moving apartments it's only ever been rebooted once, to upgrade from pfsense 1.2 to 2.0. It's never crashed and never caused a problem, and I beat on my network connection. OpenVPN performance from outside is only limited by my WAN speed. It's been awesome.
I also use pfsense in a VM in front of a bunch of other VM's on a VMWare server and it works great for that as well.
I've used an old eMachines PC with a couple of network cards and a switch in the past. An order of magnitude better than the Linksys router from my ISP it replaced. Also never had to reboot until I moved.
Never tried it as a VM front before. Good to know it's another option.
I was formerly on solar before moving to an apartment. Hence the "I've used an old eMachines PC... in the past." Besides that, the power supply barely made past 200W, which is basically 2 incandescent bulbs.
As someone who was on solar you should realize that 200W is a _lot_ of power. Especially if it's 24/7. If you hadn't heard people have moved away from incandescent bulbs because the energy use is considered unacceptable.
For a project that claims to be "Spreading the word to correct basic assumptions regarding goodput and good buffering on the laptop, home gateway, core routers and servers", there is remarkably little info I can actually find on the bufferbloat.net web site. I even clicked the Help link, only to discover it's a link to the redmine documentations. Thanks.
I have a WNDR 4700 and I can't replicate as described. However, I've also never trusted the stupid thing since it stores passwords in clear text (or at least is happy to display them in clear text on one of its admin pages).
I had fun freaking out my not-so-tech-savvy-but-exceedingly-paranoid (tin foil paranoid) uncle: He bet me $50 I couldn't crack his WiFi password. He let me use his iMac that was already connected.
I hopped onto the Admin page for the router. Had a password, which make sense. I submitted a test password, and there was no page-refresh or network activity... hm. Must be just in the Javascript...
Sure enough, it was obfuscated, but the password was in the damned HTML and easy enough to find. I got $50, and the priceless look of horror on my uncle's face.
I then explained to him that physical access to a computer usually equals "Game Over" ;)
But you didn't have physical access to the router. Setting aside that you could probably dump it out of memory if you had root on the OSX box, the router shouldn't have coughed it up so easily if it was supposed to be secure.
That's different. Browsers need to show your password to external websites to prove to others that you're you. This requires storing the actual password. They expose saved passwords in the UI because if they didn't, it would create a false sense of security. There's always going to be some way to get the saved passwords, or the feature wouldn't work.
The router admin interface only needs to check your password. It can do that by storing only a cryptographic hash, not the password itself.
I think they could however, as a default behavior, store each password encrypted individually using itself as a key, that way no plaintext passwords would need to be stored at all.
Yup that's right, my bad. I were thinking of a way of somehow not requiring input yet providing passwords without plaintext storage.
What would actually work I guess would be storing a hash of <the password, a unique string provided through https auth>. So for the first time the browser would hash the pass and afterwards just provide the pass to the server as a hash without requiring input, acting as a normal pass to the server. However, that would either require some sort of universal agreement among browsers to work, which is tricky to require, or some browser-server protocol in which the browser would only carry such procedure to supported servers. If a supported server is accessed through a non-supported browser, the server itself would perform the hash.
Probably too much of a hassle just in name of abolishing plaintext passwords on browsers, but I couldn't think of anything simpler. However, fun to imagine :)
Obs: This would have the extra bonus of depriving knowledge of plaintext passwords to servers (in case they are compromised, the attacker would not get to try the pass across other services) and preventing password extraction through impersonation of webpages (although this is already guaranteed by https to some extent).
If servers accepted a hash of a password instead of the actual password then the hash becomes the password. Ie, possession of the hash is equivalent to possession of the password since it can be used to authenticate.
Therefore, this is no different than storing them in plaintext. Furthermore, it would mean that if the hashes got stolen because a server was compromised those could be used as passwords and that would make it pointless to hash them in the first place.
And if you need to log in from a different computer?
All you are suggesting is replacing one password with another, harder to remember password. The system where the server only stores salted hashes and hashes your password server-side every time you log in is called "good practice". If you're allowing dedicated protocols and hard-to-remember keys, just use public/private keys.
Browsers need to store the passwords in plaintext, because they need to populate the password field when you visit that website. However, you can store them encrypted using a master password and decrypt them once per session.
And, on OSX at least, every browser does this anyway, since the Keychain is right there to make use of and unlocking it is built into the OS. I'm really surprised Windows has no equivalent to this.
You're using Keychain correctly, but using your computer's authentication system incorrectly. Desktop environments in general (in Windows, OSX, Linux, etc.) assume that you will lock your session whenever you are not present and in control of the computer. (Thus, Keychain locks when the session is locked.) This is currently a big hassle to do, but all other security on the system is built up around that concept.
Really, PCs need something like TouchID. Or something like pairing to your phone, and then detecting it in proximity and prompting a TouchID confirmation from it. Phone goes out of proximity = computer locks.
I've found setting up a hot corner (I use the bottom left on OS X) works well for locking quickly. Quick flick of the wrist locks it no matter where the cursor is, and unlocking it is basically muscle memory for me.
I don't wish to encourage to culture of phone over-attachment.
I am not tethered to my phone, and I don't wish to be. It's always around here, somewhere, but not on my person unless I'm out of the house. If I get up, it is going to usually stay on the table. If I go upstairs, unless I'm using it, I'll probably leave it downstairs. I am not going to worry about keeping it in close proximity to keep my computer unlocked.
A lot of ThinkPad models have fingerprint scanners. The software connected to it sucks big time, as pretty much all oob software shipped with ThinkPads, but the hardware is there, and locking/unlocking with fingers works pretty decently. I guess we'd have to wait for Apple to discover it and fanfare it as the latest greatest invention to get any mindshare adoption of it though.
It's a big hassle because many of the things that cause you to get up from your computer will both distract you and require your hands: spilling coffee on the table and running to get a paper towel to wipe it up with; stopping your baby, in the same room, from touching something they're not supposed to; retrieving the next season-DVD of a TV series from your bookshelf. It would be far better if the computer "failed safe", so to speak.
Auto-lock/"screensaver mode" (wow, remember when computers had screensavers?) sort of does this, but the time the computer is most vulnerable (especially in any semi-public setting) is right after you dash away, not after it's been sitting idle for 15 minutes. When a computer's owner could come back at any minute, the best time for a social engineer to strike is the moment the owner leaves.
The last case especially (watching a marathon of some show with some friends) reveals an interesting bit of etiquette: it's rude to lock your computer in front of friends--it implicitly suggests they're likely to mess with it, and that you don't trust them enough to mess with it in a way that's merely funny, rather than potentially harmful. The great thing about an automatic proximity-based lock would be that, in going to the bathroom or whatever, the computer would always lock--so there'd be no decision to make which could be read into. (This is oddly similar to rhetoric regarding the incentive-structures of birth control pills vs. condoms.)
A browser has to be able to supply clear-text passwords to websites, so strong hashing and discarding the clear-text won't work in their use-case. Your router only need to authenticate your password, so it _should_ be using bcrypt/scrypt/pbkdf2 to hash the password and not storing it anywhere in clear-text.
One alternative to underpowered routers running OpenWRT or pfsense is to use a beaglebone black as your router. It's got well-supported wifi devices with antennae available, and you're not compromising on clock or ram.
Except the BBB only does 10/100 Ethernet so can't really operate as a modern router. The advantage of say an OpenWRT modded D-Link DIR-825, is it includes a gigabit router that handles internal traffic while the cpu handles the firewall and vpn to the outside world. Because local traffic is handled by completely separate silicon inside the router, CPU and ram is not a constraint.
I live in a small apartment surrounded by neighbors with wifi networks. 100mbit is plenty for the wireless portion of my network, and the wired portion doesn't need a firewall. Sounds like your constraints are very different.
Well, there are also more powerful options, e.g Buffalo's WZR-HP-AG300H, which has 128MB RAM / 32MB flash / Gigabit Ethernet and two radios. Not to forget: Power consumption is should also be taken into consideration for an always on device.
Exploit doesn't appear to work on a WNDR3700v2. I'm hoping it doesn't, as this has been the only router I've ever liked after years of dealing with complete garbage.
If you have a Netgear WNDR3700v2 or a WNDR3800, check out Cerowrt [1]. The latest stable build, 3.7.5-2, has been exceptionally stable for me, and fast. I would highly recommend it.
So has anyone used any of the open hardware alternatives, like routerboard.com ? Seems like having the schematics and the firmware would be a reasonable place to be.
I looked into these kind of things but I'm in an odd position where I need an ADSL2+ chipset of a certain kind (Broadcom with good noise filtering) because of the state of my phonelines.
I was looking into running an ADSL modem in full-bridge mode (you'd be surprised how many of these modems don't support that anymore) + a routerboard or mirotik product, but when you add up the cost and configuration time it just wasn't worth it.
I'm currently running a Billion 7800VDPX, which I now have the GPL sources to (after some prodding). When I finally have some time to sit down and risk bricking my device, I'll have a look at getting OpenWRT working (although at last glance they were never going to support ADSL).
This post, and other recent ones like it, indicate to me the importance of running a port scan and making sure no management abilities are exposed over the WAN side of these devices.
Any suggestions on good, fast online port scanners?
Question: I have Cable internet here in Aus (100mb/10mb) and I like my connection, but we have to use Telstra's silly modem, and they refused to activate any other one on the network.
So, lets assume I don't trust this AP and Modem to be secure (fair enough assumption in my opinion) -- the best way would be to perhaps build my own Wireless AP running pfsense, on a BeagleBone Black or similar?
Do companies like Netgear not have a team whose only purpose is to try to break their own products? I thought that was a primary source of employment for infosec types.
I like that this was technical and informative, but still talked down to people like me who aren't at all knowledgable with how infosec works. Great read; wish I could find more like it.
I don't think he meant "talk down" in a negative way. I think he was trying to say that it clearly explained things to someone who doesn't know about the topic (while still being full of details to someone who does).
Right now, the best supported devices are ath9k's, so things like the Buffalo WZR-* models are ideal.
The WNDR 4700 model specifically doesn't have good support for 3rd party firmware [2] due to it's use of NAND flash in an unsupported manner, so if you have that model you're kind of sunk at this point.
1. http://www.bufferbloat.net
2. http://wikidevi.com/wiki/Netgear_WNDR4700