Archive for February, 2011

In-depth Analysis of PDF Security

PDF, a portable file format, had gained popularity among general users due to its extensive features, portability and availability of free tools to read and author the documents. With the increasing popularity this file format has gained among the general users, it has also become vulnerable to various malware which exploit the document for executing malicious attacks, and which uses the PDF files as malware depositing source to attack specific item or even the entire system.

Over the last three or four years, PDF malware have become increasingly devastating for computer security. The reason behind this increasing success is the achievement of blackhat community in attaining the hand-full of PDF distribution with which various malicious PDFs are being utilized to jeopardize the computer’s security. Before going into the depth of the PDF security system, let’s get a closer look at the different distribution channels, the attackers use to deposit malware in the computer. Among a variety of different PDF distribution channels, three dominating channels are Mass-Mailing, Drive-By Downloads, and Targeted Attacks.

In mass-mailing PDF distribution technique, a user is lured to open an email and receives the malware unsuspected by downloading the attached PDF file in the email. These kind of spam emails contain major subjects like IRS emails, Political or current affairs or any controversial subjects. While, drive-by -downloads deposits the malware into the system when the user visits an infected website and downloading a hosted PDF file. Malware authors utilize web exploits packs to trigger malware creation on websites. The hosted PDFs contain shell codes which on being executed download malicious content from the internet. In contrast, PDF targeted attacks are directed to individuals or organizations to give themselves a disguise of an authentic source which, consequently, will enable the user to launch the PDF file attached. What makes targeted attacks relatively successful is the use of zero-day exploits which renders the victim unaware of the fact that his system’s security is at stake.

Now, to make matters worse, each distribution channel uses different exploit techniques which are classified into two categories, namely: JavaScript based exploits and Non-JavaScript based exploits. Now, almost all the PDF exploits are utilizing JavaScript in different forms because of its use of a malicious code called heap spray code (a JavaScript code that is executed at first to set up the process memory of the reader with a shell code which as a result exposes the system to the malicious attack).

Utilizing exploit techniques in different PDF distribution methods might have given the antiviruses and malware detection products to detect the presence of malicious PDF or the attack incorporated within the PDF file. To evade the possibilities of coming into antivirus detection, Malicious Acroform Stream is utilized by malware authors. This kind of evasion method misleads the user to believe that the malicious PDF file is simple a corrupt file and crashes the PDF reader so that it keeps on working in the background and remains undetected from both the user and the virus detecting product.

When your system’s security is jeopardized and various significant items are exposed to vulnerability, what can you do to protect your system to be infected with malicious content?

A bundle of considerable protective actions can be taken by the user which may keep his system safe from possible targeted or un-targeted attack from malware authors.

First and the foremost way to avoid system infection are keeping it up-to-date with all applications and softwares patches for your PDF reader. Second of all, keep your virus-detecting product up-to-date. Wherever possible, disable JavaScript so that the JavaScript based exploits may be prevented. Last but not the least; considerable discretion should be exercised while executing a PDF document from an untrusted location.

Internet Explorer CSS 0day

Vulnerabilities, malwares and exploits have been out there since the existence of software themselves. Running with malicious intentions, these programs have always been a thorn in application developers’ sides, and keep ongoing a continuous game of cat and mouse between developers and attackers.

Being the most popular OS in the world, Windows and its associated applications have been the most frequent target of malicious exploits, and Internet Explorer is no exception. Back in December 2010, a new vulnerability affecting IE 6, 7 and 8, running Windows Vista and above was published on a full-disclosure security list, labeled IE CSS 0-day vulnerability and was later addressed in Microsoft’s Security Advisory 2488013.

This exploit reportedly targeted users of IE 6 through 8, allowing the execution of a malicious code on an affected user’s computer through the currently logged in account just by visiting a website containing a malicious CSS script. Microsoft currently believes the attack hasn’t affected many users, and while it can be easily circumvented, it is a serious threat that can be used at a much larger scale causing massive damage.

Let’s try to understand how this whole thing works. As the name suggests, this vulnerability relies on a loophole within Internet Explorer’s processing of Cascading Style Sheets (CSS). Normally, a CSS file (which dictates the look and feel of an HTML file) would already be loaded when you visit a website, but if the style sheet imports itself, it wreaks havoc on IE’s memory management, allowing any unauthorized code to execute while bypassing the usual IE downloads’ security checks, including the new Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).

DEP is designed to perform additional checks on memory to help prevent malicious code from running on a system. Specifically, if a remote attacker manages to crash a running application on your system, the areas of memory where the application stored its run-time data, including stack and heap, are marked un-executable, so even if malicious code makes it into memory bytes, the operating system would prevent it from running. Hence, DEP will prevent any unauthorized code execution unless the attack targets those memory sectors where code has already been marked executable, which is where ASLR comes in.

ASLR loads programs and DLLs in a different, random location each time they are executed, and since bypassing DEP requires you to know exactly where executable code is going to be, the randomization offered by ASLR ensures that the attacker can never accurately predict which memory blocks to target. He may opt to perform a search operation, but the code required to perform the search would be blocked by DEP in the first place. Hence, from the outside, it would seem that Microsoft has created the perfect security barrier.

Hats off to Microsoft, though, for they have, most unfortunately, allowed each DLL to decide for itself whether it supports ASLR or not. The Internet Explorer is a huge collection of DLLs itself, some of which execute at run-time to render the content that IE downloads. Now, with a malicious CSS code causing a memory heap to go berserk, the attacker would send otherwise-safe files to IE causing it to load the known DLLs. And, if any of these DLLs does not support ASLR (which they don’t), then their location in the memory is already known, and DEP simply goes out the window. One specially designed web-page is all a malicious attacker needs to gain execution access on your machine, without your knowledge at all.

While most modern browsers have entirely switched to the newer, safer versions of CSS handling, Microsoft’s prized internet browser still utilizes the same old DLLs to handle CSS rendering, and with the still-very-large user base of IE, such exploits can become disastrous should someone decide to take advantage of it. Microsoft’s security advisory suggests that the exploit is public knowledge, but neither used on a mass level yet nor critical enough to merit an out-of-band security release.

While Microsoft figures out a patch, one easy workaround could be to use Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). This would allow you to force named applications to perform ASLR on every DLL that is loaded, irrespective of whether the DLL supports it or not. That way, DEP again comes into effect for every code that depends on a memory overload, and would at least bypass this particular vulnerability.

Godaddy Web Interface Cross-Site Scripting (XSS) Vulnerability

Exploit Database recently found an interesting vulnerability regarding Godaddy which is a leading domain and website hosting provider. The Godaddy workspace XSS vulnerability provides liberty to the attacker to send malicious JavaScript to the victim resulting in stealing of cookies and other malicious activities. This means that if you are using web interface of Godaddy workspace, a malicious attacker can obtain your session information and can even login to your account interestingly without using any credentials.

Following are the steps for exploiting Godaddy XSS vulnerability:

  1. Attacker logs in to the Godaddy workspace interface.
  2. Composes an email directed towards the targeted user.
  3. Uses firebug to craft malicious link using JavaScript in the email. This JavaScript is capable of capturing victim’s cookie (session id) and sending it to attacker controlled web server.
  4. The email is sent to the targeted user (victim) who also uses Godaddy web interface.
  5. The victim receives the email and opens it.
  6. As soon as the email is opened the victim’s session id is obtained by the malicious JavaScript and sent to the attacker controlled web server.
  7. To make sure that there are no credentials required to exploit this vulnerability the attacker logs out from his account and clear the cache and cookies.
  8. The attacker receives victim’s cookie (session id) from web server log and replays it using Live HTTP Headers (Firefox addon) to Godaddy.
  9. The attacker successfully logs into the victim’s Godaddy web interface.
c viictims cookie from web server logs

, ,

Copyright © Rewterz. All rights reserved.