A Fun Attack Path, Starting with XXE

(this writeup is a bit sanitized so I don’t give too many details away)

A coworker (@breenmachine) and I recently performed a penetration test to simulate the risk of an attacker who is able to connect to a network jack inside of a hospital. The objective was essentially to see if we could gain access to specific VLANs. One of the ACLs prevented us from being able to SSH into the hosts on the target networks.

The assessment started with us performing some standard fast scans against the scope to get an idea of what we were dealing with. There were two promising targets in scope, a Citrix gateway, and a custom application that runs as a thick client to access the application server; we decided to focus on the custom application.

Loading up the thick client we were prompted for a username and password, unfortunately we weren’t able to guess using some standards (admin/admin, admin/password, administrator/administrator, root/root, etc….). At this point we decided to look more at the application itself so we grabbed the jar files referenced in the jnlp file (there were quite a few so parallel –gnu “wget {}” was used)

We extracted the files from the jars using 7z but for some reason we were having issues decompiling the class files using jd-gui (not sure why) so we decided to use jad instead which worked great. Using find and xargs we were quickly able to decompile the class files. One of the first things we came across when going through the source was the location of a couple WSDLs so we immediately opened up SoapUI and had it proxy through Burp (which was already open… because it usually is).
Sending the requests coming from SoapUI to repeater we were able to easily find XXE:

Unfortunately, unlike some other applications we’ve seen, this application was not running with root level privileges. Though luckily for us we were able to read both files and directories so we weren’t shooting completely blind which was great.

At this point it was time to start looking through the filesystem to see if we could find anything interesting. One of the files that we came across in our exploration was a shell script to add users, including a standardized password (which I will not post here because it was based on the client’s name).

At some point shortly after we found that we were able to login to the application as the Administrator with the previously mentioned bad password. Looking through the application we found that it was possible to run reports; even better, we found it was possible to create custom reports that could be run, customized by SQL queries. Simultaneously we had been going through the application’s documentation (protip: search the docs for ‘command’ to find the good stuff) and found references to perl in postgres. Putting two and two together, we were able to create a custom report with the following SQL query (we know we don’t need all the extra garbage, it was taken right from the docs):

And sure enough, with a netcat listener on the other side, we got a shell.

Exploiting Limesurvey

A few weeks ago a good friend of mine was performing a penetration test when he came across an open source application called Limesurvey running on one of the target webservers. As a penetration tester, any time you find a piece of open source software running you get excited because it’s easy enough to grab the code and start auditing it either statically or dynamically. A quick Google search showed that the Limesurvey software was known for having several vulnerabilities in the past, such as SQL injection, Remote File Inclusion, Directory Traversal, etc… But all of these vulnerabilities were post-authentication and we were without credentials. So I grabbed the code, started up Burp, and dove right in looking something that would be useful pre-authentication.

I find quite often that a major piece of attack surface is missed when auditing applications… the install process. So before I even navigated to the application in my web browser to start the installation process, I made sure that everything was being proxied through Burp. The installation was fairly standard:

1. Choose your language
2. Accept the license agreement
3. Check to make sure you have the proper versions of required libraries
4. Create a database for the application
5. Create your administrator account

Once you go through this process you are redirected to the administrator login page. As an attacker, I always think to myself “Perhaps I can go back to the installation page and somehow gain access to the application”; however, when I tried to go back to the installation page, I was greeted with the following:

So it looks like the installer disables itself somehow once the installation already happens. Alright, that’s fine, I decided to walk through each of the requests/responses in Burp Proxy’s HTTP History:

The most interesting part of the installation process to me is the user creation piece. What if I can somehow manage to create my own administrator account? If I can do that, most of the post-authentication vulnerabilities that are known to exist in the application are now considered pre-auth as I can create my own administrator account.

I find the request sent to the installer where we created our administrator account, right click on it, and send it to Burp Repeater:

With this request loaded into repeater I modify the request slightly so the parameter InstallerConfigForm%5BadminLoginName%5D is ‘badmin’ rather than ‘admin’, and I fire off the request. The following error message is returned:

My first reaction is “Well, it looks like that didn’t work”, but I decided to login to the application to see if I broke anything. I login with the standard ‘admin’ account with a password of ‘password’ (because that’s the prefilled password when walking through the installer), navigate to the “Manage survey administrators” action of the application, and cannot believe my eyes when I see the following:

It looks like the attack worked! The LimeSurvey application did not properly remove installation scripts post installation. These installation scripts allowed for me, the attacker, to create an arbitrary administrator account without knowledge of existing administrative credentials due to processing requests before validating them. With this exploit in hand, my buddy was able to further investigate the application, and eventually gain command execution on the host.

One note I would like to make is that the specific version of Limesurvey tested first was an older version of Limesurvey. The reason I tested against the old version is it was the same version that the target was using, so I wanted to make sure that any vulnerabilities I found could be used to exploit that version. With that being said, I did also test the latest version of Limesurvey at the time, the only difference was that there was a CSRF cookie (YII_CSRF_TOKEN) that needed to be handled; however, you could just set the cookie and the parameter being sent to the same value to perform this exploit. I did put together a small Python PoC for this as well:

The Sage Notebook

I was working on a penetration test recently where the allowable attack vectors were networks and applications. Like most other penetration tests of this type, I started creating an inventory of the attack surface of my target. After putting together the inventory of the applications running on the target’s servers I came across an application that I had never really seen before called The Sage Notebook. A quick Google search showed that this was an application created to allow for people to write code using Sage and Python for studying mathematics.

Two things interested me right away about this application. The first was that I was able to register my own user account and access the application. The second was that I might have potential code execution on the server itself being able to run any Python code.

So I created a user account which allows me to access the application right away. I walk through the application a bit and find out that I need to create a worksheet to be able to write my own code. I type some Python code into the box provided and press the “evaluate” button, sure enough:

Well… That was simple enough… But maybe print is allowed, let’s try some other stuff.

At this point we can already go ahead say this is going to be our entry point into this server as we have operating system command execution. After poking around a bit on the server, this made the pentest go from good to great:

Go ahead and take a look at that for a second… See the problem? Why on earth would anyone set /etc/shadow as world readable?! Sure enough:

At this point I got tired of typing commands into os.system() and decide it would be easier just to spawn a reverse shell back to myself, so I use my preferred Linux reverse shell:

Running the shadow file through John the Ripper I found that most of the accounts on the box were using weak passwords, and in some cases password was the same as the username.

Recommendations

There are a couple “lessons learned” that should be taken out of this exercise:Do not allow for untrusted users to create accounts for themselves on your application. If necessary, moderate user creation so some random person on the Internet cannot just login.

1. Do not allow for untrusted users to create accounts for themselves on your application. If necessary, moderate user creation so some random person on the Internet cannot just login.
2. This application should have sandbox restrictions and should not allow for anyone to run their own code… for obvious reasons.
3. Permissions are extremely important, especially in multi-user environments, and should be checked frequently.