undefined | Better HN

0 pointsabritishguy8y ago0 comments

Just in case it is relevant for anyone here this is what our security team have established thus far:

- Can be mitigated by enabling the root user with a strong password

- Can be detected with `osquery` using `SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" AND key = "passwd" AND length(value) > 1;";`

- You can see what time the root account was enabled using `SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" WHERE key = "accountPolicyData";` then base 64 decoding that into a file and then running `plutil -convert xml1` and looking at the `passwordLastSetTime` field.

Note: osquery needs to be running with `sudo` but if you have it deployed across a fleet of macs as a daemon then it will be running with `sudo` anyway.

0 comments

RJIb8RBYxzAMX9u8y ago

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

simias8y ago

>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.

abritishguyOP8y ago

That's correct.

princekolt8y ago

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.

2 more replies

timsutton8y ago

`sudo dscl . -read Users/root accountPolicyData`

2 more replies

nothrabannosir8y ago

Wait, isn't the point of having root you can erase your traces? Are these logs immutable, even to root? That sounds pretty next level.. and how do I trust the tools?

As far as I know, possibility of root = root = pwn, game over, time to format.

labcomputer8y ago

System Integrity Protection (SIP)[1] does prevent even the root user from modifying some system files[2]. It seems possible, at least in principle, to protect system logs from modification by user root. In practice, I think most system logs are stored in /var, and that part of the directory tree does not appear to be protected by SIP (but I hope I'm wrong!)

[1] https://support.apple.com/en-us/HT204899

[2] Unless/until you reboot to a diagnostic monitor on a special partition (which requires pressing command-R from a local keyboard during the POST), then run a command to disable SIP, and then reboot again. Continuity Activation Tool requires users to perform this step as part of the install process to allow installation of Bluetooth drivers not originally signed by Apple.

1 more reply

divbzero8y ago

> Can be mitigated by enabling the root user with a strong password

Instructions from Apple: https://support.apple.com/en-us/HT204012

stupidcar8y ago

And if you're thinking that manually disabling root might also fix this, it won't. You have to leave root enabled.

divbzero8y ago

Security update now available: https://support.apple.com/en-us/HT208315

spoondan8y ago

You can also get the password last set time with:

    sudo dscl . -readpl "/Users/dan.koepke" accountPolicyData passwordLastSetTime

kr3wn8y ago

ok dan...

submeta8y ago

Excellent! Thanks for sharing

krock8y ago

apple have a security update out now: https://support.apple.com/en-au/HT208315

j / k navigate · click thread line to collapse

0 comments

RJIb8RBYxzAMX9u8y ago

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

simias8y ago

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

abritishguyOP8y ago

That's correct.

princekolt8y ago

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.

2 more replies

timsutton8y ago

`sudo dscl . -read Users/root accountPolicyData`

2 more replies

nothrabannosir8y ago

Wait, isn't the point of having root you can erase your traces? Are these logs immutable, even to root? That sounds pretty next level.. and how do I trust the tools?

As far as I know, possibility of root = root = pwn, game over, time to format.

labcomputer8y ago

[1] https://support.apple.com/en-us/HT204899

1 more reply

divbzero8y ago

> Can be mitigated by enabling the root user with a strong password

Instructions from Apple: https://support.apple.com/en-us/HT204012

stupidcar8y ago

And if you're thinking that manually disabling root might also fix this, it won't. You have to leave root enabled.

divbzero8y ago

Security update now available: https://support.apple.com/en-us/HT208315

spoondan8y ago

You can also get the password last set time with:

    sudo dscl . -readpl "/Users/dan.koepke" accountPolicyData passwordLastSetTime

kr3wn8y ago

ok dan...

submeta8y ago

Excellent! Thanks for sharing

krock8y ago

apple have a security update out now: https://support.apple.com/en-au/HT208315

j / k navigate · click thread line to collapse