Well, as you might have noticed (and some of you knew) I haven’t been updating auditme or my blog or well much of anything else. Quite simply this was because I locked away most of my data (including auditme) in a LUKS encrypted drive… I know… I’m smart huh?

Incidentally if you have a server with pretty decent uptime you might well forget that LUKS passphrase you’ve probably only used one time when you configured it 😛

So instead of giving up all my data to the encryption gods I decided that I would brute force the pass phrase. This generally speaking is utterly pointless with LUKS full drive encryption. However, in this case I knew all the characters in the passphrase however I did not know the order I had put them in. (This is usually how it works for most people).

In my particular case the passphrase was in the format of !word1@word2*word3& etc… So I created a simple program to brute force the passphrase, and voila I recovered it, along with the rest of my data. I decided since this is quite a common occurence (at least so it would seem on Ubuntu forums) that I would post the utility that I used to do this so that everyone in a similar situation may use it.

Note : This really is only effective if you KNOW some or all of the passphrase, this is not a good idea if you’ve stolen a computer and have NO clue what the passphrase is, so if you happen to be one of those law enforcement types that thinks this is a cool way to break crypto, it’s not it’s slow and inefficient.

Using the utility

Using this application is pretty straight forward. The first thing you will need to do is pull the drive and place it in another system, barring that you can boot from a liveCD (I used Fedora because I had one handy, but Ubuntu will work fine as well.)

Then simply grab the files from moi.

wget http://dangertux.no-ip.org/downloads/luksbrute.tar.gz

Extract them

tar xzvf luksbrute.tar.gz

Note : you may need to make the following files executable.

chmod 755 lukscrack.py
chmod 755 luksbrute

Then create a file full of words you wish to use the permutations of. For instance if you knew you used the special characters ! , @ and # and the words , word1 word2 and word3 the file would look like this.


So now let’s assume your password was in the format !word1@word2#word3 that’s 6 elements that we want permutations of, so we can have lukscrack.py generate our wordlist for us (if you already have a wordlist you’d like to use I’ll explain how to do that in a second.

So we would run

./lukscrack.py -g /path/to/permutation/list -m 6

and it will generate your wordlist and begin cracking with that wordlist.

If you want to use a wordlist you’ve already generated you can simply do the following

./lukscrack.py -w /path/to/my/wordlist

Hopefully this helps someone , it was rather useful to me. 🙂


Hey everyone! So today was a pretty cool day, I got a lot of work done on the next version of AuditMe which is shaping up really well in my humble opinion. There will be a major cosmetic overhaul (hey I’m not a UI designer so sue me!) and some new functionality. The latest version of AuditMe will include deeper service configuration auditing, better mandatory access control audits (thanks for the tip Carlos!) and a nifty feature incorporated from another script I discovered called checksec which is available from trapkit.de , that audits kernel tuning and memory protection features (ASLR, NX etc) in Linux. I’m stoked about this project and I really hope I can make this thing go somewhere. That being said if my horrid python skills are willing, it will 😉







In other news my friend is famous!

So as if I wasn’t excited about my little application (I know, it’s not some amazing new desktop environment to replace Unity but I’m having fun with it!), I found out from my friend Dan Dieterle who writes on Cyberarms and infosecisland that he was published in hakin9 IT Security Magazine.

I’m very happy for him and you all should definitely check out his blog AND the magazine article. I got a copy of it from him and it was very cool. Great job Dan!

Introducing Audit Me!

Posted: January 22, 2012 in Uncategorized
Tags: , ,

Lately several people on Ubuntu Forums, have been wondering if there is a simple utility to audit weak system configurations. I couldn’t find one specifically tailored to Ubuntu so I hacked on up in a few hours over the weekend. Incidentally it’s become something interesting to me and a project I will probably continue for the foreseeable future.

Audit me is designed to find weak service and system configurations (or defaults) in Ubuntu. It’s targeted toward the server side of the house though I may eventually add support for desktop features like auditing of browser security.

Below are some screenshots of some of AuditMe’s features.

To find out more about AuditMe click here

So, my wordpress analytics tell me that you guys are looking for a “how to pwn with sqlmap ubuntu” article. No seriously, that was someone’s search term. I’m hesitant to do this, but I figure with everything else I post it’s not the worst thing I could do. Cue the song “There Are Worse Things I Could Do” from Grease.

So here we go, we’re using a “live web app” with a known vulnerability for this exercise. The webapp is available in the OWASP Broken Web Apps virtual machine for those that want to follow along.

For this you will need sqlmap which if you’re using Back Track 5 as I have in this guide is already included. If you’re not you can get it here : http://sqlmap.sourceforge.net/

There are also a few other tools to do this for you like sqlsus. They all pretty much do the same thing.

So real quick, before we start there are two things you need to realize.

  • 1 – doing this to a database/webapp that you don’t have permission to do it to is illegal.
  • 2 – SQLmap performs blind sql injection. Thus it may not detect all vulnerabilities, and likely will take longer to enumerate the actual injection than is actually needed, thus I recommend performing non blind sqli manually to save yourself time.

Okay so now that we have that stuff out of the way and should have sqlmap installed by now (if you don’t know how to install it you really don’t need to be using it.) we can begin.

Vulnerable Web App

In the WordPress Spreadsheet plugin there is a SQL injection vulnerablity in the ss_functions.php that is called in ss_load.php.

The vulnerable code can be seen here :

if ($wpdb->query("SELECT * FROM $table_name WHERE id='$id'") == 0) {

Now that we have our vulnerable bit of code we can use SQLmap to exploit it.


SQLmap is an extremely powerful tool that gives you a LOT of control over how deep you get into exploiting the database. You can simply use it to confirm a vulnerability and it will give you a valid injection string to manually confirm, or you can go all the way to a full dump and sometimes (if the dbms is configured poorly gain a remote interactive sql shell/os shell).

Getting an Injection String

If you simply want to determine that the injection vector exists we can run sqlmap as follows

./sqlmap.py -u http://atfieldsandotherstuff.com/wordpress/wp-content/plugins/wpSS/ss_load.php?ss_id=1

Note : I’ve just added an entry in my hosts file to create the domain, an ip will work fine in place of this.

We discover shortly after running the command that parameter ss_id is in fact injectable, and are given the option to continue testing other parameters, you may wish to do this, however for this guide there is no point so I won’t. So we hit N. (which is the default)

As you can see we are presented with a list of three injections that we can use to verify our vulnerability.

And we can confirm that the paramater is in fact injectable.

Database Dumping

The ever popular thing to do with SQLi is “dumping the database”. This is usually how your passwords end up on pastebin, and it’s rather trivial to do it with sqlmap.

You have two options for this dump and dump-all. Dump-all will dump ALL the DBMS database tables where as dump will only dump the active dbms database tables.

Note : If the database user for the vulnerable web app is not dba there is no difference between the two options.

So we’re going to go with a dump since this user is not the dba. (a quick way to find out is using the enumerate-privileges switch with sqlmap.)

./sqlmap.py –dump -u  http://atfieldsandotherstuff.com/wordpress/wp-content/plugins/wpSS/ss_load.php?ss_id=1

After awhile you will be presented with a nice dump of your database, which sqlmap conveniently stores for you. If sqlmap detects hashed strings in the database it will also attempt to crack them for you. This can take a long time, so it may be best to just dump them hashed and crack them off site on a system that is built for hash-cracking (oclhashcat comes to mind).

Other features you might find interesting

Additionally sqlmap comes with a few options to “take over” a dbms. These do not work in all cases, and usually rely on weak configurations where the user who owns the vulnerable database happens to be the dba. These options are.

  • –os-cmd=OSCMD Execute an operating system command
  • –os-shell Prompt for an interactive operating system shell
  • –os-pwn Prompt for an out-of-band shell, meterpreter or VNC
  • –os-smbrelay One click prompt for an OOB shell, meterpreter or VNC
  • –os-bof Stored procedure buffer overflow exploitation
  • –priv-esc Database process’ user privilege escalation

By default the OWASPBWA virtual machine is not configured to allow this, however it would be trivial to grant the owner of the vulnerable database the privileges to utilize these vectors if you’re bored. Keep in mind if you prompt for an out of band meterpreter shell you have to have the Metasploit Framework installed.

There you have it, despite the fact that I will probably regret doing this and get a ton of questions asking how to find vulnerable webapps that’s the basics of using sqlmap for automated blind sqli.

Have fun! 😉

This past week I had a very stimulating discussion with a very talented co-worker of mine. This discussion was about Exec-Shield (DEP for all my Windows fans) and ASLR under RedHat. Through the course of this discussion, we discovered a very interesting script that helped us detect which of our running processes were protected by exec-shield as well as some nifty kernel tunables for exec-shield, and ASLR. Incidentally, he wrote a very informative article about it over at prefetch.net, you should check it out. Also he has a lot of other great nix sysadmin stuff there that is definitely worth your time.

Now you’re probably thinking. Hey DT what’s this got to do with Ubuntu, you’re talking about RedHat, what’s with the sensational title?

To that, I say. “Dear reader, you catch on fast. It has absolutely NOTHING to do with Ubuntu.” Therein lies our problem, for a server OS that Canonical touts as production ready with nifty slogans like “We are cloud.” I was somewhat astonished to find that exec-shield support in Ubuntu is rather limited (read nonexistant).

What is this exec-shield and why do I want it?

Exec-Shield also referred to as NX bit and DEP is a system designed for 64 Bit PAE (Physical Address Extension) systems to divide executable code into two sections, a .data section and the actual executable instructions. Basically this helps you mitigate stack, heap and int based overflows by mitigating the executability (is that a word?) of injected shell code. The overflow will still happen, however no payload execution happens. This is obviously a nice thing to have happening.

How do I know it’s enabled?

Well quite simply on a RHEL/CentOS/FC box if you do the following

sudo sysctl kernel.exec-shield

You will get some output that signifies what setting you have for exec-shield. Default is 1

kernel.exec-shield = 1

It should look like that. Really quick, a rundown on the possible values.

  • 0 – Disabled, regardless of whether the application is compiled to support it.
  • 1 – Enabled if the application is compiled to support it.
  • 2 – Enabled for all applications unless they are compiled without it.
  • 3 – Enabled regardless of what the application is compiled to support.

But what about Ubuntu? If you were following along with Ubuntu you likely got an error when you typed that command. Why is that you ask? Quite simply, your kernel does not support Exec-Shield.

Time to switch to RHEL?

Ideally, for production systems yes, for many reasons not just this, but it’s expensive (CentOS isn’t ;-)). That being said you know I love Ubuntu. So, I have an alternative solution for you.

Emulating Exec-Shield on Ubuntu

There are a couple of things to understand here before we start. Debian upstream and thus Ubuntu removed the exec-shield patch from the distribution a few years ago, claiming it was replaced by gcc’s compile time optimizations. There is a major flaw in this logic, these enforcements are made at the application level, which is a terrible place to have them made. The kernel level is much more suitable for this type of control. Incidentally, the two work wonderfully together.

We do not have access to exec-shield, however we can emulate it through grsec, which is exactly what we are going to be doing here.

Note : this involves recompiling your kernel, so breakage could ensue.

Note+ : You will also need build essential for this

sudo apt-get install build essential

Note++ : For make menuconfig we’ll also need ncurses-dev.

sudo apt-get install libncurses5-dev

Step 1 : Downloading grsec

The first step is to obtain the latest stable release of grsec.

wget http://grsecurity.net/stable/grsecurity-2.2.2-

Step 2 : Downloading Kernel Source

Next we need the kernel source, this has to be done with an unpatched kernel so we can not use our existing kernel source.

wget http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/linux-

Once it’s downloaded extract your kernel source

tar xzvf linux-

Step 3 : Patching the kernel

Now we’ll patch our kernel source.

cd linux-
sudo su -
patch -p1 < ../grsecurity-2.2.2-

Step 4 : Configuring our patched Kernel

Now we run

make menuconfig

Most of the defaults are acceptable however we need to look at our “Security” Options








The first thing we’ll look at is GRSecurity. There are a variety of options in here. You will need to explore the ones that fit your needs best. However I recommend enabling the following

  • Security Level High
  • Hide /proc from users
  • Sysctl Support On
  • Enable Features by default On

There are many more tunables that you can fiddle with here.

There are also quite a few tunables under PaX that can be adjusted here however, the defaults are quite acceptable.








Once you’re done making changes we’re ready to compile the kernel.

Step 5 : Compiling our Grsecurity Kernel

For non-Ubuntu distros (since this has been pretty generic up until this point) we can simply


Alternatively for Ubuntu users we can build our kernel in the Debian method by doing the following.

make-kpkg clean
sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion
rm localversion-grsec
fakeroot make-kpkg --initrd kernel_image kernel_headers

Note : If you follow this step you may simply use dpkg -i to install your new kernel. Users following the other method should update their grub config and install the kernel in the normal method.

After Kernel Installation

Once we have our GRSecurity enabled kernel installed we can use the gradmn tool to put GRSecurity in learning mode and create a policy which will be enforced.
You can learn more about doing that here.
Once you have done this your Ubuntu server will be much more ready for production usage. Though…Installing CentOS takes far less time 😉

It’s been a while since I’ve posted — but I return to you now with some interesting information, and some questions. Over the past 45 days I’ve been running something of a survey. Really I’ve been data mining your browser headers, don’t worry I haven’t sold your info to any third parties 😉

However what I did find was surprising. You don’t care about browser security. At all.

Overall about 2500 people participated in this survey, though they did not know it. Of those 2,500 individuals approximately one quarter of them are using a vulnerable browser without the aid of NoScript. That’s over 400 vulnerable browsers that have visited this site in the last month and a half.

Anyone have an explanation for this?

In my mind there are two possible answers here. The first being you just don’t know any better, the second would be you just don’t care. Since you’re likely interested in securing your Linux installation if you’re reading this site, there is a good chance that you DO know better.

