Dynamic Linker Voodoo: aka How to LD_PRELOAD

The dynamic linker is one of the most important yet widely overlooked components of a modern Operating System. Its job is to load and link-in executable code from shared libraries into executables at run time. There are many intricate details on how the dynamic linker does what it does, but one of the more interesting is the use of the LD_LIBRARY_PATH and LD_PRELOAD environment variables. When defined, these variables will let you override the default behaviour of the dynamic linker to load specific code into your executables. For example, using LD_PRELOAD, you can override the C standard library functions in libc with your own versions (think printf, puts, getc, etc.)

Let's see this in action! We'll start by making a simple program to test the (now deprecated) gets() function. Here, we will create a file called test.c and put the follow contents inside it:

#include <stdio.h>

int main (void)
{
  char str[128];
  printf ("Testing gets()...\n");
  gets(str);
  return 0;
}

Note that this code is not safe and should not be used for production, but it makes a simple test scenario.

Next, we can compile the source with gcc. (Since gets() is deprecated, we're going to throw in the -w flag to suppress warning messages. We don't really care for this example.)

$ gcc -w -o test test.c

Finally, we can run the program and examine it's output:

$ ./test 
Testing gets()...
womp
$

Success! When the executable is run, it links the gets() code from libc into memory and executes that code when we call gets(). Now let's see how we can override libc's implementation with our own. First, we'll write a new version of gets() that we want run. Make a file called mygets.c and enter the following:

char *gets( char *str )
{
  printf("Error: Stop using deprecated functions!\n");
  return "";
}

Once finished, we can compile this into our own shared object library:

gcc -w -fPIC -shared -o mygets.so mygets.c

Finally, let's run the test executable again, but this time we will call it with LD_PRELOAD to load our custom shared library before dynamically linking libc:

$ LD_PRELOAD=./mygets.so ./test 
Testing gets()...
Error: Stop using deprecated functions!
$

As you can see, now our custom code is displaying where we were once being prompted for input. Of course, we could write any code we want to go in here. The only limit is whatever we can think up. This technique could be extremely useful when trying advanced debugging or when trying to replace specific parts of a shared library in your program. You can even take this a step further to create hooks for the original overridden functions.

To illustrate this, let's modify our shared library one more time:

#define _GNU_SOURCE

#include <stdio.h>
#include <dlfcn.h>

char *gets( char *str )
{
  printf("Error: Stop using deprecated functions!\n");
  char *(*original_gets)( char *str );
  original_gets = dlsym(RTLD_NEXT, "gets");
  return (*original_gets)(str);
}

We've done a few things here. We have now referenced the stdio header and we use dlsym to find the original gets() function. Notice that we use the RTLD_NEXT pseudo-handle with dlsym. In order to use this handle, we must include the _GNU_SOURCE test macro (otherwise RTLD_NEXT will not be found). This finds the next occurrence of gets() after the current library and allows us to map it to original_gets(). We can then use it in this function with the mapped name.

We can compile our library again to test out the new code (this time linking the dl lib):

$ gcc -w -fPIC -shared -o mygets.so mygets.c -ldl

Using this method, we can run our test executable again:

$ LD_PRELOAD=./mygets.so ./test 
Testing gets()...
Error: Stop using deprecated functions!
womp
$

At this point, you should notice the custom code we provided for gets(), followed by the prompt by the original libc function. Hopefully this dispels a little bit of the voodoo and gives you another valuable tool to stash in your belt.

Google C++ Style Guide

I am a really huge fan of nicely formatted and presented documentation. Sometimes I can get a little too OCD about this. If you haven't reviewed any of Google's coding style guides you should, they have a lot of nice information in there, and their views are worth considering. Lately I've decided to try and conform to their C++ guide a bit, but perusing through their doc was just ugly for offline viewing. It may not matter to most people, but I made a slightly cleaner version of the 3.274 revision of the guide in PDF format.

Download Google's C++ Style Guide in PDF here

Creating RSA public keys from private keys

Generating a public RSA key is a pretty simple task. More often than not, keys will be generated in pairs. But sometimes you will be given an RSA private key and you will need to create your own public key from it. (For example, when using Amazon EC2). Fortunately, you only need to remember a quick one-liner to do so:

$ ssh-keygen -y -f mykey.pem > mykey.pub

The -y flag tells ssh-keygen to create a public key based off of the private key passed to the -f flag. It's really that simple. by default, this will simple print to stdout, so redirecting output to a file (as in the example here) is your quickest way to saving your new key.

Node.js v0.10 Documentation

Anyone who has worked with Node.js and its documentation will know that the docs are pretty much only hosted on the nodejs.org website these days. Unfortunately, that leaves offline browsing of the docs in a particularly poor state. Since I have had the need to refer to these docs often enough without having an Internet connection, I imagine there are of ton of other people who are having the same issue.

In response, I have created a PDF file of the online docs that you can use for offline use. Download the PDF and happy coding!

Configuring a Cisco router as a terminal server

A Cisco terminal server is a router with multiple, low speed, asynchronous ports that are connected to other serial devices. These are often used to provide out-of-band management to those devices. Using this, you can establish a single point of access to the console ports of multiple devices in your infrastructure, and gain administrative access in scenarios of failed network connectivity.

Cisco usually provides a few types of breakout cables (also referred to as octocables) to connect to your router's async ports. The CAB-OCTAL-ASYNC is a 8-port variant popularly used on the 2500 series routers, and will be explained here. (Make sure to read the documentation for your device and find out which cables are appropriate to use for your setup.)

Let's assume you have a 2500 series router you would like to configure into a terminal server, and you have two 2600 series catalyst switches you will be managing. We should be able to quickly get this setup in a matter of minutes for remote access.

Cabling

Connect your breakout cable to the 2500 router and connect the RJ-45 connectors labeled P0 and P1 to the console ports of your 2600 switches. As long as all of your devices are powered on (and booted up; remember cisco gear can take 5 min or so to fully boot up) you should be ready to continue! (it's that easy.)

Setting your Loopback

You will need to have a loopback device defined in your router to properly administrate your devices on. In IOS, it should be as simple as the following:

Router(config)#interface loop0
Router(config-if)#ip address 172.16.1.1 255.255.255.255
Router(config-if)#^Z

Here, we are defining the device "loop0" and assigning the address of 172.16.1.1/32 to the device. This will be used to connect to your async lines when managing the switches.

Finding your management ports

Cisco gear is a little bit magical here, as they will automatically enumerate ports for your async lines on the loopback device. These ports will be assigned the values of 2000 + P, where P is the label of the breakout cable port number you have plugged in.

For example, we have plugged in P0 and P1 into our test switches, so the enumerated ports will be 2000 and 2001 respectively.

Configure transport access

Telnet is usually defined by default, but it's a good idea (and sometimes necessary) to explicitly define your settings. In order to allow your router to speak out to the switches over the async lines, you must set the transport settings to allow telnet. We can use the following command to do this:

Router(config)#line 0/0/0 0/0/7
Router(config-line)#transport output telnet
Router(config-line)#^Z

This will set the transport output settings on all 8 of your available async lines. Please not that, depending on the hardware you may be using, these lines may be enumerated differently. You can use the show lines command to see your actual available line information and configure accordingly.

Connecting

Now, you can easily connect from your router to either of the switches using telnet.

Router#telnet 172.16.1.1 2000

As usual, Ctrl+Shift+6 then x will bring you back to your terminal server.

If you want to make a quick alias to make connecting easier, you can do so using the ip host commands.

ip host switch1 2000 172.16.1.1
ip host switch2 2001 172.16.1.1

You can now just type switch1 to log into your switch.

From here, you can get fancy and setup aux connections to the router, say if you needed dial-up access to your gear in case of an ISP outage or something similar. But at the very least, this should be enough to get you up and going.

Exploiting masks in Hashcat for fun and profit

Hopefully you have a basic familiarity with using Hashcat. This guide will assume that you know what Hashcat is, how to load up basic dictionaries and start a job from the command line. If Any of that sounds foreign to you, I recommend you read the precursor A guide to password cracking with Hashcat before continuing.

Terms to be aware of

  • cracking chain The entire set of tools (both hardware and software) used to crack hashes
  • hash A fixed-length output of data that represents a plaintext value after it has been placed through a hash function
  • mask A specific set of rules used to tell your cracking utility which parts of a key space should be used
  • plaintext The input for a hash function. For example, a password.

The power of masks

Dictionaries can be a great tool in your password cracking arsenal, but they can hit some very real limits quickly. For example, in order to use a dictionary, you have to store it, which means you need to store all of the data for all of the different combinations you want to try. Depending on the key space and combinations you are working against, this can add up very quickly. It's also worth noting that there is a very measurable amount of time it takes to load dictionaries into memory, and I/O can become a bottleneck in your cracking chain. This is where using masks come in!

Back in the early days of password cracking, if you didn't use a dictionary, you could pretty much only use a straight brute-force attack. Fortunately, our techniques and tools have come quite a long way since then, and honestly brute-force cracking is all but obsolete these days. By using a mask, you can specify what combinations of characters to run through during your attack. The great thing here is flexibility: If you just wanted to run a straight brute-force, you would wait for your tools to run through every combination in every position until it (eventually) finds the right combination. Obviously that can take an extraordinary amount of time to complete. But what if we knew something about the plaintext itself. Let's say we now that the password is only made with lowercase letters, and ends with two numbers. Even further, let's assume that we know the password is exactly 6 characters long. At this point, it would seem like a waste to go through standard brute-force. that would require running through all combinations from one letter up, and using uppercase and special characters that we know will never match. The biggest problem here is running through bad combinations simply wastes time, and no one wants that.

Hashcat is a very flexible tool. It offers a range of different attack modes to help you out with your various cracking needs. You should reference the help information often, but let's take a quick look at it now to see the list of these modes. Using oclHashcat v1.21, you will see this information:

$ hc --help | grep -A 7 "Attack modes"
* Attack modes:

    0 = Straight
    1 = Combination
    3 = Brute-force
    6 = Hybrid dict + mask
    7 = Hybrid mask + dict

Now, technically we don't see an option for "masks" here, but I will let you in on a tiny secret. Even though Hashcat called mode 3 "Brute-force", it isn't actually your traditional brute-force. This is your mask mode ( in fact, you have to go out of your way to even make hashcat perform a traditional brute-force ). Using a mask, we can simply use the following to skip all of the extra combinations we know will fail:

$ hc -a3 hash.file ?l?l?l?l?d?d

It's a lot easier than it looks, and it's ridiculously powerful. This attack mode is a definite game-changer.

Defining your masks

When using masks, you need to define a minimum of 4 options for hashcat:
hashcat-binary attack-mode hash-file mask

It is crucial that you define each part. That being said, you are free to add in additional options, as long as those 4 exist.

  • hashcat-binary This should be obvious. It's the path to the hashcat binary itself ( in our examples: hc )
  • attack-mode For mask attacks, this will always be -a3
  • hash-file Similar to a dictionary attack, this will be the location of the file with all of your hashes
  • mask The mask can either be the actual mask you want to use, or the location of a file with multiple masks inside of it. Either one is fine, but you must supply one of them ( and only one )

To create your mask, you will simply specify which character set you want to use in which position. By default, Hashcat comes with 5 pre-defined character sets, and allows you to make up to 4 custom character sets. The built-in sets are as follows:

   ?l = abcdefghijklmnopqrstuvwxyz
   ?u = ABCDEFGHIJKLMNOPQRSTUVWXYZ
   ?d = 0123456789
   ?s =  !"#$%&'()*+,-./:;<=>?@[]^_`{|}~
   ?a = ?l?u?d?s

So let's say we wanted to act more like a traditional brute-force and go through all character combinations exactly 3 characters long. To do this, we will use the full "all characters" set, defined as ?a.

$ hc -a3 hash.file ?a?a?a

Easy, isn't is?

Now, what if we wanted to try the first letter uppercase, the next four lowercase, and the last two digits?

$ hc -a3 hash.file ?u?l?l?l?l?d?d

As I mentioned, it's very flexible and powerful.

Custom character sets

Using masks this way covers a lot of ground, but it can still stand to be a little more specific. Sometimes you may only need to search a very specific subset of characters. For example, what if you had a hash where you knew the plaintext was going to be a six character hex value. Obviously, using ?d isn't going to be enough, and using ?a will run through too many combinations that we know will be absolutely wrong. This becomes a good candidate for a custom character set.

Hashcat allows you to define a custom character set in one of four buffers:

 -1
 -2
 -3
 -4

When you define a character set, you can then call a new flag with the number of that set to use the character set in your mask. Using the example above, we would first need to define our hex character set to be used with hashcat, and we will place it in buffer 1.

-1  0123456789abcdefABCDEF

If you don't know whether the plaintext will be in uppercase or lowercase hex, this character set should cover both. The only drawback here is that it's a little cumbersome to type. Fortunately, you can shorten this down using built-ins. The following character set is exactly the same:

-1  ?dabcdefABCDEF

I tend to think that typing less is better, but feel free to use whichever method suits you best. At this point, you are ready to use character set 1 in your masks. Continuing our previous example, we can use this mask to run through your six character hex key space:

?1?1?1?1?1?1

Now let's put this all together and see how it looks on the command line:

$ hc -a3 hash.file -1 ?dabcdefABCDEF ?1?1?1?1?1?1

It's not quite as daunting as it first seemed, is it? You can, of course, refine this even further and mix in additional character sets if you need to. Let's say we know that the hex plaintext we are looking for starts with "c6" and the second to last position will only be between 0 and 9. We could create the following mask:

$ hc -a3 hash.file -1 ?dabcdefABCDEF c6?1?1?d?1

Differences in versions

It's worth noting that Hashcat and oclHashcat work slightly different here. Hashcat will run through all increments of your mask by default, for example: ?a?a?a will become:

?a
?a?a
?a?a?a

oclHashcat will not do this unless you explicitly declare incremental mode with the -i flag.

Real world practice

Using Hashcat, let's see a quick example of masks you can try from the pre-packaged examples. If you look at the file examples/A3.M0.word (in your hashcat directory), you will notice that all plaintexts for this exercise are lowercase and 5 characters long. We should easily be able to create a simple mask to crack 100% of these hashes.

$ ./hc -a3 examples/A3.M0.hash ?l?l?l?l?l
Initializing hashcat v0.47 by atom with 8 threads and 32mb segment-size...

Added hashes from file examples/A3.M0.hash: 102 (1 salts)

NOTE: press enter for status-screen


Input.Mode: Mask (?l) [1]
Index.....: 0/1 (segment), 26 (words), 0 (bytes)
Recovered.: 0/102 hashes, 0/1 salts
Speed/sec.: - plains, - words
Progress..: 26/26 (100.00%)
Running...: --:--:--:--
Estimated.: --:--:--:--


Input.Mode: Mask (?l?l) [2]
Index.....: 0/1 (segment), 676 (words), 0 (bytes)
Recovered.: 0/102 hashes, 0/1 salts
Speed/sec.: - plains, - words
Progress..: 676/676 (100.00%)
Running...: --:--:--:--
Estimated.: --:--:--:--


Input.Mode: Mask (?l?l?l) [3]
Index.....: 0/1 (segment), 17576 (words), 0 (bytes)
Recovered.: 0/102 hashes, 0/1 salts
Speed/sec.: - plains, - words
Progress..: 17576/17576 (100.00%)
Running...: --:--:--:--
Estimated.: --:--:--:--


Input.Mode: Mask (?l?l?l?l) [4]
Index.....: 0/1 (segment), 456976 (words), 0 (bytes)
Recovered.: 0/102 hashes, 0/1 salts
Speed/sec.: - plains, - words
Progress..: 456976/456976 (100.00%)
Running...: --:--:--:--
Estimated.: --:--:--:--

    --- Output Omitted ---

All hashes have been recovered

Input.Mode: Mask (?l?l?l?l?l) [5]
Index.....: 0/1 (segment), 11881376 (words), 0 (bytes)
Recovered.: 102/102 hashes, 1/1 salts
Speed/sec.: - plains, 19.94M words
Progress..: 11819600/11881376 (99.48%)
Running...: --:--:--:--
Estimated.: --:--:--:--

Started: Fri Jun 27 12:52:04 2014
Stopped: Fri Jun 27 12:52:05 2014

100% recovery; we must be on a roll! :]

Anonymizing network access with random MAC addresses

I've been reading a few articles recently about the need for people to keep their network access anonymous. A seemingly popular method is to change out the MAC address of your interface every X amount of time. It appears to be a reasonable approach; many institutions rely solely on the MAC address for various types of provisioning and tracking. If you change this reported value, all of these mechanisms tracking your access seem to get confused. By no means do I claim this is the "be-all-and-all" of keeping your access anonymous, but it's nonetheless a good trick to keep in your belt.

In response to a few scripts and utilities I've seen floating around offering to adjust your MAC address for you, I figured I'd just write one that was better than the ones I've seen so far.

The tool

cmac.sh is a simple script that can help hide your system's true MAC address. It runs on OSX and Linux, and probably many other POSIX-compliant OSes. By running this script, it will loop through your available network interfaces, and randomly assign a new valid MAC address to any "inactive" interface. You can also specify anonymous mode, where it will loop through the interface every 30 seconds (configurable) by default.

If you want to get courageous, you can even enabled bump mode, which will down an active interface during each cycle so its MAC address can be adjusted. When using this mode, you may want to set the time parameter to something long, like 5 min or so. Unless you don't mind having your active connections bumped every 30 seconds.

Additionally, you can use the -c flag to change the MAC of specific interfaces rather than all of them. For example: cmac.sh -c "en0 en1"

Remember to check out the help information (--help) before running this script.

This hasn't been heavily tested, so if you run into any bugs (or just have general questions) feel free to contact me about them.

About the randomization

This utility is designed to generate MAC-48 addresses. EUI-64 is not supported at this time. When generating the MAC addresses, I chose to embed the current list of assigned OUIs into the script (using base64) so I can keep this all self-contained. The script randomly selects one of the 19k+ OUIs and then (pseudo)random generates the remaining 3 octets for the address.

Why not randomly generate the OUI entirely? Well, there is a very small set of filtering systems out there that will actually verify your OUI against a list of those formally registered through IEEE. If they don't match, the connection will be dropped. I figured it wasn't very much work to add these in there and cover all use-case scenarios if I could. It does mean that the base64 string may need to be updated in the future to keep this list current, but fortunately they don't change often (and even if they did, 19k random OUIs is probably "good enough" for most people).

Download

cmac.sh utility

Remember to chmod a+x this file before trying to run it!

The Art of Creating Good Passwords

No matter who you are, passwords have become a critical component of one's personal life in the modern era. They are the first line of defense against unauthorized access to your personal information and technology. Your computer, your phone, your bank; they all make use of passwords in an effort to protect you from hackers and malicious software. Unfortunately, it's not simply the existence of a password that matters, because ever evolving hardware and hackers constantly discovering new and more advanced techniques to get retrieve user passwords are changing the playing field. Now, you not only need a password, but you need one that will try to withstand the deluge of attacks that could be brought against it in a compromise.

Microsoft Research released a study in 2007 which suggests that the average web user has an average of 25 accounts to maintain. Yet, the same study suggests only approximately 6 unique passwords are used among the different accounts. Unfortunately, there is quite an excess of security breaches one can choose from to see how dangerous password re-use can be. AOL, Sony, Heartland, Zappos, Ebay, and a ton of others have had compromises in recent years, exposing millions of users' passwords to hackers. But it doesn't simply stop there; each time a breach is recognized and this password data is leaked, the same data is tried against other web sites across the web in an attempt for the attackers to steal more of your personal information and assets.

What they can do

The first crucial part of password security is out of the hands of the regular web user. The sites you visit and use must implement proper techniques and algorithms to keep you safe. Too many times now, sites have been caught using old and insufficiently secure methods to store user information. There isn't much the average user can do here, especially considering you often have no way of knowing what goes on behind the scenes. This makes a good case for keeping different unique passwords at each site you use. The industry best practice is to transform your password into a password hash. In it's hashed form, there should be no way for a hash to be mathematically "reversed" into its plaintext form. For your attacker to compromise your password, they will now have to try repeated "guesses" against your hash using the same algorithm, and hope they can get a match. Don't be fooled, however, this is much easier than it sounds.

What you can do

First you need to realize that whatever you do, it's only good until the bad guys catch on. These techniques may work for a while, but they won't last forever. That being said, they should be decent enough to use a a basis for any foreseeable future.

Do not use dictionary words

