I stumbled upon a vulnerable version of Oop CMS Blog which according to Exploit-DB is vulnerable to SQL Injection.  In order to better understand what I was dealing with, I downloaded the software and I installed it on the same operating system as the target server.  Looking at the comments on Exploit-DB, the injection points seemed relatively easy and I thought this was going to be a quick kill.  Due to a variety of different circumstances, I could never get from point A to point B in a single shot.  In the end, I wound up combining a few different pieces in order to get that initial shell.

From a web browser, we take a look at the site:

I see the search box and insert a single quote to see if I can break SQL:

Not surprising given that Exploit-DB only made mention of the injection rather than actual exploit code which sometimes means that it's too simple.  

If we give it a true statement, can we retrieve everything?

Yes!  We can interact with it directly.  Let's see if we can uncover the number of columns:

We continue to add until we determine the number of columns:

Now let's see if we can inject something arbitrary:

Success!  Now let's render the SQL version:

How about if we retrieve the /etc/passwd file:

I tried writing a shell directly from the address bar but in each case, it wouldn't work.  I even base64 encoded the PHP when I discovered that SQL can base64 decode using:

from_base64(('PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8+Cg=='),5,6,7,8,9 into outfile "/var/www/html/cmd.php";

Which works great from within MySQL but again, would break when entered into the address bar.  

Giving up on the manual method, I move to SQLMap:

We already know it's injectable but SQLMap needs to come to that conclusion on its own:

Now that SQLMap knows it's injectable, let's dump the database:

Not long after:

And eventually we get to the juicy bits:

It looks like an MD5 hash but let's confirm:

Taking the hashes over to the cracking machine:

We retrieve the admin password. 

I should also point out that we didn't need to go down this path since the SQL db is in the web path and accessible for download.  I've seen web developers do this with production sites because it's simple to move everything at once.  If you forget, malicious actors can also retrieve the dumps, crack the hashes, and access your site.  

Moving to the admin page:

Logging in with the credentials:

Although I'm not familiar with this CMS specifically, it has a similar feel to others I've used and I head over to Pages and Posts to see what I can abuse.  Oddly, as vulnerable as this is to SQL Injection, the UI seems locked down as far as the typical methods such as header, footer, php code, etc.

There is an option to include an image in the post though:

I'm unable to upload a file with a PHP extension but I am able to upload a reverse shell without any real manipulation other than changing the extension from .php to .php.jpg

When I visit the newly created post, I see that "something" was uploaded:

When I use Inspect Element, I learn that my file has been renamed.  This protection mechanism will prove to be a nuisance for getting a shell.

I play around with a few different ideas and I end up using Exiftool to embed some PHP into an actual image:

I create another post and I insert my malicious image:

This is an actual JPG file, in fact, it's the site logo.  The act of inserting PHP into this image does not mean we are going to get a shell.  However, it will HIDE a shell which can be used for persistence!

Viewing our malicious image -- which looks like a normal image:

Retrieving the image location:

I should point out that by coincidence, the letters "bad" end up in the image name.  I seriously could not have planned this better!

Now here's where we circle back to SQL Injection --

http://192.168.86.129/post.php?id=33 union select 1,2,3,load_file("/var/www/html/admin/upload/8af833cbad.jpg"),5,6,7,8,9
into outfile "/var/www/html/cmd.php";

[the above is wrapped for easier viewing]

We are going to load our image with SQL and we are going to rewrite it to /var/www/html/ as cmd.php which should allow us to execute it:

After we insert our malicious code into the address bar:

In my limited experience with this CMS, a 404 page means that we did something correctly.  

If we were to look into the file system, we would see that we indeed were able to write to cmd.php:

And if we were to cat that file, we see our malicious code embedded along with the image data:

But when we access this file, we are no longer rendering it as an image, we are rendering it as PHP.  Performing a simple command to see if it's working:

Whoami returns:  www-data

Let's move a shell from our attacking system to the victim machine:

Note:  If you leave the file as .php it will execute and you will pop your own machine!  If we rename it on our attacking machine with a .txt extension, we can move it across to our victim and save it with a .php extension.

If we look at the file system, we can see that our curl worked as we planned:

We then call our reverse shell:

With our handler setup:

We catch our shell!

This wasn't as direct a path as I could have taken but I very much enjoyed taking the different pieces and leveraging them to get the shell.