In those organisations where security is core to IT functionality, internal security professionals are usually adept at finding and responding to information about vulnerabilities and threats to the software employed within the business-critical systems under their supervision.
However, there are two additional problems facing those responsible for the security and integrity of data systems. First, the ‘hit or miss’ disclosure of vulnerabilities in commercial software and, second, how to identify or address potential vulnerabilities in the custom applications (often developed in-house) that connect to and run alongside the organisation’s commercial software.
In truth there’s very little that most organisations can do about the ‘hit or miss’ disclosure of vulnerabilities inherent in the commercial software deployed throughout the business. Security and IT managers must rely on their software provider to initiate the appropriate quality controls and security testing, and also to provide bug fixes or patches as necessary.
End users should also be aware that, due to various country-specific laws or software agreements, it may actually be illegal for their company to ‘reverse-engineer’ or identify security flaws within the purchased software.
Where custom-made applications are concerned, it’s normally possible to conduct a more thorough security review of the system. There are two paths open to the in-house manager looking to assess the security of IT applications developed from within: a code review and an application assessment.
Essentially, a code review tends to be an audit of coding practices used throughout pre-compiled applications, while an assessment reviews the functionality and resilience of the compiled application components to real life threats. Whereas code review might appear to be of greater value – initially, at least – many end users ultimately discover that such reviews are costly both in terms of time and effort expended. Not only that, more often than not they fail to identify post-compilation and deployment issues.
An application assessment focuses on the compiled and installed elements of the entire IT system. Attention is given as to how the application’s components are deployed, and how they communicate (or otherwise interact) with both the user and server environments. From past experience, they usually represent best value in terms of being able to identify and resolve security threats to distributed client/server applications.
It’s true to say that most organisations don’t have sufficiently skilled resources available to cope with an application security assessment, and thus will need to seek specialist advice.
And don’t be fooled into thinking that all consultants have the necessary skills to satisfy this need. Those that do normally classify the application or system into one of two classes: Web and Compiled.
Compromising custom applications
Most exploratory attacks against an organisation’s systems are likely to focus on systems infrastructure and commercial applications (these are where most of the available exploit materials and methodologies are likely to be effective).
If the target systems are properly secured and up-to-date with bug fixes or patches, the attacker will often move on to a less well-protected system. However, depending upon the skills or resources at his or her disposal, a determined attacker may resort either to social engineering methodologies – why try to crack a password when a call to the IT HelpDesk will often result in it being reset? – or a focus upon the manipulation of the vulnerabilities inherent in applications or their sub-components.
Although custom IT applications can be vulnerable to a number of attack methodologies, four categories of attack are most prevalent: buffer overflow attacks, race conditions, exploitation of application component privileges and client-side manipulation.
Buffer overflow attacks are aimed at application components that take data as an input and pass it on to memory buffers for later use and manipulation. Failure to adequately check the size of a data packet before passing it into too small a buffer is commonplace. Attackers may be able to include their own embedded code within the oversized data packet, thereby ensuring that 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).
What of 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 non-trusted server application components.
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). Combined with buffer overflows or race conditions, these application components may be used to simplify unauthorised access and escalate the potential damage to the system.
To speed up connectivity and reduce performance levels at the server end, client-side validation of input and manipulation of data are often required.
Applications on the World Wide Web
As Internet businesses have matured, so a new category of application has emerged that enables companies to interact with both potential and existing customers. While relying on conventional corporate technologies such as databases and mail or Web servers, these Web-based applications are often subject to design compromises imposed by the bandwidth limitations of Internet connections.
Unless carefully reviewed and analysed, such design compromises can expose the integrity of application components and corporate data to avoidable security risks. In many cases, application risks far outweigh the threats to the supporting environment from traditional attack techniques.
To make the best use of client-side Internet bandwidth, Web-based applications tend to be distributed over multiple servers using a tiered architectural model. 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 – can easily lead to security flaws in an application’s implementation.
Direct attacks against custom Web applications through the manipulation of their inherent vulnerabilities have become more commonplace due to their relative ease and the scope they offer for maintaining anonymity.
Although organisations may install various mechanisms to strengthen the security of their systems infrastructure (ie firewalls, intrusion detection and operational hardening systems, etc), they often overlook the need to secure and verify the integrity of internally-developed applications and coded pages against external attacks. In these circumstances, simple manipulation of client code or data can lead to fraudulent transactions or the theft of important and confidential information.
In almost all the cases exposed by the media in recent times, 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.
Inside Web-based assessments
Although not technically complex, the process of assessing the security of a Web-based application often relies upon a multi-faceted approach using a variety of technologies and techniques. Unfortunately, there’s currently no shrink-wrapped solution available to automatically and comprehensively assess an application’s security.
Automated tools should be used only for first-round security testing and the preliminary identification of potential flaws. Thorough testing demands a far more rigorous approach founded on consulting expertise.
Depending on specific requirements – and the type of Web-based application being tested – a thorough application security assessment would typically consist of the following phases:
A case of shared principles
The methodologies and tools necessary for testing compiled applications and sub-components are quite different. While the emphasis of a Web application assessment is on the manipulation of external client data, the emphasis here is on the communication methods and data streams between all internal system components for a compiled application.
The great diversity of compiled applications and their interaction with other commercial products (eg operating systems, databases, messaging systems and hardware) often means that assessment methodologies must be tuned to the system at hand. For this reason alone it’s vital that both the client organisation and the assessment consultant fully understand the scope of (and reasons for undertaking) the security assessment.
As a general rule several steps should be taken to maximise security and data integrity during the process of building a new application. Developers should start out with the assumption that someone will intentionally try to break their application, and may have access to greater resources than they expended in developing it. They should also assume that they will receive erroneous data from authorised, authenticated users and discover a way for dealing with this.
If developers choose to use client-side input validation, they should ensure that the input is also validated at the server end. Complex code should be avoided, while the use of minimal coding structures for handling performance-related issues is encouraged. Developers also need to be careful with application component privileges, and should always apply the minimum possible permissions needed to carry out any particular task.
Passwords or user-specific details should not be allowed to pass in plain text format to the client browser or between application components. Commonly-available libraries or sample code may not necessarily be secure – any third party code should be carefully reviewed. Care should also be taken to use full path names in system and application procedure calls by way of preventing redirection and unexpected use.
Where possible, the only shared resources used should be those over which the developer has direct control – if this isn’t possible, developers should ensure that appropriate checks are made for data integrity.
Lastly, a third party should be engaged to perform an independent assessment both of the application’s security and the system’s host servers before ‘going live’.
