6 ms·

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 stron

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.

submeta 9y ago
Excellent! Thanks for sharing
RJIb8RBYxzAMX9u 9y 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
- abritishguy 9y ago
  That's correct.
- princekolt 9y 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.
  - ybloviator 9y ago
    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.
    - deleted 9y ago
      [deleted]
    - warent 9y ago
      I'm confused, why do you have to escape an asterisk?
      - deleted 9y ago
        [deleted]
      - HarfTarf 9y ago
        He's stuck inside
      - kr3wn 9y ago
        wildcard.
      - vsl 9y ago
        Markdown in HN comments.
      - royprins 9y ago
        Famous last words of a Roman centurion.
        adrianratnapala 9y ago
        Nah, I've never seen them do worse than knock people out. Probably the next thing the centurion said was "Ow, what hit me!".
- timsutton 9y ago
  `sudo dscl . -read Users/root accountPolicyData`
  - edjw 9y ago
    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 9y ago
      If you're already in the terminal you could instead enter date -r 1474441704
      - edjw 9y ago
        This is a much better answer!
  - mhandley 9y ago
    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 9y ago
      My root pw passwordLastSetTime says this morning.. the fuck??
    - marcelfahle 9y ago
- simias 9y 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.
spoondan 9y ago
You can also get the password last set time with: sudo dscl . -readpl "/Users/dan.koepke" accountPolicyData passwordLastSetTime
- kr3wn 9y ago
  ok dan...
nothrabannosir 9y 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.
- labcomputer 9y 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 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.
  - marctrem 9y ago
    A motivated and knowledgeable adversary could most likely load a custom kext to bypass the integrity measures. Am I right?
    - nothrabannosir 9y ago
      You can't load unsigned kexts anymore, due to that same SIP. It's a pain in the gonads when hacking your own kexts. I had forgotten about this, but it does indeed allow for a system that leaves an audit trail which cannot be hidden, even by root. However, user labcomputer is right, I doubt that applies to the solutions proposed by OP here. Well, I'm certain: root can switch out the shell or terminal emulator binary itself and have it lie about executing those commands and return something trustworthy. One way or another, to truly check this, you'd need an immutable audit log (probably not currently available), AND a reboot into safe mode or a mount as a HDD onto a safe system.
divbzero 9y ago
> Can be mitigated by enabling the root user with a strong password Instructions from Apple: https://support.apple.com/en-us/HT204012 https://support.apple.com/en-us/HT204012
- stupidcar 9y ago
  And if you're thinking that manually disabling root might also fix this, it won't. You have to leave root enabled.
- divbzero 9y ago
  Security update now available: https://support.apple.com/en-us/HT208315 https://support.apple.com/en-us/HT208315
krock 9y ago
apple have a security update out now: https://support.apple.com/en-au/HT208315 https://support.apple.com/en-au/HT208315

submeta 9y ago

Excellent! Thanks for sharing

RJIb8RBYxzAMX9u 9y 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

abritishguy 9y ago
That's correct.
princekolt 9y 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.
- ybloviator 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - warent 9y ago
    I'm confused, why do you have to escape an asterisk?
    - deleted 9y ago
      [deleted]
    - HarfTarf 9y ago
      He's stuck inside
    - kr3wn 9y ago
      wildcard.
    - vsl 9y ago
      Markdown in HN comments.
    - royprins 9y ago
      Famous last words of a Roman centurion.
      - adrianratnapala 9y ago
        Nah, I've never seen them do worse than knock people out. Probably the next thing the centurion said was "Ow, what hit me!".
timsutton 9y ago
`sudo dscl . -read Users/root accountPolicyData`
- edjw 9y ago
  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 9y ago
    If you're already in the terminal you could instead enter date -r 1474441704
    - edjw 9y ago
      This is a much better answer!
- mhandley 9y ago
  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 9y ago
    My root pw passwordLastSetTime says this morning.. the fuck??
  - marcelfahle 9y ago
simias 9y 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.

spoondan 9y ago

You can also get the password last set time with: sudo dscl . -readpl "/Users/dan.koepke" accountPolicyData passwordLastSetTime

kr3wn 9y ago
ok dan...

nothrabannosir 9y 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.

labcomputer 9y 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 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.
- marctrem 9y ago
  A motivated and knowledgeable adversary could most likely load a custom kext to bypass the integrity measures. Am I right?
  - nothrabannosir 9y ago
    You can't load unsigned kexts anymore, due to that same SIP. It's a pain in the gonads when hacking your own kexts. I had forgotten about this, but it does indeed allow for a system that leaves an audit trail which cannot be hidden, even by root. However, user labcomputer is right, I doubt that applies to the solutions proposed by OP here. Well, I'm certain: root can switch out the shell or terminal emulator binary itself and have it lie about executing those commands and return something trustworthy. One way or another, to truly check this, you'd need an immutable audit log (probably not currently available), AND a reboot into safe mode or a mount as a HDD onto a safe system.

divbzero 9y ago

> Can be mitigated by enabling the root user with a strong password Instructions from Apple: https://support.apple.com/en-us/HT204012 https://support.apple.com/en-us/HT204012

stupidcar 9y ago
And if you're thinking that manually disabling root might also fix this, it won't. You have to leave root enabled.
divbzero 9y ago
Security update now available: https://support.apple.com/en-us/HT208315 https://support.apple.com/en-us/HT208315

krock 9y ago

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