1

I am pentesting a site with all permissions. I have been able to upload a PHP shell embedded within a png image. I have also been able to change the extension of the file like something.php. So my question is when I run this file in my xamp local server. It renders some gibberish text and then executes the PHP code. But when I upload the same file to the remote IIS server I'm pentesting, It just renders some gibberish text? rather than executing the PHP code. Why is that and how can I bypass it?

N.B I can upload any file extension I want. I have exploited that part. Now I need to run the code I uploaded which is where I'm struggling...

After I upload and hit the uploaded file path. The output: enter image description here

The request it is sending intercepted by the burp: enter image description here

Improve this question
3
  • It’s impossible to answer this without additional knowledge. It’s depends entirely on the webserver configuration which scripts are executed and which aren’t. Maybe script execution is completely disabled, maybe it’s restricted to specific folders, maybe the IIS instance doesn’t support PHP. I recommend you do some research on IIS configuration and then systematically test which options are enabled. It's quite possible that PHP execution just cannot be triggered in this scenario -- there's no guarantee that an upload immediately leads to a code execution vulnerability.
    – Ja1024
    Commented Jun 28 at 19:28
  • I have updated the post with images. Can you check. The IIS supports PHP. Because most of the file in this CMS is using php. Whenever I hit a path it's like basic.php, entrance.php
    – NobinPegasus
    Commented Jun 28 at 19:42
  • 3
    Perhaps PHP is not enabled in the directory you can upload to. You could try putting ../ into the file name to see if you can escape out. But you may just be out of luck.
    – paj28
    Commented Jun 28 at 21:36

2 Answers 2

Reset to default
1

As you can see, PHP is not being executed in the PNG (you see the shell source code, not the result of phpinfo()).

A remote possibility is that you need some guard space before the PHP opening tag (e.g. a dozen newlines).

But the most likely reason by far is that the IIS instance is simply configured to not execute PHP code outside of its source root, or maybe PHP execution is actively disabled via the equivalent of .htaccess in the upload directory.

This is a basic security tip that most installations have - or should - by default.

I would expect directories containing code to be read only (updates can be performed in various ways, if possible with a dedicated user), user-writeable directories (CSS, images, avatars, documents...) to be not executable, and directories that need to be both writeable and executable, like code caches, to be inaccessible from the outside.

Improve this answer
1

The directory didn't have the execution permission.

I used another upload function. It uploaded to upload/file/<something>.php

It executed properly and worked. The previous directory was upload/head/<something>.php

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .