23

I recently got a phishing mail of unusually bad quality; "Please imediatly sign in under the following link, as we are your bank, you know"-ish. The link points to an unconvincing URL with .php at the end.

I was asking myself why they might use a PHP script instead of just faking the look of the given page and submitting entered data to a form.

I don't really want to click the link to find out, but I would love to get to know what this PHP file is about to do. Is there a way of downloading the script, such as you could with the client-sided JavaScript?

Or am I not able to access the PHP file, as it is executed by the server?

Are there other ways of analyzing this file and its behavior without any danger?

Anders
  • 64,406
  • 24
  • 178
  • 215
Zaibis
  • 701
  • 1
  • 4
  • 16
  • 28
    A PHP file is executed server-side and CANNOT do anything to your web browser. What it can do is dynamically generate malicious client-side code which could cause issues for you. – MonkeyZeus Sep 03 '15 at 13:12
  • 1
    Accessing a URL that (seemingly) references a PHP file is almost always very different than doing the same but for an HTML file; the former causes the host server to execute the file whereas the latter actually does result in your computer downloading the file. – Kenny Evitt Sep 03 '15 at 13:19
  • @MonkeyZeus I'm aware of that, and exactly thats what I wanted to avoid, seeing what the content will be wihtout having my browser built it. – Zaibis Sep 03 '15 at 13:35
  • @KennyEvitt: Correct me if I'm wrong, but in both cases there will be the content downloaded, won't it? jsut in the first case the php form dynamically generates it and it isn't static saved on the server?! – Zaibis Sep 03 '15 at 13:38
  • 8
    If you are looking to avoid having your web browser download and execute potentially malicious client-side code then you can use `wget` to download the output into a file which you can then open with Notepad. The only potential issue with this is that the PHP code might be able to detect that you are not using a web browser so it could merely output a blank file. You might need to send some headers which mimic a real UA-string. – MonkeyZeus Sep 03 '15 at 13:44
  • 3
    @Zaibis You're mostly correct. Technically a URL ending in ".php" could result in *any* code, not just PHP, being run. And technically a server could not respond to a request. Both scenarios are tho extremely rare. – Kenny Evitt Sep 03 '15 at 13:54
  • 13
    Nobody has yet said that accessing in any way an URL from spam (or something like it), especially if it contains an ID (theoretically an address without ID also can be sent only to you), can let the spammer/phisher know that you did it and encourage him to send more spam or sell your address to somebody else. Server can be configured to run some code when responding to any request, alse ending with ".html". – BartekChom Sep 03 '15 at 18:59
  • @BartekChom Even the case of an invalid URL and a web server without fancy/malicious configuration would work for the spammer as the URL (with ID) will end in the access or error log – Hagen von Eitzen Sep 05 '15 at 12:10
  • 2
    > "The link points to an unconvincing URL …" — there's no way to say Where the link actually points, *the link's text says absolutely nothing* about what will be done. It may end with `.jpg`, for example, and reply with an `.exe` file, or reply with HTTP redirect to arbitrary place. Behavior is only limited by the protocol, which is chosen by first word (http[s], ftp[s], etc…). And in any case, the server can know and store your IP address, and everything you've sent to it. – Display Name Sep 05 '15 at 13:12

6 Answers6

69

If the server is configured correctly, you cannot download a PHP file. It will be executed when called via the webserver. The only way to see what it does is to gain access to the server via SSH or FTP or some other method.

This is because PHP is a serverside language, all the actions are performed on the server, then the result is sent to your browser (which is clientside).

If you are afraid to mess with your system, you could use Virtualbox with an Ubuntu VM and open the page from there. If you take a snapshot of the VM after installing, and before doing dangerous things, you can later go back to that snapshot and undo anything the script could have done to the VM.

SPRBRN
  • 7,379
  • 6
  • 33
  • 37
  • Many phishing mails link to pages hosted on hacked websites with weak passwords, so maybe is possible to get access just guessing those. Of course you don't get too much with this. – Gustavo Rodrigues Sep 03 '15 at 12:45
  • 4
    If you want to get at what the server delivers without executing it in your VM's browser, you could use curl to download the HTML. You'd have to manually download any external files like CSS, JavaScript, and images, though. (That might not be a bad thing.) Strictly speaking, though the server could deliver something different based on the HTTP headers. Isn't it also possible that just by visiting the address you might be giving the attacker information they want: confirmation that there is a person at the destination address? (An identifier would have to be coded into the URL, of course.) – jpmc26 Sep 03 '15 at 21:15
  • I know a web server which had a bug at one point so that appending a space to the url would make it serve a script instead of executing it. – Carsten S Sep 04 '15 at 12:02
  • 3
    *and undo anything the script could have done* => apart from any network traffic that went out the VM, after all it's connected to Internet... – Matthieu M. Sep 04 '15 at 13:28
  • 1
    @GustavoRodrigues You don't get much with that, except for potential jail time for unauthorized access to a computer system. Don't try to access a potential compromised server. – Sumurai8 Sep 05 '15 at 14:07
  • Is what I said. By the way maybe I don't saw any problem with this because where I live the laws related to this are too recent so even cases where people did it maliciously don't got jailed (at least as I can record). – Gustavo Rodrigues Sep 05 '15 at 16:59
12

As others have said, the PHP file is executed server-side, unless the server is so badly set up that it will simply serve the source.

If you would like to examine what is sent to your client without the possibility of it doing anything untoward, use a text editor like Notepad to open the URL. That is, use File → Open but open the URL rather than a real file.

The server will interpret the request and send what it would normally send to a browser. Your text editor will receive it, but all a text editor can do is display if for editing. It will never get near a browser or other rendering engine to be executed.

Andrew Leach
  • 384
  • 1
  • 10
  • Awesome, such simplicity is often tough to think of. – TDsouza Sep 08 '15 at 10:28
  • @TDsouza not really because it doesn't make that clear that the PHP server side code will be deleted from the file if you look inside the php file that a client receives – barlop Jul 05 '16 at 19:51
  • PHP server-side code is not deleted. A PHP script directs server-side processing; server-side code is **not sent to the client at all.** This answer provides a means of examining what is actually sent to the browser, but without the risk of executing any client-side code. – Andrew Leach Jul 05 '16 at 21:21
2

There is a way if the server contains an LFI exploit: https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion .

Though, if the server is properly configured once should not be able to download PHP files.

I recently had the pleasure of patching this in a project I inherited, hence why I know about it. One could directly download PHP scripts by giving the name of the desired script over the $_GET[] which would count.

Truth being told, you'd have to have some luck that there's an exploit possible and you'd also need to figure out the way the server's filesystem is structured (i.e. what is the relative path of the script you're interested in compared to the script containing the LFI-vulnerability) So if you plan on exploring the server, use a sandbox/VM. You may be in luck if the server is indeed poorly configured as suggested by the comment from Gustavo Rodrigues.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Clueless_captain
  • 121
  • 1
1

The .php file is executed on the server side so there is no way of getting the source code unfortunately. What you can try however is to manipulate the URL with the hope that the sysadmin made a mistake.

When a user visits http://www.example.com/index.php, the web server generates the HTML response by /usr/bin/php executing the index.php file from /var/www/html.

Web servers are typically configured to execute .php files only, so .jpg or any other file types are served as normal.

If a forgetful sysadmin made a copy of the .php file for backup purposes however, you might be able to retrieve the copy without being executed by /usr/bin/php

So if the sysadmin made a copy as /var/www/html/index.php.bak, you may download its source code by visiting http://www.example.com/index.php.bak with your browser.

Finding these leftover files is a cumbersome task, so you might want to have a look on automated URL fuzzing tools.

Finally I recommend using curl to make these experiments, because it won't execute JavaScript or Flash on your machine.

Gabor
  • 179
  • 5
  • 1
    I once successfully used the "Emacs backup" trick - appending ~ to the filename, e.g. ``http://www.example.com/index.php~``. I guess this is because the author of the attack gained SSH access and what he had at hand was either Vi or Emacs, and he was in the Emacs camp. And I've not see that many Apache servers configured to refuse serving '*~' files. –  Sep 04 '15 at 12:04
1

No, you can't, because PHP is executed on the server. End.

  1. There is no need to get the code, because it's not executed on your computer, so there is no security risk for you.
  2. PHP will serve websites like any other, so that there is no PHP-specific answer.

    If you're interesed in a general answer, have a look at How do I safely inspect a suspicious email attachment? Its answers are also true for opening websites safely.
Community
  • 1
Christian Strempfer
  • 465
  • 1
  • 3
  • 15
0

You cannot via HTTP because

A)PHP code written in the file, is deleted from the file by the http server before it is sent to the http client

So an HTML form might reference blah.php which contains a php snippet, code surrounded with php tags, that checks if submitted password=1234 but if you were to wget blah.php you won't see that code. (even if the php supporting web server did let you get blah.php directly, without redirecting you to receive some other file.. it's not really the blah.php on the server that you are getting). It's blah.php processed by the server with php code removed and replaced with whatever the php outputted. Or with whatever client side code(html/javascript) the php code determined should be shown.

and

B)the HTTP server's php module will execute any php and produce the resultant file to send to the client.

By the way, technically an HTML file on a server can contain PHP. So it's not like PHP files are more dangerous than HTML files. PHP code does server processing and then outputs other client side stuff one may find in an HTML file like HTML or clients side javascript.

barlop
  • 129
  • 4