Friday, February 28, 2014

MobiSec

I've started to investigate mobile application security and one of the tools that seems to be useful is MobiSec. MobiSec, like Kali or SamuraiWTF, is a Linux distro that has many tools that are geared towards the mobile application security arena.

GoatDroid

Like many of the other Goat applications OWASP has, GoatDroid is intended to be an application that is riddled with vulnerabilities for people to find. You can find out more about the GoatDroid app here.

MobiSec does come with another sample app by SecurityCompass. You can find out more about the SecurityCompass lab here.

Setting MobiSec Up

Ok, first thing's first. We install MobiSec as a virtual machine and click through. Once that's over with, we login with mobisec/mobisec. Next thing we'll do is disable the firewall. This is normally a horrible decision to make, but in the interest of being able to focus on the task of assessing mobile applications we'll disable iptables so it isn't a distraction. You are running MobiSec behind a NAT and 7 proxies aren't you?

To disable the firewall, we'll go to System -> Administration -> Firewall configuration

You'll be asked to provide the root password, which is mobisec, and then you'll uncheck the Enabled box.

Something else I did was update and upgrade the software packages by running a sudo apt-get update && sudo apt-get upgrade.

The next thing I did was update the Android SDK. Going to Applications -> MobiSec -> Development Tools -> Development Environments -> Android SDK Manager will open the Android SDK Manager so you can see what SDK and tools are installed.

MobiSec 1.1 came with Android SDK Tools version 17 and Android SDK Platform Tools 11 while versions 20 and 12 were available. Go ahead and click on Install 2 packages to download the updates. You'll be greeted with a dialog to accept the user agreements for each update or you can select to accept all.

Once you finish this, a dialog will pop up that tells you to close the manager and re-run it. Do this because new updates are available. I'm not sure why it can't just update everything to the most current version in the first go around. However, you might run into an issue if you blanket accept all of the updates. I had to uncheck the option to download anything in API 19 because I got an issue like this if I tried to:

I just updating everything else and then re-ran the manager a third and fourth time and accepted all of the available updates and it ran just fine. Is any of this mandatory? Probably not, but I just prefer to update whenever possible.

Setting Up GoatDroid

Next we'll wget the pre-packaged GoatDroid project by running this command from a terminal, wget https://github.com/downloads/jackMannino/OWASP-GoatDroid-Project/OWASP-GoatDroid-0.9.zip

Then we'll unzip it with by running, unzip OWASP-GoatDroid-0.9.zip

Inside the OWASP-GoatDroid-0.9 directory there should be a goatdroid-0.9.jar. Run this jar by typing, java -jar goatdroid-0.9.jar

You should see the GoatDroid application appear.

First thing to do is to configure GoatDroid. Open the configuration screen by going to Configure -> Edit Configuration.

You will want to set the Virtual Devices Path to point to a specific device that is located in ~/.android/avd. I chose the Android_4.0.3.avd in this example. You will also want to point the SDK Path to /opt/mobisec/devtools/android-sdk. If you left the firewall enabled, you'd have to look at the Web Services tab and make the appropriate adjustments to allow connections. Otherwise just hit Update Settings.

We'll try running the FourGoats application first. Select it from the list on the left

It may take a while for the emulator to boot up depending on how fast your computer is. Eventually though you should see a screen like this:

Now we'll install the GoatDroid application to your device. From the GoatDroid application, click on the Push App To Device button. You'll see a dialog saying that it is pushing the application to the device. After a little bit you should get another dialog saying that it has successfully installed the application. Go ahead and click on the Start Web Service button as well.

Look at the apps installed by clicking the top right hand corner with the 6 squares. You should now see the Four Goats app listed.

Go ahead and click on the GoatDroid application. It should take you to a login screen. First we'll need to configure the connection settings. Click the 3 little squares in the upper right hand side and click Destination Info. Next set the Host to be MobiSec's IP address and set the HTTPS port to be 9888. Hit Save and you should be taken back to the login screen.

Use goatdroid/goatdroid to login.

And now you should be in. Test away!

This procedure is essentially the same for installing/setting up the Herd Financial app too.

So What?

This is enough to get you started, but we haven't really done anything yet in the way of assessing GoatDroid. I'll be posting how-to's as I chug along and figure this stuff out. Better hope I'm smrat enough!

Friday, February 14, 2014

I'm using this post to document how to install WordPress 3.8.1 on Debian 7 for the purposes of testing plugins. I'm looking on how to do more vulnerability research and WP plugins seems as good of a place as any to start poking around. It's also a good exercise in creating a LAMP stack, albeit probably not the most ideal one.

I'll skim over the part about installing Debian 7 as a virtual machine since that's mostly click through and skip to the part once you first log in.

Updating Debian and Updating the Sudoers File

Once you login the first thing you should probably do is update and upgrade everything. To do that you would normally open up a terminal and type: sudo apt-get update && sudo apt-get dist-upgrade -y
However, the user you logged in as is probably not in the sudoers file so you'll get hit with a message like this:

So before we can actually run our update and upgrade let's add user to the sudoers file. First we'll swtich user by typing the command, su. Then we'll execute the visudo command and add the user account to the sudoers file.

That should open up the sudoers file using the nano editor. Add this line, user ALL=(ALL:ALL) ALL, to the file. I inserted this line after the entry for root and then save and exit. You'll get asked what to save it as. Just save it as /etc/sudoers

Now, let's exit out of our root shell and go back to the user account. Next, we'll update the file, /etc/apt/sources.list so that it'll update itself from the most update repository of software. I had to do this extra step because I didn't choose to update Debian from the network during my install. Edit the /etc/apt/sources.list file and if you have an uncommented line starting with, deb cdrom..., comment it out and add this line, deb http://ftp.us.debian.org/debian stable main. Your sources.list file should look like this.

Then we'll attempt to re-run our update command again.

This may or may not take some time to complete while it updates all of the software on your machine depending on if updated software was installed when you installed Debian.

Installing Our LAMP Stack

Next, let's install the necessary software to support WordPress. If you Google how to install WordPress on Debian you'll probably get 10 different results on how many packages you'll have to install. This is what I used and what worked for me. You may have to install additional packages depending on your situation. I ran this command: sudo apt-get install apache2 mysql-server mysql-client php5 php5-mysql. You should get a list of packages that will get installed:

Once the install kicks off, you'll get asked for a password for the MySQL root:

Configure MySQL

Next we'll configure MySQL. Enter into a MySQL prompt by typing, mysql -u root -p. You'll get prompted for a password.

Then we'll create a database for WordPress to use by typing, create database wordpress;

Next we'll create a user named wpuser with a password of wordpress123 for WordPress to use by typing, grant all on wordpress.* to wpuser@localhost identified by 'wordpress123';

Another thing you'll want to do is enable logging for MySQL. This way you can see what kind of queries are being generated. This will be helpful in understanding how to abuse SQL queries if you are trying to perform SQL injections. Open the MySQL configuration file with your editor of choice like this, sudo vim /etc/mysql/my.cnf. Then, uncomment these two lines:
#general_log_file = /var/log/mysql/mysql.log
# general_log = 1

It should look like this:

Then restart MySQL by typing, sudo service mysql restart

For future reference, when you go to pentest a plugin, you can tail the log by typing, sudo tail -f /var/log/mysql/mysql.log. You'll then see all the queries that the plugin is making. It should look similar to this:

Install FTP

Installing an FTP server is also handy because WordPress can automatically install and delete plugins for you. To do this, we'll run the command, sudo apt-get install proftpd, to install the FTP server. During the installation, you will be asked if you want to run proftpd from inetd or standalone. Choose standalone.

To see if proftpd is running fine we'll run, sudo service proftpd status, and it should report that it is.

Installing WordPress

Now let's download and install WordPress. The most up to date version is currently 3.8.1. You can always get the most up to date version at http:///wordpress.org/latest.zip. To download it we'll run, wget http:///wordpress.org/latest.zip

Once we unzip the file by typing, unzip latest.zip, we should have a directory named, wordpress. Now we will create the sub-directory that we want our test blog to reside in. I'm going to name it blog so I'll first create the necessary directory by typing, sudo mkdir /var/www/blog, and then cp -R wordpress/* /var/www/blog

Let's update the permissions of the /var/www so that the apache user, www-data, will be able to update files as necessary by typing, sudo chown -R www-data:www-data /var/www

Next open up wp-config.php with your editor of choice and we'll update some values. Since we are interested in just doing vulnerability assessments and not hardening this install of WordPress we'll make some compromises in the interest of convenience in order to speed up the installation and testing of plugins. I would not advise doing this on an install that you actually care about. Taking snapshots of your virtual machine early and often is recommended.

First, we will make it so that the admin panel is remote accessible by setting these properties. In my case, the IP of the virtual machine is 192.168.58.155 and the url to the WordPress installation is /blog

define('WP_HOME', 'http://192.168.58.155/blog');

define('WP_SITEURL', 'http://192.168.58.155/blog');

Then, we'll disable the automatic updating feature in WordPress. WordPress will update plugins for you if it detects there is a new one available. This is normally nice, but if you're trying to install vulnerable plugins you found on exploitdb then you probably don't want this. The first property should be good enough to disable all updating that takes place, but I threw in the second property if you just want to disable the updating of plugins.

define('AUTOMATIC_UPDATER_DISABLED', true);

define('auto_update_plugin', false);

Finally, we will set the properties that WordPress needs to connect to the MySQL database you created earlier and the user you created.

define('DB_NAME', 'wordpress');

define('DB_USER', 'wpuser');

define('DB_PASSWORD', 'wordpress123');

define('DB_HOST', 'localhost');

All in all, the properties you set should look like this:

Now we'll open up a web browser and point it to the WordPress install script to set up our blog. Navigate to, http://192.168.58.155/blog/wp-admin/install.php. You should be presented with a welcome screen. If not, go back and recheck the properties you set in wp-config.php. You most likely messed up the database properties.

Go ahead and fill in whatever values you'd like for the Site Title, Username, Password, and E-mail (it doesn't have to be valid). Once you're done hit the Install WordPress button and then login.

Installing Plugins Manually

We will start out with manually installing a vulnerable plugin found here, as an example. (Disclaimer: I chose this vulnerable plugin at random. I have no connection to the author of the exploit.) Download the vulnerable plugin and then click on Plugins, then Add New. From the Install Plugins screen, there should be a link that you can click on to upload a plugin in .zip format.

In the next webpage, click on the Choose File button, select the thinkit-wp-contact-form.zip file you just downloaded, and click the Install Now button.

You'll be forwarded to another webpage indicating that the plugin has been uploaded, unpacked, and installed. Finally you'll want to activate the plugin by clicking the Activate Plugin link.

Now, you'll be forwarded to the main Plugins page and you'll see that the vulnerable plugin is listed along with the Akismet and Hello Dolly plugins that came pre-installed. You should also see a ThinkIT Contact entry on the left hand side toolbar.

Replicating the Vulnerability

Excellent, now we can try to trigger the XSS vulnerability. From the description we know that we can trigger a XSS attack from this URL, wp-admin/admin.php?toitcf_current_id=[XSS]&page=toitcf. First we'll need to create a form so first, click on the ThinkIT Contact entry on the toolbar and then click on Create New Form.

A default form will then appear. We don't care what entries these hold so we'll leave them as is and then go to the bottom and click the Save button.

Once you hit Save, you'll be sent to the default page for the ThinkIT Contact plugin. You should now see an entry for the form you created. If you hover over the Edit link, you should notice that the link has the same format of the URL described in the exploitdb entry, http://192.168.58.155/blog/wp-admin/admin.php?toitcf_current_id=1&page=toitcf. Click the Edit link.

The vulnerability description makes it sound like whatever value we pass in for toitcf_current_id parameter will get reflected. Let's try setting toitcf_current_id to have the value, 'hacked'. We should expect to see the word hacked somewhere in the webpage or perhaps in the source. Once you set toitcf_current_id to hacked in the URL load the webpage. By navigating to http://192.168.58.155/blog/wp-admin/admin.php?toitcf_current_id=hacked&page=toitcf we were able to get the word hacked on the webpage.

The only thing left to do is to set toitcf_current_id to be some JavaScript and see if it will be executed. Navigate to http://192.168.58.155/blog/wp-admin/admin.php?toitcf_current_id=<script>alert(1)</script>&page=toitcf and if all goes as planned you'll see a dialog popup with the text, 1.

And there you have it! You have been able to replicate the vulnerability described in the exploitdb entry.

Now What...

Now you can feel free to manually install other vulnerable WordPress plugins to replicate the exploit or go through the Plugins -> Add New menu to install new plugins and do your own assessments of them to find your own vulnerabilities.