| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAH8yC8=T7aoBmv97D0UjCZiBcmf4PUBnoK-AbsoJqE-bRPepQw@mail.gmail.com> Date: Wed, 28 Mar 2012 11:34:56 -0400 From: Jeffrey Walton <noloader@...il.com> To: "Thor (Hammer of God)" <thor@...merofgod.com> Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk> Subject: Re: PcwRunAs Password Obfuscation Design Flaw On Wed, Mar 28, 2012 at 11:30 AM, Thor (Hammer of God) <thor@...merofgod.com> wrote: > You've well-articulated a problem most (if not all) of the implementations I've seen just dance over. The application accomplishes the encryption requirements stipulated by policy or regulation, but the key is easily available to the application and of course to attackers. > > I have no idea what mitigation techniques are available for PHP, but in .NET/Win applications there are a couple of "first step" attempts to at least address the problem. First you've got DPAPI, which in its simplest form is an API that allows the application to encrypt/decrypt data by way of keys stored in the system certificate store which is protected by a different set of credentials. The attacker would have to get system to get to the keys. Of course, if the attacker could alter code as you've outlined, then they could very well just use the API to decrypt data without worrying about getting the keys themselves. The problem with DPAPI is that it is system-based. The data encrypted by that system can only be decrypted by that system. That won't work in distributed environments, and it can be problematic in system failure scenarios. > > [SNIP] > > I too would be interested in hearing what processes others are using to address this. Linux has not warmed up to the fact that userland needs help in storing secrets (unlike Windows with DPAPI and Apple with KeyChain). Under Linux, about the best you can do to avoid hard coded passwords in source files is store the password in a file, and then clamp the ACL on the file so only tomcat, apache, or whomever can read. Generally, it means you remove world and group. Jeff >> -----Original Message----- >> From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-disclosure- >> bounces@...ts.grok.org.uk] On Behalf Of b >> Sent: Tuesday, March 27, 2012 6:16 PM >> To: full-disclosure@...ts.grok.org.uk >> Subject: Re: [Full-disclosure] PcwRunAs Password Obfuscation Design Flaw >> >> So this brings up an interesting problem to tackle: >> >> How can you encrypt things for use by applications such as service account >> credentials for authentication to other systems and database access >> credentials on disk in such a way that the application can obtain the >> encrypted information without prompting the end user for a decryption >> passphrase and an attacker with local filesystem access cannot obtain the >> encryption key to the credentials by simple computation (like if you had the >> encryption key calculated based on some static/easily guessable >> information)? >> >> >> >> >> I have seen some attempts to solve this problem, such as with setting up SSL >> certs for apache's use if the certs private key is encrypted, you have to >> supply the private key decryption password at application startup and the >> key then lives in memory. >> >> This isn't very practical, in my opinion, in most environments I have seen >> because an unplanned outage could require system reboots by your >> monitoring personnel who might not know the application decryption >> passphrase and higher administrators have to be called in to start the >> services up properly. >> >> With web pages written in something like PHP, it would be even less practical >> because then you would have to design some sort of daemon that stays >> running in memory and the php code would ask the daemon to decrypt the >> database credentials for each request. Or another approach would be to >> thing like that like using the IPC capabilities of your operating system and >> using shared memory. To use this shared memory you would have some >> program that runs on system startup and you enter the credentials and they >> get saved to this shared memory location and your other apps or php pages >> can use the IPC interface to read this memory. >> >> Even these things have their issues because if the attacker can trigger a >> memory dump that gets written to disk (like causing a BSOD and you have full >> memory dumps enabled) and the attacker has local filesystem access they >> could then read the dump from disk (after the system comes back up) and >> obtain the key like that. >> >> >> >> >> I'd like to hear you all's thoughts on this so I can learn something new. >> >> >> >> >> -B > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists