-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support SNI when doing VHost fuzzing? #398
Comments
Oh interesting, never tested for those. Do you happen to know a sni only server on tryhackme or anywhere else? This might work when just supplying the ip instead of the domain name but would love to test those cases |
Ah! Your intuition was correct, using the IP address as the target along with --domain and --append-domain worked perfectly! This was the TryHackMe machine: https://tryhackme.com/room/takeover Original command was: Working command was: Thanks! Do you think a flag might be useful to force this when someone uses the original domain rather than the IP anyway? Just a thought, I'm happy either way considering the second command works. |
do you know why i get this error? i used both command, im in hack the box |
Most probably because you used "https" and not "http" |
This stems from a TryHackMe room which required the discovery of virtual hosts on an HTTPS server which implemented SNI. For most virtual hosts, the main domain's cert worked but simply displayed the same content (e.g. www.domain.com, test.domain.com etc. would get the same response as domain.com).
When valid virtual host was found, a 421 status code was returned, since gobuster had used the original domain.com TLS connection, which didn't use the proper cert for the virtual host.
As it turns out, this status code was enough for gobuster to find the virtual host, but my concern is if the server were configured to simply return the same content instead of an error, these virtual hosts would be missed.
This could be solved with an optional flag like --update-sni or --use-sni which would ensure that a new TLS connection was established with the virtual host used as the SNI.
The text was updated successfully, but these errors were encountered: