Transcript Securing ColdFusion and IIS

Securing ColdFusion and IIS
David T Watts, CTO, Fig Leaf Software
28 July 2001
What’s this presentation about?

This is an overview of what needs to be done to secure a
Windows NT/2000 server running IIS and ColdFusion
applications.

This presentation is neither complete (it doesn’t discuss
everything that should be done) nor adequate (it doesn’t
cover each step in fullest detail).

This presentation only covers securing the application
server itself, and doesn’t cover general network security
issues, or physical security issues.
General security concepts

Successful security requires a “layered” approach –
reliance on a firewall isn’t enough. Each network device
and service should be secured to the extent possible.

There is no such thing as “fully” secure.

Security is a process – you can’t simply “secure a server”
and be done with it.

Security and convenience are directly opposed. You’ll
need to determine what level of convenience you can do
without, and what level of security you need.

“Security by obscurity”, by itself, is no security at all – if
the service is publicly accessible, it will be found!
Current state of affairs

There have been many successful attacks against IIS
servers recently:
sadmind worm (“F**k USA Government”)
“Code Red” worm (“Hacked by chinese – www.worm.com”)

IIS exploit code is readily available.

Common IIS exploits depend on well-known
vulnerabilities.
What does “IIS” stand for?
It
Isn’t
Secure
Can IIS be secured?

The default installation of IIS is designed to provide many
types of functionality.

Most of this functionality is unused by most IIS users.

Production IIS installation requires removal/disabling of
unnecessary functionality.

Secure IIS installation also requires secure OS
configuration.
What’s covered within this
presentation?

Determining the appropriate level of security

OS configuration

IIS configuration

CF configuration

CF application security issues

Database configuration

Security maintenance
How much security?

Is the server a production server?

Is it connected to the public internet?

What is the value of the data it uses?

What is the value of the service it provides?

How much integration with other network services does it
need?

Can this server, if compromised, be used to compromise
more valuable assets?
What are the threats?

Attacks against the OS:
- denial-of-service
- NetBIOS

IIS vulnerabilities:
- script reading
- ISAPI vulnerabilities

CF service vulnerabilities:
- access to RDS
- access to CF Administrator
- vulnerability within API extensions

CF application vulnerabilities:
- manipulation of data within HTTP requests
- inclusion of code within HTTP requests
Threat manifestations

Automated attacks (sadmind, “Code Red”)

Directed attacks
Securing NT/2000

General concepts

Disk configuration

Networking

ACLs

Services
OS security – general concepts

Securing a Windows server for connection to the internet
requires that it be configured with as little software as
possible, and that each application have as few rights as
possible.

Default installation options for Windows, on the other
hand, are aimed at providing maximum functionality at
the expense of network security.

The server should be configured offline if possible, since it
can be attacked during the configuration process!
No escape from sadmind!
Disk configuration

The server should have separate partitions for system,
applications, and data.

All partitions should use NTFS.
Networking

The minimum necessary set of networking protocols and
services should be installed and enabled.

On servers directly exposed to the internet, SMB
functionality (NetBIOS over TCP/IP, Win2K Direct Host)
should be disabled.

If possible, the server should be configured as a standalone server, rather than as a domain member. It should
NEVER be a domain controller!
Access Control Lists (ACLs)

Every resource within Windows – files and registry keys,
for example – can be secured by editing the ACLs for the
resource.

For filesystems, ACLs are typically inherited from parent
containers, so it’s best to set ACLs on filesystem roots
before installing additional software.

Filesystem roots should have strict permissions
(Administrators, SYSTEM).

NTFS 5 (used in Win2K and NT 4 SP4+) has interfaces
that allow ACLs to be very strictly controlled.
ACL interface
More about ACLs

Registry ACLs should also be set. This can be done with
regedt32.exe.

Microsoft provides several tools for easy configuration of
ACLs based on how the server will be used.
Services

Unnecessary services should be disabled.

In NT/2K, services run by default within the SYSTEM
security context, which allows them full control over the
server, but no network rights. Because services run as
SYSTEM, if a service can be forced to run hostile code,
that code will run with those administrative rights. For
those services that can be configured to run as specific
users instead of SYSTEM, this should be done.
Configuring IIS

During the installation, no samples or documentation
should be installed.

After installation, many things need to be done to secure
IIS.

