Category Archives: Security

adware goes old school with cron job




I’ve been wondering for a while now why we see so much adware persisting with nothing much other than easily detected Launch Agents when there’s a variety of other methods available on macOS. Some of those require privileges, like this little known one, but others do not.

Thanks to a DetectX user’s quick reporting, I was able to spot a known offender making good use of the venerable old crontab routine. Set to run on the 4th minute, every second hour, the job fires an executable lurking in the user’s Application Support folder.





A quick look on Google’s VirusTotal confirms what we expected:






Although cron jobs are easy to spot if you go looking for them, this one would probably have stayed hidden away for a while longer if it hadn’t been for the speedy reporting of the user.

DetectX will now find this particular miscreant in its normal search routine, but if you want to check for others, run the Report a Problem to Sqwarq Support function in the Help menu. We’re happy to look through the logs that creates on your Desktop for you, or if you like delving into this kind of thing, check out the DetectX_Swift.Processes.txt file in the logs and search down for where it says ‘User Crontab’ as indicated in the screenshot at the top of this post. If you find anything there that you didn’t put in yourself, it warrants further investigation. Feel free to contact us at Sqwarq support if you need help with that.

Stay safe, folks! 🙂


Mac Media Player’s secret MacKeeper installer




Last week I added MacGo’s Mac Media Player.app to DetectX’s search definitions after finding that the installer was delivering MacKeeper on unsuspecting users. After a support call asking me whether the MacGo player itself was malicious, I decided to look into what was going on in a bit more detail.

Downloading the Mac Media Player from the developer’s site rewarded me with a DMG file called Macgo_Mac_Media_Player.dmg, and mounting that revealed the Installer.app (pictured above).

Examining the package contents of Installer.app had a few surprises. For one thing, the bundle identifier (a reverse domain-name style string used to uniquely identify an app on macOS) was the oddly titled com.throbber.tipcat, and the executable binary file was named hemorrhoid. Examining both the binary and other files in the Installer bundle revealed some heavily obfuscated code that is really quite unusual to see in anything except malware.

That gave me pause to try and run the Installer in the lldb debugger and see exactly what it was up to, but – also another sign of malware – the Installer.app appears to have been coded precisely to stop that from being possible. Every time I tried to attach the debugger to the Installer’s process, the installer quit with “status = 45”, a sign that the debugger is being deliberately thwarted.

My next tack was to dump the class names with

otool -oV /Volumes/Installer/Installer.app/Contents/MacOS/hemorrhoid | grep name | awk '{print $3}'







And that revealed some oddities, too. With names like ‘stockyardsStormed’ and ‘DefilersDiesels’ I was sufficiently intrigued to run the installer to completion and see it in action. As the screenshots below from my shareware troubleshooter DetectX and Objective Development’s Little Snitch 4 indicate, the unwary will get a lot more than just a free video player:







Finally, just to confirm my results, I uploaded the installer.app to VirusTotal, and found that it was a variant of the InstallCore strain of adware.







That pretty much wraps up the case against the installer, but what about the Mac Media Player app and its related version the Macgo Mac Blu-ray Player Pro? It seemed as far as I could tell that the apps themselves were ‘clean’. However, RB AppChecker Lite reveals that the installer and both the apps are signed with the same Apple Developer ID, ZJ Tech Inc, F9QTW5KSLJ.







That pretty much rules out any possibility that the developers had been unknowingly compromised. Clearly, ZJ Tech are quite happy to distribute their software to customers and do a stealth install of MacKeeper at the same time. Presumably, there’s some financial pay-off for them in doing that. Given that ZJ’s media players also seem to be little more than copies of VLC.app, it seems there’s pretty good reason enough to avoid using their products.


how to protect your app from hijacking


I was lucky enough to get a great tip from MalwareBytes’ Thomas Reed this week on the possibilities of code hijacking.

Thomas was kind enough to share details of a talk he gave at MacTech last year, in which he demonstrated how some 3rd party apps are susceptible to having their binaries replaced by a fake binary even when the original application is properly code signed with a valid developer’s signature.

The vulnerability lies not so much in the code signing itself, but in the mechanism for when and why it gets checked. In short, code signing is checked when an app is first launched, but after that, except in a few special situations, macOS’s security mechanisms pretty much ignore it. That means once an app has passed GateKeeper, it’s a ripe target for attackers to come in and replace the binary with one of their own.

In order to ensure the app on disk is still in fact the app that was downloaded and first launched, developers need to implement a check on each launch.

If you’re using Swift, some example code for doing that (pictured above) is available from my pastebin here. I’ve also got a version for Objective-C, adapted from here.

The key to it is what you specify in the entitlement constant. In this example, I’ve specified three things: that the code is signed by Apple, that is has the app’s bundle identifier and that it has the developer’s Team ID. Don’t forget to change my dummy values for your real ones in the code! You can get all these details for your app by running this in Terminal:

codesign --display -r- <path to your app>

With that information, the function verifies that the application in memory meets the requirements specified in the entitlement.

Call the function at some point after launch (e.g, when your main nib has loaded) and handle the boolean result appropriately. For example, if the function returns false, you might throw an alert like this one from DetectX Swift telling the user that the app is damaged and needs to be re-downloaded, and then terminate the app when they hit “OK”:

Let’s keep our code (and users!) safe everybody. 🙂


DuckDuckGo Privacy Extension not so private

DuckDuckGo recently made changes to their browser extension which turns it into an adblocker and privacy advocate, stalling websites that would like to track you and sell your behaviour to the nearest (not necessarily highest) bidder.

It sounds great, until you install the extension and realise you’re trading one privacy exposure for another. As the picture above makes clear, you’re allowing the extension to read everything you post on a website, including your passwords. To be fair, this is not uncommon with adblockers, but it is also not necessary; 1Blocker and Better adblocker, for a couple of examples, do it properly:

I don’t know who’s really behind DuckDuckGo or what they really do with the data they can see from my web browsing. I know no more about them than I know about those behind all the adtrackers and other spyware that the DuckDuckGo extension is trying to block (while being able to read my passwords and potentially track my browsing habits).

DuckDuckGo may have a good reputation, but there’s a whiff of the hypocritical in a tool that promises to protect you from spying that can itself potentially spy on you.

Sorry, but that’s not the kind of tool I need to protect my privacy. I immediately uninstalled it.


how High Sierra updater leaves behind a security vulnerability

DetectX

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.

An ‘etrecheck’ report on ASC

Being an Apple Launch Daemon, of course, the cleanupinstaller.plist is 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

Inside the 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.

#! /bin/bash
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 launchd jobs!

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 cleanupinstaller.plist reboots.

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

NOTES:
1. This issue was reported to Apple Product Security in August 2017.

 

scan for malware on the command line

Screen Shot 2017-12-20 at 19.23.50


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

Since that’s a bit of a handful, even using tab completion, you might want to edit your .bash_profile to include a shortcut alias. Here’s mine:

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 -a option:

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 vsearch or vvvv commands:

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:

Screen Shot 2017-12-20 at 18.05.26

5. Anything else?
There’s a 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.

Enjoy! 🙂


how to remove MyCouponize adware





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.

You can remove it easily with DetectX Swift (a free/shareware utility written by myself) as shown in this video. If you prefer reading to watching, here’s the procedure:

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.
Press the 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 com.MyMacUpdater.agent







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 com.MyCouponize.agent

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.

DetectX and DetectX Swift are shareware and can be used without payment, so go grab yourself a copy over at sqwarq.com.


what is rapportd?


Since early November, I’ve been seeing reports of High Sierra users being presented with a dialog box from the Firewall asking whether the user wants to accept incoming network connections to rapportd.

This is causing some confusion among troubleshooters as there’s a fairly notorious process with the same name associated with IBM’s (badly-performing) Trusteer software. This latter often causes system slow downs and the general recommendation is to remove it unless you absolutely can’t live without it.

However, the rapportd process responsible for the dialog has nothing to do with IBM’s Trusteer and is, in fact, an Apple daemon introduced in 10.12. According to the man page, Apple’s rapportd is a daemon providing support for the Rapport connectivity framework. Although rapportd is bundled with 10.12, it appears to have only become active in 10.13.

Issuing

lsof -i -P | grep -i rapport

at the command line doesn’t return any hits on my 10.12 machine, but High Sierra reveals that Apple’s rapportd process is listening for network connections on port 49158. Further investigations have found that rapportd is connected to Apple’s HomeKit framework, a home automation platform for controlling smart home products with iOS apps and Siri voice commands, and is likely related to Airplay 2.

To verify which rapportd process you’re dealing with, jump into Terminal and paste this command:

ps aux | grep rapportd

Alternatively, if you’re a DetectX Swift user, you can search for it in the Profiler view (Command-F evokes the Find inspector bar):

If the search or find reveals a process address as /usr/libexec/rapportd, that’s your Apple friend and you can safely allow the connection. Searches for rapportd also might produce any of the following paths, all of which are legitimate:

/System/Library/LaunchDaemons/com.apple.rapportd.plist
/System/Library/Sandbox/Profiles/com.apple.rapportd.sb
/usr/libexec/rapportd
/usr/share/man/man8/rapportd.8

On the other hand, if you see a path address for

/Library/Rapport/bin/rapportd.app/Contents/MacOS/rapportd

or searches reveal

/Library/LaunchAgents/trusteer.rapport.rapportd.plist

that’s the IBM app you’re looking at. Whether you want to allow that or uninstall that will depend on both your mac’s performance and whether you need the software or not.

Hope that helps to clear up some of the confusion!

🙂

malware can make Safari windows invisible

 

Given news that some hackers are using websites to mine cryptocurrency even when users apparently close their browser on Windows, I got to wondering whether a similar exploit would work on macOS.

As the video above shows*, a malicious app can easily hide an open Safari window from all desktop workspaces, making it incredibly difficult for users to notice or to make visible again even when they do. This trick can be exploited without elevated privileges, and it doesn’t matter whether the malicious app is code-signed or not.

An invisible Safari window is a problem because it could be running scripts, mining cryptocurrency, redirecting to sites for adware revenue or doing all manner of other things. Note the window could contain multiple tabs that the user may have already been tricked into opening before the window is made invisible.

As can be seen in the video, the Safari window isn’t in another full screen workspace, or minimized in the Dock or hidden by any other window or toolbar (as in the Windows 10 trick).

On the contrary, it can’t actually be found anywhere, and nor will Window > Bring All To Front help. If you open a new window and then try to use Merge All Windows to bring the hidden window out, all that happens is your new window will disappear with the hidden window too.

The only visible indicators that there’s an invisible window open are the window list in the Window menu, and the invisible outline revealed by Expose (four-finger swipe down).

So what if you find there is an invisible window hiding from you, how do you get it back?

To retrieve and kill the hidden window, you need to click View > Enter Full Screen, then click the red close button. Don’t click the green button to take it out of full screen though, as that’ll just cause it to hide again, with a nice animation that you can see on the video!

Another day, another hacker trick to watch out for folks!

🙂

* This vulnerability was demonstrated on 10.12.6. It also exists in both 10.11.6 El Capitan and 10.13.2 High Sierra.

yes, enable the root user if you’re on High Sierra

 

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:

https://support.apple.com/en-us/HT204012

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.

%d bloggers like this: