let’s bury the myth of the safe Mac

Do Macs get malware? Can my Mac get infected by a virus? Do I need AV software for my Mac? These are questions I hear a lot, but the answers that come from many so-called Apple Mac gurus are often wrong or misleading.

In this post, we’ll take a look at some of the reasons why people think Macs are safe from malware and the confusions that are often bandied around concerning “AV” (“anti virus software”), “viruses” and genuine malware. Then we’ll look at the actual security situation on macOS and make some suggestions as to how you can stay safe without turning yourself into a paranoid security conspiracist or downloading useless software that just eats up your system resources while providing no real protection.

“It’s All Security Theatre” theatrics

There’s an unfortunate and dangerous misconception perpetrated by certain people in the macOS community. These people variously claim that there is no malware threat to Macs, or if there is then Macs are immune from it, and no matter what the case, Macs are inherently safer than other kinds of computer, specifically Windows computers.

The purveyors of such arguments typically make a big deal of trying to undermine any argument that security is an issue on macOS by claiming that malware on Macs is all a myth made up by AV vendors to drum up business for their own products. In many Mac user forums, people worried about hacking and malware are often treated to dismissive replies of this sort:

“you are at much greater risk from a concussion due to a fish falling from the sky. The Mac AV industry and security researchers have worked very hard to make you believe this is something to be afraid of.”

The claim that emanates from such people often begins with “there are no known viruses for macOS” and, therefore, you don’t need anti-virus software. This is a laughable confusion of terminology.

AV software is inappropriately named. There actually aren’t any known viruses on macOS, it’s true (these days, there are very few for Windows either and most AV software isn’t primarily looking for them). That’s because viruses are a specific kind of threat that went out of fashion long ago. Viruses were the product of vandals; the modern security threats facing macOS users are the products of profiteers. It’s a different ball game.

These days, criminals are more interested in pushing macOS adware, backdoors, keyloggers, RATS, trojans and spyware. Ransomware has also been known on the platform, though thankfully to date that’s an isolated incident.

The conspiracy theorists like to point out that security vendors have a vested interest in making people fearful. It’s rather like saying insurance companies or law enforcement have an interest in higher crime rates. I’m all for healthy cynicism. The reality is that there are, indeed, commercial interests involved in fighting malware just as there are in fighting other kinds of crime. And where there’s commerce, you’ll also find cheats and unscrupulous dealers. There are plenty of dodgy AV products around; some are even on the Apple App Store. Some of those proclaiming that the security industry is all fraud are pushing their own software as an alternative. Unscrupulous, indeed.

Be wary of any software that offers to “find” threats but then insists you pay up in order to remove them or which tries to lock you in after minimal use where you cannot fully determine the value of the offering.

However, unlike the one shown above and others like it, there are genuine security products out there developed by genuinely-good people serving the community.

But the real point is that the existence of commercial interests in the anti-malware industry is, on its own, no more an indicator of duplicity than it is in any other industry. While amplification of threat intelligence through news stories, tweets and other social media serves the security industry just as amplification of relevant issues serves any business sector, to claim that all vendors are unscrupulous or that the threat is entirely fictional is disingenuous and worse, it’s dangerous.

As we’ll see below, the threats are real, but the conspiracy theorists threaten to lead macOS users into a false sense of security.

Burying the Myth of the Safe Mac

It’s not just the conspiracy theorists you have to watch out for. It’s also the “wisdom of the wise”. Far and wide, you’ll hear Mac gurus arguing from their own personal experience that, since they’ve never encountered macOS malware and they’ve been using the platform for x, y, z amount of years, there are, consequently, no malware threats to macOS and that it’s inherently safer than other platforms.

The logical fallacy in that should be clear. Arguing from a sample of one to a conclusion for all is just bad thinking. It also should perhaps come as no surprise if a “power user” hasn’t come across threats to their own Mac. They typically have limited and specialised interests that don’t take them to many of the far corners of the internet. Power users also tend to write scripts or even their own software to do things on their Mac, whereas other users would instead go looking for a tool to download from adware-infested mass distribution sites, torrent sites and who-knows-where, with all the risks that that involves.

