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
Performance gain in http-default-accounts.nse via request sharing #516
Comments
@cldrn FYI |
See r36136 - 37a9142 for the corresponding fingerprint changes |
Great work! I will test it and hopefully add new fingerprints next week when I have access to Dell Dracs, different switches, etc. |
Please do not bother with DRAC4 or iDRAC6; I already have fingerprints for both. The one for iDRAC6 is ready to be committed. DRAC4 and older do not currently work due to an unrelated problem with TLS in Nsock. (See #511 for details.) Altogether I have three uncommitted fingerprints blocked due to this problem. I would like to see a raw landing page response from the ancient Dell ERA card. I have developed a fingerprint a while ago but it still uses a unique probe path so its For the sake of performance I am also tempted to ditch the various |
The original version of script
http-default-accounts
relied on checking for 404 HTTP status code against unique URL paths associated with a given fingerprint to determine whether a target should or should not be probed for existence of default credentials associated with the fingerprint.In r31899 back in August 2013 we have added a target_check feature to the fingerprints to improve the fingerprint target-matching accuracy by inspecting not just the status codes but potentially other features of the HTTP responses. This resulted in a substantial performance boost of the script due to eliminating irrelevant credential tests.
The part that has not changed was the use of unique identification URLs in each fingerprint, despite no longer having this strict requirement.
We can realize additional performance gain by turning the fingerprint target-matching approach around. Instead of using the uniqueness of the URLs as the primary factor and augmenting it with the target_check feature we can shift the responsibility almost entirely onto target_check, making it more picky, and aim for URLs that are as common as possible, sharing the HTTP responses across fingerprints.
With my working copy of the fingerprints (24 in total) the current version of the script fires 29 identification requests but when taking advantage of the response sharing the number drops down to 16, i.e. about 45% reduction. Put differently, 13 of the fingerprints do not require additional requests at all (because another fingerprint already provided the data).
Also, as a side benefit, this change will substantially reduce the use of obscure and potentially confusing URLs, such as the path in the following output:
I am planning to commit the change in two parts. The first one is the actual response sharing, which is completely transparent with respect to the script results.
The second part is to update a number of the fingerprints to take advantage of this feature. The work has been largely completed but I will use separate commits as there is no hard dependecy between the two.
The text was updated successfully, but these errors were encountered: