Remote code execution in Asus router firmware(github.com)
github.com
Remote code execution in Asus router firmware
https://github.com/jduck/asus-cmd
10 comments
Thanks for the tip this is exactly what I had to do to get the latest firmware upgrade with the patch.
note to anyone not using openwrt:
you should be using openwrt :)
you should be using openwrt :)
AsusWRT is pretty great on its own, apart from this bug, and its kept uptodate.
Asus released updated firmware it seems, that was quick!
http://www.asus.com/ie/Networking/RTAC66U/HelpDesk_Download/
http://www.asus.com/ie/Networking/RTAC66U/HelpDesk_Download/
No update for N56U yet.
>2014/11/21
Well, killing a process is the easiest workaround for now, and it should work until we get a patch.
>2014/11/21
Well, killing a process is the easiest workaround for now, and it should work until we get a patch.
Worst case is that all publicly accessible routers were rooted en-masse within an hour of this announcement. My solution is an offline factory reset and firmware update.
Is there any risk of persistent root on these devices?
Is there any risk of persistent root on these devices?
This issue is nowhere near this serious, it's only exploitable from within the LAN. (http://forums.smallnetbuilder.com/showthread.php?t=21774)
In the days of javascript, this is not such a big roadblock. https://developer.chrome.com/apps/app_network
Been using > https://code.google.com/p/rt-n56u/ on Asus RT-N56U for more then a year now. No issues at all. This firmware is maintained by "Andy Padavan" Changelog here > http://rt-n56u.googlecode.com/git/changes.eng.txt Latest update was yesterday. You can use Entware package manager to install any of this packages here > http://entware.wl500g.info/binaries/entware/Packages.html
Question- Lets say you patched this 'too late' - Would doing a hard reset of the router by holding the reset button of the router actually remove any backdoors/exploits? Or is it the case if someone gets root that backdoor will be persistent forever and your only hope is to get a new router? My understanding is that the factory reset only resets the configuration options and does not physically reimage the OS.
> Would doing a hard reset of the router by holding the reset button of the router actually remove any backdoors/exploits?
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.
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.
reuploading the firmware should also work, it usually just reimages the system partition. if you don't know if you trust that you can also go to dd-wrt, openwrt or tomato and once you see that running you know the system partition has been reimaged and should be fine.
So simply upgrading the firmware now will remove any existing roots or backdoors?
To a point. It's possible to persist a backdoor on these routers beyond a firmware upgrade. If you think you're a big enough target for someone to actually install a backdoor like this on your systems, I'd be happy to take a look.
There is also a project that provides an open firmware for some of the vulnerable Asus routers:
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?
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?
I haven't tried that one. I'm using asuswrt-merlin [0], which is another fork based on the official Asus sources.
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
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
+1 for asuswrt-merlin. It's the Cyanogenmod of the router world: the stability and speed of officially supported drivers, with the added flexibility and freedom of a custom firmware.
I wouldn't say its quite as stable, but it is close.
That doesn't seem to be on the RT-56U which the OP has.
Why not use a good Tomato build? This is my favourite at the moment and gets updated quite frequently:
http://tomato.groov.pl/
http://tomato.groov.pl/
OpenWrt[1] supports many devices, too, and has a strong emphasis on free/open source software. (Tomato uses a proprietary GUI.)
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
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
After great success with Polarcloud's Tomato on the old WRT54G, I really wanted to use tomato on my AC66U, which is on "Tomato by Shibby"'s supported list, but it resolutely refused to run; same story with OpenWRT. Merlin's build seems to be the only reliable choice for Asuswrt, or at least that's my experience.
Running DD-WRT v24 sp2 on my N66U here. It works like a charm and you can customize the OS all you want since it's Linux-based.
Any reason you went with DD-WRT instead of OpenWRT (just curious)?
I've been a DD-WRT user for many years now. I have considered the other options before installing DD-WRT on the N66U (which I received just after Christmas), but none of them were offering significantly better functionalities over DD-WRT for what I needed, so I just went with what I knew worked well.
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.
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.
Do you know if its possible to somehow get the 66 to "split" a connection somehow,
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
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
DD-WRT allows you to do this using its QoS service. You can specify rules by range of IPs or by MAC adresses, so this definitively is possible.
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:
http://www.dd-wrt.com/wiki/index.php/Quality_of_Service
http://www.dd-wrt.com/wiki/index.php/Iptables_command
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:
http://www.dd-wrt.com/wiki/index.php/Quality_of_Service
http://www.dd-wrt.com/wiki/index.php/Iptables_command
Or, just use the Asus' own QoS system.The newer routers actually have a fairly fancy one. But neither of these has a way to limit directly by interface, do they?
Tomato by Shibby can use QoS on vlans, and that makes it possible to apply traffic shaping on different interfaces.
Are you really looking to limit the speed available to wireless clients, or are you just trying to limit the impact a wireless device can have on the performance experienced by the wired devices? Reserving some external bandwidth as wired-only is a pretty crude way to accomplish the latter.
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.
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.
seems like you should be able to define a qos policy to apply to frames tagged on the wireless vs wired, and apply it on the uplink.. pretty sure they do show up at individual interfaces. problem with torrent or anything is, you dont have very fine control of the incoming frames from the provider. used to run game servers, and the incoming discovery packets would fill up the inbound after a while, even if you throttled the existing clients, there wasn't much you could do.
There is also an OpenWRT version: http://wiki.openwrt.org/toh/asus/rt-n56u
But it doesn't seem very well supported since 2012.
But it doesn't seem very well supported since 2012.
Is this vulnerable from the LAN-side only or from the WAN side?
LAN-side only according to the Asuswrt-Merlin people: http://forums.smallnetbuilder.com/showthread.php?t=21774
In case it wasn't obvious: yet another case of shooting yourself in the foot with your amazing C skills... Will people ever learn to avoid this, since 99,9% of all C programmers simply aren't good or meticulous enough to write network-facing code in a safe manner?
What's the alternative?
An easy hack for disabling many of these additional "features" is just to overload the port by forwarding it to a non-used IP:port.
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.
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.
NSA diode candiate, unfortunately :(
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
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
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.