ata passwords

i’m quite suspicious of ATA passwords, and i think that it justified by what has gone on in the past

1) disk manufacturers have been known to add backdoors

– seagate drives were once shipped with a hardcoded master password (printed on the drive itself), which people had trouble changing

– there are collections of ATA backdoor passwords on the internet, demonstrating that it was a widespread phenomenon

– drive manufacturers have been induced or coerced into introducing firmware backdoors

2) BIOS manufacturers have been known to weaken the passwords passed to the disk by encoding/truncating them

– limiting the number of legal characters (reducing entropy)
– truncating or limiting the length of the password string (reducing entropy)
– converting all the characters to be case-insensitive (reducing entropy)
– translating ascii codes into ‘scan codes’ (reducing entropy)
– i would say this is all likely at the request of intelligence agencies

3) the actual protections and limitations are often not clear

– i remember a story of a drive claiming ‘AES encryption’, but where only the encryption key was protected with AES, then the key was merely used to XOR the actual drive data (can’t find link)
– people might set the user password and not realize that there is a good chance of there being be a known, or trivially breakable, master password lurking in the background (which they could have changed but didn’t know they had to)
– transferring a disk to a machine with a different BIOS (manufacturer and/or version) may well not work out well, because the BIOS ‘translates’ the user input in a BIOS-specific way before forwarding it to the disk. i.e. successive generations of lenovos do it differently, and dell does it differently to lenovo, and so on

4) BIOS manufacturers have often backdoored their products, and a backdoored BIOS means your ATA password can easily be compromised

– likely out of incompetence/misguidedness at first, and then due to intelligence agency pressure
– ‘accidental‘ vulnerabilities can act as a backdoor into the BIOS

5) specialist services exist to remove user/master passwords from drives

– i don’t know whether this applies to the latest generations of drives or not, it could just be hype.. but who really knows? (“all Samsung 3.5″ and 2.5” drives!!!)

over time the ‘depth’ of the backdoor has increased. first it was just a ‘special string’ on the BIOS or disk, then it was a per-unit secret string, then it was a weakening of the entropy of what the user entered, and now it’s likely deep in the drive firmware

as the depth of the backdoor has increased, the comfort level to the user has increased, and the threat level has gone from ‘nextdoor neighbor’ to ‘an intelligence agency’. the trouble with backdoors, though, is that if they become public they can be used by anyone

anyway, i guess for the non-top-secret business case, the ATA password might well be good enough. without expensive specialist support or top secret knowledge, and having being careful to set the drive to ‘maximum’ security (not just ‘high’), the only way a ‘mere mortal’ can remove the protection is to also trigger a secure wipe of the disk

but for the case where a government might be interested in what’s on the disk (perhaps classified material from working on a military IT project), i’m not so sure!

however, even if we deployed LUKS as well, this is probably just a speed bump.  a backdoored BIOS can likely sniff the LUKS password, malware can likely insinuate itself into /boot…  and then there’s the physical attacks (cold boot or DMA atack to get the key, evil maid to implant a hardware keylogger or tamper with /boot, …). but let’s face it, most likely of all is that they’ll get you with a client-side attack which just bypasses everything :-p

yes, if someone wants that data badly enough, they’ll get it! 😀

running a local moloch server

i came across moloch at my new workplace and thought i’d run it locally and play around with it. it’s a scalable packet capture and analysis tool. it has a nice GUI, and an API to build tools with (e.g. alerting)

# install
git clone
cd moloch

# build
./ Moloch INTERNAL encryption phrase: [0mgMolochRules1] MOLOCH: Adding user admin/admin

# add/change interfaces (if needed)
gedit /data/moloch/etc/config.ini

# fix up a script that was spewing errors
gedit /data/moloch/bin/
(add) ulimit -l unlimited

# create some sketchy start/stop scripts (can’t believe some aren’t provided!!)
==== /data/moloch/bin/start
sleep 30
nohup /data/moloch/bin/ &
nohup /data/moloch/bin/ &
===== /data/moloch/bin/stop
ps -elf | grep moloch | awk -F ” ” ‘{print $4}’ | xargs kill -9

# restart moloch

# connect

# change admin password

if you hit problems, look at the files in /data/moloch/logs. everything worked ok for me after the aforementioned steps

# links

linux process sandboxing with linux ‘user namespaces’ and firejail

i’m quite a fan of security-by-isolation, i.e. VMs and/or sandboxing. of course there are still vulnerabilities in the form of security-by-correctness failures (sandbox escapes), but i think they are far less likely to be found and widely exploited

i was initially considering running my internet-facing/vulnerable clients (browser, various messaging clients, etc) in a VM, but this seemed quite heavyweight and inconvenient

qubes would allow comparatively lightweight vms (they share the same resources such as filesystem), but that OS was out of the question because it can’t run some stuff i need it to (e.g. virtualbox VMs on top)

i figured i might not need to isolate an application in its own OS or filesystem, but rather use a sandbox. i came across sandboxie and then went on a hunt for a linux equivalent. i found firejail

it’s been described as ‘chroot on speed’, but it allegedly more secure than chroot. using linux kernel ‘user namespaces’, a container can be set up for a process so that it has its own private view of the filesystem, the network, processes, and so on

so for a potentially dangerous program (like suspected malware), one could run it in firejail where it has no internet access and no changes are persisted to the filesystem. alternatively, changes can be isolated to a private working space on the filesystem for the process (or process group)

it’s fine-grained control, so you can selectively disable ipv4, ipv6 or named pipes, whitelist or blacklist network interfaces (including localhost) or IP addresses, create a copy of the tcp/ip stack, whitelist or blacklist dirs/files, narrow permissions on the filesystem, hide other accounts entirely (such as root), reconfigure dns, and so on. amazingly you can even whitelist (or blacklist) the system calls that a process can make! amazing! but there are yet more features, such as replacing the process’s X11 server with one that allegedly cannot be screenshotted or keylogged, and whitelisting/blacklisting of ‘capabilities’ (of which there are about 35 in today’s linux kernel), which can be used to constrain superuser activities

firejail is easy to use, you just run ‘firejail <command>’. if it finds or is explicitly pointed-at a pre-baked profile for the <command> then that is leveraged, otherwise it defaults to a boilerplate profile. the default profile is generic.profile file if firejail is run by a regular user, and server.profile if run by root. profiles matching the application’s basename are searched-for first in ~/.config/firejail, then in /etc/firejail.  if you supply any other options to firejail apart from the jailed process name, then they override the respective part(s) of any loaded profile

firejail also logs attempts by the process to access blacklisted resources! and it has this nifty feature that you can symlink any binary to firejail, and firejail will look at the name it was given and then hunt for the real thing on the remainder of the path (so you could make a symlink called ‘firefox’ which pointed at the ‘firejail’ binary, and firejail would see it was actually called with name ‘firefox’, and load the real firefox in a firejail). it’s packed with good features!

firejail is incredibly easy to use. that is great, but i think is also slightly dangerous. for instance typing ‘firejail skype’ will launch the bundled profile at /etc/firejail/skype.profile and it will work fine, but i find the ignorance of what is going on under the covers a bit scary 🙂 also, i can see that profiles often use blacklisting, which i’m wary of because blacklisting is fragile.  of course whitelisting is also fragile, but in a different way 😀

so while initially i will use those pre-build profiles (of which there are many!), my goal, *eventually*, is to learn all about firejail and build my own profiles based purely on whitelisting. in fact the recommended approach for whitelisting is ‘run and profile the process with no permissions, see what breaks, fix the profile and try again’. using this approach i should build up a library of custom profiles and confidence in what firejail is allowing/disallowing, plus a much better idea of what the processes i’m jailing are actually trying to do! when i get a bit more expert then another blog post will materialize

# install firejail
apt-get install firejail

# example invocations (these all have pre-built profiles)
firejail google-chrome-stable
firejail firefox
firejail skype
firejail /opt/Wire/wire <– requires downloading the wire profile and an .inc file from

# look at the firejailed process tree
firejail –tree

lastly, firejail is itself a setuid program, which is a security risk! so there is definitely a degree of ‘security by correctness’, but hopefully it is small and the program drops its privileges after running a relatively small surface-area of code. all in all, and without being an expert in this area, i’m well impressed with firejail!

INTERESTING NOTE! an exploit for firejail has arrived! it seems to have been possible because the setuid attack surface was too large… – hopefully this will be addressed soon

# links (linux kernel ‘user namespaces’ feature overview)
Firejail Seccomp Guide
Firejail Linux Capabilities Guide
man firejail-profile