Tag Archives: Android

Beware How You Use Password Managers

ARS Technica wrote a piece on the continuing security flaw with password managers like LastPass and KeePass on Android.  Technically, the problem is an Android problem, but from the user’s standpoint they don’t really care.

The problem is tools like LastPass and many others use the Android clipboard to automatically log you on to a web page.  That clipboard is available for any app to sniff and steal the content.

This problem was originally uncovered in 2013, but came back into the light because of an app recently published on the Play store which is a proof of concept app to steal passwords out of LastPass.

An alternative is to use the password manager the way I do which is to open the password manager, look at the password and type it into the browser.

But that is not as convenient.

LastPass CEO Joe Siegrist, when asked if he had ever notified his users of this vulnerability, did a slight of hand and responded that this was an Android problem.   I would guess that means that the answer to the question is no.

To be fair, it IS an Android problem.  But if users were aware that this mode of using LastPass and many other password managers was not safe, some percentage would change the way they use it.

According to ARS – and I am not a LastPass user – there are other modes of using LastPass besides autofill that are not susceptible to this problem (such as using the LastPass keyboard or LastPass browser).  I don’t know about other password managers, but it seems like an important question to ask.

While the proof of concept app just published, clipcaster, is benign, some other app might not be so benign.  It could run in the background, collecting userids and passwords and sending them to Bulgaria and you would never know.

Food for though.

Android Allows App Hijacking On Install

A couple of months ago I wrote about an iPhone bug that allows users to unintentionally install rogue iPhone Apps (see post).

Well now Android users are getting hit with a similar attack.  Ars technica is reporting that they have found an Android Installer hijacker (see article).

Like the iPhone bug, it only works if you install an app from somewhere other than the Google Play store.  Like the iPhone bug, the vulnerability allows the user to think they are installing App A when in fact they are installing App B.  The mechanics of how it works is different than the Apple bug, but both are related to inadequate validation of the installers at install time.

The bug was patched in Android 4.3_r0.9, but apparently some versions of 4.3 are still vulnerable.  Android 4.4 and Lollipop (5.0) are not vulnerable.

Unfortunately like some other Android bugs, this means about 900 million phones or 49% of all Android users are vulnerable.

If you steer clear of third party app stores you will not have a problem, even if you are running a vulnerable version of the Andoid OS.

Google Is Acting Like Apple – And NOT To The User’s Benefit

Google is a smart organization.  It has watched the stranglehold that Apple has over its users and has decided that it likes it.  Just like art imitates life, Google imitates Apple (and then says “who me?”).

The issue at point is a bug found in the WebView rendering engine, used in all Android releases prior to KitKat (4.4).  That rendering engine is open source.  Google replaced it with a version that uses a rendering engine developed for its Chromium project.  The rub is that this rendering engine requires a licensing agreement between Google and the user (such as Samsung or LG) and the terms of that licensing agreement are distasteful to the handset manufacturers.  According to Extreme Tech, some of the distasteful terms are that you don’t compete with Google (i.e. develop apps that Google also has), that you take all of Google’s apps if you want any of them and that you agree to not create your own version of Android like Amazon has done.

For the end user like you and me, this means that if you have a pre-KitKat phone, you will have to live with this bug in the rendering engine – and any other ones that are found, because Google says that since WebView is open source and they are no longer using it, it is up to the user (meaning either you or me, the cellular carrier or the phone manufacturer) to develop, test and deploy a fix.  Fat Chance!  For one thing, most phones are locked down, so the end user’s ability to install a patch is limited at best, the carriers don’t have the skills to do it and the phone manufacturers want you to buy a new phone anyway.

Apple has done similar things for years. For example, I remember a story of a user that wanted to install the new version of the Kindle software on her iPad, but even though it would work perfectly on that iPad, Apple deemed that iPad obsolete and would not provide an OS upgrade for that version that was needed for the Kindle software to run.  So,  the user had the choice of not running the Kindle software since Amazon ‘killed’ the older version of the Kindle software so it would not run or buy a new device.

In this case, about 930 million Android users will be susceptible to this and future bugs until they crush their phones (so that no other user will be impacted – not just transfer the problem to another user) and buy a new Apple or Android phone.

Apparently, there are about a dozen attack tests available in Metasploit, a popular penetration testing tool, which will not be patched.  This of course, does not count any new bugs found between now and when those 930 million phones are crushed.

So, as Rapid7 suggests, if I were a hacker, I would develop exploits for those 930 million phones knowing that those bugs are never going to be patched.  A simple return on investment analysis says that the return will be huge.  If those phones are used by corporate users, the corporate data is free for the taking.

Since users are locked in to contracts which have large penalties, those phones will remain active at least  until the contracts expire.

In addition, as companies have rushed to “bring your own device” strategies to supposedly save money, the users have to provide their own phone to get their job done and are much less likely to fork over the dough to buy a new phone even after their contracts expire since the money comes out of their own pocket and not the company’s.

Samsung, apparently, is so upset about Google’s efforts to turn the Android into a closed, licensed, OS like Apple’s iOS, it is developing its own called Tizen.  When, or if, Tizen becomes mainstream is unclear, but even if it does, it now means that users will have 4 choices for phones (Apple, Android, Windows and Tizen).  Developers will pick the winners and losers and corporations will have to support yet another development environment for building apps.  Glad things are so simple.

Android becoming a licensed OS is probably not a big problem for end users in the long run – they don’t really care.  Apple’s iOS is licensed and it appears to be pretty popular.  In the transition period, however, the users get the shaft.



Factory Reset On Your Android Phone – What Does It Really Do?

I suspect that many of you have performed a factory reset on your phone thinking that all your data was gone and then either gave away or sold your phone.  I have.

Tech Times wrote an interesting article on the subject and it is not all sunshine in Android land.

Avast, the computer security software firm purchased 20 second hand Android phones on eBay and used a standard forensics tool (FTK imager) on these 20 supposedly factory reset phones.

The results?  They recovered more than 40,000 pictures, some with kids in them.  Some with “personal” selfies.  Along with a bunch of other things like a loan application.  Remember these 40,000 pictures came from only 20 phones.

The issue is that just like in DOS (or Windows), all the factory reset does is change the index to the file so it is not visible.  The data is still out there.

Before you panic too much (sorry, you can’t change history – that phone you sold last year – just forget it), there is an answer.

Google says that if you enable encryption before you do that factory reset, you should be in good shape.  Remember that you have to enable encryption on the external SD card separately from the built in storage (or remove it from the phone and keep it).

Once you have turned on encryption, THEN perform the factory reset.

It still does not delete any of the files, but it DOES delete the encryption key, so when someone retrieves the deleted files, they won’t have the key and therefore won’t be able to decrypt the file they were able to recover.  Not perfect, but a whole lot better than before.

Avast (of course) does offer a freemium product called Avast Anti-Theft that they claim will overwrite deleted files, but unless you are very paranoid, you should not need to do that.

I guess it is what you DON’T know that can bite you.