Vulnerability Management: Just Turn It Off! Part III

Our previous post in the ‘Just Turn It Off!’ series (Part II) explained many commonly overlooked features than can unintentionally weaken your network’s security.

We discussed the risks of an unsecured VNC, rlogin, HTTP TRACE and various other features, that fortunately, have a fairly simple fix.

In our third and final post of this series, Tripwire’s Vulnerability and Exposure Research Team (VERT) highlights four more unnecessary risks that often appear in even the most secure networks.

Our researchers give step-by-step instructions on how to immediately address these considerable risks that can be hurting the security of our environment.

1. LEGACY REMOTE DESKTOP PROTOCOL

By Craig Young, Security Researcher

Microsoft’s Remote Desktop Protocol (RDP) is an invaluable tool in both corporate and home networks. It’s lightweight enough to work with limited bandwidth, while at the same time robust enough to provide bells and whistles like remote file and device sharing.

In the corporate world, it shows its worth by providing a graphical interface to Microsoft servers that may be inaccessible or ‘headless.’ On the home network, especially with Windows Home Server, it provides a low-cost, easy to use and relatively secure means of remote access. The relative level of security is what we’ll explore here.

Over the last year, three critical vulnerabilities have been announced surrounding the remote desktop protocol, including one that is wormable. Two of the three (including the wormable CVE-2012-0002) can only be exploited without authentication when the remote desktop service is running in the less secure legacy mode.

With network level authentication (NLA) enabled, successful exploitation first requires successful authentication, thereby decimating the threat of automated attack tools. This option was released in 2006 to enhance security by requiring authentication credentials before the server initializes a full remote desktop connection.

Enabling NLA greatly reduces attack surface by limiting the functionality exposed to unauthenticated users. In other words, NLA can mitigate vulnerabilities before patches and IPS signatures exist.

Here are a few key points that can go a long way toward getting the most out of RDP while maintaining good security practices:

• Enabling inbound RDP connections on Windows XP or Windows 2003 should be avoided
• Remote Desktop with Network Level Authentication is strongly encouraged on supported platforms
• RDP access should always be limited to trusted local hosts and authenticated VPN users

Tripwire IP360 and Tripwire PureCloud customers can detect the absence of NLA on a system by watching for the “Legacy Mode Remote Desktop Protocol” vulnerability in reports.

There really is no good reason to leave legacy mode RDP enabled, so for crying out loud, JUST TURN IT OFF!

2. SNMP DEFAULT COMMUNITY STRINGS

By Darlene Hibbs, Security Researcher

When not properly secured, Simple Network Management Protocol (SNMP) can make it simple for attackers to obtain useful information about devices on your network and possibly even reconfigure them.

SNMP can run on anything from routers and switches to servers and printers and is often enabled by default with community strings: ‘public’ for read access and ‘private’ for write/management access.

The community string acts as the password for SNMP communication, so it is important to set complex and hard-to-guess community strings.

Tripwire IP360 and Tripwire PureCloud customers can look for various ‘Weak SNMP Community String ‘COMMUNITYSTRINGNAME‘ Found’ vulnerabilities, which will identify many common and easily guessed community strings beyond just ‘public’ and ‘private’.

Confirming SNMP public community string:

The command line tool snmpget provides a quick and easy way to check for community strings on devices running SNMP:

snmpget -v1 -c public host sysDescr.0

For example:

[root@dhcp-218-195 ~]# snmpget -v1 -c public 192.168.218.70 sysDescr.0 SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software IOS ™ C2950 Software (C2950-I6Q4L2-M), Version 12.1(20)EA1a, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2004 by cisco Systems, Inc. Compiled Mon 19-Apr-04 20:58 by yenanh

If the community string doesn’t exist, you will instead get:

[root@dhcp-218-195 ~]# snmpget -v 1 -c private 192.168.218.195 sysDescr.0 Timeout: No Response from 192.168.218.195.

Changing Community Strings:

As SNMP can run on a variety of systems, it may be necessary to consult the product documentation to configure or disable SNMP.

If SNMP is not necessary, it should be disabled whenever possible. If it is necessary, SNMP v3 should be used whenever possible.

