Apps with dangerous permissions pulled from Chrome Web Store

Do you trust Google to review and ban potentially malicious applications from its online stores?

The Android Market has already been found offering "trojanized" apps, and now the Chrome Web Store has been spotted offering two popular game extensions that request potentially dangerous permissions of users that want to install them.


The apps in question are named Super Mario World and Super Mario 2 and are not manufactured by Nintendo. The fact that they are asking questionable permissions of the users has been discovered by David Rogers, the blogger behind blog.mobilephonesecurity.org, when he was in the process of installing one of them.

"Installation is pretty instantaneous," says Rogers. "As I looked at the screen, I saw the box to the bottom right. 'This extension can access: Your data on all websites, Your bookmarks, Your browsing history'".

He proceeded to deinstall the extension immediately, and searched for an explanation for the unduly broad permissions. The permission to access the user's bookmarks include the permission to read, change, add to and organize his bookmarks, and the one for accessing the user's browser history is supposedly necessary for the app to be able to open new tabs or windows.

But the worst one is the one that gives access to the user's data on all websites. Not only can the app read every page the user visits (think e-mail, Facebook, online banking), but can also use cookies to request the user's data from various websites - in short, the app can impersonate the user to the website.

Apart from being disappointed that Google has failed to spot the problematic permissions and ban the apps, Rogers really takes issues with the "permissions by default" installation.

"You click one button and it’s there, almost immediately with no prompt. Now, I’m not the greatest fan of prompts, but there are times when prompts are appropriate and install time is actually one of them," he explains. "It gives me the chance to review what I’ve selected and make a decision, especially if I hadn't spotted that information on a busy and cluttered webpage."

While I do think that Google has basically made no grave mistake here - it did, after all show the permissions needed - the problem is that for this system to work as it should is that you need to have careful and judicious users. And let's face it, they don't constitute a majority on the Internet.

Rogers also points out that to the average user, the fact that the Chrome Web Store is operated by Google makes him trust implicitly the downloads from it. In his opinion, this should make Google extremely careful when it comes to evaluating and vetting possibly dangerous apps.

In the end, Google has quietly removed the two apps from the market, but has not commented officially on the action. Let's just hope that they will take Rogers' objections in consideration.

Patch for Android authentication flaw only fixes part of the problem

Very recently, researches uncovered a rather serious security flaw affecting around 99 percent of all Android devices. Issues with the way authentication tokens are stored and transmitted on Android versions older than 2.3.4 (which is the overwhelming majority of users at the moment) made it possible for cybercriminals to intercept those tokens on unsecured wireless connections. By impersonating a familiar hotspot, an attacker merely needs to sit back and wait for unsuspecting Android users to connect and log in to affected services.

Today, however, it was announced that Google was moving quickly to address the flaw, and, since the company is implementing a server-side fix, no action by end users is required. It’s believed that tokens served after the change will be encrypted before being sent to and stored on an Android device. The patch will begin rolling out today and should shore things up with Google Docs and Google Calendar, but it’s not totally eradicating the problem as reported by some outlets.

The Picasa vulnerability is still present in Android 2.3.4 and it remains unpatched for the time being. Google has told ComputerWorld’s JR Raphael that engineers are still investigating that particular issue, but no timetable was given for a possible fix.

Google Chrome sandbox apparently cracked

French security firm VUPEN has announced that its researchers have managed manufacture an exploit able to bypass Google Chrome's sandbox, ASLR and DEP.

It is precisely the sandbox feature what made hackers eschew or fail in their attacks directed at Chrome at Pwn2Own time and time again - since, as researcher Charlie Miller pointed out, it has a "sandbox model that's hard to get out of". The feature is also what secured its reputation as the most secure browser around.

VUPEN researchers have also presented a video that shows the exploit in action with Google Chrome v11.0.696.65 on Microsoft Windows 7 SP1 (x64), though no details about it can be actually gleaned from it. According to VUPEN, the user only needs to visit a specially crafted web page with the exploit and a number of payloads are automatically executed, which ultimately allows an attacker to execute arbitrary code outside the sandbox at Medium integrity level.

"The exploit shown in this video is one of the most sophisticated codes we have seen and created so far as it bypasses all security features including ASLR/DEP/Sandbox, it is silent (no crash after executing the payload), it relies on undisclosed (0day) vulnerabilities discovered by VUPEN and it works on all Windows systems (32-bit and x64)," they simply say, and add that the code and the technical details of the underlying vulnerabilities will not be publicly disclosed, but shared only with their Government customers.

While I understand that various governments will likely pay infinitely more for the details of the vulnerabilities than Google would through it's bounty program, the creation of this exploit, the discovery of this 0day vulnerability, and VUPEN's refusal to share it with the public or Google is extremely bad news for Chrome users.

In the end, we can't know which governments have shelled out for the exploit and how will they use it. If VUPEN doesn't change its mind, I'm afraid the only thing left for Google to do is to try to find out the hole for themselves and patch it, or hope that a researcher more inclined to share with them the details finds it and notifies them.

Poisoned Google image searches becoming a problem

If you are a regular user of Google's search engine you might have noticed that poisoned search results have practically become a common occurrence.

Google has, of course, noticed this and does its best to mark the offending links as such, but it still has trouble when it comes to cleaning up its image search results.

ISC's Bojan Zdrnja took it upon himself to explain how the attackers actually do it, and shows that it is actually rather simple.

For one, they attack and compromise a great variety of legitimate websites - usually those which use Wordpress, since it often has vulnerabilities that can be easily exploited and the legitimate users are often lax when it comes to updating it.

Then, they introduce PHP scripts in the sites' source code. "These scripts vary from simple to very advanced scripts that can automatically monitor Google trend queries and create artificial web pages containing information that is currently interested. That is actually how they generate new content – if you ever wondered how they had those web sites about Bin Laden up quickly it is because they automatically monitor the latest query trends and generate web pages with artificial content," he explains.

They also harvest other sites for images, and embed them into the site. When the scripts detect Google's crawlers, they deliver to them pages containing the automatically generated content, and the pictures end up in the image search database.

"The exploit happens when a user clicks on the thumbnail," says Zdrnja. "Google now shows a special page that shows the thumbnail in the center of the page, links to the original image (no matter where it is located) on the right and the original web site (the one that contained the image) in the background."

Google displays all of this in an iframe, and the browser automatically sends the request to the compromised page. The PHP script inserted in it checks if the user has come from a Google results page, and if he did, it displays another script - this time it's a JavaScript one - that redirects the browser to another compromised site that serves malware.

Users should be careful on what they click, but sometimes it is hard to detect malicious links. Zdrnja advises the use of browser add-ons such as the NoScript for the Firefox browser, but believes that Google could help by not using an iframe to display the results.

400% increase in Android malware

Enterprise and consumer mobile devices are exposed to a record number of security threats, including a 400 percent increase in Android malware, as well as highly targeted Wi-Fi attacks, according to a report by Juniper Networks.

With smartphones set to eclipse PCs as the preferred method of both personal and professional computing, cyber criminals have turned their attention to mobile devices.

At the same time, the gap between attacker capabilities and an organization's defenses is widening. These trends underscore the need for further mobile security awareness, as well as more stringent, better integrated mobile security policies and solutions.


"The last 18 months have produced a non-stop barrage of newsworthy threat events, and while most had been aimed at traditional desktop computers, hackers are now setting their sights on mobile devices. Operating system consolidation and the massive and growing installed base of powerful mobile devices is tempting profit-motivated hackers to target these devices," Jeff Wilson, principle analyst, Security at Infonetics Research. "In a recent survey of large businesses, we found that nearly 40 percent considered smartphones the device type posing the largest security threat now. Businesses need security tools that provide comprehensive protection: from the core of the network to the diverse range of endpoints that all IT shops are now forced to manage and secure."

Key report findings include:

App store anxiety: The single greatest distribution point for mobile malware is application download, yet the vast majority of smartphone users are not employing an antivirus solution on their mobile device to scan for malware.

Wi-Fi worries: Mobile devices are increasingly susceptible to Wi-Fi attacks, including applications that enable an attacker to easily log into victim email and social networking applications.

The text threat: 17 percent of all reported infections were due to SMS trojans that sent SMS messages to premium rate numbers, often at irretrievable cost to the user or enterprise.

Device loss and theft: 1 in 20 Juniper customer devices were lost or stolen, requiring locate, lock or wipe commands to be issued.

Risky teen behavior: 20 percent of all teens admit sending inappropriate or explicit material from a mobile device.

"Droid Distress": The number of Android malware attacks increased 400 percent since Summer 2010.

"These findings reflect a perfect storm of users who are either uneducated on or disinterested in security, downloading readily available applications from unknown and unvetted sources in the complete absence of mobile device security solutions," said Dan Hoffman, chief mobile security evangelist at Juniper Networks.

"App store processes of reactively removing applications identified as malicious after they have been installed by thousands of users is insufficient as a means to control malware proliferation. There are specifics steps users must take to mitigate mobile attacks. Both enterprises and consumers alike need to be aware of the growing risks associated with the convenience of having the Internet in the palm of your hand," he added.

The complete report is available here (registration required).

Facebook apps found giving access to user accounts to third parties

A discovery that really should not surprise anyone has been made yesterday by Symantec - it turns out that due to to a flaw in the authentication schemes used before the now default OAuth 2.0, Facebook IFRAME applications have been leaking access tokens to third parties such as advertisers or analytic platforms.


What it means is that these third parties had access to users' accounts and all that is in them - even if the privacy settings shouldn't have allowed it - and they also had the ability to post messages on the users' behalf.

Symantec points out that these third parties have likely been unaware of their ability to access that information, but that is hardly comforting.

"Access tokens are like ‘spare keys’ granted by you to the Facebook application. Applications can use these tokens or keys to perform certain actions on behalf of the user or to access the user’s profile. Each token or ‘spare key’ is associated with a select set of permissions, like reading your wall, accessing your friend’s profile, posting to your wall, etc," the researchers explain. "By default, most access tokens expire after a short time, however the application can request offline access tokens which allow them to use these tokens until you change your password, even when you aren’t logged in."

They estimate that over the years - starting with 2007, when Facebook applications were first introduced - millions of access tokens have been leaked and they think it possible that a great number of these tokens are still available in log files of third-party servers or still being used by advertisers. Luckily for the users, there is a simple way for making these tokens invalid: changing the Facebook password.

According to Symantec, Facebook has already fixed the flaw, but the fact that vulnerabilities like these seemingly pop up in regular intervals make me believe that Facebook is not actively searching for them - that, in fact, they are there because it suits Facebook's agenda.

On the other hand, Facebook is an extremely complex system, and things like this are inevitable - especially when dealing with legacy technologies. Part of the solution is the company's announcement that it will be pushing app developers to migrate their apps from the old Facebook authentication system to OAuth 2.0.