Friday, January 18, 2013

Twins born in different years with even different faces? PC-AV-in-cloud and Mobile-AV-in-cloud

It is rare for twins to have different birthdays. But thanks to the increasing mobile malware, a set of twins have shown up with birth year 2007 and 2013 respectively. Their names are PC-AV-in-cloud and Mobile-AV-in-cloud. It seems that current mobile threat landscape is very like the PC one of years ago.

To effectively handle the scale and magnitude of new malware variants, AV functionality was being moved from the user desktop into the cloud. In 2007, the first baby, PC-AV-in-cloud, was born with arguments. Does the paper “why in-the-cloud scanning is not a solution” at VB 2009 ring a bell to you?

Not finished yet! The mobile platform becomes a new target for hackers. Traditional virus mass-production tricks are cloning into mobile threat landscape. More and more hackers are using encrypted strings, code obfuscations to deal with manual reverse engineering. Malware writers leverage technique tricks (rootkit, botnet, and even mobile packer?) which they created for PC years ago, directly at mobile devices. As a result, android mobile malware are adopting traditional malware techniques at a fast pace (such as apkfuscator). Security vendors are busying with extending cloud-based security infrastructure with mobile-scanning cloned from PC counterpart.  It looks like we are going to have a new baby, Mobile-AV-in-cloud in 2013. Are you ready for this?

Unfortunately, anti-virus for PC desktops is not working well on mobile platform due to battery power constrain, internet bandwidth, limited computation capability, and constant pattern update. Recent research works showed mobile AV engines can be easily fooled by simple code obfuscation with detection rates dropped sharply. To make things worse, solution challenges exist when implementing in-the-cloud scanning on mobile devices. When the client software cannot determine if a suspicious application is malicious or not, it will send the application or its related information to the cloud. In the case of server-side polymorphism, which causes each downloaded file to be a unique version, will force the client to send files constantly. The battery constrains will be a serious issue.

Security vendors are facing various challenges regarding the architectural design, implementation, and validation on mobile anti-malware. New techniques need to be designed to handle with the constraints of the mobile platform. Zscaler's ZAP (Zscaler Application Profiler) is web based tool designed to streamline the capture and analysis of HTTP(S) traffic from mobile applications. ZAP is capable of analyzing traffic from both iOS and Android applications and includes the following functionality.

For additional details on how to use ZAP and view a video walkthrough, please see the ThreatLabZ blog.

Thursday, January 17, 2013

Mobile App Wall of Shame: ESPN ScoreCenter


ESPN ScoreCenter

Price: Free
Category: Sports
Updated: Dec 19, 2012
Version: 3.0.0 Build 361
Size: 13.1 MB
Language: English
Vendor: ESPN Inc.
Operating System: iOS

Update: [01/18/13 4:19pm EST] Zscaler was contacted by ESPN to inform us that they have addressed both of the vulnerabilities that we informed them about on the server-side and we have confirmed this. We want to thank ESPN for working quickly to protect their users.

Background

ESPN ScoreCenter is a popular sports application on the iOS platform (currently the #1 free sports app in iTunes). The app delivers live scores, news, video, alerts, etc. and is an official application of ESPN Inc. Version 3.0 of the app features a completely redesigned the UI, but also includes a couple of key vulnerabilities.

Vulnerability #1 - XSS

We tend not to think of mobile applications as being vulnerable to cross-site scripting (XSS). After all XSS belongs to the domain of web applications and mobile apps are native apps. Right? Not necessarily. Many mobile apps are actually just web pages displayed in a WebView control or more commonly web content mixed in with native controls and such is the case for ESPN SportsCenter. As with many web apps, when user supplied content isn't properly sanitized, active content, such as JavaScript can be injected. The included screenshot illustrates a simple alert window being displayed within the application. The vulnerable page also exists on the mobile web version of the app during logout and can be seen in the following sample URL:

http://m.espn.go.com/mobile/apps/reg/login?lang=en&timeOffset=-300&swid=63DBACA2-032F-491E-A28D-1B4835DC14XX&username=%3Cscript%3Ealert('test')%3C/script%3E

XSS is of course valuable for a variety of attacks, such as stealing a user's authentication cookie, however, in this case that may not be necessary, thanks to vulnerability #2...

Vulnerability #2 - Clear Text Authentication Credentials

I'm continually surprised by just how common it is for mobile applications to pass authentication credentials in clear text. Mobile apps often pose a higher risk than their web based counterparts and this illustrates the reason why. In many ways, mobile apps behave like web apps, but without the many visual controls provided to end users to spot and avoid insecure behavior. In a web app for example, if your password is about to be sent insecurely, you have warning signs. Perhaps you notice that SSL is not being enabled as you don't see the lock icon or perhaps SSL is being used but with an invalid certificate which you are warned about by a standard popup message. In mobile apps, these same vulnerabilities exist, but end users are blind to them as mobile app developers do not have to include any warning signs and in an effort to conserve screen real estate, generally don't. Think about it, when viewing web content in a mobile app, you normally have no way of knowing where the content is actually coming from because there is no address bar to reveal the source URL.

ESPN ScoreCenter's flaw - sending your password in clear text. Therefore, anyone sniffing traffic on the network would be able to easily steal your username/password. More often than not, when I see this flaw, it occurs not during a regular login, but rather when you first set up your account and such is the case with ESPN SportsCenter. Once you've created an account, subsequent logins at the regular login page (/mobile/apps/reg/loginlanding) are sent via HTTPS. This is not the case however when an account is first created, with the username/password sent in clear text : 

http://m.espn.go.com/mobile/apps/reg/createaccount

POST /mobile/apps/reg/createaccount HTTP/1.1
Host: m.espn.go.com
Accept-Language: en-us
Pragma: no-cache
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Mobile/10A551
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://m.espn.go.com/mobile/apps/reg/createaccount
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Cookie: s_vi=62b95c266882437b80b87bd3e078cac5805e20de20a8387999d1c6b02c74a2d6
Proxy-Connection: keep-alive
Content-Length: 329
Origin: http://m.espn.go.com
Accept-Encoding: gzip, deflate

passedSubId=&langCode=&udid=&version=&userAgent=Mozilla%2F5.0+%28iPhone%3B+CPU+iPhone+OS+6_0_2+like+Mac+OS+X%29+AppleWebKit%2F536.26+%28KHTML&country=US&form=true&policies=true&firstname=ThreatLabZ&lastname=Zscaler&username=ThreatLabZ&gspw=Zscaler&email=threatlabz%40zscaler.com&birthdayMonth=1&birthdayDay=2&birthdayYear=1973 

Conclusion

It isn't hard to uncover security flaws such as this, it simply requires inspecting the HTTP(S) traffic sent by an application. It is disappointing to see that the testing performed on apps before they are admitted by Apple to the iTunes store does not even include such basic security tests such as looking for XSS vulns and sending passwords in clear text.

These flaws were uncovered by leveraging Zscaler's free ZAP (Zscaler Application Profiler) service to inspect the application traffic. Want to test the apps on your Android/iOS device to see if they're exposing unnecessary risk? Test them with ZAP.

Monday, January 14, 2013

Are you vulnerable to yet another Java 0Day exploit?

Test to see if you're vulnerable.

Only five months after the last high profile 0-day Java vulnerability, there is new 0-day being exploited through Java plug-ins. This vulnerability is present in Oracle Java 1.7.0 to 1.7.10 and has already been included in a variety of browser exploit kits. On January 13, 2013, Oracle released a fix for the issue in the form of Java 1.7.11.

Java has a long history of 0-day vulnerabilities being actively exploited. Exploits are usually drive-by attacks: users get infected by navigating to hijacked websites where an invisible Java applet drops a malicious executable on the user's machine. The very popular, Blackhole exploit kit includes numerous Java exploits.

This vulnerability has been exploited very quickly on the Internet. Firefox reacted quickly by flagging all versions of Java as vulnerable plugins. This means Java is disabled by default on Firefox and users get warned if a page requires the use of Java. It would appear that the work they recently did on their Click to Play feature for vulnerable plugins has paid off. Apple took a similar approach by pushing out a new malware definition list that rather than blocking malware, as it generally does, simply disabled the Java Web Start browser plugin altogether.

Are you vulnerable?

The latest iteration of Java is version 1.7 revision 11. This is now the default version on Windows. Although Java 1.6 is not vulnerable to this latest threat, Java 1.6's end of life is February 2013, so you should not downgrade to that version.

One annoying fact with Java is that new versions are installed on top of each other. As such, you are likely to have multiple versions of Java installed on your system. Internet Explorer may not even be using the latest version of Java that you have installed.

We have therefore created a new page to list all of the versions of Java installed on your computer. You can test your browser here.

Disable Java

To be on the safe side, you can disable Java in your browser to prevent malicious applets from running.

Firefox

Go to Tools - Add-ons - Plugins

Look for Java Deployment Toolkit and/or Java Platform SE. Disable them all.

Java disabled in Firefox

Chrome

Go to WrenchSettings and Show advanced settings... - Privacy and Content settings - Plug-ins - Disable individual plug-ins... - Java - disable. It is quite difficult to find!

Java enabled in Chrome

Internet Explorer

Go to Tools - Manage Add-ons. Disable Java(tm) Plug-in SSV Helper and Java(tm) Plug-in 2 SSV Helper.


Java disabled in Internet Explorer 9
Update: To completely disable Java in Internet Explorer, follow the steps at http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE.


Safari

Go to Safari - Preferences

Look for Web Content: Enable Java and uncheck the option.




Test it

Now go to our Java test page to ensure that Java has indeed been disabled in your browser.

Click to Play

If you need Java occasionally, you can enable it on-demand with Click to Play. I described Click to Play, a way to manually enable plugins only on visible content, in a previous post. This feature is only available in Firefox, Chrome and Opera.

Firefox also offers several browser extensions to easily enable/disable java with one click. I personally like Quick Java.

Take this opportunity to check all the plugins running in your browser and disable the plugins that you do not really need. Don't give the bad guys an attack surface that's any larger than it needs to be!

Friday, January 11, 2013

Preparations for a spam campaign

We have discussed a number of spam and malware campaigns on this blog. This time, I'll show what happens in the days and weeks before the campaign starts. I've found two examples that show the steps that are taken by the spammers in preparation of their campaign.

First step: hijack websites

The spammers need to ensure that its spam e-mails or messages are not quickly flagged as spam. One technique to avoid spam filters it to use existing websites with a good reputation to redirect users. These domains would not be part of any blacklists and should already be known and categorized by vendors. This is a better alternative to the free hosting and DNS providers, which may not have a good reputation like .co.cc and .tk.

Unfortunately, hacking legitimate websites in large numbers is quite easy these days. Popular open-source platforms, like WordPress, Joomla and Drupal, contain a lot of security vulnerabilities (in the core software and the plugins), which attackers can take advantage of.

The first campaign I spotted was hijacking German Joomla! sites. All the hijacked sites seem to be running Joomla 1.7. I'm not sure if the attacker used the privilege escalation issue, the XSS vulnerability or one of the 23 other vulnerabilities found in 2013.

The other campaign targeted WordPress sites, an open-source platform loved by webmasters and attackers.

Step 2: hide the malicious page before the campaign.

Rather than modifying the exiting page, new pages are added to the hijacked sites. The attackers often put these files in hidden directories (starting with a dot), temporary folders, or plugin folders.

The Joomla sites were having malicious files put in /tmp/, such as:
  • hxxp://www.original-ettaler.de/tmp/gmmsxlibort.php
  • hxxp://www.neumann-arbeitsbuehnenvermietung.de/tmp/gmmsxlibort.php
  • hxxp://www.myatrium.de/tmp/gmmsxlibort.php
  • hxxp://www.optik-boysen.de/tmp/gmmsxlibort.php
  • http://www.onepos.de/tmp/gmmsxlibort.php
  • etc.
For the WordPress sites, the attackers hid the malicious files in folders used by common WordPress plugins and themes:
  • http://gv-global.com/components/com_ag_google_analytics2/gmmsx.html
  • http://www.highontheheart.com/wp-content/themes/twentytwelve/gmmsx.html
  • http://dreamzinfrabangalore.org/wp-content/themes/twentytwelve/gmmsx.html
  • http://jivakafoundation.org/components/com_ag_google_analytics2/gmmsx.html
  • http://agg-systems.eu/components/com_ag_google_analytics2/gmmsx.html
  • http://vacationrentalbusiness.net/wp-content/themes/twentytwelve/gmmsx.html
  • etc.

Step 3: keep out security scanners

Attackers don't want security tools to flag their redirection pages as malicious before the campaign. One common technique involves making the pages redirect all visitors to a random website, like http://www.google.com/ until the campaign is ready to start.

When the campaign is running, the redirection pages will still try to separate legitimate users from security scanners. They can check the IP address of the visitor, use Flash or JavaScript to make the redirection and use cookies or IP addresses to track visitors and allow them to visit once only, etc.

Step 4: open the curtains

Once the spammer has gathered enough legitimate sites and e-mails or messages are being sent out, the redirection pages point users to the malicious site.

For the Joomla campaign, the final spam page is hxxp://www.dailynews.com.2012.fashion.italy.moda.trends.luxurynws.com/. As often is these type of scams, the page looks like an official news paper article extolling the merits of some product or work from home scheme. In this case, the products are replicas of luxurious watches.

Fake news article about replica watches
The second spam campaign redirect to the usual Work from Home scam at hxxp://newsmarket3nextgenonline.com/?12/2. This site is currently down.

Example of Work From Home scam
Now you know what goes on before these spam e-mails hit your mailbox.

Thursday, January 3, 2013

Monster is lurking….Beware!!!!



    Monsterindia.com is a very popular Indian job search website and a subsidiary of Monster Worldwide.  If you are using Monster job search app for Android then you need to be aware of the fact that it’s leaking your username and password in clear text. Beyond this, it also leverages weak authentication encoding. If we sniff the traffic we can easily get username and password as they are sent via HTTP (no encryption). In order to see this in action, you can leverage ZAP (Zscaler Appliation Profiler), which helps you determine the overall risk posed by apps that you have installed on your Android/iOS device.

Here is registration screen of the app.


Lets dive in and see exactly how this app is leaking data. Let’s start with an initial account registration, when first installing the app. When doing so, you’ll observe following traffic: 


Here, if you look closely, you can observe the highlighted text, which reveals that the e-mail address, username and password are all transmitted in clear text.
If you then subsequently login with an already established account, you’ll observe the following network traffic:

Here, I am using canary data for testing purposes and I have used ‘fnzscaler’ as the user name. As can be seen, this is again being sent in clear text to server. While not nearly as critical as the fact that the password was leaked during the account signup, there’s no reason why this traffic shouldn’t be sent via HTTPS to ensure that someone sniffing traffic on the network wouldn’t be in a position to brute force the login after obtaining your username.
Similarly if we take look at traffic on iOS device, the same thing can be observed. It is also sending the username and password in clear text during the registration process.

It is disappointing that Google’s Bouncer service, or some other method was unable to quickly detect such simple coding mistakes and prevent an app with such a basic privacy flaw from appearing in the Google Play Store, until the issues are addressed.
For security purposes, I recommend that you check the risk score of apps on your mobile device, using ZAP. It can help to uncover high risk applications on the iOS and Android platforms. 

Be careful while using such apps.