Recent Spike in NeoSploit Activity From Zscaler Research at Thu 11 March, 2010 - 02:37
This week I have seen a number of blocks to google.analytics.com.[a-z]*.info domains, for example,
google.analytics.com.okruvgbpfyyl.info
google.analytics.com.poaluygbcxu.info
google.analytics.com.hjhcgawqijc.info
google.analytics.com.kfyalnkfqhl.info
google.analytics.com.gxycidzewmed.info
The whois information shows that these domains have now been sink-holed by ShadowServer:
Redirection to these domains appeared to have occurred from heavily obfuscated JavaScript from the domain:
adrotator.mediaplex.feed-mnptr.com (currently resolves to 188.72.252.129)
This domain is still live, and is mentioned on a few sites (Kaspersky and Google SafeBrowsing) as being malicious, but is otherwise not generally well known at the time of this analysis.
Google searches for adrotator.mediaplex.feed-mnptr.com show that the iFrame has been injected into some popular websites, for example, mtv.com, a number of msn.com sites, and a whole host of other sites (evite, cnbc, buy, juno) - reference.
Once redirected to one of the www.google.analytics.com.[a-z]*.info domains, the victim receives JavaScript from what appears to be the NeoSploit exploit kit, where the following pages may be pulled down:
Java exploit: class.class, Main.class
PDF and Browser exploits: kav6.html, kav6.php, kav6.py, kav6%20.asp, AVORP1KAV6%20.asp, kav6.exe/
Payload (e.g., Fake A/V): kav6.exe
Are URL shorteners really dangerous? From Zscaler Research at Tue 09 March, 2010 - 20:41
There has been plenty of buzz about URL shorteners and security. URL shorteners have been described as a new attack vector since being popularized by social networks such as Twitter. I don't feel that URL shorteners are any more of a threat than their full length counterparts and here's why...
How URL shorteners work
The purpose of a URL shortener is to replace a log URL (e.g: http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html) with a shorter one (e.g: http://bit.ly/cikl0z). When a user clicks on http://bit.ly/cikl0z, he is redirected to http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html via an HTTP 301 redirection:
GET /cikl0z HTTP/1.1
Host: bit.ly
HTTP/1.1 301 Moved Location: http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html
----------------------------------------------------------
GET /downloadwhitepaper_stateofweb-q4-2009.html HTTP/1.1
Host: www.zscaler.com
HTTP/1.1 200 OK
The browser made two requests: one to http://bit.ly/cikl0 and one to http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html
Existing defense mechanisms
All the existing in-browser (Google Safe Browsing in Firefox, Opera's Fraud Protection, etc.) or external (IDS, proxy, etc.) URL scanners are applied on both the initial short and redirected long URL requests. If the long URL is a known malicious site, it will be stopped whether or not the the user clicks directly on the long URL, or on a shortened URL.
Firefox Safe Google Browsing warning on a URL after a redirection
Also, content inspection (Antivirus, Deep Packet inspection, etc.) is applied on both requests.
The use of URL shorteners and redirections does not require any new security inspection. All of the web browser security tools in place prior to the use of URL shorteners are still relevant.
Hiding the real URL
The main argument against URL shortening services is that users don't know which domain they are being redirected to. In our previous example, users see the bit.ly host name in the link address, and do not know that they will be redirected to www.zscaler.com until after they click on the link. After the redirection, the ultimate destination URL can be seen in the web browser address bar.
The long URL is displayed in the browser address bar after redirection
How many people know the difference between a good URL and a bad URL? Even then, how can anyone be sure that a site won't serve malicious content. Many perfectly legitimate websites (Redcross, Indian Governmental websites, etc.) have been hacked and can contain an infamous hidden iframe to spread malware. Well-known websites are no longer necessarily safer than unknown or new sites. Simply using the reputation of the hostname for deciding whether a URL is safe or not is not a good idea.
In a post Michael wrote a year ago, he checked 100,000 TinyURL (URL shortener service) urls. He did not find any link to a malicious executable, no phishing sites, and really few redirections to malicious content.
I believe the danger of URL shorteners has been overblown, mainly based on the idea that individuals are in a position to determine if a website is dangerous or not simply by looking at the final URL. Users are far better off relying on antivirus, URL blacklists and regular browser updates for security. And these tools work just fine or shortened URLs as well.
- Julien
In the wild PDF exploits using a combination of “ASCIIHexDecode” and” ASCII85Decode” filters From Zscaler Research at Mon 08 March, 2010 - 09:45
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.
That’s it for now. Be Safe.
Umesh
Redcross Site Hacked From Zscaler Research at Fri 05 March, 2010 - 07:05
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.
Are you a victim of an Injected malicious hidden Iframe? From Zscaler Research at Thu 04 March, 2010 - 20:44
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.
