Cold Fusion Server Security

posted onDecember 16, 2001

by hitbsecnews

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 know 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.