When the self-professed gurus tell you they have never encountered a security issue on a Mac, they aren’t testifying to the safety of the platform; they are in fact revealing only that they know nothing about macOS security.

Will Gatekeeper Protect You From Malware?

Some people are more realistic and acknowledge the existence of the threat, just as Apple themselves have done by building anti-malware protections into macOS itself, namely, Gatekeeper, XProtect and MRT (Malware Removal Tool).

Because Apple have taken these measures and have been pretty vocal in their marketing about it, too, many think that Apple’s built-in security technologies will keep them safe. Here’s a typical example of this kind of thinking, where a forum poster suggests Apple may not be sharing information about malware threats because they can just kill them by revoking the malware developer’s code signature.

Of course, there is no such setting as “Run only signed apps”, but seasoned Mac users would understand that the poster is referring to Gatekeeper, which is the first check the system makes on application code signatures.

Unfortunately, the poster is just flat-out wrong. Even when set to App-Store only, it’s a simple matter for even a standard user to run apps with invalid signatures or no codesigning at all. Both Gatekeeper and XProtect are easily bypassed. Not only can standard users override Gatekeeper’s “App Store only” settings, so can other processes. None of this needs admin privileges. As for Apple’s Malware Removal Tool, it is useful to the extent of its signature database, but it has the major limitation that it only runs when you reboot your Mac.

Malware Campaigns That Target macOS Users

A typical day for me hunting macOS threats on VirusTotal looks something like this, with several hundred new samples to inspect:

So, yes, macOS malware is a thing and it’s out there. From nation state actors to sneaky hackers on Discord, if you’re using a Mac to interact widely with other people, visit websites, read email – in other words, doing the things that make your Mac useful – then there is a non-negligible chance of you encountering someone trying to infect your Mac.

In 2018 alone, we saw the emergence of malware families such as OSX.MaMi, CrossRAT, OSX.AppleJeus, WindTail, OSX.Dummy, CoinTicker, OSX.DarthMiner and OSX.LamePyre. On top of that, we’ve seen the appearance of a number of adware installers acting as trojans for cryptominers, such as PPMiner, CreativeUpdate and SearchPageInstaller. Old favourites like OSX.Fruitfly remain viable threats that can be repurposed by other actors as neither XProtect nor Gatekeeper is equipped to tackle script-based and fileless attacks.

Adware and PPI (pay-per-install) PUPs (potentially unwanted programs) like MacKeeper and Advanced Mac Cleaner, MyShopcoupon and chill tab are rampant. Adware in general is an increasing concern as we see adware developers expand their range of techniques and begin to cross the line into malware-like behaviour. Browser extensions are still a widely unappreciated threat, built-in browser anti-phishing protections are easily defeated, and if you haven’t had a phishing email in your Inbox then you are likely one of an increasingly diminishing global minority.

Finally, let’s note that for criminal types, it’s never been easier to get into the macOS malware business with the proliferation of dedicated exploit kits like empyre, EvilOSX, Pupy, Bella, EggShell and others.

How To Stay Safe on macOS

The evidence provided above is conclusive: the threats are real, so don’t let anyone try to kid you otherwise.

That said, the most widespread, “in the wild” problems affecting Macs today come from adware and PUPs. It might not be the end-of-the-world if your Mac gets infected with some nuisance adware and scam virus alerts keep popping up in your browser, but neither is it a particularly pleasant experience that you should have to put up with.

Fortunately, dealing with them is fairly straightforward, so let common-sense prevail. Most home users don’t need the expense or resource-impact of a full-on AV Suite. Reboot your Mac often to take advantage of what protection the built-in MRT tool offers, and use a lightweight, troubleshooting tool like my DetectX Swift to help diagnose and remove problems if your Mac starts behaving oddly.

While the technically-proficient may be able to deal with a lot of adware from the Terminal, DetectX is light enough to be run on a regular or scheduled basis (like after you install any new software) and can look for and remove adware, malware, keyloggers and more.

