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
Explore
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.
Package listing. The attacker uses a package
manifest provided with the software installer, or
the filesystem itself, to identify component files
suitable for attack.
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.
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.
Experiment
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.
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-Embedded
3
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.
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-All
5
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-All
Indicators
ID
type
Indicator Description
Environments
1
Positive
Well known data types are used and embedded
inside the client-accessible code.
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.
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 Prerequisites
In 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 Exploit
Likelihood: Very High
Methods of Attack
Analysis
Examples-Instances
Description
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 Required
Skill 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 Required
The 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 Techniques
Attackers 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 Vector
This 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 Zone
Client-side software, whether it be a monolithic application, client/server,
or n-tier (web-based).
No 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 Principles
Reluctance to Trust
Never Assuming that Your Secrets Are Safe
Related Guidelines
Never 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
Vision and Technical Leadership provided by Cigital, Inc.
This Web site is hosted by The MITRE Corporation.
Copyright 2009, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.
Description
