Date: Thu, 29 Mar 2012 10:03:42 +0200
From: Christian Sciberras <uuf6429@...il.com>
To: b <b@...isoryalerts.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: PcwRunAs Password Obfuscation Design Flaw

So, it seems it dawned on everyone that current computer models are
fundamentally flawed.
The "protection" we're trying to add is, at this point, one huge hack
attempt to get things right.
Do I have a specific solution? No. But I do think rethinking the wheel
might be worthwhile.
This would include forgetting POSIX for a minute and think what could be
improved without relying on religious zeal.
Yes, I know it's hard, but it's for the betterment of humanity! I hope...


Chris.




On Thu, Mar 29, 2012 at 3:20 AM, b <b@...isoryalerts.com> wrote:

> So I guess what I am hearing from you and the other members of the list is
> that this problem can pretty much only be solved to provide complete
> security* except from physical attacks by having an operating system that
> is
> mathematically proven to do x, y, and z functions and only x, y, and z
> functions such that userland code could not ever get system level access to
> read arbitrary points in memory; and the operating system would have to
> provide a facility to userland programs for secure credential storage and
> the OS would enforce only certain programs (verifying using cryptographical
> checks that said program is indeed said program) would be able to obtain
> those credentials (and only in memory); and in addition to all of that the
> decryption key for the secure credential storage mechanism's database would
> never be stored on disk and would have to be entered by an administrator on
> system bootup?
>
>
> * I realize some of you may gawk at the use of that term, but I'm not sure
> what else to say there for "complete security."
>
>
>
>
> -B
>
>
>
>
> -----Original Message-----
> From: Thor (Hammer of God) [mailto:thor@...merofgod.com]
> Sent: Wednesday, March 28, 2012 11:30 AM
> To: b; full-disclosure@...ts.grok.org.uk
> Subject: RE: [Full-disclosure] PcwRunAs Password Obfuscation Design Flaw
>
> 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.
>
> To get passed single-machine issues, there is another method called DKM,
> which as the name infers is a distributed key management system based on AD
> and the machines' membership is appropriate groups given access to the
> keys.
> So in a similar fashion, keys are protected by secondary credentials at the
> machine level.  Again, this requires an attacker to gain system access to
> get the keys, but again, gives an attacker with file-level access where
> code
> can be changed access to the procedure calls to get the data if they have
> to.
>
> It is a very difficult problem to solve, but it all comes down to risk
> management.   If you are protecting against off-line attacks or attacks
> from
> other systems, DPAPI or DKM will definitely help.  If you are protecting
> against attacks where SYSTEM access is granted, it gets far more difficult
> (one may even say quite improbable) to protect the keys.
>
> What I've been doing myself is a bit different, but it ultimately suffers
> from the same potential issues:  As part of my TGP "suite,"  I've extended
> functionality to WinMobile so that data encrypted on the PC can be
> exchanged
> and decrypted on the phone.  It's pretty cool actually...  to get around
> the
> key management issues, I wrote an API where the devices authenticate to,
> and
> use certificates to gain access to the encrypted keys on a centralized key
> store.   On the phone, the calls are made each time keys are needed.  On my
> web servers, the call is actually made on application startup, storing the
> keys in memory.    At any time one becomes aware of some breach, you can
> cut
> off access to the keys.  Not ideal of course, but it works.
>
> I'm not worried about the BSOD scenario.  The remote attacker would have to
> cause a BSOD, and then somehow access the dump.  In production systems, the
> page files are typically kept on another drive (well, maybe not "typically"
> but that is up to the admins) in which case the dump won't exist.   But to
> your point, I just looked at my own web VM, and it is indeed set to do a
> full dump to the system drive.   I still don't think there is enough of a
> risk of that type of breach to warrant changing the paradigm from
> system-only access to keys in memory.
>
> I too would be interested in hearing what processes others are using to
> address this.
>
> t
>
>
>
> > -----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/
>

Content of type "text/html" skipped

_______________________________________________
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