HELP- Netonix Virus?

[Stephen]

There is still a program running in the back ground that will max out CPE usage . Cleared up switch are good for 8 to 12 hours and we have found this in the log ??

any Ideas ?

...

Hi sdwisp, please try using Access Controls to block access to to the webui from any device except the machine you use to manage the switch. This is mostly just a test, but the suspicion is that there is something still running, just not on the switch itself. First let's see if that helps.

[allstarcomps]

Hi

Using the Mikrotik edge router(I'm more familiar with) I torched some of SDWISPs infected routers. I noticed ever so often a connection to 209.141.35.56 on port 36508.

Looking at some IP info sites it looks like that IP address is located in Las Vegas as a virtual machine. IP also on the Abuse list as https://www.abuseipdb.com/check/209.141.43.56.

It could be the CnC server for this attack.

I'll keep digging around see what I find. We are still experiencing high CPU usage and missed pings throughout the network.

[allstarcomps]

I'm not a linux guy so its taking me a minute. Netstat did return open connections to the dns name and port I mentioned above.

tcp 0 1 192.168.202.10:38227 mail.abugou.xyz:36508 SYN_SENT

I'm also seeing in ps -ah command a 28tf process that is running that I do not see on a defaulted switch. every time I kill the process it just recreates its self.

[Stephen]

Hey allstarcomps, thanks for some insight. This seems like different behavior than we were seeing before. Running similar commands (in my case ps aux) did not return any extra running process's on the infected switch for us.

Quick question, since we're doing linux stuff.

Try getting the process id of 28tf, using the command you're already running.

Then run:
cat /proc/<28tf proc id>/fd/1

Depending on how the developer of this program compiled it, this might let us watch stdout of the process, anything it's printf'ing to the console. Which might be helpful.

You can also try
cat /proc/<28tf proc id>/fd/2 - which is stderr

It's a long shot, but might be enlightening if it works.

---
But to clear this if you need it gone asap, probably either a factory reset or an upgrade (even to the same version if it's already on 1.5.16) might also work.

Let us know what you see.

Another question, did these switch's also have the malicious /www/index.html file with the fbi PowerOFF image in them?

[allstarcomps]

I spent sometime trying to hunt down the 28tf process. could not find it. I rebooted the router and it went away. I believe the file was downloaded and executed in memory. Every time it was killed it just came back.

I just checked another router the process thats running is 9qgo, which means its a randomly named process so hunting and killing would be difficult to do.

At the moment looks like using the firewall to block IP:209.141.35.56 DNS:mail.abugou.xyz or port:36508 and rebooting the router is the best solution.

[allstarcomps]

sd_wisp@Dulzura_1_Solar_v_1:/www# cat /proc/940/fd/1
cat: can't open '/proc/940/fd/1': No such file or directory
sd_wisp@Dulzura_1_Solar_v_1:/www# cat /proc/940/fd/2
cat: can't open '/proc/940/fd/2': No such device or address

When the process is running it also likes to kill other commands/processes.
sd_wisp@Dulzura_1_Solar_v_1:/www# ls -l -t
-rw-r--r-- 1 sd_wisp root 20681 Aug 1 16:13 config.json
-rw-r--r-- 1 sd_wisp root 8 Aug 1 14:57 fan_test_results
drwxr-xr-x 2 sd_wisp root 91 May 15 20:50 Models
drwxr-xr-x 3 sd_wisp root 340 May 15 20:50 Scripts
Killed

So its been a little difficult to chase after them.

In terms of the index.html file. Yes I cleaned about 25+ switches yesterday. Today was 90%+ cpu usage dropped packets/missed pings. Log files all had the lighttpd server constantly restarting.

pwdx shows the process is in the /www folder. Nothing shows up in the folder even with the hidden files attribute.
pwdx 839
839: /www

I downloaded some of the index.html file. 892 bytes of the 900 bytes(process kept killing the transfer before it finished). download it here if you want. https://allstarcomps.com/Netonix/index.zip. It was a simple HTML file with the image encoded in base64. I didn't get the entire encryption so it doesn't show.

[lligetfa]

99% SURE ITS A LIGHTTPD VULNERABILITY

Does 1.5.16 have the same version/vulnerability as 1.5.14? If so, other mitigation steps are required until such time a new version is released.

[wtm]

I want to verify that we were able to see that all our infected Netonix units were in fact communicating with 209.141.43.56, this a server run on PONYNET.

This might give some more information on them:
https://threatresearch.ext.hp.com/mapping-malware-distribution-network/


Also was looking at the versions of Lighttpd, and found that there was a fix for a CVE-2024-3094.
Info per Cisco on that (interesting read)

https://pentest-tools.com/blog/xz-utils-backdoor-cve-2024-3094

We have started to block the Server IP, and that seems to help a bit.

However, even upgrading the devices to 1.5.16 does NOT remove the bug, as it is still in there as Lighttpd keeps restarting, and we are getting interruptions to the data flow in the switch. Possibly a need to completely reset the switch and see if that wipes the bug out?

We did try to re-install 1.5.16 again on one switch, and it immediately locked up the switch, and we had to physically bypass it and remove it from the network.

I would think that there is going to have to be a new firmware or patch to install and hopefully that will wipe out the bug? At this point don't know what program is infected?
Also, we need to figure out HOW this infected the devices?

[sirhc]

However, even upgrading the devices to 1.5.16 does NOT remove the bug, as it is still in there as Lighttpd keeps restarting, and we are getting interruptions to the data flow in the switch. Possibly a need to completely reset the switch and see if that wipes the bug out?

With all due respect I can 100% guarantee you a firmware upgrade removes everything.

Now it does not path the hole but ANY malicious code or ANY code not distributed in our firmware is removed.

[sirhc]

Our current plan is to release v1.5.17rc1 tonight or tomorrow that plugs THIS SPECIFIC hack but does not close the hole.

Then release another version as soon as possible that close the hole.


But people need to be looking for the infected machine that is giving access to a switch that is sitting on an invalid IP and could not be accessed directly.

If on a valid IP and your using our access list then a machine that is granted access must be infected.

Switches that are infected will not show signs of being infected until you access the web ui on the switch. If the machine your using is infected then by accessing the switch UI infects it.

You should use SSH to access switches first and if index.html is NOT there but then you access the switch UI and it is then there your infecting your own switches.

A switch can get infected but malcious code is only started when you access the web ui. SSH is safe and will not activate it