Common Vulnerabilities and Exposures (CVE)

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

Typical severity: High

Prerequisites: The application must be navigable in a manner that associates elements (subsections) of the application with ACLs. The various resources, or individual URLs, must be somehow discoverable by the attacker The administrator must have forgotten to associate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource.

Solutions: In a more general setting, the administrator must mark every resource besides the ones supposed to be exposed to the user as accessible by a role impossible for the user to assume. The default security setting must be to deny access and then grant access only to those resources intended by business logic.

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

Typical severity: Very High

Prerequisites: HTTP TRACE is enabled on the web server The destination system is susceptible to XSS or an adversary can leverage some other weakness to bypass the same origin policy Scripting is enabled in the client's browser HTTP is used as the communication protocol between the server and the client

Solutions: Administrators should disable support for HTTP TRACE at the destination's web server. Vendors should disable TRACE by default. Patch web browser against known security origin policy bypass exploits.

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

Typical severity: Medium

Prerequisites: The target must be misconfigured to return a list of a directory's content when it receives a request that ends in a directory name rather than a file name. The adversary must be able to control the path that is requested of the target. The administrator must have failed to properly configure an ACL or has associated an overly permissive ACL with a particular directory. The server version or patch level must not inherently prevent known directory listing attacks from working.

Solutions: 1. Using blank index.html: putting blank index.html simply prevent directory listings from displaying to site visitors. 2. Preventing with .htaccess in Apache web server: In .htaccess, write "Options-indexes". 3. Suppressing error messages: using error 403 "Forbidden" message exactly like error 404 "Not Found" message.

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

Typical severity: Very High

Prerequisites: System's configuration must allow an attacker to directly access executable files or upload files to execute. This means that any access control system that is supposed to mediate communications between the subject and the object is set incorrectly or assumes a benign environment.

Solutions: Design: Enforce principle of least privilege Design: Run server interfaces with a non-root account and/or utilize chroot jails or other configuration techniques to constrain privileges even if attacker gains some limited access to commands. Implementation: Perform testing such as pen-testing and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables.

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

Typical severity: Low

Prerequisites: Ciphertext is known. Encryption algorithm and key size are known.

Solutions: Use commonly accepted algorithms and recommended key sizes. The key size used will depend on how important it is to keep the data confidential and for how long. In theory a brute force attack performing an exhaustive key space search will always succeed, so the goal is to have computational security. Moore's law needs to be taken into account that suggests that computing resources double every eighteen months.

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

Typical severity: High

Prerequisites: Server software must rely on client side formatted and validated values, and not reinforce these checks on the server side.

Solutions: Design: Ensure that client process and/or message is authenticated so that anonymous communications and/or messages are not accepted by the system. Design: Do not rely on client validation or encoding for security purposes. Design: Utilize digital signatures to increase authentication assurance. Design: Utilize two factor authentication to increase authentication assurance. Implementation: Perform input validation for all remote content.

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

Typical severity: Very High

Prerequisites:

Solutions: Assurance: Sanitize the code of the standard libraries to make sure there is no security weaknesses in them. Design: Use obfuscation and other techniques to prevent reverse engineering the standard libraries. Assurance: Use static analysis tool to do code review and dynamic tool to do penetration test on the standard library. Configuration: Get latest updates for the computer.

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

Typical severity: High

Prerequisites: The architecture under attack must publish or otherwise make available services that clients can attach to, either in an unauthenticated fashion, or having obtained an authentication token elsewhere. The service need not be 'discoverable', but in the event it isn't it must have some way of being discovered by an attacker. This might include listening on a well-known port. Ultimately, the likelihood of exploit depends on discoverability of the vulnerable service.

Solutions: Authenticating both services and their discovery, and protecting that authentication mechanism simply fixes the bulk of this problem. Protecting the authentication involves the standard means, including: 1) protecting the channel over which authentication occurs, 2) preventing the theft, forgery, or prediction of authentication credentials or the resultant tokens, or 3) subversion of password reset and the like.

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

Typical severity: High

Prerequisites: Signer and recipient are using complex data storage structures that allow for a mix between signed and unsigned data Recipient is using signature verification software that does not maintain separation between signed and unsigned data once the signature has been verified.

Solutions: Ensure the application is fully patched and does not allow the processing of unsigned data as if it is signed data.

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

Typical severity: Very High

Prerequisites:

Solutions: Ensure virtualization software is current and up-to-date. Abide by the least privilege principle to avoid assigning users more privileges than necessary.

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

Typical severity: Very High

Prerequisites: The attacker must be able to write to resources or redirect access to the service registry.

Solutions: Design: Enforce principle of least privilege Design: Harden registry server and file access permissions Implementation: Implement communications to and from the registry using secure protocols

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

Typical severity: Very High

Prerequisites: Opportunity to intercept must exist beyond the point where SSL is terminated. The adversary must be able to insert a listener actively (proxying the communication) or passively (sniffing the communication) in the client-server communication path.

Solutions: Implementation: Implement message level security such as HMAC in the HTTP communication Design: Utilize defense in depth, do not rely on a single security mechanism like SSL Design: Enforce principle of least privilege

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

Typical severity: High

Prerequisites: The target host uses session IDs to keep track of the users. Session IDs are used to control access to resources. The session IDs used by the target host are predictable. For example, the session IDs are generated using predictable information (e.g., time).

Solutions: Use a strong source of randomness to generate a session ID. Use adequate length session IDs Do not use information available to the user in order to generate session ID (e.g., time). Ideas for creating random numbers are offered by Eastlake [RFC1750] Encrypt the session ID if you expose it to the user. For instance session ID can be stored in a cookie in encrypted format.

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

Typical severity: High

Prerequisites: The attacker must have the ability to place themself in the communication path between the client and server. The targeted application must receive some application code from the server; for example, dynamic updates, patches, applets or scripts. The attacker must be able to employ a sniffer on the network without being detected.

Solutions: Design: Encrypt all communication between the client and server. Implementation: Use SSL, SSH, SCP. Operation: Use "ifconfig/ipconfig" or other tools to detect the sniffer installed in the network.

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

Typical severity: High

Prerequisites: Person in the Middle network setup.

Solutions: Newer Bluetooth firmwares ensure that the KNOB is not negotaited in plaintext. Update your device.

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner. State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits. If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

Typical severity: High

Prerequisites: User state is maintained at least in some way in user-controllable locations, such as cookies or URL parameters. There is a faulty finite state machine in the hardware logic that can be exploited.

Solutions: Do not rely solely on user-controllable locations, such as cookies or URL parameters, to maintain user state. Avoid sensitive information, such as usernames or authentication and authorization information, in user-controllable locations. Sensitive information that is part of the user state must be appropriately protected to ensure confidentiality and integrity at each request. All possible states must be handled by hardware finite state machines.

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.

Typical severity: High

Prerequisites: The forcibly browseable pages or accessible resources must be discoverable and improperly protected.

Solutions: Authenticate request to every resource. In addition, every page or resource must ensure that the request it is handling has been made in an authorized context. Forceful browsing can also be made difficult to a large extent by not hard-coding names of application pages or resources. This way, the attacker cannot figure out, from the application alone, the resources available from the present context.