Monday, August 15, 2016

Full Disk Encryption (FDE) Including Most Of /boot on Arch Linux

Hey everyone - I have been playing around with full disk encryption on Linux a bit lately, and I see a lot of literature that says /boot cannot be encrypted because the boot loader will not be able to decrypt it.  This is only partially true.  Newer versions of grub support decryption of LUKS containers at boot time.  Today, we will take a look at doing full disk encryption including (most of) /boot with Arch Linux.  Some of the commands we will run (namely mkinitcpio) are Arch specific, but the rest of this post may be useful to you if you are running another distribution.


Motivation

I recently purchased a laptop because I plan on traveling a bit more in the future, and it would be nice to have something with a larger screen and a bit more power than my tablet.  Since laptops can get lost or stolen, I thought it would be a good idea to employ full disk encryption on my laptop's SSD so that my data is protected if something happens to the laptop.  In Windows, you can achieve full disk encryption using BitLocker if you are using a Pro or Enterprise version of Windows 7+.  You can also use open source utilities like VeraCrypt or LibreCrypt.  In OS X, you can use FileVault 2 which was introduced with OS X 10.7 (Lion).  I am not going to be running Windows or OS X on this laptop, so I needed a solution that would work with Linux.

FDE

Full disk encryption sounds awesome right?  Before we dive in, we need to talk about what FDE is and is not.  FDE is only good against attacks where the adversary has physical access to the disk.  If the disk is mounted and being used, then it is decrypted.  Therefore, FDE is not the be all, end all of security for your machine.  It is part of a layered, defense-in-depth approach to system security.  FDE is great for devices that do not always have great physical security around them.  Devices like laptops, phones, and tablets can be stolen or lost.  If your disk is unencrypted, someone only needs access to that disk to steal the data.  FDE adds one or two layers of authentication by asking for a passphrase, requiring a physical device to be attached to the system (like a TPM module or USB flash drive with a special file), or both.  If someone gets a hold of a disk with a strong passphrase, it will be relatively difficult for them to recover data from that disk.  You could also use FDE on your desktop if you are worried that it will be lost or stolen.  Remember that once an adversary has physical access to your computer, they can do whatever they want.  Therefore, the measures we will talk about help mitigate data compromise.  They do not completely prevent it.

Components

When it comes to disk encryption in Linux, the names you will hear the most are dm-crypt and LUKS.  LUKS stands for Linux Unified Key Setup.  LUKS is nice because it is a platform independent on-disk format specification and works in every modern Linux distribution and even Windows with LibreCrypt.  In theory, if you had a file system driver in Windows for your file system, you could use a tool like LibreCrypt to read the contents of the disk.  dm-crypt is the backend for transparent disk encryption in the Linux kernel.  It was introduced with kernel 2.6.  Later, we are going to use cryptsetup which is the tool for utilizing dm-crypt.  So, we will use cryptsetup to set up a LUKS formatted disk.  All of this will use dm-crypt in the backend.

Out of the Box

Fedora and other distributions will offer disk encryption to you when you install them.  On one of my Fedora systems, most of the drive is indeed encrypted (including swap, which is great):
$> lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0 167.7G  0 disk  
├─sda1                                          8:1    0   500M  0 part  /boot
└─sda2                                          8:2    0 167.2G  0 part  
  └─luks-51a39f9a-f82d-4732-97ee-740583a36df1 253:0    0 167.2G  0 crypt 
    ├─fedora-root                             253:1    0    50G  0 lvm   /
    ├─fedora-swap                             253:2    0   3.9G  0 lvm   [SWAP]
    └─fedora-home                             253:3    0 113.3G  0 lvm   /home

However, you can see that sda1 (/boot) is outside of the LUKS container.  So, why should you care?  Your sensitive data is in /, /home, or perhaps in your swap file.  In theory, that is all that should need to be encrypted.  How true this is depends on your risk tolerance.

Let's take a second to talk about what is in /boot.  On modern Linux systems, /boot contains all of the files that the system needs to start up (including the kernel).  Once you select a kernel image to load in your system's boot loader (be it systemd-boot, LILO, grub, whatever), your boot loader will load that image and pass off execution to the kernel (the kernel image is called vmlinuz in modern Linux distros).  The kernel will load the initial ramdisk (used to be called initrd, now known as initramfs) which contains tools and drivers that the kernel needs to load the full system.  On a system using disk encryption for the system drive (/), cryptsetup is one of these tools.  Cryptsetup handles mounting and umounting encrypted partitions, so for the system to interact with a disk encrypted with dm-crypt, it needs cryptsetup.  So, what if some nefarious person were to modify the cryptsetup in your initramfs to spit out the pass phrase?  Or, what if they were to modify the files in the initramfs to load a rootkit or something similar?  This article talks about those possibilities, and while it is from 2011, the concepts have not changed.

These ideas sound a bit scary because no one checks the integrity of their initramfs file before they boot their machine, so you probably would have no idea that this has happened.  If your laptop is lost or stolen, it will likely be sold for money.  However, if you want to protect yourself as much as you can, we will talk about a way to encrypt most of /boot.  I say most of because on EFI systems, an EFI system partition (known as ESP) is required to boot.  ESP contains EFI bootloaders and applications that the EFI firmware on your computer needs to start.  I am not aware of any EFI firmware that supports an encrypted ESP, so that has to remain unencrypted.  Therefore, many of the problems with unencrypted initramfs files are transferred here.  In theory, someone could modify the Linux EFI boot loader with "bad" code.  You can mitigate this by enabling Secure Boot.  Secure Boot enforces cryptographic signatures for EFI boot loaders, so if your boot loader is modified, the signature check will fail, and you will know about it.

If your system does not use EFI, or you do not care about having an EFI boot loader, then this article (which forms the basis for most of the procedure outlined in this blog post) will work for you.  However, if you want to dual boot on an EFI system (like Windows 8+), you will need to account for EFI.

The Setup

We are going to set up our disk with LVM (logical volume manager) because LVM allows for dynamic resizing of a volume group which could be nice in the future.  You do not have to use LVM.  If you choose not to, the steps are actually easier since you do not have to do all of the LVM-related set up stuff.  We are going to set up LVM inside of our LUKS container (LVM on LUKS).  This does not allow for spanning multiple disks, so if you need to do that, this section in the Arch wiki will help you there.  Since my system only has one disk (and will likely ever only have one disk), I am going for the simpler solution.

For our example, we have a 20GB disk, and we will put two partitions on it.  The first (sda1) will be for the EFI System Partition (ESP) and the second will be for everything else (sda2).  If you already have Windows installed, you are probably not going to be using sda1 and sda2 (since those partitions are already set up by Windows).  In that case, you will need to substitute the partition numbers you will be using.  We will have a separate place for /home, but that will be inside of the volume group as will our swap.  You can use whatever tools you like to partition your disk.  I am going to use gdisk for this example.

Partitioning the Disk

On our 20GB disk, we are going to reserve 512MB (100MB is the minimum) for ESP, and the rest (roughly 19.5GB) for everything else including /, /home, and swap.  Using gdisk, we will create the first partition as EFI (code EF00) and the second partition as standard Linux (8300).  Here is what my partition table looks like:
[root@testbox ~]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 41943040 sectors, 20.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 979137A6-28E0-44B3-84FD-7920716B9BFC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 41943006
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624        41943006   19.5 GiB    8300  Linux filesystem

Creating the LUKS Container

Now that our partitions are set up, we will set up a new LUKS container on /dev/sda2.  We are not including /dev/sda1 because it must remain unencrypted.  We need to use cryptsetup (the frontend for dm-crypt) to get everything set up:


# We are going to specify a key length of 512 bits (which is an effective key length
# of 256 bits since we are going to keep the default of AES in XTS mode)
[root@testbox ~]# cryptsetup -s 512 luksFormat /dev/sda2

# Now are are going to open the container so we can work with it
# lvm is the name that we will use to refer to the open container.  You can name it whatever you want.
[root@testbox ~]# cryptsetup luksOpen /dev/sda2 lvm

Creating LVM Structure

You can skip this part if you are not using LVM.  If you are interested in using LVM and do not know much about it, here is a quick crash course.  You should read more on the subject elsewhere for a more in depth explanation.

In a computer system, you can have one or more physical volumes (partitions or disks).  They might be labeled as /dev/sda1, /dev/sdb1, and so on.  With LVM, you can put one or more of those physical volumes into what is called a volume group.  That volume group can be split however you like into logical volumes.  A logical volume is like a filesystem (say / or /home).  LVM is nice because it adds an abstraction layer that allows you to add and remove physical disks and adjust accordingly while keeping everything together.

For our example, we will create a physical volume for /dev/sda2.  /dev/sda1 is not part of the volume group because the ESP needs to be separate.  To create a new physical volume, we use the pvcreate command:

[root@testbox ~]# pvcreate /dev/mapper/lvm

Now, we need to create our volume group.  I am going to call mine VolGroup0, but you can call yours whatever you like.  We need to use the vgcreate command for this.

[root@testbox ~]# vgcreate VolGroup0 /dev/mapper/lvm

Finally, we need to create each of the logical volumes.  We are going to have one for swap (4 GB), one for / (12 GB), and the rest will be for /home:

# Create a 4GB (-L 4G) logical volume on VolGroup0 named (-n) swap
[root@testbox ~]# lvcreate -L 4G VolGroup0 -n swap

# Create a 12GB (-L 12G) logical volume on VolGroup0 named (-n) root
[root@testbox ~]# lvcreate -L 12G VolGroup0 -n root

# Create a logical volume named (-n) home on VolGroup0
# from the rest of the space (-l +100%FREE)
[root@testbox ~]# lvcreate -l +100%FREE VolGroup0 -n home

Creating Filesystems

Now, we need to create our file systems.  swap will be swap, and the rest will be ext4.  You can use whatever you like.

# Substitute VolGroup0 for the name of your volume group
[root@testbox ~]# mkswap /dev/mapper/VolGroup0-swap
[root@testbox ~]# swapon /dev/mapper/VolGroup0-swap

[root@testbox ~]# mkfs.ext4 /dev/mapper/VolGroup0-root
[root@testbox ~]# mkfs.ext4 /dev/mapper/VolGroup0-home

Now, you can continue the rest of the installation process until just before you install the boot loader.  We need to tweak things a bit.


Adding a Key File

In the article where I first read this, the author talks about creating a key file so that you only need to type your password once when booting.  When grub unlocks your drive after your type your password in, it passes control to the kernel that then has to unlock your drive again so that it has access to it.  The author's solution was to create a keyfile that could unlock the drive and pass that keyfile to the kernel when grub passes control to the kernel.  This works.  However, the key file is readable when the system is bootable to anyone that has root.  The author tries to mitigate this by chmod-ing the key file to 000 (no permissions for anyone, even the owner), but root can still read the file.  The key file is stored in the encrypted partition, so if someone steals your drive, they need to know the password to boot or mount the disk.  With that said, keep in mind that if your system is compromised while it is booted, all bets are off.

If you want to buy this risk, create the key file like this:


# Use dd to create a 2KB file of random bytes
[root@testbox ~]# dd bs=512 count=4 if=/dev/udrandom of=/etc/key_file

# Add that key file to the keys for the LUKS container
[root@testbox ~]# cryptsetup luksAddKey /dev/sda2 /etc/key_file

Adding Kernel Hooks for Encryption

The kernel needs the right hooks to be able to decrypt the LUKS container we made.  Before we install the boot loader, we should put in those hooks.  In the file /etc/mkinitcpio.conf, change the line that says HOOKS and add lvm2 and encrypt to the list.  If you are using a key file, put the path to the key file between the quotes on the FILES= line.  After this, rebuild the kernel:

[root@testbox ~]# mkinitcpio -p linux

Installing and Configuring GRUB

As of this writing, GRUB is the only boot loader that supports booting from an encrypted disk.  To install it:

# efibootmgr is needed for EFI support in GRUB
[root@testbox ~]# pacman -S grub efibootmgr

