System Overlord

A blog about security engineering, research, and general hacking.

Towards a Better Password Manager

30 Oct 2014 in Security (Reading time: 4 minutes)

The consensus in the security community is that passwords suck, but they’re here to stay, at least for a while longer. Given breaches like Adobe, …, it’s becoming more and more evident that the biggest threat is not weak passwords, but password reuse. Of course, the solution to password to reuse is to use one password for every site that requires you to log in. The problem is that your average user has dozens of online accounts, and they probably can’t remember those dozens of passwords. So, we build tools to help people remember passwords, mostly password managers, but do we build them well?

I don’t think so. But before I look at the password managers that are out there, it’s important to define the criteria that a good password manager would meet.

  1. Use well-understood encryption to protect the data. A good password manager should use cryptographic constructions that are well understood and reviewed. Ideally, it would build upon existing cryptographic libraries or full cryptosystems. This includes the KDF (Key-derivation function) as well as encryption of the data itself. Oh, and all of the data should be encrypted, not just the passwords.

  2. The source should be auditable. No binaries, no compressed/minified Javascript. If built in a compiled language, it should have source available with verifiable builds. If built in an interpreted language, the source should be unobfuscated and readable. Not everyone will audit their password manager, but it should be possible.

  3. The file format should be open. The data should be stored in an open, documented, format, allowing for interoperability. Your passwords should not be tired into a particular manager, whether that’s because the developer of that manager abandoned it, or because it’s not supported on a particular platform, or because you like a blue background instead of grey.

  4. It should integrate with the browser. Yes, there are some concerns about exposing the password manager within the browser, but it’s more important that this be highly usable. That includes making it easy to generate passwords, easy to fill passwords, and most importantly: harder to phish. In-browser password managers can compare the origin of the page you’re on to the data stored, so users are less likely to enter their password in the wrong page. With a separate password manager, users generally copy/paste their passwords into a login page, which relies on the user to ensure they’re putting their password into the right site.

  5. Sync, if offered, should be independent to encryption. Your encryption passphrase should not be used for sync. In fact, your encryption passphrase should never be sent to the provider: not at signup, not at login, not ever. Sync, unfortunately, sounds simple: drop a file in Dropbox or Google Drive, right? What happens if the file gets updated while the password manager is open? How do changes get synced if two clients are open?

These are just the five most important features as I see them, and not a comprehensive design document for password managers. I’ve yet to find a manager that meets all of these criteria, but I’m hoping we’re moving in this direction.

Dangers of decorator-based registries in Python

26 Oct 2014 (Reading time: 2 minute)

So Flask has a really convenient mechanism for registering handlers, actions to be run before/after requests, etc. Using decorators, Flask registers these functions to be called, as in:

1
2
3
4
5
6
7
8

#!python
@app.route('/')
def homepage_handler():
    return 'Hello World'

@app.before_request
def do_something_before_each_request():
    ...

This is pretty convenient, and works really well, because it means you don’t have to list all your routes in one place (like Django requires) but it comes with a cost. You can end up with Python modules that are only needed for the side effects of importing them. No functions from those modules are directly called from your other modules, but they still need to be imported somewhere to get the routes registered.

Of course, if you import a module just to get its side effects, then pylint won’t be aware you need this import, and will helpfully suggest that you remove it. This generally isn’t too bad, if you remove a file with views defined in it, they’ll just fail, you’ll notice quickly, and readd the import.

On the other hand, if you’re using a before_request function to, say, provide CSRF protection, then you’ll have a serious problem. Of course, that’s the case I found myself in. So, you’ll want to make sure that doesn’t occur and use a resource from the file or disable pylint.

PSA: Typos in mkfs commands are painful

20 Oct 2014 in Computer (Reading time: 5 minutes)

TL;DR: I apparently typed mkfs.vfat /dev/sda1 at some point. Oops.

So I rarely reboot my machines, and last night, when I rebooted my laptop (for graphics card weirdness) Grub just came up with:

1
2

Error: unknown filesystem.
grub rescue>

WTF, I wonder how I borked my grub config? Let’s see what happens when we ls my /boot partition.

1
2

grub rescue>ls (hd0,msdos1)
unknown filesystem

Hrrm, that’s no good. An ls on my other partition isn’t going to be very useful, it’s a LUKS-encrypted LVM PV. Alright, time for a live system. I grab a Kali live USB (not because Kali is necessarily the best option here, it’s just what I happen to have handy) and put it in the system and boot from that. file tells me its an x86 boot sector, which is not at all what I’m expecting from an ext4 boot partition. It slowly dawns on me that at some point, intending to format a flash drive or SD card, I must’ve run mkfs.vfat /dev/sda1 instead of mkfs.vfat /dev/sdb1. That one letter makes all the difference. Of course, it turns out it’s not even a valid FAT filesystem… since the device was mounted, the OS had kept writing to it like an ext4 filesystem, so it was basically a mangled mess. fsck wasn’t able to restore it, even pointing to backup superblocks: it seems as though, among other things, the root inode was destroyed.

So, at this point, I basically have a completely useless /boot partition. I have approximately two options: reinstall and reconfigure the entire OS, or try to fix it manually. Since it didn’t seem I had much to lose and it would probably be faster to fix manually (if I could), I decided to give door #2 a try.

First step: recreate a valid filesystem. mkfs.ext4 -L boot /dev/sda1 takes care of that, but you better believe I checked the device name about a dozen times. Now I need to get all the partitions and filesystems mounted for a chroot and then get into it:

1
2
3
4
5
6
7
8
9

% mkdir /target
% cryptsetup luksOpen /dev/sda5 sda5_crypt
% vgchange -a y
% mount /dev/mapper/ubuntu-root /target
% mount /dev/sda1 /target/boot
% mount -o bind /proc /target/proc
% mount -o bind /sys /target/sys
% mount -o bind /dev /target/dev
% chroot /target /bin/bash

Now I’m in my system and it’s time to replace my missing files, but how to figure out what goes there? I know there are at least files for grub, kernels, initrds. I wonder if dpkg-query can be useful here?

1
2

# dpkg-query -S /boot
linux-image-3.13.0-36-generic, linux-image-3.13.0-37-generic, memtest86+, base-files: /boot

Well, there’s a handful of packages. Let’s reinstall them:

1

# apt-get install --reinstall linux-image-3.13.0-36-generic linux-image-3.13.0-37-generic memtest86+ base-files

That’s gotten our kernel and initrd replace, but no grub files. Those can be copied by grub-install /dev/sda. Just to be on the safe side, let’s also make sure our grub config and initrd images are up to date.

1
2
3

# grub-install /dev/sda
# update-grub2
# update-initramfs -k all -u

At this point, I’ve run out of things to double check, so I decide it’s time to find out if this was actually good for anything. Exit the chroot and unmount all the filesystems, then reboot from the hard drive.

…

It worked! Fortunately for me, /boot is such a predictable skeleton that it’s relatively easy to rebuild when destroyed. Here’s hoping you never find yourself in this situation, but if you do, maybe this will help you get back to normal without a full reinstall.

Getting Started in CTFs

14 Sep 2014 in Security (Reading time: 2 minute)

My last post was about getting started in a career in information security. This post is about the sport end of information security: Capture the Flag (CTFs).

I’d played around with some wargames (Smash the Stack, Over the Wire, and Hack this Site) before, but my first real CTF (timed, competitive, etc.) was the CTF run by Mad Security at BSides SF 2013. By some bizarre twist of fate, I ended up winning the CTF, and I was hooked. I’ve probably played in about 30 CTFs since, most of them online with the team Shadow Cats. It’s been a bumpy ride, but I’ve learned a lot about a variety of topics by doing this.

If you’re in the security industry and you’ve never tried a CTF, you really should. Personally, I love CTFs because they get me to exercise skills that I never get to use at work. They also inspire some of my research and learning. The only problem is making the time. :)

Here’s some resources I’ve thought were interesting:

Getting Started in Information Security

13 Sep 2014 in Security (Reading time: 1 minute)

I’ve only been an information security practitioner for about a year now, but I’ve been doing things on my own for years before that. However, many people are just getting into security, and I’ve recently stumbled on a number of resources for newcomers, so I thought I’d put together a short list.