On Windows:

1. In the Start Menu, click Run and type, or type in the search box: services.msc
2. Locate the SNMP Service
3. Right click on SNMP Service and click Properties
4. Go to the Security tab and check the list of Accepted community names
5. Remove any public, private or other easily guessed community strings and replace with complex community strings

On Linux:

1. open snmpd.conf in a line editor, usually /etc/snmp/snmpd.conf
2. look for lines such as:
   com2sec notConfigUser  default       public
3. Comment out any lines containing public, private or other easily guessed community strings or replace with complex community strings

SNMP default community strings? JUST TURN IT OFF!

3. OPEN/GUEST ACCESS TO SMB SHARES

By Matthew Condren, Security Researcher

SMB shares are often enabled with little to no security protecting them, allowing them to be accessed by unprivileged users. Tripwire IP360 and Tripwire PureCloud customers can ascertain the status of their shares by looking for the following vulnerabilities in their scan report:

• An SMB share permits anonymous read access
• An SMB share permits anonymous write access
• An SMB share permits anonymous full control access
• The Guest account has permission to read from an SMB share
• The Guest account has permission to write data to an SMB share

Confirming The Status Of Your Shares

The permissions on your shares can be determined using smbclient. For example, let’s assume that you have a share named ‘Share’, and you attempt to connect to it using smbclient:

# smbclient \\\\192.168.xxx.xxx\Share -U Guest% Domain=[2K3SRVRD86] OS=[Windows Server 2003 Service Pack 2] Server=[Windows Server 2003 5.2] Smb: \>

As demonstrated above, we gained access to the share using username ‘Guest’ with a blank password. You can now execute commands in order to test the level of access you have to the share.

Securing Your Shares

You can modify the permissions on an SMB share to restrict access to certain users, as well as restricting the level of access each has, such as read, write or full control.

Windows 2003 and earlier

1. Right-click on your share and choose ‘properties’ from the context menu
2. Choose the ‘sharing’ tab from the resulting dialog
3. Click the ‘Permissions’ button
4. Use the ‘Add’ and ‘Remove’ buttons to specify the privileged users
5. Choose the appropriate Allow/Deny checkboxes for each user or user group

Windows 7/2008/Vista

1. Right-click on your share and choose ‘properties’ from the context menu
2. Choose the ‘Sharing’ tab
3. Click on the ‘Share’ button
4. Add the desired users to the list by choosing then from the drop-down and clicking ‘Add’
5. Use the permission level drop-down beside each user to set permission level

Open/guest access to SMB shares? JUST TURN IT OFF!

4. TELNET

By Tyler Reguly, Technical Manager, Security Research & Development

You are probably wondering why we are discussing telnet in 2014. Short answer: It’s still out there. Slightly longer answer: people run older operating systems, which are systems that still shipped with telnet enabled by default.

Tripwire IP360 and Tripwire PureCloud customers can detect the presence of telnet on a system by watching for the “Telnet Available” vulnerability in reports.

Confirming Telnet

Telnet can be easily confirmed using the telnet command on most major operating systems. The command is simply ‘telnet <host>’ to see if you connect. Using ncat in this situation will lead to unexpected data:

neogeo:Downloads treguly$ ncat aix53 23 ??%??

Ncat has the –t option, which will allow it to negotiate telnet options (represented as ??%?? above). The output at this point will appear closer to that of telnet but with the ? and % characters still visible.

You can confirm telnet locally on RHEL5, using ‘chkconfig –list’ to find the line that reads ‘telnet: on’.

Disabling Telnet

First, let’s add the caveat that you should only disable telnet if you have another way of accessing the system. The goal here is not to render your systems inaccessible.

RHEL5 Telnet

1. Browse to /etc/xinet.d and locate the telnet file
2. Update the line ‘disabled = no’ to read ‘disabled = yes’
3. Restart xinetd (/etc/rc.d/xinetd restart)

AIX 6 Telnet

1. Browse to /etc and locate the inetd.conf file
2. Update the line that starts with ‘telnet stream’ to read ‘#telnet stream’
3. Restart inetd (refresh -s inetd)

Running telnet? JUST TURN IT OFF!