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: