While troubleshooting a user’s mac the other day, I happened to come across a curious line in one of the logs:
After a bit of digging, it occurred to me that this and the other flags being sent in the process command were possibly Preferences or Settings in the Chrome.app. Looking at
chrome://settings/privacy revealed, of course, Google’s phishing and malware protection setting, ‘Protect you and your device from dangerous sites’.
Here it is set to ‘On’, which is the default setting:
A quick test proved that setting it to ‘Off’ produced the `—disable-client-side-phishing-detection’ flag in the browser’s process output. Setting it back to ’On’ and relaunching the browser produced no output, confirming my theory.
A quick message to my user also confirmed that he wasn’t aware that phishing protection had been disabled, and to the best of his memory, had not been disabled by himself.
A simple preference setting
That got me to wondering whether that setting could be turned off programmatically by another, possibly malicious, process. To my surprise, it turns out that it’s trivial to do so.
All Chromium browsers have a Preferences file located in their Application Support folder. Usually this is within another folder called ‘Default’, but not always. Chrome and Vivaldi, for example, have it there, but Opera (and Opera Developer) store the Preferences file at the root level of their respective support folders.
The file contains the setting for whether the Phishing protection should be enabled or not. To determine how the preference was encoded in the file, I made a copy of the current Preferences file, toggled the setting, then made another copy. BBEdit’s ‘Find Differences’ function quickly told me the name of the key (if you don’t have BBEdit, you can also use Xcode’s FileMerge to run diffs, though it isn’t as pretty or as full-featured):
Again, there are differences among browsers. As shown above, Opera uses the key “fraud_protection_enabled” which takes a boolean. Chrome and Vivaldi, on the other hand, use a “safebrowsing” key which takes an array of key-value pairs, with the first item of the array being the key “enabled:”, and taking a bool for its value, like this:
With this information, it’s a pretty simple thing for another process running under your username to write to the Preferences file and turn off the built-in protections.
What about Safari?
Safari isn’t vulnerable to quite the same tactic as it doesn’t store its preferences in the same way. However, it’s even easier to defeat Safari’s ‘Warn when visiting a fraudulent website’ setting:
Apple hardened some of Safari’s preferences (like setting the Home page) some time ago to stop adware from making unauthorised changes, but this one is still unprotected in the current public release of macOS High Sierra. A one-liner in Terminal removes the preference:
defaults write com.apple.Safari WarnAboutFraudulentWebsites 0
What can you do?
The ease with which these protections can be surreptitiously turned off in all major browsers is a worry. And let’s face it, who would notice if this setting was quietly turned off? In both Chrome and Safari, the change takes effect immediately and does not even require a restart of the browser.
Fortunately, my shareware app DetectX Swift will warn you if browsing protection is off when you run a search and prompt you to turn it back on. To ensure that all insecure pages have been removed after turning the setting back on, DetectX Swift will continue to show the warning until you restart the browser and execute another search.
The protection covers all the browsers mentioned above. If you’re running some other browser and would like to know if it’s similarly vulnerable, drop a line in the Comments or contact Sqwarq Support and request support for your browser to be added.
Stay safe, folks! 😀
Featured pic: Nature by PichieArt
This software is called Google Updater, and it secretly “calls home” on a regular basis and downloads updates to your Google software without either asking before, or notifying you after, doing so. In Developer circles, this is considered very shady practice. Users should be asked for consent and informed when software makes changes to either itself or the user’s computer, and ideally those notifications should tell the user what has been changed and how the changes could impact them.
Before I beat this drum any harder, however, I owe you at least the other side of the story. If I worked for Google, I’d probably come up with this response: “Hey look, a major source of computer virus and malware infections is that users are often using out-of-date software that hasn’t been patched to combat newly-discovered exploits. No matter how much we tell users to keep ther software up-to-date, the truth is the majority don’t. We provide an automatic updater so that users don’t have to worry about it, and can be assured they’re always using the latest and safest version of our software”.
I’ve heard this argument so many times, I don’t doubt it’s something close to what Google would actually argue. My problem with this is that while automatic updates can be a good thing if they’re security related, it’s not at all clear why an app should be updating itself automatically for any other reason, or why it’s updating itself without providing notifications about when and what updates were made.
If an independent developer did that, they’d almost certainly find their software labelled as “suspicious” at best, and “dangerous” at worst. The fact that Google is a multinational, global enterprise with a stranglehold on the internet, and which is often tangling with the law in countries throughout the world, may make you feel more or less confident that they can be trusted more than independent developers, whose income depends very much on their reputation. I’ll leave that one for the reader to decide. 😉
Do I have Google Updater?
To see if you’ve got Google Updater hiding on your system, try this quick test in Terminal. Triple click the line of code below to highlight it.
defaults read com.google.Keystone.Agent
If you’ve previously installed my Terminal workflow, just hit control-opt-cmd-T or right/control click and choose “Services > Run in Terminal” from the contextual menu. Alternatively, if you have my free utility app FastTasks 2, the Analyser’s Profile view will show you if Google Updater is installed (see ‘Locate Google Updater’ below for the locations to check in the profile view). Elsewise, manually copy and paste it into a Terminal window.
If the result comes back as
Domain com.google.Keystone.Agent does not exist
you’re fine. Google Updater has not found its way into your system. Anything else and you’re going to need to decide whether you want to remove it or not. If you’re a regular Chrome user, keeping Updater might prove convenient, though you’ll have to live with the idea that the app is updating itself in ways over which you have no control. If you rarely or never use Chrome, there’s no reason to have this hidden process regularly calling home to Google every time you’re connected to the net.
How do I remove it?
You have two options. You can either disarm it or you can nuke it. Disarming it is simplest, it’s a one-line Terminal command:
defaults write com.google.Keystone.Agent checkInterval 0
This command tells the Updater how often to “call home”. A value of 0 basically means ‘never’. Disarming it is probably better than nuking it if you still keep Chrome on your system and use it occasionally. You can temporarily set it back to something like ‘once a week’ from time to time to check for security updates with
defaults write com.google.Keystone.Agent checkInterval 604800
Nuking the Google Updater is a bit more complex. You’ll want to run some uninstaller commands, and then you’ll want to go and clear up the crud that is still left behind. And before you can do either of those, you need to find out where it’s hiding. So, we have a three-step process.
1. Locate Google Updater
Triple click the first of these two lines, and choose ‘Services > Reveal in Finder’ from the contextual menu (that’s another right-click or control-click on the selected line), and then repeat for the second line:
You will likely get the error message “The operation can’t be completed because the item can’t be found” from one of these lines, but not the other. Note that the difference is all in the presence or absence of the tilde ~. Make a note of which one worked, and run the appropriate commands in step 2.
2. Run the uninstaller commands
Run these in Terminal (again, triple clicking to highlight and doing the usual trick afterwards with shortcut key or Services menu if you have my workflow installed), one at a time:
Updated, Jun 2018:
If the Updater was in your user library (with the tilde ~), then first triple-click this (it’s all one line) and run it in the Terminal:
If the Updater was in your domain library (no tilde ~), then first do this (it’s all one line):
sudo /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksinstall --uninstall
and enter your Admin password (note that you won’t see any indication of your password being typed in the Terminal window). Then do this:
sudo touch /Library/Google/GoogleSoftwareUpdate
3. Clear up the crud
If the updater was in your user library, open that now and go to
and delete the folder called ‘GoogleSoftwareUpdate’. If you don’t use any other Google software (I don’t), you can just delete the entire ‘Google’ parent folder.
If the updater was in your domain library, search for the same folder and send it to the trash. You will need to give Finder your admin password to authorise the move.
Next, let’s just check the uninstaller was successful. Look for the following. If you don’t find them, good (the installer did its job). If you do, help them on their way to oblivion by sending them to the trash:
If you’ve deleted Chrome from your Applications folder too, then you might as well hunt down and exterminate its prefs list while you’re at it:
The following sources were used in researching this post:
‘Don’t be evil’ picture was remediated from here.
Terminal tricks for defeating adware