Was my router's username and password hacked?

[Minglarn]

Was just thinking.
The WAN exploit did give admin rights to the person who just logged in.
That means that he/she could have run "nvram show" ... and get the admin password for the router?

So I think it's time to change that one too...

 

[eddiez]

Was just thinking.
The WAN exploit did give admin rights to the person who just logged in.
That means that he/she could have run "nvram show" ... and get the admin password for the router?

So I think it's time to change that one too...

Me no crazy, yes?

 

[sfx2000]

I simply stick to a VPN tunnel for anything requiring access to home resources.

While on this, it should be noted that two separate audits will be done on OpenVPN 2.4's code. The final result should be really interesting.

Remoting in via VPN is the best option - and it's fairly easy to set up a jump box to facilitate access inside if one doesn't want to run a PC full time..

OpenVPN usually is pretty mindful about security - the risk for them is probably not directly in their code, but platform and integration since the code itself is independent of OS...

 

[sfx2000]

Just also want to go on record here that while the Asuswrt-RMerlin community noticed this potential risk first, I don't believe this was introduced by any changes that were added/changed - Rmerlin has been ahead of the factory firmware with finding and implementing fixes...

It's more about how advanced users are watching things more closely, and how they're using the device compared to the 'typical' user that just plugs it in, sets up the wifi, and goes about their business...

This is a good thing - if folks weren't watching, this issue could have gone unnoticed for a long time...

 

[sfx2000]

No way to be sure until proven as such, but I suspect the same hole _should_ also exist in the stock firmware, since I've made it a point to never touch the authentication code in httpd, aside from the obvious security fixes (preventing visible buffer overruns, that sort of thing).

I agree... see my comment above.

The community here observed it first - and it shows the power of the 3rd party user group...

