0XXX Ransomware Attack


Kev600

Recommended Posts

I came back from vacation and powered up my 6.12.4 Unraid server and, whilst working to build my ebooks/pdf collections, I noticed I had a specific share partly affected by the 0xxx ransomware on 06/11/23.
I don't think it's affected anything too crucial - but with a sick feeling in my stomach,  I'm still reviewing the remaining 600~ infected files -Obviously, I'm not paying $800 worth of Bitcoin.

 

I went through this - outdated?! page - https://unraid.net/blog/unraid-server-security-best-practices and didn't have anything as a great big 'come get me' misconfiguration... and I think that the exploit has possibly occurred when accessing an old BuffaloNAS drive which only supports SMBv1, via Unassigned Devices; with a clean/uninfected Windows10 laptop in the middle... But I'm still not sure how this actually happened, when my router isn't exposing any sensitive ports... OK I did have #80 pushed to #380, when trying, unsuccessfully; to get Nginx Proxy Manager to work with Containers.. and I have an old Win7 VM which I'll investigate a little further..

I've never had any issues with that BuffaloNAS server in over 10 years as an externally, port forwarded FTP Server, with occasional WebAccess via BuffaloNAS.com, and direct SMBv1 access to/from my Windows 7/10 PC's.
So I'm not convinced it's the source of the exploit.

I set up ClamAV and I've scanned everything on my Unraid Array - and yes there are a bunch of really old Windows exe files that are infected with some really old trojans, I knew about - Which shouldn't have any effect in a linux environment, and have subsequently been deleted... 

 

But the bottom line here is WE, the Unraid Community, NEED HELP TO PREVENT THIS.
I currently feel very uncertain about having a combined app/storage/backup server when it's already been compromised. 


Very interested to hear comments on this, please. 

Thanks

Kev

  

Link to comment

Ransomware is more common these days and literally all it takes is one rogue executable on any Windows machine that's connected to a writable SMB user-share. Unraid is only ever as safe as you configure it to be and the underlying system is not the primary attack vector of interest for Ransomware, even if you carelessly expose some ports on the internet. It's much more flexible to just infect Windows devices and look for generic writable network shares of any OS, rather than spending all that time and effort exploiting that one specific Linux OS (that might be patched anytime rendering the whole exploit useless).

 

The easiest safeguard against Ransomware is setting all your important user-shares to SMB read-only access and creating only a "quarantine" one with SMB read/write access. On Windows you'll move all your new files to the quarantine one instead (temporarily). From there you'll eventually move them to the important shares periodically (e.g. via user script or command line), but without ever granting any external (particularly Windows) system write access to those shares, so you'll do all that on UNRAID directly. That way the worst that can happen is your temporary "quarantine" share gets encrypted and you'll have only a week's worth of files lost instead of all of them. 

 

Edited by Rysz
  • Like 1
Link to comment

Thanks Rysz.

 

So - I'm gutted to realise/admit that the Share in question had public read/write access for both NFS and SMB; which I guess explains how the files became exposed. I think I set that because Windows was failing to connect to the Share!

I'm still at a total loss as to what triggered the exploit though! I've never had any issues like this with any data on any devices...


Moreover, what's a recommended way, please, to use UNRAID as a safe, robust storage/fileserver at LAN level, let alone WAN.....(Planning to use NextCloud for that). Surely just using ONE read/write share with the subsequent file management; isn't the only/best solution?

 

Thanks

Kev



 

Link to comment
Just now, Kev600 said:

Thanks Rysz.

 

So - I'm gutted to realise/admit that the Share in question had public read/write access for both NFS and SMB; which I guess explains how the files became exposed. I think I set that because Windows was failing to connect to the Share!

I'm still at a total loss as to what triggered the exploit though! I've never had any issues like this with any data on any devices...


Moreover, what's a recommended way, please, to use UNRAID as a safe, robust storage/fileserver at LAN level, let alone WAN.....(Planning to use NextCloud for that). Surely just using ONE read/write share with the subsequent file management; isn't the only/best solution?

 

Thanks

Kev



 

 

Well my solution is probably among the most paranoid and inconvenient ones, so it's surely not the best or most acceptable one. Ideally you'd just make sure to use a strong password and keep the client access limited to a necessary minimum (best measures = the most inconvenience you can accept basically). Of course these clients with access should be kept up to date with the latest updates and anti-virus definitions. If you then only install software from reputable sources and don't open executable files you have a bad feeling about on them I'd say you're golden. This applies on any kind of server or data access so it's not limited to Unraid, the problem isn't limited to Unraid either. I mean thousands of users likely don't apply any kind of precaution and never have any problems, you just got really unlucky there, so I wouldn't linger on it too much. But it's good to learn from such experiences and know what kind of precautions you can ideally do, because then you can decide on what kind of precautions you want to do and are acceptable comfort-wise.

Link to comment

I think the important part of what Rysy first posted may not recognized here - That the Unraid server may not (and more likely not) be the initial target of this Ransomware attack.  What is more likely is that another system on your network has been compromised, and that, in turn, has affected your server.

 

You should take actions to check all of the devices/systems on your network to determine that they are not also affected by this attack.  It may not be apparent, rather lying dormant at this time.

  • Upvote 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.