Blog Archives

browsers’ anti-phishing protections easily defeated

nature__by_pichieart-dce0yeh

While troubleshooting a user’s mac the other day, I happened to come across a curious line in one of the logs:

Screen Shot 2018-06-11 at 16.28.05

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:

Screen Shot 2018-06-11 at 16.31.28

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. 

Screen Shot 2018-06-11 at 16.40.39

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):

Screen Shot 2018-06-11 at 16.56.36

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:

Vivaldi:

"safebrowsing":{"enabled":true,"unhandled_sync_password_reuses":{}}

Chrome:

"safebrowsing":{"enabled":true,"scout_group_selected":true,"unhandled_sync_password_reuses":{}}

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:

Screen Shot 2018-06-11 at 17.44.08

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

Screen Shot 2018-06-11 at 18.04.48

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.

Screen Shot 2018-06-14 at 12.24.44

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

how to easily spoof a user’s password





Spoofing or phishing – presenting a user with fake authentication requests – is a common email tactic, but it’s not the only vector where you need to be on your guard. Every version of macOS is vulnerable to a very simple phishing attack right on your desktop that doesn’t require admin privileges to run, would not be detected by GateKeeper or XProtect, and which could easily be placed on your mac by any of the nefarious malware / adware installer scripts that come with some less reputable software downloads.

This attack isn’t new, but it’s not often talked about. The easiest way to see how it works is in this quick 4-minute demo:

As you can see, it’s easy to grab the icon of any Application and put it in the script; it doesn’t even have to be the icon of an app that’s running. The simple demo I gave above could easily launch iTunes first to increase the coherence of the attack, or it could use a completely different icon, including the icon of security programs you may have running on your mac.

How can you check?

If you were presented with a password request like this and wanted to check whether it’s legitimate or not, an easy way would be to use my free utility DetectX Swift’s Profiler. Click the Profiler function, and search for ‘osascript’ within the Running Processes section. Note how DetectX Swift shows you the text of the script being run, confirming that this dialog is up to no good:


%d bloggers like this: