Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
So few days ago a friend fixed an lfi on his site , and he sent me the url used , it was base 64 encoded url but not usual ../../../etc/passwd ,
It is : Li4vLi4vZXRjL3Bhc3N3ZAAucG5n
Now decoded on base64decode.org I get this :
../../etc/passwd�.png
What is that question mark , I thought it was null byte , but it seems to be some unicode thing. I can't figure it out. Can anyone explain me what does it stand for , can't seem to get same base64 string when I encode it again. Thanks
It's a null character. I used this decoder to save it to a binary file that I then opened with Notepad++ to verify. Whatever it's doing there, that � is how your browser (as you mention in the comment you're using Firefox) decided to represent it in output.
It's not malicious since it doesn't do anything at all except prevents certain Base64 decoders to correctly follow a link provided (could be a simple obfuscation trick to confuse automated crawlers / spiders and alike, while you as a human shouldn't have problems removing excess characters, if they appear at all - i.e. Chrome and IE don't display it, and Opera displays it as □). As you probably have noticed, it also adds another byte to the string being encoded, so the Base64 encoded representation doesn't come with the usual = 4-byte padding typical for Base64 encoded strings (../../../etc/passwd.png would encode to Li4vLi4vLi4vZXRjL3Bhc3N3ZC5wbmc=) that would additionally help identify encoding scheme used.
My guess, you were given such encoded URL to either prevent possible malware to decode it (as a rather simple form of a Turing test), or your friend simply used some Base64 encoding tool that came with this capacity and enabled it without any particular intention (or maybe thought the output looks better that way, without the 4-byte padding). Either case, you're going to have to ask your friend about it, if you want to come to the bottom of it. There are potential uses for such obfuscation, but I can't vouch your friend had exactly this in mind when using it.
It is a null byte character.
It is used if the code always appends an extension to the included file. For example, if the code is
<?php
include($_GET['lang'].".php");
?>
However, you, as the attacker wish to read ../../etc/passwd using the LFI. If you use the null byte character you can append this to the request URL as %00:
www.example.com/index.php?lang=../../etc/passwd%00
This will make the PHP processor stop at the null byte and include the file ../../etc/passwd rather than the path ../../etc/passwd.php which won't work due to the extension. So in summary it gives the attacker a way to truncate the path at a given point and remove any undesired extension.
Regarding the base64 encoding - this could be to prevent the null byte from being "lost" in transit. If you use any mechanism to transfer the URL elsewhere, the software used might terminate the string at the null byte and this would be removed from the URL. An example is if you paste a URL into Firefox, often the string is terminated at the null byte and the page request when made does not include the null byte character.
