Hi. Thanks for the enlightening blog, and the very clear descriptions! they really help. Now I'm dealing with a close subject, and I hope you can shed some light over it.

I develop a monitoring tool, installed as launchd daemon, running as root. It needs to connect to an HTTP server to send data. For that, on several client machines, it needs to connect via proxy. Now proxy settings are system-wide, and accessible via CFNetworkCopySystemProxySettings() and friends.

When proxy is authenticated, credentials are stored in the Login keychain, per user.

1. When my daemon uses KeyChain APIs - it finds nothing, because there's no login keychain around. How do other system services do it?

2. If I run my code from the active user (for which the keychain is unlocked), I still see the dialog asking user to Allow/Deny/Always allow my app access to the keychain.

Now Apple preinstalled Apps (Safari, Mail, iBooks, AppStore etc.) do go to the internet, through the proxy, and must use the proxy credentials for that. Yet they never pop up that dialog, and quietly connect to the proxy.

How can that be? How do they get this trust? And by the way, when I press "Always Allow" Where is this trust saved? how does securityd know that my app is eligible for keychain access? Could I somehow ask the user for permission at INSTALLATION time, once, and avoid hacking the keychain?

I know these are many questions - but any hint, or direction, will be greatly appreciated. I can't find any explanation of this in Apple Docs, or googling around. Maybe I don't know what to ask...

Hi
Did you work out your own answer here by any chance
thanks

When I try to compile this on OS X 10.11 with Xcode 7.2 I get this error.

keychaindump.c:12:10: fatal error: 'openssl/des.h' file not found
#include <openssl des.h="">
^

Turns out 10.11 doesn't include openssl headers according to this post.

https://medium.com/@deepak....

I followed the instructions above to download the correct version of openssl (`openssl version`) and I used the following command to compile it.

gcc keychaindump.c -o keychaindump -lcrypto -I/usr/local/include

It compiled with some warnings.

keychaindump.c:449:9: warning: implicit declaration of function 'geteuid' is invalid in C99 [-Wimplicit-function-declaration]
if (geteuid()) {
^
keychaindump.c:490:21: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
if (key_len = dump_wrapping_key(key, g_master_candidates[i], buffer, sz)) {
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
keychaindump.c:490:21: note: place parentheses around the assignment to silence this warning
if (key_len = dump_wrapping_key(key, g_master_candidates[i], buffer, sz)) {
^
( )
keychaindump.c:490:21: note: use '==' to turn this assignment into an equality comparison
if (key_len = dump_wrapping_key(key, g_master_candidates[i], buffer, sz)) {
^

I ran it and it took less than a second to run and it found nothing. It also printed some errors. This is the output.

[*] Searching process 89 heap range 0x7fcbe2400000-0x7fcbe2800000
[-] Requested 4194304 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7fcbe2400000
[*] Searching process 89 heap range 0x7fcbe4800000-0x7fcbe4900000
[-] Requested 1048576 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7fcbe4800000
[*] Found 0 master key candidates

Thanks for your script. I need your help for finish my work.. This is a screenshot of what I have for now. As you can see I have wrapping key and master key but no news about reveals plaintext passwords. Do you know what happened? May you help me? Thanks in advance

I wouldn't call that a design compromise, that's just how cryptography works.

Your keychain is open because by default the password for the keychain is the same as the system user password. When you supply your pass when logging in, the system uses it to open the keychain as well. Which is essentially to store the password in the memory.

For the keychain to be open, the system needs to be able to decypher its contents. If you have root access, then you have full control of the system, thus you should be able to read the keychains contents as well. There's no cryptographical way to go around this.

You can however close the keychain while being logged in and I'd bet you won't find the password in the memory then.

You can set any keychain to lock automatically after a minute for instance. You can set up a different password than the system password for it as well.

But when someone gains root access to your computer, the only way to protect your keychain is not to open it at all because only then there is a missing piece of information required to decypher the keychain, which is the password that you have in your head only. But that makes it kind of useless.

I really like the way you built the tool however. It's experiments like this that build awareness and help find security issues.

I'll certainly download Radio Silence and give it a whirl.
Meanwhile, as an LA resident since birth, I have to ask you if you are related to Esa-Pekka. I'm surely not the first.

Hello,
I am trying to run this but have no knowledge in compiling the program that was written. Can someone share the program with me so i can run it on my computer.
Thank you.

Ah... just built and tested with your POC code from github... and it doesn't work on OS-X 10.11 El-Capitan.

running it as root I receive:

[*] Searching process 95 heap range 0x7ff491c00000-0x7ff492000000
[-] Requested 4194304 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7ff491c00000
[*] Searching process 95 heap range 0x7ff493000000-0x7ff493400000
[-] Requested 4194304 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7ff493000000
[*] Found 0 master key candidates
Debug$

Seems like

kern_return_t r = vm_read_overwrite(task, start, sz, (vm_address_t)buffer, &read_sz);

has been blocked on El-Capitan? or maybe I need to upgrade the program in some way? Will signing it with an eligible developer certificate change anything?

please i am novice here.im using a mac os 10.6.8. i have forgotten my password to the keychain. i ma trying to run the keychain dumper but cant. i wanna know if any one could script as in .zsh or step by step..im new to mac and pls how to Find securityd’s MALLOC_TINY heap areas with vmmap. thank you very much

Hi Juuso, are you still available for questions? I haven't seen recent activity... Thanks

This is usefull & Great. As in the example it shown the passwords saved in keychain but couldn't provided the password for the wi-fi and bluetooth devices connected.

Undefined symbols for architecture x86_64:

"_main", referenced from:

start in crt1.10.6.o

ld: symbol(s) not found for architecture x86_64

collect2: ld returned 1 exit status

????

> Next, I used PBKDF2 with my login password to get my 24-byte master key. Scanning the memory again, a perfect copy of the master key was found in securityd’s heap.

Heya. I'm trying to use PBKDF2 on my own login password to find a match with the key securityd has in memory. Can you provide any details on how you went about this? How do you determine what salt to use?

I'm currently using the PKCS5_PBKDF2_HMAC_SHA1() function in openssl/evp.h. As far as you know, is there any reason that wouldn't work?

Thanks!

Hi, I don't remember the exact details of how I calculated the master key. In any case, the implementation doesn't really matter. I think I used Ruby or Python instead of C to play around.

The main thing is to grab the correct 20-byte salt from your keychain file and use 1000 iterations. With the function you mentioned, it's going to be something like this:

PKCS5_PBKDF2_HMAC_SHA1(password, strlen(password), salt, 20, 1000, 24, out);

To get the 20-byte salt from the keychain file, you can use the same technique that keychaindump uses to dump the wrapping key. For example, see line 246 of keychaindump.c:

memcpy(iv, blob + 64, 8);

That line copies an initialization vector from the same structure that contains the master key salt. You could replace line 246 with a line like this (and modify the rest of the function accordingly) to grab the salt:

memcpy(the_salt_you_are_looking_for, blob + 44, 20);

Hope this wasn't too confusing.

Just what I needed. Thanks!

How did you know to use PBKDF2? Is that the only KDF available on the system? I would like to be familiar with the tools you used to list the crypto calls made-or is that just gdb?

Securityd is open source. See, for example, the document at http://www.opensource.apple...

Great tutorial since Firesheep. This is perfect to be bundled with the recent Java exploit.

So is there a way to prevent this?

I maybe missing something in your excellent write up, but It seems that even if I used a different password for my keychain than login, I would still run into this problem once I unlock the keychain.

Would setting the keychain to automatically lock after 0 minutes stop this attack?

If someone who is not you has root access to your computer, there is absolutely nothing you can possibly do to stop them from seeing or changing anything. It is completely equivalent to being the operating system itself. The password has to by typed by you (or otherwise entered somehow) and it has to be stored in RAM somewhere while it's processed even if that's for a millionth of a second. Of course one generally would never deliberately give out root access to someone you didn't trust with your computer, which leaves being straight-up hacked.

So this is a nifty tool for peculiar circumstances, but be aware that it's just one very particular, automated example of an unauthorized root user being able to absolutely destroy you.

There are ways to mitigate against plain-text passwords being in memory, eg .Net's SecureString class accepts a character at a time and encrypts it (and exposes a decrypted character at a time on the way out).

Of course, if you're able to dump memory, you're able to inject a keylogger so the point is somewhat moot.

What you meant to say is "If someone who is not you has root access to your computer, there is absolutely nothing you can possibly do to stop them from seeing or changing anything *on your computer*." And even there, root's powers are not unlimited. It cannot, for example, peer inside unmounted encrypted disk images. Also, root has never had any special privileges across the network.

What this program does is extend an attacker's reach to all the sites (both on the web and over AFP) you have access to. It does not reveal disk image passwords, but could probably be extended to do so. (It appears to be decrypting them, but filtering them from the output.)

Your best bet is not to give an attacker root access in the first place.

Locking your keychain will prevent this particular problem, but it will not prevent the attacker from stealing your passwords later with a rootkit. They could, for example, insert their own code in the login process that steals your password the next time you type it in. Basically, there is no way to hide from root.

The attack described in this post was interesting, in my opinion, because it is surprisingly reliable across OS versions, works instantly and requires no persistent changes in the system.

this looks like a nifty tool should someone find themselves in the circumstance of having root on an OSX computer shared by other people they really need to spy on for some reason :)

But "Your best bet is not to give an attacker root access in the first place" is kinda like saying "the best way not to get robbed is to not go down to the street corner and hand out housekeys to people who look suspicious" don't you think :)

Not trying to beat you up, you've already agreed in other comments that this is not some shocking new discovery, but casual passers-by seem to be missing that point.

This is a useful, and well-written tool. Thanks!

Thank you.

how did you guys get this to run? I keep getting "expected identifier or ‘(’ before ‘}’ token" when I tried to test it on my mac.

IT DOSEN'T FREAKIN WORK

IDIOT

rtwhtrhwhbreighvyeirounuoreymvuieryvio3r8kiueryjc3uriocqeryjiveh6rjitf6yiofhtyrtoihyert8tfuter9jy89ureouiuryuiorutireitorekuijrogkuejiu[t9giortygpkoerlguoeoeitvortukgirtjgirtngoirtigoiyueoigkiogkuokufloetiykyoitugkemo;rtikygrtugotugoitigyotuoifryeioferjyiuejyeiruyjeriueriyftreif

erhgierjgperhgioerjgergergerg

0ifodbfhgioeruhgoreg

blar blar blar blar

This is a bit disingenuous as a post. If you let me in to your house then I could go through your personal stuff, financial records and your underwear drawer. Of course you could run all these processes to uncover the password.

Thanks for your comment. And you are absolutely right. Of course it is possible to do anything, even rewrite the whole OS, as root. I mainly wanted to show two things.

1) Because the keychain is automatically unlocked, the passwords can be stolen immediately, without installing any kind of rootkit and waiting for the next login. For example, it wasn't obvious to me that as soon as I allowed an installer package to do its work, my whole keychain could already be compromised.

2) The tool itself. Anyone could have written it, but as far as I am aware, nobody had done it yet. It might be of some use to penetration testers, comparable to samdump for Windows.

I'm sorry if I gave the impression that there was some kind of newfound vulnerability or bug in play here.

Exactly. In this era of Java zero-days, botnets, meterpreter reverse shells and whatnot, it's getting more and more trivial to remotely exploit and control Mac OS X workstations. Having the ability to harvest the entire unencrypted keychain after such a compromise is kind of a big deal.

I'm going to go with "design flaw". A basic tenet of all security software is that, yes programs need to see passwords and use them, but NO, they should never ever ever save them in memory. And while it's true that root access generally means you can do whatever you want, that basic tenet exists so that the one thing you CAN'T do even with root is access encrypted data. That's kind of the entire reason encryption exists — to protect information vertically as well as horizontally - that is, to keep the parent out as much as the siblings.

I understand that as root, you could just "hang out" on a system you've broken in to and just monitor things and eventually find some passwords. But this is another thing entirely. It's like a hackers paradise - break into a machine, gain root, instantly gain access to all remote accounts of all users currently logged in.

Having said all that, I understand perfectly why Apple has done this. In some sense, it's similar to the compromise of ssh-agent (which stores the private keys somewhere in memory, not the passphrase used for opening those keys). But at least ssh-agent doesn't unlock every password in the world all at once - private keys are unlocked one-at-a-time as needed, and as such, getting into ssh-agent memory is more of a hit-or-miss akin to key loggers, rather than the eggs-in-one-basket that is securityd.

Because securityd is proprietary, Apple SHOULD have an advantage over ssh-agent, in that they can just obfuscate the data in-memory to frustrate attacks like yours. Just encrypt and encode the in-memory data using one of many possible methods randomly selected at runtime, and it would be incredibly hard to find this data directly. The attacker could still probably attach a debugger to the process and wait for something to be unlocked, but this at least reduces things back down to the key-logger level of access, rather than instant.

If you can't make security perfect (which you never can), then you should at least avoid making it easy for the attacker.