Posts Tagged ‘Linux’

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?


I was considering posting some relatively technical article tonight, in fact I laid the ground work, fired up the VM did all the testing and took all the screen shots already. However, in doing that I realized that quite frankly many of the individuals in the open source community who put forth an effort to aid, educate or in other words help new users understand the security benefits and ramifications of a Linux based operating system are rarely praised.

Sure there are professionals out there, and we seek to educate, others just want to make it through the day alive, and others still are security evangelists (divas); a title which I myself have no doubt earned several times over in certain circles. The truth is though, particularly in the community on Ubuntu Forums the individuals who try to help are not compensated in any way shape or form. They are volunteering, and they do it for the betterment of the community. I am speaking about several individuals in particular whom I will name (well handle) at the end of this. These individuals took a concept, that is not easy to approach “Security for Newbies” (new users being the politically correct term), and undertook a huge task by organizing the community and putting out a fairly detailed amount of documentation as well as a gigantic thread with all sorts of crazy stuff in it. They did this in a relatively limited time and with a limited knowledge base, researching a lot of information so that others may learn from their work.

I was involved in this project as well, and while I did not even begin to bear the burden of the work, I did receive a portion of the flames that I’m sure those spearheading the project received. I heard “hey man Ubuntu is secure, you’re spreading fear uncertainty and doubt.” or “This isn’t what Open Source software is about”. Truthfully, with respect to those opinions (it’s my blog if you don’t like it leave) I disagree. The efforts put forth by these individuals is at the very core of OSS, in that they are sharing the knowledge which they acquired, whether you like it or not for your benefit. Of course, if you disagree, or just don’t want to hear it, you’re entitled to that opinion.

However, my thoughts on the subject are that everyone involved did an amazing job, and it was a great project to be a part of, and hopefully we can keep the ball rolling and making it something better still. In fact in my opinion it was a unifying thread in some respects, and it dissolved a lot of the mysteries surrounding Linux/Ubuntu and a great deal of good came from it.

So overall, I just want to say great job to all of those involved in the “Security for Newbies Thread” and the associated wiki it spawned.

So without further ado by name thanks here it goes

  • MrLeek – The thread as your idea, and though it was a rocky start, it wouldn’t have happened without your idea and contributions.
  • Ms. Daisy – Probably the individual who put the most time in editing building and otherwise organizing a giant conglomeration of ideas and thoughts. Probably also the largest learning curve achieved (MVP anyone?). Ambitions for blue team (see you soon ;-))
  • Olle Wiklund – Contributed multiple ideas, as well as marketed the idea of the wiki and promoted it to individuals who desired learning.
  • Haqking – An infosec professional with like a billion years of experience and a really good friend of mine, who’s contributions to the thread helped greatly (as well as a good place for me to vent some frustrations) Also note worthy this man is lethal with google 😉
  • Thewhistlingwind – Keeping the thread on track with grounded and practical knowledge of application in security concepts. To quote a song by The Offspring “you’re gonna go far kid.”
  • vasa1 – you only made a few posts, but you helped guide the direction of it more than you probably realize (as I was putting in research for different concepts in the thread I kept finding your name in most of the things I looked up lol.
  • mrwoof – Router security tips, simple things that most people don’t look at but can end up devestating quickly
  • BlinkinCat – Encouraging the thread and FAQ in its infantile stages
  • tartalo – Also encouragement, probably when the project needed it the most
  • Spartacux – I know I give you crap for wearing your “tin foil hat” too much, but you made some great points, and though a lot of the privacy related stuff didn’t make it to the wiki your points will still be heard through the thread.
  • dflyer – While I disagree with the usefulness of shieldsup and anything else made by Steve Gibson, it does have its purposes, and can help educate users (mostly correctly) in the state of TCP ports. +1 for contributing a resource that speaks clearly to some people.
  • OpSecShellshock – Another talented infosec professional, I’m pretty sure this individual knows everything there is to know about web based vulnerabilities, well done and thank you for taking the time.
  • crazyguy50 – For elaborating very concisely what shields up does. (you did miss the part about selling subscriptions to zone alarm though :-P)
  • CharlesA – IT professional, and well on his way to becoming a member of the Infosec field, keep at it, you’ll make it you’ve got your head in the right place. Generally cool guy and official mod mascot 😉
  • Bukie – Awesome points on passwords, even more winning for sending the thread into a 2 day debate about divulging password constructs
  • desukane – Contributed by bringing the wiki back to a level of speaking to its target audience (which was not in fact at B-Sides)
  • Lisati – For bringing a GOOD choice of beer and differentiating two very important social groups “hackers” and “crackers” hackers make money legally and shower, this is the difference. 😉
  • jramshu – For bringing some good points to the thread as well as a healthy sense of paranoia (and on a personal note for reminding me that we should in fact NOT mess with Texas)
  • Orangecrate – by providing a dissenting opinion, you can’t make a document relevant if you can’t make it important to those who couldn’t care less.
  • leoquant – valid points about targeting of certain platforms flash in particular
  • Vanhenjyr – for pointing out the fact that some of this stuff is really hard to embrace, thus spawning the NoScript configuration guide 🙂
  • Many Anonymous Contributors – For those who didn’t want to be recognized, you’re still getting recognized. Thank you for your contributions
  • If I missed you in any way — please send me a message on the forum I will add you to the list if you want to be, if you do NOT want to be on this list let me know I will take you of as well.

    Also this project is not dead, or finished, if you’d like to contribute feel free to join in 🙂

    Have a great weekend everyone!
    (read I’ll see you on the forums tomorrow morning lol)

What’s a seven letter word for the cycle of death and rebirth? Awesome! No seriously, it’s Samsara. However awesome is the word that I have in mind when I’m referring to Zenix OS 2.0. I actually read about this project on Silver Fox’s blog. Turns out it is designed to be a Debian respin for Buddhist users. Now I’m not Buddhist , despite the nature of my gravitar, so I’m sure there are a lot of hidden ‘goodies’ in this OS for those who appreciate the finer points of the Buddhist culture and religion. From my point of view what I see is a very light-weight , very pretty, but not feature deprived Linux distribution. I love this respin I really do. Great job to Bodhi.Zazen, Silverfox and anyone else who may be involved in this project because its coming along VERY nicely.

What I Love About Zenix

In my opinion, it’s gorgeous. If you are a huge fan of graphically rich environments like Gnome Shell, KDE or Unity, this distro might not be for you. However, if you like simplicity, with a little extra frill and a nice looking tiling window manager then you’re in the right place. One of my favorite aspects of it is the large collection of custom wallpapers that come with the distro, they are VERY cool, if you like eastern culture styled themes these are sure to impress.

Outside of the “pretty factor”, this OS is extremely light-weight and fast. This is to be expected from any Debian respin, however when combined with the attractiveness of the environment it balances out quite well. It runs in less than 100 MB of ram on a VM, this is also stated on Zenix’s website, however I coffirmed that it was sitting right at 92 MB using Oracle’s Virtual Box. It comes by default with XFCE 4 while it’s not as pretty (by some standards) as KDE or Gnome, I love it , it does the minimalist concept behind the Operating System a lot of justice while still keeping it attractive.

In addition to the overall layout and look of this spinoff it is jam packed full of little extras, which I assume tie in to the Buddhist aspect of the operating system. As I said I’m not Buddhist so I can’t fully appreciate them however it was a pleasure exploring some of the nifty mixins (read I spent a lot of time googling what words meant). One example that I thought was really creative and interesting was the terminal spinoff of “cowsay”, which in this case would be Dhammapada say (Buddhist Spirtual text, the title translates roughly to path of eternal truth). An example of what my terminal greets me with is here.

If it ought to be done; then do it; apply yourself to it strenuously. A lax man of religion spreads even more dust.

You don’t have to be Buddhist to appreciate the quote, and that’s not to say that any religion or culture should be reduced to terminal novelties, but it was definitely a welcome change of pace from nix sysop quotes that don’t really maintain their relevance. Other cool Buddhist tie ins that I found were in the 2 default desktop names, Samsara and Nirvana, as well as the Conky theme.

What I Like About Zenix

Zenix is not feature leen in the slightest, it comes bundled with IceCat (like Firefox) and Midori for browsers. I’m not a huge fan of Midori but I know it does have a loyal following. One of the things I like about Zenix that makes my little sec-dork heart feel super warm and fuzzy is the fact that IceCat comes with NoScript and Ad Block (as well as a few others) pre-installed in this distro. Also bundled are VLC, Xchat and a host of other useful applications to get you up and running out of the gate.

Security Includes

Another interesting feature in Zenix is the security menu, I’m not sure how I feel about some of this but there are some decent features in here. Some of the more useful are CryptKeeper for encrypting folders and files as well as GUFW for configuring your firewall. A feature in this menu I’m not a huge fan of to the point of disliking is the Keepassx password safe, if you don’t know me you might not know but I think password vaults are stupid, though if your only alternative is a sticky note I suppose it serves its purpose.

The next set of “features” I truly do not understand. If someone could explain to me what Zenmap or Wireshark have to do with Buddhism, or eastern culture I would love to hear it. I’m not against Wireshark or nmap except in the fact that many people in the Linux community believe that Wireshark is in fact the solution to every problem that may occur on a network.

Suffice it to say these two applications are under the security tab. You’ll also find a sub tab labeled “Intrusion Detection” in this we have the ability to disable and enable the PSAD daemons (there are 3 total). You will also discover that FWSnort is installed by default and configured with PSAD. This gives us the ability to create a powerful firewall. I was excited about the idea that these might be implemented in such a light-weight distro, unfortunately my expectations weren’t quite met when I discovered that by default PSAD/FWSnort isn’t enforcing anything in particular worth mentioning. Perhaps in future versions including an updated set of Emerging Threat’s latest snort rules would be good. It’s not a terrible idea to include an IDS (assuming Buddhists are extremely security conscious desktop users), however it would be greatly improved if the IDS did something other than block basic nmap scans.


I was actually fairly surprised to find that the online Documentation and Forum available were surprisingly complete. This is always a bonus, and while I didn’t particularly find anything that I needed (I didn’t need anything) the pre-made Virtual Box xorg.conf came in rather handy.

Things I Didn’t Like So Much

Honestly, there wasn’t much I didn’t like about this. The biggest thing I disliked is that the installer is a royal pain. It gives some really nice customization options, and I’m not sure if the intended target audience is Linux savvy or not so I won’t comment on the fact that it is not your standard Ubiquity installer. The ordering of the installation process just felt awkward even in a VM. Not unworkable as obviously I installed it, it just could have felt smoother.

Sudo/su is a little bit flaky. During install time I chose to go with using su over sudo (I’m not a fan of sudo). Ironically I ended up getting both, and when it came time to install Virtual Box guest additions, neither one quite worked right. So this is something that may need to be tweaked in future versions.

Overall, I still think its a great distro and hope they keep improving on it. If you’re interested in getting a copy of this distro you can do so from their official website.


With the release of Ubuntu 11.10 Oneiric Ocelot upon us, I decided I would discuss one of the lesser used security features bundled with Ubuntu, Apparmor. Apparmor is actually a great utility particularly in terms of desktop security where browser exploits can become ridiculous quickly. It is suited for production applications as well, however often times is forgone due to the resources confining an application can require.

This guide is designed for the desktop user who all too often chooses not to use Apparmor for the reason, it’s too complicated, it’s a very advanced task, there are no premade profiles for my software; whatever the reason Apparmor is a great security feature, and while us Ubuntu users don’t have something super convenient like YaST to help us configure it, we can still create our own Apparmor profiles with relative ease.

For those of you who don’t understand what Apparmor does but just know that it’s a good thing to have. A quick explanation is, it limits what an application can and can not do, by utilizing a profile with a pre defined set of controls. If the application tries to exceed that profile it will not be allowed. This is useful for countering the dreaded 0 day exploit. Apparmor will essentially limit the exploit code to exercising the program’s functionality. While this still may be undesirable it is much less devestating than the alternatives.

This guide was created with the aim of showing a Novice user how to create their own Apparmor profile, it was created using the oh so awesome and new Oneiric Ocelot, but should work on Lucid Lynx, Maverick Meerkat and Natty Narwhal, anything older I can’t guarantee, although Apparmor hasn’t really changed that much so most will likely still apply.

Making sure we have all the necessaries

Before we delve into creating our Apparmor profile let’s make sure we have all the necessary tools in this case I’m referring to the Apparmor utilities package. We can get it by doing the following

sudo apt-get install apparmor-utils

For this guide we will be constructing a profile for Chromium Browser you can install it by doing the following

sudo apt-get install chromium-browser

Understanding Apparmor Profile Syntax

I will be walking you through the creation process , as well as some of the syntax options we choose and why, however it is wise that you familiarize yourself with all available parameters here

A brief summary of syntax and parameters :

#include – includes abstractions from another profile to help simplify the profile creation process
capability – adds a capability on a per-thread basis (eg : capability sys_admin , capability dac_override)
network – adds networking capabilities (eg : network inet stream)
Access modes
– r : read
– w : write (don’t use with append)
– a : append (don’t use with write)
– ux : unconfined execute
– Ux : unconfined execute with a steralized environment
– px : discrete profile execution
– Px : discrete profile execution with steralized environment
– m : protected execute utilizing mmap()
– l : link
– k : lock

As I said, if you need more information on the function of these check the link here for a more in depth explanation.

Creating our Apparmor Profile

The first step in generating our Apparmor profile for Chromium is to type the following in a terminal

sudo aa-genprof chromium-browser


this tells Apparmor we to generate a profile for /usr/bin/chromium-browser. Once you’ve entered this command you will be prompted to “Scan for system events” , before we do this we need to start Chromium and exercise it’s functionality. Start it up, visit some websites and generally use the browser as you normally would.

Once we’ve done this we can hit “S” to scan for system events. You will be given some choices on what chromium will have access to, this is where it gets a little complicated, and we need to understand what chromium is doing with them.

The first we will be given is /bin/readlink : we can grant ix (inherit execute) to this by pressing X

The next option is /etc/chromium-browser/default : this is our chromium configuration and we can give this r so we press A for Allow

After this we can allow w in /home/*/.config/chromium/FirstRun by pressing A, now here we are given a choice of /home/username/.config/chromium/FirstRun or /home/*/.config/FirstRun, the * acts just as you would expect a wildcard which means match any name we use our arrow keys to scroll down to this and use this option because it makes our profile more portable, we may not always have the same user running our confined application.

The next choice is to allow read in /proc/meminfo , we want to do this so that chromium can manage shared memory , so we choose A for Allow.

The next option is to allow read in /usr/bin/chromium-browser , we want to be able to run our browser so we choose A for Allow, we may have to come back and tune this.

Next we have the option to allow read in /usr/share/icons/Humanity/devices/16/drive/drive-harddisk.svg or to add an abstraction that gives us access to this path, for this we will scroll up to #include and hit enter

After this we will be prompted to save our file. We will press S to do so.

Debugging our Profile

At this point we have a shell of a profile generated for Chromium in /etc/apparmor.d/usr.bin.chromium-browser , we can view it and edit it by doing the following

sudo nano /etc/apparmor.d/usr.bin.chromium-browser

As you might imagine our profile is far from complete, so we will now edit it with our text editor.

The first thing we will want to add to our profile is

#include <abstractions/audio>
#include <abstractions/nameservice>

This will insure that chromium has access to audio and dns lookups.

Debugging the profile manually

Many people will say to place the profile into complain mode via

sudo aa-complain usr.bin.chromium-browser

Then use the application for awhile and run

sudo aa-logprof

To go through the options of what to allow and disallow. This is a good option, but it takes a really long time, so what we’re going to do is debug the profile manually. In a seperate terminal window (not as root) we are going to run chromium-browser and watch for errors.

The first error we can see is that we don’t have access to /etc/lsb-release. We can grant access to that by adding the following to our apparmor profile

/etc/lsb-release r,

At this point we can reload our profiles by doing the following

sudo /etc/init.d/apparmor reload

and attempt to execute chromium-browser again. This time we are told we don’t have permission to acces /usr/lib/chromium-browser/chromium-browser we can add the following to our profile

/usr/lib/chromium-browser/* r,

we can use the star because it is safe to say that Chromium should at LEAST be able to read everything in it’s directory. As we can see that is not enough, as we are still presented with the same error after reload. We can get around this by adding

/usr/lib/chromium-browser/chromium-browser rix,

To give execute permissions to the chromium-browser file. Our next error shows that chromium-browser-sandbox in the same directory is also needed, in order to insure the least amount of permissions given are, we add the following instead of a wildcard.

/usr/lib/chromium-browser/chromium-browser-sandbox rix,

Our next error is failed to move to PID namespace we will add the following to our profile

capability sys_admin,

/proc/*/fd r,
/prox/*/auxv r,

Our next error is slightly more cryptic but essentially says cannot chroot into /proc so we need to add the following to our profile

capability setgid,
capability setuid,
capability sys_chroot,
capability sys_ptrace,
capability dac_readsearch,

/proc/ r,
/proc/*/status r,
/proc/sys/kernel/shmmax r,

Remember if you stop being able to understand what you need to do at any time you can always run

sudo aa-logprof

And Apparmor will give you suggestions based on syslog events.

Our next set of errors give us this can’t access /sys/bus/pci/devices

so we will add

/sys/bus/pci/devices/* r,
/dev/shm/** rwk,

Now we are still getting some errors, so now is a great time to run aa-logprof and get some suggestions it will add the following

/usr/lib{,32,64}/** rw,
/etc/chromium-browser/policies/** rw,

The next set of errors will all have to do with /sys/bus/pci/devices/0000:00:00.0/* So we’re going to cheat a little bit here, since if you notice the addresses are just incrementing between 4 different files we can do add the following two lines

/sys/bus/pci/devices/0000:00:0[0-9].[0-9]/* r,
/sys/bus/pci/devices/0000:00:0[a-d].[0-93]/* r,

Or you can add them each individually as the errors come, I just thought I would give you the cheater mode [a-d] matches any letter a through d , [0-9] matches any number 0 through 9.

This time we’ll see, when we start it works.

We should now have a profile that looks something like this

/usr/bin/chromium-browser {
#include <abstractions/audio>
#include <abstractions/base>
#include <abstractions/gnome>
#include <abstractions/nameservice>

capability dac_override,
capability dac_read_search,
capability setgid,
capability setuid,
capability sys_admin,
capability sys_chroot,
capability sys_ptrace,

owner @{HOME}/** rw,
/bin/dash ix,
/bin/readlink rix,
/dev/shm/** rwk,
/etc/chromium-browser/default r,
/etc/chromium-browser/policies/** r,
/etc/lsb-release r,
/home/*/.config/chromium/Default/* k,
“/home/*/.config/chromium/First Run” w,
/home/*/.pki/nssdb/cert9.db k,
/home/*/.pki/nssdb/key4.db k,
/proc/ r,
/proc/*/auxv r,
/proc/*/fd/ r,
/proc/*/status r,
/proc/meminfo r,
/proc/sys/kernel/shmmax r,
/run/shm/* rw,
/sys/bus/pci/devices/ r,
/sys/bus/pci/devices/* r,
/sys/devices/pci0000:00/0000:00:0[0-9].[0-9]/* r,
/sys/devices/pci0000:00/0000:00:0[a-f].[0-9]/* r,
/usr/bin/chromium-browser r,
/usr/bin/xdg-settings rix,
/usr/lib/chromium-browser/* r,
/usr/lib/chromium-browser/chromium-browser rix,
/usr/lib/chromium-browser/chromium-browser-sandbox rix,
/usr/lib{,32,64}/** rw,
/var/lib/dbus/machine-id r,



Hopefully this will make it easier for you to create your own apparmor profiles more quickly without having to spend days in “learning mode” for your applications. Also if you end up having any problems, with your profile in the future as your needs grow you can always go back and debug your profile with aa-logprof or manually via a terminal.

Thanks for reading I hope everyone is having a GREAT weekend! 🙂

Users migrating from Windows to Ubuntu are constantly asking, “which is the best anti-virus for Ubuntu?” Or, “Do I need anti-virus for Ubuntu?” The only constant is the replies that are given on support forums and IRC chat rooms. The basic consensus is that Ubuntu is more secure, and isn’t plagued by malware like Windows is. Now while that is true to an extent, I am hesitant to build any security model on the “honor system”. A system that says , we don’t need anti-malware solutions because the bad guys aren’t targeting us. That sentence should actually read: “the bad guys aren’t targeting us today“.

Quite simply put, if malware developers were to decide tomorrow that they wanted to target the Linux or Ubuntu desktop user base, it wouldn’t be that hard. It’s really no different than targeting Windows, the only real difficulty is that memory addressing across distributions for vulnerable applications might change considerably. However, with the readily available supply of free open source software, modifying exploit code to exploit vulnerabilities in a multi-distro environment really wouldn’t be all that difficult.

So what we are going to look at today is a typical Ubuntu 10.04.3 LTS install, fully updated running no services. We are going to compromise it and install malware. Then we are going to see which (if any) of the three leading free anti-malware solutions can find and eliminate our malware. The three solutions we will be testing today are AVG Home Linux edition, Avast! Linux edition and the ever popular ClamAV.

The Victim

As always we have our victim set up, this is a standard desktop install of Ubuntu 10.04.3 LTS, fully update, running no services, all applications are unmodified and downloaded from the repositories.

What this system looks like to an external attacker

What we’ve done here, quite simply is to create a site that creates a shell by loading malicious javascript and injecting a payload. This is nothing new, in fact it’s pretty typical and is often called a “Drive-by-download”. This works under Ubuntu because our payload is crafted to work under Linux. Once we have the shell we are then free to do as we please (note we are walking through this manually all of this could be automated).

*note : If we were using NoScript here the compromise would not have occured.

Now our malware is installed, again this would normally be an automated process, however we’re breaking it down to understand the different steps that occur here. Our malware is pretty simple in this case, it does only a few things, it key logs so that we can capture credentials, and it opens a reverse shell and a bind shell. This allows the attacker to read the keylogs and escalate privileges once a password has been uncovered. The malware being “trapped” in the home directory perpetuates itself by adding itself to the compromised user’s .bash_profile.

Now that we have installed our malware, and we can see it’s working, we will try out the top three free Anti Malware solutions, for Linux/Ubuntu. They should find two files suspicious in nature linuxmalware and

What this system looks like for us after the compromise


So, I have the latest version of Avast! for Linux available, and I updated the definitions. I did a scan of our home folder, where our malicious files are stored /home/.mozilla/firefox to be precise. The results, Avast! found nothing wrong whatsoever.

AVG Anti-Virus

I would have liked to have gotten the results from AVG, however the current version of AVG did not work when installed under Ubuntu 10.04.3 LTS, either from .deb or compiled from source. If someone knows how to stop it from segmentation faulting on scan, please inform me, I would love to know if it detected this, as the Windows version does detect these files as malicious.


As we can see, ClamAV also did not find our files particularly malicious or interesting in nature.


Seeing as though none of our scanning engines detected a reverse shell, bind shell, or keylogger. We can pretty much say that the Ubuntu community is NOT properly prepared if malware authors DO start targeting our desktop systems. The past few years have seen marginal increases in Linux based malware threats, and as the operating system becomes more popular in the home user space I’m sure it will begin to draw the attention of malware developers.

I keep harping on these points in my posts for two reasons. One — Malware can be propogated in Linux the same way it can be in Windows, it just isn’t. Two , if it ever is, the Linux community will be unprepared for it. So the next time you’re arguing why mainstream developers don’t go near Linux, keep in mind, its security may be highly over-rated.

I also highly recommend that you use NoScript, since these types of attacks can very easily be targeted at the Ubuntu and Linux communities. The fact that they aren’t is sheer luck in my personal opinion.


In the wake of the scare, everyone is talking about root kits and hacking of Linux. So let’s talk about what a root kit, more particularly phalanx-b6 which is very similar to (if not identical) to the root kit installed on the server. We will also discuss more practical methods for “rooting” a system in the Ubuntu world.

This was written and tested using Ubuntu 10.04.3 LTS as a frame of reference to make it relevant to the Ubuntu community. This is also written to clear up myths and misnomers about root kits.

The Compromised Machine

Like Windows , in the Linux world all root kits start with a compromised machine. In terms of every day use this usually comes in the form of weak credentials. Whether it is a weak password, or a stolen ssh key the most common method for getting “rooted” is by leaving your credentials weak. In the case of services like a publicly exposed VNC this is going to be the case, with a maximum 8 character password it is a virtually unsecurable service.

Less frequently there will be a service exploited that yields code execution, though this is not as frequent it is still possible. Of course in the home userspace you have all sorts of file format exploits, pdf’s packaged with malicious executables, debian packages that have been injected with malware, and of course browser based exploits (thank you Adobe we love you). Still most frequently the “rooting” occurs due to weak credentials, even in the event of one of the above mentioned exploits occuring you either had weak credentials or a poorly configured system that allowed local escalation, both are quite possible.

note : after running the initial bruteforce to get a time estimate we added the password to the beginning of the wordlist to clean up the screenshot

In this case we will focus on weak credentials, since that is by far the more common of and more easily demonstrated (meaning I don’t have to install vulnerable services to make it work).

This machine is going to have SSH installed with weak credentials, not something unlikely to be found either on an internet facing server or a home machine. Just as a quick illustration of why strong passwords are so important we are going to “crack” our VM really quickly, and gain ‘unauthorized’ access to it. Of course, it’s our VM so this is perfectly legal. For this demo we actually used a password that might be considered “reasonably strong” , yeah it’s not. It took us about 20 minutes to brute force this password which needless to say was “ag00dpassword!!”

* note : For those pointing out where we can secure this; yes denyhosts or fail2ban would be a great idea here , but many server admins don’t use them for whatever reason.

Installing Phalanx-b6

So here we have our remote terminal session going and we’re going to install the Phalanx rootkit on our Ubuntu 10.04 machine. So we’ve compiled it successfully on our victim machine (VM ;-)) and we’re going to run the install script now.

Uh oh, segmentation fault, that’s not good.

But wait…

Let’s take a look at what the system looks like after a reboot. Where did our “/.bad” directory go?

It’s no place to be found, because it’s being hidden by the Phalanx rootkit (along with /usr/share/.home/.ph1) Let’s see what a common anti-rootkit solution for Linux says about this, out comes the ever infamous (mostly for false positives) rkhunter.

And there it is rkhunter detected our phalanx root kit working happily on Ubuntu 10.04.3 LTS. Thankfully, this rather archaic rootkit was easily detected, unfortunately it is less easily removed, generally if you want to play it safe you will be doing a full reinstall after you see something like this occur.

For reference, Phalanx key logs, steals ssh keys and opens a back door listener port (9091).

Other Methods of Post Exploitation

Another commonly used method of post exploitation is loading up the system with backdoored php web shells and netcat listeners, possibly running hash cracking locally (although this is a really good way to get found).

We will look at a simple and publicly available post exploitation script, this script allows for adding of administrative users creating web shells (if a webserver is present) and the installation of several services such as nmap , hashcat, netcat, and others. This is just a simple shell script, and is something that is much easier to detect, the only methods that it uses to hide itself is by sanitizing logs, and it doesn’t do anything without direct interaction. This is quite simply just an automated tool to make post exploitation easy, similar to the metasploit meterpreter payload.

This is much more common then an actual root kit, and is often classified as a root kit, it is important to understand that this type of script is NOT a root kit.


So now that we’ve illustrated a couple of different techniques that are commonly used during post exploitation, what can we as system administrators or home users do?

  • USE STRONG CREDENTIALS : I can’t emphasize this enough, consult the beginning where we brute-forced our ssh password if you don’t know why you should.
  • Use things like denyhosts and fail2ban to prevent brute force attacks from being successful, use them in conjunction with key based authentication.
  • Audit your logs : This catches alot of activity, however not all.
  • Use strong outbound Firewall Policies : A strong outbound iptables firewall would have stopped the bindshell created by phalanx dead in it’s tracks, it would not have stopped the root kit from being active, but it would definitely have denied access to it, granted, the user had root privileges so could have insured the firewall policy was allowing the traffic.
  • If you think you’ve been compromised use things like rkhunter or chkrootkit, yeah they cough up a lot of false positives, but as you can see they DO work.

Basically just be careful with how you run your system, neither Ubuntu nor any other operating system is secure unless you follow a decent security model yourself.

If you would like to examine any of the files used in this article you may download them below (please be an adult with them). I also would not recommend installing them on your own machine, for obvious reasons.

Phalanx-b6 Shell Script

As always there has been debate about the overall security model of Ubuntu, and truthfully, it’s just fine. However, where the problem does come in is where people blindly assume that Ubuntu is beyond reproach in terms of security. That is a disaster waiting to happen.

Risks of installing packages

Normally, when you’re installing from a trusted repository you are trusting the administration of the repository in terms of quality assurance. This makes sense, there are many methods in place for ensuring package continuity. That being said, when downloading packages elsewhere you have to be more careful, when you’re installing that package you are giving it a lot of room to groove so to speak. We will get into that more in a moment, however let us look for a moment at what the average user might do when downloading a package that might not necessarily be trusted. For this example I am using a copy of XPenguins with some slight modifications. So you have your .deb package downloaded, and you want to make sure it’s good to go before you fire up dpkg and install it.


Logically, some user’s might check the file for “viruses” or other malware using a popular Linux solution, ClamAV. As we can see ClamAV with the latest definitions finds nothing wrong with our XPenguins. This is a vote of confidence, let’s take a look at what a few other AV engines think about it, 42 of them to be precise. You can view the Virus Total report here.

So we are fairly confident about this file being safe for consumption at this point. However, we are still a little bit paranoid.


Since we are mildly concerned with the possibility for viable Linux malware and other security issues we have our UFW configuration set to be a little more paranoid than most users. We are blocking all outbound ports except those we KNOW we need.

At this point we are fairly confident to install XPenguins and have cute little Linux mascots killing themselves all over our desktop.

Installing the package

so we install our package using a typically accepted method for installing .deb packages.

sudo dpkg -i xpenguins_2.6-4_i386.deb

…And we have penguins doing all sorts of cool stuff all over our desktop…

Wait…what happened?

So we just installed our package, and we have the software we want, but let’s take a closer look at what just happened.

An explanation of how this happened and how to prevent it.

So we’ve gathered that somehow we obtained a remote shell when this machine installed our package. But how? Quite simply we created a malicious executable and repackaged the file, this executable could have been anything, in this case it was meterpreter, however there is absolutely no reason it could not have been some new “Linux malware” that supposedly doesn’t exist.

How did it have root privilages?

Quite simple, the repackaged executable contained a post install script that executed our malicious executable, since dpkg was run with sudo to install the application it had root privilages. Allowing us to do all the above, including adding a user to the administrative group (sudoers), installing SSH, and updating the firewall rules to allow incoming SSH traffic. Granted in a “real world” example an attacker might opt for something more discreet, like netcat. However I used SSH to emphasize that the “attacker” could do whatever it was they wanted, uploading netcat and creating a persistant listener would have been only a matter of creating a shell script and an upstart job.

Why didn’t Anti Virus Detect it?

Simply because it was packaged, additionally an executable that creates a reverse connection is not inherantly malicious. Plus, the fact it was packaged as a .deb obfuscated it’s intentions from typical heuristics based analysis. The MD5 sum obviously wasn’t flagged as malicious as we’d just created the file.

Why did UFW not stop it?

The listener was bound to port 80. It’s a safe assumption that most users with internet connectivity will use port 80, thus that it will be allowed. UFW even with restrictive rules did nothing here.

How can we prevent this if it is undetectable?

Well the good part is it’s not undetectable, it just will go beyond detection by most “normal” users. If we extract the contents of the .deb using dpkg -x. We will see exactly where our malicious executable is /usr/bin/xpenguin_ownage. If we run THIS file through AV it will detect it as meterpreter immediately.

What about Apparmor?

Yes, you could in theory create an apparmor profile for dpkg, although I would think it would be very difficult due to the amount of things dpkg needs to access in order to successfuly install software.


Just a little food for thought next time the “how safe are PPAs” debate comes up. Anyone can put whatever they want in a PPA, just remember that. Also if you want the totally awesome application xpenguins it is available in a non malicious version from the repos using :

sudo apt-get install xpenguins

If you would like to analyze the xpenguins package I created for this it is available for download here (it is back doored, you have been warned)

Have a great weekend everyone!