SANS Top Application Vulnerabilities Series 3

This post is the final of Top software vulnerabilities according to SANS Institute

Dereferencing A NULL Pointer

Dereferencing a null pointer is when the application dereferences a pointer that was supposed to return a valid result instead returns NULL and this leads to a crash. Dereferencing a null pointer can happen through many flaws like race conditions and some programming error. The processes that are performed with the help of the NULL pointer usually lead to failure, and the possibility of carrying out the process is very slim. This helps attackers to execute malicious code.

Incorrect Permission Assignment

This vulnerability happens when an application assigns permission to a very important and critical resource in such a manner that exposed the resource to be accessed by a malicious user.

When you give many people permission to a resource, this could lead to sensitive information being exposed or modified by an attacker. If there are no checks in place against this kind of approach to permission assignment to resources, it can lead to a very disastrous end if a program configuration or some sensitive data gets into the wrong hand

Unrestricted File Upload

This vulnerability occurs when the application does not validate the file types before uploading files to the application. This vulnerability is language independent but usually occurs in applications written in ASP and PHP language. A dangerous type of file is a file that can be automatically processed within the application environment.

Information Exposure Through XML Entities

When an XML document is uploaded into an application for processing and this document contains XML entities with uniform resource identifier that resolves to another document in another location different from the intended location. This anomaly can make the application to attach incorrect documents into its output.

The XML documents sometimes contain a Document Type Definition (DTD), which is used to define the XML entities and other features. Through the DTD, the uniform resource identifier can serve as a form of substitution string. What the XML parser will do is access what is contained in the uniform resource identifier and input these contents back into the XML document for execution.

Code Injection

The existence of code syntax in the user’s data increases the attacker’s possibility to change the planned control behaviour and execute arbitrary code. This vulnerability is referred to as “injection weaknesses” and this weakness could make a data control become user controlled.

This vulnerability depicts a scenario where software allows untrusted data into the code and does not perform validation of special characters which can negatively influence both the behavior of the code segment and the syntax.

In short, an attacker would be able to inject some sort of arbitrary code and execute them within the application. The following PHP code shows the usage of the eval() function in untrusted data. In the code below an attacker can pass into the code the “param” parameter arbitrary code which will then be executed in the software.

The below example explain the call to the phpinfo() function. This vulnerability can further be exploited in other to execute arbitrary OS commands on the target software through the system() call.

Hard-coded Access Key

This is when the password and access key is hard coded into the application directly for inbound authentication purpose and outbound communication to some external components and for encryption of internal data. Hard-coded login details usually cause vulnerability that paves the way for an attacker to bypass the authentication that has been configured by the software administrator.

The system administrator will always find it very hard to detect this vulnerability and fix it.

There are two main streams to this weakness:

Inbound: The application contains an authentication system that validates the input credentials against the hard-coded details.
Outbound: The application connects to another system and details for connecting to the other system are hardcoded into the system.

Uncontrolled Resource Consumption

This vulnerability happens when the application does not control the allocation properly and maintenance of a limited resource, this allows an attacker to be able to influence the amount of resources consumed, which will eventually lead to the exhaustion of available resources.

Part of the limited resources includes memory, file system storage, database connection pool entries, and CPU. Let’s assume an attacker can trigger the allocation of these limited resources and the number or size of the resources is not controlled, then the attacker could cause chaos through denial of service that consumes all available resources.

When this happens, it would prevent valid users from accessing the application, which will invariably have a negative impact on the environment. For instance, when the application memory goes through an exhaustion attack, this could slow down the entire application as well as the host operating system.

The three different instances which can lead to resource exhaustion are: