What's new

Unexplained 'hacks' into Asus routers

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

eddiez

Senior Member
Also see for details and discussion: http://www.snbforums.com/threads/was-my-routers-username-and-password-hacked.36602/page-3

Number of independent users reporting identical hacks: 4
Issue: Unexplained access to Asus routers, AC68/AC87
Traces: SSH ports changed from 22 to 2222,
log entries on dropbear code execution: http://pastebin.com/FvrJZzxw
Probable point of entry: WAN Web access
Access attempts: One-time-right username & password
Traced back IP in logs:
37.8.101.9:50693
37.76.197.8
46.43.113.225
46.32.210.36
177.221.107.45
Affects only modded firmware: No idea...

@ASUS_ASUSWRT
 
Last edited:
What FW and Dropbear version? Also what you mean by this?

"Affects only modded firmware: No idea..."

Are you using any simple password on your router? "admin12345"
 
What FW and Dropbear version? Also what you mean by this?

"Affects only modded firmware: No idea..."

Are you using any simple password on your router? "admin12345"
- FW 380.64, Dropbear 2016.74 included
- Have only seen Merlin users reporting the exact same incursions, no reports from stock users (but maybe they don't look into the logs that often)
- No, no simple password here (incl. capitals, symbols). Mind you that 4 users were visited, password one time right.
 
Last edited:
Do you have Remote Access to WebUI enabled?
 
Do you have Remote Access to WebUI enabled?
Not anymore :rolleyes:

But yes I had. That was probably the way in. Currently "they" set up SSH access through port 16161. iptables rule cannot be removed manually, will reappear again in the iptables list...
 
Not anymore :rolleyes:

But yes I had. That was probably the way in. Currently "they" set up SSH access through port 16161. iptables rule cannot be removed manually, will reappear again in the iptables list...
Did you bring the router back to factory default, delete the JFSS partion, and installed the firmware again (as advised in the other thread by Merlin), followed by manual configuration?

As also suggested in the other thread the most likely root cause is enabling WAN access to the GUI, followed by remote actions on your router.

The dropbear issue as also already explained is most probably not the root cause of your remote attack issue.

Numerous times explained in as many threads:
  1. Do not enableWAN access to the GUI.
  2. Do not enable WAN access to FTP.
  3. Do not enable WAN access to SSH.
  4. The only safe remote access to your LAN is VPN.
  5. After remote attacks:
    • disconnect the router from WAN.
    • revert the router to factory defaults.
    • delete the JFSS partion (included in previous step for stock firmware).
    • re-install the firmware.
    • revert the router to factory defaults again.
    • manual configure the router.
 
Did you bring the router back to factory default, delete the JFSS partion, and installed the firmware again (as advised in the other thread by Merlin), followed by manual configuration?

As also suggested in the other thread the most likely root cause is enabling WAN access to the GUI, followed by remote actions on your router.

The dropbear issue as also already explained is most probably not the root cause of your remote attack issue.

Numerous times explained in as many threads:
  1. Do not enableWAN access to the GUI.
  2. Do not enable WAN access to FTP.
  3. Do not enable WAN access to SSH.
  4. The only safe remote access to your LAN is VPN.
  5. After remote attacks:
    • disconnect the router from WAN.
    • revert the router to factory defaults.
    • delete the JFSS partion (included in previous step for stock firmware).
    • re-install the firmware.
    • revert the router to factory defaults again.
    • manual configure the router.
I know all of this. The SSH backdoor was only enabled after gaining access through the WAN access. Will be keeping the router in this state until further data is no longer required. Did remove the installed hidden doors and will monitor for new ones.

What is worrisome,is that wan access will give access without even brute forcing (weak) passwords. In one case a very complex password was forfeited in one go. That makes you wonder what the hackers are exploiting to get in. That must be worth looking into.

Verstuurd vanaf mijn SM-G935F met Tapatalk
 
I know all of this. The SSH backdoor was only enabled after gaining access through the WAN access. Will be keeping the router in this state until further data is no longer required. Did remove the installed hidden doors and will monitor for new ones.

What is worrisome,is that wan access will give access without even brute forcing (weak) passwords. In one case a very complex password was forfeited in one go. That makes you wonder what the hackers are exploiting to get in. That must be worth looking into.

Verstuurd vanaf mijn SM-G935F met Tapatalk

The WAN access is not the only possible root cause. Yes, it is the most probable one, but till now we should not rule out the other possibility - infected LAN device exploited some vulnerability from within the LAN side.
 
The WAN access is not the only possible root cause. Yes, it is the most probable one, but till now we should not rule out the other possibility - infected LAN device exploited some vulnerability from within the LAN side.
Going through every device but nothing found so far.

Verstuurd vanaf mijn SM-G935F met Tapatalk
 
Anyone use DDNS with same password as router? If using admin as login you only need password.
No... And both router and DDNS also have different username.

What is the reason for that question? Is the password of DDNS send unencrypted/plain by the router?
 
Last edited:
I'm the same but my log says more:

Jan 5 12:12:26 dropbear[31873]: Password auth succeeded for 'honza' from 46.32.205.52:34440
Jan 5 12:12:28 dropbear[31873]: User honza executing '/sbin/ifconfig'
Jan 5 12:12:31 dropbear[31873]: User honza executing 'cat /proc/meminfo'
Jan 5 12:12:32 dropbear[31873]: User honza executing '2>/dev/null sh -c 'cat /lib/libdl.so* || cat /lib/librt.so* || cat /bin/cat || cat /sbin/ifconfig''
Jan 5 12:12:34 dropbear[31873]: User honza executing 'cat /proc/version'
Jan 5 12:12:36 dropbear[31873]: User honza executing 'uptime'
Jan 5 12:12:37 dropbear[31873]: User honza executing '1>/dev/null 2>/dev/null /sbin/iptables -L -n && echo 1 || echo 0'
Jan 5 12:12:39 dropbear[31873]: User honza executing '(python -V 2>/dev/null && echo python && python -V) || (/usr/local/bin/python -V 2>/dev/null && echo /usr/local/bin/python && /usr/local/bin/python -V)'
Jan 5 12:12:40 dropbear[31873]: Exit (honza): Exited normally
Jan 5 12:17:43 dropbear[32694]: Password auth succeeded for 'honza' from 197.50.148.112:56460
Jan 5 12:18:01 dropbear[32694]: Exit (honza): Exited normally

Any news about this?
 
Do you also have Remote Access to WebUI enabled?
 
@hggomes
I think active remote access is the common denominator here... And looking at the absence of brute force signs there might be something to manipulate, without actually entering the web UI; there are no logins recorded in the logs, only the SSH activities. Maybe some zero day ...

Verstuurd vanaf mijn SM-G935F met Tapatalk
 
@hggomes
I think active remote access is the common denominator here... And looking at the absence of brute force signs there might be something to manipulate, without actually entering the web UI; there are no logins recorded in the logs, only the SSH activities. Maybe some zero day ...

Verstuurd vanaf mijn SM-G935F met Tapatalk
I noticed that SSH access is now off. Previously it was set LAN only.

Odesláno z mého SM-G935F pomocí Tapatalk
 
@hggomes
I think active remote access is the common denominator here... And looking at the absence of brute force signs there might be something to manipulate, without actually entering the web UI; there are no logins recorded in the logs, only the SSH activities. Maybe some zero day ...

Verstuurd vanaf mijn SM-G935F met Tapatalk

Yes, you are right is definitely via WebUI Remote Access.

Well not in here, it's a simple addon which is great to have in this situation:

Aug 1 00:01:24 HTTP(S) login: Login attempt failed from 192.168.1.129
Aug 1 00:05:46 HTTP(S) login: Login successful from 192.168.1.129
Aug 1 00:13:25 HTTP(S) login: Logout successful
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top