MyCouponize is an aggressive adware infection that simultaneously installs itself in Safari, Chrome and Firefox, It hijacks the user’s search and page loads, redirecting them to multiple web sites that advertise scamware and other unwanted junk.
1. Run the search in DetectX.
2. Click on the [X] button.
You’ll find this button just above the results table to the right, between the search count and the tick (whitelist) button. It will turn red when you hover over it. When it does so, click it.
Then hit ‘Delete’ to remove all the associated items.
You’ll need to enter a password as some of the items are outside of your user folder.
esc key or click the ‘Cancel’ button on any pop up dialogs that appear.
3. Go to the Profiler
Here we’ll unload the launchd processes that belong to MyCouponize.
Navigate to the user launchd processes section and move the cursor over the item
Click the ‘Remove x’ button that appears when the line is highlighted.
Wait for the profiler to refresh and then go back to the same section and remove the second process called
4. Quit the mediaDownloader.app
This item has already been deleted in step 1, but its process may still be running in memory. If its icon appears in the Dock, right click on it and choose ‘Quit’ from the menu.
4. Finally, go to Safari Preferences’ Extensions tab
Click the uninstall button to remove the MyCouponize extension.
After that, Safari should be in good working order. If you have Chrome, Firefox or possibly other browsers installed, make sure you remove the extensions or Add Ons from those, too.
Update: There’s a security update available in the App Store now that mitigates this risk. It should be applied by all High Sierra users as a matter of urgency.
Today has been all about a monumental security flaw in High Sierra which allows anyone to log in to a mac and immediately become the root user without a password at all.
If you haven’t yet seen the news, check out the 30-second video above. If you’re not on High Sierra, no need to worry.
Although there are conflicting reports of exactly under what conditions the exploit can be triggered, it seems that in most cases two attempts are required to escalate user privileges. The first time enables the root user with the password that you do or do not put in the password field (i.e., it’ll accept a blank password). The second time is using those credentials to unlock whatever it is you want to unlock (in the video, only 1 attempt is shown as I had already ran the exploit once prior to making the video). There also seems to be conflicting reports about whether the flaw can be exploited remotely. What does seem certain is that malicious 3rd party applications could programmatically use it to escalate privileges for themselves, so it’s important to make sure you take the proper precautions to deal with this flaw until Apple patches it with an update.
Alas, with so much excitement, it seems some people are getting confused about exactly what needs to be done to avoid falling victim to this security flaw. The answer is not, as has been mistakenly suggested in some quarters, to disable the root user, but quite the reverse: you need to enable it.
The one thing that stops the flaw from being exploited is having the root user already enabled and set with a strong password.
By default, macOS ships with the root user disabled, so unless you (or someone who administrates your mac) has enabled it at some point, it won’t be set. If you’re not sure, this AppleScript will quickly tell you the status of the root user:
Update: further testing on 10.13 shows that the root user may be enabled without writing a ShadowHash entry to dscl. In that case, the script would incorrectly indicate root was disabled. Thus, to be certain, the best way to check is to follow the instructions in the apple support article linked to below.
If you find the root user is disabled, then go and enable it by following Apple’s instructions here:
Be sure to use a strong password of at least 14 characters or more. You can save the password if you want, but it doesn’t really matter much if you forget it. There’s really never any need for an admin user to require the root user at all, and there are other ways to get root privileges safely through the Terminal if needs be.
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:
It’s been unusually quiet on Applehelpwriter these past few months, and the reason is that I’ve been devoting all my time and efforts to the new version of DetectX. The new version is called DetectX Swift because (yeah, you guessed it) I wrote it in Swift and because it’s considerably faster than its older sibling.
DetectX Swift’s got a new interface, but there’s far more going on under the hood. The Search uses some fancy heuristics as well as hard-coded and live update search definitions to ensure it provides the very best in security threat scanning.
The new Profile view employs some super cool dynamic highlighting and lets you inspect the contents not only of directories but also of scripts, plists and other files that could execute troublesome code on your mac.
There’s changes in the History view, too, both in the display and functions. One of the coolest things I like about the new History function is that you can run a diff on any previous run against the latest run, immediately seeing how they differ.
There’s tons more to DetectX Swift, but the best way to find out about it is just to try it. The beta version is free to use for both Home and Commercial users, so just head off over to its home page and grab yourself a copy!
Don’t forget to keep us informed of how it goes. The beta is still in an early stage and more features are slated as it develops, but feel free to tell us about anything that you feel could be done better or things that you’d like to see added.
Share and enjoy! 🙂
Pretty soon now I’ll be releasing the first beta of DetectX Swift. Lots more details will be forthcoming over the next few days and weeks, but here’s a quick 1-minute look at how the new Profiler function works and some of the cool things you can do with it.
At our house, giving visitors the wifi password is always an exercise in frustration. Can’t remember? Oh, then I’ve got to either go trawling through Keychain Access or log in to the router, neither of which are particularly appealing.
Here’s an easier way. It’ll require an admin password (and you’ll need to supply it for as many passwords as you’re looking for – no ‘with administrator privileges’ will help here I’m afraid), but otherwise requires nothing more than a quick double-click of this saved script, once you’ve added your own SSID names in place of the dummy ones.
Just to be clear, you do NOT need to add the passwords to the script. So long as the mac that you run this script on already knows the Wifi password, the script will retrieve it.
If you are preparing to install macOS on multiple computers, one of the things that can make your life simpler (and the waiting shorter) is a bootable USB installer.
The idea of the installer is that you only need to download the macOS Installer.app from the App Store once. Usually, when you run the installer after downloading it, it’ll delete itself and you have to go through the whole download process again on each machine or disk that you want to install macOS onto. By making a bootable USB drive, you simply plug the drive in to your mac, launch the installer app and tell it where to install the OS. You can repeat this as many times as you like as the installer will remain safe on your USB.
There are various ways to make a bootable USB installer, but they all involve the same process:
1. Download the macOS Installer from the App Store.
2. Run the
createinstallmedia command from the Terminal, an AppleScript or a helper app.
3. Reboot your mac, choosing the newly created USB as the startup disk.
4. Run the installer.app from the USB.
Step 2 is where the fun is. The
createinstallmedia command can be tricky to get right, particularly if you’re not familiar with working on the command line. For those of you that are, follow Apple’s instructions here.
For a little more convenience, I wrapped all that inside an AppleScript which will first ask you for the location of the installer, then ask you to choose the USB target.
For maximum convenience, I also wrote a free little Swift app I’ve dubbed ‘Boot Buddy‘ (cos “Create bootable macOS Installer Drive.app” just didn’t quite have the right ring to it..!) that will present the whole thing in a neat little user interface. Three clicks, more or less, and you’re done.
Boot Buddy doesn’t require an admin password to install, but you do need to provide an admin password to actually create the bootable installer as the
createinstallmedia process has to be run as root. Boot Buddy doesn’t see or use this in any way whatsoever other than to start the
createinstallmedia process or to cancel it (if you choose to do so); authorisation is handed off to macOS to take care of.
Boot Buddy requires macOS 10.11 or higher and can create bootable USBs from Mavericks, Yosemite, El Capitan, Sierra and High Sierra installer apps.
Share and enjoy! 🙂
With malware big in the news again, and evidence that at least one malware variant that targets macOS creates hidden users on the victim’s system, here’s a timely tip on how to check for unwelcome guests.
For this tip, we’re going to use the Terminal, which you can find in the /Applications/Utilities folder. If you’re not a frequent visitor to the land of the command line, you might want to see my 3-part series “Learning the Terminal”.
Regardless, the first thing we’re going to do in Terminal is about the simplest command you’ll ever type:
w. Yep, type a single ‘w’ at the prompt and press return.
w utility is a very quick way to see who’s currently logged on to your system and to ensure that there’s no surprises. You should see a couple of entries for yourself: one as ‘console’ and one as ‘s***’. The first represents a login through the usual Desktop GUI login window; the second is there because you just logged into Terminal. Anybody else logged in either via the command line (like a potential remote user) or the GUI will show up here. Notice that on my machine, there’s another user called ‘Developer’ who hasn’t logged in using the GUI, but is logged in via a command line interface. Note that ‘w’ returns the full user name, not the short one.
w utility will tell you if a hidden user is currently logged on, what if there’s a hidden user that isn’t active at the particular time you check? To look for those, we have a couple of options. First, we can use the
dscl utility to list all users, and you might be surprised at how many there are:
dscl . -list /Users
Look to the end of that list where the names that don’t begin with an underscore start. ‘Daemon’, ‘Nobody’, ‘Root’ and ‘Guest’ are all standard system accounts, as are all those entries that begin with an underscore. Don’t worry about those. However, aside from those, you should only see names that you recognise. To make things a little easier, we can add another command to the dscl command to filter that list. Try this
dscl . -list /Users | grep -vE ‘_|root|nobody|daemon|Guest’
That should now only return the names of real users. There shouldn’t be any names in there you don’t recognise. In my example, I know the last three, but the first one ‘dev’ isn’t familiar to me. Note that unlike ‘w’, this command returns short user names, and that ‘dev’ looks very much like it’s the same account as ‘Developer’ that I saw earlier.
However, what we have so far is a list of users, not a list of hidden users. To see specifically if any accounts are hidden, we need a longer command:
defaults read /Library/Preferences/com.apple.loginwindow
Normally, when there are no hidden users, this will return the contents of a property list file that may look something like this:
GuestEnabled = 1;
OptimizerLastRunForBuild = 31898816;
OptimizerLastRunForSystem = 168494592;
SHOWFULLNAME = 1;
lastUser = loggedIn;
lastUserName = imackim;
That tells us that there’s no hidden users on this mac. How so? Because if there were it would return something very different, like this:
We can see not only the list of hidden users, but also that the preference for hiding users has been set to ‘1’ (in plist syntax, ‘1’ means true and ‘0’ means false). Note again that unlike the
dscl command above, this returns the account’s full name, not the short user name.
If we’d like to ‘unhide’ that user, so the account appears in the login window GUI and in System Preferences’ ‘Users & Groups’ pane, we’ll need admin privileges. To do that, cut and paste the following into Terminal:
sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool NO
Supply an admin user password at the prompt and hit ‘return’, but type slowly as the display doesn’t register your key presses, which makes it easy to fat finger your password.
For the more advanced
We can save ourselves some typing by putting much of this into a script so that we can run it whenever we want. If you’re not familiar with how to create and use bash scripts, take a look here.
Our script will basically do the same as all the commands we listed above (except changing the prefs for
Hide500Users) in one fell swoop, and there’s a couple of little twists that I’ll leave as an exercise for the reader to figure out. To save on the typing, you can copy the whole script from my pastebin here.
The script’s output is illustrated in the shot at the top of this post.
This little tool will help you keep track of when Apple make changes to system config data like XProtect, Gatekeeper and the Malware Removal Tool. It will also alert you if there is a Security update in the App Store that needs to be manually applied.
Critical Updates is free for home use. Organisations wishing to license it for commercial-scale use should contact me through Sqwarq support.