Moved!

I moved! You may find what you were looking for over at rabbit6.com 

-Jason

Start OpenVAS on Backtrack 5 the quick way - How to

A while back I wrote myself a small cheat-sheet for getting OpenVAS started in Backtrack 5 R3, and I thought some of you might find it useful.  I don't like bouncing between menus and terminals, so I wrote the steps to be run sequentially in the terminal.

1. Make the OpenVAS SSL certificate

openvas-mkcert

2. Create the client certificate

openvas-mkcert-client -n om -i

3. Download the latest NVTs

openvas-nvt-sync

4. Start the scanner service

openvassd

5. Rebuild the NVT database

openvasmd --rebuild

6. Create and Administrator account

openvasad -c 'add_user' -n openvasadmin -r Admin

7. Start the manager

openvasmd -p 9390 -a 127.0.0.1

8. Start the Administrator

openvasad -a 127.0.0.1 -p 9393

9. Start Greenbone security assistant

gsad --http-only --listen=127.0.0.1 -p 9392

Then login at http://127.0.0.1:9392 using the username and password from step 6. If you have any issues, troubleshoot with:

/pentest/misc/openvas/openvas-check-setup

Foiling the "Skype email vulnerability"

I'm sure you've already heard plenty about Skype's recent account hijacking vulnerability whereby attackers could hijack a Skype account by adding the target user's email address to an account and then performing a password reset sent to their *own* account. All that was required to hijack the account was the email address of the target user.

A simple trick I use that would have foiled the above issue (or at least made it more difficult to execute) is to insert a few random characters into my email address in a way that doesn't prevent it from functioning.  There are two quick ways to do this that I know of; either by using Gmail or by using a catch-all/wildcard address on your own domain.

Gmail

Gmail ignores anything in your email address following a "+" sign and before the "@" sign. The idea is that you can put key words in that spot to use for later filtering and labeling inside Gmail. For instance "foo+BAR@gmail.com" is the same as "foo@gmail.com" or "foo+FIGHTERS@gmail.com". Instead of a label, you can include a few random letters in your address when creating new accounts which Gmail will ignore, but which will make it potentially more difficult to determine what address you used on any given site. (i.e. "foo+4Gh8unS@gmail.com")

Using your own domain

This one is probably obvious given the above, but if you create a wildcard address you can then use any random username at your domain. That can be a drag if spammers start spoofing your domain, so as a work around you can include a keyphrase in the email name and then use filters to pass those messages through to your inbox while rejecting the others.

Not going crazy because of this

This really only works if you trust your browser to store your username for logins or if you use a password manager like LastPass. Otherwise, you'll have to remember your random username for every site, which goes out the window in about 5 minutes.

natas16 solution / hints

Today, out of nowhere, I suddenly started seeing a huge number of page views to my post on scraping HTML comments with Python. After digging around, I figured out it was coming from some mentions I made regarding using part of that code for solving some of the challenges in the natas wargame from OverTheWire.org.

I normally don't write about wargame solutions, since the fun is in working out the solution for yourself, but I thought I'd share some more Python code I came up with for natas16 because I've seen a bunch of people doing some really nutty things trying to get through it. Here's my solution - but I warn you I've stripped out the keys (so you'll have to work your way to 16 on your own) and I've intentionally made this less than a step-by-step walk through.

natas16 starts looking pretty sparse:

If you've worked your way through, you'll see this is pretty similar to the shell code injection challenge you encountered on the way. A quick look at the provided source shows that our imaginary adversary got wise to our injection and has tried to prevent similar exploits in the future:

So here we can see that our submitted key is checked for ;, |, &, `,' and " globally via a regular expression and gets tossed out if any are found. That rules out a direct shell injection attack like we used before, right? Well..

A big part of cracking this one relies on the contents of dictionary.txt. A bit of searching through the page shows us that it appears to contain an entry for every letter and every number from 0 to 9.  We know from the rules of the game that our target password file is located in /etc/natas_webpass/natas17, but we can't just inject a "cat" statement into the grep command because of rights issues..

Here comes the fun part. What if we could use results of the parent grep command to signal when we've found what we're looking for in a nested shell command with access to /etc/natas_webpass/natas17? Something like.. nah, you'll have to figure that part out on your own.

When you do, you'll probably discover that it would take a decent amount of time to try each and every letter for each and every position *coughHINTcough*. It would be pretty nice if we could whip up a Python script to do the hard work for us. It's worth mentioning that the way I detected a success was by the lack of results from a search. Here's my script:

import requests
import string

auth = ("natas16", "Key_To_natas16")
url = "http://natas16.natas.labs.overthewire.org/index.php"
s = requests.session(auth=auth)
data = {}
characterPool = string.ascii_letters + string.digits

submission = '$(magicCommand /etc/natas_webpass/natas17)'
password = ""


for i in range(1, 32):
        for c in characterPool:
                data["needle"] = submission % (password + c)
                r = s.post(url, data, auth=auth).content
                if len(r) == 473:
                        password += c
                        print "Col: ",i," Pass: ", password
                        break

print "Complete: ",password

Obviously I've removed the key to natas16 which you can retreive from natas16.. and I've substituted the "magicCommand" for my hypothetical string.. but if you look at the structure of this script it should give you some strong indications about how to go about solving natas16 (without dropping the solution right in your lap turnkey) If you can't figure it out from the above, or if you can't even make it to 16, shoot me an email or message me on Twitter and I'd be happy to try to give you a few more hints.

Install OSSEC on OS X Mountain Lion 10.8 - How To

If you've tried to install OSSEC on OS X Mountain Lion, you probably attempted to install it using the command line compiler bundled with XCode and run into the error message:

sha_locl.h:261: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type!

After a bit of research, it seems there is an issue with the llvm-based compiler Apple is using.

However, by using Apple's compiler to build standard gcc, you can then use the result to successfully install OSSEC.

Install XCode 4.5

If you're starting from scratch, you'll need XCode 4.5 and it's command line compiler:

1. Download and install XCode 4.5 from the App store (It's now a free download)
2. Launch XCode, and go to Preferences, then Downloads. Next to "Command Line Tools", choose Install.
3. After the command line tools are installed, close XCode and open a terminal.
4.  To verify your install of the command line tools, type "gcc" and return. The result should be similar to the following:



5. bash-3.2$ gcc
   i686-apple-darwin11-llvm-gcc-4.2: no input files
   

This indicates you've got Apple's llvm based compiler installed.

Build gcc from source

Now you can build gcc. I used this tutorial by Sol at the Solarian Programmer blog for building gcc 4.6.2 on Lion to successfully build 4.6.3 on Mountain Lion.  Here's a condensed version:

1. Download:
1. gcc 4.6.3 (gcc-4.6.3.tar.gz) - I believe you can use a stable version of 4.7 as well
2. gmp 5.0.5 (gmp-5.0.5.tar.bz2)
3. mpfr 3.1.1 (mpfr-3.1.1.tar.bz2)
4. mpc 1.0.1 (mpc-1.0.1.tar.gz)


2. Uncompress and untar each into your ~/Downloads directory by double clicking them in Finder to launch Archive Utility.


3. Compile gmp in the terminal using the following commands:
   

   sh-3.2# cd ~/Downloads/gmp-5.0.5/
   sh-3.2# mkdir build
   sh-3.2# cd build
   sh-3.2# ../configure --prefix=$HOME/my_gcc
   sh-3.2# make
   sh-3.2# make install
   



4. Compile mpfr
   

   sh-3.2# cd ~/Downloads/mpfr-3.1.1/
   sh-3.2# mkdir build
   sh-3.2# cd build
   sh-3.2# ../configure --prefix=$HOME/my_gcc --with-gmp=$HOME/my_gcc
   sh-3.2# make
   sh-3.2# make install
   



5. Compile mpc
   

   sh-3.2# cd ~/Downloads/mpc-1.0.1/
   sh-3.2# mkdir build
   sh-3.2# cd build
   sh-3.2# ../configure --prefix=$HOME/my_gcc --with-gmp=$HOME/my_gcc --with-mpfr=$HOME/my_gcc
   sh-3.2# make
   sh-3.2# make install
   



6. Finally, compile gcc (adjust the make -j 4 command for the number of cores you want to use)
   

   sh-3.2# cd ~/Downloads/gcc-4.6.3/
   sh-3.2# mkdir build
   sh-3.2# cd build
   sh-3.2# ../configure --prefix=$HOME/my_gcc --enable-checking=release --with-gmp=$HOME/my_gcc --with-mpfr=$HOME/my_gcc --with-mpc=$HOME/my_gcc 
   sh-3.2# make -j 4
   sh-3.2# make install

Replace Apple's gcc with the one we just built

You should now have an executable in ~/my_gcc/bin called gcc. We need to substitute this gcc for the one that comes with XCode. I did that by temporarily copying Apple's gcc to gcc2 and creating a symlink to the new gcc:

sh-3.2# sudo su
sh-3.2# cd /usr/bin
sh-3.2# cp gcc gcc2
sh-3.2# rm gcc 
sh-3.2# ln -s /Users/jason/my_gcc/bin/gcc /usr/bin/gcc

NOTE: You probably don't want to leave that symlink in place any longer than you have to, but it's convenient to link to a home directory for the time being. Also, modify if your name isn't Jason!

We can check that all is well by issuing:

sh-3.2# gcc -v
gcc version 4.6.3 (GCC)

Download OSSEC

At which point we're ready to download OSSEC (I used 2.6 stable). After downloading, use Finder and Archive Utility (double click the downloaded file) to extract the tarball. Back in the terminal, we need to do some prebuild configuration.

Manually execute the account creation script

OSSEC seems to fail to correctly identify that it's running on OS X, and during the account creation phase will attempt to use the "darwin-addusers.pl" script instead of "osx105-addusers.sh" script. We can get around this problem by running the right account creation script ourselves ahead of time.

sh-3.2# sudo su
sh-3.2# cd /Users/jason/Downloads/ossec-hids-2.6/src/init
sh-3.2# cp osx105-addusers.sh /Users/jason/
sh-3.2# chmod 755 /Users/jason/osx105-addusers.sh
sh-3.2# /Users/jason/osx105-addusers.sh

That should create the necessary accounts and groups for the rest of the install to go smoothly.

Install OSSEC

When the script is done, kick off OSSEC installation:

sh-3.2# cd /Users/jason/Downloads/ossec-hids-2.6/
sh-3.2# ./install.sh

and follow along with your favorite install guide. (Chapter 2 of the OSSEC Book should contain anything you might need.) I found mostly default settings to be satisfactory for my purposes.

The Unity Amazon search in Ubuntu 12.10

Ubuntu ruffled some feathers recently when they announced the Home search in Unity as included with Ubuntu 12.10 will include the ability to search Amazon for products related to your search terms. Ostensibly, the idea is to use the Amazon referral bucks to support Ubuntu, but many users are worried the feature unnecessarily sells out user privacy for a quick cash grab.

 Diving into the API behind the feature, some were quick to point out that the queries are not encrypted, however  Mark Shuttleworth and Jono Bacon have both stated that the feature will be encrypted before the launch of 12.10.  In the linked post from Mark, he seems to intimate that only Canonical will ever see these queries:

We are not telling Amazon what you are searching for. Your anonymity is preserved because we handle the query on your behalf.

Which is somewhat true; the query goes to http://productsearch.ubuntu.com which uses its redirect method to send the user to the appropriate destination. Once https is enabled, only Canonical will see this initial query. Unfortunately, the redirect method results in lots of calls directly to the upstream provider. Here's an example query for "The Beatles":

http://productsearch.ubuntu.com/v1/search?q=The%20Beatles;decade=1960;geo_store=US

which produces results in which we can find:

images": {
        "350x350": [
          "http://cdn.7static.com/static/img/sleeveart/00/005/854/0000585438_350.jpg"
        ], 

a direct call to 7digital, an online music store.  It's likely that 7digital will only be able to capture your IP, the content retrieved,  and the time it was retrieved, but clearly things aren't only occurring between the user and Canonical. Without proxying these search results the privacy implications of the built in search are not quite as cut and dry as Canonical seem to indicate it they are.

This is, of course, pre-release software, and the only people getting their hands on it are people specifically going out of their way to get a look at it before it's finished. This situation could completely change in short order, but Mark also added these endearing words to that post:

Don’t trust us? Erm, we have root. You do trust us with your data already. You trust us not to screw up on your machine with every update. You trust Debian, and you trust a large swathe of the open source community. And most importantly, you trust us to address it when, being human, we err.

Well that gives me the warm fuzzys. There's nothing like being told not to worry about privacy problems because they're already up in your business anyway. I'll be interested to see how they handle this situation and if they end up proxying the results as well, but his "we have root" comment is indeed a compelling argument - to try something other than 12.10.

PS:  In case you are curious, the Amazon associate tag passed in the proxied queries from ubuntu.com appears to be "u1treatyrslf"

Python script to scrape HTML comments

Recently this ownedcore thread about Blizzard hiding identifiable data in World of Warcraft screen shots sparked a minor tweetstorm among the infosec folks I follow. While I'm not a WoW player, the thread did get me thinking about hidden-in-plain-sight covert channels and where they might be found.

While nowhere near as sophisticated as Blizzards steganography, I remembered seeing a few "easter eggs" where people had hidden ASCII messages in HTML comments for exciting, retentive types like myself to find. While I usually find them by just "viewing source" in Firefox when I'm bored (and that's really bored) I thought a fun short project would be putting together a script to grab comments from the command line for use in more sophisticated tools or monitors.

At first I thought of putting together something with curl or wget and grep, but a lot of times these tiny projects are perfect for trying out something new, so instead of a shell script I decided to throw something together in Python instead. I've never done any scraping with Python, but it seemed like it might be a handy skill to have in my back pocket.

The result is the short script below. I'm not going to claim this is great code since Python isn't my forte (yet), but it gets the job done. I used BeautifulSoup 4 and mechanize as mentioned in this stackoverflow post,  and a bit of code for manipulating comments right from the BeautifulSoup 3 documentation.

While this doesn't save much work if you're just casually checking a site's comments, it's a great building block if you're looking to automatically check for changes or hidden messages. (If you need some fun examples, checkout The Oatmeal or Reddit)

  #!/usr/bin/env python   
  #coding:utf-8   
   
  import sys   
  from mechanize import Browser   
  from bs4 import BeautifulSoup, Comment   
   
  brwsr = Browser()   
  res = brwsr.open(sys.argv[1])   
  data = res.get_data()   
   
  soup = BeautifulSoup(data)   
    
 comments = soup.findAll(text=lambda text:isinstance(text, Comment))   
  for comment in comments:   
   print comment   

If you haven't played with BeautifulSoup or mechanize, check them out as they both look to be useful for quick and dirty scraping of web data.