Lifting Data Embedded in Client Distributions |
| Attack Pattern ID: 37 (Standard Attack Pattern Completeness: Complete) | Typical Severity: Very High | Status: Draft |
DescriptionSummary
An attacker can resort to stealing data embedded in client distributions or client code in order to gain certain information. This information can reveal confidential contents, such as account numbers, or can be used as an intermediate step in a larger attack (such as by stealing keys/credentials).
Attack Execution Flow
Identify Target:
Attacker identifies client components to extract information from. These may be binary executables, class files, shared libraries (e.g., DLLs), or other machine code.
Attack Step Techniques
ID Attack Step Technique Description Environments 1 Binary file extraction. The attacker extracts binary files from zips, jars, wars, PDFs or other composite formats.
env-Local env-Embedded env-ClientServer env-Peer2Peer2 Package listing. The attacker uses a package manifest provided with the software installer, or the filesystem itself, to identify component files suitable for attack.
env-Local env-Embedded env-ClientServer env-Peer2PeerIndicators
ID type Indicator Description Environments 1 Positive Proprietary or sensitive data is stored in a location ultimately distributed to end users.
env-Local env-Embedded env-ClientServer env-Peer2Peer2 Negative Access to binary code is not realistic. For example, in a client-server environment, binary code on the server is presumed to be inscrutable to an attacker unless another vulnerability exposes it.
env-Web env-ClientServer env-Peer2Peer env-CommProtocolOutcomes
ID type Outcome Description 1 Success The attacker identifies one or more files or data in the software to attack.Security Controls
ID type Security Control Description 1 Preventative Obfuscation can make the observation and reverse engineering more difficult. It is only capable of delaying an attacker, however, not preventing a sufficiently motivated and resourced one.
Apply mining techniques:
The attacker then uses a variety of techniques, such as sniffing, reverse-engineering, and cryptanalysis to extract the information of interest.
Attack Step Techniques
ID Attack Step Technique Description Environments 1 API Profiling. The attacker monitors the software's use of registry keys or other operating system-provided storage locations that can contain sensitive information.
env-Local env-Embedded env-ClientServer env-Peer2Peer2 Execution in simulator. The attacker physically removes mass storage from the system and explores it using a simulator, external system, or other debugging harness.
env-Local env-Embedded3 Cryptanalysis. The attacker performs cryptanalysis to identify data in the client component which may be cryptographically significant. (Key material frequently stands out as very high entropy data when compared to other mundane data). Given cryptographically significant data, other analyses are performed (e.g., length, internal structure, etc.) to determine potential algorithms (RSA, ECC, AES, etc.). This process proceeds until the attacker reaches a conclusion about the significance and use of the data.
env-Local env-Embedded env-ClientServer env-Peer2Peer4 Common decoding methods. The attacker applies methods to decode such encodings and compressions as Base64, unzip, unrar, RLE decoding, gzip decompression and so on.
env-All5 Common data typing. The attacker looks for common file signatures for well known file types (JPEG, TIFF, ASN.1, LDIF, etc.). If the signatures match, he attempts decoding in that format.
env-AllIndicators
ID type Indicator Description Environments 1 Positive Well known data types are used and embedded inside the client-accessible code.
env-Local env-Embedded env-ClientServer env-Peer2Peer2 Inconclusive Proprietary data encodings are used. Although this incrementally increases the difficulty for an attacker to decode the data, it provides no better protection than well-known data types. Since few software developers are trained in obfuscation and cryptography, most proprietary encodings add little security value.
env-Local env-Embedded env-ClientServer env-Peer2PeerOutcomes
ID type Outcome Description 1 Success The attacker extracts useful information.Security Controls
ID type Security Control Description 1 Corrective The software can contain an update mechanism, key management mechanism, or other means of updating proprietary data. Although this can react to a single breach, it is not an effective continuing solution. Many software manufacturers are lured into a repeated update cycle (c.f., satellite TV providers, iPhone) as hackers break proprietary data protection schemes. Planning to issue corrections is a poor long-term strategy, but it can be an effective stopgap measure until a design-level correction can be made.
Attack PrerequisitesIn order to feasibly execute this class of attacks, some valuable data must be present in client software.
Additionally, this information must be unprotected, or protected in a flawed fashion, or through a mechanism that fails to resist reverse engineering, statistical, cryptanalytic, or other attack.
Typical Likelihood of ExploitLikelihood: Very High
Methods of Attack- Analysis
Examples-InstancesDescription
Using a tool such as 'strings' or similar to pull out text data, perhaps part of a database table, that extends beyond what a particular user's purview should be.
Description
An attacker can also use a decompiler to decompile a downloaded Java applet in order to look for information such as hardcoded IP addresses, file paths, passwords or other such contents.
Description
Attacker uses a tool such as a browser plug-in to pull cookie or other token information that, from a previous user at the same machine (perhaps a kiosk), allows the attacker to log in as the previous user.
Attacker Skills or Knowledge RequiredSkill or Knowledge Level: Medium
The attacker must possess knowledge of client code structure as well as ability to reverse-engineer or decompile it or probe it in other ways. This knowledge is specific to the technology and language used for the client distribution
Resources RequiredThe attacker must possess access to the client machine or code being exploited. Such access, for this set of attacks, will likely be physical. The attacker will make use of reverse engineering technologies, perhaps for data or to extract functionality from the binary. Such tool use may be as simple as "Strings" or a hex editor. Removing functionality may require the use of only a hex editor, or may require aspects of the toolchain used to construct the application: for instance the Adobe Flash development environment. Attacks of this nature do not require network access or undue CPU, memory, or other hardware-based resources.
Probing TechniquesAttackers may confine (and succeeed with) probing as simple as deleting a cache or data file, or less drastically twiddling its bits and then testing the mutation's effect on an executing client.
At the other extreme, attackers capable of reverse engineering client code will have the ability to remove functionality or identify the whereabouts of sensitive data through whitebox analysis, such as review of reverse-engineered code.
Attack Motivation-Consequences- Information Leakage
- Data Modification
- Privilege Escalation
Injection VectorThis pattern of attacks possesses no injection vector, in its normal instances, as it affects clients fundamentally vulnerable to client-side trust issues. One exception to this rule exists: attacks making use of second-order injection attacks (SQL, XSS, or similar command injection) may 'deliver' an attack, through an intermediate server or data store, to a peer-client, or another user's use of the same client. In the case of the second instance (another user's use) this vector seems onerous but would be necessary in circumstances in which the hosting system protects the application well but implicitly trusts (potentially malicious) data received from the server (such as may be the case in kiosks well-protected through physical means).
Activation ZoneClient-side software, whether it be a monolithic application, client/server, or n-tier (web-based).
Related Weaknesses| CWE-ID | Weakness Name | Weakness Relationship Type |
|---|---|---|
| 311 | Missing SecurityDatabase\Encrypt\Encryption of Sensitive Data | Targeted |
| 525 | Information Leak Through Browser Caching | Targeted |
| 312 | Cleartext Storage of Sensitive Information | Targeted |
| 314 | Plaintext Storage in the Registry | Secondary |
| 315 | Plaintext Storage in a Cookie | Secondary |
| 318 | Plaintext Storage in Executable | Secondary |
Related Attack Patterns| Nature | Type | ID | Name | Description | View(s) this relationship pertains to |
|---|---|---|---|---|---|
| ChildOf |  Attack Pattern | 167 | Lifting Sensitive Data from the Client | Mechanism of Attack (primary)1000 | |
| ParentOf | Attack Pattern | 65 | Passively Sniff and Capture Application Code Bound for Authorized Client | Mechanism of Attack1000 | |
| ParentOf | Attack Pattern | 204 | Lifting cached, sensitive data embedded in client distributions (thick or thin) | Mechanism of Attack (primary)1000 | |
| ParentOf | Attack Pattern | 205 | Lifting credential(s)/key material embedded in client distributions (thick or thin) | Mechanism of Attack (primary)1000 |
Relevant Security RequirementsNo sensitive or confidential information must be stored in client distributions. This includes content such as passwords or encryption keys. In cases where this is necessary, avoid storing any such information in plaintext
All information arriving from a client must be validated before use.
Related Security PrinciplesReluctance to Trust
Never Assuming that Your Secrets Are Safe
Related GuidelinesNever Use Unvalidated Input as Part of a Directive to any Internal Component
Treat the Entire Inherited Process Context as Unvalidated Input
Use Well-Known Cryptography Appropriately and Correctly
Purposes- Reconnaissance
- Exploitation
CIA Impact Technical Context| Architectural Paradigms | All |
|---|---|
| Frameworks | All |
| Platforms | All |
| Languages | All |
Content History| Submissions | ||||
|---|---|---|---|---|
| Submitter | Organization | Date | Comments | |
| John Steven | Cigital, Inc | 2007-02-10 | Initial core pattern content | |
| Modifications | |||||
|---|---|---|---|---|---|
| Modifier | Organization | Date | Comments | ||
| Chiradeep B. Chhaya | Cigital, Inc | 2007-02-23 | Fleshed out pattern with extra content | ||