A look at the results

The most popular vulnerable browser was Chrome/Chromium 15.0.874.102 which suffers from a use after free memory corruption vulnerability among several others. Though the memory corruption is the most significant multiple vulnerabilities fall into “serious” category. Oddly every single person using this browser version was using Ubuntu Linux 11.10 either in x86 or amd64 flavors. Canonical? Fix your repos? Or maybe people just aren’t updating.

While we’re discussing Operating System versions. I found it interesting, but not surprising that several of the operating systems running these browsers were end of life. Meaning they haven’t been receiving security updates for quite some time. Several individuals were using Ubuntu sub 8.04, and more were using Ubuntu 8.04-8.10. These operating systems are end of life, and are not receiving security updates. If you’re running these I strenuously urge you to ugrade to at least the current LTS 10.04. There really isn’t much else to say about operating systems, since browser headers are often times less than conclusive in terms of operating platform.

So what were some of the most vulnerable browsers? Well, there were quite a few but the most interesting I saw were the following :

  • Firefox 3.0.x
  • Firefox 3.5.3
  • Firefox 3.6.16
  • Chrome 6.0x

That is just a sample of the MOST vulnerable browsers, you can see a full diagram of vulnerable browsers in the graph at the beginning of this section.

So what’s up? Why are you running a 4+ year old browser with out NoScript? Now, I realize that some of you were probably spoofing browser headers, like whoever had Firefox 1.0, that’s probably not legit. However, I would wager the vast majority of these results are in fact accurate. It’s also important to note that I filtered out webcrawlers, each of these is in fact an actual browser (unless of course the crawler is spoofing headers).


Many linux users apparently just don’t care. If you’re reading this in a state of shock, but can’t remember the last time you updated anything, maybe it’s time to do a …

sudo apt-get update && sudo apt-get upgrade


sudo yum check-update && sudo yum update

After you’re done with that, maybe you should take a gander at NoScript

It’s important to understand a couple things about this data. This data was filtered by excluding any non Linux systems, this includes Android, iPhone, Windows and Apple machines, as well as any browser running NoScript. These are only Linux users. Not all are running Ubuntu, other popular distributions included Fedora, Mint, and Debian.

So, you tell me, why do you think many users are hesitant to upgrade to a more supported and secure browser?

By request, and because I haven’t posted on here in a while here’s a quickie for Tripwire on Ubuntu. This is done using 11.10 but should work on nearly any version of Ubuntu >= 10.04. It’s important to know two things ahead of time with Tripwire. One , it’s extremely high maintenance compared to other host based intrusion detection systems. Two, it depends on a known good configuration at install time. So if you feel your system is already compromised it’s wise to start off with a fresh install prior to doing this.

Step 1 : Install Tripwire

To install Tripwire, simply do the following in a terminal.

sudo apt-get update && sudo apt-get install tripwire

Step 2 : Configure Postfix

After Tripwire is installed, you will be prompted to configure Postfix. Choose local only configuration for Postfix unless you are using some external monitoring service like Satellite or Space Walk. You may accept the rest of the default options presented to you up until you reach the part of “Twipwire Configuration” Displayed below.

Super ominous warning. If you heed it go to step 3, if you say yes proceed to step 5.

You will be prompted with a warning that the debian install process sucks, and if you have your site key and configuration policy publicly exposed for a period of approximately 1.3 seconds. If this is unacceptable to you follow the alternate instructions in Step 3 below. Otherwise choose yes.

Step 3 : Configuring Site Key and Configuration Policy

First we must create our sitekey we may do so by running the following command in a terminal

twadmin -m G --site-keyfile site.key

You will be prompted for a passphrase, create a strong one and remember it.

Then we must create a local keyfile which may be done by doing the following

twadmin -m G --local-keyfile local.key

You will again be asked for a passphrase. Create a new one for the local keyfile.

Step 4 : Generate your Configuration Files

Now we need to generate our config files, we will do so by doing the following

sudo cp *.key /etc/tripwire
sudo twadmin --create-cfgfile -S site.key /etc/tripwire/twcfg.txt
sudo twadmin --create-polfile -S local.key /etc/tripwire/twpol.txt
sudo rm /etc/tripwire/twpol.txt /etc/tripwire/twcfg.txt

* You will be prompted for your passphrase for each keyfile in this step you must provide it correctly to continue. Also, do not perform the last line until you have confirmed that the above steps were successful.

Step 5 : Creating the Baseline for Tripwire

Now we simply need to run the command to baseline our system which is below.

sudo tripwire --init

and any time you want to compare the current status of the system to the baseline database you need to run

sudo tripwire --check

Enjoy 😉