Updated from version 2.8.1 to 2.9 Crowdstrike altert from IT

[eraldtroja]

I can provide more details as I get them from IT but in a nutshell this has occurred and I need some guidance.

I was at version 2.8.1 as of yesterday morning. I fired up the following commands to update my ports:

sudo port selfupdate
sudo port upgrade outdated
sudo port uninstall inactive

I'm running MacOS Sonoma 14.3. The system is managed by my IT department.

Within minutes of performing the update I received calls from IT stating that Crowdstrike had alerted them of a data dump, hence my machine would need to be brought in for a complete wipe.

I think this might be a case of a false positive, and I'll provide more details if needed, but I need to get some guidance of what an update from 2.8.1 to 2.9 does in order to possible categorize it as a false positive when it comes to a "data dump"

Thank you.

[jmroot (Joshua Root)]

Selfupdate involves downloading the latest tarballs of MacPorts base and the ports tree with rsync, then installing base if outdated, which is essentially just a typical ./configure && make && make install. I don't know what Crowdstrike considers a "data dump" so it's hard to say what might have triggered it. There was another ticket about Crowdstrike, where it didn't like the installer script examining and updating the macports unprivileged user account that we use for running builds: #66878

[eraldtroja]

Replying to jmroot:

Selfupdate involves downloading the latest tarballs of MacPorts base and the ports tree with rsync, then installing base if outdated, which is essentially just a typical ./configure && make && make install. I don't know what Crowdstrike considers a "data dump" so it's hard to say what might have triggered it. There was another ticket about Crowdstrike, where it didn't like the installer script examining and updating the macports unprivileged user account that we use for running builds: #66878

Ok, where can I get some documentation on what are the exact system changes that ./configure && make && make install brings onto the system in order to have IT consider it and perhaps bring it up with Crowdstrike to classify it as a false-positive?

I practice very good cyber hygiene, so I am 100% confident that this is the only change that has triggered their alert.

Thanks!

[jmroot (Joshua Root)]

./configure && make builds the source and shouldn't change anything outside the build directory. make install creates, deletes, and/or updates the files that comprise the MacPorts base installation, and creates or updates the macports user. That's pretty much it. ​https://github.com/macports/macports-base/blob/v2.9.0/Makefile.in#L34

[semoore_pfpt (S M)]

Hello, sorry to bump this ticket, but I also received a Crowdstrike alert from my Security Department. The trigger for this alert is specifically these lines which Crowdstrike categorizes as "user credential dump".

​https://github.com/macports/macports-base/blob/release-2.10/Makefile.in#L46-L53

I uninstalled Macports and reinstalled without root privileges (Using steps in this Github gist: ​https://gist.github.com/daggerok/d6c7ed8b9efa03b30ffd0e9f44cdd121)

Unfortunately, the Crowdstrike alert triggers even if you install Macports without privileges (EG: port selfupdate). Apparently calling dscl at all will generate an alert on Crowdstrike. Is there a way to skip the user / group check on install?

[jmroot (Joshua Root)]

I guess the most expedient workaround would be to make the outermost if statement also check for root privileges, i.e. change line 46 of the Makefile from

@if test -n "${DSCL}" -a -n "${DSEDITGROUP}" ; then \

to

@if test "$(id -u)" -eq 0 -a -n "${DSCL}" -a -n "${DSEDITGROUP}" ; then \

[jmroot (Joshua Root)]

In 426ded6078e1e04ef8ff960f4f73a902cf3e06c9/macports-base (master):

Makefile: Avoid running dscl when not root

See: #69187

[djzort (Dean Hamstead)]

I have just encountered this same issue upgrading to 2.11.0

I am using "sudo port selfupdate" so $(id -u) is going to return 0 and run $DSCL causing crowdstrike to freak out.

[jmroot (Joshua Root)]

We really do need to create and/or modify the macports user, so I don't know what can be done except to teach Crowdstrike that it's OK for the MacPorts installer to do that.

[djzort (Dean Hamstead)]

Without reading through the code in great detail, could macports save that information in the config file and just assume it ongoing?

[jmroot (Joshua Root)]

No, we need to actually create an unprivileged user, and if that user already exists but has the wrong home directory set, we need to correct that.

[semoore_pfpt (S M)]

Hello again, still encountering this issue. Our security department still reaches out when I run port selfudpate even though I've installed nonroot.

I've gone ahead and switched to the git installation method (​https://guide.macports.org/#installing.macports.git) but I can't run the make install recipe without encountering the following (crowdstrike related) issue: #63656

The workaround mentioned in the issue above works.

1. macports-base repository cloned
2. Edit Makefile.in
3. Completely remove the @if test `id -u` -eq 0; then, these lines: ​https://github.com/macports/macports-base/blob/v2.11.3/Makefile.in#L49-L95 .

Sorry to keep bumping, but can we add another conditional to Makefile.in? We could add another Makefile conditional that completely skips the user check if --with-no-root-privileges was set on ./configure.

I'd take a stab at a PR myself, but I don't quite understand the flow of ./configure -> Makefile.in -> Makefile.

Pseudocode below

ifeq ($(DESTDIR),)
    # don't attempt to manipulate local user if --with-no-root-privileges set
    ifeq ($(NOROOTPRIVS),)
    @if test `id -u` -eq 0; then \
        # ... DSCL stuff that triggers crowdstrike \
        # probably because the heuristic interprets it as a crazy one-liner \
    fi
    endif
endif

[jmroot (Joshua Root)]

OK, the fact that Crowdstrike is pattern matching on the whole shell command string and not looking at the dscl commands that actually end up running explains a lot. We can probably try something like what you suggest.

[jmroot (Joshua Root)]

In a21537738175c08ed31f9f16d4703c3c51be215b/macports-base (master):

Avoid dscl commands entirely if not root

Apparently Crowdstrike only cares that the shell script being executed
mentions 'dscl' and 'Password', regardless of whether it's in a
conditional branch that never gets executed.

See: #69187

[semoore_pfpt (S M)]

I just successfully installed 2.11.4 with no Makefile.in changes! Thank you @jmroot !

I believe your fix will close #69187 (this issue) and #63656.

export MACPORTS_HOME="${HOME}/.local/state/macports"
test -n "$MACPORTS_HOME" && \
  ./configure \
      --enable-readline \
      --with-no-root-privileges \
      --prefix="$MACPORTS_HOME" \
  && make && make install

[jmroot (Joshua Root)]

Well, the reporter of this ticket was using sudo, but I closed #63656 at least.

[emrecio]

tl;dr: remove old macports user using "sudo dscl" (see wiki), download tarball of latest release, "configure; make; sudo make install"

Please note, I was running into the same issue. It might have had something to do with how the macports user was installed back in 2022. I removed it completely (using sudo dscl . -delete...) commands on the uninstall wiki page. Removed the /Users/macports directory.

Downloaded the tarball for latest macports (instead of running selfupdate, since selfupdate was killed by crowdstrike before finishing, and reports itself as already upgraded - is there a force option for selfupdate?); and did a "configure/make/sudo make install" and it seems to have created the macports account completing without error! :)

Some Background what I researched:

The cs trigger killing it (when I ran "make install" as sudo with the old macports account still in place) was:

.*/bin/bash.*
/bin/sh\s+-c\s+if\s+test\s+`id\s+-u`\s+-eq\s+0;\s+then\s+if\s+test\s+-n\s+"/usr/bin/dscl"\s+-a\s+-n\s+"/usr/sbin/dseditgroup"\s+;\s+then\s+if\s+!\s+/usr/bin/dscl\s+-q\s+\.\s+-read\s+"/Groups/macports"\s+>\s+/dev/null\s+2>\&1\s+;\s+then\s+echo\s+"Creating.*

Note: the cs trigger killing it from "sudo ports selfupdate" starts with ".*/bin/sh.*" instead. Note: even after putting in an exception for the cs triggers for macports, it would still kill the process if the process attempted to run the dscl command. (As noted above) removing completely the following if starting with:

ifeq (,)
# create run user if it doesn't exist
...

from the Makefile allowed it to "complete" (or at least run to the end with no further errors.

However, long term fix it seems like completely removing the old macports account might have done the trick??? I went through the entire process from scratch with no mods and it worked... We'll see after the next upgrade.