Email security: We CAN fix the tech, but what about the humans? Last month’s Mr Chow ransomware attacks serve as a timely reminder that security should be at the top of any business IT strategy. Ransomware is on the increase, at least according to the FBI and while it is not all email borne, it is an example of how sophisticated hackers and criminals are getting with technology. Certainly …
Further than that a decent phish can easily craft an email that appears to be something the right person would expect. The only question is how much time & effort does the attacker want to put into the job.
Prevention is important but DETECTION is a must. Assume a determined attacker will succeed - because they will! - and start focusing more on identifying the attack faster and blocking extension.
First quit training them to open up attachments and links in your emails the other 99% of the time.
IT and HR were the biggest offenders on my last job, and quite often to remind me to take security training, linking the online test and attaching the educational materials as a word file.
This is my tip and it's easy to set up. Most good users send plain text equivalent or you can get a "mess" but with something readable. You can see the actual links are from www.twesbarcoyd.co.ru and tracking pixels also show in just their HTML glory.
There are a few senders who don't make the effort and you see nothing. And where you do trust the sender (and their links) you can read in formatted form.
Nothing is fool proof but it adds another layer to the existing processes.
Agreed - I send in plain text, and I interleave my replies with quoted material as appropriate, rather than reply at the top.
What amuses me, though, is that I sometimes get replies to long, complicated emails from clients who use HTML and normally top post, but who clearly see the need to reply in a similar manner to the way I do when replying to them. They still use HTML, but insert their replies at appropriate points in the email, with a note at the top along the lines of "my replies are in red below".
New dogs trying to teach themselves old tricks.
Mobile email has always made me despair. You cannot usually view the headers - easy on the desktop - and now on iOS with '3D touch' clicking a link and holding previews the full page, where previously it simply showed the link text for copying, the easiest safety check.
I had Eudora on the Palm 15 years ago that at least showed the headers. We get worse at this, not better, while the threats go the opposite way.
Sound advice that should be drummed in starting from kindergarden.
But isn't.
If you do this for a living plan for it happening where "it" is ransomware, data extraction, fraud etc.
No plan survives contact with the enemy but you at least have a framework to guide you.
As far as I can tell from the article, fixing the tech seems to amount to nothing more than spam filtering. There's a good deal more that tech can do. One would be to sandbox email handling so that ransomware can't get at the user's files or gain privilege to install keyloggers or whatever. Another would be to verify message source. We have a system which was built on the premise that people could be trusted and put it in the hands of those who can't and haven't really considered what has to be done to rectify that situation.
"There's a good deal more that tech can do."
Not really. What you can do, they can UNdo.
"One would be to sandbox email handling so that ransomware can't get at the user's files or gain privilege to install keyloggers or whatever."
Java was designed with a sandbox and look where it is now. Fact is, sandboxes can be ESCAPED and routinely ARE escaped Even hypervisors are under attack. We're also seeing e-mails that can attack even from plain text mode, even from the preview window. What next? e-mails that pwn you (or your hypervisor) on download, before you even have the chance to see it?
"Another would be to verify message source."
Not much good when the attack came from a pwned machine. The address would likely already be verified if not an insider.
"We have a system which was built on the premise that people could be trusted and put it in the hands of those who can't and haven't really considered what has to be done to rectify that situation."
The ONLY solution is to REbuild the ENTIRE Internet from scratch, using a basis of DIStrust instead. But that would break a lot of things, not the least of which being the anonymity that allows whistleblowers and the like to speak their minds without threat from an oppressive State. Meaning a potentially disastrous unintended consequence.
But the point is it doesn't really make things harder. If you can go AROUND the security measure (by, say, using privilege escalation) then it becomes just another hoop to jump, and hoop jumping tends to hurt users more than they help because they start to find ways AROUND the hoops. That's why houses only have ONE dead bolt typically.
"by, say, using privilege escalation"
Here's one part of the problem, the notion that there are users or programs which have more privileges than others. So it, for instance, I have root privilege I can encrypt anybody's files.
I used to work with database servers where the server had sole control of an area of disk space in that only the server read or wrote from the disk because only it had the algorithms for the storage structures. Any program which needed access to the data had to do that through a client/server relationship.
Now running under, say, a Unix system this isn't perfect.
Firstly there's no mechanism to verify the client that makes the request is allowed to do so, the only security is at the user level so a rogue program running under the user's ID could wreak havoc.
Secondly although the disk might be allocated to a server ID and group with 660 permissions there's nothing to stop a rogue program elevated to root from trashing the whole disk area.
This sort of client/server relationship between processing and storage could be applied as a basis for securing data.
So there are a couple of things to look at in terms of OS architecture.
One is to provide authentication IDs to programs as well as users so if user fred's office-suite program wants to write a revised version of his masterpiece to disk it has to call the server and there is then a mechanism in place to verify that the caller has both fred's authorisation in order to overwrite* an existing file of fred's and office-suite's authorisation to call the server. This, of course, depends on some mechanism such as code signing to verify that the office-suite can be installed with the correct ID. There could be additional safeguards such as the server verifying that the file actually has the structure that's expected - if, for instance, it's supposed to be an OpenDocument file it should have the structure of a zipped file containing several XML documents which are valid according to the appropriate schemata. This verification mechanism might even come into play when the office-suite is passed an alleged office file from the email client**.
The other is to not have that omnipotent root. There needs to be a disk space manager that can dole out a portion of space to the server. That manager doesn't, however, have to have the rights to read or write to that portion, nor does it have to have the rights to set up user or program IDs. It might even be the case that such a manager can only be active when booted into a safe mode.
Do we sacrifice some operational convenience for this sort of OS? Maybe, but it's arguable that some of our woes are the direct result of sacrificing security for convenience. The balance is wrong and needs to be rectified. Id be surprised (assuming I'm still here!) if we're still using such intrinsically unsuitable OSs by the end of the next decade, and probably a good deal sooner. Note that I regard Unix-style as well as Windows-style OSs as intrinsically unsuitable.
* Of course it might not overwrite, there might be versioning in play.
** If the user stores copies of emails locally there will, of course, be a separate server with its own disk space for this purpose.
"The other is to not have that omnipotent root. There needs to be a disk space manager that can dole out a portion of space to the server. That manager doesn't, however, have to have the rights to read or write to that portion, nor does it have to have the rights to set up user or program IDs. It might even be the case that such a manager can only be active when booted into a safe mode."
SOMEONE has to have access to it or it's useless; the attacker just poses or takes over that someone. Plus if there's only one non-root way in or out, what happens if that way gets hosed (including any and all backups--think Murphy)? You end up with a lockout situation, and if that locked-out area has critical data, you can't just erase it and move in, either.
"Do we sacrifice some operational convenience for this sort of OS? Maybe, but it's arguable that some of our woes are the direct result of sacrificing security for convenience."
And convenience trumps security 8 days a week. Who cares about security if the job doesn't get done? The job ALWAYS comes first because your job (and the business) depend upon it first and foremost.
PS. As for Qubes, credits to milos a hypervisor attack pwns the underlayer before long.
Firstly there's no mechanism to verify the client that makes the request is allowed to do so
Maybe not in Unix, but Linux permits this by way of SELinux.
Secondly although the disk might be allocated to a server ID and group with 660 permissions there's nothing to stop a rogue program elevated to root from trashing the whole disk area.
Again, SELinux sorts that out.
The other is to not have that omnipotent root.
You know what I'm going to say, don't you?
Russell Coker used to publish the root password to his server on his website. And allowed root logins over ssh. Yes, you could log in to his machine as root. No, you couldn't do anything special with that root access...
Vic.
"One would be to sandbox email handling so that ransomware can't get at the user's files or gain privilege to install keyloggers or whatever."
Java was designed with a sandbox and look where it is now. Fact is, sandboxes can be ESCAPED and routinely ARE escaped
One quick solution is to not allow anything in email to be executed. S/W should be properly installed - with confirmation from the user - before it can execute. Something more drastic would be a very different OS architecture so, for example, your ransomware can't overwrite your office suite files because the server which is the only thing that can actually access the part of the disk with those files on it only responds to the office suite programs.
"Another would be to verify message source."
Not much good when the attack came from a pwned machine. The address would likely already be verified if not an insider.
The pwning of the machine is, of course, a symptom. There's certainly an element of "if you want to get there you don't want to be starting from here" about the whole problem.
But the banking spam, for instance, is very unlikely to have come from a pwned machine in the bank so it should be perfectly possible to bounce that as soon as it's presented to the recipient's server. The fact that this would also take out the bank's 3rd party marketing spamming agencies is an added advantage.
The ONLY solution is to REbuild the ENTIRE Internet from scratch, using a basis of DIStrust instead.
Not the only solution. What's required is to build trustable services on top of it. That wouldn't preclude the continued existence of untrustable services.
"One quick solution is to not allow anything in email to be executed."
They'll just find an exploit and go AROUND it, say by latching to another process.
"Something more drastic would be a very different OS architecture so, for example, your ransomware can't overwrite your office suite files because the server which is the only thing that can actually access the part of the disk with those files on it only responds to the office suite programs."
Then they just go for the server instead. There MUST be a way to ACCESS it, and if you can ACCESS it, someone else can hack it.
"But the banking spam, for instance, is very unlikely to have come from a pwned machine in the bank"
Meaning that'll be EXACTLY where it comes from.
"Not the only solution. What's required is to build trustable services on top of it. That wouldn't preclude the continued existence of untrustable services."
No, because trusted services on an UNtrusted medium open you to Men in the Middle. It's the Weak Link problem. You have to secure the ENTIRE thing, end-to-end, or the weak link pwns you.
Put it this. In today's world, the operative statement is "Don't Trust ANYONE...Not Even Yourself."
Look at Qubes OS... you can have an untrusted (red-windowed) mail programming launching the office file with an untrusted (red-windowed) Office. Those untrusted pieces of software and attachment would not have rights to mess around with files on the computer or the server. You could be running a trusted (green-windowed) version of Office editing another file and they would be separate. Any malware in the attachment would not affect it.
Indeed, the use of things like apparmor to limit just what areas the email client can read/write to is one thing, but obviously gets in to problems in usability given most users want to be able to save and attach from their normal document areas. Still, it avoids your SSH keys being emailed out by mistake...
The other thing that can help a bit is to deny execution to user-writeable areas, either my Linux mount options or windows ACLs. Can be inconvenient for software developers and won't block all scripting or similar attacks, but its a start.
Most of all stop word processors, etc, from executing bloody scripts :(
As far as I can tell from the article, fixing the tech seems to amount to nothing more than spam filtering. There's a good deal more that tech can do
Indeed. I received an email which, although it was from a trusted source was clearly malware as it threatened me with being cursed. Luckily it must have originated from someone like those stupid scammers who hard code an encryption key into their ransomware as it included a final paragraph that said I would be fine as long as I forwarded it to ten people within seven days. I have already almost finished a python script to automate this in the future so no more dependency on spam filtering for me thank you very much.
"I received an email which, although it was from a trusted source was clearly malware as it threatened me with being cursed. Luckily it must have originated from someone like those stupid scammers who hard code an encryption key into their ransomware as it included a final paragraph that said I would be fine as long as I forwarded it to ten people within seven days."
Are you sure it wasn't a simple invoice?
Another would be to verify message source
SPF and friends have been around for a long time - the problem is that far too many people simply don't care. Publishing a record goes a long way[1] towards preventing spoofing, but far too many domain administrators will gladly write enormous essays about how it takes too long rather than add a single TXT record to their DNS (which would take them just a few minutes). People are actively hostile towards protecting their own assets...
Vic.
[1] SPF cannot be perfectly effective until everyone uses it - but that doesn't mean that the partial effect we have already doesn't make a huge difference to the problem.
wrong tree
it's the OEM software makers who need to be guided -- either by free market competition -- or by government regulation -- into providing secure software and authentication
the "people" -- will gladly embrace it
but where the makers want to promote selling above all else everything must be "easy peasey"
and it's easy-peasey for the hackers as well; "sophisticated hacks" and "state sponsored attacks" -- are just white-washed excuses for sloppy work.
Throw in the fact that cloud-based email services are growing and you can see potential for greater damage if businesses don’t act." ... "“The risk with cloud-based email is the same as one of its major benefits - it's easily accessible from anywhere in the world,”
So cloud-based email is basically... email, then? More specifically, if that "accessible from anywhere" bit refers to more than just new emails, it's IMAP?
OK this is enterprise but there should be a trickle-down into consumer land...
1. Most attached documents don't need active code. As such they should go through a process where they remain intact from a presentation perspective but with all the funky active(read malware) stuff removed. As for executables masquerading as documents they should be binned a million miles away from the user.
2. Links in emails should be validated by the mail gateway and again when clicked using standard web security tools. They should be treated no differently to a link inside a web page. Usual reputation, anti-malware etc should apply
3. 'At risk users' should have sandbox based browsers that isolate the interaction with the web to keep the device safe.
Of course there's more to it but as such an 'efficient' attack vector and with decent user education at least a generation away email security needs to be a bit more than spam blocking.
"Of course there's more to it but as such an 'efficient' attack vector and with decent user education at least a generation away email security needs to be a bit more than spam blocking."
A LOT more to it. A malware could just attack and take over the e-mail client, no matter how thin or sandboxed it may be (sandbox escape and privilege escalation are common now), and use it as a springboard to other exploits. Same with malware web links. It'll probably use a Turing Test so that it passes validation checks and ONLY infects when it detects a human in control. And they can escape the browser as easily as the e-mail sandbox (after all, escaping a Java sandbox is easy enough, too).
As for educating users, didn't a comedian once note that you can't fix stupid? And suppose the Stupid is over your head?
My system is this - all attachments are removed from the email delivered to the users. If an email arrives with attachments and the user wants access then they can copy the email from their mail archive to their inbox.
Sure - this isn't perfect and it's a small hassle when .doc files arrive but 99% of the time the attachments are malicious - we're seeing tones in "invoice_1526253.doc.js" files these days.
All companies/corporations must digitally sign their outgoing email. A number (increasing number?) of email clients can handle this. This provides end-to-end integrity and assurance of origin.
Additionally clients need to be able to perform SPF/DKIM checks rather than hoping (in vain) that the ISPs MTA has done this. Companies then need to implement SPF/DKIM for ALL their domains which many companies don't do.
This will make it harder to impersonate legitimate emails but still requires an informed user and appropriate client software support. All the standards already exist and are used go some extent.
Actually not much will break and if you adopt soft fails initially then this will be further reduced.
Anything and everything on the Internet can be compromised. It's really about building a framework that supports defence in depth and therefore requires multiple compromises to subvert.
Still possible but at some point the effort required and the reduced returns will start to have an effect.
It's all about doing something rather than passively accepting it all. And the tools are there right now.
"Anything and everything on the Internet can be compromised. It's really about building a framework that supports defence in depth and therefore requires multiple compromises to subvert."
Which isn't viable because the bad guys only have to be lucky ONCE, then they can blast your whole works wide open. Plus multiple defenses tend to get met with escalations and bypasses: ways to beat multiple defenses simultaneously.
"Still possible but at some point the effort required and the reduced returns will start to have an effect."
A company's jewels are likely to be worth more than any amount of effort it would take to get them, meaning it's almost always profitable. It's like with spam: the investment is minuscule compared to the reward. That's why the 'Net's still full of Script Kiddies.
"It's all about doing something rather than passively accepting it all. And the tools are there right now."
So it's been claimed. But is it REALLY worth it in a Sword of Damocles world?
Companies then need to implement SPF/DKIM for ALL their domains which many companies don't do.
It's worse than that. Some companies publish stupid records.
I'm currently seeing spoofing attacks from domains that have multiple /24s explicitly permitted - that's never going to make sense.
But worse than that - there was a phase some months back where I was seeing many records ending in "+all" - thus explicitly authorising absolutely everyone. I contacted several domain owners to tell them about htis - not one replied, and not one changed their records. I actually modified my SPF milter to treat "+all" as "-all".
Vic.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
