Home folder encrypt...
 
Notifications
Clear all

Home folder encryption Linux

12 Posts
4 Users
0 Likes
552 Views
(@lmwashere)
Posts: 8
Active Member
Topic starter
 

I have two hard drives which were recovered on a search warrant. They both contain installs of Linux. Both of them appear to have empty home folders. Completely empty.

I am thinking that when the suspect chose to install Linux, he opted in on the encrypt your home folder option. Does anyone have any experience with this? Does my theory sound correct and is there any way to check it?

The only thing I can think of to test this theory is to do a linux install and select that option. Then view the HDD in FTK imager or pro-discover and see if I get the same results.

Any ideas would be most appreciated.
Thanks in advance

 
Posted : 25/01/2012 12:26 am
binarybod
(@binarybod)
Posts: 272
Reputable Member
 

There are many different ways of encrypting data on a linux system.

Completely empty folders is not something you get with cryptfs (the ubuntu method of encrypting home folders). If memory serves me right you should get a link to the .Private folder and a text file telling you how to go about restoring your data if everything has gone wrong.

If you have a completely empty home folder (or user folders within that) then it is likely that the home folder is located on another partition (or even within a file on a loop device). Have a look at /etc/fstab and you should see where everything should be mounted. This file together with /etc/crypttab will reveal all (or at least close off one avenue of enquiry).

Paul

 
Posted : 25/01/2012 12:36 pm
(@lmwashere)
Posts: 8
Active Member
Topic starter
 

Excellent! Thanks for your help.

Ubuntu is based on Debian and this is Mandriva, which if I am not mistaken came from Mandrake a few years back and Red Hat before that. So there may be some differences. Unfortunately for me the majority of my linux tinkering has been with Debian based distros.

These are interesting thoughts on the loop device. Though I have not found anything that looks like an image for that. At least not on these drives.

I have also not found the ".private" folders on either disk, nor have I been able to locate /etc/fstab or /etc/crypttab. /etc/ is there but only contains

/profile.d/ - empty
/rpm/ - empty
/sysconfig/console/consolefonts - empty
/sysconfig/console/consoletrans - empty
/sysconfig/network-scripts - empty

Are you familiar with locations to look for equivalent information in this distro. It seems to me that there should be a great deal more information stored in this directory. Mine has much more anyway. This makes me wonder if these were actually working installs.

Data carving on the first drive found images from a previous windows XP install, p2p software logos and other evidence that I was looking for, so it's not a total loss if this doesn't pan out.

The other interesting thing about these hdd's is that they have virtualbox installed. I have not been able to locate any .vdi files, nor have i found any files of suspicious size. I don't think that software comes with the default install, and would provide a good way to hide activities.

Other thoughts?

 
Posted : 25/01/2012 9:06 pm
binarybod
(@binarybod)
Posts: 272
Reputable Member
 

I've never even looked at Mandriva, sorry (so, if you like, please disregard anything that follows).

I don't know what is going on here (a familiar situation for a forensic analyst) but I have some suspicions

Hypotheses…

1a) There is another drive where /home and /etc can be found.
1b) There are files in the root folder that can be mounted on a loop device where /etc and /home can be found.
1c) /etc and /home are located somewhere that I can't figure out yet (easily done, at 54, I only have a limited brain capacity, those neurones are depleting at an alarming rate…)

2) This is an incomplete install and /home and /etc were never properly instantiated. (My favourite hypothesis based on what you have said )

3) Magic is involved

Now, to follow the scientific method we need to disprove these hypotheses so how do we do that? Experimentation is the answer so here are a few methods I have thought of in the time it has taken me to write this post…

A) Examine /boot, this is a great clue. If you are familiar with the Linux boot process then you should know that this is a great way to find out the configuration of the main file systems. Basically, my understanding is that /boot cannot be encrypted at the point where it needs to be loaded (but I stand to be corrected). If you want to harden your system to this extent you could put /boot on a USB drive and the system only works if that drive is present at boot. This should help negate hypothesis 1 if there is nothing strange going on.
B) Virtualise(ze [<- this, for the colonies]) the machine, see what happens. Just go with the flow on this, if it works then WTF? This should address hypotheses 1 and 2
C) Find a witch or a wizard and ask them what they think. This will address hypothesis 3.

Seriously though, with some proper research and applied critical thinking I'm sure you can add some (scientific) hypotheses and a host of experiments to disprove them.

Linux systems are VERY flexible, if you can imagine it, then it is probably achievable. It only takes a geek to make it happen and they only have to be one step ahead of you in the imagination stakes…

HTH (or not)

Paul

 
Posted : 26/01/2012 1:57 am
(@lmwashere)
Posts: 8
Active Member
Topic starter
 

It does help. Thanks.

I am with you on the favorite hypothesis.

 
Posted : 27/01/2012 6:34 am
(@widgit)
Posts: 11
Active Member
 

Linux is great fun to look at, nice change of pace to the usual Windows machines.

If it fails to virtualise do you have the option of cloning the disk and booting it with the original/similar hardware? Might help you get your head around it a bit.

I've never seen an exhibit come in with /boot on separate removable media (that I know of) but I have played around with making it happen on a demo rig.

I understand /home being on a separate disk, but would someone likely bother moving /etc? Would it accomplish anything practical?

 
Posted : 27/01/2012 3:15 pm
(@buster)
Posts: 28
Eminent Member
 

It's possible that the user has set the volumes up using Linux Logical Volume Manager (lvm) in which case you will need to have a look at the path /dev/mapper.

You should see entries similar to the below if that is the case

# ls -l /dev/system/
total 0
lrwxrwxrwx 1 root root 23 Mar 9 1718 home -> /dev/mapper/system-home
lrwxrwxrwx 1 root root 24 Mar 9 1717 linux -> /dev/mapper/system-linux

Stu

 
Posted : 27/01/2012 3:41 pm
(@lmwashere)
Posts: 8
Active Member
Topic starter
 

Thanks for the additional info. I will have a look there when i get back into the lab. I have to split time between there and other ventures for the time being but I will post back with what I find.

 
Posted : 31/01/2012 7:17 am
(@lmwashere)
Posts: 8
Active Member
Topic starter
 

The only two entries in /dev/mapper are

live-osimg-min
live-rw

Live image perhaps? Maybe improperly installed onto the hard drive? These symbolic link files really don't tell me much. Tried exporting them and opening them in notepad++ as I could not get the dd image to boot properly in vmware. The only information in them appears to be "../dm-0" followed by a string of null characters.

 
Posted : 03/02/2012 9:18 pm
(@lmwashere)
Posts: 8
Active Member
Topic starter
 

The only two entries in /dev/mapper are

live-osimg-min
live-rw

Live image perhaps? Maybe improperly installed onto the hard drive? These symbolic link files really don't tell me much. Tried exporting them and opening them in notepad++ as I could not get the dd image to boot properly in vmware. The only information in them appears to be "../dm-0" followed by a string of null characters.

 
Posted : 03/02/2012 9:18 pm
Page 1 / 2
Share: