In today’s security environment, organizations across all industries face the strong possibility of a security breach. It does not matter if you have a headcount of three or 50,000 employees, and it does not matter if your revenues range in the thousands or billions; you are a target. Every network – no matter how large or how small – is ripe for being targeted in an attack.
Because the likelihood of attack is at an all-time high, you must make sure you are prepared; however, no defense is perfect. Attackers will look at all points of entry and get in, whether by exploiting systems, social engineering or by riding in on infected mass storage devices.
“It doesn’t matter if you’re a multi-billion dollar financial services company in London, or a small accounting firm in Tulsa; the threat environment is the same,” said Lamar Bailey, leader of Tripwire’s Vulnerability and Exposures Research Team (VERT).
“After you setup the common defenses like IPS, AV and firewalls, it is time to make your own network a hostile environment for likely attackers. In fact, your job is to make your environment so hostile to hackers that they give up and go look for easier prey.”
So, how do you move beyond the basic defenses and make your environment more hostile to attackers? This article series will show you how to create an environment that’s harder for cyber criminals to attack by removing some of the low hanging fruit attackers use to gain information and access your resources.
“JUST TURN IT OFF” is based on a series of short articles written by current and former VERT members, based on common and yet unnecessary security risks that the team routinely finds on even well-defended networks, many of which have been around for quite some time.
“All of these identified risks could be immediately addressed by doing exactly what these articles suggest, which is simply to turn them off,” said Bailey. “We’ve identified twelve different vulnerabilities that are easy to address and present considerable risk to your security environment if left unaddressed.”
So, sit back and let the VERT team explain to you twelve easy ways to bolster your security by addressing some of the most common vulnerabilities:
1. Unprotected JBoss JMX Console
By Craig Young, Security Researcher
There has been much discussion regarding CVE-2010-0738, which describes an authentication bypass affecting certain JBoss JMX console deployments. Let’s discuss the underlying vulnerability, how to mitigate the threat, and most importantly, how an unprotected JMX console can lead to a network-wide compromise – or worse.
At a high level, the JMX console is like a window into the JBoss microkernel which (among other things) allows for management and deployment of JBoss applications. It’s important to point out that the JMX console default configuration shipped with most JBoss packages is just a skeleton configuration that doesn’t enable any authentication requirements. In order to enable authentication, one must uncomment some lines in the default configuration as specified in various getting started guides.
The problem described in this CVE is that the sample security constraints provided for JMX console explicitly specify that the POST and GET HTTP methods require authentication (although one might infer that this means POST and GET HTTP methods require authentication and other HTTP methods are forbidden, the server may actually respond to other requests with an error while simultaneously allowing the request to be processed).
The advised remedy for this issue is to remove the <http-method> tags from the security constraint as documented by Red Hat. Using the updated security constraints, the server will require authentication for all HTTP methods.
Regardless of what version or flavor of JBoss you use, it’s crucial that access to the JMX console is properly restricted. This means password protection (applied to all methods), as well as conventional firewalling to limit access to the JMX console port to only trusted networks.
Automated attack tools exploiting this authentication bypass are just as effective on systems without password protection as they are against systems vulnerable to the authentication bypass. Once an attacker (or an attack tool) has gained access to the JMX console, the sky is the limit. It is trivial to use jboss.system:MainDeployer to deploy malicious applications, thereby achieving arbitrary code execution within the context of the application server.
Alternatively, an attacker with a little more imagination could redeploy existing JBoss applications with malicious code, thereby using your JBoss application to compromise the clients accessing it.
There is absolutely no reason to justify having an unprotected JBoss JMX console so, for crying out loud, JUST TURN IT OFF!
2. Apache .htaccess Limit Tag
By Craig Young, Security Researcher
In the first section, we talked about the HTTP authentication bypass pertaining to the JBoss JMX console (CVE-2010-0738). As discussed, this vulnerability hinges on a recommended/default policy that applies security constraints only to the specific HTTP methods GET and POST. This has the unintended consequence that other methods, such as HEAD will be passed off to the GET handler, even without authentication.
While this vulnerability was disclosed two years ago, a very similar flaw exists in a common Apache configuration. While attending Black Hat, we had the opportunity to converse with Matias Katz, an Argentinian penetration tester and co-author of the HTExploit tool demonstrated in the Black Hat Arsenal.
HTExploit demonstrates how it is possible to use an unexpected HTTP method to access PHP scripts that were intended to be password protected. The tool preys on poorly configured htaccess files like the one below, which explicitly states the specific HTTP methods to limit:
AuthName “Section Name”
As in the case of the JBoss JMX console authentication bypass, an attacker can bypass the htaccess authentication requirement by using a method other than GET. Even if the htaccess file has been configured to restrict access for all HTTP methods specified in the RFC, it should be noted that an attacker can also use gibberish in place of a valid method, and Apache will allow PHP to process the request as if it were authenticated.
The quick fix for this is to remove the ‘Limit’ tag so that Apache will enforce restrictions on all requests. Apache admins should beware – if you use a ‘limit’ section in your config, JUST TURN IT OFF!
3. Server Banners
By Arthur Mackiewicz, Former VERT Member
A server banner is a message sent by a server as a greeting with information about itself. FTP servers, or web servers, will have information, such as which software they are running and which version of that software is currently running.While disabling server headers doesn’t actually make the server more secure, it is a good way to ensure that the server doesn’t become the path of least resistance.
Advertising the specifications of the service(s) that are running on a server is not the best idea. Considering that enumeration is one of the initial stages of an attack, making this step more difficult for potential attackers assists with the overall security of your network.
Although banner grabbing may not be used as often as it was in the past due to the availability of automated tools, such as Nmap, the possibility of manual attempts still exists. Coupled with the fact that the legalities behind activities, such as banner grabbing, are a grey area, it’s best to eliminate the potential risk.
There is no need to display information on which version of particular software you are running, so JUST TURN IT OFF!
By Ian Turner, Security Researcher
It was revealed at DEFCON back in July 2012 that MS-CHAPv2 had been cracked. While the CloudCracker blog and others provided full analysis shortly after the news broke, here’s a quick summary: the MS-CHAPv2 handshake is little more than cryptographic jazz hands surrounding what is essentially a single DES encryption. Additionally, there is now a publicly available method for cracking this in less than a day.
The result of this crack is the MD4 hash of the user’s password. The username was already transmitted in the clear. With this information, it is possible to decrypt the captured network traffic and all future network traffic for this user when using the same password. The username and password hash can also be used to log into any service that uses MS-CHAPv2 for its authentication.
MS-CHAPv2 is used in two widely-available protocols: PPTP and WPA2 Enterprise. How can we protect ourselves in light of this crack? Stop using MS-CHAPv2. While other authentication methods may be available for PPTP, the better solution would be switching to another VPN technology, such as IPsec or OpenVPN.
With WPA2 Enterprise, the alternatives to MS-CHAPv2 are more varied, but there is limited mainstream support at this time. EAP-GTC was developed by Cisco as an alternative to MS-CHAPv2, so you can also explore whether that is an option that will work for you.
With so many high-profile database leaks, we’ve been increasingly focusing on password security. While this MS-CHAPv2 crack reveals the password hash and not the password itself, it still allows unauthorized access to those systems. The attacker doesn’t need to know the user’s password to gain access when MS-CHAPv2 is in use.
Good alternatives to MS-CHAPv2 exist, so make sure to JUST TURN IT OFF!
Stay tuned for our next blog post in this vulnerability management series, where security researchers will discuss other common vulnerabilities with this simple fix.
- The Five Stages of Vulnerability Management
- How To Make Vulnerability Management Relevant…Again
- So You Like Pain and Vulnerability Management?
- The Buyer’s Guide to Vulnerability Management Solutions
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].
Title image courtesy of ShutterStock