For a long time, people have used a combination of words from the dictionary and maybe some numbers thrown in to compose their passwords. Maybe something you like and your lucky number (Dragon13), or a person's name and a year (michelle1980), or if the rules are a bit stricter, capitalization may be required (SomePassword123). The problem with this is that the patterns are far too predictable. Anyone can grab a few dictionaries and run some rules against them to come up with these combinations. Don't think that simply making them leetspeak or toggle-cased will fix this either. dR4g0n13 is just as easily cracked using the default rules that come with the Hashcat password cracking software.

Dictionary chaining

A popular web comic one cited "correct horse battery staple" as being an excellent password. The problem here is that hackers are now chaining multiple dictionary words together more frequently, and in a way it actually makes passwords weaker. If we think about it for a moment, when you are only trying dictionary words, each word takes the role of a character position. If you only use 4 words in your password, it's akin to using a 4 character password for those attacks.

Do not use personal information

Personal information should be avoided at all costs. It reveals too much about you to an attacker, and could potentially be too easy to obtain as well. This makes for a very dangerous combination. How easy would it be for someone to look up your facebook page and get personal information about you? Your interests. Your family. your friends. Places you like to go. Shows you like to watch. The internet is a tremendous archive of easily accessible personal information. So don't use it.

Recommendation in the wild

Microsoft makes the case for the following categories to create a strong password:

  • Is at least eight characters long.
  • Does not contain your user name, real name, or company name.
  • Does not contain a complete word.
  • Is significantly different from previous passwords.
  • Contains characters from each of the following four categories:
    • Uppercase letters
    • Lowercase letters
    • Numbers
    • Symbols

These are pretty good suggestions, but these categories on their own don't cut it. Using their example, Hello2U! is a prime example of a poor password. It comes right out of the dictionary, capitalization is at the front, and a symbol/number combination (in this case the exclamation point) is on the end. Now, there are two things two realize here. First, Microsoft makes the point that you should use spaces in your passwords. I am completely for this. The more spaces, the better. It happens to be an EXTREMELY underused character in passwords. However, their recommendation is not so great: H3ll0 2 U!. Unfortunately, this is no better than the first example. The default install of hashcat can add spaces between words and perform "leetspeak" transformations on your text, which still leaves this vulnerable.

Your passwords should definitely be long, and I do like that Microsoft recommends a minimum length, but I personally believe 8 characters to be too small. That can be a little difficult for some users, but the longer the password, the better. I tend to use no less than 20 characters for my own, but if you are using at least 10 or 12, you will be better off (assuming the passwords are being stored decently).

Entropy is your friend

By its definition, entropy is a lack of order or predictability. The greater entropy you have in a password, the harder it is to crack it. In mathematical terms, the entropy of a password is given by H=Llog2N where L is the length of the password and N is the size of the alphabet. Most people won't actually have to know what this means, but you should remember this: Use as many different unique symbols as possible in your password.

If you have a 15 character password, use 15 different characters. Again, this is a hard one for a lot of people, but it really does help. Just remember, a is not the same as A, so it's really not as bad as you might think.

Keyboard walks

Another common practice these days is to use what are called keyboard walk. This is just outright wrong! There are entire dictionaries and rulesets tailored towards these types of passwords. Just don't use them. * qwerasdf * qewradsf * zaqcdexsw123

There are tons of them I could list here, but hopefully you get the point. Keyboard walks = evil = easy = you don't want to use them.

So what makes a good password?

The idea here is to hold out as long as absolutely possible against your attacker's techniques. Nothing is 100% "hack-proof", but we can make them work pretty hard for it (and hope that many will simply give up rather than spend the effort). But keeping in mind the following should help: * It should be long (the longer the better) * It should never contain personal information * It should contain as much entropy as possible * Don't be afraid to use spaces * Avoid dictionary combinations * If you are going to use dictionary words, misspell them! * Do not use "keyboard walks"

The right thing to do is to use a password manager. LastPass, 1Password, RoboForm... there is no shortage of them available. Just google password manager and you will get a ton of information.

In lieu of this, you will need to make your own passwords using these rules, like so:
I c4N zwim f@sTer tHan S0CRAt35 bK+g
36 characters
30 different characters (not awful, I wonder if I could make that better)

It's fairly easy to remember, and although I did use some dictionary words I used a misspelling and some random garbage in there as well.

My recommendation

Use a password manager. Many are free, they are simple to use, and when a breach occurs at your favorite site, you can simply tell it to generate you a new good password. It's really easy.

perl: warning: Setting locale failed

I tend to see quite a number of people using AWS instances receiving something similar to the following:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Fortunately, it's pretty simple to correct this.

The Debian way

For Debian-based systems, you can simply reconfigure the locale package as root

# dpkg-reconfigure locales

A screen should appear, allowing you to select the locales to use for your environment. Just select the ones you wish and save.

Fedora and RPM-based systems

Fedora is a little different, but should also be easy. First you can try rebuilding the archive using some available system tools.

# build-locale-archive

If this fails, however, you can always try reinstalling your glibc common package.

# yum reinstall glibc-common

Recovering SSL certificates and keys from Firefox's local store

Many years ago, I signed up for an account online that required a client-side certificate for authentication into your account. Everything seemed to work fine, but the company's policy was such that if one were to loose their client-side certs, they would be unable to access their account anymore (the company would NOT replace lost certs). And so it happened that I ended up loosing my cert over time.

So, two years after I lost it, I found the old machine that the certs were on. Great! But of course, it wouldn't just be that easy. The machine refused to boot, so I was going to have to put in a little more effort to get this thing back.

The prep

The first thing I needed to do was grab the actual local store. It was running Fedora 14, so I figured Kali would be no problem. I was able to boot up off of a Kali 1.0.6 USB key and mount the hard disk from my machine. From here, I was able to search my old home directory and just copy the entire .mozilla folder over (better to grab everything and sort it out later).

Examining the files

I found three db files in my profile folder; one of these had to be it. A quick check with the file command told me that the files were going to be Berkley DB 1.85 files. This was misleading, however, as Mozilla is actually using NSS for these stores. That threw me for a little bit, but should provide a valuable lesson: File may be a good tool to assist your exploits, but don't blindly trust its output.

After learning the true storage engine being used, it was easy to use the NSS lib utils to extract the desired data. A couple of things to note however:

  • you will need multiple files to make this work (cert8.db stores certs, key3.db stores private keys)
  • Using certutil will allow you to extract public certificates in pem, but if you need a full PKCS#12 with private keys, you should be using pk12util
  • when using the certutil and pk12util programs, please be aware that the -d flag does not take the filename of your data store as a parameter. It is the prefix directory only. These utilities will automatically discover the appropriate NSS stores within the directory you specify.

Listing the certs

Using certutil, you can easily list the certs stored in your db. Here's some example output for a similar task using the current directory as our directory prefix:

$ certutil -L -d .

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

VeriSign Class 3 Extended Validation SSL CA                  ,,   
EssentialSSL CA                                              ,,   
support                                                      ,,   
VeriSign Class 3 International Server CA - G3                ,,   
GlobalSign Extended Validation CA                            ,,   
The Code Project Premium SSL Security CA                     ,,   
Akamai Subordinate CA 3                                      ,,   
RSA Public Root CA v1                                        ,,   
Entrust Certification Authority - L1B                        ,,   
COMODO High Assurance Secure Server CA                       ,,   
NSS Certificate AC:12:05:77:3B:BE:46                         ,,   
COMODO Extended Validation Secure Server CA                  ,,   
StartCom Extended Validation Server CA                       ,,   
Network Solutions Certificate Authority                      ,,   
Google Internet Authority                                    ,,   
Go Daddy Secure Certification Authority                      ,,   

Once you've found your certificate, just write down the name, which you can use to extract the certs.

Extraction

If you just want to extract the public cert in pem format, you can use the following:

$ certutil -L -d . -a -n "NSS Certificate AC:12:05:77:3B:BE:46" > recovered.pem

However, this will not give you the private key. In my case, I needed a full PKCS#12, so it was time to use pk12util. This is very similar to the certutil program.

$ pk12util -o recovered.p12 -n "NSS Certificate AC:12:05:77:3B:BE:46" -d .
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file: 
Re-enter password: 
pk12util: PKCS12 EXPORT SUCCESSFUL

You will be prompted for the encryption passphrase for your existing key, as well as the new passphrase for the new .p12 file you are creating.

Conclusion

With PKCS#12 in-hand, I was able to import the key into my current laptop's browser and re-authenticate to my long-lost account. Time for beer!

I'd like to thank halfie for pointing me in the right direction and letting me know that Firefox does not use BDB for the local data stores.