Was my router's username and password hacked?

[ColinTaylor]

@bmi I certainly looks like brute force. But that isn't the same attack we're discussing here.

 

[swetoast]

@bmi check your settings
@eddiez you must have had something exposed

 

[Wutikorn]

I think it's a brute force attack...

What firmware are you running? It seems like the router still allow the brute force attack to continue even it knows that that is abnormal behaviours. It would be better if the router block the login attempt after several failed attempts for several minutes(5-60minutes). It does seem like brute force of a known username/password list. But as ColinTaylor says, this is not in my case as in my case, the attacker somehow manage to get my credential without brute force attack, so it's likely to be vulnerability. Anyway, don't forget to close Web Access from WAN to prevent further problems.

 

[eddiez]

I think it's a brute force attack...

They could have purged the logs as well when inside. But why wouldn't they have purged them fully. I think this is not directly related to the reported entries...

 

[eddiez]

@bmi check your settings
@eddiez you must have had something exposed

Yes, WAN webaccess.
They paid a visit again last night, three times from different IP's. All outside access was now off...
No SSH/Telnet/Web access/AiCloud off/uPnP off...

Jan 4 04:10:33 dropbear[18525]: Password auth succeeded for 'adminxxxxxx' from 46.43.113.225:42479
Jan 4 04:17:21 dropbear[18862]: Password auth succeeded for 'adminxxxxxx' from 46.32.210.36:45857
Jan 4 04:26:51 dropbear[19316]: Password auth succeeded for 'adminxxxxxxx' from 177.221.107.45:3569
Jan 4 04:28:48 dropbear[19316]: Exit (adminxxxxxx): Exited normally

 

[Wutikorn]

Yes, WAN webaccess.
They paid a visit again last night, three times from different IP's. All outside access was now off...
No SSH/Telnet/Web access/AiCloud off/uPnP off...

Jan 4 04:10:33 dropbear[18525]: Password auth succeeded for 'adminxxxxxx' from 46.43.113.225:42479
Jan 4 04:17:21 dropbear[18862]: Password auth succeeded for 'adminxxxxxx' from 46.32.210.36:45857
Jan 4 04:26:51 dropbear[19316]: Password auth succeeded for 'adminxxxxxxx' from 177.221.107.45:3569
Jan 4 04:28:48 dropbear[19316]: Exit (admin_eddiez): Exited normally

Is there any log about what they are trying to do with infected routers?

 

[john9527]

Yes, WAN webaccess.
They paid a visit again last night, three times from different IP's. All outside access was now off...
No SSH/Telnet/Web access/AiCloud off/uPnP off...

Jan 4 04:10:33 dropbear[18525]: Password auth succeeded for 'adminxxxxxx' from 46.43.113.225:42479
Jan 4 04:17:21 dropbear[18862]: Password auth succeeded for 'adminxxxxxx' from 46.32.210.36:45857
Jan 4 04:26:51 dropbear[19316]: Password auth succeeded for 'adminxxxxxxx' from 177.221.107.45:3569
Jan 4 04:28:48 dropbear[19316]: Exit (adminxxxxxx): Exited normally

Do you have any dropbear 'Child connection from' messages WITHOUT a following 'Password auth' message immediately proceeding this?

 

[eddiez]

Do you have any dropbear 'Child connection from' messages WITHOUT a following 'Password auth' message immediately proceeding this?

The board doesn't allow code to be posted
Full log: http://pastebin.com/FvrJZzxw

@Wutikorn

 

[john9527]

The board doesn't allow code to be posted

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

 

[netware5]

How would I know if something is open?

Use Web GUI to check the status of http, https, telnet, ftp and ssh then disable them on WAN side. Next step is to use nmap scan from outside to check if any other port is open by some other application (this will show also if some port is open by any malicious code that is possible to be installed from inside LAN).

 

[hellboy2]

And if only asking the question whether or not the mods in the firmware can enable this is already considered an unacceptable insult...wow. Please back off with this attitude of admiration.

If you want official support, why don't you use official code, then?
I suppose you have read Merlin's disclaimers?

Professionals? GMAFB... We are not professionals, but amateurs in sense "we love what we do" (ref: latin: Amo = I love), and we know and understand the limitations of the code and the support structure. I use it, because its track quality record is way above what many professionals deliver.

That said, I agree that this is a serious problem, and Asus should be notified.

 

[netware5]

Yes, WAN webaccess.
They paid a visit again last night, three times from different IP's. All outside access was now off...
No SSH/Telnet/Web access/AiCloud off/uPnP off...

Jan 4 04:10:33 dropbear[18525]: Password auth succeeded for 'adminxxxxxx' from 46.43.113.225:42479
Jan 4 04:17:21 dropbear[18862]: Password auth succeeded for 'adminxxxxxx' from 46.32.210.36:45857
Jan 4 04:26:51 dropbear[19316]: Password auth succeeded for 'adminxxxxxxx' from 177.221.107.45:3569
Jan 4 04:28:48 dropbear[19316]: Exit (adminxxxxxx): Exited normally