Now, we need to configure it.  Before we do that, we need to grab the UUID of the partition for the LUKS container.  We can use UUIDs so that it does not matter what the device is called (like /dev/sda2).  If the device becomes /dev/sdb2, the UUID is the same.  To find the UUID, use lsblk:

[root@testbox ~]# lsblk -f
NAME                 FSTYPE      LABEL UUID                                   MOUNTPOINT
sr0                                                                           
sda                                                                           
├─sda1               vfat              6FFE-A2F4                              /boot/efi
└─sda2               crypto_LUKS       b9de7df0-4965-40b2-adf2-9db0b57622a4   
  └─lvm              LVM2_member       jSBliM-yHze-UUkV-i39Y-6ZuL-x0v5-JTRLzG 
    ├─VolGroup0-swap swap        swap  96bfb9ce-571e-411e-bf60-b25a2f042760   
    ├─VolGroup0-root ext4             b5064ff5-3113-45f2-85c8-f3737edf8b5a   /
    └─VolGroup0-home ext4             1ae97c3f-b427-417b-871e-4d903c57e30f   /home

We want the UUID from /dev/sda2 (the LUKS container).  In this case, it is b9de7df0-4965-40b2-adf2-9db0b57622a4.  So, in /etc/default/grub, we will add the following to the GRUB_CMDLINE_LINUX line:
# Substitute your UUID after UUID= and before :lvm
cryptdevice=UUID=b9de7df0-4965-40b2-adf2-9db0b57622a4:lvm

Finally, add GRUB_ENABLE_CRYPTODISK=y to the end of /etc/default/grub.  Save the file, and finish installation:

[root@testbox ~]# grub-mkconfig -o /boot/grub/grub.cfg
[root@testbox ~]# grub-install /dev/sda

And that is it!  Finish up the installation, and reboot.  You should get a prompt asking for your password, then boot should proceed normally.

Conclusions

For me, enabling FDE including /boot was an exercise to learn more about the process and how LUKS, GRUB, and the boot process work together.  I cannot say if the outcome is worth all of the effort.  It was an interesting exercise that mitigates a rare form of attack.  The procedure we outlined here needs to be modified for other distributions, because mkinitcpio is specific to Arch-based distributions.  The GRUB configuration steps would work for any distribution running a new enough version of GRUB (> 2.0).

Do you use FDE?  Is this procedure too paranoid or not paranoid enough?  Let me know!  Thanks for reading!

Monday, August 1, 2016

Interesting Vulnerability in Some Cable Modems

Hey everyone - This is from a while back, but there was an article about a vulnerability in certain ARRIS (formerly Motorola) Surfboard cable modems.  The vulnerability here is multi-faceted, so we will break it down.  Meet me after the jump...

Monday, July 18, 2016

A Discussion About Office Macros

Hey everyone - With the last few posts, we have talked about various host-based defense measures you might want to consider implementing.  Today, I want to talk about something else on the host that is a common vector for malware: Office macros.

You might be thinking that we have covered some things over the past few weeks that seem really basic and that Office macros is just another basic topic.  However, since Office macros are still a viable means for malware authors to spread their work, I feel that it is important to talk about.

Monday, July 4, 2016

The "Other" Linux MAC Software: AppArmor

Hey everyone - We have spent a lot of time talking about security measures that are somewhat similar in what they do at a high level.  The implementations differ, but AppLocker, SELinux, and AppArmor (which we will talk about today) implement varying levels of mandatory access control.  The reason I am harping on this topic so much is because I do not feel that it is well understood.  While I have mentioned in every article I have written on these defense measures, none is a foolproof way to prevent all attacks all of the time.  When they are configured correctly, they make it more difficult for an attack to be successful.

AppArmor is similar to SELinux, but the implementation details between each differ.  They both sit on top of the default discretionary access control that exists in Linux systems.  Which one you would want to implement will probably depend on which Linux distribution you are using.  AppArmor is turned on by default on Ubuntu and OpenSUSE whereas SELinux is turned on by default for Red Hat based distributions like CentOS and Fedora.  Both are available for other distributions as well.

Monday, June 20, 2016

SELinux and Why You Should Not Disable It Because That Would Be Easier

Hey everyone - We have spent some time talking about a few defense measures for Windows machines, but what about defense measures for your Linux machines?  Today, I want to discuss SELinux with you.  You will see a lot of blog posts, forum posts, and guidance elsewhere to disable it because it appears to get in the way.  I would like to help dispel that myth and show you that it can be a good thing.  Let's get started.

Monday, April 25, 2016

A Hiatus

Hey everyone - Some exciting things are going on for me over the next month or so, and while they are (hopefully) going to be fun, I need to hit the pause button on posting for a bit.  I will be moving, and during the transition, I will not have my server or consistent internet access.

I want to finish up the series on host based defense measures, so I will post those after the break which should be sometime in late May or early June.  Feel free to drop me a line if you need anything.


Thanks as always for reading.

Monday, April 11, 2016

Using AppLocker

Hey everyone - Today, we are going to talk about AppLocker.  We will start with a discussion of what it is.  Then, we will talk about why you would want to use it.  Finally, we will talk about how to use it.  More after the jump...

Monday, March 28, 2016

Understanding and Deploying EMET

Hey everyone - Last week, we talked about a few defense measures you can employ on your computer or in your organization.  One of those tools was EMET: Microsoft's Enhanced Mitigation Experience Toolkit.  Today, we will talk about EMET, why you might want to use it, and how to deploy it.  Let's do this!

Monday, March 14, 2016

A Change Of Pace

Hey everyone - This week's entry is going to be very short.  In order to spend more time preparing content for you and to better accommodate my changing schedule, I am changing the schedule up a bit.  Instead of a new entry every week, I will put out a new entry once every other week.  The next entry will be on March 28, then after that, April 11.

Thanks for reading as always.

Monday, March 7, 2016

An Interlude: Setting Up A Small Windows Domain

Hey everyone - I wanted to take some time to set up an environment for us to play in.  Instead of assuming that everyone reading this was familiar with how to do it, I thought it would be good to show how to set up a simple Windows domain.  You might be asking what this has to do with information security since this seems more like systems administration.

That is a good question.  I believe that in order to adequately protect (or break into) a system, you need to understand how it works.  If you go through the steps to set up a domain, I think you will get a better appreciation for how the components fit together.  If you already know how to set up a domain or have one set up, feel free to skip this post.

We will use this little domain for examples going forward, so if you want to follow along, it would be a good idea to have a setup similar to this.

For those of you that are interested, we will talk about what we are going to set up then we will walk through it after the jump.

Monday, February 29, 2016

"Eradicating Zero Day Malware?" / A Discussion of Terminology and Some Best Practices

Hey everyone - Someone asked me an interesting question, and I thought it was worth a little bit of discussion in a post.  The question was "Once you discover zero day malware, how do you get rid of it?"  Let's talk about it after the jump.

Monday, February 22, 2016

On The Topic Of Incorrect Filesystem Permissions

Hey everyone - We had fun with containers, and now I want to shift to a slightly different topic.  I came across this article about privilege escalation due to a vulnerability caused by incorrect file system permissions.  The article talks about the issue in Windows, but it can happen with any file system and operating system.  We will take some time today to get familiar with file system permission in Windows, specifically NTFS.  We will also take a look at ways you can help prevent the issue referred to in the article.

Monday, February 15, 2016

Adventures in Containerization - Part 2: Unprivileged LXC Containers in Fedora 23 (And Probably Some Other Distros Too)

Hey everyone - Last week, we talked about what containers are and why you might want to learn about them.  Today, we will take a look at getting LXC installed and a container spun up.  When I started writing this entry, I tried to get things running on a fully updated CentOS 7 VM.  Unfortunately, to get unprivileged containers working, we needed a few things that CentOS 7 does not have, including a new enough version of shadow-utils.  Because we need to map user IDs and group IDs in the container to user and group IDs on the system, we need a version of shadow-utils that can let us add subuids to our user.  The version of shadow-utils that is available for CentOS 7 as of this writing (4.1.5.1-18.el7) does not support subuids (we need 4.2.1).  There are a number of other dependencies (including a newer kernel version - at least 3.13), and unfortunately, as of this writing not too many distributions have everything that we need. We could build all of the necessary dependencies from source, but I wanted to keep that to a minimum, and there are other packages we will need to build from source later (see below).

