Fingerprinting a webserver + finding new web applications

NmapNiktoNetcraft online toolWappalyzer browser pluginCurl/wget to send malformed requestsnmap -sV ip_adr

-sV is the flag for banner grabbing

Nikto — host ip_addr

Nikto will automatically try banner grabbing

Wapplyzer browser plugin

Will auto analyse if possible

curl http://ip_addr/BAD_REQUEST

Some servers will respond differently to bad requests

Different baseURLs may refer to different applications, often we can only find these by directory brute forcing, for example https://google.com might go to the search engine but https://google.com/mail might point to a totally different webappBesides port 80 and 443 we should investigate anything that looks like a webserver. Use tools like nmap to enumerate all the open ports, -p- for all ports instead of top 1000 and -sU for UDP ports includedvHosts are different hosts on the same webserver, for example mail.google.com and www.google.com might point to the same webserver but they might return a different application based on the routing of the URL. We can use vHost brute forcing tools.Investigate comments made by developersInvestigate metadataReview JS filesIdentify if any debug features exists that we might be able to useMap the application flows in xmindLinkfinder (https://github.com/GerbenJavado/LinkFinder)SecretFinder (https://github.com/m4ll0k/SecretFinder)Burp suite, right click a target > engagement tools > extract comments (Only in pro)ZAP proxyWget to download JS filesGoogle maps API scanner https://github.com/ozguralp/gmapsapiscanner/

Currently one of the best fingerprinting tools on the market. Included in a default Kali Linux build. Language: Ruby Matches for fingerprinting are made with:

Text strings (case sensitive)Regular expressionsGoogle Hack Database queries (limited set of keywords)MD5 hashesURL recognitionHTML tag patternsCustom ruby code for passive and aggressive operations

Sample output is presented on a screenshot below:

Figure 4.1.8–8: Whatweb Output sample

Wapplyzer is available in multiple usage models, the most popular of which is likely the Firefox/Chrome extensions. They work only on regular expression matching and doesn’t need anything other than the page to be loaded in browser. It works completely at the browser level and gives results in the form of icons. Although sometimes it has false positives, this is very handy to have notion of what technologies were used to construct a target website immediately after browsing a page.

Sample output of a plug-in is presented on a screenshot below.

Figure 4.1.8–9: Wappalyzer Output for OWASP Website

%framework_name%powered bybuilt uponrunning

While efforts can be made to use different cookie names (through changing configs), hiding or changing file/directory paths (through rewriting or source code changes), removing known headers, etc. such efforts boil down to “security through obscurity”. System owners/admins should recognize that those efforts only slow down the most basic of adversaries. The time/effort may be better used on stakeholder awareness and solution maintenance activities.

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/https://github.com/allyshka/vhostbrutehttps://github.com/urbanadventurer/WhatWebhttps://www.wappalyzer.com/https://nmap.org/book/man.htmlhttps://github.com/sullo/nikto