Category Archives: DetectX
If you’re a regular user of DetectX Swift (DTXS), you’ll be familiar with the Folder Observer function. Although DetectX has always been and will remain an on-demand search tool in principle (i.e., it doesn’t do anything unless you launch it), the Folder Observer adds the capability to alert you and optionally launch DTXS if any items are added or removed from your Launch folders.
This is a useful feature which removes the need, for example, to set Folder Actions or other scripting solutions on the folders which are most likely to be written to in the event of an adware or malware attack. However, as some users (and even myself!) have noticed, the Folder Observer can, at times, be a little irritating.
For example, here at sqwarq I have Little Snitch installed, which puts daemons and agents in both of the local domain Launch folders. The annoyance occurs whenever Little Snitch requires an update. When that happens, the daemon and agents will get written to, and DTXS will dutifully throw me an alert:
Great, except that I don’t really want alerts for software I already trust. I only really want to know about stuff that I don’t know is already in those folders. Of course, I can uncheck the preference for the Folder Observer entirely to stop all alerts, but that then deprives me of the security of being warned of things that I do want to be informed about.
Fortunately, there’s a simple solution that will allow you to tame DTXS and customise the alerts to your personal needs.
1. Go to DetectX Swift > Preferences and click the ‘Observer’ tab.
2. Click the ‘Ignore Keywords’ checkbox (you need to be a registered or licensed user).
3. Click the ‘Edit’ button, and add the launch label of each item you want to ignore in a comma-separated list.
4. Click the ‘OK’ button to finish.
You can get the launch label either by reading it from each of the property lists that you want to ignore, or directly from DetectX Swift’s Profiler. The linked video shows one way you can do that.
I often need to check version numbers of apps I’m using from the ‘About’ menu. However, unlike ‘Preferences’, ‘Hide’ and ‘Quit’, the About menu doesn’t have a default hotkey.
Normally, it’s no problem to add a menu hotkey through System Preferences > Keyboard > Shortcuts, but you can’t do that for the ‘About’ menu. That’s because the Shortcuts requires an exact menu name, and the ‘About’ menu is actually postfixed with the name of each app, so there’s no way to specify the menu universally.
The script is quite simple, but does require System Events, and that means you need to make sure that System Events itself or the app that’s going to run the script has Assistive Access allowed in System Preferences’ Privacy pane.
The raw text for the script is available from my pastebin here.
Since releasing DetectX Swift back in January, a lot of people have been asking me how the new ‘Swift’ version differs from the older one, aside from requiring 10.11 or higher (the original will run on 10.7 or higher).
Well sure, it’s written in Swift — and it’s much swifter, literally, but of course there’s a lot more to it than that.
I’ve finally had a spare moment to enumerate the feature list and create a comparison chart. Although the image above is essentially the same as the one you’ll see at the link address at the moment, there’s still a bunch of features to be added as we go through development of version 1. Thus, be sure to check the latest version of the chart to get the most up-to-date info.
Some time shortly after the release of High Sierra public betas last year, I started noticing a lot of user reports on Apple Support Communities that included something odd: an Apple Launch Daemon called
com.apple.installer.cleanupinstaller.plist appeared, but oddly its program argument, a binary located at
/macOS Install Data/Locked Files/cleanup_installer was missing.
Being an Apple Launch Daemon, of course, the
cleanupinstaller.plistis owned by root:
-rw-r--r-- 1 root wheel 446 Oct 10 06:52 com.apple.installer.cleanupinstaller.plist
After discussion with a few colleagues about this oddity, I decided to see if I could catch a copy of the missing program argument. After rolling back to an earlier version first, I found that the macOS Install Data folder is created when a user runs the Upgrade installer (along with the Launch Daemon plist). A clean install with the full installer does not appear to create either the properly list or the program argument.
The Locked Files folder indicated in the program argument path is hidden in the Finder, but revealed in Terminal.
Locked Files folder is the
cleanup_installer binary. The binary is 23kb, and the strings section contains the following, giving some indication of its purpose:
Upon a successful upgrade, the
/macOS Install Data/ folder is removed, but the Launch Daemon is not, and therein lies the problem.
Let’s have a look at the plist:
The ‘LaunchOnlyOnce’ and ‘RunAtLoad’ keys tell us the program argument will be run just once on every reboot. It’ll execute whatever is at the program argument path with root privileges. With the executable missing as noted in numerous ASC reports, that leaves open the possibility that a malicious process could install its own executable at the path to aid in persistence or re-infection if the original infection were to be discovered or removed.
To test this hypothesis, I threw a quick script together that included a ‘sudo’ command.
sudo launchctl list > /Users/phil/Desktop/securityhole.txt
The legacy command ‘launchctl list’ produces different results when it’s run with
sudo and when it’s not. Without
sudo, it’ll just list the
launchd jobs running in the user’s domain. With
sudo prepended, however, it’ll instead list the
launchd jobs running in the system domain. This makes it easy for us to tell from the output of our script whether the job ran with privileges or not.
Having created my script, I created the path at
/macOS Install Data/Locked Files/ and saved the script there as ‘cleanup_installer’. It’s worth pointing out that writing to this path requires admin privileges itself, so this issue doesn’t present any kind of ‘zero day’ possibility. The attacker needs to have a foothold in the system already for the danger to be real, so I’ll repeat that the vulnerability here is the possibilty of the attacker hiding a very subtle root persistence mechanism within a legitimate Apple Launch Daemon, making it all the more difficult to detect or remediate if otherwise unknown.
The final step was to
chmod my script to make it executable, and then restart the mac. Sure enough, after reboot and without any other intervention from myself, the script was executed and my Desktop contained a text file with a nice list of all the system
Of course, that’s a trivial script, but here’s the tl;dr:
Anything – including code to reinstall malware – can be executed with root privs from that path every time a High Sierra install containing the Apple
If you’re already beyond your second reboot since updating and your /LaunchDaemons folder contains this property list, the obvious thing to do is to remove it (as High Sierra should have done when it completed the reinstall). It appears to serve no purpose once the program argument has been removed, other than to offer a way for malware to seek persistence.
Secondly, you should be able to safely remove the
/macOS Install Data/ folder if you find that exists. This is usually removed after a successful update, but it can also be left behind if a user cancels out of an update half way through. If you do find this still lurking on your system, you can check that it is what it’s supposed to be by copying and pasting this into Terminal:
strings -a /macOS\ Install\ Data/Locked\ Files/cleanup_installer
and confirm you get the same or similar as listed earlier in this post. On my system here, the file also gives a checksum of
945203103c7f41fc8a1b853f80fc01fb81a8b3a8. You can produce that on the command line with:
shasum -a 1 /macOS\ Install\ Data/Locked\ Files/cleanup_installer
However, it’s entirely possible that Apple either already have or may in the future make changes to that binary since I captured it, so a varying checksum alone should be treated with caution.
Of course, even after having removed these items, there’s nothing to stop an attacker that’s already compromised a machine from recreating both of those (as indeed, there’s nothing to stop a privileged attacker creating anything else on your system!). Thus, it’s always a good idea to keep track of what changes occur on your system on a regular basis. My free/shareware tools DetectX and DetectX Swift are designed to do exactly this. In DetectX, after running a search, the log drawer will tell you if the /macOS Install Data/ exists:
1. This issue was reported to Apple Product Security in August 2017.
We’ll try to get keys to you within 24 hours of receiving your correct answer, but bear in mind, it is Xmas, so delays may be possible while we digest our roast potatoes, parsnips and carrots!
DetectX Swift now has the ability to do command line searches for issues on your mac like malware, keyloggers, browser hijacks and potentially dangerous software, and there’s a number of extra options that are not available when using the user interface. In this post, I’m going to give you a quick tour of the CLI (Command Line Interface) tool with some examples of how to use it (if you haven’t yet grabbed a free copy of DetectX Swift you might want to do that first to play along).
1. Basic scan
Let’s start with a basic scan. To use the CLI search, you need to specify the full path to the app executable. In this example, let’s suppose that the app is in /Applications folder. In that case, you’d need to execute this on the command line:
/Applications/DetectX\ Swift.app/Contents/MacOS/DetectX\ Swift search
sphil@sphils-iMac-5:~$ cat .bash_profile
alias sudo='sudo '
alias detectx='/Applications/DetectX\ Swift.app/Contents/MacOS/DetectX\ Swift'
Note the sudo line (and note the extra space in the value). We’re going to need that so that we can pass the alias to sudo when we want to pass certain options to the search. Like…
2. Scan other users
Probably the most important benefit you gain with scanning on the command line rather than from the app’s interface is the ability to scan all, or selected, other users. You can search all users by using
sudo and the
sudo detectx search -a
If you want to restrict the search to one or more users, the
-u option allows you to specify a list of shortuser names (comma-delimited):
sudo detectx search -u alice,bob
3. Go deep
If you’d like more verbose output, including how long the search took, try either the
sudo detectx vvvv -a
4. Save the results
You can specify a path to output the results, either in regular text:
sudo detectx vvvv -a ~/Desktop/searchtest.txt
or, by passing the extra
-j option, in JSON format:
sudo detectx search -aj ~/Desktop/searchtest.json
Here’s an example of what the formatted JSON file looks like:
5. Anything else?
help command that will output the documentation to the command line, and also if you get into the habit of regularly running command line checks, don’t forget to launch the app from time to time in the Finder. Like its predecessor, DetectX, DetectX Swift does a lot of other stuff besides searching that can help track down and remediate problems with your mac, and a large part of that revolves around the way it tracks changes to your system every time you launch it. The CLI tool runs independently of that and won’t give you that kind of feedback or record those changes.
Finally, note that in the release version of DetectX Swift, the CLI tool is only available for a limited period to Home and Unregistered users. Unlimited acccess to the CLI tool requires a Pro or Management license.
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.
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! 🙂