You can use DetectX Swift indefinitely and without paying a cent. It won’t burden your finances with a monthly subscription bill or demand that you pay money to remove suspicious or unwanted files, or insist that you pay up after a few uses. While there is an optional registration for home use which also provides a few bonus features, it’s not necessary to register in order to use the app’s core functionality. You can even script it with AppleScript and enjoy almost all the troubleshooting functions it offers as an unregistered, unpaid user. I also offer free, personal triage to both registered and unregistered users if you have an issue that DetectX does not resolve.

If you have a fleet of Macs in an organisational setting you might want to consider the low-cost, DetectX Swift Management license in order to access the command line search tool and integrate with platforms like Jamf or Munki. For more in-depth coverage and cross-platform support, enterprises should look at next-gen AV software that uses behavioural AI like SentinelOne.



Picture Credit: Mikayla Mallek

how to reverse malware on macOS

Resources for learning malware analysis and reverse engineering abound for the Windows platform and PE files, but by comparison there’s very little literature or tutorials for those who want to learn specifically about how to reverse macOS malware and macOS malware analysis techniques.

In this series of posts, you’ll take a sample file and use native tools and techniques to understand what a file does and to build a list of IoCs (Indicators of Compromise) that can be used in detection.

As there’s a lot of ground to cover, the tutorial is split over several parts. In Part 1, you’ll learn how to set up a safe environment to test malware on macOS. You’ll install all the tools you need (bonus: doesn’t cost a cent!) and learn where you can source samples of macOS malware from. You’ll examine an application bundle and its contents to understand how it works and find an interesting encrypted text file. In Part 2, you’ll learn the fundamentals of static analysis of Mach-O binaries, the native executable file type for macOS. In Part 3, you’ll use dynamic analysis techniques to execute a malware file in a controlled manner and read code from memory.

If you have ever wanted to learn how to reverse malware on macOS, this is the place to start! Continue reading…

browsers’ anti-phishing protections easily defeated

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:

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:

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

defending against EvilOSX, a python RAT with a twist in its tail

Intro
EvilOSX is a malware project hosted on GitHub that offers attackers a highly customisable and extensible attack tool that will work on both past and present versions of macOS. The project can be downloaded by anyone and, should that person choose, be used to compromise the Macs of others.

What particularly interested me about this project was how the customisation afforded to the attacker (i.e., anyone who downloads and builds the project, then deploys it against someone else) makes it difficult for security software like my own DetectX Swift to accurately track it down when it’s installed on a victim’s machine.

In this post we’ll explore EvilOSX’s capabilities, customisations, and detection signatures. We’ll see that our ability to effectively detect EvilOSX will depend very much on the skill of the attacker and the determination of the defender.

For low-skilled attackers, we can predict a reasonably high success rate. However, attacker’s with more advanced programming skills that are able to customise EvilOSX’s source code to avoid detection are going to present a bigger problem. Specifically, they’re going to put defenders in an awkward position where they will have to balance successful detection rates against the risk of increasing false positives.

We’ll conclude the discussion by looking at ways that individuals can choose for themselves how to balance that particular scale.



What is it?
EvilOSX is best described as a RAT. The appropriately named acronym stands for remote access trojan, which in human language means a program that can be used to spy on a computer user by accessing things like the computer’s webcam, microphone, and screenshot utility, and by downloading personal files without the victim’s knowledge. It may or may not have the ability to acquire the user’s password, but in general it can be assumed that a RAT will have at least the same access to files on the machine as the login user that has been compromised.

Whether EvilOSX is intentionally malicious or ‘an educational tool’ is very much a matter of perspective. Genuine malware authors are primarily in the business of making money, and the fact that EvilOSX (the name is a bit of a giveaway) is there for anyone to use (or abuse) without obvious financial benefit to the author is arguably a strong argument for the latter. What isn’t in doubt, however, is that the software can be readily used for malicious purposes. Irresponsible to publish such code? Maybe. Malicious? Like all weapons, that depends on who’s wielding it. And as I intimated in the opening section, exactly how damaging this software can be will very much depend on the intentions and skills of the person ‘behind the wheel’.



How does it work?
When an attacker decides to use EvilOSX, they basically build a new executable on their own system from the downloaded project, and then find a way – through social engineering or exploiting some other vulnerability – to run that executable on the target’s system.

There is no ‘zero-day’ here, and out of the box EvilOSX doesn’t provide a dropper to infect a user’s machine. That means everybody already has a first line of defence against a malicious attacker with this tool: Prudent browsing and careful analysis of anything you download, especially in terms of investigating what a downloaded item installs when you run it (DetectX’s History function is specifically designed to help you with this).

EvilOSX doesn’t need to be run with elevated privileges, however, nor does the attacker need to compromise the user’s password. As intimated earlier, it’ll run with whatever privileges the current user has (but, alas, that is often Admin for many Mac users). All the attacker needs to do is to convince the victim to download something that looks innocuous and run it.

Once run, the malicious file will set up the malware’s persistence mechanism (by default, a user Launch Agent) and executable (the default is in the user’s ~/Library/Containers folder) and then delete itself, thus making it harder to discover after the fact how the infection occurred.

After successful installation, the attacker can now remotely connect to the infected machine whenever both the client (i.e., victim) and server (i.e., attacker) are online.







Once the attacker has surreptitiously connected to the client, there are a number of options, including webcam, screenshots, and downloading and exfiltrating browser history.







In my tests, some of the modules shown in the above image didn’t work, but the webcam, screenshots, browser history and the ability to download files from the victim’s machine were all fully functional.



Customisation options
By default, EvilOSX will offer the attacker the option of making a LaunchAgent with a custom name – literally, anything the attacker wants to invent, or to use the default com.apple.EvilOSX.







That in itself isn’t a problem for DetectX Swift, which examines all Launch Agents and their program arguments regardless of the actual filename. The malware also offers the option to not install a Launch Agent at all. Again, DetectX Swift will still look for the malware even if there’s no Launch Agent, but more on this in the final sections below.

If configured, the malware installs the Launch Agent and, by default, points it to run a binary located at ~/Library/Containers/.EvilOSX. There’s no option for changing this in the set up routine itself, but the path to the program argument is easily modified if the attacker is willing to do some basic editing of the source code.







Making matters even more difficult is that with a little know-how, the attacker could easily adapt EvilOSX to not use a Launch Agent at all and to use one of a variety of other persistence methods available on OSX like cron jobs, at jobs and one or two others that are not widely known. I’ll forego giving a complete rundown of them all here, but for those interested in learning more about it, try Jason Bradley’s OS X Incident Response: Scripting and Analysis for a good intro.



String pattern detection
Faced with unknown file names in unknown locations, how does an on-demand security tool like DetectX Swift go about ensuring this kind of threat doesn’t get past its detector search? Let’s start to answer that by looking at the attack code that runs on the victim’s machine.

We can see what the attack code is going to look like before it’s built from examining this part of the source code:







As the image above shows, the structure and contents of the file are determined by the output_file.write commands. Before exploring those, lets just take a look at what the finished file looks like. Here’s the start of the file:







and here’s the final lines:







Notice how the first four lines of the executable match up with the first four output_file.write commands. There’s a little leeway here for an attacker to make some customisations. The first line is required because, as noted by the developer, changing that will effectively nullify the ability of the Launch Agent to run the attack code. Line 4, or some version of it, is also pretty indispensable, as the malware is going to need functions from Python’s os module in order to run a lot of its own commands. Line 3, however, is more easily customised. Note in particular that the output_file.write instruction defines how long the random key shall be: between 10 and 69 (inclusive) characters long. One doesn’t have to be much of an expert to see how easy it would be to change those values.

Line 5 in the executable is where things get really interesting, both for attacker and defender. As it is, that line contains the entire attack code, encrypted into gibberish by first encoding the raw python code in base64 and then encrypting it with AES256. That will be random for each build, based on the random key written at Line 3. We can see this in the next image, which shows the encrypted code from three different builds. Everything from the highlighted box onwards to the last 100 or so characters of the script are random.







However, as one of my favourite 80s pop songs goes, some things change, some stay the same. The first thing that we can note, as defenders, is that when this code is running on a victim’s machine, we’re going to see it in the output of ps. If you want to try it on your own machine, run this from the command line (aka in the Terminal.app):

ps -axo ppid,pid,command | grep python | grep -v python

That will return anything running on your Mac with python in the command or command arguments.

Of course, the victim (and yourself!) may well have legitimate Python programs running. To limit our hits, we can run the file command on each result from ps and see what it returns. Our attack code, being a single, heavily encrypted and extremely long line in the region of 30,000 characters, will return this indicator:

file: Python script text executable, ASCII text, with very long lines

That still isn’t going to be unique, but the test will futher narrow down our list of candidates. We can then use string pattern detection on the remaining suspects to see which contain the following plain text items,

import os

exec("".join(os.popen("echo

-md sha256 | base64 --decode")

readlines()))

We could arguably even include this:

U2FsdGVkX1

which occurs immediately after echo, but for reasons I’m about to explain, that might not be a good idea. Still, from the default source code provided by the developer, if we find all of those indicators in the same file, we can be reasonably certain of a match (in truth, there’s a couple of other indicators that I haven’t mentioned here in order to keep DetectX Swift one-step ahead of the attackers).

Unfortunately for defenders, the attacker has a few workarounds available to them for defeating string pattern detection. To begin with, the attacker could adapt the code to use something other than base64, or indeed nothing at all. Similary, AES256 isn’t the only option for encryption. For these reasons,we can’t assume that we’ll find something like U2FsdGVkX1 in the malicious file. Then, there’s the original source code’s use of the long-deprecated os.popen. That is an odd choice to start with, and someone with a bit of experience in Python would be able to rewrite that line to avoid the telling indicators.



Skill level and customisation options




Advanced detection options
At this point you may be feeling that the attacker holds all the cards, and to a certain extent that is true, but there are some positive takeaways. First, we can be fairly sure of catching the neophyte hackers (aka “script kiddies”) with little to no programming experience who are trying to hack their friends, school or random strangers on the internet. The motivation to adapt the code is probably not going to be there for a large number of people just doing it 4 the lulz.

Secondly, depending on your tolerance for investigating false positives, and as I’ll explain how below, if you needed to be super vigilant, you could simply check on every python executable running on your Mac which file identifies as having ‘very long lines’. For sure, there are legitimate programs doing that, but the number still isn’t going to be that high on any given machine, and the paths to those legit programs are going to be readily identifiable. If security is of overriding importance, then it’s not much inconvenience, and time well spent.

By default, DetectX Swift will find instances of EvilOSX running on a mac when it’s used out of the box, and when its used with a modified launch agent and executable path. It will also still find it when the attacker has made certain alterations to the source code. However, a determined attacker who chooses to rewrite the source code specifically to avoid string pattern detection is always going to be one-step ahead of our heuristics.

We are not out of options though. You can still use DetectX Swift combined with the Terminal.app as a means to making custom detections as mentioned above. Here’s how:

1. Launch DetectX Swift and allow it to search for the variations of EvilOSX it knows about. If nothing is returned, go into the Profile view.
2. Click inside the dynamic profiler view, and press Command-F and type python into the search field.
3. If there are no hits in the Running Processes section, you don’t have EvilOSX running on your machine.
4. If there are any hits within the Running Processes section, make a note of each one’s command file path by selecting it in the view and pressing Command-C to copy it.



5. Switch to the Terminal app, type file (with a space) and Command-V to paste. If the path has any spaces in it, surround it in single quotes. Then press return.
6. If the path doesn’t come back with ‘very long lines’, the file isn’t EvilOSX.
7. If it does, hit the up arrow on the keyboard to put the previous command back at the prompt, use Control-A to move the cursor to the beginning of the line, and replace the word file with cat (if you’re familiar with Vi or similar command line text editors use one of those instead). Hit return.

Inspect the output from cat with the following in mind:

8. Does the file end with readlines()))?
9. Use command and the up arrow to go back up to the beginning of the file. How close does the file look to matching what you’ve seen here? Look for variations like import * from os and import subprocess.
10. Consider the path that you pasted in. Is it something that looks like it belongs to a genuine program, or is it a completely unfamiliar? Anything that points to ~/Library and isn’t contained within a recognized application named folder should warrant further investigation.

