The page shows differently depending on the "language" of the visitor. By probing various requests with Burp Repeater, it turns out that the language is desumed from the "Accept-Language" HTTP header, and in particular from the two-letter word specifying the language. For example "en" in "en-US;q=0.5". By probing various inputs, for example "it-IT;q=0.5", we discover that the page displays a different writing and a different image. This may be implemented by retrieving the strings and the images from a database, or by including them from PHP. It turns out that the second case is true. The index.php page loads, if it exists, some PHP code in a file called "en" in case (for example) the Accept-Language is "en-US". This leaves space for a path traversal attack. We can test the vulnerability (with Burp Repeater) by sending the following HTTP Accept-Language header:
../../../../../etc/passwd-US;q=0.5
We notice that the content of etc/passwd is returned back into the page. From the challenge assignment, we know that the flag is inside a "flag" file in the document root. Using the Accept-Language header:
flag-US;q=0.5
does not work, because the PHP code is loaded from a subdirectory of the document root. So we can try:
../flag-US;q=0.5
This should work, and the flag should appear in the returned page.
The vulnerability can be fixed by avoiding to include files whose (part of the) name comes from the input. A possible way is to replace the include statement with a switch-case statement that treats separately each language value and executes static include statements.