A little bit of a change of tack today…I used to wear a security hat many years ago, so some recent news items got me thinking about some good uses of the DesktopNow software.
I assume a lot of you out there have heard of CryptoLocker – it’s the ransomware from hell, because the malware writers have finally learned how to implement encryption properly. It’s a choice between paying up, restoring from offsite “cold” backups (if you have them – many don’t) or facing possible total loss of all your data. It’s also an excellent discussion point for the merits of application whitelisting technologies – of which Application Manager is one of the market leaders, IMO.
CryptoLocker
If you haven’t heard of CryptoLocker, then here are some useful links discussing this evil beastie:-
http://www.dailydot.com/crime/cryptolocker-virus-ransom-bitcoin/
http://en.wikipedia.org/wiki/CryptoLocker
http://www.theregister.co.uk/2013/10/18/cryptolocker_ransmware/
http://www.channelregister.co.uk/2013/10/24/endpoint_security/
The key about it is the successful implementation of serious public key encryption – without the key, you’re more or less screwed. And if the encryption spreads into your networked and backed-up files, because you’re not using cold backups and/or maintaining multiple copies, then you may find yourself backed into a very nasty corner.
Of course, you could just pay the bad guys what they want – reportedly 13% of users infected are actually doing so – but I’m hoping people aren’t serious about this as a recovery method. Aside from the obvious fact you’re encouraging these sophisticated criminals to come up with more innovations that can cause this level of damage, how do you know they won’t add your details to a list of “marks that paid up” to more precisely target these kind of things in future?
Reactive AV
Although the major AV vendors are (now) doing good detection for stuff like this, there are a couple of issues with this “blacklist” approach.
a) You may have remote endpoints with network-connected files that haven’t received the latest AV updates, for whatever reason
b) Reactive AV is precisely that, and when new strains of the ransomware are evolving, there is a “window” during which you are vulnerable, because the new version has to be identified and added to detection
User rights management
Ensuring your users aren’t administrators won’t help you here – CryptoLocker doesn’t need admin rights to do its thing. Any files that a user has Modify access to are potentially vulnerable once it executes.
This is a good time to start thinking about monitoring your NTFS permissions too, because if an infected user has Write access to stuff they shouldn’t have, CryptoLocker may well spread to those files.
Backups
Even if you’re doing your backups properly (and you need to test your restore process too!), this means that you’re still vulnerable, to a degree. If the worst happens, you’re going to need to do a restore – and suffer from potential loss of data, even though it won’t be total.
Application whitelisting
The only way to be sure of stopping this Satanic creation is to prevent the damn thing from executing in the first place. Application whitelisting technologies – such as Microsoft’s SRPs, AppLocker, or Application Manager – are what is used to achieve this. However, the traditional implementations of this, particularly the Microsoft flavours, are not popular tools in business because they are inflexible and need regular maintenance.
AppSense Application Manager is ideal for this situation because it uses Trusted Ownership to remove some of the overheads associated with maintaining Software Restriction Policies – discussed originally here, and then in slightly more detail here.
Implementing the blacklist
According to the documented process of how CryptoLocker functions, it arrives either as an email attachment with an infected link, or alternatively via a botnet mechanism (spread by the Zeus trojan). Once in, it drops an executable with a random name into the root of the user’s %AppData% folder, creates a Run entry in the Registry to ensure persistence, and then searches a list of pre-programmed C&C servers till it can find one to connect to. After connection, it generates a public-private key pair and sends the public part back to the infected host.
To halt this thing in its tracks we’re going to function on preventing the execution of the random executable, as without this, the rest of the nefarious deeds can’t go ahead.
Application Manager should, if it is turned on with the default options, block CryptoLocker “out-of-the-box”. By default options I mean Trusted Ownership and Application Access Control turned on….
….and you need to make sure that the Everyone group is running in Restricted mode, as well as not inheriting any other execution mode from other Group Rules. For instance, if you put the Everyone group down as Restricted and the OTHER group as Unrestricted, a user who is in the OTHER group will inherit the Unrestricted setting, as the least restrictive set of permissions applies in AM.
Now, the user’s %AppData% folder should normally have permissions like these, where ownership is set to the current user…
…and where those permissions are inherited by subfolders…
….and if this is correct (which it will be, unless you’ve messed with the normal user profile settings), this is all you need to get Application Manager up and running. With SRPs, you need to explicitly disallow execution from the target folders to cover yourself (unless you’ve set the “only allow specified executables” policy, and that’s a nightmare to administer, believe me), but with Application Manager, you can activate the protection fully with a minimum of fuss. If a user drops the CryptoLocker executable in the %AppData% folder, Trusted Ownership will block it from executing.
Ensuring existing applications can work
Of course, this is all in an ideal world, where your applications don’t ever need to execute anything from folders outside of the normal scopes (%ProgramFiles%, %windir%, %systemroot%\system32, etc.). If you haven’t done the required discovery process, how can we make sure we just deploy an Application Manager configuration that can mitigate against this and similar malware, just until we have time to deploy AM correctly?
In this case, we’d need to turn off Trusted Ownership. This is not recommended in general, it’s specifically for a use-case scenario where you wish to mitigate against CryptoLocker quickly using AM without doing any application discovery or analysis. If you do take this approach, I highly recommend starting the application discovery and analysis phase so that you can take advantage of the advanced features of AM and provide yourself with a much more secure environment.
|
| The base settings to stop CryptoLocker in its tracks |
The settings above should also cover execution from the Outlook Temp Folder – but I’ve known people who actually redirect the Outlook Temp Folder, by modifying the OutlookSecureTempFolder REG_SZ Registry value, which is to be found at HKEY_CURRENT_USER\Software\Microsoft\Office\version\Outlook\Security, so if yours is redirected, you may want to prohibit execution from the redirected area too.
Note that preventing execution from these areas will also stop users running stuff like GoToMeeting and other content that they may actually need to execute to get things done. Luckily, in this case Application Manager will log up an alert to the Management Console and to the local event log telling you exactly what was blocked
However, if you’re concerned that malware like CryptoLocker may imitate software like GoToMeeting by mimicking the file name, you can secure yourself further by using other features of Application Manager to allow it to run, such as Trusted Vendors or Web Installations, but that’s a bit of a bridge too far for this particular post.
A quick demo
As we can see, execution is prohibited for the files dropped in the %AppData% folder, keeping users secure from any possible CryptoLocker infection – and more importantly, your business data!
Summary
The very basic CryptoLocker-stopping configuration is available for download here should you want to use it. Bear in mind this has most of the other security features turned off as it was intended for environments where Application Manager has not been previously used, and therefore which haven’t done any analysis. If you’re serious about getting value from Application Manager, you will need to do your analysis and bump up the security level. I will cover some helpful tricks to accelerate your analysis in a later post.
If you’ve already got AM deployed and working successfully with the default options, then you don’t need to do anything – Trusted Ownership alone will have protected you from the depradations of CryptoLocker.
Application Manager is a massive help in these sorts of situations because it allows you to provide mitigation with minimum fuss and management overhead, when compared to similar software. It should also, when configured correctly, allow you to stop just about all external threats. And you should take these threats seriously, because scammers and spammers are finally starting to get slick and polished. I’m not just referring to the implementation of encryption in this case – take a look at this email-borne malware that was unearthed recently. Would your users click on it? Would you? Application Manager gives you a fine-grained, lower-admin way of stopping this sort of stuff before it can cause problems. I consider an application whitelisting tool the most vital part of any defense-in-depth strategy, because it can head so many issues off without having to rely on signature updates and the like.
And finally – things like this piece of malware should remind us that security of your enterprise is a never-ending battle. Just when you think you’re on top of it, something like this has a tendency to evolve, and if you let your guard slip, it could certainly bite you where it really hurts. Application management is only one part of the whole security landscape – don’t neglect any of the others!
Share
