Securing ColdFusion and IIS

1
Securing ColdFusion and IIS

• David T Watts, CTO, Fig Leaf Software
• 28 July 2001

2
Whats 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 doesnt
  discuss everything that should be done) nor
  adequate (it doesnt cover each step in fullest
  detail).
• This presentation only covers securing the
  application server itself, and doesnt cover
  general network security issues, or physical
  security issues.

3
General security concepts

• Successful security requires a layered approach
  reliance on a firewall isnt 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 cant simply secure
  a server and be done with it.
• Security and convenience are directly opposed.
  Youll 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!

4
Current state of affairs

• There have been many successful attacks against
  IIS servers recentlysadmind worm (Fk 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.

5
What does IIS stand for?

• It
• Isnt
• Secure

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

7
Whats covered within this presentation?

• Determining the appropriate level of security
• OS configuration
• IIS configuration
• CF configuration
• CF application security issues
• Database configuration
• Security maintenance

8
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?

9
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

10
Threat manifestations

• Automated attacks (sadmind, Code Red)
• Directed attacks

11
Securing NT/2000

• General concepts
• Disk configuration
• Networking
• ACLs
• Services

12
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!

13
No escape from sadmind!
14
Disk configuration

• The server should have separate partitions for
  system, applications, and data.
• All partitions should use NTFS.

15
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
  stand-alone server, rather than as a domain
  member. It should NEVER be a domain controller!

16
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 its 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.

17
ACL interface
18
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.

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

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

21
ISAPI applications and virtual directories
22
Configuring IIS, contd

• Unused ISAPI extensions should be removed.

23
Configuring IIS, contd

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

24
Configuring IIS, contd

• 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
  youll 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.

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

26
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 wont
  prevent RDS access!

27
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 havent 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 isnt vulnerable.

28
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 (ltgt, JavaScript).
• For a guide to input filtering, look at the CERT
  site and the input filters available from the
  Developers Gallery.

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

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

31
Resources

• General information about ACLs can be found
  athttp//www.trustedsystems.com/
• Useful ACL diagnostic tools NTFileMon,
  NTRegMonhttp//www.sysinternals.com/
• Security checklists for IIS 4 and 5, as well as
  lots of other stuffhttp//www.microsoft.com/secu
  rity/http//www.microsoft.com/technet/security/
• SecurityFocus IIS security checklisthttp//www.s
  ecurityfocus.com/
• NTBugTraq OS and IIS patchlistshttp//ntbugtraq.
  ntadvice.com/
• Configuring CF to run as a different
  userhttp//www.defusion.com/articles/index.cfm?A
  rticleID89
• NSA Windows 2000 Security Recommendationshttp//
  www.nsa.gov/
• SecureIIShttp//www.eeye.com/
• Tripwirehttp//www.tripwire.com/