For many years now, Penetration Testers and Hackers have used Shell Code to gain access to Web Servers and make changes. What I mean by Shell Code is really what’s called a “Web Shell“. This is a way that you can get something onto the Server and then run “Command Line” syntax from either query string values or directly within a web page.
Last week at the RSA Security Conference, Marcus Murray demonstrated this very attack utilizing an image, as the mechanism to compromise the server. The whole premise of this is the end user (Hacker or Tester) having access to a file upload mechanism that will accept this type of file. You can see the short Video here: https://www.youtube.com/watch?t=165&v=NPqVVhxhqmY
After watching this, this got me thinking about SharePoint. Is SharePoint protected from this type of attack?
In most cases SharePoint is never configured for Anonymous file upload, but is however enabled by default for those that are authenticated into the system. This is by design and really the very nature of SharePoint.
So while travelling back from London over the weekend I spun up a “Kali Linux” and “SharePoint 2013” Virtual Machine and spent some time trying to see if SharePoint was vulnerable to this type of attack using a “Web Shell“.
I didn’t want to perform the same test, but something similar, just to prove a point. To start with I created a standard ASPX page called “Evil.aspx” and uploaded it to the “Pages” library of an out of the box Publishing Portal.
The Page contained the following C# code (this can be found on the internet and has been around since about 2006).
Upon running the page: https://{URL}/Pages/Evil.aspx I got presented with the following message:
This is what I expected to see, as running code directly within pages is blocked inside of SharePoint, by the use of the “PageParserPath” setting within the sites “web.config“.
So to fix this I modified the “web.config” for the site allowing this to run, to see what it would do.
Now running the “Evil.aspx” page gives me the following:
I can now run commands within the box which are ran against “cmd.exe” that is hosted within the SharePoint Server itself.
IPCONFIG
HOSTNAME
WHOAMI
So, now that we have found out the configuration needed for this to work, how can we make this a little more inconspicuous, something better than an “ASPX” page?
This is where we use the same approach that Marcus Murray demonstrated in the Video, we look at embedding code within the properties of an image.
So first let’s get an image, I am going to use “SmileyCat.jpg“.
We then need to download a tool called “ExifTool” which will allow us to modify the properties of images. It can be downloaded from here.
http://www.sno.phy.queensu.ca/~phil/exiftool/
Once you have it downloaded you need to run it from a command line passing in the parameters you need.
The approach we want to use is a standard image, so during upload any protections that check for code won’t run. To this we will add a code block to the “Comments” field of the image which will then get executed when you view the image.
The code we used earlier can be used but not in the format we had it. We need to take the “C#” code and get it escaped so we can pass it as one big string value. It should look like this when escaped:
Next we run the following using the “ExifTool” to retrieve the current list of file and image properties.
This should then return the following properties of the file.
To add the comments property we can use the following command line.
Now when we run the following command we should see the comments property filled with the values above.
To complete the process we now need to rename the “SmileyCat.jpg” to be “SmileCat.jpg.aspx” instead. This is so the web server and SharePoint will execute the code as it thinks it is an “ASPX” page. Next we upload the file into a SharePoint image or document library which is probably where your user account has access versus a pages library.
As you can see it looks like it’s an image file with the “.jpg” file extension. If we now run this page / image it will load displaying the code that we added, not just showing it but executing it too.
As you can see when we try to run the image / page it renders the code we injected into the comments property and is now available to use in SharePoint. We can now run the same commands we ran previously and it will work.
Now that we have code that can be executed we can do all kinds of things, upload files, create a reverse shell connection to a Linux machine, similar to the Video that Marcus did at RSA Conference. As outlined in his presentation he uses some PowerShell to begin the attack, allowing the remote connection from the browser directly into the attacking Linux machine. PowerShell can be easily ran from the “Evil.aspx” web shell. Let’s say we had created a “Payload” in Metasploit called “Evil.txt“.
We can then host this “Evil.txt” somewhere, for this example on a website somewhere with a URL of:
http://sp2013dev:8080/Evil/Evil.txt
Now we can use this in the “ASPX” page by getting the page to download the “Evil.txt“, convert that to an “Evil.exe“, then get the site to run this executable which in turn based on the payload, will call home to the server “192.168.1.6” on port “4444“. My Linux machine needs to be setup first to do this, by using the following commands in Metasploit.
Once this is run the console will sit in listening mode.
Running the following code in the “Evil.aspx” page will create the connection back.
Once this command completes in the “ASPX” page, our Linux console receives a response and connects the two together.
With the meterpreter session we can now do all kinds of things which we will not cover in this post, there are plenty of other sites that can cover these commands.
The key to this all working though, within SharePoint is the change to the “web.config” that allows code to be executed, versus it getting blocked by design.
So as I have often said before, rule number one stop removing the security features that are built into the core Product so you can make it do something it was not meant to do.