18

Yesterday I discovered somebody had uploaded this PHP code to my server as a .jpg file via my asp.net MVC application's "Upload your profile picture" form. I believe the attack was unsuccessful for a number of reasons (the images are given random filenames, then resized, and they're stored in a non-execute directory). The file was leftover because I failed to clean up the temporary file if the resizing failed, which I've now fixed.

But it worries me that I don't understand what the next step of this attack would be...Say he'd successfully uploaded a .jpg file that had malicious PHP code in it to my Windows/IIS server, and he knew the file's URL. Now what? He would need to get IIS to interpret that .jpg file as PHP code rather than an image, right? What might his plan have been to accomplish that?

The only thing I can think of is if it were an apache server and .php files were being filtered out but .htaccess files weren't, he maybe could have managed it. Is there any equivalent approach that might have worked in IIS?

Improve this question
4
  • 3
    Maybe they were trying to upload a file named script.php.jpg. Some apache configurations would run this as a php script. See e.g. core.trac.wordpress.org/ticket/11122
    – sourcejedi
    Commented Mar 13, 2013 at 19:43
  • What's a nonexecute directory??
    – Mark E. Haase
    Commented Mar 14, 2013 at 15:14
  • 1
    @mehaase It's my made-up term for a directory where any IIS users are denied the "Read and Execute" permission. I recognize that this doesn't prevent some other PHP script from executing it as AJ Henderson explained but I thought that it would prevent it from being executed if the attacker accessed its url directly.
    – Jared Phelps
    Commented Mar 14, 2013 at 19:13
  • 1
    That script is an webshell, named wow (found here: github.com/BlackArch/webshells/tree/master/php )
    – T.Todua
    Commented Jan 12, 2019 at 11:04

3 Answers 3

Reset to default
16

One possible path would be to try and get it to be included somehow. A lot of add-on frameworks can run an arbitrary PHP code file. If the attacker was able to find such an add-on framework, they could give it the path to the file and it would be executed as PHP regardless of the file extension.

Improve this answer
5
  • Good answer, thank you. That seems like a security nightmare...Is that a common and/or accepted PHP practice?
    – Jared Phelps
    Commented Mar 14, 2013 at 22:37
  • @JaredPhelps - it is by necessity. The idea of including references is done in basically all complex software. Just, with PHP, there isn't an option to use binaries. You can avoid a lot of issues by doing an extension check before loading them though and then making sure that you don't allow upload of PHP files, but not everyone is that thorough.
    – AJ Henderson
    Commented Mar 15, 2013 at 13:05
  • Sure, I understand the need to include and reference other libraries, but it seems pretty crazy to get those references from the query string, you know?
    – Jared Phelps
    Commented Mar 15, 2013 at 16:33
  • 1
    @JaredPhelps - it doesn't come from the query string, but it does come from the DB often if it is modular. If they can get the code in place it lets a separate SQL Injection attack become a code execution attack, but they still need to be able to find a way to inject the data.
    – AJ Henderson
    Commented Mar 15, 2013 at 16:48
  • Oh, I see, thanks for the explanation, that makes a lot more sense than what I was envisioning.
    – Jared Phelps
    Commented Mar 15, 2013 at 17:31
1

That's an interesting script you found there. One thing I noticed is that it will apparently serve images -- if you've registered mod-php to handle .jpg files:

enter image description here

I have no idea what this picture is there for, but it's an interesting feature.

Anyway, the script appears to be a remote shell. I disagree strongly with Manishearth on almost every point. AJ Henderson has a much better answer: no matter what the file extension is or where it is stored, PHP will try to execute it if told to. If the attacker can control the path to an included file, then the attacker can execute this script.

Improve this answer
1
  • Exactly why do you disagree/what do you disagree with? I never refute that PHP will execute if told to. I'm saying that you can prevent the "if told to" by keeping tight control on the name and location, nobody (except someone with shell access) will be able to tell PHP to execute it in the first place.
    – Manishearth
    Commented Mar 14, 2013 at 15:58
1

As long as you have control over the file name and where it's stored1, it's not an issue. They basically could try replacing an existing php file, such that next time it's run, their code gets run instead.

Another trick they could try is forcing your server to run the file. PHP is run with permissions that can't be obtained by a hacker via normal HTTP. The attacker could upload foo.php, and your server will move it to images/foo.php. Now, the attacker visits the page. This can be prevented by controlling the filename (again) and/or setting your .htaccess to disable PHP in your image directory.

You need to be especially careful about this when your site is of the form where visiting a page of the form run.php?name=abc.php will display or include 'abc.php'. In such a case, keep restrictions on the GET parameter so that only certain files can be run. This applies for any part of your application which includes or runs some PHP file based on input from the user. Scrutinize these and ensure that the user cannot force the system to run a file outside of the ones which you want to run.

1 This includes preventing them from getting the file saved as ../../foo.jpg or (shudder) ../index.php

Improve this answer
4
  • "As long as you have control over the file name and where it's stored1, it's not an issue." Wrong. See AJ Henderson's post, and also consider what happens if mod-php is a registered handler for .jpg files.
    – Mark E. Haase
    Commented Mar 14, 2013 at 16:04
  • "PHP is run with permissions that can't be obtained by a hacker via normal HTTP." I'm not sure if this is true for IIS in particular, but it's definitely not true in general. E.g. when running mod-php with apache, mod-php runs inside the daemon processes, and therefore executes as the same user, same umask, etc.
    – Mark E. Haase
    Commented Mar 14, 2013 at 16:06
  • @mehaase: Fine. Assume that mod-php is a registered handler for .jpg. So? Until the attacker coaxes PHP to run that file, he can't do anything. I've addressed AJHs point about "giving a path" in my last paragraph, though I probably ought to expand that a bit.
    – Manishearth
    Commented Mar 14, 2013 at 16:09
  • @mehaase: By that I meant that HTTP can only send and receive messages, which have no direct effect on the filesystem. PHP can wreak havoc with the filesystem if told to.
    – Manishearth
    Commented Mar 14, 2013 at 16:11

You must log in to answer this question.

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