In the last few months, we have seen many blogs on PDF exploits related to filters like “ASCIIHexDecode”, “FlateDecode”, etc., being used to avoid Antivirus detection. The idea employed by attacker’s leverages different filtering techniques to hide malicious data so that it will be difficult to understand and decode. We have encountered many PDF exploits where either “[/FlateDecode /ASCIIHexDecode]” or “[/FlateDecode /ASCII85Decode]” filters are used. As defined by gnupdf, “the ASCIIHexDecode filter decodes data that has been encoded in ASCII hexadecimal form” and “the ASCII85Decode filter decodes data that has been encoded in ASCII base-85 encoding and produces binary data”. Interestingly, we have found another case, which Zscaler blocks, whereby both of the filters are used in the same PDF on different objects. This technique can be used to hide malicious code inside the PDF.
The following sample is still live on the web. Let’s open it in notepad and search for the “ASCIIHexDecode” or “ASCII85Decode” filters to see if they are used. Here is the screenshot where the “ASCIIHexDecode” filter is used:
If you look at the above image, there is something suspicious, a non-readable block of code in the 18 object with a length of 19343. The PDF is not blank and contains 4 pages text. The malicious code is injected toward the bottom of the PDF to avoid detection. Let’s decode it to see if it contains malicious JavaScript. The tool “pdf-parser.py” from PDF Tools supports both of the filters and easily decodes the code inside.
The decoded script is now shown above. The above malicious script is using special characters like @, _, ?, !, $, etc for substitution in one of the variables. If we remove these characters from the variable, you will see clear text malicious JavaScript code inside. Looking at the above JavaScript code, it does not contain any functionality to replace or remove these characters. Without such functionality, the code would be incomplete. We therefore need to look for additional functionality elsewhere in the PDF file. We later found another filter called “ASCII85Decode”, which included some additional suspicious code. Here it is:
Let’s decode this further using “pdf-parser.py” tool. The below command is used to decode this particular object. D:\pdf-parser.py --object=20 --raw --filter withSearch.pdf > out2.log Here is the decoded script for this filter,
That’s it. It does indeed contain additional malicious JavaScript. This is an interesting case where the script is divided into two parts, encoded using different filters and used in two different objects. This is done intentionally by the attacker to fool Antivirus engines and avoid detection. Let’s decode this script to see which PDF vulnerabilities it targets.
The above malicious JavaScript targets 3 old vulnerabilities,
collectEmailInfo() – CVE-2007-5659
Collab.getIcon() – CVE-2009-0927
.printf() – CVE-2008-2992
The above example showed that attackers are using different techniques to avoid Antivirus detection using different filtering mechanisms. Also, attackers are now splitting the scripts into parts, encoding them with different filtering techniques and putting them into different objects. Using this approach increases the complexity of decoding/detection. There are number of live PDF exploits on the web using these filtering techniques. Detection rates for the above example are very low. Only 13 antivirus vendors out of 42 detect this sample. The Virustotal results show that a number of popular Antivirus vendors are still missing the detection. This also shows that you can’t rely on a single protection mechanism like installing only an antivirus engine on your system. A combination of antivirus, IDS/IPS, URL filtering/categorization, etc is necessary in order to provide a defense-in-depth approach to security. We have seen an increase in client-side attacks like this as opposed to traditional server-side attacks. Attackers are not only targeting popular applications like PDF, Flash, etc., but they are also using a variety of techniques to deliver their malicious code as well.
In this morning's logs I noticed that Zscaler detected malicious content within redcross-esc.org web-pages. Turns out that the site was a victim of a malicious iFrame injection, and I thought a short post on this would be a good follow-up from Umesh's previous post on hidden malicious iFrames.
redcross-esc.org belongs to the American Red Cross East Shoreline Chapter and is hosted on GoDaddy. Pages infected include:
Screenshot of malicious iFrame: First stage decode: Final decode writes iFrame to hxxp://foxionserl.com/: Fortunately the foxionserl.com domain is not currently resolving, so the malicious page is not being pulled - Google results show that it had hosted a Adobe Acrobat PDF Reader exploit. Notifications are being sent to Redcross and GoDaddy.
People surf to a number of web pages throughout the day - online shopping, banking, social networking, search engines, etc. But do they know when something bad is happening behind the web page visible in their browser? A large number of legitimate web sites have been victim of attacks, where the payload modifies the pages on the website to include hidden Iframes to malicious content. This content is processed by the browser, transparent to the user, and can compromise the user’s system if they are running vulnerable client applications (for example, the browser itself, browser plug-ins, Adobe Acrobat reader, and Flash player).
Malicious Iframe attacks are not new but remain heavily used to carry out different attacks. HTML Iframe tags are used to embed content into the web page from a particular source, including sources external from the actual web site. Attackers are using zero pixel Iframes embed malicious content while to keeping content hidden from the user. People are often become victims from such attacks as it is easy to inject such malicious Iframes into a legitimate webpage by taking advantage of web application vulnerabilities like SQL injection.
Let’s walk through live example where a malicious Iframe has been injected in the webpage. Here is the screenshot of one of the website injected by Iframe,
The above screenshot shows obfuscated JavaScript is present in the webpage after the closing html “” tag (prior to the actual page body). Malzilla a user friendly GUI tool was used to decode the obfuscated JavaScript. You can find good documentation on their website.
Interestingly, the JavaScript decodes into another obfuscated JavaScript. There is small function called dF() and a call to the “document.write()” function. Below is a screenshot of decoding this further:
After decoding a second time, the JavaScript is clear and readable. This hidden injected Iframe embeds this JavaScript within the page, and when someone visits the page the JavaScript is processed by the browser, transparent to the user.If you look at the height and width of the Iframe, it is set to 1 pixel, which will not be seen by the user.
The above live example used multiple obfuscation techniques to hide the functionality of the malicious JavaScript. We have seen a number of websites infected with the same JavaScript code. The above example used “document.write()” function to write the malicious script into the page.Below is a decoded single obfuscated JavaScript example, which is still present on many websites:
Attackers are using simple to complex obfuscation techniques to encode their malicious script. Due to this, many Antivirus engines are unable to detect new injected Iframes. Here are the Virustotal results for the first example showing very low detection. Here is the third example of injected obfuscated script:
There are some important points to be considered here.
In the past, it was common for attackers to inject their malicious Iframes at the bottom / end of the webpage. Attackers are now injecting malicious Iframes anywhere in the webpage.
Many websites which were found to be infected in past months by malicious hidden Iframes appear to still be infected with them. Meaning most web site owners or hosting providers are not policing the content that they are serving on the web.
Our data shows many previously infected websites are still infected with hidden malicious Iframes today. Due to different obfuscation techniques detection by Antivirus vendors remains poor. This shows that even if it is a well-known attack, people are still at risk of being compromised. Web site owners and hosting providers should regularly patch any 3rd party web applications used to avoid known vulnerabilities (such as SQL injection), and regularly inspect their web pages for unauthorized modification (to include these malicious Iframes). Look out for obfuscated JavaScript within webpage’s, and for additions made prior to or following the HTML body tags. Users should patch all client applications (browsers, browser plug-ins, Adobe Acrobat, Flash, Java, Microsoft Office, etc.) used to view content pulled from the web. Additionally users can inspect the source of webpage and report compromised sites to the web site owner or hosting provider.
As we've discussed multiple times, search engine optimization (SEO) is a favored tool for spreading malware. Along with the Haiti earthquake and the Winter olympics, the recent earthquake in Chile is a top news story. Unsurprisingly, attackers have already set up new websites to spread malware.
knoxhop.org/?q=hawai-tsunami-2010 is one of these malicious sites. It currently ranks from 19 to 22 for a Google search of "Chile tsunami 2010" (2nd or 3rd page). It shows up even with Safesearch on. As you can see on the screenshot, my antivirus thinks the page is safe (see the green star next to the page title added by the antivirus).
Google search result for "Chile Tsunami 2010"
The page is typical of the malware sites I have seen recently - the harmful data is sent only if you arrive from Google search results. That is, if your referrer header contains the Google search URL. Direct access to this page, or the wrong user agent, gives you a harmless (but ugly!) web page.
Depending on the user agent, and the OS, the user gets different content. An iframe linking to a Russian website is added for all users. It is used to count the number of people hitting this page.
Mac users get redirected to http://www.zml.com/?did=5663. This is an affiliate link to the movie download site zml.com.
Chrome and Firefox users get an iframe to http://89.248.160.238/page.php?id=46 which contains obfuscated javascript. This URL is blocked by Firefox as a known malicious site.
Firefox warning
Internet Explorer and Opera browsers get an iframe to a fakeAV page.
With every new big events come new malware pages. Be aware of unknown website, even if the are displayed as top results on Google, and shown as safe by your antivirus!
The Cloud Security Alliance is working on a project entitled Top Threats to Cloud Computing, which will be published at the Cloud Security Alliance Summit during RSA 2010. For the past few months, we've assembled a panel of experts to debate the top security threats related to cloud computing and now it's your turn to participate. You can help us with this effort by completing the Top Threats Survey. The survey takes about 5 minutes to complete and will allow us to better understand the severity of the threats that we've identified thus far from the perspective of a broad audience. We'll present the summarized results of this survey at RSA. This project will continue to evolve after the conference as we solicit feedback to continually adjust the list to accommodate new threats. Stop by the Cloud Security Alliance Summit for the unveiling!