Cold Fusion Server Security
Cold Fusion is a server side scripting language used to generate dynamic web pages. Because it is a commercial tool, it is little understood by those who do not have direct access to a Cold Fusion Server. Thus, Cold Fusion benefits by some security through obscurity. Throughout its lifetime Cold Fusion seems to have been of little interest to the computer security community. I know of no known exploits that can be run against Cold Fusion. There are, however, several exploitable areas of Cold Fusion that could allow an unauthorized user access to a Cold Fusion server. Many of the vulnerability issues faced by a Cold Fusion server are independent of any Cold Fusion service. Initially only released for Microsoft server platforms, Cold Fusion suffers from every vulnerability that affects its host system. Although there is a Linux version of Cold Fusion server, it is notoriously difficult to install and negates many of the advantages offered by Cold Fusion. It is extremely rare to find Cold Fusion running on anything other than an NT/2000 server. The largest Cold Fusion vulnerability is its general reliance on Microsoft SQL server for its database backend. If misconfigured, or poorly configured, SQL server could offer a gaping hole into a Cold Fusion server. Cold Fusion most often relies on an ODBC (Open Database Connectivity) connection via port 1433 to communicate with a SQL Server backend. Although alternative methods exist, this is the most common configuration. Microsoft SQL connections can be exploited in a number of ways, but the most common vulnerability is the default blank 'sa' account password (which gives root privileges on the database). The easiest way to explore a remote Microsoft SQL server is to download the client tools from Microsoft. Enterprise Manager and Query Analyzer can both be downloaded for free and offer a wealth of graphical and command line options to connect to a remote host with.
Cold Fusion also offers several other options for remote connections that can possibly be used to compromise server security. The first of these is the browser based server configuration feature found on all servers by default at http://serverip/cfide/administrator/index.cfm, although astute administrators will often move this page to a different location. The browser based configuration tool is the only way to configure certain options on a Cold Fusion server, so it will be present in some location on any Cold Fusion server. This page presents a default login screen that requests only a password for authentication.
Often there is no password specified by the administrator at install time and remote access is possible simply by clicking the 'Password' button. Once logged in to the browser configuration tool several possible configuration options are presented, including choice of mail relay server to be used by Cold Fusion, ODBC data settings (including ODBC usernames), debugging options (useful for examining SQL queries used for the server), logging settings, and even security settings. If access is gained to the Cold Fusion web based administration pages it is possible to change the Cold Fusion RDS (Remote Development Service - described below) password. Basically the single password to the Cold Fusion web based administration pages is the whole enchilada as far as Cold Fusion is concerned, if you can crack this password you can compromise the entire server.
Cold Fusion RDS is a remote administration tool that can be accessed using the Cold Fusion Studio program. RDS operates over port 80 and allows for remote development on a Cold Fusion server. RDS security is controlled by username and password. RDS is a developers dream because it allows for remote file manipulation and transfer, but is a security nightmare because it allows for remote manipulation of ANY file on the target server.
In order to use a remote RDS connection you must have Cold Fusion Studio installed, but last time I checked you could download an evaluation copy for free for a month (not to mention you can probably get a warez or cracked copy fairly easily). To connect to a remote server in Studio simply click on the globe tab at the bottom right hand corner of Studio, then right click the RDS icon at the top of the resulting pane and select 'Add RDS Server'. You are required to enter a username and password on the target server to authenticate, but you can try as many times as you like to connect. Because Cold Fusion uses HTTP traffic for authentication it is very impractical to lock RDS to repeated exploit attempts.
Actually downloading .cfm files does not present the wealth of information that .php files might. Since Cold Fusion uses ODBC it does not require usernames and passwords to be hard coded into pages. Unless a developer is foolish enough to hard code passwords into their pages, very little useful information would be derived from stolen CFM pages (although it is not uncommon in cases of simple authentication for a developer to simply hard code a password into a page rather than database that information).
The other major compromise avenue against a Cold Fusion server would be an exploit of poorly coded URL or form variables. Cold Fusion handles variables in much the same way as PHP or ASP. Application, session, and page variables are all set and manipulated in pretty much the same way. URL and form variables are especially easy to manage in Cold Fusion and sloppy coding could allow exploit of these variables. Cold Fusion, however, is extremely adept with escaping variables from SQL statements so including bad SQL commands in a variable will do nothing but throw an error or add poor data to a database server. Cold Fusion errors are generally of little value to anyone other than a developer and may prove useless from a security exploitation standpoint.