1

Some wireless access points are acting a little weird, so I want to reboot them every couple of hours. Luckily there exists a security flaw which lets me login as root through telnet when using port 1111 (without username and password).

Now I want to use that to let my QNAP NAS execute the reboot command through telnet every now and then. The problem is however that that telnet version doesn't give any response if I connect to the AP. The telnet I use on OSX works just fine but the one on the NAS not.

BusyBox v1.01 (2012.06.14-18:35+0000) multi-call binary
Usage: telnet [-a] [-l USER] HOST [PORT]

When I execute telnet <HOST> 1111 nothing happens. I can send the escape character ^] which gives me the following options:

Console escape. Commands are:

 l  go to line mode
 c  go to character mode
 z  suspend telnet
 e  exit telnet

The only way to get some commands executed is by suspending telnet with z followed by some random command which isn't recognized. Then the prompt shows this:

# telnet 192.168.1.5 1111
^]

Console escape. Commands are:

 l  go to line mode
 c  go to character mode
 z  suspend telnet
 e  exit telnet
z
continuing...

asdf
Illegal command.
00>

After that I am able to communicate with the AP, but when I exit the telnet session and try the same again, the AP refuses to connect at all and it must be manually rebooted (looks like the telnet session isn't shut down properly on the AP).

So the question is what commands should I execute in order to communicate with the AP using the Busybox telnet version of the QNAP?

(No, can't use ssh unfortunately)

floorish
  • 253
  • 5
  • 9
  • Are you seriously asking why you're having trouble getting a particular class A exploit (unauthorized remote access, and as root, no less) to work? What happens when you try to telnet in on port 23? Regardless of the answer, flaky equipment with an unaddressed remote-access-as-root-exploit has only three uses I know of. As anonymous gifts to enemies, fuel for dumpster fires or as a source of scrap metal. – HopelessN00b Jul 01 '12 at 07:12
  • @HopelessN00b I thought so that was coming ;) The problem is with the version of telnet on the QNAP, not with the exploit which has actually nothing to do with it, since it works with other telnet clients. It is just an open port. The connection is of course only accessible within our local network, which has a firewall to the outside. And I can restrict connection to that port to certain ip addresses, so don't worry about that. Port 23 is not open, so no connection is possible. – floorish Jul 01 '12 at 09:12

1 Answers1

0

It has to do with some line feeds and carriage returns being mixed up.

I installed netcat on the QNAP through IPKG to get some better feedback:

ipkg install netcat

And used that to connect to the access point and echo the commands with \r\n

(sleep 1; echo -e "system id\r\n";) | nc -q 5 192.168.1.6 1111
floorish
  • 253
  • 5
  • 9