augustd
ASP.net Reporting Results Incorrectly
Reports for ASP.net report in the following format:
Issue detail The server software versions used by the application are revealed by the web server. Displaying version information of software information could allow an attacker to determine which vulnerabilities are present in the software, particularly if an outdated software version is in use with published vulnerabilities. The following software appears to be in use:
Microsoft IIS: 8.5 ASP.Net MVC Framework: 5.1 ASP.Net: 4.0.30319
From the header:
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: <redacted>
Server: Microsoft-IIS/8.5
Set-Cookie: ASP.NET_SessionId=<redacted>; path=/; HttpOnly
X-AspNetMvc-Version: 5.1
X-AspNet-Version: 4.0.30319
However the X-AspNet-Version response header isn't ASP's way of indicating the MAJOR.MINOR.BUILD in use on the server, as explained here: https://stackoverflow.com/questions/12971881/how-to-reliably-detect-the-actual-net-4-5-version-installed
The checks for ASP.net should be updated to match those observed in the stackoverflow thread. Please let me know if you concur with this finding and would like me to put in a pull request.
Are you saying that you want to translate the version numbers returned in the header to the verbose values in the Stackoverflow article? For example, 4.0.30319.1022 would become .NET 4.0 on Windows XP SP3, 7, 7 SP1 (with MS14-009 GDR security update).
I'd be all for that, but the problem I have noticed is that the headers usually don't reveal the full minor version. You only get 4.0.30319 which could be any number of real versions. If you have a way of detecting the full version I'd really a pull request!
I think the problem is twofold - primarily, the issue description is a bit misleading and it makes you think that the server is running ASP.net 4.x (instead of running something like 5.1). I think adding a clause against ASP.net headers or reducing the certainty for it would be prudent.
The second part of it (reliably detecting the version with 4.0.30319 in the header) does seem like it may not be solvable, but I'll setup a lab for it and see if I can get something worthwhile.
Based on your feedback I've reduced the certainty to "Firm" for ASP.Net findings.
Excellent, thank-you. I've been moving house so I haven't yet had a chance to set up a lab and test for a reliable method of fingerprinting this but I'm hoping to do so in the next couple of weeks.
Just remembered about this one today, I'll circle back to it in a few days.