Despite the fact that it’s been over 2 years since I posted Part 1, I got bored and decided I should take another look at the Patriot Gauntlet Node. So I go and grab the latest firmware from Patriot’s website (V21_1.2.4.6) and use the same binwalk techniques described in the first post, I extracted the latest firmware.

So, the TL;DR is: It’s unexciting because Patriot makes no effort to secure the device. It seems that their security model is “if you’re on the network, you own the device”, which is pretty much the case. Not only can you enable telnet as I’ve discussed before, there’s even a convenient web-based interface to run commands: http://10.10.10.254:8088/adm/system_command.asp. Oh, and it’s not authenticated. Even if you set an admin password (which is hidden at http://10.10.10.254:8088/adm/management.asp).

The device runs two webservers: on port 80 you have httpd from busybox, and on port 8088, you have a proprietary embedded webserver called GoAhead. It uses not ASP, as the file extensions would have you believe, but actually uses an embedded JavaScript interpreter called Ejscript to generate active pages.

I don’t intend to spend much more time on this device from a security PoV: it doesn’t seem intended to be secure at all, so it’s not like there’s anything to break. The device is essentially pre-rooted, so go to town and have fun!

I’ve been disappointed with myself for a while for not updating more often. It’s been months! I’d been pushing myself to update regularly, but I also only want to update with genuine content. Social networks are places where I can just place random thoughts, this is a place for meaningful content that will (hopefully) be useful to others. (Though the jury’s still out on that one.)

Part of the reason for the lack of updates is burnout. For one reason or another, I just haven’t been feeling myself for a while, and so haven’t been doing as many interesting things. Some of this burnout is due to the nature of things I’ve been doing at work, but it wouldn’t be fair to blame all of it on work.

I’ve also been dealing with some (potential) health issues. Mostly it’s been a case of symptoms with no obvious cause, which is even more maddening to me. Despite reassurances from doctors, I can’t help but have a nagging feeling that something is actually wrong. It’s quite the distraction, psychologically.

So, in more timely news, I’ve made the transition from “20s” to “30s” (two weeks ago). When I was 25, I posted asking if 25 was old, because I felt like I hadn’t accomplished anything. Though I think I’ve accomplished a few things in the interceding time, I’m not convinced it was 5 quality years worth. I need to get better at prioritizing my time and making sure that I use my time in good ways. I’d like to make sure I’m either doing something I enjoy, something meaningful, or something helpful to others. Anything else is just a waste of precious time.

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.

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.

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.