3

A friend who is a medical doctor has a medical imaging device that exports small jpg files by providing a Samba share. It runs a heavily modified version of Windows 2000 and only supports SMBv1. SMBv1 is utterly insecure and was already used by Ransomware to infect hosts. There is no support available for Windows 2000 or from the device manufacturer anymore.

Despite its age, the device is "medically" up to date and a replacement would cost multiple 10,000s euros. We would like to isolate the medical device as a Ransomware attack would certainly render the device unusable.

I bought a cheap OpenWRT router to mount the SMBv1 share from the medical device and re-share it with a newer Samba server, hiding the medical device behind that router. It worked at first, but re-sharing network shares is discouraged and resulted in reoccuring problems in production that I couldn't easily fix.

Workflow is as follows: During medical examinations, pictures are taken. These are stored on the device and shared via SMBv1. Later, the pictures are manually retrieved by the PC in the doctors office and deleted. Speed isn't too important, there are like 5 pictures of few MiB each. They don't have to be immediately available as he retrieves the pictures only after he ended the examination. Reliability is important, as lost pictures would cause the examination to be repeated.

What is the best option to isolate the medical device from the network while reliably allowing reading and deleting the pictures taken?

Sojaki
  • 103
  • 1
  • 8
  • 1
    FYI: As long as the device is discoverable by any internet accessible device then the SMBv1 device is exploitable. Windows 2000 didn’t receive any mitigation to any of the EternalBlue exploits which were spread as a worm. – Ramhound Apr 26 '21 at 11:39
  • @Ramhound Thanks for pointing out it out. That is our concern as well. As soon as any of the PCs gets infected somehow, the imaging device probably gets infected and bricked – Sojaki Apr 26 '21 at 12:25
  • @Ramhound: Those seem to be aimed towards the SMBv1 server, and the MS bulletin makes no mention of the Windows' SMBv1 client being vulnerable to the same attack. (Though it's quite possible that it will have a similar type of bugs, but fortunately it's a bit harder to trick a vulnerable client into connecting to a malicious server than it is for a malicious client to connect to a vulnerable server, especially if it's an embedded device and not a workstation with browsers and email clients...) ...As for the server side, Samba isn't affected by RCEs present in a Windows server, nor vice versa. – u1686_grawity Apr 26 '21 at 12:26
  • @user1686 - SMBv1 was wormable on Windows XP to Windows 10. Microsoft in order to avoid literally tens of millions of legacy devices being vulnerable and spreading WannaCry patched those clients. **SMBv1 clients absolutely was vulnerable to the EternalBlue exploits.** – Ramhound Apr 26 '21 at 12:31
  • @Sojaki - What I am suggesting is that, if that device is discoverable on the network, it could then be exploited in order to patch otherwise patched devices. – Ramhound Apr 26 '21 at 12:32
  • @Ramhound: That's because "client" Windows versions still have a SMB server in them, of course. – u1686_grawity Apr 26 '21 at 12:55
  • @user1686 - I am providing a warning against the Windows 2000 installation, that has SMBv1 enabled, and is accessible on the intranet. If that client can be discovered by other clients, that are accessible to the internet, the author could potentially be exposed even if the Windows 2000 client is not directly accessible to the internet. I am not sure what "those' refer to by the way in your last comment – Ramhound Apr 26 '21 at 12:57
  • @Ramhound: Having a SMBv1 client enabled for outbound connections _does not mean_ that the same system necessarily has a SMBv1 server enabled and accepting inbound connections. – u1686_grawity Apr 26 '21 at 13:00

1 Answers1

3

I would suggest the same, but instead of re-sharing a CIFS mount, set up a cronjob (and/or an 'incron' job) to move the deposited files from the "incoming" SMBv1 share to the real destination. It would be just a one-line script that calls find -mtime ... -exec mv ... (with some care to avoid moving files that are still being written, of course).

Using inotify-based tools (e.g. systemd.path or incron) would allow the transfer to be triggered instantly whenever a file is created, without actually wasting the device's resources on a frequent schedule.

However, I would probably run it in a container on a "real" server, with better resources (more RAM, better storage) than a cheap OpenWRT router has.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • Nice and simple solution! I thought of some kind of synchronization, but that would be more complicated and error prone. – Sojaki Apr 27 '21 at 10:08
  • inotify doesn't seem to work with remote filesystems though ([LWN.net](https://lwn.net/Articles/605128/), very end of the article) – Sojaki Apr 27 '21 at 10:09
  • Eh? From your Samba server's point of view, it is a _local_ filesystem that you'll be monitoring. It's the directory which you will be serving over SMBv1. _(I think 5.12 added support for inotify for cifs mounts though...)_ – u1686_grawity Apr 27 '21 at 10:18
  • When I want to move files from the incoming SMBv1 share to a local folder to share them with newer SMB, I need to monitor the incoming SMBv1 share, which is a remote fs. The SMBv1 server is on the medical device which I can't modify – Sojaki Apr 27 '21 at 10:25
  • Oh, I thought your post said that the device was a _client_ for user-provided SMBv1 server. _(Hence my arguing with @Ramhound about that...)_ – u1686_grawity Apr 27 '21 at 10:26