How do you know if your handset is infected with malware? You might not be able to tell until after it’s triggered. And this particular trigger method is very interesting. You know how Google Now listens for you to say the word “Google” to initiate a voice search? Malware might know the same trick. An infected device could be just waiting to hear the right thing before taking action.
This white paper (PDF) from a group of student researchers envisions an “annoyance attack” in a movie theater. Infected phones may be waiting for sound from one of the movie trailers, at which point they would take themselves off of silent mode and start ringing. But the traditional tricks used by malware, like botnet initiated denial of service attacks, still ring true.
If you’re not excited about reading research papers, take a look at the article Darlene Storm published on the subject. She references some examples of real-world malware apps and the mayhem they caused. In this research case, the thing to focus on is the trigger mechanism. The authors point out that security measures are getting better all the time, making it harder for malicious software to phone home or receive commands from a central server without being detected. By using the array of sensors on a modern smartphone, they can be activated in a multitude of different ways—audio, video (camera or light sensor), vibration, or magnetic—without raising the hackles of the security apps. Of course, the answer is to make sure the malware doesn’t make it onto your device in the first place.
What is freedom? This is a big question being asked by people around the world over the past few years. Many of us believe (and often rightly so) that we are fairly free. Arguably, this is correct in many countries throughout the world. You have political freedoms and many many more. But do you have electronic freedom?
For almost everyone reading this article, it is likely you have a Google Account. This means you have a Gmail account. It’s tied deeply into Android via the Google Apps package of proprietary applications (they are not open sourced, unlike the core Android operating system), and rely on closed back-end systems. The problem with such closed systems is:
This last part is significant. Even if you decide that you can trust Google (and I remind everyone of the flaws of the concept of trust—it is much wiser to trust no-one), they can change their legal policies such that they are no longer effectively trustworthy. Google’s own terms of service are a long read, and definitely worth taking a look at. Try and decipher them for yourself, and figure out what applies to which services.
At this point it’s worth being clear. This is not meant to be a “Google is evil” article. Google does make efforts to care about user privacy; take a look at your Google Dashboard. The company is quite transparent about the information retained. The trouble is that there’s no easy way for you to say, “No. I don’t want you to store this.” Google is a company that makes money from knowing everything it can; it’s not in the company’s interest to encourage you to make this more difficult for them! And while it is commendable Google wants to let you see what they know about you, the company doesn’t really help you adjust information such as how to remove Android devices you no longer want listed as being associated with you, including IMEIs and so on.
Over the course of this series of articles, we’ll look at ways you can move away from being so heavily reliant upon Google services. At all times, we’ll try to use Open Source solutions, which are free to use and modify. As a bonus for security, open source code is able to be scrutinized by anyone who wants to take a look at it. Per the popular Open Source advocate’s expression, “Many eyes make all bugs shallow,” which tends to improve security.
In the upcoming first article of the series, we’ll take a look at how to reduce our reliance on the Google Play Store and why we’d want to do that.
Let’s be honest; our phones are probably some of the most personal objects we have. From the memories captured with the camera to the hour-long text conversations, from the bank and credit card details stored within the apps to even our calendars; the consequences of a lost phone or a phone in stranger’s hands would be devastating. So in addition to the password protected lock screen, you may want to add an extra layer of security with HI App Lock.
Developed by XDA Forum Member hiapp, Hi App Lock allows you to lock any app on your phone with a four to eight digit PIN. A more efficient way of protecting information from intruders than apps that require you to navigate to a specific location to view protected files, Hi App Locks simply prompts for a PIN input every time you want to open up an app. This method also allows for the flexibility to protect any sort of data and information that may be on your phone such as emails, bank details, photos, text messages, and so forth.
Force closing the app through the settings menu would only close the app momentarily, upon which HI App Lock would instantly relaunch itself before anyone has the chance to navigate to a protected app. Other important functions include locking incoming and outgoing calls, prevention of uninstalling of apps, a widget for quick lock and unlock, and a security question in the event when you may have forgotten your pin number. Of course, however, rooted devices with ADB debugging left enabled and those without password-protected recoveries or encrypted /data storage can still find themselves at risk, so make sure you turn off ADB and encrypt your device if you’re planning on securing your device.
Hi App Lock is compatible with any device running Android version 2.1 or newer and is free from the Play store. If this has gotten your attention, make sure to check out the application thread for more information.
After our earlier article warning users to uninstall the Sky apps from their devices, it’s time to take a look at the technical significance of this attack. Firstly, the attackers have managed to do two key things here, each of which should each be impossibly difficult for the Play Store update system to be secure:
The former is obviously important to security, since without access to the Developer Console, it is not possible to push out an update to an existing app. While obviously a malicious user could publish his own app, he would not be able to push an update to an existing app already installed via the Play Store, unless he can do so using the account of the developer who originally published the application.
The latter is equally (if not more) important a security measure: Even if an attacker gains access to your Developer Console, they cannot push an update to an existing app if it is not signed using the same keys as before. This check is also enforced on each individual Android device, meaning even if there was a bug in the Play Store implementation of this security, your own device would reject the update! All bets are off though, if the private signing key is compromised or accessed.
In the case of the current Sky attack, it seems likely that both the Developer Account and the private signing keys were compromised. At this point, the safest option would arguably be for Google to use its remote uninstall trigger on these packages, if there is any indication the actual packages themselves were compromised. Sky will no doubt resist this, as they would not want to see their apps disappear from users’ devices. Unfortunately for them though, it is long past that. These users need to uninstall the app now, as Sky can no longer continue to use these keys.
And herein lies the ultimate problem in the Android security chain (and indeed in most certificate based security systems). There is no system for effective, wide-reaching key revocation. If your Android signing keys are compromised, the trust chain ends. There is no way for you to revoke your compromised key, so clients will no longer trust an app update signed with it. There is also (less importantly from security, but more importantly from the developer’s perspective) no way to securely supersede these keys with new ones (while ensuring an attacker cannot replace the keys with his own).
What does this mean for developers?
Take all reasonable steps to protect your Google Play Store Developer account:
Take immense care of your private code signing key as well:
Finally though, what lessons should we all learn (and perhaps Google start to ponder)?
Hopefully, Google will make use of their remote uninstall ability to remove the app from user devices, and also let them know somehow (email to their Gmail accounts) what happened, and that Sky did not look after their key properly. This is a major embarrassment to Sky, and they should hang their heads firmly in shame for not taking sufficient precautions to ensure that everyone with access to their signing key was suitably competent to prevent it falling into the wrong hands.
At the end of the day, it is the end user whose security is affected by the failings of the developer. And for this reason, security lapses such as these are unforgivable.
May 26, 2013 By: Pulser_G2
Today is Sunday, 26th May, and across the world, many people have woken up following a leisurely lie-in to the small notification of an updated app being available. Nothing unusual there, or so you’d think.
The only difference is that today, some of these app updates may well have been malicious updates, pushed to some of the Sky UK official Android apps. As reported by PC Pro and Android Police; the Sky Go, Sky+, SKY WiFi, and Sky News apps all appeared to be targeted in the attacks that involved updates being pushed to the Google Play Store for these applications. READ ON »
Personal information security has been a prime concern for computer users since nearly the beginning of computing itself. Malicious users find exploits and develop viruses, trojans, and rootkits to gain control of our devices to use them for their own advantage. This not only costs us in form of degraded performance and potential data usage costs, but can also have more dire consequences such as our financial information being sniffed and used to withdraw money from our accounts, or identity theft that could land us in serious trouble with law enforcement.
Previously, these issues were major concerns primarily on desktop computers, but with the massive popularity in mobile devices, such malicious individuals and groups have now started targeting popular mobile platforms. While Google has included better security measures in the latest versions of Android and several antivirus vendors have also developed solutions to get rid of such malware from our devices, it’s always a good idea to secure our devices as much as possible to prevent any security breaches from happening in the first place. To help you with this, XDA Senior Member x942 has developed SecDroid, an Android app that secures your devices against several intrusion methods.
SecDroid achieves this by disabling several services on your device that most users will not require to be running all the time. These services include SSH, SSHD, Telnet NC (net cat), and Ping, to keep others from gaining access to your device via a remote terminal. SecDroid also disables Package Manager so that no apps can be installed remotely to your device (you can still install them from Market or using APK files directly on the device itself). Lastly, it also allows you to disable ADBD (the ADB service running on the device that allows you to connect to it through command line from a remote computer) until the next reboot.
SecDroid is currently in active development, and this is its first alpha release. The developer has also released the source code of SecDroid under the GPLv2 license. You can find more details and the download link in the forum thread.
It doesn’t always make the front pages, but device security is still one of the most important topics for Android users. Whether it’s for protection from exploits that can brick a phone or apps that have permissions they really don’t need, users and developers are always on the lookout for potentially dangerous applications. One app some use is XDA Forum Member svyat‘s PDroid, which is now ported to the Verizon Samsung Galaxy S III.
XDA Recognized Developer TrevE has released the port for the Verizon Galaxy S III. It functions just like PDroid is supposed to. For those who don’t know what it does exactly, here’s an explanation from TrevE:
PDroid is a (awesome) security framework similar to superuser but allows selective blocking of app permissions. It creates a “proxy” between the actual permissions and the PDroid framework which allow passing of different return data.
Because of the proxy created this method is better than apps which just remove permissions from manifests because it should not cause any fcs- Apps will never know the difference. It also allows patching permissions such as location/android id/camera to return spoofed data.
PDroid is a very complex mod across many parts of framework.
In more simple terms, PDroid allows users to control what permissions applications can have. This is an excellent app because it can stop a malicious app dead in its tracks, before it has a chance to do any damage by accessing features or information that you don’t want to grant. And since it uses a proxy method to prevent unwanted access, this prevents the force closes present with other methods of permission blocking. Any Android user who wants to micromanage app permissions should definitely give this a look.
To learn more, go to the original thread.
December 29, 2012 By: Former Writer
Lock screen security, and Android device security in general, is a frequent topic of conversation. While lock screens are becoming more functional with features such as the now-standard lock screen widgets, security remains about as easy as ever to work around. This is an issue that may be eased with a new app called NFC Secure Beta.
XDA Senior Member r2DoesInc has released NFC Secure Beta. What the application does is force users to use a NFC tag to unlock the phone. However, it doesn’t replace the current lock screen entirely. As r2DoesInc explains:
NFC Secure is not a lockscreen. It’s a supplement to your current lockscreen. Once you pass your lockscreen and enter the actual device, NFC Secure kicks in. When this happens, you are 100% locked out of the device, no way to get past it, even with a reboot, unless you have your key.
So, along with a good lock screen password, NFC Secure can make it next to impossible for the average Joe to get into your device. This renders tricks like looking at smudges on the screen to discern an unlock pattern useless. Also, if users are worried that they lose their NFC key, the app is capable of supporting multiples, so spares can be made.
This is a lot more information about NFC Secure that can be found in the original thread.
December 27, 2012 By: jerdog
Security applications are a dime-a-dozen these days. While it normally wouldn’t be noteworthy to have a new entry into the fray, this one is different in one very important way: The developer knows none of your information. AeGis, which comes to us from XDA Recognized Developer Decad3nce, is unlike competing applications in that it does not require a data connection, you are not asked to log in to anything, and you do not need to register and pay a large firm a yearly fee in order to use the below features:
- Ability to remotely lock your device via SMS
- Ability to remotely enable sound on your device via SMS
- Ability to remotely locate your device via SMS
- Ability to remotely wipe your device via SMS
- Ability to lock application with a password
In what may be the best feature of them all, Decad3nce has chosen to completely open-source the application, giving you the ability to fork and add new features as you see fit. AeGis utilizes the latest in Android’s Holo design principles, and requires Android 4.x.