PDF Exploitation & Forensic Resources

A new report from security vendor ScanSafe indicates that attacks continue to increase, with a single user seeing 77 compromised websites in May of 2007, compared to 1024 sites in May 2009.  Data theft Trojan exposures increased from 0 in May 2007 to 307 events in May 2009.


ScanSafe Article:  http://www.scansafe.com/downloads/gtr/2009_AGTR.pdf



By far the new leader on the threat horizon is malicious PDF files exploiting flaws in Adobe Reader or Acrobat which outpaced the use of Flash exploits, and also grew to 80% of all exploits that the company encountered.  This trend most likely indicates a combination of the increasing availability of vulnerabilities in Adobe products and the continued popularity and acceptance of PDF files in both the workplace and home user sectors.  Attackers will exploit whatever is most exploitable.




From a criminal’s point of view, tactics have evolved from wide-scale attacks to today’s focused ‘business’ model, directly targeted like a marketing campaign, and driven by web-based malware kits capable of automatically enumerating applications and browser plug-ins, and serving up the appropriate exploits.  The optimization of malicious traffic has been an active strategy for several years, with the attackers realizing that the more exploits they introduce with their kits, the higher the probability of a successful infection.  The apparent preference for Adobe exploits is really a direct result of the market penetration of Adobe products, and the wide spread use of out-of-date PDF readers and Acrobat versions.


Case Study


Case in point is the continued use of CVE-2007-5659; CVE-2008-2992; CVE-2008-0015; CVE-2009-0927; and CVE-2009-4324.  These are not new exploits, and the choice to continue using these older exploits seems to imply a basis on metrics based on the hundreds of thousands of visitors hitting their fraudulent online properties.  In this case, why bother wasting money on picking up a zero day exploit on the underground market when they already know that millions of users are susceptible to two year old exploits?




Didier Stevens has provided a fantastic resource and tools for analyzing PDF files.  Some of these resources have been incorporated into VirusTotal.    Didier Stevens:  http://blog.didierstevens.com/programs/pdf-tools/


Ray Yepes has provided an excellent article for locating MYD files, mySQL database files used by Adobe Organizer to maintain information about PDF files that have been accessed.  

Ray Yepes:  http://www.issa.org/Library/Journals/2008/April/Yepes-PDF%20Forensics-Uncovering%20MYD%20files.pdf


Forensic Tools & Updates

Here are some great tools and a few updates that might prove useful.

Web Browser Forensics

When I think “browser forensics”, I tend to think about cache and cookie files.  There’s more to it than that.

  • Harry Parsonage has put together an excellent resource describing web browser session restore forensics. 
  • Here‘s some additional value add to Harry’s information, from the sausage factory. 
  • Woany has released a tool inspired by this paper.  
  • Woany also has other tools available for parsing data that may be associated with web browser forensics, as well as from other sources, including ForensicUserInfo and RegExtract
  • NirSoft provides an excellent utility for password recovery and other purposes. 
  • If you’re analyzing an acquired image, you may need to boot the with LiveView and login to run some of the tools. 
  • JADSoftware has several excellent tools, including a couple of free ones.  I like free.
  • Finally, some other browser stuff that might be of interest.  in particular bookmarks and favorites.

Jeff Hamm has written an excellent paper regarding Google Toolbar Search Artifacts and a separate paper regarding the Adobe Photoshop Album Cache File.

Vendor Vulnerability Analysis – How To Part 3


Vendors deliver patches, updates and upgrades in very different ways.  Some require their users to remain informed and patch manually.  Others will notify their constituents by email that a patch or update is available, and provide download links for the patches.  Still others will provide notifications in the software, and allow the user to configure how these updates are handled.

These strategies work great for one-off applications, home users, and the smallest of businesses, however the medium to enterprise class environment is moving towards automated delivery for several reasons.  They are looking for methods to centralize testing, deployment and inventory so as to maintain a standard build.  This build is kept as close to the same as possible in order to control costs, minimize special handling requirements when troubleshooting, simplify system upgrades and replacement, and to meet regulatory requirements regarding system hardening and access controls.

Vendors also need to be cognizant of the fact that malicious users will send out authentic looking emails to take advantage of the vendor’s customers or seek ways to attack auto-update mechanisms if the vendor pursues these methods of delivery.


As vendors release patches to fix vulnerabilities, these too need to be assessed.  They should be assessed using the same methods used to assess the vulnerability they were meant to address.  Look for answers to the same questions, but this time, the focus is on how quickly has code developed or expected to develop, and how quickly do we need to patch, rather than what damage can be done.  Not that the other questions are irrelevant, just that now there is immediacy on fixing the root cause of the problem.  Removing the vulnerability.

  • How serious is the impact of the vulnerability if exploited?
  • How many vulnerable systems are present in the environment?
  • What is the most likely attack scenario and target base?
  • How far has exploit code development progressed?
  • What work-arounds, reconfigurations or other risk mitigation strategies remain applicable, or should be removed?

  Continue reading

Vendor Vulnerability Analysis – How To Part 2


There are many ways to assess vulnerabilities.  CERT/CC produces a numeric score ranging from 0 to 180, considering factors such as whether the Internet’s infrastructure is at risk and what sort of preconditions are required to exploit the vulnerability.  The SANS vulnerability analysis scale considers whether the weakness is found in default configurations of client or server systems.  Microsoft’s proprietary scoring system tries to reflect the difficulty of exploitation and the overall impact of the vulnerability in general and broad terms.  I prefer to use the CVSS or Common Vulnerability Scoring System, to provide a uniform and reliable assessment framework.  CVSS takes into consideration what I consider the 3 key information elements that need to be considered when assessing a vulnerability:

  • BASE components:  Represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments.  These include Access Vectors for exploiting the vulnerability, Access Complexity for how difficult it is to exploit, Authentication to measure what level is required to exploit, and the impacts of successful exploitation to confidentiality, integrity and availability.
  • TEMPORAL components:  Represents the characteristics of a vulnerability that change over time but not among user environments.  These include Exploitability indicating how far code has progressed, Remediation Level indicating what fixes are available, and Report Confidence which examines sources of information.
  • ENVIRONMENTAL components:  Represents the characteristics of a vulnerability that are relevant and unique to a particular user’s environment.   These include Collateral Damage Potential to estimate costs, Target Distribution to estimate relevance and spread, as well as requirements for confidentiality, integrity and availability sensitivity of the organization.

The purpose of the CVSS base group of metrics is to define and communicate the fundamental characteristics of a vulnerability. This objective approach to characterizing vulnerabilities provides users with a clear and intuitive representation of a vulnerability.  Analysts can then invoke the temporal and environmental groups to provide contextual information that more accurately reflects the risk to their unique environment. This allows for more informed decisions when trying to mitigate risks posed by the vulnerabilities.

Questions that should be asked when preparing or performing a vulnerability assessment include:

  • What are my most valuable systems and data?
  • What are my most vulnerable systems and data?
  • What systems and data is the business charged with protecting from a regulatory perspective?
  • What services is the business charged with protecting from a regulatory or contractual perspective?
  • What are the basic characteristics of the vulnerability?
  • How serious is the impact of the vulnerability if exploited?
  • How many vulnerable systems are present in the environment?
  • Are there any preconditions or requirements for exploitation?
  • What is the most likely attack scenario and target base?
  • How far has exploit code development progressed?
  • Has there been an actual attack in the wild?
  • How will I know of additional code developments?
  • Are there characteristics that could serve as indicators of attack?
  • Are there IDS signatures that may help to detect exploitation?
  • Are there anti-virus signatures that may help to prevent exploitation?
  • What work-arounds, reconfigurations or other risk mitigation strategies are applicable?

Continue reading

Vendor Vulnerability Analysis – How To Part 1

In a given environment, whether small, medium, large or enterprise class, there are a multitude of systems involved in keeping the business running, and providing that connection with the customer.  Every system is a machine, and machines need servicing often.  Part of that servicing is to introduce improvements and corrective measures, especially regarding security, since that is the area that will be directly attacked in order to impact your business, provide others a competitive edge, or outright theft from your business and customers.

Long gone are the days when you could stand a server up, connect it to the internet and seldom think about that server again.  Firewalls can keep out the obvious attacks, but fixing the root cause is still the best method for avoiding disaster.

TARGETS – Opportunity & Choice

Targets of Opportunity:  These are places that are often stumbled upon when researching the reach and spread of a given vulnerability.  A researcher discovers a vulnerability that can allow them to take over entire networks.  How far and wide is the vulnerable product deployed?  Where is it directly exploitable, and what supporting mechanisms will aid in attacking protected targets?  Targets of opportunity are typically attacked because they are vulnerable to a discovered vulnerability, and may lead to simplifying the attack of a target of choice.  They are often connected to many other organizations through a variety of means and relationships.  These relationships can be exploited as easily or more so than their networks.

Targets of Choice:  Why do bank robbers rob banks?  Because that is where the money is.  Targets of choice are any business that holds items of interest and value to the attacker.  Banks are by no means the only targets of choice, any organization or government installation that holds trade or other secrets, data that can be used to gain money, information, power or an advantage over others is sought after.  Any organization that holds credit card information, personal information, identity credentials, cash or tradable commodities, provides goods and/or services (and what business doesn’t?) is at risk of having those resources targeted, harvested, and potentially stolen.


The lifecycle of a typical vulnerability is:

  • Research
  • Discovery & Announcement
  • Vulnerability Assessment
  • Mitigation Development
  • Patch Development
  • Patch Delivery
  • Patch Analysis
  • Patch Deployment
  • Deployment Validation
  • Vulnerability Verification

Continue reading