Was my router's username and password hacked?

[john9527]

@john9527 Even with the apparent conflict in options, at least two of those effected(?) claim that they didn't have SSH enabled for WAN or LAN. So this, in itself, is not how they initially got in.

Take a look at the changelog for dropbear......they fixed several exploits in the .74 release (latest, which both Merlin and my fork use) which allowed for root command execution. Maybe there's one that hasn't been addressed yet. I did check the CVE databases, but didn't see anything new.

 

[eddiez]

Q:
> In our efforts to find out what is happening, all logs show the following Dropbear output:
>
> 10849 admin_ed 1136 S dropbear -p 192.168.1.1:22 -a -j -k This is sort
> of interesting (and I think I see the bug) with the options '-a -j -k' it should be '-a' or '-j -k'
>
> Code:
> -j Disable local port forwarding
> -k Disable remote port forwarding
> -a Allow connections to forwarded ports from any host
>
> Can you explain, given the output of all options in the line, if there is a sequence in which these are interpreted?
> In the above example, SSH access should only be applicable to LAN.

Respons:

Hi Edgar,
The "-a" option is ignored if "-k" is specified - the remote forward will be disallowed before it gets to check the "-a" part. "-j" is separate for local forwarding.

I haven't followed that forum thread too closely but those flags don't really seem relevant.

Cheers,
Matt

 

[Wutikorn]

My fork is OK.....just wrote a patch for Merlin. Looks like it came in with 380.59 (Colin got it)

So should Asus be told about this problem?

 

[john9527]

So should Asus be told about this problem?

Given Matt's (dropbear) response, it's something that should be fixed, but probably not a big deal. It was just something that jumped out at me looking at the data. I'm sure ASUS will get feedback through Merlin's work.

 

[eddiez]

Gents, I am no Linux brain (not even a coder so to speak), so if you wanted to keep your ACCEPT entry in iptables without someone deleting it manually (so make it appear again)...how would you do that? Trying to figure out howcome the iptables can't get rid of the 16161 ACCPECT line...

 

[tomsk]

Spike of port 16161 activity around dec 23rd..... was that when people started noticing it?
https://isc.sans.edu//port.html?port=16161

 

[john9527]

Trying to figure out howcome the iptables can't get rid of the 16161 ACCPECT line...

It looks like they may have also started a background process (from your ps output you sent)

28297 admin_ed 1380 S {exe} ash /tmp/nat_restore

try to copy /tmp/nat_restore off to a safe place to preserve it
then, in case it's a script running.....try to do a 'cat /tmp/nat_restore'
then kill that process and see if you can then delete the rule.

 

[netware5]

Gents, I am no Linux brain (not even a coder so to speak), so if you wanted to keep your ACCEPT entry in iptables without someone deleting it manually (so make it appear again)...how would you do that? Trying to figure out howcome the iptables can't get rid of the 16161 ACCPECT line...

Most probably the malware they have installed constantly monitors the firewall rules and restores this rule immediately after your attempt to modify it. The problem will be solved after FW re-flash and formatting jffs partition. But you said that you want to keep the router's config for a while in order to investigate the mechanism of intrusion. So most probably you will be not able to delete this entry in iptables until FW re-flash.

P.S. I've just saw that @john9527 has the same idea.

 

[jack901]

I just run a min config and no wan side allowed.but also on the admin/system page at the bottom it has allow only certain ip to connect and I use that and no other device on the network can get to the router. tho probably not fool proof (as what is) no device on the lan can get to it.

 

[eddiez]

It looks like they may have also started a background process (from your ps output you sent)

28297 admin_ed 1380 S {exe} ash /tmp/nat_restore

try to copy /tmp/nat_restore off to a safe place to preserve it
then, in case it's a script running.....try to do a 'cat /tmp/nat_restore'
then kill that process and see if you can then delete the rule.

copy /tmp/nat_restore "No such file"

But was able to kill the process

 

[john9527]

copy /tmp/nat_restore "No such file"

can you see it in the directory list for /tmp
ls /tmp

 

[eddiez]

can you see it in the directory list for /tmp
ls /tmp

No. Only NAT references shown are:
nat_rules
nat_rules_eth0_eth0

Think they got rid of that...

I did do a nat-save. Can that (clean) saved file be placed here as nat_restore?
(quick study : http://www.iptables.info/en/iptables-save-restore-rules.html )

FYI
Dropbear dir shows:
dropbear_rsa_host_key
dropbear_ecdsa_host_key
dropbear_dss_host_key

 

[AndreiV]

but also on the admin/system page at the bottom it has allow only certain ip to connect and I use that and no other device on the network can get to the router.

It helps, I do the same except I have 2 devices that can access in case one dies and make sure you bind the ip's.

It is very easy to lock yourself out of your router

 

[CaptainSTX]

It helps, I so the same except I have 2 devices that can access in case one dies and make sure you bind the ip's.

It is very easy to lock yourself out of your router

Another option for the totally paranoid or those that want to be even more secure is to assign the IP that can access the router to an IP that is not assigned either statically or in you DHCP pool. Then when you want to access your router you need to use a device where you can manually assign it the IP you have selected for access, then connect to your router, type in the user name and password.

 

[Cycle Mycle]

Sorry for what may be a stupid question but how do I configure the logging levels so that admin logins get logged?

Until now I haven't paid much attention to the system log but I used to see an entry there each time I logged in as admin - only ever from the LAN - but this no longer happens. My RT-N66U is currently running 380.65_alpha1 but it's not something I've changed and I'm pretty sure 380.64 didn't log admin logins either. Does anyone know when or why this was changed?

Again, sorry for posing the question. I could find out by reflashing the old builds in reverse order but it would mean the family were without the internet for hours - they'd probably rip my lungs out. My concern is that others may have been hacked but not realise it because admin logins are not being recorded in the system log.

On the paranoia front, I too do the specific IP address for admin thing but only login from a PC booted from a 'nix Live CD, don't touch the internet at all during the router admin and shutdown afterwards. It feels safer anyway!

 

[Minglarn]

Hi guys!
I've seen that admin login from the WAN also. However, i did not save the logfile. Back then my WAN access was open to the router but I've closed it.
Since I closed the WAN access I haven't seen any more attempts to login from the WAN..
I did a ps w | grep dropbear to check the status of my router (AC87U with Merlins latest FW relaease 380.63_2)...
This is what I get:

15139 admin     1068 S    dropbear -p 192.168.1.2:2222 -a -j -k
15344 admin     1136 S    dropbear -p 192.168.1.2:2222 -a -j -k
15367 admin     1136 S    dropbear -p 192.168.1.2:2222 -a -j -k
18004 admin     1380 S    grep dropbear

A probe to 16161 shows this:

16161 Stealth    Unknown Protocol for this port Unknown application for this port

Should I be alarmd? Or should I test some more ?

 

[netware5]

Hi guys!
I've seen that admin login from the WAN also. However, i did not save the logfile. Back then my WAN access was open to the router but I've closed it.
Since I closed the WAN access I haven't seen any more attempts to login from the WAN..
I did a ps w | grep dropbear to check the status of my router (AC87U with Merlins latest FW relaease 380.63_2)...
This is what I get:

15139 admin     1068 S    dropbear -p 192.168.1.2:2222 -a -j -k
15344 admin     1136 S    dropbear -p 192.168.1.2:2222 -a -j -k
15367 admin     1136 S    dropbear -p 192.168.1.2:2222 -a -j -k
18004 admin     1380 S    grep dropbear

A probe to 16161 shows this:

16161 Stealth    Unknown Protocol for this port Unknown application for this port

Should I be alarmd? Or should I test some more ?

Do a probe from outside (WAN side) of TCP port 2222 to check if it is open.

 

[Minglarn]

Do a probe from outside (WAN side) of TCP port 2222 to check if it is open.

2222    Stealth    rockwell-csp2 Rockwell CSP2

Seems closed?

 

[netware5]

2222    Stealth    rockwell-csp2 Rockwell CSP2

Seems closed?

These are good news But to stay on the safe side it is better to re-flash the FW, do a factory reset, format jffs partition and enter the settings manually. This is essential especially if your original SSH port was not 2222. And do all the above things with WAN disconnected.

 

[Minglarn]

These are good news But to stay on the safe side it is better to re-flash the FW, do a factory reset, format jffs partition and enter the settings manually. This is essential especially if your original SSH port was not 2222. And do all the above things with WAN disconnected.

Thanks for the info. So you would not recommend to save a settings file and then reload it when the router is set to factory default?