Remote code execution in Asus router firmware
github.com
github.com
In the Administration > Firmware Upgrade tab, never rely on their [Check] version button. It's consistently inaccurate. It's a long-known (and serious) flaw that's been like this since day one of these products and still to this day. It'll happily report, "The router's current firmware is the latest version.", even if it's months behind in vulnerability fixes. Go to Asus' site for the latest firmware then use the upload option to upgrade. Or, probably better yet, don't use their firmware.
you should be using openwrt :)
http://www.asus.com/ie/Networking/RTAC66U/HelpDesk_Download/
>2014/11/21
Well, killing a process is the easiest workaround for now, and it should work until we get a patch.
Is there any risk of persistent root on these devices?
This "hard reset" method just resets the nvram configuration to default values. It doesn't touch the kernel/userland portion of flash. Once someone has code running on your router, they can easily update the firmware in place. This means you should at minimum flash your router with a new trusted firmware file from the manufacturer (If you download the new file over HTTP, the malicious code on your router could intercept this download and re-inject itself. The mid/high-end Asus routers should be more than fast enough to proxy all of your HTTP connections.).
Many Asus routers use Broadcom's CFE bootloader. Source is available for CFE version 6.0 (used in the AC66U and newer routers), so custom versions can be created with a slightly lower barrier to entry than binary assembly patches.
It's also fairly trivial to modify existing router firmware images, using tools like binwalk and firmware-mod-kit.
With this in mind, your worst case scenario is:
1. The attacker uploaded a new firmware to your device.
2. It includes a modified bootloader to persist the exploit when you do a firmware upgrade via bootloader.
3. It includes a modified kernel/userland with exploit code, and a feature to hide/preserve the affected areas of flash.
This is a relatively unlikely scenario, but could also be hard to detect without externally dumping your SPI flash chip. It's also hard, but not impossible, for an attacker to exfiltrate information from your network unnoticed at this point. Chances are you don't monitor all of your outbound traffic beyond the router if you're running stock firmware.
Another exfiltration method could involve placing the Broadcom wireless chip into client mode and sending data through a nearby wireless network, or just speaking raw wireless frames which are mostly invisible unless you're specifically monitoring wireless traffic on the same channel. This can be done in a sneaky fashion if your router has dual wireless radios (to do concurrent 2.4ghz and 5ghz) and uses the same SSID for both frequencies. One of the radios can be put into client mode without disrupting connections to the other. It's worth noting you can't run the Broadcom radios I've seen in Asus routers in both client and AP mode (or monitor mode, etc - check the wl command line tool for control) at the same time, which makes this harder.
https://code.google.com/p/rt-n56u/
It seems to be active. I've been thinking of switching to it from a stock rt-n56u. Anyone have any experience using this firmware?
It's very similar to the original firmware, but with a few extra bug fixes and features. Asus occasionally backports some of the bug fixes to the official firmware. The vulnerable feature has been disabled in the latest version. [1]
[0] https://github.com/RMerl/asuswrt-merlin
[1] http://forums.smallnetbuilder.com/showthread.php?t=21774
The rt-n56u appears to have preliminary support. [2]
[1] http://wiki.openwrt.org/toh/start [2] http://wiki.openwrt.org/toh/asus/rt-n56u
I have 2 routers running DD-WRT (RT-N66U as my main router and TP-WR1043ND as a wireless bridge) and it works like a charm.
For example lets say i have a 100mbit symmetric connection coming in with the 66 siting on the end of it as the home office router, can i somehow dedicate 10mbit of this to be used only by the wired network and remaining 90 available to the wireless
So if someone is downloading/uploading too much it never can use more than lets say 90% of the external wan connection
You can also set rules regarding specific groups of services (games, torrent, netflix, etc.).
If you want a more powerful way to control your bandwidth, DD-WRT has iptables installed, which can be configured by connecting to the router through SSH. The possibilities using iptables are pretty much limitless, but there is a level of complexity that is completely abstracted when using the QoS service.
For more information, see:
Any time you have a bandwidth sharing issue, the first step should be to rate-limit the router to just below the modem's speed (thereby preventing the modem's bufferbloat from kicking in) and apply an advanced qdisc to your router's WAN interface (preferably fq_codel if your software is new enough). That will keep latency from going sky-high when the WAN connection gets saturated, and ensure fair mixing of competing flows.
Only if that is insufficient should you move on to more barbaric strategies like overtly singling out certain clients or protocols for special treatment, since those policies are high-maintenance and often prevent the second-class citizens from getting full performance even when the network is otherwise idle.
But it doesn't seem very well supported since 2012.
This is only really useful for the Internet side of things for standard manufacturer's firmware or if you're using WRT.
For new routers, this is standard practice for me until a WRT option becomes available. Sometimes you can't, I remember not being able to overload something on a Linksys EA6500.
For edge devices, it's a criminal that high security standards are not more pervasive. Though given the nature of retail products, it's not a big surprise even though it is still disappointing. (How many of these boxes even work for longer than 5 minutes without spontaneously rebooting (crashing) or having a xfer rate within an order of magnitude of the channel bandwidth?)
PS: If there were a minimal OpenBSD/(x86|arm) based pfSense-alike project that could be easily themed, minified and plugin-ed, that would rock... and potentially dramatically reduce the attack surface by reducing the duplication of awful embedded web app implementations. (Yes, there are DDWRT and other Linux embedded network gear projects and pfSense (which is great)... OpenBSD for fewer lines of code.) It seems like what might happen going forward because the existing vendor stacks are often terrible and likely expensive for them to maintain. (Kickstarter for hw+sw or enterprise "crowd"-funded perhaps.)
Folks requesting pfSense ARM support: https://forum.pfsense.org/index.php?topic=34707.0