Adobe Flash Zero-Day Attack Uses Advanced Exploitation Technique

On February 7, Adobe issued a security bulletin warning of zero-day attacks that leverage two Flash vulnerabilities. One (CVE-2013-0634) is related to ActionScript regular expression handling. (Some sources refer to this vulnerability as CVE-2013-0633. We are waiting for Adobe to confirm the proper CVE ID.)

McAfee Labs rapidly responded to the threat. While digging in depth into the original sample, we found that the exploit uses highly sophisticated exploitation techniques to attack various Flash Player versions. It also includes “user-friendly” tricks that give no signs or symptoms to its victims.

The ingenious exploit uses a previously unknown technique to craft the heap memory on Flash Player. With the aid of a regular expression-handling vulnerability that is related to a heap-based buffer overflow, the attack can create a highly reliable memory information leak that allows the exploit to bypass the usually effective exploitation mitigations of address space layout randomization (ASLR) and data execution prevention (DEP) on Windows 7 and other versions.

More important, the technique looks like a common exploitation approach to Flash Player. The vulnerability actually doesn’t help much–just overwriting few bytes that are considered as a field of “element number” for a specific ActionScript object. These traits show that the exploitation technique is not limited to this particular Flash vulnerability; it may apply to other Flash or non-Flash vulnerabilities.

McAfee Labs has learned the full details of this exploitation technique, and plan to publish our analysis in the near future. Watch this space for updates.

At this moment, considering the dangerousness of the attack, we strongly recommend that all users update their Flash Players. The official patch is available here. Though the patch doesn’t kill all exploitation techniques, it will keep systems immune to the current exploits in the wild.

For McAfee customers, various protections are provided. We have released signature “0x402df600_HTTP_Adobe_Flash_Player_CFF_Heap_Overflow_Remote_Code_Execution” for the exploits related to CVE-2013-0633 and “0x402df700_HTTP_Adobe_Flash_Player_ActionScript_Buffer_Overflow_Remote_Code_Execution” for CVE-2013-0634 for the Network Security Platform appliances. Also, the generic buffer overflow prevention feature on our HIPS products will stop the related attacks.

 

Thanks to Bing Sun, Xiaobo Chen, and Chong Xu for their help with this analysis.

Cross-Platform Frutas RAT Builder and Back Door

Contributor: Val S.

We recently came across a sample of a back door remote access tool (RAT) written entirely in Java. The RAT is freely distributed on underground forums, free for any registered forum user to download. It is named Frutas, which means “fruit” in Spanish.
 

Figure 1. Frutas logo
 

The Frutas RAT allows attackers to create a connect-back client JAR file to run on a compromised computer. When executed, it parses an embedded configuration file for a server IP and port to connect to. The back door builder provides some minor obfuscation, which allows the attacker to use a custom encryption key for some of the embedded back door functionalities.
 

Figure 2. Back door client creation
 

Upon receiving a back door connection, the RAT server alerts the attacker and allows them to perform various back door functions on the compromised computer, including:

  • Query or kill system processes
  • Browse file systems
  • Download and execute arbitrary files
  • Send popup messages
  • Open a specified website in a browser
  • Perform denial of service attacks against a specified IP address

Figure 3. Back door functionality
 

Figure 4. Example pop-up message sent to users
 

The back door Java file uses a custom class loader that loads encrypted class files (named Opcion[1-14]) as it receives commands from the RAT controller server. The key, specified by the attacker when creating the back door, is used to encrypt the class files using DES as a stream cipher.
 

Figure 5. Back door Java decompilation
 

This is a low prevalence remote access tool that is targeted at, although not limited to, the Spanish hacker base. This can be seen in the low detection rate. Symantec detects the back door controller and builder as Hacktool and the back door as Backdoor.Trojan.
 

Figure 6. Current detection status
 

To protect yourself from becoming a victim of this remote access tool it is essential that you keep your computer up to date by applying the latest updates, along with keeping your antivirus definitions up to date.

TOGAF Demystification Series: TOGAF Doesn’t Play Well With Others

Fit Together

In this post in the TOGAF demystification series I will talk about how well or not so well TOGAF plays with other frameworks in the industry. In my last post this topic was brought up and I see it on the LinkedIn forums as well.

So let's talk about this myth that TOGAF doesn't play well with other frameworks. So what do I mean by that? The myth is that TOGAF is all about TOGAF or is monolithic in nature. This is far from the truth. TOGAF is a truly unique framework in that it really does embrace the notion of a better together story with other frameworks and approaches to solving problems. This better together story is all about bringing in other frameworks to complement, reuse and ultimately reduce the amount of duplicate methods in the industry. The thought process must be, if it works for them then it should work for us too. 

A great example of this is at the absolute core of TOGAF. A core concept of "Architecture" is not defined by TOGAF but rather by ISO/IEC 42010:2007 (formally known as IEEE 1471). Of all areas to define yourself and be justified, TOGAF doesn't do so. It takes in the definition and applies it to the architecture framework. TOGAF provides guidance around the definition and meta-model given that it was created outside any one methodology / framework. 

Below is the actual text from TOGAF:

TOGAF considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 - ensuring that usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard - and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to 3. Definitions and Part IV, 35. Architectural Artifacts.

As you can see above, while many other frameworks feel that they have to make it their own in an self-interested type of way, this isn't the case with TOGAF. There is clear evidence that that TOGAF is doesn't have the "must be invented here" syndrome  and will not duplicate the approaches in other methods. I applaud them for that level of leadership in the industry where it is a common practice in the overall technology and architecture fields respectively to do deliberately duplicate meanings, approaches and overall methods for doing things. 

One last area of note, in most phases in the ADM the first step is essentially to establish how you want to perform that phase. In this step you as the EA are to select the methods, approaches, reference models, architecture or standards and apply them to the problem you are solving in that phase. This is essentially saying is:

  • Not every architectural problem needs a prescriptive process. 
  • USE YOUR JUDGEMENT when applying architecture process and rigor.
  • If TOGAF doesn't have something that solves your problem fill the gap.
  • Reusable architecture building blocks are the key to accelerating predictable results, TOGAF is architected to support this.

Lastly, TOGAF has published many mappings to other frameworks. In the specification you can find references to ISO, IEEE , PMI, Zachman and DODAF to name a few.

Below is a listing of some of those mappings (not all inclusive):

 

Note: Some of these mappings were done with older versions of TOGAF. However, there should be minimal gaps and provides the intent of a better together story. 

FCC invests $10M in new network security but leaves backdoor unlocked

In August of 2011, while in the middle of upgrading its network security monitoring, the Federal Communications Commission discovered it had already been hacked. Over the next month, the commission's IT staff and outside contractors worked to identify the source of the breach, finding an unspecified number of PCs infected with backdoor malware.

After pulling the infected systems from the network, the FCC determined it needed to do something dramatic to fix the significant security holes in its internal networks that allowed the malware in. The organization began pulling together a $10 million "Enhanced Secured Network" project to accomplish that.

But things did not go well with ESN. In January, a little less than a year after the FCC presented its plan of action to the House and Senate's respective Appropriations Committees, a Government Accountability Office audit of the project, released publicly last week, found that the FCC essentially dumped that $10 million in a hole. The ESN effort failed to properly implement the fixes, and it left software and systems put in place misconfigured—even failing to take advantage of all the features of the malware protection the commission had selected, leaving its workstations still vulnerable to attack. In fact, the full extent of the problems is so bad the GAO's entire findings have been restricted to limited distribution.

Read 9 remaining paragraphs | Comments