During the recent brouhaha surrounding the AppleScript "Simpsons Worm" that recently circulated, a Macintouch reader expressed concern that someone might write a similar worm that used AppleScript's Keychain Scripting to steal passwords from the victim's locked keychain:
Following up on recent discussion regarding the Simpsons AppleScript worm, Angus McIntyre sent in this response to Ian Stoba's points about a script that could potentially manipulate Fetch to modify data on remote machines:
"I can add another nightmare scenario to this - on MacOS 9, AppleScript can read data from an unlocked keychain using the Keychain Scripting application (a standard Scripting Addition distributed with the OS). It could then use the URL Access Scripting application (another standard item) to send the recovered hostnames, user IDs and passwords to a remote site (perhaps as a form submission to a mailform on a free website, the mailform set to send to a dropbox on a free system such as Yahoo or Hotmail). When URL Access is doing its stuff, there's no visible indicator to show anything's going on - no dialogs, no browser windows."
In reply to Angus McIntyre, Ken McLeod chimed in:
Following up on yesterday's note from Angus McIntyre about the potential for an AppleScript to read data from a locked keychain (in the context of recent discussion regarding the Simpsons AppleScript worm), Ken McLeod raises an interesting security point:
"It's important to note that no data can be retrieved from an unlocked keychain without the user's explicit permission for each item, unless users go out of their way to bypass this security by turning off access warnings for a given keychain. By default, the confirmation alert is enabled specifically to prevent a 'malicious code sucks all your passwords out of your unlocked keychain' scenario.
"However, if you have disabled warnings for access to your keychain, such a scenario becomes possible. Users should double-check their keychain settings (using the Settings item under the Edit menu in the Keychain Access control panel) and make sure that the 'Allow access without warning' checkbox is NOT checked."
I didn't feel it was safe to allow users to believe that the Apple API's provided any kind of real protection against the scheme Mr. McIntyre proposed:
Our coverage of access to data in locked keychains (as it applies to the recent Simpsons AppleScript worm) continues with a note from Ron Risley:
[Ken McLeod wrote:]"It's important to note that no data can be retrieved from an unlocked keychain without the user's explicit permission for each item, unless users go out of their way to bypass this security by turning off access warnings for a given keychain..."
"Unfortunately, this is overstating the case quite a bit. True, if a worm/trojan/virus writer sticks to using the Apple API's to access the keychain, those protections would work. It isn't hard, however, to bypass the API's -- though I'm not going to provide a tutorial on how to do so.
"The keychain is a convenience, but it comes at a price. I strongly recommend that users keep at least two keychains, one with low risk passwords that they can keep open for convenient surfing, and another with financial and privacy passwords that they keep locked when not in actual use. Some passwords probably shouldn't be stored on a keychain at all."
In spite of the inherent problems with password server systems -- problems which are well documented in the literature -- some people expressed skepticism about my statement. Since I believe that it is important that the people who use security systems understand their limitations, I wanted to post a little more information about the reasons why Apple's keychain technology cannot ever be truly secure.
There is a fundamental problem with any password server scheme running on a system without protected memory. The fundamental dictates of cryptography require that all secrecy must reside in the cryptographic keys. Any system that relies on mysteries, obfuscation, or 'secret' information outside of the key is relying on "security by obscurity" and is provably vulnerable to trivial attacks. (For an excellent discussion of this and other fundamentals of cryptography, see Schneier, Bruce Applied Cryptography: Protocols, algorithms, and source code in C and, by the same author, Secrets and Lies: Digital security in a networked world.)
Since the Apple keychain software is just a process running on the computer, any process running on that same computer has access to all the same data. Once you unlock a keychain, it is open to any process on the machine. Try as you might to hide the decryption key using convoluted code, all you are doing is obfuscating; all your "security" lies in confusion, depending on the assertion that no one will go to the time or trouble to sort out what is plainly visible in memory.
The hopelessly naive might be tempted to say that sorting through all that code would be too much trouble for a would-be virus author to go through. They would be wrong. First off, the task is not that complex. Indeed, sorting through the two small security libraries that contain the relevant code is a tiny job compared to the herculean task of dissecting a large program such as Microsoft's IIS Internet server. And yet IIS has been successfully hacked, multiple times times, using just that approach.
The bigger issue, though, is that you don't have to go through the trouble. Once you have relied on security by obscurity, you have left yourself open for all kinds of malicious hacks that do not depend on intimate knowledge of how your security software works. That is why, in cryptography, all security schemes that rely on obscurity are considered trivially vulnerable to attack.
In the case of the Apple scheme, one tempting target is the point at which the software asks you to allow or deny access to the keychain by a running process. No matter how convoluted the system, you can always trap at a point where user input is solicited. It does not matter whether the software uses high-level system calls or talks directly to the hardware, all you have to do is find the offending instruction and patch it out. You end up with your own perverted version of the keychain software that can do whatever you want with the data. There are other attacks, but this one is fairly straightforward.
The proof is in the tasting. I decided to try to find out just how much work it would be to do a quick hack to bypass the API protections and read data from an unlocked keychain. I don't normally have time for such foolishness, but my wife was out of town this evening and work is unusually light this week. I decided I would take a stab at it. Of course, on the one hand I am an experienced programmer. Working against that, though, is the fact that it has been over ten years since I wrote a serious Macintosh program -- that was before the PowerPC and the Keychain. I believe we were on System 7.
My first attempt succeeded by reading the keychain while effectively bypassing the chance for the user to deny access. Creating the hack took less than five minutes, start to finish, and involved no programming whatsoever, just a little chipping with ResEdit. I have to say that I was surprised, though I was expecting to spend less than two hours at the task.
I want to emphasize that it is no credit to me that I was able to do this. When a cryptographer says that something is provably trivial, there is usually a reason.
Did Apple do a lousy job on the Keychain software? Not at all. Everything we know about cryptography says that there is no way to make a password server secure on a machine without protected memory. In fact, the Apple engineers did a fine job of building in protections wherever they could. I actually use the keychain, extensively, in preference to my own version of a password server that I created before the resurrection of the Keychain with Mac OS 9. It's a great tool for serving up those dozens of passwords we need to navigate the Web and access its services. I should also emphasize that a locked keychain is, as far as I know, quite secure (though I haven't done any kind of analysis of it). It also might be possible to make a secure password server on a machine with protected memory, so that the Keychain on OS X might be safer, though I cannot personally vouch for it.
Of course not. Just because it is trivial doesn't mean I should in any way encourage its use. Anyone who wants to believe that I am confabulating is free to put their most sensitive passwords on their Keychains and, in reality, they will probably never be attacked. Those who have ears to hear will probably be a bit more careful.
[ Home | Hearth & Home | Mind & Body | Old & New | Comp & Comm | Words & Ideas ]
Date created: June 28, 2001
Last modified: July 8, 2001 17:56
Copyright © 2001 Ron Risley