How to deal with a remote code execution vulnerability

Remote code execution vulnerability severity   

Both remote code execution vulnerabilities create a total loss of confidentiality, integrity and availability. They come with a Common Vulnerability Scoring System 3.0 rating of 7.8 on a 0-10 scale.

The first vulnerability could allow an unauthorized attacker to execute arbitrary code in the context of the current user. A successful defense of an attack would require a user to take some action before the vulnerability can be exploited, such as the installation of a malware extension to the code. Failed exploit attempts will likely result in denial of service conditions.

The second vulnerability could allow the attacker to gain privileges via a Trojan DLL in an unspecified directory.

A programming-savvy attacker could target the SecurityHeaders, which sends a report on HTTP security headers and server information back to a local browser. An attacker could exploit the default value broadcast for the IIS version in use as such:

Server:  Microsoft-IIS/8.0

where Server is the HTTP server header and Microsoft-IIS/8.0 is the default value.

The attacker could also exploit the preloading of the HTTP Strict Transport Security security header protocol. When the preload directive is added to the security header, all subdomains are included for a specified period of time. The main risk associated with this vulnerability is that the specified period of time setting could be up to a year. And, a developer wouldn’t be able to shorten this setting to 90 days to fix the subdomain problems, and an update may not be able to propagate until after the original maximum time directive expires.

Remote code execution vulnerability risk mitigation steps

Here are some recommendations on how to mitigate the latent remote code execution vulnerabilities.

Automatic downloads: Set up a default setting of automatic downloads of Visual Studio Code updates.

Access rights: Grant minimal access rights to individuals and team members — such as read only, read and write. Avoid allowing members, except the administrator leader, to have full access rights.

Network traffic: Run network intrusion detection system IDSs to monitor network traffic for malicious activity that may occur after an attacker exploits the Visual Studio Code vulnerabilities. Ensure IDSs are free of vulnerabilities as well.

Analysis report: After you implement the HTTP response headers as mentioned above, follow these three steps to receive an analysis report. First, transfer the latest version of a script from a local machine to a server. Second, enter any website address in a local browser to implement HTTP response headers in the script. And third, head over to Security Headers or another website to analyze the report sent back to the browser. An overall grade is included for all security headers, the report discloses server information by default and doesn’t provide warnings on the risks if you use the preloading list in a HTTP security header.

Server information: Avoid broadcasting default server information. IIS 8.0 software allows the developer to add a new value to the script like Web.config before it deploys to the server. The report from SecurityHeaders should show the new information like this:

Server: Hello World!

To suppress the HTTP server header from sending to a local browser, the developer should use IIS 10, which is shipped with Windows 10, Windows Server 2016 and other options. You only need one code line in the script to suppress the header, the removeServerHeader attribute, which can be set to true.

<security>

<requestFiltering removeServerHeader=”true” />

</security>

Compiler language used to run the script is one of the VB and C variants. Non-window platforms may not have the capability to remove or suppress the HTTP security header.

Preloading list: Exclude the preload directive from the HTTP Strict Transport Security header to avoid preloading a list of all subdomains.  The max-age directive is expressed in seconds (one year).

<customHeaders>

<add name=”X-Xss-Protection” value=”1;mode=block” />

<add name=”X-Frame-Options” value=”sameorigin” />

<add name=”Strict-Transport-Security” value=”max-age=31536000″ />

</customHeaders>

If a preloaded list is used, start with a lower maximum age expiry time — 30 days — to make sure all the subdomains have HTTPS support. It’s better to wait until the time frame expires in 30 days than in a year to fix a problem.

Alternatively, use an HTTPS front end for an HTTP-only server — which should be done before you secure the back-end server.