6 Risks Still Around For No Reason

Apache is the most popular web server on Earth, with a market share of 46.4% — well above Nginx (21.8%) and Microsoft IIS (9.8%). Thanks to Linux package managers like Yum and APT you can install and get it up and running in minutes. The core installation even features powerful modules for URL rewriting, user authentication, and more.

With a low barrier to entry and such a mature feature set it’s no wonder it’s the go-to web server for standalone developers and enterprise DevOps teams alike.

Given that same market maturity: why is it still vulnerable by default?

See For Yourself: Installing Apache with Yum

Let’s examine the initial state of Apache 2 after a fresh installation to identify security risks.

For the purposes of our test we’ll spin up a t2.micro instance in Amazon’s EC2 cloud using RHEL7 (we could have just as easily chosen another distribution like CentOS).

Spinning Up a t2.micro Instance on EC2

The only non-default settings will be opening ports 80 and 443 in the security group when we’re creating the instance.

(New to AWS and EC2? Getting Started with Amazon EC2 Linux Instances)

Step 1: Update the currently installed packages

sudo yum update -y

Step 2: Install Apache 2

sudo yum install httpd -y

Step 3: Add the Apache service to startup, and start the Apache web server

sudo systemctl enable httpd.service

sudo systemctl start httpd.service

Are we running now? Let’s navigate to the IP address of our instance with a web browser and find out.

Red Hat Enterprise Linux Default Welcome Page

Great! Although if you don’t see the above test page or receive an error there are a slew of things that could be wrong (firewalls, blocked ports, etc). Detailed configuration instructions can be found on guides like this one on CertDepot: https://www.certdepot.net/rhel7-install-apache/

What’s Wrong Already? PCI Scan Results

The payment card industry (PCI) requires merchants (online or off) to follow their requirements for secure credit card processing. These same requirements and guidelines generally follow along with the latest security research, making it a good foundation to assess risk. Let’s do a PCI DSS compliance scan to survey the landscape of vulnerabilities.

