Tenable Blog

The Trouble with Remote Access

Remote access protocols are certainly one of the long-standing topics discussed when it comes to information security. Most security practitioners have had to deal with the threats and risks posed by the wide range of protocols used to remotely manage and access systems, including Telnet, SSH, RDP, and even third-party providers such as GoToMyPC. Convenience is heavily weighed against security, as users and administrators require access to the systems, yet security in the forms of authentication and encryption seemingly "get in the way." This debate has come up in my career more times than I care to remember. When I first set out to help make systems more secure, one of the first actions I proposed was to remove Telnet from all of my UNIX (Solaris and Linux at the time) systems. Turns out it was a valuable lesson for me as I learned that while technically not so challenging, convincing 25 or more developers that they had to use an SSH client rather than the built-in Telnet utility was the most challenging aspect of that project.

The same debate occurred later in my career when I was tasked with helping the newly-created Windows systems administrators group secure their brand-new Windows domain environment. I had a similar conversation about Microsoft Terminal Services, which uses the RDP (Remote Desktop Protocol). At the time, in the default configuration, an attacker could perform MiTM attacks to obtain the username and password, in addition to logging the keystrokes sent to the systems being managed. Again, technically there was an easy fix (change some settings on the servers, and use a compatible client on the management systems). However, the real challenge was persuading the administrators to make the switch, as they had always just used the default configuration and, by their own account, "nothing bad ever happened." In this case, I had to use a demo and perform an attack, with permission, of course, against an administrator. Once they saw it, the progression to a properly-configured and more secure RDP implementation was underway immediately.

Tenable has added a compliance check for Windows which allows users to compare file hashes using a .audit script (Windows compliance checks v2.0.32 or later). By default, MD5 is used to compare two versions of a file, however, users can compare hashes generated with SHA1, SHA256, SHA384, SHA512, or RIPEMD160 algorithms.

Exporting To CSV

Nessus now supports the ability to export your reports into a comma-delimited file format (CSV). Using this export format, you can import the results into your favorite spreadsheet program. Tenable recommends using the following software:

• Microsoft Excel 2010 or later
• Apple iWork Numbers

To export a CSV-formatted report, select any of your existing Nessus results, click "Download Report," and then choose "CSV" as shown below.

Select the "CSV" Reporting Format

Covering All Your Bases

Internet-facing servers are a popular attack target: They are accessible to everyone on the Internet and can easily be probed for vulnerabilities. Based on exposure alone, Internet-facing servers present a higher risk of becoming compromised. This risk needs to be mitigated if organizations must provide access to services such as web, mail, and VPN connectivity. It is therefore important that these servers are regularly assessed for potential vulnerabilities (and more important that something is done to remediate the vulnerabilities). This blog entry provides guidance for some basic security issues which are important to monitor on Internet-facing servers, such as:

1. Maintaining Patches - It is important to keep up-to-date with patches in general, and with systems that are exposed to the Internet, fixing both local and remote vulnerabilities are particularly important. For example, a web server may contain a vulnerability which allows an attacker to gain a shell with the privileges of the running user (e.g., www-data). If local vulnerabilities are present, the web server vulnerability can quickly lead to the attacker gaining root-level privileges. With this level of access, attackers have a much better chance to cover their tracks and hide their presence within the system. Therefore, ensuring all available security patches are installed on your systems is important.

2. Easily Exploitable Web Application Vulnerabilities - If you've ever monitored the logs of an Internet-facing web server, you know attacks against applications are frequent. Application testing involves many different processes and techniques, but you don't want to give attackers any low-hanging fruit. It is important to test your applications before they are put in production, but also continue to monitor for vulnerabilities in production. Several automated tools in use by attackers exploit flaws, such as SQL injection, on a regular basis. Once the application is on your production system, it is important to regularly assess it to stay ahead of the curve and remediate the vulnerabilities before attackers get to them.

3. Exposed Services - Internet-facing servers ideally offer a limited number of services, since they do not need to support a wide range of services that an internal development server would offer. This makes it easier to scan and identify vulnerabilities and detect any new services which may crop up. Firewalls are often deployed to provide an extra layer of protection for systems exposed to the Internet and ensure that only required services are permitted. Scanning these hosts on a regular basis will quickly identify any new services that are running or mistakes made in firewall configuration which may unintentionally expose an internal service or server.

Compliance Auditing with PowerShell

Microsoft's PowerShell framework has been part of their product line for quite some time. In recent years, it has played a major role in new operating system versions (such as Window 7 and Windows Server 2008) thanks to its inclusion in common engineering criteria. All future Microsoft server products will have PowerShell support integrated in them by default. This means Microsoft products will benefit from a single management interface, rather than a mixed usage of the registry, WMI, or other system files/utilities.

For those unfamiliar with PowerShell, it's a command-line shell meant to perform administrative tasks using cmdlets. Cmdlets are purpose-built commands designed to accomplish specific tasks for reading registry keys, files, wmi-objects, starting and stopping Windows services, and a host of other tasks. A wide range of cmdlets and their usage are documented on Microsoft's website.

The ability to run PowerShell cmdlets remotely opens up interesting possibilities from a compliance perspective. For example, it's now possible to read a file, apply several different filters, and determine compliance. You can also run a cmdlet and let the user review the output, then tailor the output as needed. Tenable recently added an AUDIT_POWERSHELL check to Windows compliance checks which allows users to do just that, right from an .audit file. Below is the basic syntax:

We are pleased to announce the release of Nessus 5 On Demand Training. Highlights of the new self-paced training course include:

Cross referencing the results of your vulnerability scans with the list of public exploits helps identify likely targets for authorized penetration testing teams. Removing these vulnerabilities significantly raises the value of a penetration test since the team will have to work much harder to find issues that aren’t found through automation. There are many subtle issues to consider when correlating available exploits with vulnerabilities. In this blog entry, we’ll highlight these issues by considering exploit correlation with attacks available from the Metasploit project, Core, and Immunity with the results of a very large Nessus scan of several thousand web servers.

New Features

Nessus version 5.0 introduces key features and improvements, separated into the four major phases of the vulnerability scanning process:

1. Installation and management (for enhanced usability)
2. Scan policy creation and design (for improved effectiveness)
3. Scan execution (for improved efficiency)
4. Report customization and creation (for improved communication with all parts of the organization).

We've created a video showcasing the new features in Nessus 5.0 listed above:

Below you can find a more detailed list of the new features added to Nessus 5.0:

Penetration tests are typically a point-in-time exercise to determine if a remote adversary or malicious insider can compromise systems that contain sensitive data. Most organizations do not conduct penetration tests on a daily basis. Instead they schedule them annually, quarterly, or in some cases monthly. Penetration tests procured on a consulting engagement are often limited to key systems and assets rather than the entire network of systems. This diminishes the value of the penetration test as the results quickly become outdated and may not be relevant to new systems or recent network changes. However, by correlating the availability of exploits with a continuous monitoring program to identify vulnerabilities, an organization can have a better idea of how “exploitable” they are on a real-time basis.

The video below is part 3 in our series of the top ten things you didn't know about Nessus and covers Nessus plugins that provide outstanding capabilities beyond detecting traditional vulnerabilities:

Further Reading:

• Tip: Finding Open SMB File Shares