Monitoring networks for potential security violations can uncover some interesting events and surprising aspects of applications.
Base64 encoding is used by many applications to "obscure" the password when it travels across the network. Base64 encoding does not implement a cryptographic algorithm to protect sensitive information, yet is often used in many networks and end-user applications.
The Passive Vulnerability Scanner (PVS) has a rule to detect clients that are sending authentication credentials (username and password) in Base64 format:
Using the information provided by PVS, we could construct a very short Perl command to reveal the plain-text password (note: there are many methods and programs that trivially decode base64):
$ echo cGF1bDpzZWNyZXQ= | perl -MMIME::Base64 -ne 'print decode_base64($_),"\n"'
Running PVS gave me insight into which applications were using Base64 as the encoding mechanism for authentication. I found a few applications associated with the popular social networking site "Twitter" to be vulnerable:
PVS has another plugin to detect Base64 encoded passwords in any web server that may be in your environment. For example, the Basic Authentication method is implemented in most web servers and is comprised of Base64 encoded credentials. PVS plugin 4225, "HTTP Server basic Authentication Detection" provides this and will generate an alert as follows:
The above screenshot comes from a Tenable research site (hence we cannot show the IP addresses or URLs). I like the fact that this plugin provides the web server path and associated application that triggered the alert. Armed with this information, you can easily track down the offending application. This is a great example of how PVS can be used on your network to keep track of pesky applications that may be using Base64 encoding for authentication credentials.
You may also want make sure that your internal applications, such as Apache and IIS web servers, are not configured to use "Basic" authentication. The PVS alert above was generated from an Apache 2.2 web server, using the following configuration:
AuthName "Secret Files"
When you login to this particular web site you will be presented with a username and password dialog box requesting your credentials:
The Nessus vulnerability scanner provides a network-based check that will look for the presence of Basic authentication, plugin ID 34850, "Web Server Uses Basic Authentication" as seen below:
However, there is always a risk that the directory or application that is using "Basic" authentication will not be found by Nessus from the network. This can happen if the directory that is protected using this mechanism is not found in the discovery phase of the scan. To solve this problem Tenable ProfessionalFeed customers can use the compliance checking features of Nessus to audit the Web Server configuration. We provide a compliance file for Apache servers that can be found in Downloads -> Compliance and Audit Files -> Configuration Audit Policies. Then under "Tenable Configuration Audits" download the "Apache Best Practices" compliance checks. I added the following compliance check:
type : FILE_CONTENT_CHECK_NOT description : "Check if AuthType entry in httpd.conf is correctly set" file : "httpd.conf" search_locations : "/usr/local/apache/conf:/etc/httpd" regex : "^[^#]*AuthType .*" expect : "AuthType Basic"
The above compliance check will look through the Apache configuration file (that must be placed in the locations listed in the "search_locations" directive) and find any occurrences of "AuthType Basic". If this configuration exists, this test will fail and create an entry in the resulting report:
As part of a defense-in-depth strategy, you need to have many checks and balances. Relying on just one method of detection is typically not enough. With the example above, we can see how passive network analysis, network vulnerability scanning and local compliance auditing can be used in conjunction with each other to help identify risk on your network.