About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

The Hackers Handbook — Afterword

It was easy to write a nasty worm for OS X. Last of many parts.

Get It

Try It

The first article in this series discussed the ease with which worms can be propagated on OS X and highlighted two types of system flaws; the second article in this series discussed a method of propagation; the third article in this series discussed methods of attacking the target system; this article will discuss a few more sophisticated methods of propagation, insertion, and attack.

Following the suggestions in this handbook will net you a worm for OS X. It won't net you the most sophisticated worm ever - that wasn't the intention of the series - but it will net you a worm. And of course you can make it more sophisticated.


One of the most obvious speed bumps is in the propagation: enough people will in fact click on things without thinking because an alarming number of computer users simply don't think. But user interaction is required - and therefore social engineering is required as well.

Creating a method of propagation that does not require user interaction is of course ideal. It's possible to do this if you can find the right exploit. And excellent places to start would be Full Disclosure and SecurityFocus, looking for serious rendering bugs in OS X - in particular any that can pertain to Apple Mail. Security researcher Tom Ferris regularly finds scores of these bugs - and Apple in expected fashion wait a long time to fix them.

If any of these bugs can affect Mail you have the possibility of achieving a propagation that nothing but an Apple bug fix can stop - merely selecting the message in the Mail inbox will unleash the bug, start the exploit code, and immediately propagate the worm to everyone in the address book - truly 'cataclysmic'.

The exploit code given - the proof of concept code for MOAB #15 - won't do anything but make it possible to obtain a root shell. If you invoke any of the three executables that's exactly what they do - set both the real and effective UIDs to zero and the group ID to zero as well - by definition root. You have to work on that bit to actually accomplish something constructive (destructive).

  • You could theoretically wait until you've propagated to everyone in the address book and then completely destroy the system by wiping the entire hard drive. There's nothing stopping you - that's for sure.

  • You could fiddle with the firewall to open ports and then download additional software from the Internet and install it wherever you want - /bin, /usr/bin, /sbin, /usr/sbin. And of course reset all permissions if needed. How many users go in there? How many even know those locations exist?

  • You could do background mining. You could download a copy of Opener and start looking for third party 'fanboy' ways of storing admin passwords in either base64 or outright plain text in preferences files. You go inside the keychain and find out what passwords are stored for what purposes and send it all home to the mother ship.

  • You could rig the computer to report regularly to a botnet otherwise populated exclusively by Windows machines and give them a hand in distributing spam across the Internet. Good money in that!

  • You could rig the computer to participate in organised (distributed) denial of service attacks against major corporations and government sites. Good money in that too!

  • You could use the computer to propagate further attack vectors as they are developed. You could devise means of querying computers in an IRC channel of their status, whether they are already busy doing your dirty deeds, whether they've been further equipped with the latest of your malware weapons, and so forth.

  • You could encrypt the entire user home area and then demand a ransom for the password.

  • You could send the MAC number home to the mother ship so the computer will be uniquely identifiable.

  • You will of course make sure you've added a hidden ghost root account so you can always get back in the computer again using a tool such as netcat or telnet.

  • If you find the computer is connected to a local network you will naturally try to compromise every computer on that network.

There are no limits. Not even the sky.


What you as a user can do to protect yourself against these threats is very minimal. Should the worm use MOAB #15 as its attack vector you could in theory reset the permissions on the three files to what they should be (04755) but if you're wont to installing software in the wrong locations you'll be calling out DU all the time to repair your stupid permissions and then the security hole will be back.

To clarify: there's really no reason to ever 'repair permissions' on your own and right now - as Apple still haven't fixed this embarrassing bug - it's not to be advised under any circumstances. The method of protection suggested by MOAB - and be glad they're on your side and not black hats - is to disable the agent DU uses for this by taking away its own SUID root bit.

Almost all software you download will tell you to drag your new app into /Applications. This is not only wrong, not only stupid, it also brings about a situation where you might have to 'repair permissions' again.

At no time under any circumstances have Rixstep staff ever tried to 'repair permissions' - nor have they ever been allowed to keep the contents of /Library/Receipts. As a matter of policy this directory is cleaned out regularly. Again: there is no need to ever use /Library/Receipts on your own - provided you're not irretrievably stupid. And in such case disabling the fangs in DU won't affect you at all, nor will resetting the modes of the three suspect files in /Applications/Utilities.


Why have Rixstep published articles detailing how a worm can be created for OS X? The answer is simple.

It's namely come to the attention of staff at this site that several hacker groups are actively investigating the possibility of propagating a worm for OS X. Although these worms will most likely be clumsy and relatively ineffective this activity is to be sure a sign of the times: OS X is nowhere near a tipping point where exploits are profitable but serious players in the world of the black hats are readying the technology they have for the day the exploits do become profitable. And a few test runs are always necessary to test the code in practice.

All the while Apple do nothing at all and churn out further technologies designed in the same naive fashion from a security standpoint. The fanboys at MacRumors and other sites are going to crap all over themselves the day the first worm hits.

There's reason to believe initial test runs - if they manifest themselves at all - will be designed to be widespread to better gauge efficacy. They will most likely not cause great harm, the authors instead wanting to see how well they work. But if they work well - and if Apple continue to stick their collective head in the sand - then things will progress rapidly and OS X users will find themselves where Windows users are today and the smarter of us are unfortunately going to have to look for a new platform again.

Try to help out yourself: write to Apple and report this bug. Tell everyone you know to do the same thing. Follow the format for submitting bugs and be as concise and informative as possible. Show some incentive: do it right now [yes right now] before you do anything else.

Change your file permissions for the three affected files. This is really easy. Put all of the following on one line and submit your password when asked.

sudo chmod 04755
/Applications/Utilities/Activity\ Monitor.app/Contents/Resources/pmTool
/Applications/Utilities/Keychain\ Access.app/Contents/Resources/kcproxy
/Applications/Utilities/ODBC\ Administrator.app/Contents/Resources/iodbcadmintool

Then make sure hackers can't go behind your back and still screw things up. DiskManagementTool is what runs on behalf of diskutil - and gets the permissions wrong. If you reset its own SUID root bit it can't harm you anymore.

sudo chmod 0755 /System/Library/PrivateFrameworks/DiskManagement.framework/Resources/DiskManagementTool

Finally zip up and then clean out the contents of /Library/Receipts. If you need it you can always put it back - but odds are you'll never need it.

Stop thinking you're invincible. Because you are not. The good ship Unix can't sink but the makeshift ship OS X can. You own your computer and a licence to your system software; you have a right to demand this software be kept up to date and as secure as possible; and so far your vendor are not exactly performing at that level. Demand they clean up their act.

See Also
Wooden Leg
Hacking the iPhone
'How I Hacked the iPhone'
Alpine Dottie
Effective UID: 0
iPhone and Security
iPhone and the Media
iPhone Hack to be Patched
iPhone OS X System Architecture

Thanks to Devon at Pixel Groovy for the excellent artwork.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.