Tools to reduce risk regarding password security and HDD slack space.

Question

Down at that to bottom of this essay is a comment about a spooky way to beat passwords. Scan the entire HDD of a user including dead space, swap space etc, and just try everything that looks like it might be a password.

The question: part 1, are there any tools around (A live CD for instance) that will scan an unmounted file system and zero everything that can be? (Note I'm not trying to find passwords)

This would include:

• Slack space that is not part of any file
• Unused parts of the last block used by a file
• Swap space
• Hibernation files
• Dead space inside of some types of binary files (like .DOC)

The tool (aside from the last case) would not modify anything that can be detected via the file system API. I'm not looking for a block device find/replace but rather something that just scrubs everything that isn't part of a file.

part 2, How practical would such a program be? How hard would it be to write? How common is it for file formats to contain uninitialized data?

One (risky and costly) way to do this would be to use a file system aware backup tool (one that only copies the actual data) to back up the whole disk, wipe it clean and then restore it.

Answer 1

I don't understand your first question (do you want to modify the file system? Why? Isn't this dead space exactly where you want to look?)

Anyway, here's an example of such a tool:

#include <stdio.h>
#include <alloca.h>
#include <string.h>
#include <ctype.h>

/* Number of bytes we read at once, >2*maxlen */
#define BUFSIZE (1024*1024)

/* Replace this with a function that tests the passwort consisting of the first len bytes of pw */
int testPassword(const char* pw, int len) {
    /*char* buf = alloca(len+1);
    memcpy(buf, pw,len);
    buf[len] = '\0';
    printf("Testing %s\n", buf);*/

    int rightLen = strlen("secret");
    return len == rightLen && memcmp(pw, "secret", len) == 0;
}

int main(int argc, char* argv[]) {
    int minlen = 5; /* We know the password is at least 5 characters long */
    int maxlen = 7; /* ... and at most 7. Modify to find longer ones */

    int avlen = 0; /* available length - The number of bytes we already tested and think could belong to a password */
    int i;
    char* curstart;
    char* curp;
    FILE* f;
    size_t bytes_read;
    char* buf = alloca(BUFSIZE+maxlen);

    if (argc != 2) {
     printf ("Usage: %s disk-file\n", argv[0]);
     return 1;
    }

    f = fopen(argv[1], "rb");
    if (f == NULL) {
     printf("Couldn't open %s\n", argv[1]);
     return 2;
    }

    for(;;) {
     /* Copy the rest of the buffer to the front */
     memcpy(buf, buf+BUFSIZE, maxlen);
     bytes_read = fread(buf+maxlen, 1, BUFSIZE, f);

     if (bytes_read == 0) {
      /* Read the whole file */
      break;
     }

     for (curstart = buf;curstart < buf+bytes_read;) {
      for (curp = curstart+avlen;curp < curstart + maxlen;curp++) {
       /* Let's assume the password just contains letters and digits. Use isprint() otherwise. */
       if (!isalnum(*curp)) {
        curstart = curp + 1;
        break;
       }
      }
      avlen = curp - curstart;

      if (avlen < minlen) {
       /* Nothing to test here, move along */
       curstart = curp+1;
       avlen = 0;
       continue;
      }

      for (i = minlen;i <= avlen;i++) {
       if (testPassword(curstart, i)) {
        char* found = alloca(i+1);
        memcpy(found, curstart, i);
        found[i] = '\0';
        printf("Found password: %s\n", found);
       }
      }
      avlen--;
      curstart++;
     }
    }
    fclose(f);

    return 0;
}

Installation:

1. Start a Linux Live CD
2. Copy the program to the file hddpass.c in your home directory
3. Open a terminal and type the following
4. su || sudo -s # Makes you root so that you can access the HDD
5. apt-get install -y gcc # Install gcc # This works only on Debian/Ubuntu et al, check your system documentation for others
6. gcc -o hddpass hddpass.c # Compile.
7. ./hddpass /dev/YOURDISK # The disk is usually sda, hda on older systems
8. Look at the output

Test (copy to console, as root):

gcc -o hddpass hddpass.c

</dev/zero head -c 10000000 >testdisk # Create an empty 10MB file
mkfs.ext2 -F testdisk # Create a file system
rm -rf mountpoint; mkdir -p mountpoint
mount -o loop testdisk mountpoint # needs root rights
</dev/urandom head -c 5000000 >mountpoint/f # Write stuff to the disk
echo asddsasecretads >> mountpoint/f # Write password in our pagefile
# On some file systems, you could even remove the file.
umount testdisk

./hdpass testdisk # prints secret

Test it yourself on an Ubuntu Live CD:

# Start a console and type:
wget http://phihag.de/2009/so/hddpass-testscript.sh
sh hddpass-testscript.sh

Therefore, it's relatively easy. As I found out myself, ext2 (the file system I used) overwrites deleted files. However, I'm pretty sure some file systems don't. Same goes for the pagefile.

Answer 2

How common is it for file formats to contain uninitialized data?

Less and less common, I would've thought. The classic "offender" is older versions of MS office applications that (essentially) did a memory dump to disk as its "quicksave" format. No serialisation, no selection of what to dump and a memory allocator that doesn't zero newly allocated memory pages. That lead to not only juicy things from previous versions of the document (so the user could use undo), but also juicy snippets from other applications.

How hard would it be to write?

Something that clears out unallocated disk blocks shouldn't be that hard. It'd need to run either off-line or as a kernel module, so as to not interfer with normal file-system operations, but most file systems have an "allocated"/"not allocated" structure that is fairly straight-forward to parse. Swap is harder, but as long as you're OK with having it cleared on boot (or shutdown), it's not too tricky. Clearing out the tail block is trickier, definitely not something I'd want to try to do on-line, but it shouldn't be TOO hard to make it work for off-line cleaning.

How practical would such a program be?

Depends on your threat model, really. I'd say that on one end, it'd not give you much at all, but on the other end, it's a definite help to keep information out of the wrong hands. But I can't give a hard and fast answer,