Tiny Deathstars of Foulness

Large deployments of Mac OS X based systems are becoming more and more prevalent. In some ways, this is due to one to one programs and more frequent enterprise deployments of Mac OS X. As such, people are more and more looking to manage systems. And any time you have systems being managed, those using managed systems start looking to break the management of the computers. Therefore, a new topic comes up: trying to discern when a system has broken out of the management framework. For example, how do you know when users have broken your firmware password? How do you know when they’ve circumvented your managed preferences framework to give themselves teh root? How do you know when they’ve traded access to teacher tube to some other video site with more scantily clad teachers on it? How do you know when employees have unlocked the “My IT Department Sucks” badge on Foursquare at work, even though your firewall specifically doesn’t allow access to social networking sites? Here are some tips, most of which assume there is some form of patch/policy/update management solution (e.g. Casper, Absolute Manage, FileWave, Puppet, etc) in use in the environment:
  • Create a jailed environment. If the system breaks any of the other rules then put them in the jailed environment. While in the jailed environment, revoke Internet access (e.g. set an invalid proxy, static the gateway to, kill name resolution or something like that). Also alert admins any time the system is jailed.
  • Hide your admin accounts: and pre-Lion, possibly an entirely hidden dislocal node.
  • Check the date and time stamp of /var/db/shadow/hash daily. If the date/time stamp does not match the last time you changed the password then the system has broken the policy. In Lion, check the contents of /var/db/dslocal/nodes/Default/users and check root/your local admin, as well as your local admin password.
  • Set the firmware password: but use your patch management to set it more frequently – or check the contents of the firmware password against what it should be (such as at You cannot “lock” or force a firmware password, but you can verify that they haven’t been changed.
  • Check pmond, if the mode of any files are not as intended then reset and alert that it was changed. You could scan other binaries, particularly in /bin, /usr/sbin, etc w/ something like tripwire:
  • If Lion, enable Full Disk Encryption, which requires the recovery partition. So hack the recovery partition to remove reinstall abilities and anything else dangerous in your environment:
  • If using mcx, compare the mcxread output to that which is expected (e.g. for a user or a computer, I wouldn’t mix them given that you may get more false positives than you want)
  • Consider an old security topic: extrusion detection. Here, we look for traffic patterns that would be normal, that is, if the system were an unmanaged host. For example, if part of your management is to proxy traffic and the system is not using your proxy then that could be a problem. So look for unproxy’d traffic hitting your firewall from systems where it shouldn’t.
  • My favorite: the honeypot. Put something on the computers that looks awesome, that users just can’t help but think they just have to open. For example, a file called “Access to the Grading System” in a school or “Admin Access to Payroll System” in a company. Something almost ridiculously named. Put it somewhere that only a user with administrative access could get (like the desktop of your local admin account). When they open it, disable loginwindow.
  • Finally, take a hard line with those who break the rules. Making an example of someone is sure to end up greatly reducing those who might follow in their footsteps. In a corporate environment this can be tricky, as people have to do their jobs, but feel free to be crafty. I like the old scarlet letter approach, or caning. But given that those aren’t quite so popular any more, perhaps pop-up screens that say “HAHAHAHAHAH, we busted you – you were pwnd suckah!” every 15 minutes that flash pink and yellow so all their friends can see it isn’t a bad call. In schools, particularly in one to one environments, such would be particularly embarrassing, but we don’t want to scar them for life. Thus the significant drop in caning. You could also take the machine away for a day or two, (time to reimage it). Maybe force them to use SimpleFinder…
The balance between giving users the ability to have as open an operating environment as possible while still enforcing the basic policies that the organization has deemed are required is a struggle. Especially if all of the users have admin accounts. But we’ll address that one at a later time… For now, I’d like to hear some of the things others have done. Normally I don’t solicit commentary on my site, but I figure the site turns 8 years old in a few weeks, so why not! Oh, did I mention, there’s a prize for the most awesome comment!

December 5th, 2011

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , ,

  • Jake H

    Back in the day, I found some odd bottlenecks in our LAN around lunchtime at our high school. Found out students were bringing Quake3 demos on a USB flash drive to play. We didn’t have the tools to stop .exe’s from a flash drive so we had to resort to other methods (classroom management 101?). I downloaded Quake3 on my Mac and scanned the network for servers around lunch time. Bingo. Hopped on and started fragging left and right. Funny thing was, my username was “Tech Services” so they died with phrases like “Headshot from Tech Services” across their screen. Funnier thing was I then remote controlled into that PC right after I fragged a certain player, and rebooted the machine on the spot. So one by one the server was losing people and it became just a few of us, and “Tech Services”. Nobody really got the hint at first, until I changed the name to “RBHS Tech Services”. Scanned the network for weeks after that and no servers. LAN behaved better, the teacher enjoyed having a quiet lab at lunch, and I got to frag while on the clock.

  • LeRoy Dennison

    The last one is the most important. There is no point in having policy that is not enforced. Enforcement includes difinitive consequences that apply to everyone. One public example of these consequences being applied to someone goes a long way toward future compliance by others.

    • If the student carves their name in the desk, they’re going to get punished for doing so. Or if they tear pages out of books. Is disabling management on your system all that different? Let’s say it costs $25 to replace a book that gets damaged. How much in labor and/or software costs are spent trying to prevent and then fix these very same issues…

  • Michael

    Effectively, all of this falls into the honeypot category. If someone observes carefully before making any of the changes that would trigger the jail or alert, he’ll be able to find ways to disable that kind of monitoring as well. Even stuff that’s run remotely (i.e. through ARD and the like or through your software/patch management) could in theory be fooled.

    Essentially, once someone obtains admin privileges, the sysadmin is screwed. Therefore, I prefer to just set firmware passwords and leave it at that. A sneaky user could still pull the hard drive out of his MacBook, hook it up to his computer at home and carefully search for all the tripwires you’ve set up and remove them.

  • Bill

    What is pmond?