[RJIb8RBYxzAMX9u]

osquery is not a built-in tool. You can get the same info with plutil(1):

  $ sudo plutil -p /private/var/db/dslocal/nodes/Default/users/root.plist

If I understand OP correctly, if passwd is a lone asterisk, then you haven't been exploited.

Edit: trying a little harder to dump accountPolicyData:

  $ sudo defaults read /private/var/db/dslocal/nodes/Default/users/root.plist accountPolicyData | grep -oE '[[:xdigit:]]+' | xxd -r -p

[simias]

>if passwd is a lone asterisk, then you haven't been exploited.

At the risk of sounding a bit pedantic you can't really assume that, it's possible that somebody used this vulnerability, installed some sort of backdoor and then disabled the account to hide their tracks.

[abritishguy]

That's correct.

[princekolt]

Bad news: I tried the exploit in my macOS Sierra installation and it didn't seem to work. However, the passwd entry on the output of your first command IS A LONE ASTERISK.

However I still can't login as root. This leads me to believe this behavior has always been there, and maybe the login methods just didn't allow an empty password.

[ybloviator]

This is very normal in 'nix' systems. '' indicates a locked account. (I've given up figuring out how to escape an asterisk)

ex:

  daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
  operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
  bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
  tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin

If the OS is letting you in with a '*'in the encrypted password field, something is very very wrong.

[warent]

I'm confused, why do you have to escape an asterisk?

[HarfTarf]

He's stuck inside

[vsl]

Markdown in HN comments.

[royprins]

Famous last words of a Roman centurion.

[adrianratnapala]

Nah, I've never seen them do worse than knock people out. Probably the next thing the centurion said was "Ow, what hit me!".

[kr3wn]

wildcard.

[dep_b]

Only High Sierra is affected.

[timsutton]

`sudo dscl . -read Users/root accountPolicyData`

[edjw]

When you do this you'll get the creationTime and passwordLastSetTime as seconds since the 'epoch' – January 1, 1970, 00:00:00 (UTC). These are numbers like 1474441704.265237 which aren't very easy for a human to read :-)

To convert this into a human-readable date and time, open a terminal and do this:

  python

  >>> import time

  >>> time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime(1474441704.265237))

You'll get something like 'Wed, 21 Sep 2016 07:08:24'

(I'm sure you can do this in other languages than python...)

[fauigerzigerk]

If you're already in the terminal you could instead enter

  date -r 1474441704

[edjw]

This is a much better answer!

[mhandley]

One of my Macs is showing a root password change date of Nov 10th 2017. I can't explain that, so I'm reinstalling now. It did have sshd enabled and remotely accessible, though I thought root login was prohibited.

If I understood correctly, this particular bug was only exploitable from the GUI and this machine hasn't been away from home, so it's likely this isn't related, but posting here, in case it's part of a bigger picture.

[marcelfahle]

OK, I guess when doing OP's root trick, the root user gets activated/created, and that's that's when the PW gets set to empty. I guess that's where my passwordLastSetTime comes from.

[haZard_OS]

This works remotely as well (although not through SSH, obviously).

[danielrangel]

possibly the same timestamp here: 1510300538.767916 'Fri, 10 Nov 2017 04:55:38'

[gurkendoktor]

Oh wow. Is there any other explanation for this other than this having been exploited in the wild for almost three weeks? Or maybe someone just tried to log in over SSH to exploit some other weakness (something like predictable SSH passwords on jailbroken iOS devices), and happened to create the root user on your machine?

Did you also have sshd running, and do you know what kind of network you were using at the time?

[marcelfahle]

My root pw passwordLastSetTime says this morning.. the fuck??