Never Stop at Banner Grabbing

Hello guys, today we are going to talk about a very interesting vulnerability which I found on a private program. The vulnerability leaked the detailed server version when visiting an unusual error page. The details about this vulnerability are disclosed later after a small introduction to Web server fingerprinting. Please don’t forget to read the Bug Bounty Tip at the end of each post and also like, share and subscribe to the Blog.

Web server fingerprinting

Web server fingerprinting also called banner grabbing is a critical task for the penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

There are several different vendors and versions of web servers on the market today. Knowing the type of web server that is being tested significantly helps in the testing process and can also change the course of the test. This information can be derived by sending the web server specific commands and analysing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyse the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely do different versions react the same to all HTTP commands. So, by sending several different commands, the tester can increase the accuracy of their guess.

For example:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369

From the Server field, one can understand that the server is likely to be Microsoft-IIS/5.0.

Each server has its own protocol behaviour and even though if the server name isn’t disclosed, by just looking at the protocols, the user can determine the server in the background.

Case Study: Detailed server information disclosure

The application under test was a three-tier web application – Presentation tier (Front-End/User Interface), Application Tier (Functional Logic) and Data Tier (Databases) having various subdomains under the scope. As the program doesn’t allow information disclosure, the domain is named as example.com.

Let us consider a subdomain of the website example.com to be sub1.example.com. While testing for the site sub1.example.com it was found that banner grabbing was allowed and would leak the server to be Microsoft-IIS/8.5. Although banner grabbing is a bug but considered as P5 (Informative) on various platforms such as Hackerone and Bugcrowd. Reporting only banner grabbing would affect your average severity, therefore, more details were needed to be submitted along with the server version.

Although dirb is a better tool for directory brute-forcing, a few directory brute-forcing payloads were used in the Intruder of Burp Suite to get the results much faster. The website had its own response to the page not found errors. It would redirect the user to a custom page not found page with a redirect response of 301. The 6000 payloads which were fired line by line would normally show a 301 response code redirecting to the 404 custom page. After approximately 2000 payloads fired, there was one payload which didn’t redirect to a custom 404 page, but a 404 page of the server.

The requested URL was as follows:

https://sub1.example.com/General/admin. (A full stop at the end)