Was my router's username and password hacked?

[netware5]

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?

Yes. Just for precaution. We don't know what a mess 'they' did with NVRAM settings.

 

[sfx2000]

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

If someone wants a directed scan at your box, feel free to PM me - results will be kept in confidence...

 

[highwire]

Did you have Web Access from WAN enabled? What about Asus Router app? What is/was your SSH port with WAN+LAN? What was the firmware version when you first saw SSH setting changes?

This happened just after I did a firmware reload and NVRAM reset. RT-AC87U. Merlin 380.64. No web access from WAN ever. Never used the smartphone app. I don't know what port was active - probably 22.

I'm also seeing -a -j and -k on dropbear.

admin@RT-AC87U:/tmp/home/root# ps | grep dropbear

6323 admin 1068 S dropbear -p 10.0.0.1:22 -a -j -k

9157 admin 1096 S dropbear -p 10.0.0.1:22 -a -j -k

9163 admin 1380 S grep dropbear

 

[icornish]

This happened just after I did a firmware reload and NVRAM reset. RT-AC87U. Merlin 380.64. No web access from WAN ever. Never used the smartphone app. I don't know what port was active - probably 22.

I'm also seeing -a -j and -k on dropbear.

admin@RT-AC87U:/tmp/home/root# ps | grep dropbear

6323 admin 1068 S dropbear -p 10.0.0.1:22 -a -j -k

9157 admin 1096 S dropbear -p 10.0.0.1:22 -a -j -k

9163 admin 1380 S grep dropbear

default SSH port is 22, and this is very similar to mine, bar the IP. My IP subnet is 192.168.1.x

 

[sfx2000]

Yes. Just for precaution. We don't know what a mess 'they' did with NVRAM settings.

Would be really fun if they dug down into the CFE and put a root kit in

Then perhaps there would be no getting rid of it - this is one of the concerns about rootkits and UEFI on x86...

 

[sfx2000]

And someone mentioned there is no python inside AsusWRT - but one sees python in the logs - this is just stuff echo'ed back as part of a helper script...

This is a sign of a ROP attack - ROP stands for Return Oriented Programming - where the attacker can grab little bits here and there inside existing code, and build a new binary to do things...

And with Thumb, sometimes it's not obvious when looking at things - but basically these attacks use various code on the stack, and pop things around the PC, LR, and R0/R1 registers inside the ARM - that we some some fatal exceptions in some of the logs where the ARM reboots is a very good indication - and that librt, along with a couple of other libs, someone has taken a very close look at the build and has crafted the attack very nicely...

smells like russia actually...

 

[eddiez]

And someone mentioned there is no python inside AsusWRT - but one sees python in the logs - this is just stuff echo'ed back as part of a helper script...

This is a sign of a ROP attack - ROP stands for Return Oriented Programming - where the attacker can grab little bits here and there inside existing code, and build a new binary to do things...

And with Thumb, sometimes it's not obvious when looking at things - but basically these attacks use various code on the stack, and pop things around the PC, LR, and R0/R1 registers inside the ARM - that we some some fatal exceptions in some of the logs where the ARM reboots is a very good indication - and that librt, along with a couple of other libs, someone has taken a very close look at the build and has crafted the attack very nicely...

smells like russia actually...

My device showed a couple a hard reboots/crashes...

http://pastebin.com/5M0igFJ1

Maybe someone can figure out what they have achieved/were trying to accomplish (CFE?)
Router is still in 'hacked' shape (dropbear and all WAN connections killed though), so available for research

 

[sfx2000]

I didn't mean to scare folks with the comment about CFE - just keep in mind that the httpd process, pretty much like everything else, runs as a privileged user - that is how one can flash firmware inside the WebGUI - hence getting into the CFE...

I'm not going to go into too much detail here - but exposing the HTTP port to the WAN is a very, very, very bad idea... as it is what it is - and it loads a lot of code into memory that would be very useful...

Unfortunately - it's not just AsusWRT, as this is legacy hangover from the WRT54G DNA that many consumer Router/AP's are built on, and there, they had remote admin...

Best thing that Asus could do is disable that function all together - but I'm not sure how this would impact all their vertical services (DDNS, Cloud, Protect, device Apps, etc...)

 

[RMerlin]

Best thing that Asus could do is disable that function all together - but I'm not sure how this would impact all their vertical services (DDNS, Cloud, Protect, device Apps, etc...)

There are some safe, legitimate use for exposing the web interface to the WAN. That's how I do all of my development: test routers are within my LAN, and my laptop sits on the LAN, in front of the tested router's WAN.

if I remember correctly, thumb support is disabled in Asuswrt's kernel.

Also, newer routers have an encrypted CFE, which makes things harder for exploits to hide anything in there. It's not 100% locked down however, but that's not something I'd feel like discussing in public, just like I wouldn't discuss the (now known) cfecommit tricks supported by previous router generations...


So far, everyone affected had their web interface open to the WAN, which leads me to believe this is the work of bots, not of malicious websites hitting you from the LAN side.

If anyone actually felt like tracking down what is REALLY going on, they'd have to setup a honeypot, with full traffic capture of what goes in and out of the honeypot. Without that, it will be a wild guessing game figuring out the exact vector of attack. Most likely it's a way to bypass user authentication and apply changes to an existing webpage (the Advanced_System_Content.asp page seems to be getting hit based on the list of services being restarted). Another possible way is a method allowing to retrieve the username and password, and then using it to fully access the webui, and opening SSH access.

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

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

 

[sfx2000]

There are some safe, legitimate use for exposing the web interface to the WAN. That's how I do all of my development: test routers are within my LAN, and my laptop sits on the LAN, in front of the tested router's WAN.

I fail to see any useful purpose to exposing a Web Interface to the outside world - nice for dev purposes, but not for production...

if I remember correctly, thumb support is disabled in Asuswrt's kernel.

One can jump into Thumb at any time - this is one of the concerns with ARMv7... keep in mind if one has gotten supervisor usage of the ARM...

Also, newer routers have an encrypted CFE, which makes things harder for exploits to hide anything in there. It's not 100% locked down however, but that's not something I'd feel like discussing in public, just like I wouldn't discuss the (now known) cfecommit tricks supported by previous router generations...

And the kernel has to unlock the CFE to boot... and to flash firmware - which means that http and the kernel have exceptional privs...

And we don't have a signed bootloader to ensure that the kernel itself is safe - so the doors are unlocked...

So far, everyone affected had their web interface open to the WAN, which leads me to believe this is the work of bots, not of malicious websites hitting you from the LAN side.

Bots have to be written by humans...

If anyone actually felt like tracking down what is REALLY going on, they'd have to setup a honeypot, with full traffic capture of what goes in and out of the honeypot. Without that, it will be a wild guessing game figuring out the exact vector of attack. Most likely it's a way to bypass user authentication and apply changes to an existing webpage (the Advanced_System_Content.asp page seems to be getting hit based on the list of services being restarted). Another possible way is a method allowing to retrieve the username and password, and then using it to fully access the webui, and opening SSH access.

Exactly...

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 suspect it is - the third party community is probably more aware of things - joe six-pack likely isn't...

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

I don't think Dropbear by itself is a problem - but getting root on the device can allow someone to configure Dropbear as needed...

 

[sfx2000]

if I remember correctly, thumb support is disabled in Asuswrt's kernel.

Features : swp half thumb fastmult edsp​

It's there...

 

[RMerlin]

Features : swp half thumb fastmult edsp​

It's there...

But the kernel's ability to load thumb binaries is disabled however.

 

[sfx2000]

But the kernel's ability to load thumb binaries is disabled however.

There's things below the kernel...

 

[Makaveli]

I wonder how many of these people seeing attacks have been using the Android App to manage their routers.

I use the only use it when i'm at home and on the LAN. I don't allow the app to work remotely for reasons like this. Also no SSH to Wan that was a red flag even though I have friends telling me its safe just use random ports.

I will VPN in if I need access.

 

[RMerlin]

Found (and fixed) one buffer overrun that could be at least used by a remote user to crash httpd. No idea if it could be used to remotely execute code (that kind of testing is outside of my field of expertise), so I cannot say if it was used in recent exploits or not. But that's one potential hole closed at the very least...

 

[Taxed]

Hey everyone, just your average lurker here that usually runs the official firmware but every now & then I load up some Merlin. I just wanted to post that I have been on official Asus firmware since Nov. 2016 & I am currently running the latest which was just released in late Dec. & I have never seen any of those strange entries in my logs. I have been checking daily for a week now since these threads started at my settings & all have been good. No wan access changes no ftp nor ssh. I do not run Windows at home, only Xubuntu and your standard Androids & iPhones. I do not use the Asus Router app. I started to search the net about this issue and found a couple interesting sites especially one back from 2014 which has some tricks about finding every router that runs AiCloud? Have any of these vulnerabilities been fixed? What I find strange is some user commented in 2016, all the way on the bottom, about getting SSH running undetected???

https://w00tsec.blogspot.com/2014/07/hacking-asus-rt-ac66u-and-preparing-for.html?m=1

Also, has anyone noticed any DNS changes? Are the affected routers home to users with Android devices & children with unlimited access to the Playstore?

 

[RMerlin]

The AiCloud and FTP issues reported in 2014 have been fixed.

I do not know how secure AiCloud is these days. 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.

 

[Wutikorn]

Also, has anyone noticed any DNS changes? Are the affected routers home to users with Android devices & children with unlimited access to the Playstore?

There have been reports about malware on android that changes DNS setting, but I have not faced one. I heard that the main target of one of DNS changing attack is in China, but there could be several more attacks. When I was reading about one DNS changing attack that its main target is China, it seems like infected devices downloaded apps outside Playstore which claims to be Baidu. However, I would install a free well-known antivirus(Ex. Sophos, McAfee, Malwarebytes, Avira, ...) on Android devices for children as they may not know how to browse safely.

 

[eddiez]

Good to see that the hacks have sparked a very relevant and value adding discussion that you wouldn't see in a Joe Average user thread. Quite educational as well for the less tech savvy here.

Would be interested how Asus would respond to this though. No sound yet from them although I did tag them in the list on the official Asus thread. I expect some queueing before a real tech head would respond but this does require their attention. Don't know if US consumer regulation could make this a liability issue, that could certainly speed things up a bit perhaps. What your elaborations tell me is that if WAN access is this fragile, literally millions of Asus routers could be at risk of becoming part of botnets.

Verstuurd vanaf mijn SM-G935F met Tapatalk

 

[Xentrk]

There have been reports about malware on android that changes DNS setting, but I have not faced one. I heard that the main target of one of DNS changing attack is in China, but there could be several more attacks. When I was reading about one DNS changing attack that its main target is China, it seems like infected devices downloaded apps outside Playstore which claims to be Baidu. However, I would install a free well-known antivirus(Ex. Sophos, McAfee, Malwarebytes, Avira, ...) on Android devices for children as they may not know how to browse safely.

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.