[RANSOMWARE] >>READ 1st Post<< Deadbolt

[Hulli]

I just reset my NAS to factory settings (reinitialize so it wipes everything) and after switching on it still has the deadbolt message!

Sure, because factory reset will not copy a new system to the Nas.
So index.html will still be there because it's part of the normal system.
I assume building the Nas from scratch with a new system could help. Otherwise wait for new malware remover or other solution from qnap or change it manually.

Brgds

Hulli

[jaysona]

CVEs are not only reported by those involved, obviously. These can be reported by essentially any security company, large companies... and even private investigators can carry out the reporting process. This is done precisely to prevent the affected company itself from manipulating the data.

Not quite. If I find a vulnerability that is unique to QNAP code, only QNP can open a CVE for that vulnerability because QNAP is the designated entity. I can not assign a CVE number to something that uniquely affects QNAP code.

[chumbo]

(...)btw .. you were warned a while ago .. and you ignored the warning
viewtopic.php?f=21&t=154832

No, actually I did follow your advice...I stopped using the QNAP apps.

[Theliel]

Not quite. If I find a vulnerability that is unique to QNAP code, only QNP can open a CVE for that vulnerability because QNAP is the designated entity. I can not assign a CVE number to something that uniquely affects QNAP code.

Sorry mate, but it doesn't work like that. Anyone can request the opening/assignment of a CVE with total independence of which product/company it belongs to. I have already reported CVE more than once. If the security flaw belongs to a company attached to the Mitre, you must contact them through the existing channel for this purpose, since they themselves act as CNA. In the event that the company or the developer or... does not belong to the Mitre, you must go to the CNA Last Resorts, another "group" that makes the CNA assignments in the event that those involved are not subject to the Mitre (or do not respond you or...). At this point, as affiliates, they have the obligation to attend to the request for the report, assign a CVE ID if applicable (it is not a duplicate, the report is valid, etc etc etc), comply with the confidentiality policies, times etc. etc etc...

If the CNA plays dirty and intends to hide information of some kind, or refuses not to assign the CVE despite the information being correct... you just have to go directly to the Mitre and report what happened. If the information provided is true, they will penalize/punish the CNA, and they will directly assign you the CVE.

[nonojapan]

Still nothing from qnap after 24 hours that I opened tickets in both U.S and Japan.

[OneCD]

Still nothing from qnap after 24 hours that I opened tickets in both U.S and Japan.

@nonojapan, you’re responding to quotes incorrectly. Please put your comments outside the quote blocks.

[nonojapan]

Still nothing from qnap after 24 hours that I opened tickets in both U.S and Japan.

@nonojapan, you’re responding to quotes incorrectly. Please put your comments outside the quote blocks.

Sorry about that

[P3R]

Not QNAP is the culprit, that is only you! You have put your NAS unsecure into the internet!

I strongly disgree with all of that. Qnap have for years told their customers that they should expose their Qnaps so that they have easy access to their data from anywhere. They have used insecure defaults that have lead even non-aware users into exposing their systems. To demand that the non-professional home and SMB users that Qnap target with their low-end products should understand security and be responsible for exposing their systems is absurd when the manufacturer have pushed them into doing exactly that. Also it's Qnap that have these constant fatal 0-day vulnerabilities, many caused by sloppy programming, like the backdoor account that caused the first QLocker campaign. Not to mention all the downplaying and secrecy around all of these vulnerabilities.

Qnap have the full responsibility for the attacks being possible and the customers have every right to be furious for the attacks being possible and occuring so frequently.

Once again sorry, but this is also a mistake from a majority of users: they often think "hey, its a NAS, my data is secure" And this is also wrong, a NAS can break down, not only a single drive (for that is Raid), but the complete NAS can fail. Therefore an actual and periodical backup strategy is mandatory.

This is correct.

While Qnap have a responsibility to deliver a reasonably secure system, which they have failed with big time, they can never be responsible for protecting the user data. That is always the responsibility of the data owner himself and that is best done with external backup copies of data on other systems and with at least one stored at another site. For those that think so, no a real-time sync is not considered a good backup.

Malware attacks is just one of many threats to data on a single NAS and users that don't have external backups of their data have failed to protect it to at least a minimum level.

Qnap is responsible for the attacks being possible. The users are responsible for their failure to protect their data from single-system threats, which have caused the attacks to have much worse consequences, like data loss. One can't expect home users to be able to evaluate security threats and protect themselves against them but everyone must have heard that they need to backup their data.

[genmaitya]

So much wow! The risk *is not* practically zero if the NAS is accessible from the Internet, even with QuFirewall enabled. Smh.

I recommend installing Qufirewall and selecting "Include subnets only" to reduce attacks from the Internet.
Then change to use VPN for access from the Internet.
UPnP is of course prohibited.
Or it is also effective to limit the management port to private address only.

[Sevenfeet]

Not QNAP is the culprit, that is only you! You have put your NAS unsecure into the internet!

I strongly disgree with all of that. Qnap have for years told their customers that they should expose their Qnaps so that they have easy access to their data from anywhere. They have used insecure defaults that have lead even non-aware users into exposing their systems. To demand that the non-professional home and SMB users that Qnap target with their low-end products should understand security and be responsible for exposing their systems is absurd when the manufacturer have pushed them into doing exactly that. Also it's Qnap that have these constant fatal 0-day vulnerabilities, many caused by sloppy programming, like the backdoor account that caused the first QLocker campaign. Not to mention all the downplaying and secrecy around all of these vulnerabilities.

Qnap have the full responsibility for the attacks being possible and the customers have every right to be furious for the attacks being possible and occuring so frequently.

Once again sorry, but this is also a mistake from a majority of users: they often think "hey, its a NAS, my data is secure" And this is also wrong, a NAS can break down, not only a single drive (for that is Raid), but the complete NAS can fail. Therefore an actual and periodical backup strategy is mandatory.

This is correct.

While Qnap have a responsibility to deliver a reasonably secure system, which they have failed with big time, they can never be responsible for protecting the user data. That is always the responsibility of the data owner himself and that is best done with external backup copies of data on other systems and with at least one stored at another site. For those that think so, no a real-time sync is not considered a good backup.

Malware attacks is just one of many threats to data on a single NAS and users that don't have external backups of their data have failed to protect it to at least a minimum level.

Qnap is responsible for the attacks being possible. The users are responsible for their failure to protect their data from single-system threats, which have caused the attacks to have much worse consequences, like data loss. One can't expect home users to be able to evaluate security threats and protect themselves against them but everyone must have heard that they need to backup their data.

This post is spot on. There is plenty of blame to go around....both QNAP and the user community.

I deal with enterprise customer success issues with one customer who cannot afford something like this to happen (the entire world would freak). Yet weeks ago I was in daily meetings on mitigating Log4J issues company wide. Hey, vulnerabilities can happen to the most prepared companies.

First, let's look at QNAP. They need to be better, especially if they are promoting cloud services or other features where their products are facing the exposed Internet. Lots of warnings like "here's what can happen if you do this....do you really really really want to proceed?" Customers, especially home users and small to medium sized businesses who buy this technology have to understand the risks. I don't know if they have a bug bounty program but I'd start one if they don't. It's a lot cheaper to reward a white hat security guy then be burned time and time again and lose customers.

And for the companies who do use these products, find someone in your city who does IT security consulting....there is usually a resource you can pay for this. Yes, I know you don't want to spend the money but the security audit and education is cheap compared to the alternative.

For all of us who depends on the data these things house...that's not your data on this NAS. At least, it's not your data unless it's in at least three places. One copy on the NAS, yes. Another local copy has to be available in case the worst happens (ransomware, hardware failures, theft, fire, flood, you name it). DO NOT use the same platform to keep your data copy, no matter how convenient it might be. I use a different RAID on a different OS to keep my QNAP NAS files. This is not a cheap thing to do, but it's cheaper than losing years of work and personal data forever. I don't even use QNAP's copy sync tools to keep them synced....don't trust 'em, there are other alternatives not written by the same software teams. And then there needs to be a cloud backup of the data for the third copy. And I make the cloud backup from the backup server, not from the QNAP. Because I'm paranoid.

Then there are the things you must do to keep a NAS safe. If you don't need it facing the Internet, don't. Most people don't. If you do need to get to it from the outside, use a VPN. Don't have a VPN feature on your router? Find a better router and buy it. Features like UPnP is asking for trouble. None of the devices on my LAN need it and if it ever was needed, I'd probably VLAN that ** away from everything else. Because you need to be paranoid. Do you have a port open for a Plex server (or worse, you're using UPnP)? DON'T. An exposed Plex server only tells people scanning IP addresses that something interesting is on the other side. Not worth the risk.

I don't use QuTSCloud and don't have a reason to. The fewer vectors to the outside world, the better. Admin account is disabled and strong passwords used everywhere else. That was the lesson last time this happened...good advice.

I'm running QuTS Hero 5.0.0.1892 and I literally begin my day scanning QNAP's website for firmware updates since they are often posted there before the upgrade servers than the NAS would talk to. Once I saw what was happening after the email from QNAP (thanks guys!), I did a cursory check of my NAS to see if anything was amiss. No problems seem to be in flight so I shut the unit down for the night and I'll do a proper security sweep tomorrow morning. I think there is a .1900 code base in beta but with this attack I'm wondering if that will change once we get more information on the attack vector.

