A Florida water treatment plant breached. People nearly poisoned. A SCADA device exposed via Windows & Team Viewer. Not where we want to be. How did it happen, how do we prevent systematically? Read On!
Earlier I wrote about the attack on a Florida water treatment plant. A remote site had an old Windows 7 PC with Team Viewer and shared passwords, and, well, the rest wrote itself.
A new blog post out gives some more details about a ‘watering hole’ attack that occurred just in advance. In a nutshell, a (legitimate) related industry site was compromised and served a wee bit of malicious JavaScript. Someone from the target opened a page there.
As we can see in the screen shot, a script is present that probably the original author did not wish. WordPress is particularly hard to secure for Content-Security-Policy, but, a script-src directive in the CSP would have prevented this issue. The browser would have rejected loading the malicious script.
I’ve written a lot about Content-Security-Policy (and some videos!). In particular, I showed how it protected my personal site (well the users of it) from malicious content injected by some malware extension they had installed. Its a great seat belt. Head on over to the Mozilla Observatory and check your site.
Now, let’s assume that either a) we didn’t prevent with Content-Security-Policy, or b) the attacker worked around. What would be our next step (Defense In Depth!). Well, Zero-Trust. If we assume that we can’t fix human behaviour, that people are going to need remote access to things, we may as well make it safe and convenient. A simple single-sign on, Zero-Trust Network Access model, we could have made that SCADA device safely usable remotely, removing the value of the attack.