You’ll need to consider carefully the answers to 8, 9, & 10, with an emphasis on the latter, for each python file you tested to make an assessment. If you’re in any doubt, contact us here at Sqwarq and we’ll be glad to take a look at it and confirm one way or the other.

Conclusion
EvilOSX is just one of an increasing number of Python RAT projects that are appearing on the internet. It’s not particularly sophisticated, and this is both a strength and a weakness. With modest programming skills, an attacker can modify the source code to increase the chances of evading automated detections. However, vigilant users can still identify EvilOSX if they know what to look for, as explained in the preceding sections of this post, or by contacting Sqwarq support for free advice.

Stay safe, folks! 🙂

What’s the difference between DetectX and DetectX Swift?

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.

Of course, if you have any questions drop me a comment below, or email me either at Sqwarq or here at Applehelpwriter.

Enjoy 🙂

scan for malware on the command line

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:

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! 🙂

DetectX Swift History

DetectX Swift beta has arrived

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! 🙂

why malware loves auto login (and why you shouldn’t)

Whenever I talk to people about the dangers of having their mac set to login automatically without requiring a password, I’m often waved away as an old worryguts. “I’m the only user on my mac”, they say, and “My mac is unlikely to get stolen”.

These optimistic dismissals may turn out to be true or false, but aren’t really relevant to the main security issue. Auto login presents a threat to anyone connecting to the internet.

To see why this is so, let’s look at how auto login works. First of all, the user enables auto login through System Preferences’ ‘Users & Groups’ pane. Open the pane and click on the Login Options item at the bottom of the sidebar (see the screenshot above). Choose a user from the ‘Automatic login:’ pop-up menu. You’ll need to provide the account password.

Where it gets interesting is what macOS does next with that information. You might perhaps think it secures that information safely in your Keychain, but that wouldn’t work at all. Your Keychain needs a user password to unlock it, so auto login can hardly unlock your Keychain to get the stored password out. No, it needs to be stored somewhere else that can be accessed when the computer starts up.

That place is in the hidden folder /etc/, and specifically in a file called kcpassword. This is outside of any user’s Home directory, so the system doesn’t need a user password to access it.

However, if you try to open that file to read it yourself (we’ll do this shortly, hold on), you’ll find you can’t read it without providing your admin password (the boot process already runs as root, so it doesn’t have this problem). For reasons we’ll see in a moment, you’d be mistaken to take much comfort from that in terms of security, but lets stick with /etc/kcpassword for a while first.

Now here’s something anybody can do, with or without elevated privileges (and by ‘anybody’ here we also mean ‘any process’): test to see if /etc/kcpassword exists. The file is only created when auto login is enabled, and it’s deleted when it’s turned off; thus, existence of the file is a simple way to check whether a mac has auto login enabled without needing to go through a user’s System Preferences pane.

A malicious program, for example, might run some code like this to test whether a target system is set to auto login:







If the file does exist, then passwordExploit will be ‘TRUE’, and all the attacker has to do now is execute code to read and parse the file:







We can take a look at what the file contains easily enough from the command line. Assuming you have auto login enabled (or you could just enable it temporarily for fun if you want to play along), try

sudo cat /etc/kcpassword

As we’ve already seen, you’ll need a password to see the password, but this isn’t a problem that’s going to phase a malware author, and nor does it mean that the malware author won’t be interested in the prize. Again, hold those thoughts while we look at what’s inside the kcpassword file.

Here’s what mine contains:







Hmm, goobledygook, it seems. Encrypted nonsense that surely takes a lifetime to break, no? Far from it. Be ready to behold the masterpiece of wisdom, humour or nearest book title that is your password by pasting this into the command line:


sudo ruby -e'key=[125,137,82,35,210,188,221,234,163,185,31];
IO.read("/etc/kcpassword").bytes.each_with_index{|b,i|break if key.include?(b);
print [b^key[i%key.size]].pack("U*")}'

Tradaa! And here’s my inglorious password: k33p_out_th3_badi3z.







How is that possible? No, it’s not some secret new encryption breaking technique. The fact is the kcpassword is not encrypted at all, it’s XOR’d. To see the basic idea, take the first character, ‘?’. The asci code for ‘?’ is 63 (this is for demonstration purposes only; the actual XOR’ing is done in hexadecimal rather than the simpler decimal used in this example). That number in binary is 00111111. To XOR it, all I have to do is provide another binary number, lets say 84, which is 01010100, and apply the rule that for each equivalent bit in the two numbers, if the bits are the same we output a zero, and if they are different we output a 1. Thus, ‘?’ (63) ^ ’T’ (84) comes out like so:

00111111 (asci 63 = ‘?’ – encoded password character)
01010100 (asci 84 = ’T’ – XOR mask)
—————
01101011 (asci 107 = ‘k’ – plain text password character)

Now, if we go through each of the characters in my encoded (note, not ‘encrypted’) password, and apply the correct XOR mask for each, we can reveal the password — note the mask for the first character in my demo was 84, but each character is XOR’d with a different mask — and that’s precisely what the Ruby script we used above did (again, noting that the masks are in hex rather than decimal).

OK, now you may have some questions. 🙂 The first is probably: do Apple KNOW THIS!? Oh sure, of course! Nobody uses XOR for security, at least not like this, but you can’t blame Apple that much. It’s a reasonable assumption on their behalf that if a user sets their computer to auto login, security isn’t high on their priority list. The second reason why Apple probably feel unconcerned by this is that you need a password to see the password, so surely there’s no real danger?

That may have made sense 30 or 40 years ago when the only people who had admin passwords were, well, administrators, and when processes couldn’t easily exfiltrate data via the internet. It doesn’t make much sense nowadays in a computing environment where people download software from unknown sources which immediately asks the user for a password to install and then phones home. Users rarely say ‘no’ to such requests (after all, they downloaded the software because they wanted to run it, right?) and almost certainly have no idea what processes run with admin privileges as a result.

It would also be a mistake to believe that, in this scenario, a piece of malware that has just tricked the user into providing an admin password to install would not need or want to run the exploit against the kcpassword file. Far from it.

Usually, when apps ask for your password to install, they don’t get to see the password directly. Some malware will present a false dialog to do this, but most will take the easier (and less suspicious) route of letting macOS mediate the process. A legitimate password dialog box is actually from macOS, and it only grants privileges to the requesting app; it does not give them the password in plain text. But the plain text password is the holy grail of malware persistence: as powerful as elevated privileges are, they may also be temporary, limited, and revoked; they also can’t be stored or easily transferred.

To see why this matters, consider a piece of malware that gains elevated privileges through the OS in the way described, but not the password. If the malware is discovered, it can be removed. If the attacker wants to strike again, they have to fool the same person into the same trick of installing their software as they did before. In a world where we’re all increasingly ‘once-bitten twice shy’ when it comes to computer security, that’s not a trivial task.

On the other hand, if the attacker gains the plain-text password from the first attack, this can either be stored elsewhere on the victim’s computer (somewhere that doesn’t need privileges to be accessed) or even sent back to the attacker’s remote command and control server. In that case, even deleting the malware isn’t going stop the attacker (indeed the attacker may delete the malware themselves to avoid detection!). All they have to do is connect to your mac remotely, input your admin password and they’re straight back in again.

I hope it’s clear from this that due to the weak obfuscation of the kcpassword file, auto login is a tremendously bad idea. It doesn’t matter whether your mac is locked in a one-person vestibule with round-the-clock guards. It’s when your mac is in use that it’s vulnerable.

Moral of the tale: disable auto login, folks, especially those of you that just enabled it to play along with this post!



Acknowledgements:
Ruby script: http://osxnotes.net/passwords.html
Background info: OSX Incident Response – Jaron Bradley

how to reveal hidden users

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.

The 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.

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

Next, we need to change the IsHidden key in dscl for that user, so

sudo dscl . -change /Users/dev IsHidden 1 0

In the above command, substitute my user’s shortname dev for the shortname of the user on your machine. The 1 0 is the old value (hidden) followed by the new value (unhidden). The line can be read as “change User dev’s IsHidden value from hidden to unhidden.”

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.

Enjoy! 🙂