[nonojapan]

Sevenfeet, I think you are right about the 3 back-ups. On my site 70% was back-up on AWS3, so not everything is lost. May I ask, how to you do to automate the back-up from Qnap NAS to the back-up NAS ? What maker do you advise for the back-up NAS? Thanks a lot.

[pbch1]

Why you are talking about companies instead of restrict to to topic to (maybe) find a solution?
Yes. As Sevenfeet metioned: "Qnap have for years told their customers that they should expose their Qnaps so that they have easy access to their data from anywhere." --> That is also my reason to buy a QNAP then.

About Firmware-Question. My QNAP has 5.0.0.1891 build 20211221 and i'm infected.
QNAP Ticket 26/01/2022 09:15 MEZ - No return message until now.

I'm looking for more people they can cornfirm to get a working key i paid.
I'm looking for a answer if i should update the system or sty as it is to not block the only way to get data back with a key.

[Taigrow]

I also was hit. I was able to log in. I think I stopped it from going further. I tried the SSH and change the files but wont let me. I was just in the process of fixing the old synology back up nas when I was hit. (synology fatal error had to replace all drives)
I have unaffected files on the Qnap. But cant get the Rsnyc,ftp,smb not any connection to the synology from the Qnap. I can access via network places but not direct between the two.
Does anyone else have this problem?
Before the crashed Syn and Qnap deadbolt it would rsync no problem. Any help would be great. I really don't want to have a computer between the two to move files if possible.
I still regret falling for the "thunderbolt" DAS line from Qnap.

[OneCD]

I've just been checking the BTC address given to users... it's not showing any transactions (which seems odd as a few people say they've paid).

https://www.blockchain.com/btc/address/ ... qm93j9jcul

Is anyone here familiar with BTC transactions who knows why?

[SimonKenoby]

Hello, I have seen this morning that I got infected, luckily it seems that no file have been encrypted yet. So i'm trying to remove it before it can do any harm. I have succeded to restore index.html by connecting in ssh.

I have tried what was suggested in earlier page of this post, remove file in mnt/HDA_ROOT:

Code: Select all

[/mnt/HDA_ROOT] # ls -la
total 1016
drwxr-xr-x  9 admin administrators   4096 2022-01-27 04:49 ./
drwxr-xr-x 17 admin administrators    360 2022-01-27 08:02 ../
-rwxr-xr-x  1 admin administrators 960896 2022-01-25 16:58 13813*
-rw-r--r--  1 admin administrators    501 2021-11-12 15:02 .conf
drwxr-xr-x 61 admin administrators  12288 2022-01-27 08:20 .config/
drwxrwxrwx  2 admin administrators   4096 2022-01-27 04:54 .inited/
drwxr-xr-x  9 admin administrators   4096 2022-01-27 08:13 .logs/
drwx------  2 admin administrators  16384 2019-10-26 18:00 lost+found/
-rw-r--r--  1 admin administrators   5062 2020-07-08 17:40 md_backup_2020-07-08_17.40.08
-rw-r--r--  1 admin administrators   5065 2020-07-08 18:06 md_backup_2020-07-08_18.05.17
-rw-r--r--  1 admin administrators      0 2019-11-02 11:39 .nfs_fix_check
-rw-r--r--  1 admin administrators      0 2019-10-26 11:05 .QTS.installed
-rw-r--r--  1 admin administrators      0 2019-10-26 11:05 .QTS.installed.notice
drwxr-xr-x  2 admin administrators   4096 2022-01-27 04:41 ssl_lib/
lrwxrwxrwx  1 admin administrators     24 2020-04-10 16:28 twonkymedia -> /mnt/ext/opt/twonkymedia
drwxr-xr-x  2 admin administrators   4096 2021-03-17 12:49 update/
drwxr-xr-x  3 admin administrators   4096 2022-01-27 04:57 update_pkg/

But,

Code: Select all

[/mnt/HDA_ROOT] # rm -f 13813
rm: can't remove '13813': Operation not permitted

I can't remove this file.

And there is no process with this PID:

Code: Select all

[/mnt/HDA_ROOT] # kill 13813
-sh: kill: (13813) - No such process

I have also looked that what process looked suspicious to me, but nothing it using CPU or writing intensively to the drive.

In addition, it seems that indeed my snapshoot have been deleted.

So if someone has idea on how to find it and remove it before it can do any harm I would be thankful.

Also, if it can help, my nas rebooted during the night, maybe that's what prevent it from acting?