Vulnerability Management: Just Turn It Off! Part II

Our last post in the “Turn It Off!” blog series discussed some of the most common and yet unnecessary features that can make your environment more vulnerable, including JBoss JMX consoles, server banners and the Apache HTExploit.

These risks are often encountered by our Vulnerability and Exposure Research Team (VERT), even on well-defended networks and many of which have been around for quite some time. VERT leader, Lamar Bailey says all of these identified risks can be easily and promptly addressed by simply turning them off.

Our next post in the series discusses four more common vulnerabilities that could be lingering in your network and how to immediately address them:

1. PASSWORD-LESS VNC

By Jordan Powers, Security Researcher

Virtual Network Computing (VNC) is a desktop sharing system that uses the RFB (remote framebuffer) protocol to remotely control another system. VNC is platform-independent, meaning a VNC viewer on one operating system may connect to a VNC server on the same or any other operating system. Multiple clients may also connect to a VNC server at the same time.

In addition, a VNC server can ship without any required authentication and the default configuration lets users connect to a system without credentials, allowing a malicious user to gain complete control of the system. It is because of this ease of access that any VNC instance should have authentication configured with complex passwords.

Tripwire IP360 and Tripwire PureCloud customers can look for ‘VNC 3.3 and VNC 4.0 With No Authentication’ being identified in their vulnerability scans. This will detect an insecurely configured installation of VNC 3.3 or VNC 4.0.

Confirming VNC with No Authentication:

The command line tool Ncat provides a quick and easy way to port scan for the default VNC port 5900:

                       ncat -v -z <hostname or IP> 5900

Example without Authentication:

As we can see, we get NetBIOS name, which indicates authentication is not required:

                       # ncat  192.168.218.239 5900 RFB 003.008 RFB 003.003 ?` ??JPOW-85E601F426

Example with Authentication:

As we can see, we do not get NetBIOS name, which indicates authentication is required:

                       # ncat  192.168.218.239 5900 RFB 003.008 RFB 003.003 Z??p??w?<E

Enabling a Password

On Windows:

1. In the Start Menu click All Programs>RealVNC>Configure VNC Service
2. Locate the “Authentication” Tab
3. Ensure VNC Password Authentication Radio Button is chosen
4. Ensure VNC Password Authentication is configured

On Linux:

1. In System> Preferences> Remote Desktop Preferences
2. Locate the “Security” Section
3. Require the user to enter this password:

Password-less VNC: JUST TURN IT OFF!

2. RLOGIN

By Peter Melse, Security Researcher

rlogin is deprecated by many due to a lack of encryption, though it can be configured to use encryption. The default server configuration on many default installations still allows for unencrypted use and should only be enabled if absolutely necessary.

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

Confirming rlogin Status

To test for unencrypted servers, you can use netcat in the following manner:

                       $nc -p 1021 192.168.x.x 513  localuser^@remoteuser^@terminal^@9600^@

Note: You may get a permission denied message if not using a source port below 1024. The “^@” is caret notation for NUL. On keyboards in the United States, you can type this character by pressing Ctrl + @.

If this is successful, the remote server will return:

                       Password:

Mitigation instructions

On most UNIX installations, rlogin configuration is part of inetd. On Ubuntu, this file is found at /etc/inetd.conf. Comment out the following line:

                       login   stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind

Following a restart of inetd, (The example below works on Ubuntu 12.04):

                       /etc/rc0.d/K20openbsd-inetd restart

Verify, using netstat, that TCP port 513 is no longer listening.

                       Netstat –an | grep 513

If no output is returned, the service is successfully disabled.

If rlogin is available on your system, JUST TURN IT OFF!

3. HTTP TRACE

By Ian Turner, Security Researcher

While initially thought to be benign, the HTTP TRACE method allows for cross-site tracing (XST) attacks. The TRACE method returns all data sent, including HTTP headers. When initiated by a website control object, such as Flash, from within a browser, the web browser will include HTTP headers, including cookies and HTTP authentication.

The TRACE method returns these headers back to the requesting control, effectively bypassing any security mechanisms the browser may have employed to isolate that information from the website control object.

HTTP TRACE should be disabled in the web server to prevent this kind of attack. The method of disabling TRACE is web server specific, and some web servers, such as Lighttpd, avoid this altogether by not implementing TRACE in the first place.

There are two ways of disabling HTTP TRACE in Apache. Since Apache versions 1.3.34 and 2.0.55, the TraceEnable directive has been available to control availability of the HTTP TRACE method. Setting this to “off” will disable TRACE entirely:

                       TraceEnable off

The HTTP TRACE method can also be disabled using mod_rewrite. Using mod_rewrite is less efficient than the TraceEnable directive, but also has the flexibility and power of mod_rewrite.

                       RewriteEngine On
                       RewriteCond %{REQUEST_METHOD} ^TRACE
                       RewriteRule .* – [F]

Disabling HTTP TRACE is a simple but important security measure that should be taken to prevent XST attacks.

So, JUST TURN IT OFF!

4. WEAK SSL/TLS CIPHERS

By Tyler Reguly, Security Researcher

With new security threats arising on a near daily basis, we often forget about some of the older issues that we need to resolve. One of them is weak SSL/TLS Cipher Suites.

If you’re looking to become PCI compliant, this is a big deal. ASV scans require that weak cipher suites be disabled. So what are weak cipher suites? Why are they bad? How do we disable them?

SSL/TLS authenticates and encrypts communication between two hosts. This communication can be handled by a slew of cipher suites. Some of these are good, some of them not so much. It’s important to properly configure a server to ensure secure communication for everyone involved.

OpenSSL s_client provides an easy and effective way to test your servers for weak cipher suites.

SSLv2

Any SSLv2 cipher suite is bad, simply because SSLv2 is a flawed protocol. SSLv2 not supported:

                       neogeo:~ treguly$ openssl s_client -connect 192.168.2.101:443 -ssl2

                       CONNECTED(00000003)

                       140735146795872:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:429:

RC4

RC4 is a flawed encryption algorithm (cipher), meaning any cipher suite that employs RC4 is also flawed. RC4 not supported:

                       neogeo:~ treguly$ openssl s_client -connect 192.168.2.101:443 -cipher RC4

                       CONNECTED(00000003)

                       140735146795872:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741:

MD5

MD5 is used to create a message authentication code (MAC) for verification purposes. Since MD5 is broken, it shouldn’t be used. Lack of verification negatively impacts the authentication side of TLS Authentication and Encryption. MD5 not supported:

                       neogeo:~ treguly$ openssl s_client -connect 192.168.2.101:443 -cipher MD5

                       CONNECTED(00000003)

                       140735146795872:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741:

These are just a few of the tests you can run. You can experiment with various values passed to the cipher flag to determine exactly which cipher suites your product supports.

Disable weak ciphers on Apache 

Edit ssl.conf and reconfigure the following lines as needed and restart Apache.

Example:

                       SSLCipherSuite HIGH:!MD5:!RC4:!aNULL

                       SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2

Disable weak ciphers on IIS

Update the registry to disable specific SCHANNEL supported ciphers. The following registry path stores this configuration information:

                       HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

Values to Change

                       [DES 56/56]       “Enabled”=dword:00000000

                       [NULL]               “Enabled”=dword:00000000

                       [RC2 40/128]     “Enabled”=dword:00000000

                       [RC2 56/128]     “Enabled”=dword:00000000

                       [RC4 40/128]     “Enabled”=dword:00000000

                       [RC4 56/128]     “Enabled”=dword:00000000

                       [RC4 64/128]     “Enabled”=dword:00000000

Microsoft released a system update KB2868725 in November, 2013, related to disabling RC4 on systems.

When it comes to weak SSL/TSL ciphers, JUST TURN IT OFF!

Will you be turning off any of these common risky features? Look for our last post in the vulnerability management series, revealing more ways to bolster your security through this easy fix.