Was my router's username and password hacked?

[eddiez]

Yep, noticed that one also. Not a Linux guy though...can't find the location through SSH

 

[ColinTaylor]

Yep, noticed that one also. Not a Linux guy though...can't find the location through SSH

Issue the ps command again. Is it still there and using the same port? If so, try going to https://www.grc.com/shieldsup and testing port 16161.

 

[eddiez]

Issue the ps command again. Is it still there and using the same port? If so, try going to https://www.grc.com/shieldsup and testing port 16161.

Yep... and it's open :-(

Port

Status Protocol and Application

16161

OPEN! Unknown Protocol for this port
Unknown Application for this port

 

[john9527]

I need to see entries prior to what you had posted...maybe starting two hour earlier

@eddiez
I'd still like to see this data if you have it available. If you don't want to post in the thread, you can PM me the pastebin link.

 

[eddiez]

@eddiez
I'd still like to see this data if you have it available. If you don't want to post in the thread, you can PM me the pastebin link.

I'll create the collection now...

 

[john9527]

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'

-j        Disable local port forwarding
-k        Disable remote port forwarding
-a        Allow connections to forwarded ports from any host

 

[eddiez]

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'

-j        Disable local port forwarding
-k        Disable remote port forwarding
-a        Allow connections to forwarded ports from any host

Bug or was it consciously altered?

 

[netware5]

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'

Strange .... I've just checked my router (logged in remotely through OpenVPN). I also have both '-a' and '-j -k'. My Router was freshly updated to 380.64 just few days ago. I never detected any signs of infection yet. Here is the screenshot:

 

[john9527]

Bug or was it consciously altered?

Bug in the code (ssh.c)

 

[eddiez]

Bug in the code (ssh.c)

So all are open, essentially?

 

[john9527]

So all are open, essentially?

Can't tell. Don't know who wins in the case of apparently conflicting options....allow forwards or disable forwards. I'd have to dig through dropbear.

 

[eddiez]

Can't tell. Don't know who wins in the case of apparently conflicting options....allow forwards or disable forwards. I'd have to dig through dropbear.

Sent a mail to the dropbear guys
https://matt.ucc.asn.au/dropbear/dropbear.html

 

[john9527]

Sent a mail to the dropbear guys
https://matt.ucc.asn.au/dropbear/dropbear.html

Just to clairify.....I think setting the conflicting options is a bug in the ASUS firmware.....not in dropbear.

 

[eddiez]

Just to clairify.....I think setting the conflicting options is a bug in the ASUS firmware.....not in dropbear.

I'v asked about the attribute interpretation sequence. Easier than going through the documentation...

I've been removing the 16161 port from IPtables (iptables -D INPUT -p tcp --dport 16161 -j ACCEPT), but guess what...every time after waiting a bit the IPtables entry to accept 16161 connections (ACCEPT tcp -- anywhere anywhere tcp dpt:16161) reappears again. Even when not saving the IPtables (service iptables_save)

There might be more alterations present.

 

[ColinTaylor]

Just to clairify.....I think setting the conflicting options is a bug in the ASUS firmware.....not in dropbear.

Looks like the change came in with the 4th April 2016 merge with Asus GPL 380_2697?

 

[netware5]

Just to clairify.....I think setting the conflicting options is a bug in the ASUS firmware.....not in dropbear.

I fully agree with you. Could you check in the code base since which version it appeared? Then most probably it spread in Merlin's FW and your fork.

 

[ColinTaylor]

There might be more alterations present.

Perhaps you could dump the output of "ps w" and "nvram show" and send them to John privately (because they contain password information)

EDIT Sorry @john9527 That's very presumptuous of me.

 

[eddiez]

Perhaps you could dump the output of "ps w" and "nvram show" and send them to John privately (because they contain password information)

Done

 

[ColinTaylor]

Looks like the change came in with the 4th April 2016 merge with Asus GPL 380_2697?

@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.

 

[john9527]

I fully agree with you. Could you check in the code base since which version it appeared? Then most probably it spread in Merlin's FW and your fork.

Looks like the change came in with the 4th April 2016 merge with Asus GPL 380_2697?

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