Information Security Today Home

New Books

Digital Privacy: Theory, Technologies, and Practices
Cyber Forensics: A Field Manual for Collecting, Examining, and Preserving Evidence of Computer Crimes, Second Edition
Mechanics of User Identification and Authentication: Fundamentals of Identity Management
How to Achieve 27001 Certification: An Example of Applied Compliance Management
Insider Computer Fraud: An In-depth Framework for Detecting and Defending against Insider IT Attacks

Security Weaknesses of System and Application Interfaces Used to Process Sensitive Information

Sean M. Price

Organizations that process sensitive information must contend with the insider threat. Examples of sensitive information include proprietary, privacy, financial, or classified government information. The insider threat occurs when individuals authorized access to a system and its information willingly decide to violate policies by negatively impacting the confidentiality, integrity, or availability of the system or information. Modern operating systems contain a variety of security controls that include authentication, auditing, and access control list (ACL) mechanisms that can be used to hold individuals accountable and limit the possible damage that may occur.

Security controls are configured to support an organization's security policy. Unfortunately, many applications do not provide a capability to extend the security policy to the user's interface. This situation provides an avenue for the malicious user surreptitiously to alter or remove sensitive information through normal interfaces provided by the system and its applications. Due to the lack of granular security policy enforcement on application interfaces, organizations rely on written policies, training, and especially trust to protect sensitive information.

Users are typically delegated a certain amount of trust. They are expected not to violate the provided trust. In organizations with sensitive information, security policies are used to specify what user actions regarding the system are acceptable. Unfortunately, some users ignore policy and make decisions that affect the confidentiality, integrity, and availability of systems and information. Users that violate their trust can do so through the interfaces provided to access the system as opposed to only through the introduction of malicious software. User interfaces of commercial off-the-shelf (COTS) products may not have built-in policy enforcement mechanisms that are robust enough to support an organizational security policy and prevent these kinds of abuses.

Some operating systems and applications provide mechanisms to enforce policy through configurations. Two mechanisms used to provide policy enforcement include ACLs and policy configurations. Proper configuration of ACLs can support the concept of least privilege and prevent users from directly accessing information for which they are not authorized. However, this is not always completely enforceable on systems that only provide discretionary access control (DAC). For instance, suppose that user A is authorized read access to file S and user N is prohibited by policy from reading S. If A creates a new file C, which is a copy of S, and gives N read access to C, then a policy violation occurs because N has access to the contents of S. In this regard, DAC is unable to support the desired security policy fully.

Thus, to alleviate this situation may require some implementation of originator-controlled access control. Individual system policy configurations can be set to enforce a desired security policy. For example, a policy can be set on a Windows NT-based system to deny ordinary users the ability to use the built-in registry editing tools. Although this is a prudent security measure, it can be easily circumvented by running the tool from removable media.

Users performing sensitive operations on a system expect that an application will not inadvertently disclose the information during its period of processing. Unfortunately, applications are not always designed to restrict access to information by other users. This can occur when temporary files containing the sensitive information remain on the system in locations that are accessible to other users. Another way sensitive information can be exposed is through the existence of malicious software eavesdropping on the user's activity. Users may be unaware that the activity and interaction with the trusted application is being spied on by another process. In the situation of information disclosure through the actions of applications, user trust in the system and application is degraded.

This chapter focuses on the problems associated with user abuse of authorized interfaces. Common interface aspects that provide a user with the ability to circumvent or disregard security policy will be presented. The discussion is centered on Microsoft Windows NT-based operating systems and compatible applications, but much of the information is applicable to other operating systems that also make use of graphical interfaces.

Interface Security Weaknesses
Interfaces are primarily designed to support the end user. Designers of COTS products may not always consider the implications of the product in an environment where access to sensitive information should be controlled. Likewise, non-security-focused products may not be designed to support an organization's security policy.

Insiders abusing their access are provided the tools to do so from the proliferation of COTS products that do not provide organizations with the flexibility to support a security policy. This represents a security design problem in user interfaces. A number of common elements within application and system interfaces provide avenues for users to circumvent policy. These common features include menu items; standard operating system interfaces; selective policy settings; and application extensibility through mobile code, scripting, and add-ins.

Default application menus provide a number of ways for users to abuse their access. Many application menus provide a similar standard of user functions. Menu items are browsed and selected by the user through mouse or keyboard actions. Functions available through menus are typically accessible by end users unless the system or application has a policy enforcement mechanism that hides or disables their functionality.

One of the most prevalent functions under a typical File menu is the option to Save or Save As. This provides users with the ability to save their work or the display to any location desired. However, this provides an avenue for sensitive information to be removed from a system. A user need simply save a copy of the file to removable media and walk out with the sensitive information. This type of action is typically not audited by applications or systems and, therefore, is difficult to detect.

COTS products do not generally restrict the ability to save files from the menu options. The inability of organizations to enforce a policy through application interfaces puts their sensitive information at risk. Granted, it is necessary for users to save their work, but a policy determining where a file may be saved should be supported by a security policy-enabled interface.

Another menu item allowing users to remove information is the Print function. This interface action can provide hard copies of viewed information. Fortunately, some operating systems, such as those based on Windows NT, provide for some audit capability of printing actions. However, this can be circumvented if the printer is connected directly to a workstation.

Web browsers have a unique menu option that allows the user to view the source code of the Web page. This provides the end user with all of the displayed information in Hypertext Markup Language (HTML) format. The user has complete access to any sensitive information displayed through the browser. This is problematic when organizations make use of browsers as the user interface for their databases. Browsers usually associate a specific application for viewing the source code. In a Microsoft Windows environment, the Notepad application is typically used for this purpose. The ability to view the source code of a Web page is yet another method of extracting sensitive information from a system.

The clipboard is a command interface shared between applications and operating systems, providing the user with the ability to copy and paste text and objects. Clipboard functions are utilized through hotkey combinations and application graphical interfaces. The Copy, Cut, and Paste functions can be found under the Edit menu. These editing functions place copied or cut data into a shared memory location that is available for all applications and the system to use. This ubiquitous capability allows users to move data between applications easily. It also provides a simplistic method to copy sensitive data from one location and paste it into another in violation of organizational policies. Copy and paste operations are not usually audited regarding the actual content that was copied and pasted. This situation makes it difficult to detect insider misuse of systems and policy violations using clipboard methods.

Some applications have the ability to automate internal tasks through scripts. Some script technology, such as JavaScript, enhances the user experience by animating tasks, performing calculations, or automating application operations. In the case of browsers and other applications like Microsoft Office products, local users frequently have access to a script's source code. A malicious user may alter the code to cause the application to perform other functions not originally intended by the script. Likewise, nefarious users may develop their own scripts to subvert the interface or, in the case of a database application, the current transaction.

Providing users with an ever-enriching environment has led to the exploitation of software extensibility where an application allows the execution of foreign or mobile code within their process. Extensible objects include plug-ins and add-ins which are typically ActiveX controls that provide functionality beyond the scope of the original application. Likewise, Java applets provide extensibility as well, but with the possibility to limit their actions through the Java sandbox. Insiders may abuse this functionality by introducing malicious extensible objects designed to circumvent a security policy. The ability to include an add-in is generally available to users through sub-menu items.

Some applications do provide limited support for an organizational security policy. These applications have menu options to enable or disable capabilities such as mobile code and scripting. Unfortunately, users may possess sufficient system rights to set these security options at their own discretion. It is possible to prevent users from altering the policy for some applications that allow control to the interface through configuration files or the system registry. Users can be prevented from making unauthorized changes to the interface policy through the use of a properly configured ACL for the configuration file or registry key. The failure to implement the appropriate controls is viewed as a security operations problem.

Standard keyboards have a function key called Print Screen. When pressed, this key sends a message to the operating system to capture the entire screen (or a portion of it when used in conjunction with the Alt key) graphically. In Microsoft Windows, the captured bitmap image is placed on the clipboard for the user. The image can then be used by any program capable of working with raw bitmap data. This provides yet another interface where the user may arbitrarily capture sensitive data and place it into a file for removal from the system.

File and object access mediated by a system's DAC mechanism may not be granular enough to detect or deter inappropriate access. For example, Web browsers typically cache Web pages before displaying them. By default the user has full access to the source information in the page. This is because the user becomes the owner of the file object when the page is cached. Object owners have complete control according to the Windows DAC mechanism. Cached pages of sensitive information from organizational databases could easily be copied to other media using tools capable of reading and creating files. Discretionary access control fails to extend a security policy for specifying the types of applications authorized to read or modify a given file.

The former discussion has focused on the graphical aspects of application and system interfaces that can be exploited by an insider to compromise sensitive information. A final interface to consider is the command environment. A command interpreter or shell provides a non-graphical route to compromising data as well. Utilities exist for copying, modifying, and moving files on most operating systems. Protecting sensitive information from insider abuse with application and system interfaces requires careful consideration of all possible avenues an ordinary user might use to subvert a security policy.

Proposed Solutions
Application interfaces should be flexible enough to allow for the implementation of an organization's security policy. Providing system owners with the ability to define the components of an interface without user intervention is referred to as implicit security. Interfaces designed with implicit security will provide organizations with a mechanism to reduce the number of methods an insider might use to remove sensitive information from a system surreptitiously. Menu functions permitting file manipulation actions such as Save As, Print, Copy, Cut, and Paste could be disabled, removed, or redirected so that information cannot be mishandled through the interface.

Clipboard functions shared between the system and applications represent a substantial challenge to control. Three possible approaches should be considered when attempting to control clipboard functions.

First, all interfaces with the standard clipboard commands of Cut, Copy, and Paste should be disabled or removed. This would prevent the user from navigating through a menu to select the desired clipboard functions. Removing the functions from the menu selections, as opposed to disabling them, would follow good human-computer interface practices. Efficiency is increased by removing unusable items, which additionally reduces the total menu options. Retaining a disabled menu item would likely disrupt the user's internal locus of control due to his inability to utilize the restricted functions.

Second, keyboard shortcuts for clipboard functions also need to be negated. This could be accomplished by capturing keyboard activity through system hooks. Print Screen key activity should also be captured through hooks in addition to capturing clipboard shortcut combinations.

The third control necessary to prevent a determined insider from removing information is to empty the clipboard contents continuously. This is a necessary activity in the event the insider introduces other software that might perform other types of capture methods and place the data on the clipboard. Although the clipboard function provides a potential path to remove information from the system, it has become a necessary feature that provides user efficiency, and therefore, a similar functionality should be retained.

The clipboard functions found in most menus are necessary for normal editing tasks. Completely eliminating this capability would certainly reduce user efficiency. Alternatively, the system's clipboard capability could be wrapped and a policy mechanism implemented to control what may be copied and to where it may be placed. Implementing generic wrappers would provide a way to detect and respond to clipboard activity.

Wrapping functions have also been used as a form of misuse detection. In this sense, a system wrapper could be used as a policy enforcement mechanism to prevent unauthorized activity such as inappropriate file access or unauthorized process activation. Wrappers could be used to detect access to sensitive files. This functionality would be necessary to detect inappropriate access to Web pages cached by a browser. Alternatively, system call functions could be monitored for inappropriate access.

Systems supporting DAC only check for the rights of a user to access an object and to what degree any modification is permitted. What DAC does not support is a specification for the permitted type of application or interface authorized to manipulate an object. The concept of extending an ACL to include authorized applications was demonstrated by Schmid, Hill, and Ghosh. In their research, access to a protected document was only allowed when called by the authorized program. This concept helps ensure that sensitive information is not being accessed by malicious code. This concept could be extended to prevent malicious users from attempting to remove files from the system. Suppose we have information in file S accessible using program X. Using the approach proposed by Schmid, Hill, and Ghosh, a malicious user could be prevented from accessing S using any program other than X.

The insider threat must be dealt with by organizations to minimize the loss of confidentiality and integrity of sensitive information. Currently, application interfaces provide numerous methods for users to remove sensitive information from a system surreptitiously, in violation of a security policy. System and application interfaces could be modified to remove the functionality or be wrapped to negate attempts to circumvent the policy. Whatever method is used, efficiency for the user and a center of locus must be maintained or users will reject the system. Security practitioners and system developers are encouraged to consider the attributes of application interfaces and integrate policy aspects that can be used to control the actions of insiders granularly.

About the Author
Sean M. Price, CISSP, is an independent information security consultant located in the Washington, DC area. He provides security consulting and engineering support for commercial and government entities. Sean is continually immersed in research and development activities for secure systems. This article is from Information Security Management Handbook, 2009 CD-ROM Edition edited by Harold F. Tipton and Micki Krause. New York: Auerbach Publications, 2009.

Subscribe to Information Security Today

Powered by VerticalResponse

© Copyright 2008-2009 Auerbach Publications