Everything you need to know about the Petya, er, NotPetya nasty trashing PCs worldwide It is now increasingly clear that the global outbreak of a file-scrambling software nasty targeting Microsoft Windows PCs was designed not to line the pockets of criminals, but spread merry mayhem. The malware, dubbed NotPetya because it masquerades as the Petya ransomware, exploded across the world on Tuesday, taking out …
The issue is organisations have NO EXCUSES whatsoever for failing to deploy patches that are issued.
Software compatibility
Hardware compatibility
Software/hardware that needs to be properly audited and certified to be used
Number of patches released in a single lump
Trustworthyness of the vendor releasing said patches (how often to they cause failures).
Time taken to make sure it won't break your stuff
Seriously of the need for this particular patch (ie can the secretary's assistant's intern's machine wait another few weeks, and can we get in the team to re-certify the MRI machine before we point it at some unsuspecting brain?)
There's a few reasons right there for many places not updating immediately. Better networks might make a huge difference (ie if your MRI machine can get it's data to where you need it, but nothing from the internet can reach it...), but some stuff cannot be fixed except for at huge cost.
There's a few reasons right there for many places not updating immediately.
So it wouldnt matter if NSA had announced the exploits, Shadowbrokers had dumped sooner or researchers finding as part of normal work - people would still put off the patch for $REASONS and then get pwnd.
Every decision to not apply a patch (even when the reasons are good) is a broad acceptance that anything bad which happens afterwards is better than the risk of patching. When events like WCry land, they need to accept that its an outcome of their decisions. If a patch is rated Critical by the vendor and SANS are saying "patch now" it seems reasonable that any delay is accepting a lot of risk.
Systems important/critical/fragile they cant be patched quickly should be kept off the net etc.
While I agree with the sentiment that hoarding vulnerabilities in the name of national security is rather stupid, the above isn't really true in this case since MS have patched the vulnerabilities in question. If this had happened last year when the NSA new about the bugs but MS didn't it might have been a good point, but when malware is exploiting bugs that were patched months ago it hardly makes sense to complain that they weren't patched even earlier
Not everything can be patched easily. When XP and intranet pages etc exploded into the business world, a lot stuff was written to work with technologies that only existed IE61. I'm sure the writers assumed these things would continue but they didn't, for whatever reason the tools were not supported in IE7 and onwards. But there was the issue that a hell of a lot of stuff considered "business critical" was written for IE6 and would not work on 7 or later. People could not upgrade to a more secure browser because of this. I assume there's still many places where 6 has to be used even today.
A lot of other systems were developed around older tech, which can be hard to update as has often been discussed in these forums.
The question I am wanting asked is.. How long did NSA know of this particular flaw? DId it date back to pre-XP versions of Windows? Did the NSA know about it before Vista? Before XP SP3? When? Because the longer they sat on it, the more systems were built using the flaw, and the more systems became vulnerable; ie if they know about it pre-Vista and had told MS then, then MS could've had Vista and onwards fixed, and only the XP systems to worry about. Had the NSA told MS before XP SP2 then XP would've been fixed back then, and probably very few systems would've been vulnerable - the lot probably fixed before the first real bits of ransomware came around.
at this point if you don't have the patches it's neither the NSA's nor Microsoft's fault, it's yours.
As you should well know, there are systems that are difficult to patch for various reasons. Had MS been alerted to and fixed these bugs a couple of years ago, some of those machines wouldn't be a problem now. Had it been a decade or more ago, even most XP systems would've been fine.
Yes, those who have refused to patch because "I don't wanna" are largely to blame for their own misery. Those who cannot patch because of other more technical reasons, however, may have the NSA to thank for their misery. Depending on how long ago the NSA knew of this stuff (probably in an article I haven't read or have forgotten).
1 If I got the wrong version of IE, please mentally substitute the correct one.
I agree with blaming the Americans, but not the NSA... if Microsoft had done their homework well, none of this would be possible! Let's not forget that the attack vectors are all Microsoft's doing. IF they wold concentrate on putting out better software instead of shiny software or bloated software, none of this would occur. Yes, this would slow down the pace of innovation in the software industry, but it is getting to a point that we need less innovation/new features and more stability/security. We have become too accustomed to the quick release-fix it in an update cycle. These are the consequences.
Let's not forget that the attack vectors are all Microsoft's doing. IF they wold concentrate on putting out better software instead of shiny software or bloated software, none of this would occur.
You can only patch bugs you know about. You can only know about bugs by discovering them during testing, or by someone else discovering them and telling you about them. MS did patch this stuff once they learned of the problem, but the NSA should've spoken up the moment they found the flaws. The NSA, as I understand it, is an organisation with a job to protect the data security (and the interests of) US citizens and corporations. By covering up this flaw, they've failed in this regard in many ways, not the least being the amount if ill-will that has increased towards the US and her citizens as a result of their actions.
MS could've done better, sure - but their closed-source doesn't quite have the benefit of well-intentioned interested parties looking over it for things to improve, which is a big help at times to those in the Open Source camps. Every programmer leaves bugs in their code, many found because they stop compiling, many more found because of an obvious flaw during execution, and some that lie hidden for decades because a) no one thinks of the test that would find them and b) nothing happens in the wild to trigger the flaw.
Writing software is difficult. Fixing bugs is difficult and a pain. But building test rigs that can catch every bug? That's incredibly hard, and no one has managed it yet. Though that said, I understand some basic testing tools would've found the flaw in SMB1?
it is getting to a point that we need less innovation/new features and more stability/security. We have become too accustomed to the quick release-fix it in an update cycle. These are the consequences.
That I agree with you on. I'd much rather computing be a few years behind where we are now, with the advantage that some of the painful talks I've had to have with people over lost data (eg kids photos) would never have happened.
And here is the rub; in Australia it illegal to write or even posses the source code to a computer virus unless there is a legitimate reason. By writing virus code that has entered the country the have broken Aussie law - in Australia, which gives cause for a legal sanction.
So if we had the identities of the NSA staffers who wrote this stuff, they can be charged here, just as Cardinal George Pell has been. The USA and the Vatican are both nation states.
Wait, so this means you can't use tools like Metasploit in Australia?
Kali Linux?
How do they red team and penetration test networks without exploit code?
I think this might actually make Australia a target rich environment if anyone decides to look in that direction.
Are offensive security sites blocked in Australia?
The real blame goes to... people continuing to use Windows.
But please, do continue so that we can enjoy Linux tranquillity... because you know what happens when there are too many Linuxes like Android: malware, viruses, etc...
I'm so glad Linux desktops keeps around 2% so that not to attract too many attention!
"The real blame goes to... people continuing to use Windows."
Oh, how cute. A Linux fanboi in the wild.
Just this month a South Korean ISP had 150 Linux servers hit with ransomware and paid over a million dollars to get their data back.
https://www.onthewire.io/south-korean-isp-nayana-pays-1m-ransom-to-decrypt-servers/
So much for not attracting attention.
Nothing to see here, move along.
A silly fanboi, sure. The example you gave illustrates an analogous scenario to the subject of the article. I think the common factor is that system administrators do not exercise due diligence, or companies do not allocate sufficient resources, whether human or financial, to the maintenance of secure networks and servers, etc.
In the fanboi's defence, though, I think that there is less work involved in securing Linux based servers. All operating systems have vulnerabilities but some seem to be more vulnerable to exploitation than others.
Not really.
First, this malware only uses EternalBlue as a last resort to spread.
Second, whoever wrote EternalBlue did not create the vulnerability, they just found it and wrote an exploit for it (Every persistent threat organization out there has zero days like this in their pocket it isn't like this was a unicorn).
Third, Microsoft released a patch for this over a month ago and it is obvious that a large number of entities are not applying patches in a timely manner. When I do penetration tests on networks using Metasploit, the first exploit I throw is MS08-067 because 50% of the time, it wasn't patched properly. that is an exploit that was REPORTED publicly in 2008. It is almost 10 years old and you can still find machines vulnerable to it in the wild.
Why not blame ShadowBroker for releasing the exploit?
Why not blame shoddy Information Security practices that don't train users to use a little internet hygiene before they start clicking on links in emails they aren't expecting?
Why not blame network engineers that deploy their networks in a flat topology so that any machine can reach any other machine?
Why not blame software companies that don't secure their networks and allow malicious actors to plant malware in their patch catalogs?
Why not blame system administrators that don't disable password caching so that administrator hashes aren't left behind on a machine when the administrator logs out?
There is plenty of blame to go around. Have some.
It still amazes me how people are using bog-standard OS variants for critical tasks. Maersk for their global shipping operations and whomever is in charge of monitoring radiation at Chernobyl. Sure, there's likely some forced aspect of software X only runs on Windows but for massive companies with real market power and scientists I cannot see why you wouldn't enforce the usage of a hardened OS suitable for the task. Some suitable Linux variant springs to mind.
How many times must an OS fail in critical applications before the right people have a fucking light bulb moment?
Yet another reason to have good backups. It's good if you can stop it from getting in, in the first place... but most times, for most places, you'll need a recovery model.
Who is the Data Protection Advocate at your company? Maybe get to know them.
How does your business plan on recovering?
For this sort of fast acting malware backups are great, but there are plenty out there that silently do their work for weeks before activating, in which case you are screwed.
But yes, backup 99% of the time will bail you out.
Getting the company to agree to buy a few petabytes of storage, now that's a different matter.
"but there are plenty out there that silently do their work for weeks before activating"
Do you have a citation for the frequency of this? It keeps being raised but all the reported outbreaks seem to be pretty well instant or nearly so. According to TFA this one spreads for an hour before kicking in but that's very different to working for weeks.
"Do you have a citation for the frequency of this?"
The obvious example is Stuxnet, which was released months in advance and did nothing until a precise date. But there's plenty of others; many infections rely on a change in their C&C server's output to tell them to activate (unlike the deactivate message used for Wannacry) or are post-dated. Or consider Botnets, many of which lie dormant for months until activated for use.
Stuxnet springs to mind. But that's not a common attack. Maybe time-bombed ransomware - like https://www.reddit.com/r/techsupport/comments/373wk0/locker_virus_similar_to_cryptolocker/. It still seems unusual. Although the long-lived, stealthy characteristics do represent a great ransomware implementation - high infection rate, long incubation period, short duration and high mortality (payback).
STUXNET and aged botnets are examples of long term attacks however 99.9999% of ransomware attacks are geared towards generating a fast profit. Sitting and waiting for long periods of time doesnt fit the model.
This means if you have good, offline backups, then there is a fair chance you can recover from the ransomware attack to at least a known good point in time.
There are botnets in the wild that are just sitting there waiting for the zombie master to issue a command. Some of them have been there for a long time. Here is one that was built in 2013 and was only recently discovered. 350,000 bots.
https://www.technologyreview.com/s/603404/cybersecurity-experts-uncover-dormant-botnet-of-350000-twitter-accounts/
"For this sort of fast acting malware backups are great, but there are plenty out there that silently do their work for weeks before activating, in which case you are screwed."
I guess in that case the size of your incremental backup sets would be a pretty good canary for a ransomware attack.
Competent enough coding to produce chaos on its targeted networks but not spread (by design) and a trivially easy way to stop the ransom from being collected, locking the computers permanently. Almost like the ransom parts were cobbled together as an afterthought, rather than their ultimate objective.
Conducted pre, rather than during, a public holiday.
An incompetent team of ransomware writers or a very competent team seeking to a)Cause substantial disruption to Ukraine or b) Cripple competitors of certain software businesses. c)Eliminate the evidence for a large scale fraud
This would mean everyone else is merely "collateral damage," or a free pen test that they failed.
Not incomptetent at all. They were good enough to put the attack together and it apparently works frighteningly well against a large number of targets.
So, now we know they're not incompetent and also not interested in the cash, the only other explanation is that they wanted it to be a loud, flashy, obvious attack, and also wanted it to become readily apparent that it's not about the money.
This isn't a ransomware attack, it's an intelligence operation which happens to be taking place using computers. There's a link in the article to The Gruqc's medium blog. He really knows his stuff and is very good at analysis of this type of thing.
There are some odd things though. Assuming every line of code changed from the original Petya was done for a reason then why so obviously limit the file types it targets? Possibly they identified a target list and narrowed it down to those without thinking that leaving the original list in place would achieve the same goal and serve to obfuscate what they were specifically after.
Another possibility is that the list was deliberately left as a message to the actual target (which could be anyone caught up in it, maybe Maersk were the original target and the other hits were just to spread the panic and confusion around). That's the problem with this sort of thing, it's moved away from hacking/script kiddies/cybercrime and attacks like this are increasingly used as COINTELPRO or PSYOPS operations.
Might be reading too much into it. The filetype may have been chosen for speed of delpoyment. A sliding scale of what to encrypt first would have been best.. but just xhoosibg the juciest targets is quicker and easier. Especially as searching first would tip of more virus scanners.
you say fishiness, I say red herring, maybe. After all, wasn't it our own glorious democracy which produced the gems of "It's now a very good day to get out anything we want to bury." Perhaps the bad guys took it to heart, with a twist? Or a double maskirovka, by our Russian "friends"?
@John Smith 19 - The whole thing has more of a smell of an inside job in the Medoc software company. My own list of suspects would start with recently terminated sys admins.
The activation date is simply explained by this is targeting businesses, whose PCs would often be shut down on a holiday. The file types targeted also point to businesses as the target, since MS Word documents are going to be more common and more valuable than photographs in most cases.
A current or former sys admin may have access to the update servers, and he may also have the contacts in the Ukrainian hacker community to get a virus commissioned for the job. He wouldn't however necessarily be familiar with the money making end of the ransomware business, and under estimated the effort required to put together a robust payments system (as many, many, software developers do when it comes to legitimate business).
There are loads of incompetent virus operators and spammers out there. I get loads of spam where the sender didn't configure their software properly and sent a blank template or forgot to attach the virus payload. We don't need to over-think the whole issue. If the Russian state were behind it, I would be very surprised if they fell short of making a convincing effort by not getting the payments end of things set up properly. They would in fact probably simply outsource the whole job to a criminal virus/ransomware gang who were well versed in how to do things properly end to end and who would simply collect the money as usual.
The balance of probabilities suggests a botched criminal inside job by someone who had access to the means of distribution but wasn't experienced in running a ransomware operation.
" My own list of suspects would start with recently terminated sys admins."
Or any other techy from there.
I wonder whether the private keys were being emailed in plain text to that email box. Of course with it closed down maybe victims are getting their email bounced back to them.
My money is on the FSB (Cozy Bear, APT29 IIRC) using one of the criminal hacker gangs they work with rather a lot. Intentionally crippling the ransomware end of things was by design. Be interesting to see what gruqc says further on. [He's brilliant at these types of analyses.]
"So it will be intriguing to witness how quickly these firms recover. Or maybe they just practice exemplary backup procedures?"
Rosneft apparently managed to recover so quickly that it had no downtime whatsoever, and there was no impact on any of the productive assets at all. Oh, wait, I'm sorry, that should read "Russian state-owned oil company Rosneft"... Not that that seems oddly suspicious or anything.
Heterogeneous computing.
I know Windows is allegedly cheaper to support the OSX or anything else, but I'll lay odds in the affected companies the MAC/Unix Systems are still going, and lets face it for most things now, we only need a browser, so why not mix up the client base and give people the right OS for the job. Only need eMail and Browser, a Chrome Book, Media, Mac, General Power User, Windows, Out and about, Android or iOS.
In the data centre, lets have Windows, Solaris, AiX et al, again. I bet it's cheaper than having your data centre taken out. Remember security is strength in depth and Heterogeneity, you can make a homogeneous system fool proof secure, but not damn fool proof.
"But not all systems are fragile, like Windows."
I've posted this before:
https://googleprojectzero.blogspot.co.uk/
I refer you to the last paragraph:
"Conclusion
Right now the Linux kernel has a huge number of poorly tested (from a security standpoint) interfaces and a lot of them are enabled and exposed to unprivileged users in popular Linux distributions like Ubuntu. This is obviously not good and they need to be tested or restricted."
My conclusion. Windows appears fragile because it is the target of attacks because its the most popular. If other OSes were more popular they would be the target and a ton of secuirty holes would suddenly appear.
@Mark
You do realise, don't you, that there are a multiplicity of other OSs and of CPU architectures? There are also other forms of networking semantics than SMB. Each OS, CPU and networking technology you introduce into the mix raises the difficulty for an attacker more or less exponentially. As the system becomes more difficult to attack even Windows systems gain from herd immunity.
Agree completely. Its absolutely true that having 90% of the world on the same OS makes life easy for the attackers.
My point was more around the perception of Windows being fragile is probably to do with it getting attacked more than anything else. I wouldn't argue that it hasn't got security flaws but I imagine most other things do to. Linux was just an example.
@Doctor Syntax
"Each OS, CPU and networking technology you introduce into the mix raises the difficulty for an attacker more or less exponentially."
Your statement is logically sound, but the concern I'd have is that the effort required to support and maintain such a system would also increase at the same rate. Furthermore, unless each of your Sys Ads fully understood the architecture end to end, there might be a chance that they would unknowingly provide an exploit or attack vector by misconfiguring a segment of the system.
That is assuming they don't just get lazy and build their own back doors and loopholes to make their lives more convenient.
As a way of illustrating the point, consider the arbitrary password requirement rules that many large enterprises still force on their staff, regardless of the advice from SME's. If you make your password policy so onerous that your end users resort to writing their passwords on post-it notes, you may as well have not bothered. The same could be said for other aspects of IT security.
If you make your password policy so onerous that your end users resort to writing their passwords on post-it notes, you may as well have not bothered. The same could be said for other aspects of IT security.
As long as unprivileged users (and non-users, including cleaners and janitors) are barred from entering areas where one might find those passwords on post-its, or, probably better, in an notebook that can be shut and put away under lock and key (and not taken to the toilet and left there) when there's no need to use it, it's not a bad choice.
Try reading a password that's on a paper to the side of the monitor of whatever system you've just logged into remotely.
Of course, you don't write it on the whiteboard or on a labelwriter label that's visible from outside the room, Especially not when a TV crew comes around.
This is why you have a security team that is separate and autonomous from anyone else that runs and maintains the network.
System and network administrators install patches and software/firmware upgrades and the security team runs vulnerability scans to ensure that the patches and upgrades are applied properly.
The security team is also responsible for monitoring access to VPNs and external access to the network. This prevents administrators from opening accesses as a matter of convenience.
In a separate reporting structure, you have an Information Assurance team (team in both cases can be a single person). The information assurance team is responsible for publishing policy and auditing the security team.
The security team would report to the CTO/CIO and the information assurance team would report directly to a board of directors or executive management committee.
This keeps everything separate so that it is more difficult for an insider threat to cause havoc.
As for the password issue, the only real solutions are MFA or password vaulting.
Mark 110 - classic straw man.
> In the data centre, lets have Windows, Solaris, AiX et al, again.
Who even mentioned Linux?
Of course it's understood that Linux is untested and untrusted, it's why the poster didn't mention it in the list of what to put in the data centre. And I'm sure windows was only listed as a concession because in the real world you can't exclude it entirely.
"malware writers *would* cater for all systems"
It raises the bar for them having to deal with all systems. It wouldn't just be a matter of recompiling the same code.
Also heterogeneous systems can have different modes of operation. For instance drop the idea of using a browser - or anything else - to apply a GUI to your server-based application. [Pauses to allow millennials to stop hyperventilating at the thought of a GUI-free application.] Now you have an old-fashioned terminal application that can be run via a link with the semantics of an RS-232 link. That really raises the bar on trying to get an infection back from a PC to the server.
"for most things now, we only need a browser"
This just isn't true, though. There's a great many industrial control devices which only run on Windows - in fact, which only run on obsolete versions of Windows that are out of support. Exactly the kind of devices, in fact, which a lot of these Ukrainian companies in the power sector will be relying on.
I used to support Schelling saws for a major plastics company in the UK. These saws are designed to slice big blocks of plastic into thin sheets, cost £250k each and are the size of an Olympic swimming pool. They only work with Windows XP. No Linux, no OSX, no silly browser-based bollocks. Just a fat client Win XP box.
When I worked at what used to be ICI's head office in Manchester, where most of the staff were engaged in trying to come up with a new shade of green paint, the machines that controlled the centrifuges and pigment analysis needed to be run on Windows XP. There was no browser involvement, and using more modern versions of Windows was impossible because the drivers were written so badly that anything after Win XP regarded them as unsafe.
And this is the case is a great many areas of business. We use Sage for our accounts, for example; several versions of Sage (possibly all, in fact) flatly must be installed locally on a fat-client Windows box. There's 800,000 businesses using Sage in the UK alone, and all of them are using it on a windows box because they don't have a choice. I now work with CAD users; the idea that they'll ever be performing their work remotely or in a browser is laughable. The local C++ clients they're using are getting bigger, heavier and more complex every year.
There's no denying that monocultures are bad, but honestly the illusion that there's a choice in the matter because a few applications can now be delivered via the browser is just that - an illusion. Lots of core software still cannot run on virtual machines, cannot be run through the browser, or cannot be run remotely at all, and is unlikely to ever be able to, which makes implementing a heterogeneous environment much, much harder in the sort term - it'll take decades of refreshes before there's anything like enough diversity to make a difference.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
