![]() What if the attacker doesn't control any file on the filesystem which ends in. The standard, naive way to try to exploit this LFI vulnerability is to supply a parameter looking something like ?param1=././././var/If we assume that the file /var/But this only works if the attacker can introduce a file with contents of his choice onto the filesystem, with a filename ending in. This looks like a local file include (LFI) vulnerability, right? But the situation is actually a bit trickier than it may at first appear. Suppose we have code that looks something like this: The result explains what saw in his pentest. I'll show you the vulnerable code, why standard LFI attacks don't work, and then how to build a more-clever attack that does work. No error is triggered: the excess characters are simply thrown away and PHP happily continues on. On most PHP installations, if the filename is longer than 4096 bytes, it will be silently truncated and everything after the first 4096 bytes will be discarded. For instance, /etc/passwd/., /etc/passwd/./, and /etc/passwd/././. You can append any number of trailing slashes: /etc/passwd//// is also OK.Īnd, you can append. ![]() Wild, huh? This doesn't work on base Unix, so it is a bit surprising that PHP would accept such a filename, but it appears that PHP is itself stripping off trailing slashes before opening the file. On PHP, it turns out that /etc/passwd/ also refers to the /etc/passwd file: trailing slashes are stripped off. But, here are some you may not have known about. Everyone knows that /./etc/passwd is just another way to refer to the /etc/passwd file. You can add stuff to the end of a filename. First, I need to tell you two facts about PHP's file handling that were discovered by Francesco "ascii" Ongaro and others:įact 1. Here we have a vulnerability that cannot be exploited through standard LFI methods you need more trickiness to work out how to exploit it.īackground. Instead, this is something more unusual and clever. (Full credits to and Francesco "ascii" Ongaro I'm just summarizing what they explained.) I wanted to take the time to summarize what's going on here, on this site. < Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0įascinating! has dug up a truly intriguing, lovely situation here. The following information may be helpful. /./././././././././././././etc/passwd%00/././%.īut they didn't work except the first very long path, what is going on?Īnd how that long path could bypass that vulnerable php-code? (I took a look at some tutorials about LFI) (included a word "invalid", params/website are both censored) įor my next step, I really want to understand what exactly happen so I'm trying to manually exploit it. I have tried to run a vulnerability scanning script (Uniscan 6.0) on some websites and then I found a site which is exploitable with this following path.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |