Application Security Assessments

Advice on Assessing your Custom Application

by Gunter Ollmann

Custom applications and their security threats

For many organisations, their internal security professionals are adept at finding and responding to information about the latest vulnerabilities and threats to the software employed within business critical systems under their supervision. There are a great many security resources available, online and printed, ready to help explain and address potential vulnerabilities with the most common commercial software products. However, there exist two problems for those responsible for the security and integrity of your systems. Firstly, the �hit or miss� disclosure of vulnerabilities in commercial software, and secondly, how do you identify or address potential vulnerabilities in the custom (in-house developed) application that connects and runs atop the commercial software?

There is very little most organisations can do about the �hit or miss� disclosure of vulnerabilities inherent to the commercial software deployed throughout the business. You must rely upon the software provider to have initiated appropriate quality controls and security testing, and provide bug-fixes or patches as necessary. Due to various country specific laws or software agreements, it may actually be illegal for your organisation to reverse-engineer or otherwise identify security flaws with the software you have purchased.

In the case of custom (in-house developed) applications, it is normally possible to conduct a more thorough security review of the system. There are two paths available to an organisation wishing to review the security of their application; a code review and an application assessment. A code review tends towards more of an audit of coding practices utilised throughout the pre-compiled application, while an assessment reviews the functionality and resilience of the compiled application components to real-life threats. While a code review often initially appears to be more valuable, most organisations soon find to their amazement that such a review is extremely costly in both time and effort, and often fails to identify post compilation and deployment issues. An application assessment focuses on the compiled and installed elements of the entire system. Attention is made to how the application components are deployed, communicate or otherwise interact with both the user and server environments. From past experience, the author has found that application assessments often represent the best value-for-money when identifying security threats and resolutions to distributed client-server applications.

Unfortunately, many organisations will find that they do not have sufficiently skilled resources available internally to cope with an application security assessment, and will have to seek security advice from a security specialist. Not all security organisations or consultancies can provide application security assessments, but those that do will normally classify the application or system into one of two classes; Web and Compiled.

This whitepaper aims to provide an organisation with enough information to understand the potential threats to your application beyond classical �ethical hacking� methodologies, and provide helpful advice on steps that can be taken to limit such security threats.

How hackers execute attacks against custom applications

Most initial attacks against your systems are likely to focus upon the systems infrastructure and commercial applications, as that is where most of the exploit material and methodologies are likely to work. Depending upon the skills or resources, if your systems are well secured and up to date with the latest bug-fixes or patches, the attacker may either resort to social engineering (Why try to crack a password when you can just call the helpdesk and have it reset?) or focus upon the manipulation of the vulnerabilities inherent in the application, or sub-components. Although custom applications can be vulnerable to a number of attack methodologies. Four attack categories are most prevalent:

Buffer overflow attacks � Buffer overflow attacks are aimed at application components that take data as an input and pass it to memory buffers for later use and manipulation. Failure to adequately check the size of data before passing it into too small a buffer is commonplace. Attackers may be able to include their own embedded commands within the oversized data package and thus have their commands replace existing application code and execute on the system. If successfully executed, these commands will enable attackers to acquire privileges that exceed authorised permissions up to, and including, those of the system administrator � with corresponding control of the host system. In some circumstances, application components subject to a buffer overflow may suspend or crash, thus denying users further access to the service. In other cases such an attack may bring down the host server and deny access to any services provided by the system.
Race conditions � Under certain circumstances, when an application requires access to specific files, variables or data, its programmers may not have correctly implemented multiple simultaneous accesses and installed the appropriate checks. This can often lead to an attacker enjoying unintended access to files or data through trusted and untrusted server application components.
Exploitation of application component privileges � Server based application components run with specific group or user permissions, not necessarily with that of the user running them (such as an anonymous Web user). These application components, if they suffer additionally from buffer overflows or race conditions, can be used to increase access and escalate the potential damage to the system.
Client-side manipulation � To speed up connectivity and reduce performance loads at the server end, client-side validation of input and manipulation of data is often required. It is often a relatively trivial exercise for attackers to bypass this checking and supply incorrect data or data formats to the server in an attempt to initiate any of the other three common attack formats or to reveal both confidential information and server application functionality. This method is also a popular means of conducting fraudulent transactions on commerce-enabled sites by changing the values of available products.

Web-based applications

As Internet businesses have matured, a new category of application has emerged that enables companies to interact with both potential and existing clients in this medium. These Web-based applications � while they rely on conventional corporate technologies such as database, mail or Web servers � are often subject to design compromises due to the limits of the medium. Such design compromises, unless carefully reviewed and analysed, can expose the integrity of the application components and corporate data to avoidable security risks. In many cases, in fact, application risks far outweigh the threats to the supporting environment from traditional hacking techniques.

To make the best use of client-side Internet bandwidth and to deal with high volumes of simultaneous connections and data requests, Web-based applications tend to be distributed over multiple servers using a tiered architecture model. Moreover, they frequently rely on client-side code to present and manage data. These design considerations, coupled with the use of scripting-type development languages and constant changes in authentication and certification procedures, frequently lead to security flaws in an applications implementation. Increasingly, Internet-based attacks exploit these security flaws to compromise sites and gain access to critical systems.

Direct attacks against custom Web applications through manipulation of their inherent vulnerabilities have become more popular due to their relative ease and the scope they offer for maintaining anonymity. Although companies may install various security mechanisms to strengthen security � firewalls, intrusion detection systems, operating system hardening procedures, etc. � they seldom expend much effort in securing and verifying the integrity of applications and coded pages against external attacks. In these circumstances, simple manipulation of client code or data, such as the price of goods in an online shopping basket application or sending corrupt and incorrect data to the server, can lead to fraudulent transactions or theft of confidential information.

It seems hardly a week goes by without the appearance of fresh newspaper stories describing how faulty application processes and input manipulation have led to the loss of confidential data such as banking details and credit card numbers. In almost all such cases, an understanding of manipulation techniques combined with rigorous client-side security testing would have identified the potential failure points and resulted in a more robust application, thus averting embarrassing, often dangerous compromises of system and data integrity.

The web-based application security assessment process

The process of assessing the security of a web-based application, although not technically complex, often relies upon a multi-facetted approach utilising a variety of technologies and techniques. Unfortunately, there is currently no quick shrink-wrapped solution available to automatically and comprehensively assess an application�s security. Various vendors can supply testing products that will search for the most basic faults in non-complex applications/environments and provide advice on better coding practices. Based upon experience in assessing critical Web-enabled applications, automated tools should only be used for first-round security testing and preliminary identification of potential flaws.

Depending on your specific requirements and the type of web-based application, an application security assessment should typically consist of the following phases:

Examination of external/client-side visible code for information that could be used for social engineering purposes or for information on how an application functions that might be used for a more focused attack.
Discovery of information on the type of environment that exists at the server side (eg, embedded SQL queries specific to a single database version).
Inspection of application validation and bounds checking � both for accidental and mischievous input. The purpose of this exercise is to ascertain the limits of correct server responses when handling unexpected data formats or sizes. This phase involves buffer overflow attempts to establish system resilience and performance continuity.
Manipulation of client-side code and locally stored information such as cookies and session information. Client-side code is altered to subvert authentication checking and used to establish the bounds of server reliance on client data fields. URL request information and GET/PUT requests are altered to achieve unexpected system responses and access confidential information.
Examination of application-to-application interaction between system components such as the Web service and back-end data sources. Attempts are made to reference system components by impersonating other system functions or sources. Redirection methods and messaging functions are closely examined.
Discovery of techniques that could be employed by attackers to escalate their permissions by referencing application components with higher server-side permissions, or exploitation of race conditions to identify lax permission or authentication checking.
Attempts to subvert in-transit data between the client and server system. Examination of data delivery methods and the likelihood of their subversion or use in a replay-type attack, or other session orientated attacks, including an analysis of system responses to such data.
Authentication methods in use are examined for their robustness and resilience to various subversion techniques. Attempts are made to bypass authentication processes and/or impersonate valid logged-in users. Detailed studies of user segregation methods are undertaken and an analysis of server-side responses to failed attempts is made.
Overall examination of the application�s deployment and security configuration from perceived threat models. Advice is given on secure deployment methodologies for the application type, based upon market considerations, new vulnerability developments and attack methodologies.

Compiled applications

Although not as visible or exposed as most web applications, the security threats to compiled applications are very similar and often share the same principles of data integrity and resilience. However, the methodologies and tools necessary for testing the compiled application and sub-components are quite different. While the emphasis of a web application assessment is on manipulation of external client data; for a compiled application, the emphasis is on the communication methods and data streams between all internal system components.

The great diversity of compiled applications and their interaction with other commercial products (e.g. operating systems, databases, messaging systems and hardware) often means that assessment methodologies must be tuned to system at hand. For this reason, it is vital that both your organisation and the assessment supplier fully understand the scope and reasons for undertaking the security assessment.

General advice on securing custom applications

The Author is often asked for advice on best practices for securing applications to minimise the developer�s time for correcting potential flaws that may be discovered during a security assessment. Several steps should be undertaken, or at least borne in mind, in order to maximise security and data integrity during the process of building a new application:

Assume that someone out there will intentionally try to break your application and may have access to greater resources than you expended in developing it.
Assume that you will receive erroneous data from authorised, authenticated users, and develop a way to deal with it.
If you choose to use client-side input validation, ensure that the input is also validated at the server end.
Avoid complex code and use minimal coding structures for handling performance related issues.
Be careful with application component privileges. Always apply the minimum possible permissions needed to carry out any particular task.
Utilise methods of load limiting to prevent overloading application components or servers.
Check every return code from system components and functions to prevent race conditions or malicious input.
Never allow passwords or user specific details to be passed in plain-text to the client browser or between application components.
Ensure that confidential system information is not encoded into documents that could potentially be accessed by a remote client, either directly or through escalated application component permissions and calls.
Commonly available libraries or sample code may not necessarily be secure. Review carefully any third-party code.
Always use full pathnames in system and application procedure calls to prevent redirection and unexpected use.
Take extreme care with file permissions and access rights.
Remove all unnecessary material from the hosting servers and only install services that are required for the application/system to function.
Remove all comments and unnecessary information from client-side code.
Distribute application functions between servers when possible to limit data access from a compromised host.
Use reasonable system timeouts for network reads and writes to help prevent race conditions being reached and denial of service attacks.
Ensure you are capable of logging and tracking all inbound requests for post attack analysis.
Where possible, only use shared resources you have direct control over. If this is not possible, ensure appropriate checks for data integrity are made.
Test the application thoroughly!
Get a third party to perform an independent assessment both of the application�s security and the system�s host servers before going live.

Conclusion

The security threats and responses to your infrastructure and commercial software components are commonly understood, and classical security assessment or �ethical hacking� methodologies are adept at increasing the security level of your key infrastructure components. However, custom application code is often untested, and attackers are now focusing upon these security flaws to compromise system components or otherwise gain access to confidential data. For these reasons, organisations should ensure that appropriate security assessments are carried out on all custom, in-house developed, applications.

The Author asserts the moral right to be identified as the author of this work