Strange router behaviour.

I recently started getting proxy error messages while browsing, interesting thing is that I’m not using a proxy and as far as I knew my ISP wasn’t forcing an invisible proxy on us either. I started to investigate with some network tools, here’s a traceroute to google.com:

root@SNB:/home/s3c# tcptraceroute google.com 80
Selected device wlan0, address 10.0.0.1, port 44989 for outgoing packets
Tracing the path to google.com (74.125.230.116) on TCP port 80 (www), 30 hops max
1 google.com (74.125.230.116) [open] 1.763 ms 1.678 ms 2.013 ms

Hitting google (and any other http site ) in 1 hop shows I have a HTTP proxy on my local network. No other traffic seemed to be affected so I focused my efforts on HTTP. Logging into my router and viewing the process list gives me:

# ps -a
PID Uid VmSize Stat Command
1 root 1576 S init
2 root S [keventd]
3 root R [ksoftirqd_CPU0]
4 root S [kswapd]
5 root S [bdflush]
6 root S [kupdated]
7 root S [mtdblockd]
125 root 2036 S /usr/sbin/aconfig
126 root 2688 S /usr/bin/cm_pc
128 root 1576 S init
129 root 5124 R /usr/sbin/mini_httpd -d /usr/www -u root -p 80 -c /c
131 root 6416 S /usr/bin/cm_logic -m /dev/ticfg -c /etc/config.xml
174 root 612 S /usr/bin/cm_klogd /dev/klog
179 root 1580 S /bin/sh /usr/bin/appwrapper tinyproxy-bin
184 root 620 S /usr/sbin/pt_usp
191 root 7104 S /usr/sbin/wlan/wpa_authenticator
207 root 2036 S /usr/sbin/aconfig
208 root 2036 S /usr/sbin/aconfig
210 root 1252 S tinyproxy-bin
252 root 1524 S /usr/sbin/wlan/acsManager
368 root 2564 S /usr/sbin/pppd plugin pppoe nas0 user *MASKED*
455 root 1244 S /sbin/msntp -r 2 -t 5 -p 30 -s 196.25.1.1 0.0.0.0 0.
485 root 1032 S /usr/sbin/udhcpd /var/tmp/udhcpd.conf
488 root 644 S /sbin/dproxy -c /etc/dproxy.conf -d
489 root 632 S /sbin/utelnetd
490 root 1580 S -sh
554 root 1264 S tinyproxy-bin
557 root 1264 S tinyproxy-bin
558 root 1264 S tinyproxy-bin
686 root 1576 R ps -a

The tinyproxy-bin entry immediately jumps out, for one as far as I can remember there wasn’t any proxy running on it a couple of months back since I could do scans on port 80 without false positives. Curious to what else was running I did a full nmap scan with service detection:

root@SNB:/home/s3c# nmap -n -p1- -sV 10.0.0.2
Starting Nmap 5.21 ( http://nmap.org ) at 2011-03-17 13:41 SAST
Nmap scan report for 10.0.0.2
Host is up (0.012s latency).
Not shown: 65527 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Netgear DG632 router ftpd
22/tcp open ssh D-Link/Netgear DSL router modified dropbear sshd (protocol 2.0)
23/tcp open telnet BusyBox telnetd
80/tcp open http Mini_httpd 1.19
443/tcp open http Mini_httpd 1.19
1050/tcp open http Mini_httpd 1.19
7676/tcp open http Mini_httpd 1.19
8118/tcp open privoxy?
MAC Address: 00:30:0A:**:**:** (Aztech Electronics Pte)
Service Info: Host: localhost; Device: router

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 201.97 seconds

I doubt port 1050, 7676 and 8118 has any business being there but how is my traffic being redirected? Here’s the dump for iptables filter table:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
CFG tcp — 10.0.0.1 anywhere tcp dpt:www Records Packet’s Source Interface
CFG tcp — 10.0.0.1 anywhere tcp dpt:443 Records Packet’s Source Interface
ACCEPT all — anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp — anywhere anywhere tcp dpt:1050
DROP all — anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all — anywhere anywhere state RELATED,ESTABLISHED
DROP all — anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP icmp — anywhere anywhere icmp destination-unreachable
DROP icmp — anywhere anywhere state INVALID

Chain PORTTRIGGERFW (0 references)
target prot opt source destination

Interesting to note is that port 1050 is marked as open, we’ll come back to that. I’m not sure what the CFG target is (another chain maybe?) and how the ftp etc traffic is getting in but I’m guessing they’re related, if anyone knows give me a shout.

Iptables nat table:

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MULTINATPREROUTING all — anywhere anywhere
REDIRECT tcp — anywhere !login.router tcp dpt:www redir ports 8118
REDIRECT tcp — anywhere anywhere tcp dpt:7676 redir ports 1050

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MULTINATPOSTROUTING all — anywhere anywhere
MASQUERADE all — 192.168.0.0/16 anywhere
MASQUERADE all — 172.16.0.0/12 anywhere
MASQUERADE all — 10.0.0.0/8 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain MULTINATPOSTROUTING (1 references)
target prot opt source destination

Chain MULTINATPREROUTING (1 references)
target prot opt source destination

Chain PORTTRIGGERNAT (0 references)
target prot opt source destination

That’s it! All traffic on port 80 not going to the router is proxied to port 8118 which the port scan shows is running “privoxy”, this is probably a misidentification for our tinyproxy-bin process. Port 7676 also redirects to 1050 (which was open) which means this port is accessible from the net, I could confirm this with http://www.canyouseeme.org. Now there is no way we should have an open port on our router accessible from the web. Connecting to it with a browser simply gives a blank page. (as in html blank not white blank)

Iptables mangle table:

# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp — anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
TCPMSS tcp — anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Nothing interesting here which was kinda expected. I wouldn’t have minded doing a netstat but the command isn’t supported on the router. We know we’re running code we shouldn’t be and that there’s a possible hole into our system. So what’s next?

[UPDATE]

So it turns out I was way to optimistic, after looking through the filesystem I found “/etc/tinyproxy.filter” which was empty in my case. A second or two a light bulb went on, the proxy is used for url filters, I turned mine on recently to see how it worked and forgot to turn it off. I didn’t have any active filters so that’s why the config file was empty. Disabling the url filter feature made the proxy and the iptables redirection rules disappear 🙂

The two open ports, namely 1050 and 7676 however are still there, these don’t seem to have any function and connecting to them with a web browser only gives an error page. Theses are worth looking into from a security standpoint and should probably be disabled. Since the iptables rules are reset to defaults on each startup removing them isn’t a permanent solution. A better approach is to add a port forwarding rule for these 2 ports to a non existing ip in your subnet.

Advertisements

~ by s3c on 2011/03/17.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: