TCP backdoor 32764 – how we could patch the Internet (or part of it)

http://blog.quarkslab.com/tcp-backdoor-32764-or-how-we-could-patch-the-internet-or-part-of-it.html

by musty • 13 years ago

113 20 13 years ago

blog.quarkslab.com

tdmule• 13 years ago

The direct source of this information is the github page mentioned in the article, https://github.com/elvanderb/TCP-32764

lotsofcows• 13 years ago

Anyone played with this?

term1$ tcpdump -i en1 -X -n port 32764

term2$ telnet 192.168.0.1 32764

Output doesn't show the expected hex code. Is this naive?

ancarda3• 13 years ago

Yeah, I tried but with my external IP:

    $ telnet [redacted] 32764
    Trying [redacted]...
    telnet: connect to address [redacted]: Connection refused
    telnet: Unable to connect to remote host

Does this mean my router has no backdoor? Is it clever enough to avoid detection?

mhurron• 13 years ago

Are you running one of the affected hardware models?

sil3ntmac• 13 years ago

Check your internal IP as well, some models are only vulnerable on the LAN.

Metasploit has a check module for this, and will also get you a shell:

https://community.rapid7.com/community/metasploit/blog/2014/...

eschulte• 13 years ago

The use of the vulnerability to repair the vulnerability is very cool. I've done some related work, which may be of interest when one wants to patch a bad binary on the router (instead of simply removing a bad binary as done in this article). http://eschulte.github.io/netgear-repair/pub/netgear-repair....

dlitz• 13 years ago

I guess this is yet another reason not to rely on firewalls and outdated notions of "internal" and "external" networks for any kind of real security.

Increasingly, it seems that firewalls are doing less to improve actual security, while continuing to hinder legitimate network connectivity and the deployment of new protocols.

gnu8• 13 years ago

I think you're conflating firewalls and NAT. The idea of "internal" and "external" networks still apply in a non-NAT environment but what takes some getting used to is that with full end-to-end connectivity, you're back to an implicit "default-allow" policy where NAT created an implicit "default deny". The answer is to have a default deny firewall rule on your border router (your home gateway appliance), and then allow services as needed.

zurn• 13 years ago

Everything he said applies to a typical legacy corporate network that has a centralised default-deny firewall on front of it (but no NAT).

Host-based firewalls are much more flexible and have many security advanteges.

nmc• 13 years ago

Corresponding shodan search: http://www.shodanhq.com/search?q=port%3A32764

Edit: search directly for the vulnerability

http://www.shodanhq.com/search?q=port%3A32764+ScMM

http://www.shodanhq.com/search?q=port%3A32764+MMSc

squigs25• 13 years ago

cool article - I do think the easy fix is port forwarding?

matt_kantor• 13 years ago

I'm disappointed that this wasn't taken to its logical conclusion: use the backdoor to remote-patch affected routers.

astrodust• 13 years ago

Jail is fun!

etcet• 13 years ago

It's about liability, the possibility of failure, and touching stuff that isn't yours. If someone does write such a program, it better be thoroughly peer reviewed. That said, I'd prefer to have a bricked router than one with a backdoor...

jonalmeida• 13 years ago

Reminds me of the backdoor in D-Links routers: http://www.devttys0.com/2013/10/from-china-with-love/

wcdolphin• 13 years ago

Can we use the exploit to actually apply this patch?

TwoBit• 13 years ago

I'm hoping that some day a lawsuit is successfully taken against a device maker who does this.

TCP backdoor 32764 – how we could patch the Internet (or part of it)

Related Stories