Privacy Notice

“XYZ Mega Corp” is a B2B software company. Their identity will remain confidential and undisclosed. This anonymized report has been made public since many of the issues discovered impact a most production servers.


We recommend pushing updates to a staging server before modifying a live, production system. Here’s the upshot: be sure to maintain regular back-ups of your production server and database(s). You want to ensure the availability of your server in the event any updates cause your system to crash.

This post lists vulnerabilities that were detected throughout your public web site and server configuration. Detailed countermeasures and links have been included to help you address these issues. Furthermore, it appears you may be simultaneously running NGINX and Apache. Hence, remediations for both are discussed below.

It appears your Amazon Web Services (AWS) network architecture is similar to the below diagram. We recommend that read these Stackoverflow questions and solutions to gain a better grasp of the purpose of your network architecture: Do I need Amazon’s EC2, Cloudfront, RDS? and NGINX behind Load Balancers. Also, Stackdriver has a useful post on AWS Dos and Don’ts.

AWS Elastic Load Balancing Service Architecture

  1. Vulnerability: NGINX 1.1.19 has a number of security holes.
    Countermeasure: Use aptitude to install any patches. Alternatively, upgrade to the latest stable or mainline release
  2. Vulnerability: WordPress login is exposed to brute force attacks.
    Countermeasure: Prevent unauthorized access to wp-admin and wp-login.php by creating an IP-based Access Control List (ACL). Since your WordPress pages are being served by Apache 2.2.x you may use the following:
    $sudo nano /etc/apache2/httpd.conf
    # WordPress Config Restrictions on Apache 2.2.x (don't use for Apache 2.4.x and above)
    # Create wp-admin ACL for: 
    <Directory full/path/to/wordpress/directory/wp-admin/>
    Order allow,deny
    Allow from 123.123          # office IP block
    Allow from 456.456.456.456 # CEO's home IP Address
    <Files wp-login.php>
    Order allow,deny
    Allow from 123.123.123 456.456.456.456 # ACL may be placed on 1 line, each IP separated by a space
    Be sure to reload or restart Apache after making these changes!
  3. Vulnerability: The RC4 cipher suite is insecure and broken.
    Countermeasure: Disable the RC4 cipher suite and use Elliptic-Curve Diffie-Hellman (ECDH) by upgrading your web server version and updating your server’s SSL config file. We have an Apache tutorial with instructions. It uses the the Apache configuration recommended by WeakDH has resources on properly setting up SSL config files on popular web servers including NGINX and Lighttpd.
  4. Vulnerability: SHA-1 is a weak hashing algorithm.
    Countermeasure: Re-key your SSL certificate by using SHA-256
  5. Vulnerability: SSLv3 is compromised and exposes you to the Poodle attack.
    Countermeasure: Turn off SSLv3. See our blog post for disabling within Apache. For NGINX, see their HTTPS help docs and this Linode article
  6. Vulnerability: Outdated versions of WordPress and associated plugins have security exploits.
    Countermeasure: (1) Update to the latest version of WordPress. (2) The use of WordPress plugin’s is strongly discouraged. Many free plugins are published by amateurs and dubious entities. Some plugins generate a text copy of your wp-config.php that is indexed by Google. wp-config.php contains WordPress database usernames and passwords. See for compromised sites
  7. Vulnerability: WordPress login ID exposure. WordPress usernames are also used as login IDs. These values may be exposed through author enumeration. For example: will cause a 301 redirect to either (1) or (2) To avoid unintentional information leakage, prevent redirect scenario (1) from occurring
    Countermeasure: Have your content writers create and use WordPress nicknames. If no nickname is provided, WordPress will use the username (login ID) as the value of the author variable.
    If you don’t supply a Nickname, then the User Name will be placed in this field WordPress Codex

    Alternatively, block the author enumeration with the following .htaccess directives:
  8. # source:
    RewriteCond %{REQUEST_URI} !^/wp-admin [NC]
    RewriteCond %{QUERY_STRING} author=\d
    RewriteRule ^ /? [L,R=301]

    Pro Tip: How to Plug Security Holes

    To address security vulnerabilities, your options include (1) removing the resource (e.g., s/w application) that causes the vulnerability, (2) removing the vulnerability from the resource (via patches, feature disabling, or better code development practices) or (3) building walls around the vulnerability at the web server and OS level

  9. Vulnerability: Session hijacking, packet sniffing, content insertion, etc.
    Countermeasure: Enable HSTS (always-on HTTPS). Why is HSTS important? This 45 minute presentation by Google and this short article by the Electronic Frontier Foundation explains the benefits. Finally, a real life case study of unwanted content insertion discovered by a blogger (Chris Stuccio) on his web site
  10. Vulnerability: Secure and insecure data is loaded over HTTPS (i.e., mixed content indicated by the orange-yellow warning triangle over the HTTPS lock in the address bar). These pages are not secure.
    Since the unencrypted resource is sent in clear-text it can be “hijacked” by a motivated attacker and used as a vector to compromise the entire session (c.f., Section 4.2. Avoid Mixed Content of SSL/TLS Deployment Best Practices)
    Recommendation: Your favicon is loaded over HTTP thus producing a silent SSL warning. In your php file, either point to the favicon using a relative URL or an absolute URL using https
  11. Vulnerability: The original release of PHP 5.3.10 has multiple known security vulnerabilities.
    Countermeasure: Make sure you update your server regularly so security patches are applied. See above notice on how to get security updates on Ubuntu. Finally, for 12.04 LTS, Ubuntu plans to provide security updates to PHP 5.3.10 until 2017. However, you should plan on migrating to latest Ubuntu LTS version before these updates end. You may find the follow commands useful:
    PHP version along w/last build+patch update:
    $ php -v
    Detailed Ubuntu PHP version table:
    $ apt-cache policy php5
    Support life from year of release:
    apt-cache show php5 | grep ^Supported
  12. Informational: Unintentional information exposure.
    Countermeasure: Turn off directory browsing:
    $sudo nano /etc/apache2/httpd.conf
    <Directory />
    # Globally remove directory browsing
       Options -Indexes
    Either reload or restart Apache after making these updates
  13. Informational: All versions of PHP prior to 5.5 have known easter eggs. For example, visiting lists PHP credits and version. While displays the PHP elephant.
    Recommendation: To turn these off, open the php.ini file and set expose_php = Off
  14. Informational: Apache readme file available at

1. Staging Server

Your production environment is a mission-critical system. We recommend pushing updates to a staging server before modifying a live, production system. Here’s the upshot: be sure to maintain regular back-ups of your production server and database(s). You want to ensure the availability of your server in the event any updates cause your system to crash.

How to Apply Security Updates and Patches

With that caveat, many of the issues concerning vulnerabilities in your system may be readily addressed by updating respective packages via:

$ sudo aptitude update
$ sudo aptitude upgrade

2. Use Cron Jobs To Automate

You’ll want to update and upgrade your server packages at least weekly. Your Systems Administrator should be able to set-up a cron job to run a bash script which executes these updates automatically.

3. Do Not Skimp on Systems Administration

Server version upgrades and config file modification may be more involved. If you do not have an experienced SysAdmin on staff, we strongly recommend that you reach out to Amazon’s AWS Support and have them address these concerns.

On visiting XYZ Mega Corp’s site, we inadvertently discovered that directory indexing was turned on (default setting for Apache installs). This “open door” indicated that there would likely be several other security issues in XYZ’s server configuration. Specifically, allowing directory indexing alluded that all of Apache’s default install parameters had been left in place and no server hardening had been attempted by XYZ Corp.