Unnecessary ISAPI applications should be removed from
all virtual servers.
ISAPI applications and virtual
directories
Configuring IIS, cont’d

Unused ISAPI extensions should be removed.
Configuring IIS, cont’d

IIS web-based administrative functionality should be
disabled, or limited to secure access (via SSL, for
example). Since all administration can be done from the
console using the MMC interface, disabling/deleting the
Administrative Web Site is usually a good idea.

Log files should be moved to somewhere other than the
system partition.

FrontPage extensions should be uninstalled if not used.

Content indexing should be disabled if not used.

Unless executables specifically need to be run, only
scripts should be allowed to run.

IIS configuration can be done at a general level, or to
individual virtual servers. When done generally, it will
apply to all virtual servers that you later create.
Configuring IIS, cont’d

Once IIS has been configured, the Metabase should be
backed up from within the IIS MMC. If you want to use
the Metabase settings on another server, you can use the
Metabase editor available from the Microsoft site.

Be aware that upgrades and service pack installations
may undo changes you made to IIS; you’ll have to redo
them.

Configuration can be automated using WSH scripts.
Sample WSH scripts can be found in the AdminSamples
directory installed by default within inetpub.

IIS 6 will replace the Metabase with a text-file
configuration.
More on IIS

Because IIS is integrated with OS security, IIS must run
within the SYSTEM security context. When IIS receives an
HTTP request, that request is run within the security
context of the connected user (if a login is required) or as
the “anonymous user”, which by default is mapped to the
account IUSR_MACHINENAME.

Because IIS logins are mapped to OS logins, Basic
Authentication should be avoided if possible, unless used
through SSL.

Additional IIS services, such as FTP and SMTP, should not
be installed if possible.

The web root directory should be located on a separate
partition.
Securing CF

Sample applications and documentation should not be
installed.

The CF service, by default, runs as SYSTEM. This should be
changed to a less-privileged user account.

RDS should be disabled if possible.

RDS and CF Administrator are both web applications.
Access to both should be controlled as strictly as possible.

To secure access to RDS, apply permissions to the file
{webroot}\main\ide.cfm. Note that removing the file
and/or the directory completely won’t prevent RDS
access!
Patching the CF API extensions

Macromedia recently released a patch for all versions of
CF prior to version 5 to address a vulnerability in the CGI
and API stubs used by the web server to communicate
with the CF service.

While details on the vulnerability haven’t been released
by Macromedia, a vulnerability within the stubs could
potentially allow retrieval of files from arbitrary locations
on the filesystem.

The vulnerability probably exists within the libraries used
by the stubs, which would explain why CF 5 isn’t
vulnerable.
CF application vulnerabilities

No data returned by the browser should be trusted!
(Form, URL, CGI, Cookie)

Use data-type checking whenever possible. (Val(),
CFQUERYPARAM, CFSTOREDPROC)

Filter input for code (<>, JavaScript).

For a guide to input filtering, look at the CERT site and the
input filters available from the Developers Gallery.
Database security

Database servers should not be accessible from the
internet. In an ideal configuration, the application server
will have separate NICs for public and private traffic.

Database logins should be used to minimize database
access rights whenever possible. These logins should be
used within application server data source configurations,
which themselves should be limited to minimum
execution rights.

Stored procedures can be used as a database interface; if
used exclusively, access can be granted only for those
procedures, preventing direct access to tables.

Access to extended stored procedures should be
minimized.
Maintaining security

Check application logs.

Check system logs.

Use read-only filesystems when possible.

Use file checksumming utilities (Tripwire) to track
changes to files.

Apply patches as necessary.
Resources

General information about ACLs can be found at:

Useful ACL diagnostic tools NTFileMon, NTRegMon:

Security checklists for IIS 4 and 5, as well as lots of other stuff:

SecurityFocus IIS security checklist:

NTBugTraq OS and IIS patchlists:

Configuring CF to run as a different user:

NSA Windows 2000 Security Recommendations:

SecureIIS:

Tripwire:
http://www.trustedsystems.com/
http://www.sysinternals.com/
http://www.microsoft.com/security/
http://www.microsoft.com/technet/security/
http://www.securityfocus.com/
http://ntbugtraq.ntadvice.com/
http://www.defusion.com/articles/index.cfm?ArticleID=89
http://www.nsa.gov/
http://www.eeye.com/
http://www.tripwire.com/