Linked by Thom Holwerda on Mon 15th May 2017 16:18 UTC
Windows

Friday saw the largest global ransomware attack in internet history, and the world did not handle it well. We're only beginning to calculate the damage inflicted by the WannaCry program - in both dollars and lives lost from hospital downtime - but at the same time, we're also calculating blame.

There's a long list of parties responsible, including the criminals, the NSA, and the victims themselves - but the most controversial has been Microsoft itself. The attack exploited a Windows networking protocol to spread within networks, and while Microsoft released a patch nearly two months ago, it’s become painfully clear that patch didn’t reach all users. Microsoft was following the best practices for security and still left hundreds of thousands of computers vulnerable, with dire consequences. Was it good enough?

If you're still running Windows XP today and you do not pay for Microsoft's extended support, the blame for this whole thing rests solely on your shoulders - whether that be an individual still running a Windows XP production machine at home, the IT manager of a company cutting costs, or the Conservative British government purposefully underfunding the NHS with the end goal of having it collapse in on itself because they think the American healthcare model is something to aspire to.

You can pay Microsoft for support, upgrade to a secure version of Windows, or switch to a supported Linux distribution. If any one of those mean you have to fix, upgrade, or rewrite your internal software - well, deal with it, that's an investment you have to make that is part of running your business in a responsible, long-term manner. Let this attack be a lesson.

Nobody bats an eye at the idea of taking maintenance costs into account when you plan on buying a car. Tyres, oil, cleaning, scheduled check-ups, malfunctions - they're all accepted yearly expenses we all take into consideration when we visit the car dealer for either a new or a used car.

Computers are no different - they're not perfect magic boxes that never need any maintenance. Like cars, they must be cared for, maintained, upgraded, and fixed. Sometimes, such expenses are low - an oil change, new windscreen wiper rubbers. Sometimes, they are pretty expensive, such as a full tyre change and wheel alignment. And yes, after a number of years, it will be time to replace that car with a different one because the yearly maintenance costs are too high.

Computers are no different.

So no, Microsoft is not to blame for this attack. They patched this security issue two months ago, and had you been running Windows 7 (later versions were not affected) with automatic updates (as you damn well should) you would've been completely safe. Everyone else still on Windows XP without paying for extended support, or even worse, people who turn automatic updates off who was affected by this attack?

I shed no tears for you. It's your own fault.

Thread beginning with comment 644337
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Comment by FlyingJester
by Alfman on Tue 16th May 2017 19:15 UTC in reply to "RE[6]: Comment by FlyingJester"
Alfman
Member since:
2011-01-28

Lennie,

VPNs can be 'fun', because if you have a long running VPN which route more than just a few subnets over it you might end up breaking DNS (which is might be needed for reconnecting the VPN on timeout) or NTP updates because they are also routed over the VPN.

Many embedded devices don't have any time at all.


I know, this is why I brought it up. It creates a failure condition at some point in the future that are likely overlooked during testing. I'm less familiar with IPSEC, do you know if those are designed to stop working based on the date?

DNSSEC on embedded devices is a real problem, if you want to use DNSSEC you need NTP, but NTP relies on DNS... oops catch 22. ;-)



That's an interesting problem.

https://www.ietf.org/mail-archive/web/dnsop/current/msg19955.html

I don't think we can assume the accuracy of time on endpoints. This bootstrap would be solvable if the client were allowed to use a challenge/response protocol. Although that would come at some expense for both scalability and robustness during bootstrapping. Obviously proof of time is not going to be possible over an air gap ;)

And then you still have the issues with certificate revocation that are not really specific to DNSSEC: If you know the time, you can validate a CRL, but if you don't know the time, you have no idea if the CRL you are given is current.
https://en.wikipedia.org/wiki/Certificate_revocation_list

Reply Parent Score: 2

darknexus Member since:
2008-07-15

I'm less familiar with IPSEC, do you know if those are designed to stop working based on the date?

That really depends on your implementation and how you've configured it. IPSec is one of those protocols that you can't necessarily cover with a blanket statement. If you've configured by using PSKs, then it may not depend on the time sync. If you've done it with certificates, then you're going to have the same issues as you would using an SSL or other cert-based VPN. Even if you have used PSKs, the implementation you're using may (or may not) reject a connection if the time is too far off. Your intrusion detection can have an impact on this also.
So, short answer: it's complicated. ;)

Reply Parent Score: 2

RE[8]: Comment by FlyingJester
by Lennie on Tue 16th May 2017 20:49 in reply to "RE[7]: Comment by FlyingJester"
Lennie Member since:
2007-09-22

Both IPSEC and OpenVPN have a periodic re-keying of the temporary session keys. So time is clearly used (but that is relative time, not absolute time. It's a timer).

You can do both OpenVPN and IPSEC with pre-shared keys or with certificates.

If time is a big issue, maybe a large pre-shared key can be done safely. Depending on the crypto used, pre-shared keys can be less safe than certificates if I'm not mistaken.

I ones thought really long and hard about the embedded device problem. One thing that could help is to periodically save a timestamp. So you can't replay very old data. And obviously, don't use DNS for NTP. ;-)

Reply Parent Score: 2

RE[9]: Comment by FlyingJester
by Alfman on Tue 16th May 2017 22:26 in reply to "RE[8]: Comment by FlyingJester"
Alfman Member since:
2011-01-28

Lennie,

Both IPSEC and OpenVPN have a periodic re-keying of the temporary session keys. So time is clearly used (but that is relative time, not absolute time. It's a timer).


Relative time isn't a problem. It's that a network that's been running for years suddenly stops working because some battery died or NTP service became inaccessible or arbitrary date expiration on a certificate.


I ones thought really long and hard about the embedded device problem. One thing that could help is to periodically save a timestamp. So you can't replay very old data. And obviously, don't use DNS for NTP. ;-)


There is a way to avoid that, the client could use the hard coded root certificates to securely obtain the time from the root name servers. This would work and be secure. The main problem is scalability: a root server can't delegate the time function to other servers as with other normal DNS requests because the validity of delegation depends on having the correct time.

Using the root name servers to bootstrap time is not ideal, but it ought to be secure and technically feasible. They might even reduce the accuracy to +/- an hour to discourage their use for anything other than bootstrapping.


Another idea would be for IANA to designate some permanent IP addresses for dozens of time servers. This sounds like a hack on the surface, but when you think about it, this is how the DNS root nameservers themselves gets bootstrapped. So it could be a pragmatic solution.

Another idea would be for computers to have built in time receivers
http://www.cl.cam.ac.uk/~mgk25/time/lf-clocks/


We should always plan that the internet to break, for scenarios that can't fail, get a local battery backup time source ;)

Reply Parent Score: 2