Possibly been hacked. Need assistant from senior users.

[xtropodx]

Are you talking about the "Save settings" file? If so then that file will always look garbled because it's encrypted.

Yeah I get that, but different like this? Left looks normal, right doesn't. Saved within 10minutes of each other. And considering the change of language issue happening with the firmware surely this shouldn't be ruled out as possible area to investigate.

 

[kfp]

Yeah I get that

No you don’t. Stop opening binary files with a text editor. Regarding different line endings in syslogs, just use something other than the built in notepad and they will look fine.

https://notepad-plus-plus.org

 

[ColinTaylor]

No, that's normal. It's just Notepad freaking out on the binary data. Try looking at it with a better editor and you will see the difference.

Even if it did contain Korean characters (which it doesn't) you wouldn't see them like that because it is encrypted.

 

[AntonK]

Yeah, I highly doubt it would revert the change, as it has no real way of knowing if WAN access was deliberately enabled by the end-user, or automatically by the application.

It's a shame, because overall I thought Asus' mobile app looked pretty good when I tried it out around when it originally launched. If they can sort out these types of issues, people should be good.

I use the ASUS app on my iPhone, but I don't enable the app's remote access feature. I only use it across my internal wireless network. WAN access has been, and remains disabled on my router.

 

[test011]

Is these what we know for now?
- WAN access to web is irrelevant in these incidents (I am not saying it's safe)
- no intrusion report with 384.5 yet
- Many affected users have used Asus App in some way.

Unconfirmed but recommended move: update to 384.5 for ARM, pray for MIPS? (with other usual security measures)

 

[Insight]

Is these what we know for now?
- WAN access to web is irrelevant in these incidents (I am not saying it's safe)
- no intrusion report with 384.5 yet
- Many affected users have used Asus App in some way.

Unconfirmed but recommended move: update to 384.5 for ARM, pray for MIPS? (with other usual security measures)

I think the first comment regarding WAN access is highly to be incorrect. If WAN access is indeed disabled, meaning the app did not open up access without people knowing- whats the attack vector? A local client was popped and then they wanted router VPN tunneling too? I think we'd see this more than just on asus router ATM. Doesn't seem likely.

I'd say nearly all these cases are a direct reflection of WAN being turned on, although I haven't read every comment in the thread. Either be means of a vulnerability in the https web page or just plain weak passwords, it's not too difficult to jump in on these.

 

[umarmung]

I think the first comment regarding WAN access is highly to be incorrect. If WAN access is indeed disabled, meaning the app did not open up access without people knowing- whats the attack vector? A local client was popped and then they wanted router VPN tunneling too? I think we'd see this more than just on asus router ATM. Doesn't seem likely.

I'd say nearly all these cases are a direct reflection of WAN being turned on, although I haven't read every comment in the thread. Either be means of a vulnerability in the https web page or just plain weak passwords, it's not too difficult to jump in on these.

Given what RMerlin says (that your only option is to upgrade firmware), that all but guarantees it has nothing to do with the WAN, which means it is most likely a LAN attack, though it could also be a client router issue. These may not need a password to exploit. The most dangerous type of LAN attacks are those directly from the web browser (or mail). No point speculating more tbh.

 

[Insight]

Given what RMerlin says (that your only option is to upgrade firmware), that all but guarantees it has nothing to do with the WAN, which means it is most likely a LAN attack, though it could also be a client router issue. These may not need a password to exploit. The most dangerous type of LAN attacks are those directly from the web browser (or mail). No point speculating more tbh.

If no WAN access to enabled, it doesn't matter which vulnerabilities you have....outside communication can contact the router. The router is not accessible to anyone except lan side clients. DDNS/WAN access open this up for the public internet, not just for your app.

So someone on your LAN side wants to put the router in Chinese and setup a tunnel back to China just for fun? Sounds legit.

 

[RMerlin]

So you confirming then that this same issue/bug/flaw that everyone has posted about for last several pages here still exists in the firmware ?

No, I never said that. I have no idea what is the specific issue leading to the exploit documented in this thread.

 

[DonnyJohnny]

Given what RMerlin says (that your only option is to upgrade firmware), that all but guarantees it has nothing to do with the WAN, which means it is most likely a LAN attack, though it could also be a client router issue. These may not need a password to exploit. The most dangerous type of LAN attacks are those directly from the web browser (or mail). No point speculating more tbh.

If no WAN access to enabled, it doesn't matter which vulnerabilities you have....outside communication can contact the router. The router is not accessible to anyone except lan side clients. DDNS/WAN access open this up for the public internet, not just for your app.

So someone on your LAN side wants to put the router in Chinese and setup a tunnel back to China just for fun? Sounds legit.

Totally agreed. Be it exploitation of vulnerabilities of http server or weak password. We should minimise access to outside world.

While it is important to keep our firmware up to date especially when there is security patches, why must we give chance to others? We never know when zero day vulnerabilities being discovered and abused.

So? Recommend to use safer and tougher access like Openvpn than SSH over Wan or worst HTTPS over Wan.
At least openvpn is actively patching up holes as and when and Merlin will be able to compile them timely.

 

[xtropodx]

I'd say nearly all these cases are a direct reflection of WAN being turned on, although I haven't read every comment in the thread. Either be means of a vulnerability in the https web page or just plain weak passwords, it's not too difficult to jump in on these.

Can't speak for others but my last issue with 384.4_2 this was definitely not the case. On a version prior to 384.4_2 I was running the ASUS app, had WAN turned on etc, but after that got compromised all my router settings were tightened up harder than a nun & all passwords were changed & made to be extremely difficult.

Edit: in process of trying to post this, I got knocked offline & couldn't access my router for some reason. Had to reboot my PC.

 

[Insight]

Can't speak for others but my last issue with 384.4_2 this was definitely not the case. On a version prior to 384.4_2 I was running the ASUS app, had WAN turned on etc, but after that got compromised all my router settings were tightened up harder than a nun & all passwords were changed & made to be extremely difficult.

Edit: in process of trying to post this, I got knocked offline & couldn't access my router for some reason. Had to reboot my PC.

Are you sure you're still not compromised?

 

[xtropodx]

Are you sure you're still not compromised?

I dunno, wanna try knock on my front door .

 

[Insight]

I dunno, wanna try knock on my front door .

Why knock when the doors wide open

 

[xtropodx]

No, I never said that. I have no idea what is the specific issue leading to the exploit documented in this thread.

So what are (& are not?) some possible attack vectors with this?
-DDNS
-LAN
-WAN
-VPN server/client
-passwords
-encryption issue/setting
-any/all of the above
-etc

Asking as last time this happened thought I had things tightened up pretty well. And at this stage I've put off reestablishing DDNS/VPN Server for the time being.

 

[RMerlin]

So what are (& are not?) some possible attack vectors with this?
-DDNS
-LAN
-WAN
-VPN server/client
-passwords
-encryption issue/setting
-any/all of the above
-etc

Asking as last time this happened thought I had things tightened up pretty well. And at this stage I've put off reestablishing DDNS/VPN Server for the time being.

Most likely candidate is for anyone that exposes their webui to the WAN, because over the years there has been a number of known security issues allowing to bypass authentication.

There has been a number of XSS vulnerabilities too over the years, which could be triggered by accessing a remote malicious website.

DDNS is unlikely to be a vector of attack, since it's only a client that runs on demand, and will only connect to a specific remote server.

Poorly configured VPN tunnels are also potential security risks. Remember that the goal of a VPN is to (among other things) bridge two networks together. Therefore if you don't fully trust the remote end, people at that remote end can potentially gain access to your whole LAN.

 

[xtropodx]

Most likely candidate is for anyone that exposes their webui to the WAN, because over the years there has been a number of known security issues allowing to bypass authentication.

Is that VPN server &/or client?
So is it possible that a MODEM that is bridged to the router be used to exploit this, and/or weak/poor password on said modem?
Is there somewhere that explains all the VPN settings in one place, their risk & recommended setting?

 

[RMerlin]

Is that VPN server &/or client?

Both, since a VPN is a two-way tunnel. Server configuration matters because it determines what you give access to to remotely connected clients. And client matters because it depends on what configuration exists at the server's end, what is exposed through the tunnel, etc...

Is there somewhere that explains all the VPN settings in one place, their risk & recommended setting?

Not really, beyond the OpenVPN manual. OpenVPN configuration can be as simple or as complicated you want to make it, it's not something that can be explained with a few paragraphs of description unfortunately.

One reason why a VPN tunnel should typically only be connected when you trust BOTH ends of the tunnel. Yes, that means that those VPN tunnel providers might be security liabilities, depending on how the tunnel is configured at both ends...

So is it possible that a MODEM that is bridged to the router be used to exploit this, and/or weak/poor password on said modem?

Unlikely, since the modem sits on the WAN side of your router, therefore it's facing your router's firewall, not within it.

 

[Insight]

Most likely candidate is for anyone that exposes their webui to the WAN, because over the years there has been a number of known security issues allowing to bypass authentication.

There has been a number of XSS vulnerabilities too over the years, which could be triggered by accessing a remote malicious website.

DDNS is unlikely to be a vector of attack, since it's only a client that runs on demand, and will only connect to a specific remote server.

Poorly configured VPN tunnels are also potential security risks. Remember that the goal of a VPN is to (among other things) bridge two networks together. Therefore if you don't fully trust the remote end, people at that remote end can potentially gain access to your whole LAN.

Agree with this. The only thing to add is that DDNS is not an attack vector but an intel piece. How secure is that web front in that does the name resolution? How well is it protected and how hard is it from someone to get it to spill its guts and get everyone's WAN IP?

If an attacker knew the asus app originally turned both WAN and DDNS on my default, they'd want to dump the web front in and then have all the targets listed for smooth operations for a single exploit attack on older firmware.

 

[kfp]

Agree with this. The only thing to add is that DDNS is not an attack vector but an intel piece. How secure is that web front in that does the name resolution? How well is it protected and how hard is it from someone to get it to spill its guts and get everyone's WAN IP?

If an attacker knew the asus app originally turned both WAN and DDNS on my default, they'd want to dump the web front in and then have all the targets listed for smooth operations for a single exploit attack on older firmware.

That is a highly unlikely scenario. Users can pick any DDNS providers, and each provider would have Asus router users + other users. That’s assuming the attacks are targeted of course.

And I’m not sure the ‘guts’ would reveal any useful information for attacking your router, you can scan the entire IPv4 space pretty easily these days. They *could* change your DDNS settings so all clients trying to reach the router reach the attacker instead but that’s attacking the clients not the router :/

I’d guess most if not all remotes attacks on Asus routers are via the web UI being exposed to the WAN.