What the bolded text above means? Did you stopped the outside access BEFORE or AFTER Jan 4 04:10:33?

 

[ColinTaylor]

@eddiez Can you log on to your router (from LAN with SSH) and issue the following command:

ps w | grep dropbear

We have seen from previous logs that once the attacker gets in he starts up a second instance of dropbear that would not be apparent from the web interface.

This is what you would normally see:

admin@RT-AC68U:/# ps w | grep dropbear
  594 admin     1084 S    dropbear -p 22 -j -k
 3404 admin     1152 S    dropbear -p 22 -j -k
 3643 admin     1396 S    grep dropbear
admin@RT-AC68U:/#

 

[eddiez]

What the bolded text above means? Did you stopped the outside access BEFORE or AFTER Jan 4 04:10:33?

Before Jan 4 everything was switched off (everything to the WAN was already off, only web access had been enabled before Jan 4)

 

[eddiez]

@eddiez Can you log on to your router (from LAN with SSH) and issue the following command:

ps w | grep dropbear

We have seen from previous logs that once the attacker gets in he starts up a second instance of dropbear that would not be apparent from the web interface.

This is what you would normally see:

admin@RT-AC68U:/# ps w | grep dropbear
  594 admin     1084 S    dropbear -p 22 -j -k
 3404 admin     1152 S    dropbear -p 22 -j -k
 3643 admin     1396 S    grep dropbear
admin@RT-AC68U:/#

/jffs/configs$ ps w | grep dropbear
10849 adminXXX 1136 S dropbear -p 192.168.1.1:22 -a -j -k
10894 adminXXX 1380 D grep dropbear
27387 adminXXX 1068 S dropbear -p 192.168.1.1:22 -a -j -k
27410 adminXXX 1136 S dropbear -p 192.168.1.1:22 -a -j -k
28252 adminXXX 460 S /tmp/dropbear/dropbearmulti dropbear -p 16161 -r /tmp/dropbear/dropbear_rsa_host_key -d /tmp/dropbear/dro

When enabling SSH, I switched back the altered port from 2222 to 22

 

[ColinTaylor]

When enabling SSH, I switched back the altered port from 2222 to 22

Ah, OK. Thanks for the info.

 

[eddiez]

If you want official support, why don't you use official code, then?
I suppose you have read Merlin's disclaimers?

Professionals? GMAFB... We are not professionals, but amateurs in sense "we love what we do" (ref: latin: Amo = I love), and we know and understand the limitations of the code and the support structure. I use it, because its track quality record is way above what many professionals deliver.

That said, I agree that this is a serious problem, and Asus should be notified.

Of course I've read the disclaimers. So? Does that mean he could care less about it? I know he doesn't. And about the amateur thing, I guess most of the guys hanging around are in IT. Asus has been notified in their 'Official forum'. Although I think with the support the devs are getting they might be the more appropriate persons to address this since it might well be a generic issue...Nothing is excluded so far.

 

[netware5]

Before Jan 4 everything was switched off (everything to the WAN was already off, only web access had been enabled before Jan 4)

So in that case there are three possibilities how the attack has been managed:

1. They used a vulnerability in web access
2. Some of your LAN devices is infected and they took control from the inside of your LAN
3. They had installed some malicious code in your router during previous attacks (before 4 January) and this code is still active and opens the door for them.

The first step I would do is reset to factory defaults, re-flash FW and again reset to factory defaults. Format the JFFS partition. All these operation should be performed with WAN disconnected.

If the problem persists it will confirm that either you have infected LAN device, which immediately run the exploit again or that they managed to infect the bootloader.

P.S. Why you still kept the web access open before last attack this morning??

 

[eddiez]

So in that case there are three possibilities how the attack has been managed:

1. They used a vulnerability in web access
2. Some of your LAN devices is infected and they took control from the inside of your LAN
3. They had installed some malicious code in your router during previous attacks (before 4 January) and this code is still active and opens the door for them.

The first step I would do is reset to factory defaults, re-flash FW and again reset to factory defaults. Format the JFFS partition. All these operation should be performed with WAN disconnected.

If the problem persists it will confirm that either you have infected LAN device, which immediately run the exploit again or that they managed to infect the bootloader.

I know how to resolve it, thanks though. I want to keep the router as-is for now...It might help in assessing the exploit/vulnerability/infection. Will refrain from online banking now, though...

Have done a thorough check of devices in the LAN, nothing came up so far...

 

[netware5]

/jffs/configs$ ps w | grep dropbear
10849 admin_ed 1136 S dropbear -p 192.168.1.1:22 -a -j -k
10894 admin_ed 1380 D grep dropbear
27387 admin_ed 1068 S dropbear -p 192.168.1.1:22 -a -j -k
27410 admin_ed 1136 S dropbear -p 192.168.1.1:22 -a -j -k
28252 admin_ed 460 S /tmp/dropbear/dropbearmulti dropbear -p 16161 -r /tmp/dropbear/dropbear_rsa_host_key -d /tmp/dropbear/dro

When enabling SSH, I switched back the altered port from 2222 to 22