Securing a Law Firm, part 1: Securing Chrome

On a snowy day, late in December of 2016 I sat in a corner office of a local law firm with the firm's IT manager discussing the hottest topic of the week - ransomware. After a law firm down the road had been hit by a ransomware attack the partners were afraid. They were asking a lot of questions for which the IT manager had serviceable answers. I had my own questions in preparation for my practicum beginning in the new year.

Scribbled in various notebooks and loose scraps of paper in my bag laid the anatomy of the day's typical ransomware attack. My previous months had been spent picking up the tools of the infosec trade from the sidelines of Twitter. I wanted to see how much of it I could use.

Over lunch I probed the IT Manager about their threat model, what they were prepared for, and their recovery plans for when they failed. I approached them because I knew their environment wasn't prepared for a modern attack. My goal during the meeting was to see just how bad things were.

The office was in a bad way. The entire firm was working with legacy software and each workstation a unique snowflake. My entire class had been hearing horror stories of this environment for a year and a half. There was a lot of foundational problems but ransomware I could solve.

I scribbled each answer into my notebook.

• Windows 7 Workstations
• Windows 2012 R2 Domain Controller
• Microsoft Office 2010
• Most-used browser was Google Chrome
• No centralized logging

---

The light of my monitor illuminated my notes. My partner for the project had set to work on another task and left me with securing Microsoft Office and Google Chrome. I couldn't decide which to start with so I flipped a coin high in the air. Heads. Chrome it was.

The browser is a user's connection to the internet and the content they want to consume. It is also one of the most complex pieces of software that a user will use or a sysadmin will attempt to secure. When browsing the web one is often vulnerable to drive-by downloads and malvertisements that leverage exploit vulnerabilities in add-on software such as Adobe Flash and Java [1]. Worst of all most users can't avoid many of the exploits because the malicious code is embedded in legitimate websites [2].

Google Chrome's security was top notch when it came to default settings. Between the browser's aggressive sand-boxing[3] and ability to communicate safety to users it was the best choice. Chrome has a PDF reader built into the browser, allowing some organizations the ability to avoid a dedicated application for viewing, and defaulted to HTML5 over Adobe Flash for video playback [4] whenever possible.

To protect the users at the firm I would have to stop the browser from running scripts, since many attacks leverage JavaScript [5], and an adblocker to prevent malvertisements from tricking users into executing malicious code [5]. For good measure, enforcing TLS (HTTPS) whenever possible would protect the integrity of web traffic and ensure privacy [6].

I kicked my feet up on the table and began to plan my deployment. The guide that I had found [7] contained some additional information for securing Chrome as well. I decided to throw them in just for fun. Once I detailed the files I needed to collect I took a long sip of my energy drink and set to work.

