1

tl;dr: How secure is a combination of a sort-of hardened Google Chrome + Microsoft Enhanced Mitigation Experience Toolkit 5.1 against browser-based threats that I do not expect to be highly targeted & sophisticated? Put another way, how realistic is it that a threat is going to exploit a vulnerability against a fully-patched Chrome and get out of Chrome's good sandbox in spite of EMET's added protections?


So not too long ago I took on a client who operates a small chain of businesses in my city. At each business location, there's a small network running 2 or 3 machines in a home/home-office configuration. (The small HQ location has a domain, but client has declined suggestions to join the PCs at the other locations to it. So, that's pretty set right now.)

Each of these separate locations has one PC on which quite sensitive financial information is processed. When I was taken on, there were, of course, tons of security problems with these sensitive machines--on all the clients PCs, actually--and with the various networks at each site. After lots of work, and plenty of persuasion with the company's HQ manager I'm working with about why it was important to let me address this issue and that issue, things are now in fairly decent shape. Got good segmentation from the sensitive machines in place, got every piece of software on every PC/device that I know of either patching properly or uninstalled, etc.

Except...

On these machines where the sensitive financial info (not credit/debit card info, but of similar sensitivity) is dealt with, managers at the locations really like to check their company Gmail accounts (in-browser) and do some web browsing here and there; it's become part of their workflows by now. I advised the HQ supervising manager that this was really, really not a good idea due to the phishing as malware-delivery vector risk, drive-by browser stuff, and so forth. But at the end of the day the decision was "Well, I think they need to use those computers for email and stuff. But try to make them as secure as you can."

Sigh.

Anyway, I'm thinking about the potential for doing something more involved (using a VM with a guest hardened Linux flavor & browser, or maybe something with app virtualization on a remote server), but the temporary setup I put in place as a Gmail-checking & web browsing security solution is considerably simpler: Google Chrome with ublock ad-blocker installed, Flash turned off for all sites except Gmail and GDrive, and no other plug-ins (ie. beyond Chrome's built-in Flash) even installed on the machine. Backing up Chrome's sandboxing & other security features I've got EMET 5.1 installed plus a serviceable anti-malware solution (for whatever they are worth). I have disabled Internet Explorer, no other browsers are installed, and a policy change e-mail went out on Friday prohibiting any attempts to install or use any other browsers on these machines.

(FYI, No Java, no Reader/Acrobat, no office doc suite or viewer, or any other very commonly program targeted programs are installed. The PCs where the sensitive operations occur are running either Windows 7 or 8.1. They are ultimately connected to Internet access because they must interface with a certain financial transactions service.)

Now, obviously the highest-security course of action would be to set these machines aside solely for sensitive info processing and get some new machines/devices (they are dirt cheap these days) for email and web browsing. (Segmented on the sub-networks away from sensitive operations, of course.) But let's assume that doesn't happen. Let's also assume, just for purposes of focusing on one issue here, that the company managers actually use only the "temporary" Chrome setup I've outlined above and don't break the new policy by trying/succeeding in installing Firefox or another browser or changing Chrome's settings. (They are running with user accounts now, but they do, alas, have access to admin passwords for the machines. "For emergencies when they can't get ahold of HQ." )

Anyway, assuming those things, how much do I/they actually, realistically have to fear from browser attacks like phishing emails linking to sites with browser exploits, from malvertisements, from drive-by browsing attacks, etc. Attack code on a site or in a message itself would have to use a zero-day vulnerability (or, at most, a vuln only a few days past announcement, given that Chrome would probably be used/open, and thus have its auto-updater active, almost every working day), evade the anti-exploit protections of EMET, and breach Chrome's well-regarded sandbox to even get to user privileges. For safeguarding the systems of a company that (in my assessment) is pretty unlikely to face any well-targeted, really sophisticated spear-phishing attacks or the like, what level of real security do a hardened Chrome browser + EMET provide? Should I lighten up a bit and just let this stop-gap setup become permanent?

mostlyinformed
  • 2,715
  • 16
  • 38
  • 1
    I know your question is about the robustness of your setup. However, I believe you biggest attack vector against non-technical users (financial managers) is **spear-phishing** and or **watering hole attack**. It is more likely a user gets tricked to add a vulnerable plugin, disable a security control, or pass on their credz than targeted by Chrome 0day. I would emphasis more on regular user awareness training. – Dr. mattle Sep 20 '15 at 22:25
  • 1
    Yeah, the user education & awareness aspect is definitely one which needs significant attention. So far, most of my time/effort has gone into cleaning up urgent technical messes (active malware infestations, years worth of ancient/unpatched Java plug-ins on every PC, etc.), but definitely I need to start shifting more focus to the security policy-issuing side and, more importantly, to doing some more in-person work with the managers actually using these machines. Thanks. – mostlyinformed Sep 21 '15 at 03:35

1 Answers1

2

against browser-based threats that I do not expect to be highly targeted & sophisticated? Put another way, how realistic is it that a threat is going to exploit a vulnerability against a fully-patched Chrome and get out of Chrome's good sandbox in spite of EMET's added protections?

First, I consider getting the chance of an non-targeted attack (i.e. no APT) to get out of the sandbox of a fully-patched Chrome not that realistic, especially because you reduced the attack surface further by installing an ad-blocker and thus reducing the risk caused by malvertisement.

But, I don't consider breaking out of the sandbox the only browser-based threat. For lots of browser-based threats the sandbox does not matter at all, for example:

  • CSRF attacks against which might attack the local router and change the DNS settings for further attacks, see How millions of DSL modems were hacked in Brazil....
  • Scareware, alleged essential plugins or alleged software updates and other tactics use social engineering to install malicious software and thus break out of the sandbox with the help of the user.
  • Vulnerabilities in the web applications itself like the typical Cross-Site-Scripting attacks can be used to hijack the users identity. Again, no breaking out of the sandbox is needed for this attack.

So what you propose is a setup providing a good initial security but still leaves several attack vectors. You should still educate the user about the other risks like social engineering attacks and show how to reduce the risks further, like using another browser/browser profile, VM or even different hardware for sensitive tasks like online banking. You should also make sure that all the other systems in the users environment are hardened against web based attacks like CSRF.

Also, some sites require users to widen their attack surface because they will not work without ad blocker. Thus you need to teach users how to deal with those sites by teaching them about the risks of malvertisement and how one can unblock only specific sites in the ad blocker.

Mathieu K.
  • 139
  • 7
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Hmmm, you make some very good points. I hadn't thought much about CSRF threats here, but now I definitely see your point (I have already done significant work to harden routers against internal-side attacks, but some is left to do.) And I'd definitely say that so far the prime motivating worry for me in this case has been of an attacker achieving code execution on the sensitive PCs (through means like evil email attachments, links to malvertisements, so forth) and dropping a keylogger, memory scraper, etc. But maybe I do need to pay more heed now to subtler threats like cross-site-scripting – mostlyinformed Sep 21 '15 at 04:18