*The original and udated version of this post can be found here, on Jay Ball's personal blog.
This page is a collection of instructions to remove unnecessary server headers which may be reported as part of a Penetration Test performed by a security engineer or reported via automated tools. I have cataloged these remediation instructions for many technologies in one place to save the vast amounts of searching required for some of the more obscure technologies.
Each section below is be divided into a short solution and along with a longer one. The “Short Answer” gives the quick means to remove the offending header while the “Long Answer” gives more details along with alternate and (perhaps) more thorough solutions.
Why bother? In general, excessive headers are bad:
- They expose what version of software is running on the server, reducing the work an attacker needs to do before trying to attack the system.
- Headers are the same for a normal user or an attacker. So, a known long string of characters in an encrypted data stream might aid an attacker in cracking open the encrypted TLS connection of another user.
- It’s a general waste of bandwidth and processing power.
Apache Struts and equifax - real life consequences
9/14/2017 Update: The Apache Struts vulnerability discussed in this blog was found to be the flaw that led to the Equifax data breach. While hacking games are fun, it's a reminder that legitimate applications have these vulnerabilities, with real-life consequences and extremely high stakes. For more details on the Apache Struts vulnerability and a hackathon where we used it to own an application server, continue reading.
During a project working with Hydra, a Network Login Auditor, we discovered and corrected a buffer overrun issue with possible security implications that might include the auditor being attacked by the auditee.
TL;DR Attacker using Hydra or Medusa can get pwn'd by the victim website responding with remote code execution via buffer overrun exploit.
On November 6, Stephen Breen of Foxglove Security (@breenmachine) published a blog post outlining vulnerabilities in components of several Java Web Application Servers (WebSphere, JBoss, and WebLogic) as well as a popular development automation framework (Jenkins).
All of these vulnerabilities follow a similar pattern. And as worrying as that is, it's only the tip of the iceberg (as Foxglove’s post articulates).
So what can you do? This blog post will provide background and information on how to defend against vulnerabilities in Java serialization introduced by Apache Commons Collections affecting common Web App Servers such as WebSphere, JBoss, and Web Logic, as well as common applications like Jenkins.