Adobe

All posts tagged Adobe

It’s been a while since my last post so I thought I’d post this article on heap spraying using Adobe Flash which I have been working on to get a better understanding of the ActionScript language, hopefully it will benefit some readers to test their security layers in their own environment.

After analysing some actual exploits which were using Flash to spray the heap I decided to use the relevant code and started customising it for my own testing purposes. I was surprised that a handful of Endpoint Protection products I tested on failed to detect any sort of heap spray. Spraying using JavaScript or DEPS does however get detected but I’m not sure how it well it would stand if the code were to be obfuscated. Below is a screenshot of the ActionScript spray so you get the idea.

A good portable tool to decompile flash files which I use is “AS3 Sorcerer”. There are some nice features, definitely worth the purchase.

“ActionScript Extractor” is another good and free portable tool but has a bug as when decompiling certain flash files triggers a crash. I didnt investigate this issue if its exploitable so be careful using this tool. Also you’ll most likely need to make more corrections to the code if wanting to recompile again.

I did a quick test on all the major browsers spraying 100 times with 1mb chunks. In the image below it’s interesting to see its child processes of each of the browsers and different integrity levels. Bypassing browser sandboxes is something I’ll be researching in the future so if I do discover anything interesting I’ll be sure to blog about it.

Finally here is the code and examples you can download from here. Password is “exploit” and MD5 hash is 98afdc19007a65be636cc0a8d9fe8d9d .  It includes the exploit for IE’s CVE-2012-4792 using JavaScript, DEPS and Flash. You can use SWFTools as3compile.exe to compile but I mainly used Adobe’s Flex SDK. Here is the direct link for version 4.6.

References:

http://www.adobe.com/devnet/flex/flex-sdk-download-all.html
https://www.corelan.be/index.php/2013/02/19/deps-precise-heap-spray-on-firefox-and-ie10/
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/utils/ByteArray.html

In this post I am providing a solution to a problem some of our users had encountered. When users were starting up Adobe Reader X an exception was triggered in process AcroRd32.exe. Observing the crash details the memory addresses was always the same and module was always pgphk.dll. Taking a look at the properties of this library told me that it comes shipped with the PGP Desktop software.

After some investigative work I figured out what was actually happening:

1. PGPTray.exe executable gets loaded from the start-up.
2. This process loads up the library PGPhk.dll in PGPTray.exe process space.
3. Thereafter any new process opened the library PGPhk.dll gets injected in its process space.

So say if you load up Windows Calculator you’ll see PGPhk.dll in calc.exe. Due to this injection happening in AcroRd32.exe process it causes Adobe Reader to crash as by default Adobe Reader X runs in protected mode. Why PGP software does this injection in every process that I can’t say but is the cause of the problem.

Now there are a couple of ways around this:

1. Just don’t load PGPTray.exe executable and thus won’t load PGPhk.dll
2. Disable Adobe Reader in “Protected Mode” but I strongly advise not to do so, this shouldn’t be seen as a solution but only if there is no other options.
3. Upgrade to the latest version of PGP Desktop 10.1 which fixes the issue. This is the best action to take as you will be also fixing any previous vulnerabilities in its product. The version I had problems with was 9.5.3.
4. Create a whitelist excluding PGPhk memory section from Adobe Readers protected mode. The way to add this to the exclusion is to take the steps below.
 
  i.   Add a registry entry enabling the use of whitelisting:
        [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockDown]
       “bUseWhitelistConfigFile”=dword:00000001
  ii.  Create a whitelist file called “ProtectedModeWhitelistConfig.txt” and place it
       in the Adobe Reader executable path i.e. C:\Program Files\Adobe\Reader 10.0\Reader
  iii. The ProtectedModeWhitelistConfig.txt file will need to contain the string
       SECTION_ALLOW_ANY = *PGPhk*

Check out Adobe’s Application Security Guide document which is a very good document worth reading. Another point to mention is that if you try to rename PGPhk.dll library then PGP Desktop will only try to re-install it again. Another way to test is to close the handle PGPhkSharedMemory before starting up Adobe Reader and you’ll find that Adobe Reader loads up fine.

When you enable Adobe Readers “Create Protected Mode log file” and view the log file AdbeReaderBroker.log you will see something like this below. This is if the exclusion is not added to the whitelist giving you information you need to add future exclusions in the whitelist.

[03:11/09:08:06] Adobe Reader Protected Mode Logging Initiated
[03:11/09:08:08] NtCreateSection: STATUS_ACCESS_DENIED
[03:11/09:08:08] real_path: \BaseNamedObjects\PGPhkSharedMemory
[03:11/09:08:08] Consider modifying policy using this policy rule: SECTION_ALLOW_ANY

References:

http://forums.adobe.com/thread/755098
http://learn.adobe.com/wiki/display/security/Application+Security+Library

After a week of this 0-day vulnerability being reported a number of posts have been published over the last few days detailing the disassembled malicious flash (swf) file exposing the invalid byte triggering the vulnerability. The vulnerability is caused when handling a “newfunction” instruction by Adobe’s ActionScript Virtual Machine 2 (AVM2). The vulnerability lies in both Adobe Reader and Adobe Flash so either product is vulnerable to attack. This post Im focusing on the actual malware that gets dropped when a malicious pdf file is opened.

After the pdf file is opened the first thing it does is process the malformed flash file in the pdf file which triggers the vulnerability dropping an executable in the root.

C:\-.exe

This file has been embedded in the pdf file making it portable without depending on any external sites to download and execute the malware. Once the dropped executable gets executed and a further 3 more files gets dropped onto the system.

C:\WINDOWS\EventSystem.dll
C:\WINDOWS\system32\es.ini
C:\WINDOWS\system32\dllcache\qmgr.dll

The original qmgr.dll file located in C:\WINDOWS\system32\ gets renamed to kernel64.dll and a malicious qmgr.dll takes it place. Also the original qmgr.dll file located in C:\WINDOWS\ServicePackFiles\i386\ gets replaced with the malicious qmgr.dll. The file Eventsystem.dll is a copy of the malicious dll file qmgr.dll and the file es.ini is just ascii file contains the text below used by qmgr.dll

[qmgrConfig]
ServerAddress=hxxp://210.211.31.214/ddradmin/ddrh.ashx
SleepTime=1000     
Guid=00000000-0000-0000-0000-000000000000

The final change to the system making sure the malware starts up everytime is changing the settings in a legitimate Windows service called “Background Intelligent Transfer Service” (BITS). By default the status is not started and startup type set to manual. This now becomes a started status with the startup type set to automatic. Thereafter when the system starts the service dll qmgr.dll gets loaded in memory when the BITS service is started.

Note that the time stamp has also been modified making it harder to trace if searching by date.

Adobe has now released an update for Adobe Flash 10.1.53.64 fixing the vulnerability. This resolves the issue if a swf file is opened via the web. For pdf files Adobe Reader update has not yet been released. One way to mitigate for now is to rename the following files:
 
C:\Program Files\Adobe\Reader 9.0\Reader\authplay.dll
C:\Program Files\Adobe\Reader 9.0\Reader\rt3d.dll

This analysis had been done using Adobe Reader version 9.3.2 with a pdf file having a md5 hash value of 721601bdbec57cb103a9717eeef0bfca

References:

http://secunia.com/advisories/40026/
http://www.kb.cert.org/vuls/id/486225/
http://www.adobe.com/support/security/bulletins/apsb10-14.html
http://www.adobe.com/support/security/advisories/apsa10-01.html
http://www.symantec.com/connect/blogs/analysis-zero-day-exploit-adobe-flash-and-reader
http://community.websense.com/blogs/securitylabs/archive/2010/06/09/having-fun-with-adobe-0-day-exploits.aspx