CAPEC-68: Subvert Code-signing Facilities
Many languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment. Subverting this mechanism can be instrumental in an attacker escalating privilege. Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack.
Last updated
Overview
CAPEC-68 (Subvert Code-signing Facilities) is a standard-level attack pattern catalogued by MITRE in the Common Attack Pattern Enumeration and Classification (CAPEC). It describes a recurring method attackers use to exploit software weaknesses.
What the attacker needs
Prerequisites
- A framework-based language that supports code signing (such as, and most commonly, Java or .NET)
- Deployed code that has been signed by its authoring vendor, or a partner.
- The attacker will, for most circumstances, also need to be able to place code in the victim container. This does not necessarily mean that they will have to subvert host-level security, except when explicitly indicated.
Skills required
- High skill: Subverting code signing is not a trivial activity. Most code signing and verification schemes are based on use of cryptography and the attacker needs to have an understanding of these cryptographic operations in good detail. Additionally the attacker also needs to be aware of the way memory is assigned and accessed by the container since, often, the only way to subvert code signing would be to patch the code in memory. Finally, a knowledge of the platform specific mechanisms of signing and verifying code is a must.
Resources required
- The Attacker needs no special resources beyond the listed prerequisites in order to conduct this style of attack.
Consequences
What a successful CAPEC-68 attack can achieve.
Gain Privileges
Affects: Confidentiality, Access Control, Authorization
How to mitigate it
Defenses that reduce the risk of CAPEC-68.
- A given code signing scheme may be fallible due to improper use of cryptography. Developers must never roll out their own cryptography, nor should existing primitives be modified or ignored.
- If an attacker cannot attack the scheme directly, they might try to alter the environment that affects the signing and verification processes. A possible mitigation is to avoid reliance on flags or environment variables that are user-controllable.
Examples
In old versions (prior to 3.0b4) of the Netscape web browser Attackers able to foist a malicious Applet into a client's browser could execute the "Magic Coat" attack. In this attack, the offending Applet would implement its own getSigners() method. This implementation would use the containing VM's APIs to acquire other Applet's signatures (by calling _their_ getSigners() method) and if any running Applet had privileged-enough signature, the malicious Applet would have inherited that privilege just be (metaphorically) donning the others' coats.
Some (older) web browsers allowed scripting languages, such as JavaScript, to call signed Java code. In these circumstances, the browser's VM implementation would choose not to conduct stack inspection across language boundaries (from called signed Java to calling JavaScript) and would short-circuit "true" at the language boundary. Doing so meant that the VM would allow any (unprivileged) script to call privileged functions within signed code with impunity, causing them to fall prey to luring attacks.
The ability to load unsigned code into the kernel of earlier versions of Vista and bypass integrity checking is an example of such subversion. In the proof-of-concept, it is possible to bypass the signature-checking mechanism Vista uses to load device drivers.
Terminology & mappings
Mapped taxonomies
- ATTACK: Subvert Trust Controls: Code Signing (1553.002)
Frequently asked questions
Common questions about CAPEC-68.
- What is CAPEC-68?
- Many languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment. Subverting this mechanism can be instrumental in an attacker escalating privilege. Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack.
- How do you prevent CAPEC-68?
- A given code signing scheme may be fallible due to improper use of cryptography. Developers must never roll out their own cryptography, nor should existing primitives be modified or ignored.
- What weaknesses does CAPEC-68 target?
- CAPEC-68 exploits 3 CWE weaknesses, including CWE-325 (Missing Cryptographic Step), CWE-328 (Use of Weak Hash), CWE-1326 (Missing Immutable Root of Trust in Hardware).
- How severe is CAPEC-68?
- MITRE rates CAPEC-68 as Very High severity with low likelihood of attack.
References
Attack-pattern data is sourced from the MITRE CAPEC catalog (v3.9). Weakness associations link to the corresponding CWE entries on RadicalNotion.AI.
Defend against CAPEC-68
Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.