ETC Eos and SMBv1 vulnerabilities (RE WannaCry)

Hi,

One of my colleagues emailed your technical support team about a month ago regarding your plan of action for mitigating the risk to networked consoles from worms that propagate using the SMBv1 vulnerabilities that have recently been made very widespread with the WannaCry attack.

We have an ETC Element running Windows XP Embedded, so our console is running one of the affected versions of Windows. As Microsoft has now made patches for all recent versions of their OS available, is there any guidance on how to get these patches onto our Element, as we did have a WiFi network for remote control setup that was regularly used by phones as well as (potentially untrusted as the space is shared with several show teams) Windows laptops running ETC Nomad in client mode.

Looking forward, are there any plans to migrate away from EOS' dependency on SMBv1 and to move to versions 2 or 3 which are far more secure?

Sources:

Thanks,

Rob

  • Hi Rob,

    The configuration of the Embedded OS is carefully monitored to provide a consistent and stable operating platform. As such we want to make sure any patches provided by Microsoft don't negatively impact features or performance and are able to be deployed. ETC is investigating possible Windows Embedded OS updates that include a comprehensive fix for the vulnerability as developed and validated by Microsoft. Until this can be validated on the ETC platforms we encourage everyone to please contact Technical Services to discuss the Risk associated with your specific configuration and on options regarding actions required, if any.

    As your colleague has already contacted Technical Services, someone will be reaching back out to you directly to discuss this matter.

    Thanks,
    Matt
  • I'm a big proponent of air-gaped lighting networks for this reason. There is zero functionality to be gained by putting your lighting network on a public facing network. Don't put yourself into a situation where your system is vulnerable to such attacks.
  • I see your point, however if we have potentially untrusted devices from external technicians connecting to our air gapped control network that have previously been on the internet they may be infected with something that could potentially propogate to the console. (We use ETC Nomad in client mode regularly as a remote control)

    I personally don't agree with the "it's insecure, we know, so just don't connect it to a network" argument considering patches have been released (I understand that they will have to be tested with the specific version of Windows XP embedded running on our Element) and that EOS appears to be using SMBv1 which is known to be very vulnerable when there are newer more secure iterations of the protocol available.

    Obviously if there is a critical feature that relies on a specific functionality in SMBv1 that isn't replicated in the later versions that would explain a longer development time to move away from that protocol.

    If ETC were to come back and say we need to upgrade our Element to a Windows 7 mainboard I would far rather attempt to find the budget (we are a student theatre run by volunteers on a very small budget) than run quite such a vulnerable system.
Related