(New to PCI DSS? https://www.pcicomplianceguide.org/pci-faqs-2/)

For the purposes of our test we’ll use the Trustwave TrustKeeper® platform (more options: PCI Approved Scanning Vendors) to run a vulnerability scan of our new web server. As a caveat to any such system, automated PCI vulnerability scans often find false positives and can’t magically find every hole in a system’s security. They should be treated as the bare minimum of due diligence, not a guarantee of a secured system.

Initial PCI Compliance Scan Results

Here’s a full list of the identified vulnerabilities:

Apache HTTP Server mod_log_config Denial of Service Vulnerability

Apache HTTP Server mod_dav Denial of Service Vulnerability

Apache HTTP Server mod_deflate Denial of Service Vulnerability

Apache HTTP Server mod_lua module access restriction bypass

Apache HTTP Server Bypass Access Restriction Vulnerability via Require Directive

Apache HTTP Server Request Smuggling Vulnerability via Invalid Chunk-Extension Characters

HTTP TRACE/TRACK Methods Enabled

HTTPoxy Vulnerability

Indexable Web Directories

No X-FRAME-OPTIONS Header

Discovered HTTP Methods

Discovered Web Directories

False Positives: Red Hat Backports Fixes

The above list has six false positives — the very first six in the list, represented by the following Common Vulnerabilities and Exposures: CVE-2014-0098, CVE-2013-6438, CVE-2014-0118, CVE-2014-8109, CVE-2015-3185, and CVE-2015-3183.

There are two things to know:

The “evidence” the PCI scanner found was that the Apache version number detected (2.4.6) was less than the Apache version in which these CVEs were patched. The latest version of Apache is actually 2.4.23 (as of 2016-10-12)

Why is our fresh installation of Apache not the newest version?

Don’t worry. It is.

Red Hat has a policy of backporting the latest CVE fixes into their own packages — this allows critical patches even after certain major version releases have reached end-of-life and official support has ended.

In reality those issues have already been resolved, but since the PCI scanner only sees version 2.4.6 it believes those issues still exist. It didn’t actually try out the vulnerabilities to assess their existence, it only checked the version number.

That begs the question: how did it even know what version of Apache is running on the server?

#1 Hide the Server Version and OS

A quick look with Inspect Element in Chrome shows us what the default welcome page’s header contained.

Exposed Server Version and Operating System Details

Not only is the server version listed, but the operating system too!

There is no valid case for broadcasting this information in a production (e.g. public) environment. This is a classic example of information leakage: if a new exploit is found affecting a specific version of Apache (and/or OS combination) then this server is on a target list for someone, somewhere, to attack.

Mitigation is simple — edit the ./conf/httpd.conf file to include (or alter) the following configuration lines and restart Apache:

ServerTokens Prod

ServerSignature Off

Apache Without Server Signature

Excellent, the server signature with version and operating system information is gone. How does this change the results of our PCI scan? Here’s what’s left:

HTTP TRACE/TRACK Methods Enabled

Indexable Web Directories

No X-FRAME-OPTIONS Header

Discovered HTTP Methods

Discovered Web Directories

#2 Disable the HTTP TRACE Method

HTTP TRACE is used to echo back input for debugging purposes. It has no place in a production environment and is a direct threat due to the risk of Cross-site Scripting (XSS). Using the TRACE method for such an attack is referred to as Cross-site Tracing (XST).

(Learn more: CVE-2004-2320, CVE-2010-0386)

As with hiding the server version information, just edit httpd.conf with the following configuration line and globally disable the TRACE method:

TraceEnable Off

Once you restart Apache at least one method of leaking cookies and web authentication credentials has been eliminated.

You’ve probably caught on that the theme of this article is all about the real world usage of Apache, and in the real world there’s almost never a need to use TRACE.

#3 Limit HTTP Methods to GET, HEAD, POST

HTTP supports a lot of different methods, but unless you’re building an API or web application you should restrict them to prevent information leakage.

By limiting the HTTP methods to GET, HEAD, and POST you remove the OPTIONS method (enabled by default) and prevent future unintended usage of PUT, DELETE, CONNECT, and PATCH as well.

A few more lines in httpd.conf will accomplish this:

<Location />

<LimitExcept GET HEAD POST>

Require all denied

</LimitExcept>

</Location>

#4 Just Say No to Indexes

Welcome to the year 2016: indexable web directories are both a security risk (did you mean to show everyone all those files, even the configuration files and developer notes?) and a visual clue that the website’s configuration is in its default, vulnerable state.

There are still valid uses for indexes, such as in file storage mirrors, archives, etc. — if it’s that important to a user then they can be enabled via an .htaccess file on a folder by folder basis.

For everyone else, disable them globally by by editing the httpd.conf and adding these configuration lines before the <Directory> blocks:

Options -Indexes

Note that it’s outside the <Directory> blocks, making it a truly global effect that can be overridden on a more granular level.

Now, find the <Directory /var/www/html> block and change the Options statement within to:

Options -Indexes +FollowSymLinks

Make sure you also adjust the AllowOverride directive in the same block from ‘None’ to:

AllowOverride All

In a sane world this would be enough, but Apache includes Fancy Indexes and the /icons folder has a specific override in ./conf.d/autoindex.conf that needs to be edited:

<Directory "/usr/share/httpd/icons">

Options -Indexes +MultiViews +FollowSymlinks

AllowOverride None

Require all granted

</Directory>

Once you restart Apache you’ll no longer see indexes available for directories, but you can override that behavior as needed with .htaccess files at the directory level.

#5 Basic Clickjacking Defense with X-Frame-Options

Clickjacking is a persistent threat.

You don’t want your own content to be used maliciously to trick users into performing harmful actions, and much time and effort has been put into developing defenses such as frame breaking/busting.

Modern browsers support the X-Frame-Options header to define when and where frames are allowed to display your content. It’s not a perfect solution and has limitations, but is a foundation for a successful anti-clickjacking strategy.

Adding this configuration line to Apache’s httpd.conf will make frames available only from the same originating domain:

Header always append X-Frame-Options SAMEORIGIN

This is a reasonable approach to framed content for an initial production push of a web site. Further exceptions can be defined using the ALLOW-FROM option.

Congratulations! Now that we’ve dealt with the readily identifiable vulnerabilities and exposures from the PCI report we should examine one more security issue caused by the default configuration.

#6 Basic XSS Prevention

Cross-site scripting will ruin you and your users’ day — representing one of the severest threats to otherwise benign web experiences. XSS is all about executing malicious code (like stealing cookies) on unsuspecting victims.

For instance, one classic vulnerability has been in discussion forums that allowed embedded JavaScript (by obfuscating the <script> tags) that, once posted, exposed the login credentials of every reader to a data-gathering URL slurping up the compromised identities.

One simple preventative step is to take advantage of forcing XSS Protection for compatible browsers by adding this configuration line to httpd.conf:

Header set X-XSS-Protection "1; mode=block"

You can learn more about the development of this XSS Filter on Microsoft’s blog.

Why Not Change the Default Configuration?

The six examples above are just a few of the immediate ways Apache is vulnerable out-of-the-box. Googling ‘hardening apache’ yields plenty of articles and blogs dedicated to the topic.

Why not just include these changes as defaults in the Apache configuration files from the start?

Are there valid reasons that the above six configuration changes should not be the default behaviors? Especially when installed by package managers?

I’m sure arguments could be made for Apache being highly configurable and that being able to debug/diagnose installations quickly is important. Maybe you could make a case for wanting it to be as ‘unrestricted’ as possible in its initial state — after all, you can do almost anything with a web server these days!

But still, in day-to-day usage Apache is running web sites. It’s exceptionally good at it, and has a majority market share consisting of users with widely varying degrees of experience. We know the broadest use case demands closing the vulnerabilities listed above, so why not give Apache admins the best possible head start?

Why leave Apache vulnerable by default?