Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: MS-ISAC ADVISORY NUMBER:2015-088 Mac OSX zero day SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
MS-ISAC ADVISORY NUMBER:2015-088 Mac OSX zero day
My boss forwarded me an alert last night indicating an unpatched Mac OSX < 10.10.4 zero day was being exploited in the wild. See:

http://arstechnica.com/security/2015/08/0-day-bug-in-fully-patched-os-x-comes-under-active-exploit-to-hijack-macs/
and an earlier discussion turns up here:
http://forums.theregister.co.uk/forum/2/2015/07/22/os_x_root_hole/


I *think* I have a viable work-around that should stop this from being exploited until a patch comes out at least - setting /etc/sudoers immutable. I tested the process out on a intel Mac running 10.7.5 this morning, so far it is running normally.

I believe setting the /etc/sudoers file “immutable” should effectively harden the system against this incursion, as it won’t be writeable even by root unless “unflagged” to allow writes first. That would be a noisy proposition at best.

See, generally: http://www.cyberciti.biz/faq/apple-osx-write-protecting-file-folders-bash-command/

And the chflags man pages: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/chflags.1.html

I believe most OSX’s will require the change to be performed in single-user mode:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/chflags.2.html#//apple_ref/doc/man/2/chflags

If unfamiliar with Mac boot options, you get to single user mode by rebooting while holding down the command aka cloverleaf aka Apple and S keys at the same time, as explained here:

http://www.westwind.com/reference/os-x/commandline/single-user.html

Next run /sbin/fsck -y
Then run /sbin/mount –uw /
These commands clean the filesystem and render it writeable.
Then run chflags –v uchg /etc/sudoers

The -v gives a verbose output of the operation. If the operation works, it will list the filename changed as /etc/sudoers.
Type exit to reboot with normal startup.

Once a fix is in place, unsetting the flag or (possibly) just running “fix permissions” on the disk should clear the flag and allow the file to be written, which is probably expected default behavior by the OS. Note: As long as new users are designated “admins” , sudoers will permit them to run root commands even set immutable. I just tested this on OSX 10.7.5 and it is working and /etc/sudoers will not write. I think the approach will do, for now.

George Markham, GCIH, GCUX, CEH

Caveat: Please test on non-production machines first.
GeorgeMarkham

1 Posts
thanks for the work around. This is a neat hardening tip for OS X in general. The exploit may however still be used to alter files other then sudoers (sudoers is however probably the easiest way to cause damage) Anonymous

-
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!