Clickfix not needing Terminal Copy/Paste on MacOS

Threat Intel
,
1

**‪**Interesting development in ClickFix working through a script editor on MacOS. Taking a step out of the process via copy/paste could result in more people getting infected. How long if not already, will they do this for windows?

1 Like
2

I can’t believe AppleScript is still around—and apparently, critical infrastructure to macOS. Things seems to break when you disable it.

3

Legacy, the second worst security hole in the world.

4

Okay, let’s talk actionability. How does one disable URL scheme handlers on macOS, to prevent applescript:// links from doing anything?

5

Jamf has some extra info from several years ago from a previous URL-scheme-related issue: Remote Mac Exploitation Via Custom URL Schemes

6

Which in turn references this older Objective-See post.

So basically any application can include itself as a handler for document types in its Info.plist, which in turn will inform Launch Services.

Now, reversing from the info in this SO article, we in theory could attempt something like:

plutil -insert "LSHandlers.0" -json '{"LSHandlerPreferredVersions":{"LSHandlerRoleAll":"-"},"LSHandlerRoleAll":"come.apple.TextEdit","LSHandlerURLScheme":"applescript"}' ~/Library/Preferences/com.apple.LaunchServices/com.apple.launchservices.secure.plist

Which would make applescript:// links open in TextEdit, similar to how we disable .js files on Windows by having them handled by Notepad.

I don’t have a Mac to test this one, but I’d love to confirm this.

1 Like
7

Bumping this. I really want to figure out if this works to kill AppleScript URIs.

8

Okay, after messing with .plist files, something I haven’t done in years, it would appear that the easiest move here is to install duti.

brew install duti
duti -s com.apple.TextEdit applescript

It’s not perfect, but it at least defends against opening these files in a script interpreter.

Interesting note: each application’s Info.plist determines what kinds of files it can actually handle. So while TextEdit will open, it will not do anything with the contents of the URL.

9

AppleScript runs off of /usr/bin/osascript

Maybe poke around with the settings or add a passthru to osascript that helps secure the system? Like a tailored try/catch to scan the file and yank out applescript://calls or mutate them into :red_apple: 's :slight_smile:

10

That’s not how the URI handlers work, unfortunately. The above is the best we can do without dangerously mutating plists.

1 Like
11

I haven’t really poked, just scanned a few articles for a bit.

I have a mac. Let me charge it and get it up to date…

12

One concern I have is that duti is making a call to a deprecated API function, so no idea how long that will last.

And…it does kinda seem like an abandoned project.

13

Ah! But this is not, and appears to do the same:

Except…it’s using the same deprecated API command. I’m not a macOS systems programmers, so maybe that’s fine? I don’t know how frequently they yank those out of there.

1 Like
14

So they work, but is this a reasonable remediation for the posed risk? Mac admins, would you deploy a .pkg and some postInstall scripts via Jamf or Munki to nerf a threat vector like this?

1 Like