Author Archives: philastokes

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.

learning the Terminal : Part Four


One of the obstacles in becoming a command line guru is actually figuring out not just what’s available (see learning the Terminal: part Three) but how to use it. That just got a whole lot easier thanks to a (relatively) new tool called tldr.

Most command line (CLI) utilities come with either a man page or a help command, invoked either by man or </path/to/tool> --help, respectively. That’s traditionally the way we learn all the ins-and-outs of a given tool. If you’re lucky, there will be some examples at the end of the man page, and if you’re luckier still, there’ll be an example of exactly what you want to do with the tool there, too.

But what if you’re not lucky? Some CLI tools come with very few or no examples, some come even without a help command or man page. When that happens, prior to tldr your best bet was to go on an internet search or ask a friendly CLI expert if you knew one.

Now, tldr provides a third, and perhaps better, option. Unlike traditional man pages, tldr just spits out some basic examples of the CLI tool you specify, and that (more often than not) may be all all you need to get going (see the screenshots for examples).

If you have brew installed, you can get tldr easily with the command

brew install tldr

If not, either install homebrew first, or see the tldr homepage for other ways to install.

Using it is simple. Try some of these for fun:


tldr find
tldr awk
tldr sed
tldr cut

and so on. Here’s the output for tldr grep:

The one thing tldr doesn’t seem to have built in that I can find is a list of the commands it knows about. There is a workaround, though. You can search through the tldr pdf to see what’s available. Alternatively, we can us a bit of command-line magic to do it for us:

find ~/.tldrc -path '*common*' -or -path '*osx*' | cut -d"/" -f8 | cut -d"." -f1 | sort

If you’d like to make that into a nice little function that you can call simply with something like tldr_list, review the first post in this series on how to make and add functions to your .bash_profile.

As tldr is a community-based program, it is likely to be added to quite regularly (I have a few I’m planning to contribute myself), so we can only hope that the pdf is updated regularly and/or that tldr gains a proper introspective list function.

Speaking of updates, if you try tldr on itself, i.e,

tldr tldr


you’ll note the ‘update’ command. It’s probably worth remembering to run that from time to time. tldr also comes, of course, with its own man page, too!

Enjoy! 🙂
Related Posts
learning the Terminal – Part One
learning the Terminal – Part Two
learning the Terminal – Part Three

Apple’s keyboard shortcut to show hidden files


Time was this would take a trip to the Terminal, but if you’re running Sierra or above there’s a handy new keyboard shortcut.

Just activate the Finder and hold down shift-command-period. Repeat to toggle invisible files off again.

This works not only in save and open dialog sheets, but in regular Finder windows also.

Magic! 🙂


how to easily spoof a user’s password





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

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

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

How can you check?

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


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

Search & remove with DetectX Swift

getting ready for DetectX Swift

Screen Shot 2017-10-04 at 16.18.14

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.

 

how to retrieve forgotten Wifi password


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.

Get the script from my pastebin

Enjoy!

how to remove “Plugins Button” from Chrome





Update: DetectX v2.75+ now deals correctly with the Plugins Button adware and the instructions below are now redundant.  Just ‘Search’ and ‘Trash All…’ should be sufficient.



 

If you’re having trouble trying to remove the “Plugins Button” from Chrome because its ‘managed and cannot be removed or disabled’, then follow this procedure.

1. Launch DetectX and do a search. You should see at least 5 items. Do NOT click the Trash button yet.

2. Quit Chrome

3. In Terminal, execute this command* (you’ll need admin privileges)

sudo /usr/bin/profiles -P; sudo -K

If you see a single configuration profile installed with the profileIdentifier ‘org.superduper.extension’, then execute

sudo /usr/bin/profiles -D; sudo -K

to remove it.

Type ‘y’ when prompted.

4. Read the caveats below, and then if appropriate, in DetectX, now click the ‘Trash All…’ button.

5. Relaunch Chrome and check that all is well.

Caveats
* If you or the machine’s administrator are using ‘Managed Preferences’ and have profiles other than the one mentioned above installed, then do NOT use the ‘-D’ switch in step 3. You’ll need to identify the correct profiles. Use the -P switch to list the installed profiles and only delete the one with ‘org.superduper.extension’ identifier. Likewise, do NOT use the Trash All… feature in DetectX, which will remove the Managed Preferences folder***. Instead, double-click the items in DetectX’s window to open them in Finder and remove them manually that way.

** You’ll need to authorise the deletions when macOS asks you as DetectX doesn’t have the permissions to do that (a safety feature).

*** Note that the ‘Managed Preferences’ folder is a perfectly legitimate folder for server admins that have knowingly installed managed preferences for their users, or for those using Parental Controls. An application update for DetectX will be released shortly to more accurately target this issue rather than flagging the entire Managed Preferences folder.

%d bloggers like this: