In one of my previous 'Turn That S#!T Off' posts, I discussed an HTTP authentication bypass pertaining to the JBoss JMX console (CVE-2010-0738). 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.
This vulnerability was disclosed two years ago, but I recently learned that a very similar flaw exists in a common Apache configuration.
byArtMack
on 08-08-201209:58 AM - last edited on 08-22-201202:31 PM by MattW
A server banner is a message sent by a server in 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 that 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. This coupled with the fact that the legalities behind activities such as banner grabbing are in a grey area, it is best to eliminate the potential risk.
There is no need to display information on which version of particular software you are running, so turn that S#!T off!
byIan
on 08-01-201207:21 AM - last edited on 08-22-201202:33 PM by MattW
It was revealed this past weekend at DEFCON that MS-CHAPv2 has been cracked. The full write-up is available but I'll give you my 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 new 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 with limited mainstream support at this time. EAP-GTC was developed by Cisco as an alternative to MS-CHAPv2 so look to see if it's an option for you.
With so many high profile database leaks we've been focusing on password security a lot lately. 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 turn that S#!T off!
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 which may be inaccessible or ‘headless’. In 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 the topic of discussion for this blog post.
Over the past few months, 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 which 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
nCircle IP360 and 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, TURN THAT S#!T OFF!
byjpowers
on 07-06-201209:09 AM - last edited on 08-22-201202:33 PM by MattW
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 – a VNC viewer on one operating system may connect to a VNC server on the same or any other operating system. Multiple clients may connect to a VNC server at the same time. It is because of this ease of access that any VNC instance should have authentication configured with complex passwords.
VNC Server ships without authentication required. This default configuration allows users to connect to a system without credentials. This could allow a malicious user to gain complete control of the system.
nCircle IP360 and PureCloud customers can look for ‘VNC 3.3 and VNC 4.0 With No Authentication’ being identified in their vulnerability scans. This will detect that the system is running 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:
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 selected. 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:
Stay tuned for additional Turn Your S#!T Off posts and remember to submit suggestions.
byPeter_Melse
on 07-05-201211:34 AM - last edited on 07-05-201212:42 PM by MattW
For Today's Turn That S#!T Off, I’m going to take a look at rlogin. rlogin is considered by many to be deprecated 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.
nCircle IP360 and 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, we can use netcat in the following manner:
bymcondren
on 07-05-201207:52 AM - last edited on 07-05-201209:03 AM by MattW
Today we are going to talk a bit about SMTP VRFY. The SMTP VRFY command can allow anonymous users to probe for valid usernames on the system. This information disclosure could assist someone with malicious intent.
nCircle IP360 and PureCloud customers can ascertain the status of the VRFY command on their SMTP servers by looking for the following vulnerability in their scan report:
1) SMTP VRFY Available
Confirming The Status Of SMTP VRFY
To find out if your SMTP server has VRFY enabled you can run a test manually. Log into your server using telnet and attempt to run the VRFY command.
As demonstrated above, we were able to use the VRFY command to establish the existence of accounts on the system. The server responds with a 250 when the VRFY is successful and a 550 when the user is not found.
Disabling SMTP VRFY
You can modify your SMTP server to disable the VRFY command. You can do this in the following way.
Postfix:
1) Edit the Postfix main.cf configuration file 2) Add or modify the VRFY configuration line to look like the following:
Disable_vrfy_command = yes
Sendmail:
1) Edit the sendmail.cf configuration file. 2) Add or modify the following line to disable vrfy:
O PrivacyOptions=novrfy
When disabled the output will be similar to the following:
In my last post, I discussed CVE-2010-0738 which describes an authentication bypass affecting certain JBoss JMX console deployments. In this post I will 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, TURN THAT S#!T OFF!
byTvanos
on 03-07-201202:03 PM - last edited on 07-05-201209:09 AM by MattW
A new day, a new security threat to be tamed. This time we're looking at SSL's weak strength ciphers. Unfortunately, these weak strength ciphers are still used on the World Wide Web today. PCI Compliance scans require that we disable these weak ciphers. How are we to do this? Let's quickly run through the steps to ensure we are not using these weak cipher keys.
Confirming weak SSLv2 ciphers
We can perform a simple check with OpenSSL to test if our web servers are allowing these weak ciphers through, assuming that you are using port 443 for your https connections.
Using an editor (ex. vi) to edit your /etc/httpd/config.d/ssl.conf (or wherever your ssl.conf resides)
~#vi /etc/httpd/config.d/ssl.conf
Locate SSLCipherSuite and set: SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT
# SSL Cipher Suite: # List the ciphers that the client is premitted to negotiate. # See the mod_ssl documentation for a complete list. SSLProtocolALL+SSLv3+TLSv1 SSLCipherSuiteALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT
Restart Apache
~#service httpd restart Stopping httpd [ OK ] Starting httpd [ OK ]
Disable weak ciphers on IIS
To reject weak SSL ciphers in IIS we will make the following registry key changes in regedit:
byDarlene
on 02-27-201210:18 AM - last edited on 07-05-201209:09 AM by MattW
SNMP, Simple Network Management Protocol, when not properly secured 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 default 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.
nCircle IP360 and PureCloud customers can look for various 'Weak SNMP Community String 'COMMUNITYSTRINGNAME' Found' vulnerabilities. This 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
Ex:
[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 (tm) 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
bymcondren
on 02-24-201211:56 AM - last edited on 07-05-201209:10 AM by MattW
Today we are going to talk a bit about SMB shares. Shares are often enabled with little to no security protecting them, allowing them to be accessed by unprivileged users.
nCircle IP360 and PureCloud customers can ascertain the status of their shares by looking for the following vulnerabilities in their scan report:
1) An SMB share permits anonymous read access
2) An SMB share permits anonymous write access
3) An SMB share permits anonymous full control access.
4) The Guest account has permission to read from an SMB share
5) 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 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 (ie. Read, write, or full control).
Windows 2003 and earlier
1) Right-click on your share and select ‘properties’ from the context menu. 2) Select 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) Select the appropriate Allow/Deny checkboxes for each user or user group.
Windows 7/2008/Vista
1) Right-click on your share and select ‘properties’ from the context menu. 2) Select the ‘Sharing’ tab. 3) Click on the ‘Share’ button. 4) Add the desired users to the list by selecting then from the drop-down and clicking ‘Add’. 5) Use the permission level drop-down beside each user to select permission level.
bytreguly
on 02-23-201205:37 AM - last edited on 07-05-201209:10 AM by MattW
Not only will I tell you how to Turn That S#!T Off but today, for one day only (or, since this is the internet, forever), I will also demonstrate my psychic abilities. When you first read the title, you instantly questioned why we are discussing telnet in 2012. Short answer: it’s still out there. Slightly longer answer: people run older operating systems, systems that still shipped with telnet enabled by default.
nCircle IP360 and 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>’ and you can 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)
Stay tuned this week for additional Turn Your S#!T Off posts and remember to submit suggestions for a post or two.
bytreguly
on 02-17-201202:46 PM - last edited on 07-05-201209:10 AM by MattW
Turn That S#!T Off - SSLv2 Another day, another protocol that needs to be turned off. This time we're looking at SSLv2, that wonderful protocol that even the PCI Security Standards Council has deemed unfit for human consumption. It's surprising to hear, but this insecure protocol is still in use. So let's take a minute and quickly discuss how you can turn that S#!T off.
nCircle IP360 and PureCloud customers will see SSLv2 reported as "SSLv2 Enabled" and should, if possible, make every effort to remedy the situation as quickly as possible. The important thing to keep in mind here is that HTTP isn't the only protocol tunneled over SSL; people often forget about IMAP, POP3 and SMTP (as just a few other examples).
Confirming SSLv2
SSLv2 can be easily confirmed using OpenSSL (specifically openssl s_client) which is available for most modern operating systems.
The above message indicates that you were unable to connect to the server using SSLv2. A successful connection would have returned the certificate, information about the SSL session, and a prompt where you could enter data to send.
Disabling SSLv2
There are plenty of servers with various configuration options, so you're best resource will be the documentation for your product. As with SSHv1, for some appliances you may have to contact the vendor for assistance. I'm going to discuss the most popular two options for SSL tunneled traffic, Apache httpd and Microsoft IIS.
Apache httpd
1) Locate the SSLProtocol line (likely: /etc/apache2/mods-available/ssl.conf) 2) Update the line to read one of the following ways:
SSLProtocol ALL -SSLv2 SSLProtocol -ALL +SSLv3 +TLSv1
1) Open RegEdit and browse to: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server 2) Right Click and create a new DWORD Value named Enabled 3) Ensure the value is set to 0x00000000 (0) 4) Restart IIS
A few simple steps and, once again, another headache is gone. In the end this is just a drop in the bucket on your way to achieving a more secure infrastructure, but every drop counts. Next week we'll take a look at few more items that rank high on my "turn that S#!T off" list. If you have any requests, please feel free to let us know and we'll take a look and tell you how to turn your SH#!T off.
bytreguly
on 02-16-201201:20 PM - last edited on 07-05-201209:10 AM by MattW
When I first joined VERT, I had little insight into enterprise networks. I'd spent several years in a helpdesk role at a college and then worked as a sys admin for an SMB. While I still don't work directly with enterprise networks, I do get to see reports that customers submit and findings that they question. It's often a surprise for me, and for the customer, to see what is running on their network.
In recent years the attack focus has shifted to the client, with the browser and the office suite surpassing the telnet daemon and web server as the most attractive targets on a network. In my opinion, this means that certain network-based issues are often overlooked and I wanted to highlight my list of "WTF Issues" that security teams should resolve as quickly as possible. So enough with the intro, on to the first post in VERT's new "Turn That S#!T Off" Series.
SSHv1 Enabled
SSHv1 has had known serious issues for quite a while and the common message from the security community has always been, "Turn that S#!T off". If I had a wishlist of things I'd like to see disappear on a network, this would be near the top. nCircle's IP360 and PureCloud platforms will identify this as "SSHv1 Protocol Available"
Confirming SSHv1 Support Customers are often surprised by this one because vendors tell them that SSHv1 isn't supported but IP360 tells them it is. You can easily confirm this yourself with ncat (part of nmap):
The above server will only support SSHv2 and the first 5 characters will tell you:
SSH-2.0 - Only SSHv2 is supported. SSH-1.99 - SSHv2 and SSHv1 are both supported. SSH-1.5 - Only SSHv1 is supported.
Note that the first 5 characters will always be SSH-1 when SSHv1 is supported.
Disabling SSHv1 Assuming you're running OpenSSH, disabling SSHv1 is very simple:
1) Edit your sshd_config file (generally in /etc or /etc/ssh). 2) Locate the "Protocol" line (e.g. Protocol 2,1). 3) Update the line to read "Protocol 2" 4) Restart sshd
If you're dealing with an appliance, you may want to poke your vendor. They may have a patch out or a method of reconfiguring the appliance to disable SSHv1.
That's it, a simple little fix to a problem that simply shouldn't exist today. Tomorrow we'll discuss something else that's been stuck in my craw for a while, when I explain how to turn that S#!T off for SSLv2.
