How to exploit this include_once vulnerability in PHP?

Question

I'm performing a static analysis on a PHP code and came across this situation:

include_once SYSTEM_PATH . 'languages/content-' . $_COOKIE ['lang'] . '.php';

If I try to hack with this HTTP request:

GET /en-us HTTP/1.1
Host: xxxx.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: xxx=eng.php/../../../anotherfile
Connection: keep-alive

The response is this:

ErrorException: 
include_once(/export/htdocs/xxxx.com/base/languages/content-eng.php/../../../anotherfile.php): failed to open stream: No such file or directory

The file languages/content-eng.php exists on the server.
The file languages/../../../anotherfile.php exists on the server too (I have access to the file system).

Is there any way to exploit this vulnerability through lang cookie?

Answer 1

Sigh. Here is the reasoning for me posting a link in lieu of a long answer. Original post wants to inject/disaffect/exploit through the lang variable in cookie:

GET /en-us HTTP/1.1
Cookie: xxx=eng.php/../../../anotherfile

He then states he tried and failed:

ErrorException: 
include_once(/export/htdocs/xxxx.com/base/languages/content-eng.php/../../../anotherfile.php): failed to open stream: No such file or directory

"No such file or directory" to me means one of a few things:

1) His directory traversal is off:

/export/htdocs/xxxx.com/base/languages/content-eng.php
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/anotherfile.php

If the structure is exactly as above, there is no directory traversal vulnerability period.

2) eng.php is not detailed enough to know what it does. This would have to be the vulnerable weak link on the chain

He is relying on an error, thinking: "Oh well I have an error, I am headed on the right track"

OP: You could fiddle with the directories a bit more. It is telling you "I can't find this file" the issue becomes "what are you finding" if you state you have access to the machine, the solution I would use would be to place tokens in folders to determine where you are landing:

/export/htdocs/xxxx.com/base/languages/**option1**/token1
/export/htdocs/xxxx.com/base/languages/**option1/option2**/token2
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/token3

Then try another POST/GET perhaps:

Cookie: xxx=eng.php/token1
Cookie: xxx=eng.php/token2
Cookie: xxx=eng.php/token3

Cookie: xxx=eng.php/../token1
Cookie: xxx=eng.php/../token2
Cookie: xxx=eng.php/../token3

Cookie: xxx=eng.php/../../token1
Cookie: xxx=eng.php/../../token2
Cookie: xxx=eng.php/../../token3

Just because you got an error, does not mean directory traversal is present. For all you know it's is a global error you are getting. The initial link I sent was to guide you on a "known known" (variable you control) lang.

---

EDITING FOR SPACE CONSTRAINTS:

OP: "The base is /export/htdocs/yyy.com/base/. The anotherfile.php is in /export/htdocs/xxx.com/anotherfile.php"

Unless I am misinterpreting this:

/export/htdocs/yyy.com/base/

/export/htdocs/xxx.com/anotherfile.php

Are these on separate sites? If xxx.com is your own server/test machine, I'm under the impression you're trying an LFI exploit:

you --> modify cookie (hey, take this anotherfile.php from my machine) --> yyy.com

Again, the reasoning for my initially posting a link in lieu of an answer. If you meant the other way around (typo):

/export/htdocs/yyy.com/base/

/export/htdocs/yyy.com/anotherfile.php

Then you need to modify your insertion to ../../anotherfile or move another file into:

/export/htdocs/yyy.com/base/

Answer 2

You can't read PHP code with an include() or require() because these functions evaluate the PHP code within a file. If you can control the beginning part of the string passed to include() or require() then you can use a php://filter to read php files, but this attack pattern does not apply for this bug.

In order to get a shell with this LFI vulnerability, you need a have a backdoor on the target with a .php extension. Ideally this would be done using another vulnerability like file upload. NULL byte injection doesn't work on modern versions of PHP's fileio functions, so you are stuck with the .php extension.

Another attack pattern is to include existing .php files to expose existing application functionality in an unintended way.

Answer 3

It works perfectly fine for me with eng.php/../../../anotherfile (I'm using PHP 5.5.6-1).

• Are you sure that anotherfile.php is in the correct directory? Try placing it in the same directory as the lang php files and include it there (just for testing).
• is it readable by the web server? (for testing, you can just chmod 777 file.php).

Also note that while including PHP files should work, including other files (eg by using null byte) does not work in newer versions of PHP.