Following on from Windows, Apache 2.4 and OpenSSL our vulnerability scanner has picked up that although the version of Apache httpd 2.4.39 has not vulnerabilities, the included version of OpenSSL 1.1.1b needs to be upgraded to 1.1.1c.
Continue readingSo how do we do that when we are not building or compiling the Windows binary version ourselves?
We have a distinct lack of version control in the relatively small development team that manages one of our business applications. One of the main challenges isn’t really related to the developers, but to the vendor that connects remotely and “fixes” things without leaving any clue as to what has been changed.
So I came up with a sneaky plan to deploy Git onto the servers and manage the versions of configuration files used by the application. I can then capture any changes and roll back as necessary.
As our environment needs change more and more of our internal services are being forced to change to HTTPS.
Tomcat supports the deployment of services using HTTPS, but many of our vendors have taken the easy route and just use HTTP on the standard port 8080. This is now going to become a bit of a hurdle as we now need to advise clients of the change to HTTPS and the port change involved.
Securing Tomcat with valid certificates is the start of the journey and adding a connector using HTTPS is the first step. Then we need to make calls to the non-secure HTTP site redirect over to the HTTPS version.
In order to make Apache 2.4.27 compliant it needs the later version of OpenSSL v1.1.0. To get this you need to install the VC15 version. The VC11 etc. do not include the later OpenSSL and fail because they are compiled with v1.0.2
Banner : Apache/2.4.27 (Win64) OpenSSL/1.0.2l Reported version : 1.0.2l Fixed version : 1.1.0
This is detailed in the 16 June 2017 change log, but is repeated here as a reminder to install vcredist_x64 for VC++ 2017 which is linked on the downloads page on Apache Lounge.
Googling for how to close the vulnerability for the TRACE method on Apache 2.4 results in lots of responses that just use a rewrite rule to respond with a permission denied message. Even the Nessus plugin output lists the rewrite fix. Nessus doesn’t use this for it’s scans, it carries out a HTTP call for OPTIONS and relies on the server telling it what methods are available.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
Whilst the rewrite rule may be a valid mitigation on Apache servers, the actual vulnerability warning won’t be removed from Nessus’ results.
If you’re using Apache 2.4 then there is a config
TraceEnabledirective that you should use to simply turn off the TRACE method.
