Monday, May 11, 2009

The Mac Hacker's Handbook



The Mac Hacker's Handbook is the best reference for Mac-specific attack information that I have found. At 368 pages, it may appear small compared to the typical 750+ page security tome. That's because the authors have done a near-perfect job of sticking to the topic at hand, the Mac. The authors do not succumb to the usual temptation to try and teach assembly language or reverse engineering. Rather, they do an excellent job touching on those topics in an OS X context, and assume the reader has a little background in that area already, or can otherwise keep up. I have done some limited research into the areas of Mac malware and process injection in the past. This book has done a fantastic job of filling in many holes in my knowledge that I hadn't been able to take care of before. Plus, it introduced me to a number of Mac-specific security features I wasn't aware of before. Highly recommended for anyone interested in Mac security.

Detailed commentary follows.

The authors Charlie Miller and Dino Dai Zovi have impressed me on several levels.

A couple of years ago, I did a presentation of Mac malware, where I researched some similar areas on my own. The purpose of my talk was to demonstrate that the privilege separation on a typical single-user OS X box made no difference, because an attacker could do everything they need from user mode.

My skills are somewhere between beginner and intermediate in the areas of programming, reverse engineering, vulnerability research and exploit writing. With a lot of work, I was able to create a very crude keyboard sniffer by attaching a library to launched processes. In one chapter (chapter 11), this book spelled out everything I needed to know and more. And implements several useful injected components in a much more flexible way than I was able to. I could have really used this information then.

I ran across many of the same libraries and examples that the authors reference in the book. However, they were mostly code examples with no context, intended to be groked by hard-core Mac programmers. Here, they are presented in an actual understandable way, building on examples as they go. It makes a huge difference. The level of writing meshed perfectly with my past knowledge and filled in the holes I had. I have an advantage over a rank beginner, but I suspect they have reached as wide an audience as is possible with their writing.

They do this consistently throughout the book. And this is what really made this an excellent book for me, was the actual writing. You'll have to excuse me if I geek out a little bit on this topic, but I've written a few technical books myself, and I have a great appreciation for how hard it is to do this well.

There are many traps one can fall into when writing a book like this. A lot of the topics are circular. As in, it's difficult to pick a sane order to follow, and not repeat a lot of information. There's always a temptation to try and show off advanced topics, and not adequately cover the intro material. It's easy to get lazy and not put the time into explaining a concept, assuming everyone knows it. Authors sometimes dump a lot of pictures and code on the reader for length.

These authors fell for none of these. The ordering of topics and advancing difficulty seem ideal. Code is almost uniformly useful and well-documented. They don't beat you over the head with example after example for the same topic. Rather than attempting to include a complete PowerPC and x86 instruction reference, they give you the minimum set of instructions that they used. The pacing was great. I was neither bored reading things I knew, nor unable to keep up with the material (until I struggled slightly to absorb the last chapter or two.)

Production values are good. The price is great, the length is very appropriate. Editing is good. (Not perfect; I spotted a dozen very minor typos. But then, I can't turn off my internal proofreader anymore, you're unlikely to notice most if any of those.)

There are other minor things to appreciate if you've been around vulnerabilities and exploits for a while. I feel like they did a great job explaining heap exploitation, compared to other attempts I've read. I very much enjoyed the little bits of history when they discuss who pioneered a particular technique. Most of Dino's code has a date in the comments, so you have some idea what was known at the time.

I'd go so far as to say that this book really is a general book about how to find and exploit vulnerabilities, using the Mac as your research platform. And it turns out that the Mac is a great place to learn.

Saturday, February 10, 2007

Apple vs. Maynor update

I had a great time chatting with people at the security bloggers meetup the other night. There were any number of "I didn't know you blogged" moments all around. Two of the guys I spent some time talking with were David Maynor and Robert Graham who have recently formed Errata Security. And yes! they are blogging too.

We chatted about all kinds of things. We chatted about Robert moving on after IBM acquired ISS. It seems that David found some reason to move on from his position at Secureworks, too. And then we went to dinner at some mediterranian tapas food place, and chatted some more. They bought. Thanks for the dinner, guys!

So when I got back home, I tracked down their blog, and there's some good stuff there. Hey look, there's this one particular entry from David. Looks like he's tired of keeping his mouth shut about the Mac wireless hack thing. Short version of my take on the issue: I believe David and Johnny.

But at this point, I do have to agree that some opportunities have been lost. The Matasano guys propose some hoops that researchers should be going through. Frankly, I thought that was a little silly and totally unnecessary. Even in David's case. I never thought for a second that Apple would ship the patch while still claiming that David and Johnny found nothing. I was wrong on both counts.

So unfortunately, this leaves room for the next bit of stupidity. If/when David ever decides to demo owning the built-in wireless, or release an exploit, etc... then the Mac zealots will claim that he must have reverse-engineered the Apple patch, and that he never found anything ahead of time.

Because David can reverse engineer the patch and write a working exploit, but he's not capable of finding the hole in the first place, right? And the hole that Apple fixed just coincidentally is in the area that the original Black Hat talk covered. And the holes in other OSes that they found of the same class aren't related. And HD Moore using their fuzzer and finding a similar hole in OS X has nothing to do with it.

One of these days, I hope David drops more info. At this point though, it looks like Apple has been largely successful. They have managed to drag things out long enough and tell enough half-truths that their customers believe Apple. So it's likely that few zealots will be swayed when David finally presents proof. There will just be further dismissals from people who really don't understand security very well. I still look forward to it, though.

Hey look, David is speaking a couple of times at Black Hat Federal later this month.

Thursday, November 30, 2006

Apple gives credit to evil haxors?

(OK, even I have to admit up front that I'm just giving Apple a kick in the joy department for the fun of it over this one.)

So, I'm having a glance at daringfireball.net this evening, to see what kind of Mac security zealotry I should be enraged about lately. Gruber says they gave HD Moore credit. Hey, look at that! He's right.

Now, you would think that with all the recent past history on Apple and vulnerability disclosure, that Apple would have a policy of not crediting researchers who don't "properly" report vulnerabilities, wouldn't you? After all, not even Microsoft will give you credit if you don't play nice. But for Apple, maybe that's not the case? Here's what I believe is their official policy:
For the protection of our customers, Apple does not disclose, discuss or confirm security issues until a full investigation has occurred and any necessary patches or releases are available. Apple usually distributes information about security issues in its products through this site and the mailing list below.
Near as I can tell, that's the entirety of their official written policy. If there's a better version, I'd love a link. Note that it doesn't say anything about giving credit or not.

So maybe it's Apple's policy to give credit to the discoverer of the vuln, regardless of how it is disclosed? If so, then kudos to Apple! You've done one better than Microsoft. Honestly, I don't see why you wouldn't. It's a simply acknowledgment of a fact.

Now, if we could just get proper credit attached to an earlier wireless vuln, and work on not pretending a problem doesn't exist until "any necessary patches or releases are available", then I'd be that much happier.

Thursday, November 02, 2006

Threat vs. vulnerability

Inspired in part by Richard Bejtlich, I present Yet Another Horrible Information Security Analogy (YAHISA): A tale of bunnies and kitties.

Imagine a lush green field of grass and clover, where bunnies frolic and play. These are cute white bunnies, with pink eyes. And the occasional black bunny, which inexplicably costs more. The bunnies in this field have no natural predators. The wolves don't know about this field.

Now, picture a city cat that roams the streets, getting into fights, disappearing for days at a time. When it comes home, it's missing a little more of its ear, or occasionally needs to be stitched up. If it gets into a fight, sometimes it wins, sometimes it loses. It will eventually be run over by a car. Its bloated carcass will be poked by children with sticks.

The bunnies are vulnerable. The kitty is vulnerable, and has threats.

Wednesday, November 01, 2006

You want Mac wireless bugs?

So, the Month of Kernel Bugs (MoKB) begins today. They start by releasing a live exploit for a remote kernel bug in older PPC Macs with Orinoco-based chipsets. "1999-2003 PowerBooks, iMacs". (Note: I've done no independent verification of the bug, I just trust the people reporting it.)

With no official notification to Apple, and no patch available.

Even though the machine I'm typing this on right now is vulnerable to the exploit, I believe this is the appropriate way to handle this release. Why? Because of they way Apple handled the same kind of issue with David Maynor and Johnny Cache, of course.

Apple thinks it should not even acknowledge unpatched bugs. It (apparently) thinks that it should issue press releases denying the issue and use vague legal threats against researchers to "protect customers".

This kind of release is the result. If Apple doesn't want to play responsible disclosure, then the researchers will be happy to oblige. I trust there will be no denial of the problem by any interested parties this time?

(No, not really. The Mac zealots still won't believe it. But it sounds good, anyway.)

Update: I'm taking my Mac off the list of affected machines. It's an iBook G4 with an Airport Extreme that was purchased separately. It appears that the Extreme (802.11g) version of the Airport isn't affected by this particular bug. I might as well try to be careful about technical accuracy. I've seen how the Mac community reacts to any little inaccuracy.

Saturday, October 21, 2006

OS X Malware

Just to be up front about it: Yes, this entry was created in the spirit of stabbing OS X zealots in the eye with a lit cigarette. Why? It drives me absolutely insane when people who clearly have no concept of how these things work insist that Macs can't get malware, don't have vulnerabilities, or have some magic security model. Yes, I realize trying to educate someone like that is masochistic. However, I wanted to have a more convenient place to point to when some clueless Mac fanboy says "show me even one virus for OS X!!".

I don't care to claim that the problem of malware on OS X has in any way reached significant levels. Nor am I trying to say that it is immanent. I do mean to say that is it not non-existent, and that it is certainly not impossible that it could happen.

So I'm going to try to maintain a list. I'm doing "malware" here, not exploits nor vulnerabilities. For my purposes, that includes viruses, trojan horses, worms, rootkits and spyware. I'm also going to limit this list to malware designed for OS X. There is a long list of macro/Office based stuff, things for OS 9 and below, and so on. Yes, I realize that some of it still probably works fine on OS X under the right circumstances.

Malware:
"Opener"
01Apr2004~22Oct2004
Rootkit
http://www.macintouch.com/opener.html

"osxrk"?
08Sep2004
Rootkit
http://freaky.staticusers.net/ugboard/viewtopic.php?t=13891

"Togroot"?
http://www.oreillynet.com/cs/user/view/cs_msg/72381

"WeaponX"
~05Nov2004
http://packetstorm.security-guide.de/filedesc/wX.tar.html

(Sony Rootkit)
~11Nov2005
Rootkit
http://www.tuaw.com/2005/11/11/sonys-drm-now-for-macs-too/

"Leap-A"
16Feb2006
Trojan/Worm
http://www.macrumors.com/pages/2006/02/20060216005401.shtml
http://www.ambrosiasw.com/forums/index.php?showtopic=102379
http://www.symantec.com/security_response/writeup.jsp?docid=2006-021614-4006-99

"Inqtana.A"
22Feb2006
Worm
http://archives.neohapsis.com/archives/fulldisclosure/2006-02/0534.html
http://www.symantec.com/security_response/writeup.jsp?docid=2006-021715-3051-99
Source: http://www.digitalmunition.com/InqTana-ABC.tgz

"Inqtana.B"
22Feb2006
Worm
http://www.symantec.com/security_response/writeup.jsp?docid=2006-031413-1704-99
http://www.sophos.com/security/analyses/osxinqtanab.html
Source: http://www.digitalmunition.com/InqTana-ABC.tgz

"Inqtana.C"
22Feb2006
Worm
http://www.f-secure.com/v-descs/inqtana_c.shtml
Source: http://www.digitalmunition.com/InqTana-ABC.tgz

"OSX.Macarena"
02Nov2006
Virus
http://blogs.securiteam.com/index.php/archives/714
http://www.symantec.com/enterprise/security_response/writeup.jsp?docid=2006-110217-1331-99&tabid=1
Source: http://vx.netlux.org/src_view.php?file=machoman.zip

Not malware:
http://apple.slashdot.org/article.pl?sid=06/09/16/182207
But I put it here for reference. This is to address the people who want to claim that malware would have to ask for your admin password. Not that there is any requirement that malware be root, of course. In the OS X security model, any admin user can write to everything in /Applications.

InqTana.D
http://www.digitalmunition.com/hacklu.html
According to the author, .D is no longer a worm, but is an autorooter. Unless I have time to look at it later and change my mind, it does not appear to meet my definition of malware.

Monday, September 04, 2006

When, where, how and for how much, to reveal your vulnerability

You know, I can do these long logic chains based on a lot of assumptions as well. Can I get some vitriol?

So, you're a researcher, and you've got some sexy new class of exploitable flaws you've found. You do your presentation at con, but it seems like everyone's employers nowadays don't appreciate presenters dropping 0-day. Therefore, you decide to show a video clip instead.

You decide to playfully pick on a group of smug OS users who generally think they are more secure. (I know. Security researchers bursting the bubble of someone with a false sense of security? I'm shocked too.)

Trying hard to be "responsible" (as defined by the software vendors), you give the vendor some heads up that you're going to be showing a video demo of yourself 0wning their kernel driver. Lo! This vendor, who happens to actively cultivate this perception that their stuff is more secure, takes exception.

Let's talk about this particular software vendor for a sec. They have repeatedly demonstrated a willingness to sue anyone who reveals anything they aren't ready to reveal. They are willing to sue every time. Even if it's true. To the point where you might have to take them to the state supreme court to try and keep them from going after your sources.

Of course, that's for news, which theoretically has some constitutional protection in the U.S. How do they feel about vulnerability disclosure? "We don't feel that our customers are better served by public disclosure of potential issues". Oh.

So, maybe picking on Darth Litigious isn't such a hot idea. They decide to instead demo one of the third-party cards with its own vulnerable driver. And not even identify the card, so that vendor can't complain either. Yeah, it kind of weakens their demo, but they don't have a lot of choice.

Maybe they could just mention in passing that the sue-happy vendor's built-in card and driver have similar problems?

Surely, the masses won't ignore the impressive 802.11 research presented that made up 80% of the talk, and only focus on the demo? And pick the demo to death only because it affected their favorite platform? Surely, it can't be possible that rational, sane people would believe that the problem is demonstratable on FreeBSD, Windows, and even their own platform, but with a third-party driver... and then not believe that there is any chance whatsoever that the same kind of problem exists on the driver that ships with the OS?

No, clearly, the researchers must have faked the video. It seems MUCH more likely that they would use a third-party card ONLY as a red herring. Not because the OS vendor breaks out the lawyers at the drop of a hat. No, they faked the video, and they didn't show themselves popping the native card because, well... that's more believable. Or something.

So, clearly the zealots were right all along, the researchers are frauds. Wasn't it stupid of them to get up in front of all their friends and peers, and pull a scam? Especially since at least one of them had proven himself more than competent over the years. Oh well, no accounting for stupidity.

But zealots are rarely willing to let things go at victory. No, how about the zealots taunt the researchers with promises of prizes, on the off chance that the researchers have something to actually show? Maybe all they were waiting for was a shiny thing. And not the threat of lawsuit.

Let's examine the offer from the zealot.
  • Zealot will buy said vulnerable (Ha! As if!) shiny thing
  • Zealot will not permit researchers to put their filty paws on the shiny thing
  • Researchers will use their exploit, which they have promised to keep private until the patch is out
  • If the exploit doesn't work flawlessly on the first try, then researchers will either have to give the zealot the cost of the shiny thing, or it will be called "even". Where "even" is the researchers have to pay no money, but zealot will crow about victory, and researchers will have proven themselves untrustworthy by using the exploit they said they would keep private, and maybe get sued.
  • However, if it does work flawlessly, the researchers will be up one shiny thing, and will only have proven themselves untrustworthy, and maybe get sued. Plus, zealot will have some excuse as to why it doesn't matter because, well, whatever, nuh-uh!
  • All judging will be done by zealot, who would be out the cost of one shiny thing, and prove himself completely wrong if he declares the researchers the winners.
So, back to my opening question, if you're a researcher in this position. You've got this sexy vuln, what do you do with it? Here are some options:

  • Ignore any potential gain from your work, don't present it, sell it, use it as a resume item, etc... just post it, and take a chance the vendor will be really mad about that. Tick off potential employers. Anger some peers who think that is irresponsible.
  • Sell it. TippingPoint and iDefense will offer $10,000 or more. That's like, enough for 9 shiny things! Note that you will be required to keep the exploit private until the patch ships.
  • Present it and try and warn people about this class of problem. (Also, you get some travel expenses, and maybe enough money for 1 shiny thing. Woo!) Note that this does not neccessarily prevent you from releasing the exploit if you want. Unless maybe your employer paid for some of your time, and insists that you don't. Or maybe your peers and potential employers and customers wouldn't like that. Or maybe the conference itself got sued for that sort of thing last year, and it wouldn't be cool.
  • Unless you tried to be nice to the vendor by giving them some advance notice, who then turns around and makes you change your presentation and hold your tongue. Even if they later issue a public half-denial that they know about the problem. because, you know that presenters and conferences get sued for that kind of thing now...
So, the holding all details until a patch is released strategy looks like a pretty good choice. The researchers probably would have had more options if they hadn't tried to give any vendors advance notice, but it's a bit late for that now.

Maybe the vendor is trying really hard to communicate to the researchers that the best strategy is to just blindside the vendor? Maybe they like a challenge.

In case it's not obvious, I don't believe that David and Johnny faked anything. They are being really big about the whole thing, despite taunts, derision and bribes. I believe they will proven correct when Apple puts out the patch (which is, of course, completely on Apple's schedule.) And I also believe that the same people who are calling them frauds now will probably still be grasping at any little detail which might help them keep from admitting they were wrong.