Nothing Special   »   [go: up one dir, main page]
New to CAPEC? Start Here
Home > CAPEC List > CAPEC-237: Escaping a Sandbox by Calling Code in Another Language (Version 3.9)  
CAPEC-237: Escaping a Sandbox by Calling Code in Another Language
Attack Pattern ID: 237
Abstraction: Detailed
View customized information:
+ Description
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.
+ Likelihood Of Attack

Low

+ Typical Severity

Very High

+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.480Escaping Virtualization
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
View NameTop Level Categories
Domains of AttackSoftware
Mechanisms of AttackSubvert Access Control
+ Execution Flow
Explore

  1. Probing: The attacker probes the target application to see whether calling code of another language is allowed within a sandbox.

    Techniques
    The attacker probes the target application to see whether calling code of another language is allowed within a sandbox.

  2. Analysis: The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox.

    Techniques
    The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox.
Experiment

  1. Verify the exploitable security weaknesses: The attacker tries to craft malicious code of another language allowed by the sandbox to verify the security weaknesses of the standard libraries found in the Explore phase.

    Techniques
    The attacker tries to explore the security weaknesses by calling malicious code of another language allowed by the sandbox.
Exploit

  1. Exploit the security weaknesses in the standard libraries: The attacker calls malicious code of another language to exploit the security weaknesses in the standard libraries verified in the Experiment phase. The attacker will be able to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox.

    Techniques
    The attacker calls malicious code of another language to exploit the security weaknesses in the standard libraries.
+ Skills Required
[Level: High]
The attacker must have a good knowledge of the platform specific mechanisms of signing and verifying code. Most code signing and verification schemes are based on use of cryptography, the attacker needs to have an understand of these cryptographic operations in good detail.
+ Resources Required
None: No specialized resources are required to execute this type of attack.
+ Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Access Control
Authorization
Bypass Protection Mechanism
Authorization
Execute Unauthorized Commands
Accountability
Authentication
Authorization
Non-Repudiation
Gain Privileges
+ Mitigations
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.
+ Example Instances
Exploit: Java/ByteVerify.C is a detection of malicious code that attempts to exploit a vulnerability in the Microsoft Virtual Machine (VM). The VM enables Java programs to run on Windows platforms. The Microsoft Java VM is included in most versions of Windows and Internet Explorer. In some versions of the Microsoft VM, a vulnerability exists because of a flaw in the way the ByteCode Verifier checks code when it is initially being loaded by the Microsoft VM. The ByteCode Verifier is a low level process in the Microsoft VM that is responsible for checking the validity of code - or byte code - as it is initially being loaded into the Microsoft VM. Java/ByteVerify.C attempts to download a file named "msits.exe", located in the same virtual directory as the Java applet, into the Windows system folder, and with a random file name. It then tries to execute this specific file. This flaw enables attackers to execute arbitrary code on a user's machine such as writing, downloading and executing additional malware. This vulnerability is addressed by update MS03-011, released in 2003.
+ Taxonomy Mappings
Section HelpCAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (see parent )
+ References
[REF-91] J. Cappos, J. Rasley, J. Samuel, I. Beschastnikh, C. Barsan, A. Krishnamurthy and T. Anderson. "Retaining Sandbox Containment Despite Bugs in Privileged Memory-Safe Code". The 17th ACM Conference on Computer and Communications Security (CCS '10). 2010.
[REF-92] "Malware Protection Center: Threat Research and Response". Exploit: Java/ByteVerify.C. Microsoft Corporation. 2007. <https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Exploit%3AJava%2FByteVerify.C>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2017-08-04
(Version 2.11)
CAPEC Content TeamThe MITRE Corporation
Updated Resources_Required
2018-07-31
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated Description Summary, Examples-Instances, References
2019-09-30
(Version 3.2)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2020-07-30
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2020-12-17
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
Updated @Name, Description, Execution_Flow, Prerequisites, Related_Attack_Patterns
Previous Entry Names
Change DatePrevious Entry Name
2018-07-31
(Version 2.12)
Calling Signed Code From Another Language Within A Sandbox Allow This
2020-12-17
(Version 3.4)
Escaping a Sandbox by Calling Signed Code in Another Language
More information is available — Please select a different filter.
Page Last Updated or Reviewed: December 17, 2020
 

Use of the Common Attack Pattern Enumeration and Classification (CAPEC), and the associated references from this website are subject to the Terms of Use. Copyright © 2007–2024, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.