Netgear DG834PN

[17h13]

Firmware version V1.03.39

[enkore]

I suspect that the entire DG834 series is affected.

[elvanderb]

Thank you but you didn't say if it was vuln or not titou1234 :)

[17h13]

Oups sorry, as expected it is vunerable.

[elvanderb]

ok, thank you!
updated :)

[cowbutt]

confirmed:

Browse to http://my.router.ip.address/setup.cgi?todo=debug and login to enable telnet daemon, then

cat /proc/net/tcp

sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 806 1 808368c0 600 0 0 2 -1
1: 00000000:0017 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 3393 1 80b94b20 600 0 0 2 -1
2: 00000000:7FFC 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 878 1 80a728e0 600 0 0 2 -1
3: D5982331:0017 D5982332:B60D 01 00000000:00000000 00:00000000 00000000 0 0 3398 2 80a724a0 41 8 11 2 -1

0x7FFC is 32764.

[enkore]

Uh, thats really awesome... /setup.cgi?todo=debug is basically a
vulnerability on it's own — it doesn't do any CSRF checks at all.

On 01/05/2014 12:22 AM, cowbutt wrote:

confirmed:

Browse to http://my.router.ip.address/setup.cgi?todo=debug and login to
enable telnet daemon, then

cat /proc/net/tcp

sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt
uid timeout inode

0: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000
0 0 806 1 808368c0 600 0 0 2 -1

1: 00000000:0017 00000000:0000 0A 00000000:00000000 00:00000000 00000000
0 0 3393 1 80b94b20 600 0 0 2 -1

2: 00000000:7FFC 00000000:0000 0A 00000000:00000000 00:00000000 00000000
0 0 878 1 80a728e0 600 0 0 2 -1

3: D5982331:0017 D5982332:B60D 01 00000000:00000000 00:00000000 00000000
0 0 3398 2 80a724a0 41 8 11 2 -1

0x7FFC is 32764.

—
Reply to this email directly or view it on GitHub
#35 (comment).

[elvanderb]

The port isn't opened without the debug command?

[enkore]

I think he only uesd that shell to verify that something is listening there

[elvanderb]

oh ok, why didn't you test with the provided PoC?

[cowbutt]

Double-checking; nothing responding on port 32764 on my DG834PN running firmware version V1.03.39, probably because I'd already put in place some fairly extensive firewall rules when I initially configured it (and I can't be bothered to disable them to see if I can make it vulnerable again). :-)

[elvanderb]

OK, thank you very much, nice to know that firewall can indeed be used to block the backdoor :)

[cowbutt]

Yup, define a service, e.g. BACKDOOR TCP port 32764-32764, then use it in a rule right at the top with action 'BLOCK always' from Any 'WAN User' and optionally Log 'Always'.

That results in:

iptables -t nat -L -n -v | grep 32764

0     0 LOG        tcp  --  *      *      !0.0.0.0/0            my.router.ip.address      tcp dpt:32764 LOG flags 0 level 4 prefix `[BACKDOOR rule not match] ' 
7   308 LOG        tcp  --  *      *       0.0.0.0/0            my.router.ip.address      tcp dpt:32764 LOG flags 0 level 4 prefix `[BACKDOOR rule match] ' 
7   308 DROP       tcp  --  *      *       0.0.0.0/0            my.router.ip.address      tcp dpt:32764 

[stephanethomas]

This rule will only block this port when accessed with the WAN IP address:

python.exe poc.py --ip 92.90.26.108 --get_credentials

It won't block accesses from within the LAN using the LAN IP address:

python.exe poc.py --ip 192.168.0.1 --get_credentials

Which means anyone who can connect to your local area network will be able to retrieve the router credentials through this backdoor. @cowbutt, did you find a way to work around this limitation?

[cowbutt]

I don't do NAT on my ADSL router, so the IP address of the LAN interface is the same as the IP address of the ADSL interface. Consequently, connections to 32764/tcp get blocked no matter where they come from.

Not that I'd really care that much if 32764/tcp was reachable from the LAN. Others may not have such trustworthy users. :-)