Skip to content
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

Closed
nnposter opened this issue Aug 17, 2016 · 4 comments
Closed

Performance gain in http-default-accounts.nse via request sharing #516

nnposter opened this issue Aug 17, 2016 · 4 comments

Comments

@nnposter
Copy link

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:

PORT     STATE SERVICE
80/tcp   open  http    
|_http-default-accounts: [Arris 2307] credentials found -> : Path:/logo_t.gif

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.

@nnposter
Copy link
Author

@cldrn FYI

@nnposter
Copy link
Author

nnposter commented Aug 19, 2016

See r36136 - 37a9142 for the corresponding fingerprint changes

@cldrn
Copy link
Member

cldrn commented Aug 19, 2016

Great work! I will test it and hopefully add new fingerprints next week when I have access to Dell Dracs, different switches, etc.

@nnposter
Copy link
Author

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 target_check is probably more expensive than it needs to be.

For the sake of performance I am also tempted to ditch the various /exec and /level probe paths for Cisco IOS. So far I have not found an instance where they find a default credential but the / does not. Opinions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants