-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/809/a-little-challenge-to-our-mac-advocate-friends/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
If you're running code at the same privilege level as the logged-in user, injecting code (using a technique similar to mach_inject or APE) into whatever browser is running would get you the vast majority of keychain items you'd care to have. Injecting into the running mail client would get you most of the rest.
As for assets you couldn't get... you couldn't get at my netinfo database. While you could get at my keychain, there's nothing there that's not public (i.e. certificates). You also wouldn't get any interesting emails, since those tend to be encrypted and I don't leave my token in when I'm not using it. (I don't do software keys.)
So on what desktop platform wouldn't code execution at the user's privilege level be a big deal?
As far as I'm concerned, this is a trick question. Replace "code" with "a keylogger," and bam, there goes my root password.
DNSSEC epic proceeding, although I have an, uh, algorithmic interlude in the pipe.
Being inside safari would only you access to the Autofill information (if you have that enabled, I do not). It would not give you access to anything else.
And no, on the ICBMs you cannot inject from one application (like Safari) to another (like Mail.app).
" I’ll kick it off by saying that if I control the process invoking Security Agent"
How can you control that process? It runs as a different UID. Even the dialog that asks for your permission to access Keychain is run under a different UID from the Application asking for the item.
Every keychain item has a set of access controls. Which applications are allowed to access the item and which have been denied so you won't even get a prompt. The access to the list is handled by a separate process, which runs under a different UID from the logged in user. The applications themselves never get direct access to the keychain.
And as for the keylogger thing, the window server itself does not forward events going into password fields to other applications.
The goal is to get your iTunes password in one step, without asking the user to approve/deny anything. All you have available at your disposal is an exploit in Safari. How do you get the iTunes password?
http://www.vmware.com/vmtn/appliances/directory...
Single user machines are a bitch, yo.
uhm, what does this have to do with getting the iTunes password?
First, I'm going to assume based on the above article text that this exploit would allow an attacker to download personal files (any files that the user can normally read) from any user that visited their maliciously crafted website.
Can you imagine how bad that would sound to the average person (hell, it should sound bad to a security expert)? Visit the wrong website, or a good website that's been hacked, and any information that's not encrypted on your computer is theirs. My sister/dad/mom/any relative would flip out if they knew that could happen (and it probably can, especially since they all run Windows, but anyways...).
So what are we arguing about iTunes passwords and keychains for? Merely for academic purposes, as far as I can tell.
P.S. Thomas, I'm not really sure why you directed that comment at me. Was it misdirected?
And yes, I do know how GDB works. GDB is setgid which is the only way for it to attach to other processes on the ICBMs. Apple made a change on the ICBMs back in Jan of 2006 (which means every ICBM ever shipped has this change) that prevents processes run as the current user from attaching to other processes.
I mean, I'll just run something SGID procmod (which I didn't know existed 2 minutes ago), like, uh, GDB, but still. Thanks for the heads up, Rosyna.
How is your exploit going to become setgid procmod? That'd be a nifty trick
Incidentally, if you think about it, any input manager is already fundamentally equivalent to "procmod" anyways.
Too bad Cocoa input managers don't load into Carbon apps like iTunes. :-)
http://www.digitalmunition.com/InqTanaThroughTh...
Still, if anyone was running basic virus-detection software, both the environment variable and any library/InputManager installation would raise giant red flags. (I'm not implying that most Mac users do this, because they don't. It's just an observation.)
It's also getting harder: Leopard closes down at least one of the methods mentioned here.
Sure it's not automated, but should work.
Ryan, Matt, Roland, if you're all talking in the context of the iTunes keychain item(s), you could not access them this way even if you did manage to have write access directly to the iTunes binary.
The keychain won't allow access to an item in the keychain if the application is modified without user interaction. Instead, you'll see a dialog like this (the dialog differs based on how much the application has changed, this dialog is for an application that changed by one byte) http://www.unsanity.org/rosyna/imgs/sexy_keycha...
And the point in my original summarized question was to get the iTunes password without user interaction using a Safari exploit. Modifying the iTunes binary won't do it.
Obviously the is is still a goal for some people, obviously it's the holy grail of hacking for the sake of hacking.
But... There appears to be a rather large phishing industry that has sprung up and is doing rather well for itself thank-you by *not* being interested in your computer but rather in the user. Can I re-write your bank bookmarks to send you to 'www.happy-phishing.com/1stBankofPhish' instead of your normal bank site?
How many people store passwords for things like their bank account in a text file tucked away somewhere in their home folders? The answer is... a lot.
How many people are properly 'equipped' to evaluate the risks of answering an unexpected popup on their desktop? Not so many.
How many Mac users blindly authenticate when asked to do so by an app installer without thinking of the consequences? And how many of these would even 'notice' if Safari popped up with something like this at an unexpected time?
Who would even notice if something like this dropped its own input manager into '~/library/inputmanagers'? Who would even know what that meant? Most of the Mac knowledgeable people who read blogs like this should know or would be able to google it up easily, but what about the average person in the street who just got drawn in by the "I'm a Mac" adverts?
Rosyna, how many users would recognise that dialog box as inappropriate? After all, they see it every time iTunes updates. Yes, that would be user interaction, I know. But the user wouldn't be faced with "Do you want to send your keychain to a total stranger, Y/N?", they'd be faced with a normal dialog box they see every couple of months anyway. Hiding behind things like that wasn't acceptable when Microsoft tried it to defend some of the mistakes they made and I'm rather sad to see it now.
If you include Social engineering and human judgment into the equation, then you couldn't even stop something that says,
"Download this widget. Click OK on the dialog that says this software is malicious. Windows is currently mislabeling the software. We are working with microsoft to address the issue. We promise it is not malicious, click the Install button if you see this dialog. "
ALong with a screenshot with a huge red circle around the install button.
I can assure you, people will still install the software. There's only so much you can do to protect computer users from themselves. And this is why it's a moot point to try to discuss potential social engineering exploits. No matter what is said in these arguments, both sides are right.
Regarding Keychain commandeering, I'm wondering how effective a filter I use, 1Passwd, would be in making this more difficult.
Fair enough.
In which case I'll go with malicious input manager copied to ~/libraries/inputmanagers. Quite possible from what Thomas says, and while I wouldn't own your machine I'd own your data. The data might be worth more.
I call shennanigans on Tom for posing a trick question. You all fell for the bait too :)
Questions: Would those things be safe? Does it help me that I don't run as admin?
Not running as admin certainly helps reduce(but doesn't prevent)the chances of people taking over your machine, but the question remains, what data can be mined?
As Thomas says, how do you decrypt that image. Couldn't someone just install an input manager to watch you do it?
I saw a great talk by Marc Stiegler of HP research back in Feb where he showed their capabilities-based system which stops applications from fscking your over except, of course, in the presence of social engineering attacks. But even social engineering attacks are limited because the applications ask for their capabilities the first time they load or you can just set them based on profiles (like "web-browser", which is something which needs to read your bookmarks and cache files, but DOESN'T need to read or write files anywhere else on the system...). There were lots of caveats to the talk (like the fact that everything has to be written in an OO langauge like java, and excluding things like C++ which have those evil pointers), but the message is clear, and has been repeated in other contexts over the years: even user-level applications need to be heavily sandboxed and partitioned, and given "least privilege" (fo' real...not just given lip service) because otherwise, as the example he used repeatedly, we are left with a world where solitaire can send your turbotax pdf printout to my good friends over at 1.1dy.us and citi-bank.ru (don't go there ;)).
For those of you who may have missed it, 10.5 is supposed to have Mandatory Access Control based on the TrustedBSD code base. I am cautiously optimistic that the sandboxing therein when combined with ability that darwin already has to spawn mini-vms for applications, will help stop my applications from being able to access everything everywhere in my user account.
The problem is, "single user machine" is a really hostile setting for deploying those features.
I can see how it's game over for me if you can run code as my UID, but (forgive my ignorance) do you have any more details as to how/why the "single user machine" is more hostile for the tightening up you just mentioned?
I was under the impression that the saving grace was "on a multi user machine, you'd have only 'lost' one user not everybody", but your last comment makes me think I'm still not getting the whole picture...
Also, if I did split off, say, all "my financial stuff" into a completely separate account, would it actually be any safer despite the inconveniences? Sure it's toast if you get root, but would my other account topple anyway? Say, if I normally fast user switch from the now compromised user account?
2: Posting a little challenge to prove the point $25
3: Telling people "You’re not following..." whilst huffing and pufffing and strutting your stuff $10
4: Getting smacked in the face and told to STFU and listen for once $priceless
Thomas we love you anyway, but it's good to be humbled every now and then, it makes us better people ;0)
So, not close to "STFU" yet.
What can't I get to on YOUR MacBook from UID 501?
But in fact, they're not single-user machines. With my UID, on my computer, you win (given that you can get my password sooner or later and then have UID 0).
But with my UID on my wife's computer, you have not so much of interest. Some audio projects, but nothing of major value. With my UID on my mom's computer, you have practically nothing - I check webmail when I go back home, and that's about it.
uid=1001(xistence) gid=1001(xistence) groups=1001(xistence)
(NFS on my FreeBSD has that uid for that account, so had to be the same on my Mac to be able to read/write, took me a while to figure out how to change it)
If you got my UID 501 account, i'd be up shit creek without a paddle since it has admin privs.
wideload:~ xistence$ id 501
uid=501(administrator) gid=501(administrator) groups=501(administrator), 81(appserveradm), 79(appserverusr), 80(admin)
I almost never use that account. The only time I use it is when I get a stubborn installer that does some shell script ninjutzu, and needs to do it as root. I look at you KisMac.
Now as for my current user account, you'd get a whole lot of data about me. Keychain however is under a different password, and I am very suspicious when an app needs access to it. I keep my mail password in it for example, and if it is locked, it will ask me for access.
InputManager? The folder is set to chmod 000. No read or write access, also, just in case something is put in there, AppleScript will pop up letting me know something was dumped there (can only be done as root on a chmod 000).
Thing that would suck the most, is if my SSH keys were stolen. Access to too many machines, and no real fast way to remove them from each of the machines it has access to.
What I would worry about the most is just general information about me, stuff that could probably be found on the Internet, but would take a lot of time. I don't think that what I do have is interesting. A few PDF's, a shitload of TV Shows, Movies, projects for school, and just some open source projects I am working on.
Rosyna: Only way I have found that a keylogger would work under Mac OS X is if it was a kernel module. But that is a general problem with all operating systems, not just Mac OS X.
Thomas: The assumption that everyone that is reading your blog would run under UID 501 is a really bad one. The only reason someone would be reading your blog is if they were interested in security, and those people would be smarter than your average grandma or grandpa. That being said, my dad is a Mac OS X user and I set him up with split accounts, just so that he would do everything under his own UID and only when installing apps use Administrator.
Cheerio!
Again this is one area where security researchers sometimes forget about applying risk. Yes you can root a box, but at what risk factor?
seriously you lot take this too seriously, maybe it's because i've been doing it since 94, but damn... IT ONLY A FUCKING OS!!!
I guess if you just declare the whole discussion moot, it's easy to "win". You win! I mean no offense when I continue to respond to the rest of the comments in the thread as if you hadn't won. For, indeed, you have won.
What sorts of things should Mac users be doing? Does Bert have the right idea with that InputManager thing he's talking about?
Or is the point simply that this kind of vulnerability is really going to hurt no matter what we do? Because I believe you. It will hurt. I'd just like to find out if there's anything I should do to mitigate my risk.
Like I said, I live dangerously, and I live by what Dave wrote about safety vs. security;
http://www.matasano.com/log/644/safety-vs-secur...
BTW Thomas,
$ id 501
id: 501: no such user
;-)
Overall, I think Bert gives some solid advice. I am not sure I know everything that Bert is doing to protect the InputManagers directory, but it will probably provide some protection, specifically around automated attacks.
The most solid recommendation is to make sure that your user account is not an administative user. I definitely recommend not running with a user in the admin group. While it won't help you with your data, it will prevent someone from immediately running amok with your /Applications diretory.
This means that the main goal for disk encryption, "protecting your data when your machine is stolen" is not achieved. I would consider this a fatal flaw - although not apropos to the rest of the discussion here.
http://www.subrosasoft.com/OSXSoftware/index.ph...
They seem to think they've got a way to get access to all the keychain passwords and it doesn't look like they're hijacking the individual applications. They also claim it's forensically sound, though that seems... well, patently false since the very fact of mounting the usb drive modifies the system, but I'll save that for the forensic experts to argue.