www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
Hit by WannaCry? No one to blame but yourself
By Thom Holwerda on 2017-05-15 16:18:18

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.

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-80 -- 81-90 -- 91-100 -- 101-109
.
I shed no tears for you. It's your own fault.
By quackalist on 2017-05-16 17:09:11
Damn stupid way at looking at the problem, lots of people/institutions are at fault. Number one being the NSA and it's ilk hoarding security vulnerabilities that eventually get out into the wild.

Course the vulnerability should have been patched and the NHS should have paid for it's XP systems to have security updates from MS etc etc

But this has impacted a lot of people (me for a start who couldn't get my blood results or prescriptions) which you should have a little empathy if not tears. It wouldn't surprise me if people didn't die because of this.

Lots of other 'bad stuff' happened ...Nissan, a couple of miles away from me, stooped car production etc

Wake up call, it could have been a lot worse, not moralising
Permalink - Score: 2
.
RE[4]: Comment by FlyingJester
By Lennie on 2017-05-16 17:11:23
Cloud services is a good example.

The experiences I had was with Windows servers.

Some of the Microsoft software is build in .net and that would use code singing and Windows is checking the certificates. To check the certificates on that code it needs an up to date Certificate Authorities-list or Internet connectivity (it does automatic downloading). Sometimes... CA-list updates are actually not included in the Windows updates (without an Internet connection, you need an updates server as well of course).

So what do you get ? If a server for example reboots, the server software won't start because the CA-list is to old and it can't automatically download an update.

In theory it should never happen, has already happened several times.
Permalink - Score: 3
.
RE[5]: Comment by FlyingJester
By Alfman on 2017-05-16 17:44:08
Lennie,

> Some of the Microsoft software is build in .net and that would use code singing and Windows is checking the certificates. To check the certificates on that code it needs an up to date Certificate Authorities-list or Internet connectivity (it does automatic downloading). Sometimes... CA-list updates are actually not included in the Windows updates (without an Internet connection, you need an updates server as well of course).

So what do you get ? If a server for example reboots, the server software won't start because the CA-list is to old and it can't automatically download an update.

In theory it should never happen, has already happened several times.


That's an interesting point, there are unexpected failure modes everywhere and it's easy to overlook those things when everything is working.

Sometimes we sign SSL certificates with arbitrary expiration dates in the future that we'll very likely forget about (it will probably be someone else's problem).

Several weeks ago an offsite computer wasn't responding, apparently it didn't power on automatically as it always had before. It's a few hundred miles away and I haven't gotten a chance to diagnose it yet but I am thinking it may be the cmos battery, which not many of us give much thought to.

Like many administrators, I rely on 3rd party DNS black listing for spam classification, but those could fail or get compromised causing widespread denial of services.

All these what-if's are why certification is so important and so expensive in critical systems.

Edit:
I just remembered about OpenVPN's use of SSL certificates...off to check whether it ignores the dates or if that's a potential failure mode in the future!

Oh crap, it is a failure mode, and openvpn's official stance is they won't give users an option to ignore time even on servers where there may not be a reliable time source.
https://community.openvpn.net/ope...

Time validation is correct by default, but it introduces a new failure mode in routers that don't have a clock source... the VPN will work fine until there's an NTP failure.

Edited 2017-05-16 17:56 UTC
Permalink - Score: 2
.
RE[2]: Blame List
By wa2flq on 2017-05-16 18:10:18
> But... But they fixed it two months ago?

That's not sufficient.

Microsoft created an ecosystem in which many of their customers do not trust their patching system or updated products. Hence they own this problem.

Apple is not perfect here either but I believe most iOS and OS X users rarely think twice about taking a patch. Okay, I usually wait 2 or 3 days after a release…

I am beginning to think that OS Vendors should be required to supply free Security Patches for NN number of years, where NN is 10, 15 or 20 years. Customer and businesses behavior is never go to match good IT Practice if requires regular support and/or major upgrade costs. Even if you legislated businesses to purchase support or update regularly, it will turn into a bureaucratic mess (example: USA: Sarbanes-Oxley).

Medical, critical infrastructure or life safety equipment with embedded computing is always going to be a challenge. It's going to take changes in the professions that use these devices to step up and demand stricter support processes from their vendors.
Permalink - Score: 2
.
RE[6]: Comment by FlyingJester
By Lennie on 2017-05-16 18:11:52
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.

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. ;-)
Permalink - Score: 2
.
RE: In other security news...
By Bill Shooter of Bul on 2017-05-16 18:36:12
Yeah, there lies the rub.

I think at this point, I'm more interested in a secure device that I don't have full control over, than one that has vulnerabilities that can be exploited to allow me greater control over the device.
Permalink - Score: 2
.
RE[4]: This won't change
By yerverluvinunclebert on 2017-05-16 18:39:41
One of the things I do is to maintain essential legacy systems that provide a fundamental service to aero, military, hospital, nuclear and oil industries. All these systems are still in place because the job they do is first class, they CANNOT be upgraded EVER (nuclear SCADA) and they will continue to operate forever. Imagine having to rebuild the software that supports the drawings for the whole of airbus industries. Even though those aeroplanes seem new they were actually designed decades ago in the late 70s/early 80s and the 'puters that they run on are still the originals. As well as needing recertification of all aeroplanes in the air, to redesign and rebuild the software to run on new machines would cost tens of millions and give no benefit whatsoever, except to increase the uncompetitiveness of Airbus' offerings. The nuclear industry never change ANYTHING as to do so could cause a big radioactive hole in Cumbria. Trackside and hospital systems running on Windows 10? Do you want your Blue screen of death to be your death literally? No new systems anywhere critical, no new bugs, no new back doors please... Only systems that are tried and tested, equally fault tolerant - are required. Avoid new systems like the plague if you want the world to actually operate reliably and you want to live.

Edited 2017-05-16 18:48 UTC
Permalink - Score: 1
.
RE[7]: Comment by FlyingJester
By Alfman on 2017-05-16 19:15:18
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...

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/Cer...
Permalink - Score: 2
.
RE[2]: In other security news...
By Alfman on 2017-05-16 19:52:38
Bill Shooter of Bul,

> I think at this point, I'm more interested in a secure device that I don't have full control over, than one that has vulnerabilities that can be exploited to allow me greater control over the device.

Yea, I understand. Although personally I don't like that manufacturers present us with such a contrived choice in the first place. Owners should never be put in a position to depend on vulnerabilities to get the most out of their devices. :(
Permalink - Score: 2
.
RE[8]: Comment by FlyingJester
By darknexus on 2017-05-16 20:21:03
> 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. ;)
Permalink - Score: 2

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-80 -- 81-90 -- 91-100 -- 101-109

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?