Can't get a reverse shell on port 80

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.

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.