X-aspnet-version 4.0.3 Vulnerabilities
Gaetan Boren
The presence of the X-AspNet-Version and X-AspNetMvc-Version headers exposes the version of ASP.NET used by the web server, providing valuable information to attackers. This disclosure can aid attackers in identifying vulnerabilities and planning their attacks more effectively.
In short, what you observed is the limitation of such scanners, who cannot tell what's the actual ASP.NET version on your server side. All they can get is the x-aspnet-version header and value of "4.0.30319", so that they know you are running ASP.NET 4.x.
Like you already knew, all 4.x .NET Framework versions use the same CLR version number 4.0.30319. That's why in the reports you see those results are clearly marked for old ASP.NET versions 4.0-4.6, not 4.8 the version you are using.
Disable the X-AspNet-Version and X-AspNetMvc-Version headers: These headers can be disabled in the web server configuration. For example, in Apache, you can use the following configuration in your .htaccess file:
Update the web application framework: Ensure that you are using the latest version of the web application framework, as newer versions may have addressed this vulnerability by not including the version information in the response headers.
Implement a web application firewall (WAF): A WAF can help detect and block requests that exploit this vulnerability. Configure the WAF to block any requests that contain the X-AspNet-Version or X-AspNetMvc-Version headers.
Increased attack surface: By leaking version information, the server provides attackers with additional details that can aid in the planning and execution of attacks. This can increase the overall attack surface and make it easier for attackers to find and exploit vulnerabilities.
Lack of defense-in-depth: The inclusion of version information in the response headers can be seen as a lack of defense-in-depth. It is generally recommended to minimize the amount of information disclosed by the server to reduce the risk of targeted attacks.
Submits forms and makes requests to the web application to test for vulnerabilities such as SQL injection, remote command execution, and cross-site scripting (see table below for full list). The active scan is not destructive, but it may send thousands of requests to a web application while thoroughly testing for all vulnerabilities. Make sure you have permission from the application owner to run this scan. This scan may take up to several hours, depending on the scanned target.
When it comes to securing your website, every little detail matters. One often overlooked aspect of web server security is the information that is exposed through headers. In this article, we will discuss the importance of configuring the X-AspNet-Version header in IIS to remove version information and enhance the security of your website.
By default, IIS includes the X-AspNet-Version header in every response. This means that anyone who inspects the headers of your website can easily determine the version of ASP.NET you are using. This information can then be used to exploit known vulnerabilities in that version.
By removing or replacing the X-AspNet-Version header, you are effectively hiding the version information from potential attackers. This makes it harder for them to target your website based on known vulnerabilities.
Securing your website is a continuous process that requires attention to detail. Configuring the X-AspNet-Version header in IIS to remove version information is a simple yet effective step towards enhancing the security of your website. By hiding this information, you reduce the risk of targeted attacks, automated scans, and zero-day vulnerabilities.
At USAVPS, we understand the importance of website security. Our VPS hosting solutions provide a secure and reliable environment for your website. Contact us today to learn more about how we can help you protect your online presence.
I can see that this gives the attacker additional information so that he can verify the known bugs on these platforms and then abuse them. But it seems to me that removing these headers can only protect you against very simple script kiddies and any serious attacks would uncover this information rather easily. E.g.
And after all will removing the headers give you any benefits apart from very simple protection from script kiddies who will first target the sites that have the vulnerability like in a popular quote:
P.P.S. There is no point to have this headers anyway since it will even benefit performance (quite negligibly though), so it's a good idea to get rid of them, but I am still curious about the whole "security" argument here
As @Oasiscircle mentions, this information can be used as a starting point for attackers who know of specific vulnerabilities associated with specific versions. We know attackers use botnets to scan servers looking for version fingerprints, and they use this information to maintain databases of application versions and server addresses. Shodan provides a widely used database of this info. When a new exploit is introduced that targets a specific version, or if an attacker develops a 0day exploit against a version, these attackers do a simple select of their databases and strike quickly, hoping to catch some of these machines before they're patched.
Does that make knowing a specific version number a vulnerability? Not directly, but it puts you in the cross-hairs of a field of snipers, each with a hair trigger and the motivation to strike first. I'll leave it to you to determine for yourself if you consider that a vulnerability.
I'm generally dubious about the benefits - as @MarkBuffalo says, lots of attackers will try every attack they know on every server they find, whether it's likely to work or not (even to the extent of trying Windows specific attacks against systems reporting that they're running RHEL).
However, it's not information you need to give out, so I am generally in favour of removing it, where this can be accomplished with minimal effort. This sometimes means reducing the output to just the name of the server (e.g. Apache, IIS) rather than completely removing the Server header, as entirely removing the header may well require introducing new software elements into the server stack.
For example, it takes one line in apache.conf to reduce an httpd Server header to "Apache", but the addition of a proxy to reduce it further. In that case, it seems safer to stick with the minimal line, rather than add an additional element, which may introduce its own flaws.
Similarly, it's easy to see when a site runs Wordpress, but I'd still recommend removing the readme file - it's just not needed, and acts a bit like the bowl of brown M&Ms rider that some rock bands infamously used: you can check it easily, and it shows whether other steps are likely to have been taken.
Let's say that today a vulnerability got announced for all Microsoft IIS 7.5 servers with a small range of ASP Net versions. I'm a malicious attacker, and I want to figure out as many servers that I can exploit as possible before sysadmins patch up the vulnerability. Wouldn't it be a much easier problem to figure out if I could ask each individual server if they are vulnerable rather than having to try the vulnerability on every single server? Plus I could log all this information on a per-server basis and know exactly who I want to attack the instant a vulnerability is found for any type of server.
Hiding your version information will not stop an attack from happening, but it will make you less of a target if attackers are looking for a specific version of hardware or software. Security by obscurity doesn't mean you're safe, but it does slow people down sometimes, and that's exactly what's needed for day zero vulnerabilities.
Serious attackers will try all vulnerabilities they (or their tools) know of, whatever server name / version you pretend you are at. This information is not trustworthy and I wouldn't trust it as a hacker.
If you're serious about security, you update your server as soon as possible. In the case of 0-day, giving the server version away wouldn't make it better or worse. If you're not up to date, that's the first problem you should solve anyway. Serious hackers would assume you're up to date (a typical worst case scenario for them), and extensively check whether that's true for bonus points and a good laugh.
Before you go any further, you should evaluate whether or not you need to remove these headers. If you would like to go ahead and remove the headers then follow the following options.
After installing URLScan, open the URLScan.ini file typically located in the %WINDIR%\System32\Inetsrv\URLscan folder. After opening it, search for the key RemoveServerHeader . By default it is set to 0, but to remove the Server header, change the value to 1. Doing so will remove the Server header Server: Microsoft-IIS/7.5 from the User mode response.
Please note that this is a website-specific rule. If you want to create the rule for all of your applications, create the rule at the server level. Also, some applications, especially third-party applications, may require the Server header, so you may need to remove this rule for those applications.
Please note that this is a website-specific rule. If you want to create the rule for all of your applications, create the rule at the server level. Also, some applications, especially third-party applications, may require the x-powered-by header, so you may need to remove this rule for those applications.
Please note that this is a website-specific rule. If you want to create the rule for all of your applications, create the rule at the server level. Also, some applications, especially third-party applications, may require the x-aspnet-version header, so you may need to remove this rule for those applications.
c80f0f1006