One of the rolling release distros like Arch, OpenSuSE Tumbleweed, or Fedora Rawhide might do the trick.  Today, I am going to explore unprivileged LXC containers with Fedora 23.  There are a few tutorials on how to get this working in Ubuntu (like this one), which we will draw from.  Most of the tutorials I have seen say to use Ubuntu because that is ready to go, but I wanted to try something different.  Maybe this will help someone who is used to RedHat / Fedora.

Most of these steps should work on any Linux distro with new enough packages:
  • LXC >= 1.0 (we are running 1.1.5)
  • Linux Kernel >= 3.13 (we are running 4.3.3)
  • Shadow-Utils >= 4.2.1 (we are running 4.2.1)
After getting everything installed, the lxc commands should be the same on any Linux you decide to run this on.  More after the jump...

Monday, February 8, 2016

Adventures in Containerization - Part 1: What are Containers?

Hey everyone - We have been talking about databases and data security for the past few weeks.  I thought it would be nice to switch gears a little bit and talk about another aspect of information security: containerization.  Containerization is the process of deploying applications and services in isolated environments.  It is similar to virtualization, but does not require installing a new instance of the operating system (and all of the overhead that comes along with that).  Containers in Linux are similar to jails in BSD and zones in Solaris.  I have not worked with containers and containerization extensively, so this will be a learning experience for me as well.  Time to get started.

Monday, February 1, 2016

On the Subject of Database Encryption, Part 2

Hey everyone - We had some fun last week working on encryption in MariaDB.  This week, we will do something similar for another popular database platform: PostgreSQL.  This time, we will do things a bit differently.  Last time, we worked through examples of symmetric cryptography.  This week, we will take a look at using asymmetric (public key) cryptography to encrypt fields in the database.

Monday, January 25, 2016

On the Subject of Database Encryption


Hey everyone - In my last post, I mentioned that there are different ways to encrypt data that you want to store in the database.  I wanted to expand upon that a bit with a few examples and some considerations when storing data in a database.

Monday, January 18, 2016

On The Subject of The State of Apathy (and Protecting Data)

Hey everyone - I stumbled across an article about a recent breach that I am surprised that I have not heard much about.  Apparently, millions of U.S. voter registration records were leaked.  Even though this story is about a month old, I think it is a good opportunity to talk about why this matters.

Monday, January 11, 2016

On the Topic of Anti-Virus Software

Hey everyone - I spend some of my spare time reading articles about information security and browsing /r/netsec.  Lately in /r/netsec, there have been a few posts about issues with anti-virus software that weakens the security posture of the machine it is installed on.  Some of the comments on those posts say not to use any of these products at all.  Rather, the best preventative measure is "common sense."  Let's talk about it.

Monday, January 4, 2016

Maybe the Triad Needs a New Member?

Hey everyone - I hope you had a safe and happy new year.  A lot happened in 2015: breaches, greater visibility into some APTs, and more breaches.  The events of 2015 will likely cause ripple effects into 2016, and perhaps beyond.  The cat and mouse game of defender versus adversary will likely continue.  I think what will be an interesting factor is mainstream awareness.  This post is not about information security awareness amongst the masses, but seeing as it is a new year, I wanted to touch on this a bit because there is a lot of talk about 2016 might bring.

With breaches affecting so many people nowadays between health insurers, retailers, and anyone else that deals in information that someone else would want, it seems that more people realize how much of their information is out there for the taking.  I see it going one of two ways: breaches will become so common that they are no longer news (which may already be happening), or people will push for change when it comes to keeping their information secure.  That could mean that people take it into their own hands by taking proactive steps to keep their data safe (which is not trivial, and some might say impossible to do one hundred percent).

It will be interesting to see what happens.

I want to switch gears now to talk about something along this vein, but it is a topic that might be somewhat controversial.