[Ubuntu Chicago] [ChicagoLinux] Ubuntu encrypted Private directories

[Eddie Martinez]

Yes, the flaw is in the last step... the user password is used as an
Initilization Vector in generating the second passphrase for ~/Private. The
goal for any security system (and i wont claim this is a flaw, or a benefit
in the Ubuntu implementation), is to make the second key impossible to guess
from the first, or vice versa.

In this instance, I believe they are using KDF to make a secondary key based
upon the IV of the first MD5 key.

Also, there are ways to gain access to a computer (openssh server, ftp,
etc.) that can be used to compromise a computer. In my response to Jim on
the Chicago-Ubuntu list, I make that point that if someone does this:

find openssh-server on an ubuntu machine
connect ssh user at whatever.com
type in the password: letmein
sudo -i: letmein
passwd: u#9$%niniuop029

(here you set a new password)

In doing so, you would be changing the md5sum in which would actually take
the attacker farther away from deriving the ~/Private passphrase than they
were when they first connected to my machine, if I am understanding the
implimentation correctly (and i could be wrong).

Also, using a seperate /home, /var, /log, etc, would not useful in this
instance, as it would require connecting to a partition already mounted,
decrypted and running the ssh daemon.


-eddie m.

On Sun, Nov 2, 2008 at 8:32 PM, Christopher Allan Webber <
cwebber at dustycloud.org> wrote:

> The real question isn't whether or not the machine is rooted, IMO, it's
> how hard it is to get the password from running /etc/shadow against a
> rainbow table.
>
> http://en.wikipedia.org/wiki/Rainbow_table
>
> And, I haven't done it before, but I understand that's pretty trivial.
> At that point, you don't just "get access to the machine so you can
> change the password", you get the *actual password*.  So if you can get
> access to /etc/shadow, and can run the md5 hash against the rainbow
> table, and indeed that gives you the user's *password*, then it would be
> my understanding that if this is the *same* password used to encrypt the
> private directory, then whammo, you have access to the private
> directory.
>
> Now of course, I don't have a whole ton of experience in security
> workflows, but it seems to me like the way to break this system is:
>  - Get *physical access* to the system (ie, steal someone's laptop)
>  - Put in a boot disk to get access to the drive, and thus get access to
>   /etc/shadow
>  - Take the user's md5 hash, run it against the rainbow table
>  - Get the user's password
>  - Use the user's password to unlock the encrypted directory
>
> And voila!  You have access to the encrypted directory.  And since the
> only protection that encryption really gives is against someone stealing
> data by getting local access to your machine, you might as well leave it
> unencrypted anyway (or better, don't use the user's password & PAM for
> the passphrase on the key, and have real encryption).
>
> I could be missing something though.  Thoughts?
>
>
> "Eddie Martinez" <eddiemartinez at gmail.com> writes:
>
> > I'm not expert but it sounds to me like it would be easier to crack the
> md5
> > hashed login password/passphrase than it would be to attack the ~/private
> > dir...  The benefit comes from having a machine rooted and still having
> the
> > private directory to be called 'secure' because those two would be
> > independent, as you mentioned. The section about, "The pam_ecryptfs
> module
> > captures the user's login password and uses that to unwrap their
> encrypted ~/
> > Private mount passphrase" indicates that libpam/pam are used by the
> > pam_ecryptfs module as part of the KDF function for generating the secret
> key
> > for ~/Private.... This is actually more secure than rooting a machine or
> > editing /etc/shadow because doing so changes the md5 hash of the password
> in /
> > etc/passwd. If someone roots a machine and does 'passwd' and generates a
> new
> > root password, they will be locking themselves out of the secret key
> which was
> > used to encrypt ~/Private in the first place (asssuming no backup).
> >
> > http://en.wikipedia.org/wiki/Key_derivation_function
> >
> > At least this is my understanding, but I would still suggest SHA-512
> instead
> > of md5 for PAM, as well as grub passwd, seperate  /home, /swap, /var,
> etc.,
> > encrypted using something like AES 256, non standard passphrases/user
> names,
> > the whole nine yards.
> >
> > What I do find strange in the implementation of this, from the guides
> that
> > I've seen is the need to do a syslink to tell ~/private where the actual
> files
> > are located, as well as their handling of .ssh, but if anyone can talk
> about
> > this, I'd be more than interested to hear about it on the list.
> >
> > On Sun, Nov 2, 2008 at 5:56 PM, Jim Campbell <jwcampbell at gmail.com>
> wrote:
> >
> >     Hi All,
> >
> >     At yesterday's ChiGLUG meeting a couple of us finished up the Ubuntu
> 8.10
> >     discussion by talking about the encrypted Private directories feature
> that
> >     is new to Ubuntu in version 8.10.  Someone had brought up whether the
> >     setup of the encrypted directories use PAM to mount the encrypted
> folder,
> >     and I wasn't fully sure.
> >
> >     I did some checking today, and found some info that I thought I'd
> share:
> >
> >     https://wiki.ubuntu.com/EncryptedPrivateDirectory
> >     https://help.ubuntu.com/community/EncryptedPrivateDirectory
> >
> >     From one of the pages, "The pam_ecryptfs module captures the user's
> login
> >     password and uses that to unwrap their encrypted ~/Private mount
> >     passphrase. It also executes mount.ecryptfs_private on login, and
> >     umount.ecryptfs_private on logout."  Without knowing too much about
> it, it
> >     seems to me that the pam_ecryptfs module would be different than the
> >     standard pam or libpam module, but I'm not a 1337 hax0r or anything.
>  I
> >     also know we've got some security experts in ChiGlug and
> Ubuntu-Chicago,
> >     so I thought I'd just bring these up as a point of discussion.
> >
> >     I guess, to me, it seems like you're still toast if someone knows
> your
> >     username and password (as per usual), but it prevents someone who
> gets
> >     root access from being able to easily get at the data in the
> ~/Private
> >     directory.  Seems like they could still hack on shadow passwords
> somehow
> >     if they got access, and the setup isn't as strong as encrypting an
> entire
> >     /home and /swap partition, but this just makes things one step more
> >     difficult.  Any other thoughts on this?
> >
> >     Jim
> >
> >     --
> >     Ubuntu-us-chicago mailing list
> >     Ubuntu-us-chicago at lists.ubuntu.com
> >     https://lists.ubuntu.com/mailman/listinfo/ubuntu-us-chicago
> >
> > _______________________________________________
> > ChicagoLinux-Discuss mailing list
> > ChicagoLinux-Discuss at chicagolug.org
> > https://www.chicagolug.org/lists/listinfo/chicagolinux-discuss
> _______________________________________________
> ChicagoLinux-Discuss mailing list
> ChicagoLinux-Discuss at chicagolug.org
> https://www.chicagolug.org/lists/listinfo/chicagolinux-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-us-chicago/attachments/20081102/65547985/attachment.htm