App bundle containing shell script cannot be blocked

[alexmac]

As explained in the design doc Santa makes no attempt to support blocking of shell scripts - which is understandable in general. But in the case of a user double clicking a ".app" containing a shell script or a ".sh" file directly from the finder it seems much more reasonable to allow for some way to block this action.

Perhaps you have already spent some time considering the feasibility of this, but I would like to discuss how this could be achieved - one thing that comes to mind is that if we had the ability to blacklist a process (bash) based on its parent process (launchctl) we might be able to block this vector of attack

Clearly this wouldn't prevent a user opening terminal and running malware, but we care more about preventing our non-technical staff from being tricked into running simple malware

[russellhancox]

makes no attempt to support blocking of shell scripts

This isn't completely accurate - it won't block a shell script that hasn't been explicitly whitelisted or blacklisted so if you want to block a shell script by its hash, you can do so.

There is an open feature request (#293) to support rules that are based on the parent process but we haven't spent much time thinking about it as it's a feature with a lot of potential for causing mysterious issues.

[alexmac]

Here's the real-world scenario we encountered:

• one of our Macs was configured with gatekeeper set to "allow apps downloaded from App Store and identified developers"
• a signed app bundle (presumably a stolen/compromised cert) was downloaded by a user and run
• this app bundle used a shell script as it's main executable instead of a binary, so our santa binary whitelist did not apply

Obviously we've now updated our macs to force the stricter gatekeeper setting of "app store only" which is presumably a higher bar for someone to get a compromised app bundle created, but it would be good to have prevented this app from running without relying on gatekeeper

[russellhancox]

I see. We've generally avoided blocking shell scripts by default in lockdown due to the administrative overhead (there are lots of places where scripts are auto-generated) and the ease of bypass (running "bash script.sh" bypasses Santa). However, I can see this particular case being more useful than most and probably wouldn't be as affected by these 2 pitfalls - the ease of bypass still applies but the bar is at least raised.

I'm not certain that this can be implemented in a way that we'd be satisfied with for everyone, though we could possibly add it behind a configuration option or by adding a 3rd client mode.

@tburgin any thoughts?

[tburgin]

I think this could fit into a new scope, with some caveats. Essentially we would be disabling the Not a Mach-O scope in certain situations. If we do, then we must also check the code signature (the extended attributes kind) of these special non Mach-O executables during the rule phase. This is to handle the case where the script is a valid whitelisted code signed script.

A few "certain situations" could be:

• ppid is 1
• executing vnode is the CFBundleExecutable

Some downsides:

• This would be a performance hit on every santad exec decision. We could probably do some optimizations to make it as minimal as possible.

• Adds complexity to the exec allow / deny flow.

Should we do it?

If it is behind a configuration, I would be okay with it.

[porteusconf]

In higher ed, especially stem, folks must use lots of open-source software, most not in the app-store. So we cannot choose "App Store only" but must "allow apps downloaded from App Store and identified developers". That said, we require that everyday accounts be non-admin as damage control.

In any case, sounds like blocking scripts hidden inside .app bundles might be useful, at least for a while, if it can be done without breaking too much. But note that packagers/bundlers for python (like py2app) and java (like Install4j) can have scripts in the .app routinely and/or to run command-line-only interface to the software.

BTW, I also see lots of shell scripts/malware used by both valid and malicious apps and pkgs to install software. In past years Dropbox, Zoom-video-call and others have abused pre and post install scripts, a favorite tool of malware writers. And I bet a shell script was, at least until Aug 2020, used by the the Jamf enrollment process per https://www.jamf.com/jamf-nation/feature-requests/9531/jamf-enrollment-improvement-suggestion

"InstallApplication, [which used to be] a zero payload pkg which then curls down the jamf binary."

On a side note Apple will stop shipping macos with python, perl and ruby in the future. So, when ruby is gone, for example, the homebrew install script will need to curl a working ruby or some similar bootstrap.

Soi, I hardly ever install pkg without first looking at the all the scripts with pkgutil, Pacifist, and/or Suspicious Package And always good to look at [~]/Library/LaunchDaemons and LaunchAgents before and after, and well as [~]/Library/Application Support where malware often drops official-sounding payloads.

For .app bundles, always worth a peek around the Macos and Resources folders as well for anything out of ordinary.

[EdRowe]

I would love to see this addressed. It is a weakness that malware writers are actively exploiting for which there is no easy mitigation at this time.