Recent Fritz Box exploit

Question

Background info:

About 50% of the ADSL and cable internet access in Germany (and presumably parts of the EU) goes over AVM Fritz routers, either verbatim or rebranded as e.g. "1&1 Home Server" or "T-Online Box".
These are embedded MIPS systems with a couple of ethernet ports, an ADSL or similar plug, and other optional stuff (DECT, WLan, USB ports) running a Linux (2.6 ???) derivative.

About three weeks ago, an exploit became known which allowed gaining root access to the router. The exploit has apparently been used to call service numbers on the Falklands, charging unwitting users.

AVM's first public press release was that this was not a serious threat (what else would they say!) because it requires remote access being enabled, which is not the case by default, and which most users don't have enabled anyway.

A few days later, it was revealed that the exploit has nothing to do with remote access at all, and that someone could take over your router if you merely visited an otherwise harmless website which contains a page with malicious code. An OS update was released the same day.

Yesterday, it was alleged that a detailled description is being published on "specific hacker sites" while several millions of routers remain unpatched (i.e. vulnerable).

Questions:

1. How could such an exploit, conceptually and practically work?¹. When you visit a website (or do pretty much everything else), your browser runs a DNS query and opens a TCP connection to the remote host. The router relays your DNS query and then NATs your SYN packet (and the SYN-ACK, and all following datagrams).
In other words, the router is pretty much copying packets from one ethernet port to another (updating the IP checksum after NAT, but that presumably happens in hardware anyway, but either way software implementations of TCP checksum have been stress-tested for 40 years, they're pretty much rock-solid?). Basically, as if doing a splice from one socket to the other, except it happens in the network stack.
One should seriously hope that merely forwarding a packet to another port works 100% reliably with no exceptions and no means whatsoever of being exploited! The router doesn't validate or execute anything inside the datagrams, there is no reason for the router to even look at the "binary blob" inside each packets (... and as far as I know, it doesn't do any content filtering?).
I'm baffled how such an exploit could realistically work. Any idea?

2. Seeing how "Linux packet filter is bugged" looks like the only plausible explanation (what else could it be?), do I have reason to start panicking about my Debian server?

---

¹Note that I'm not looking for a how-to recipe, and I don't want to run an exploit.

Answer 1

After searching all day and digging through a few thousand more or less irrelevant posts in several user forums and a site which presumably "tests" for vulnerability (the telnet transcript however doesn't show anything but a somewhat broken HTML page), I found an actual exploit site.

Turns out that as usual the publicly available information was deceptive.

What is it?

The exploit, without too explicit details, is a combined XSRF / injection attack, and a sophistication of an attack that has been known since at least early 2009:

• The router's web interface, which is accessible on the LAN (and optionally also remotely), has a localized user interface.
• The web interface, which lets you change settings and run some commands, is a very obvious attack vector, which can be (or so you would think!) thwarted by setting a password.
• The exploit works because the localization code does not verify its parameters. Localization, however, includes the login page, so the exploit will run before you even need to authenticate. Setting a password will therefore not prevent the attack.
  This is the one spectacular new feature of the present exploit.
• The router will pass the requested and unverified interface language to an utility which runs as root (... and executes its parameters in a shell).
• Once that fact is known, the exploit becomes very obvious: Select a user interface language followed by a separator and an any shell commands which you wish to execute. This is a very typical injection attack (much like the more widely known SQL injection attacks).
• Typically this would be used to enable remote access and upload the passwords/config file to another server via FTP, or download a dialer, or similar.
• No "malicious code" per se is needed on the attacking website. The attack happens simply by providing an URL (for an image or such) which points to the router's default network name (or its emergency IP address) and contains the commands to execute as POST variables.
• In principle, this could be done on any otherwise harmless site via an ad banner, even without the site owner knowing.
• The user's browser tries to open the URL and thus runs the code on the router.

What to do about it?

Apart from the obvious thing, updating the firmware (hopefully a month ago already!), one should have a browser extension installed that prevents suspicious cross-site request/scripting, such as NoScript or RequestPolicy. This is something that everyone should have anyway.
Also, blocking ad banners is a definite consideration, if one doesn't already do that anyway.

What about Question 2?

Since it is not a router vulnerability per se (that is, a bug in the network stack), but merely an exploit of a broken user interface (which incidentially runs on the router), other Linux systems which don't have this interface, are not affected.