Unclear results (false positives?) about vhostscan HOT 7 CLOSED

That would be greatly appreciated! Reach out if you have any questions (can also dm me on twitter under @codingo_ if easier).

from vhostscan.

Hi Julian,

Have you tried using --fuzzy-logic on this dataset? This uses levinstien distance to measure page differences (it's useful for bypassing cases where items such as the time are on the page) and is useful in scenarios like this.

If that doesn't work, but you can see another solution, We'd certainly appreciate a pull request!

Regards,

Michael

from vhostscan.

@ewilded touching base to see where we're headed with this?

from vhostscan.

Hi, my apologies, I have been quite busy lately. I tried the --fuzzy-logic method but did not help with clear results. Will poke around the code trying to get the desired results without interfering with anything that's already working well. If successful, I'll come up with a pull request. Thanks.

from vhostscan.

OK, sorry it took so long. So I sat to this today and started playing with the code. At first I thought that the hash is using the entire response (including headers) and thus ending up different for each of the responses. I introduced an alternative comparison method (a hash of the response.content and the response.status_code) only to realize that it was not the case (response.text == response.content, which is the actual content without headers). The reason I was getting results like above was my unfortunate default virtual host with directory listing, reflecting the provided Host header in the response (

Apache/2.4.34 (Debian) Server at something.something Port 80

). Thus, such instances of the same virtual host were generating unique content leading to unique hashes and results as shown above. Once I added a static index.php to the default webroot and ran the tool again, I got the results I was expecting.
Sorry for the commotion, I did not notice I created a quite troublesome test case. I know such stuff could be avoided by introducing an alternative comparison method like word count - or even more sophisticated mechanism like the one James Kettle implemented for his Backslash Powered Scanner, now used in many other plugins as being part of the Burp API. Anyway, I don't think this scenario occurs this often to really bother.

from vhostscan.

@codingo, should this be marked as closed?

from vhostscan.

@linted yes, I believe so. Thank-you @linted.

from vhostscan.