Trusted OS and the recent Apache site hack paper

[Jeffrey W. Thompson]

The following is a paper I have written on the recently published Apache
server hack.  I believe this is as good an example as any of why Trusted
OS is extremely useful solving real world problems and just for people
who are in the government or "security" crazy.  I'm sending this to the
list as I assume that people here would appreciate such a discussion,
and for members who may not be quite sure what Trusted OS is for or why
they might want to use it for anything other than a curiosity. It is my
hope that as more mainstream Trusted OS's are released that people will
begin to use this technology to secure themselves from attack.

I look forward to hearing any feedback.

Thanks,

Jeff

--Paper--
Trusted OS and the Apache web site attack
Jeff Thompson
Software Evangelist and Visionary
Argus Systems Group, Inc.

Introduction
This paper is a response to the recently disseminated paper on the
Apache.com web server hack by {} and Hardbeat.  As their paper states,
it does not uncover any new vulnerabilities but serves as an excellent
example of a web based penetration.  This is an excellent opportunity to
demonstrate how a Trusted Operating System (TOS) could have been used to
prevent this attack without changing the misconfigured aspects of the
system.  It should be noted that this paper addresses this attack
specifically, and that TOS could have been also used to protect the
system against more direct attacks (buffer overflows, etc).

The Attack
The Problem: Inserting Scripts
The first phase of the attack was to locate a means of inserting scripts
into the web server.  The attackers accomplished this by discovering
that there was a mapping from the web server pages into a public world
write-able ftp directory.  The attackers then created a PHP based script
that allowed the arbitrary execution of commands on the system.

The Solution: Application Isolation and Network Security
This was simply a configuration issue on the web server where the
ability to create pages for the web server was allowed via ftp by an
anonymous user.  These types of misconfigurations are not uncommon and
are part of a larger problem facing web site security.  This class of
problem is the ability to insert or modify content of a site.  Under
standard systems there are several ways to do this.  The first is to
enter the system as a user who can create content in the web server's
content paths.  This was done in the Apache site hack as an anonymous
user.  Other methods are to attack the server and become root so that
all files on the system can be modified.  This is typically not
difficult for a patient attacker as evidenced by the Apache site hack.

With TOS systems it is easy to set up a web architecture that will never
allow an external attacker to modify content on the web server.  TOS
implements a concept known as Mandatory Access Controls (MAC) which are
simply access control mechanisms that do not use the user id of the
process in determining access. Commonly (though not always) these access
control mechanisms are implemented using a hierarchical classification
and a set of compartments.  These security levels have specific
relationships with each other
that allow for powerful security architectures to be set up.

A familiar set of hierarchical components (classifications) is:

Top Secret
Secret
Confidential
Unclassified
System Low

A hierarchical component is said to "dominate" all components listed
below it.  In order for a subject (process) to read from an object (a
file), it's classification must "dominate" that of the file.  For
example a process at Confidential can read a file at Unclassified, but
it cannot read a file at Secret.  In order for a process to write to a
file (really read & write) it must be at exactly the same classification
as the file.  The previous Confidential process can only write to a
Confidential file.

Some example compartments are:

Web_Server
Internal
External
Web_Content
Web_CGI
FTP_Public
SQL

Compartments operate under a different principal than classifications.
A security label can have more than one compartment in it.  A set of
compartments is said to "dominate" another set if it contains all of the
compartments of the set it is being tested against.  In order for a
subject (process) to read from an object (a file) its set of
compartments must dominate those of the file.  For example a process
with the Web_Server and Web_Content compartments could read a file that
had Web_Server and Web_Content compartments, or a file that only had
Web_Server or Web_Content.  In order for a process to write to a file
(really counts as read & write) it must have exactly the same
compartments as the file.  The previous Web_Server/Web_Content process
can only write to files that have Web_Server/Web_Content compartments
(and no other compartments).

To put all of this together, a MAC check will look at both the
hierarchical and compartment components.  Therefore a process running
with the security level "Confidential Web_Server Web_Content" will be
able to read files that are at Confidental and below and also only have
a combination of compartments Web_Server and Web_Content.  It should be
noted that a Confidential file is also readable as the process'
compartments dominate an empty set of compartments.

TOSs also implement this concept of security at the network level.  All
network connections coming into a TOS will be labeled with a security
level that is configured by an administrator.  In order for an external
client to be able to communicate with a TOS network service the security
levels set on the client connection must be equal to or dominated by the
security level of the service.  A TOS will also allow for additional
rules to be placed on interfaces and hosts that specify what ranges of
security information can be sent out.  For example only processes with
an "Internal" compartment would be allowed to communicate over a
back-end networking interface, and processes with a "Internet"
compartment would only be able to communicate over the public network
interface.  These types of rules allow for a secure architecture to be
set up fairly quickly.

In order to secure web page content from attack, the site administrator
simply places the web server at one security level say "Confidential
Web_Server Web_Content External".  The web site's content is then placed
at "Unclassified Web_Content".  This allows the web server to read all
of the pages and cgi-scripts and serve them, but not to modify them.  A
network rule is set up so that all connections to the web server will be
labeled at "Confidential Web_Server Web_Content" and thus able to speak
with the web server.  Any successful attacks to the web server will
result in access at the "Confidential Web_Server Web_Content External"
level, which will not allow modification of any web server content files
or in fact any other files on the system (as none would be set to this
level).  Essentially this attacker would have access to the system, but
not the ability to modify anything.

The ftp server on this system would be run at "Confidential FTP_Public
External".  A
network rule would be set up for the server so that all connections
would be at this level.
Thus even if the web server had portions of its document paths in the
ftp directories the
web server would not see these and thus could not serve them.

The Problem: Shell Access
The next phase of the attack was to place a remotely accessible shell
onto the system.  These are called "bindshells" after the fact that they
call the bind system call to attach to the network.  Once in place, an
attacker can simply telnet to the network port on the system where the
bindshell is listening and gain access to the system at the same level
as the bindshell.

The Solution: Application Isolation
In order to progress with a discussion of TOS, let us assume that the
administrator did not place the ftp server in a separate compartment,
but had its files readable by the web server.  We could also assume that
the attacker may have found a flaw in a back-end CGI program and
obtained a way to place programs onto the system.  Once a bindshell was
placed onto the system it could only be executed at the same level as
the web server.  This means that the bindshell would be running as
"nobody" with a security level of "Confidential Web_Server Web_Client
External".  As no other files on the system will have a security level
set to this value, the user will not be able to modify a single file on
the system.  There is no way for the user to escape this security
level.  I will explain why this is later in the document.

The Problem: MySQL application exploitation
The next phase of the attack was to go after the MySQL database server.
Part of this attack was to allow connections to the MySQL server from
external clients.  There is no way to prevent this on a standard
operating system.

The Solution: Network Security Levels and Secured CGI Back-End
In order to solve this problem, we are required to extend our
architecture slightly.  One version of TOS known as PitBull provides
extensions to the Apache web server and Netscape Enterprise Server that
allow running CGI programs to be placed in their own isolated
compartments.  By putting this functionality in place, an administrator
can allow all CGI programs to run in a totally isolated compartment
insulating the system from any breaks.  On the discussed system, these
CGI programs would be run at "Confidential Web_CGI".  If a breach like
the one on the Apache site took place and a bindshell was put on the
system, the attacker would not be able to even connect to the
bindshell.  In other words, any attack would not result in additional
network connectivity.  The reason for this is that the CGI programs do
not have the "External" compartment that is required for network access
on the public network interface card.  Additionally, the attacker could
not set up a network redirector to the MySQL application because of the
previous network restrictions. Let's assume that the attacker did gain
access to the MySQL server.  The MySQL server would have been set up in
its own isolated security level at "Confidential SQL".   All system
files and user files would be set to System Low.  This means that the
MySQL server could not modify any files on the system except for its
own.

Why Can't An Attacker Escape His Security Level?
As the more cynical of you have probably been wondering, couldn't a good
attacker just find a way to circumvent his security level, or become
root, or some special user?  The answer is of course no.  The reason is
that TOSs implement a concept known as least privilege.  Least privilege
throws away root as a special user, and instead implements a privilege
system that gives rights to an application based on what it specifically
needs to do.  For example, if an application needs to bind to a
privileged port (such as a web server) it is simply given the "bind to
privileged port" privilege.  On a standard operating system, the
application must be run as root and thus given complete and total access
to the system.  On a TOS, it only gets the ability to bind to the
privileged port and nothing else.  No complete access to the file
system, no becoming any user it wants to, etc..  Administrators are able
to run administrative commands (they have privilege and can circumvent
security).  These commands are easily isolated from an attacker by
placing them at a "Top Secret Internal" security level.  The only way to
get on the system at this level is to connect from an "Internal"
connection and as an administrator.  For example, a modified version of
the secure shell server (sshd) is available that will allow
administrators to connect to the system and perform security relevant
administration.

Wrapping It Up
This pretty much stops all of the attacks mentioned in the Apache web
site defacement paper without fixing a single application
misconfiguration error.  While an administrator should clearly configure
these software packages correctly, a TOS allows an administrator to
place reliance in the operating systems ability to protect itself from
attack rather than every single application's ability to protect the
system.  As anyone who follows security to any extent knows, relying on
application security is simply not working.


Who Makes This Stuff?
There are currently two major commercial vendors of Trusted Operating
Systems.  Argus Systems Group, Inc. makes the PitBull .comPack suite for
Solaris 7 with ports underway to Solaris 8, AIX, UnixWare, and Linux on
32bit and 64bit kernel architectures.  HP creates a TOS known as VVOS
(Virtual Vault OS) that runs on HP hardware.

There are also two OpenSource Trusted Operating System projects
underway.TrustedBSD is being built on top of the FreeBSD operating
system.  Information on TrustedBSD can be found at
http://www.trustedbsd.com/.  SGI has released a reference set of code
for building a TOS at http://oss.sgi.com/projects/ob1/.

Getting it for Free
Argus Systems Group, Inc. has launched a program known as the Argus
Revolutionwhere its PitBull foundation B1 TOS is available for free for
individual non-commercial use.  Information on the program can be found
at http://www.argusrevolution.com/

Contact
Feel free to contact me for any comments or questions. Jeff Thompson
(thompson at argus-systems.com) Information on Argus Systems Group, Inc.
can be found at: http://www.argus-systems.com/
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message