Google Chrome offers a bundle (https://enterprise.google.com/chrome/chrome-browser/#download) to collect the MSI installer for the enterprise browser, and the Active Directory Group Policy Templates. Since the firm ran off of x86_64 operating systems the clear choice was the 64-bit Chrome Bundle. The goal was to protect all the users in the domain, so I used Machine-Wide Configurations wherever possible.

The first thing I did was enforce the built-in security features of the browser. Safe Browsing is a feature that present the user with a full-screen warning upon traveling to web pages that have been marked as containing malware or phishing attempts [8]. Many users click past warnings whenever possible but the Group Policy templates that Google provided allows system administrators to prohibit passing the Safe Browsing prompt. To ensure that Chrome and Safe Browsing were as good as possible I used the policy templates to opt all machines into extended reporting.

The firm had a VPN implemented with auditing and two-factor authentication enabled. None of the users should have a use for Chrome Remote Desktop (CRD), an extension that allows a user to remote into PCs similarly to Windows Remote Desktop. To make things more difficult for users who wanted to bypass the secured VPN I assigned all CRD clients and hosts to be part of the disabled.com domain, limiting which accounts could use the service. In addition, I disabled PIN-less authentication, firewall traversal from remote hosts, and curtaining.

I cracked open a second energy drink. This process hadn't taken very long but I wasn't paying much attention to how much I was drinking, and I enjoy the taste. The only thing left was to control the add-on installations in Chrome entirely through the Extensions/Force-Installation and Extensions/Blacklist policies.

Blacklist:

Chrome Remote Desktop: gbchcmhmhahfdphkhkmpfmihenigjmpp
Adobe Acrobat: efaidnbmnnnibpcajpcglclefindmkaj

Yeah, I had the ability to prevent CRD from being installed in the first place. There was no cost to turning on the other features. The likelihood that a user would ever notice was small but the principle of reducing Chrome's attack surface was enough for me. In an update to Adobe Acrobat the genius engineers began injecting an add-on into Chrome that was built off an old framework with known vulnerabilities. Many users at the firm had been accidentally installing it, causing many calls to the IT manager to fix it. I could save him the trouble in the future.

Force Installation:

uBlock Origin: cjpalhdlnbpafiamejdnhcphjbkeiagm;https://clients2.google.com/service/update2/crx
HTTPS Everywhere: gcbommkclmclpchllfjekcdonpmejbdp;https://clients2.google.com/service/update2/crx

uBlock Origin is the most suggested adblocker by professionals. The extension is able to prevent many scripts from silently running and prevents the users from encountering malvertisements. My partner's research showed that the application was so good at preventing excess TCP connections that it was lauded for improving browsing speeds more than its security benefits [9]. This wasn't a popularity contest though.

HTTPS Everywhere was recommended primarily for mobile workstations that often accessed the internet via public Wi-Fi. It was a simple application that changes requests for HTTP content to HTTPS content whenever it can.

My fingers froze, positioned on the tab of a third can of liquid heart problems. After weighing my options, I figured that Microsoft Office could wait a couple of days. My work on Chrome was complete.

References

[1] AVTest, "Adobe & Java Make Windows Insecure," 4 December 2013. [Online]. Available: https://www.av-test.org/en/news/news-single-view/adobe-java-make-windows-insecure/. [Accessed 7 April 2017].

[2] J. Zorabedian, "How malware works: Anatomy of a drive-by download web attack," 26 March 2014. [Online]. Available: https://blogs.sophos.com/2014/03/26/how-malware-works-anatomy-of-a-drive-by-download-web-attack-infographic/. [Accessed 7 April 2017].

[3] C. Hoffman, "Sandboxes Explained: How They’re Already Protecting You and How to Sandbox Any Program," How-To Geek, 2 August 2013. [Online]. Available: https://www.howtogeek.com/169139/sandboxes-explained-how-theyre-already-protecting-you-and-how-to-sandbox-any-program/. [Accessed 7 April 2017].

[4] A. LaForge, "Flash and Chrome," Google, 9 August 2016. [Online]. Available: https://blog.google/products/chrome/flash-and-chrome/. [Accessed 7 April 2017].

[5] M. Gough, "Avoiding Ransomware with built in basic changes," 15 September 2016. [Online]. Available: https://hackerhurricane.blogspot.ca/2016/09/avoiding-ransomware-with-built-in-basic.html. [Accessed 7 April 2017].

[6] Nexcess , "The Pros And Cons Of Implementing SSL / HTTPS," 3 September 2014. [Online]. Available: https://blog.nexcess.net/2014/09/03/the-pros-and-cons-of-implementing-ssl-https/. [Accessed 7 April 2017].

[7] Decent Security, "Managing Google Chrome with adblocking and security," 10 January 2017. [Online]. Available: https://decentsecurity.com/enterprise/#/ublock-for-google-chrome-deployment/. [Accessed 7 April 2017].

[8] Google, "Google Safe Browsing," Google, [Online]. Available: https://safebrowsing.google.com/. [Accessed 7 April 2017].

[9] DeadOnToilet, "Twitter," Twitter, 4 October 2016. [Online]. Available: https://twitter.com/DeadOnToilet/status/783522192151703552. [Accessed 7 April 2017].