The dropbear flag issue mentioned in this thread are irrelevant to this issue. That port forwarding feature requires you to open an authenticated session, and it does not do what most people think it does (it's more of a port redirection than a port forward, really).

Dropbear is a red herring - it's secure in and of itself - what people are seeing is after the fact...

 

[Wutikorn]

Baidu.com is BAD! I blacklist baidu.com, hao123.com and kapook.com at a two sites I do volunteer IT support for. I have seen how the software teachers have downloaded from baidu.com can take over clients, even though it looks legit, such as an baidu branded anti-virus program. On my to do list is to get policy rules set up to lock things down.

Agree, baidu is not a good website, for some reason, my Chinese IP camera was connecting to baidu.com thousands of times a month, I'm considering to throw that thing away. But for now, I have baidu in blacklist. I should also put hao123.com too. I'm curious why you put kapook.com to blacklist? Are there many things for entertainments there? Is it dangerous or just annoying? Btw, I live in the same province as you.

Just also want to go on record here that while the Asuswrt-RMerlin community noticed this potential risk first, I don't believe this was introduced by any changes that were added/changed - Rmerlin has been ahead of the factory firmware with finding and implementing fixes...

It's more about how advanced users are watching things more closely, and how they're using the device compared to the 'typical' user that just plugs it in, sets up the wifi, and goes about their business...

This is a good thing - if folks weren't watching, this issue could have gone unnoticed for a long time...

I also doubt that RMerlin will be the cause of this. I also think that if I am running AsusWRT stock firmware, I wouldn't care whatsoever is in the changelog, or care if SSH setting has been changed, or even care opening WebUI.

 

[thelonelycoder]

Was just thinking.
The WAN exploit did give admin rights to the person who just logged in.
That means that he/she could have run "nvram show" ... and get the admin password for the router?

So I think it's time to change that one too...

Change who sees the nvram entries or change the pw store location?
The root of the problem is the apparent unsafe WebUI exposure to WAN.
This needs to be fixed, not where the pw is stored.
Remember this is the root user account, if that one does not have the privileges to read the pw then.., IDK.

 

[Wutikorn]

Was just thinking.
The WAN exploit did give admin rights to the person who just logged in.
That means that he/she could have run "nvram show" ... and get the admin password for the router?

So I think it's time to change that one too...

The attacker, in my case, had access to my admin username/password as logged when they accessed SSH through WAN. There was no failed attempt at all, and username I use is not default "admin" either.

 

[eddiez]

The attacker, in my case, had access to my admin username/password as logged when they accessed SSH through WAN. There was no failed attempt at all, and username I use is not default "admin" either.

My main concern is that there is an vulnerability in the default Asus login, enabling either bypassing it or disabling it completely. Too much coincidence that 4 users with not simple 123admin usernames and likewise passwords are hacked this way...

 

[wouterv]

My main concern is that there is an vulnerability in the default Asus login, enabling either bypassing it or disabling it completely. Too much coincidence that 4 users with not simple 123admin usernames and likewise passwords are hacked this way...

The vulnerability is implied with opening HTTP WAN access to the router GUI.
One successful remote login of yourself is enough to have your credentials being sniffed and stored for malicious use.

 

[eddiez]

The vulnerability is implied with opening HTTP WAN access to the router GUI.
One successful remote login of yourself is enough to have your credentials being sniffed and stored for malicious use.

To be sniffed would require another breach somewhere on the network or when logging on through an unsecured hotspot. Possible, of course. But without that...

 

[RMerlin]

The hole I fixed last night wasn't present in 380.64 (it was introduced with GPL 4180). I suspect there might be more than one issue at play here, since 4180 also fixed other issues. It's possible that both set of fixes might be needed.

 

[Wutikorn]

The vulnerability is implied with opening HTTP WAN access to the router GUI.
One successful remote login of yourself is enough to have your credentials being sniffed and stored for malicious use.

I think one of the other three said that HTTP was never used. I also have not login to my router from WAN through HTTP, but in any case, I will just use OpenVPN.

My main concern is that there is an vulnerability in the default Asus login, enabling either bypassing it or disabling it completely. Too much coincidence that 4 users with not simple 123admin usernames and likewise passwords are hacked this way...

If they had disable it or bypass it, would they get our credential? In our cases, they got our credentials, not sure if it before being able to access router or after, by getting info from NVRAM, as when they access WAN SSH without making failing to login.

The hole I fixed last night wasn't present in 380.64 (it was introduced with GPL 4180). I suspect there might be more than one issue at play here, since 4180 also fixed other issues. It's possible that both set of fixes might be needed.

Do you want any logs or extra information from eddiez? He may have some useful information as he has not yet done factory reset. In any case, thanks for constantly improving both security and usability of firmware.

 

[sfx2000]

The hole I fixed last night wasn't present in 380.64 (it was introduced with GPL 4180). I suspect there might be more than one issue at play here, since 4180 also fixed other issues. It's possible that both set of fixes might be needed.

Thinking outside the box - but maybe testing from the WAN side if the WebGUI is exposed - NMAP's scripting engine can do a walk thru the HTTP document tree, and this might point out other pages that are worthy of review...

 

[propergol]

excuse my ignorance but after the hackers gain access to the router through WAN he then have access to the entire local network behind?

 

[eddiez]

I think one of the other three said that HTTP was never used. I also have not login to my router from WAN through HTTP, but in any case, I will just use OpenVPN.

If they had disable it or bypass it, would they get our credential? In our cases, they got our credentials, not sure if it before being able to access router or after, by getting info from NVRAM, as when they access WAN SSH without making failing to login.

Do you want any logs or extra information from eddiez? He may have some useful information as he has not yet done factory reset. In any case, thanks for constantly improving both security and usability of firmware.

The web gui log has not registered any failed or illogical login attempts (correct or incorrect ones). So they must have used the WAN exposure to enter, bypassing the login, after which they enabled SSH and by made sure the iptables rule cannot be deleted (easily) (ash).
Or they just removed traces of brute force but left other traces still there...Sloppy so unlikely.

Looking at the timings, it does seem a planned activity. Exactly on the hour at night 03.00.30 / 04.00.30.

 

[eddiez]

excuse my ignorance but after the hackers gain access to the router through WAN he then have access to the entire local network behind?

Yes.

 

[RMerlin]

Do you want any logs or extra information from eddiez?

The only way to track this down is through a network trace. System Logs won't help in any way, sorry.

 

[john9527]

Just wanted to open a discussion on something that's been nagging at me in case I'm missing something. In one of the early reports of this
http://www.snbforums.com/threads/was-my-routers-username-and-password-hacked.36602/#post-299090
the syslog shows a dropbear 'Child connection' immediately followed by the restart of the httpd services. Notice there is no 'Password auth' message from dropbear. Without logging in, how did they initiate the restart?

 

[martinr]

I'm starting to be unable to see the wood for the trees.

Would it help if we try to re-establish the common patterns? I'm happy to collate the data. I get the impression there are only less than 6 or so people who realise they've been hacked, and I'm wondering if a questionnaire to them would help?

For example,

1. Which firmware version?
2. In the last 12 months, have your settings:
a. Allowed web access from WAN?
b. Allowed SSH access from WAN?
c. Allowed SSH password login?
3. Do you ever login to your router using an Android device?
4. Did you see a change of SSH port number and if so what to?
5. What other change to your settings did you see?

Are there any other pertinent questions? And would this be a wasted effort given such a small affected population?

If there's merit in this, I'd be happy to tidy up the questionnaire, whilst keeping it focussed on relevant questions, and then those hacked could PM me or reply direct to the forum, and it'd be a sort of taking-stock exercise.

So, if, and only if, this is worthwhile, are there any pertinent questions I've overlooked?