• 5,739,213
    REGISTERED
  • 47,640
    ONLINE NOW

Posts Tagged: security

rickroll-android-malware

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.

Say Sayonara to Google Apps

June 3, 2013   By:

company-products

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:

  • The authentication process (i.e. the process of you showing you are who you say you are) is not transparent. While you know you type in your username and password for Gmail, and possibly also enter a two-factor authentication code, you have no idea how these are stored and verified. Does Google simply check your password against a plain text representation? Unless you use an open back-end, nobody can say for sure. You would be relying on Google to tell the truth about how it worked, as you can’t verify it.
  • If someone is to compromise this back-end authentication system, you would be none-the-wiser. It is fairly certain that Google does not encrypt your emails with a per-user key derived from your password, since they also offer a password reset system (which makes defunct most security anyway).
  • If someone at Google takes a dislike towards you, they could disable your access to the closed system, and you would be unable to really do anything about it since nobody else can replicate the service and offer you it under alternative terms and conditions. By extension, if Google changes their terms and conditions, you are able to leave, but will be unable to use any of the service without agreeing to the new terms and conditions.

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.

Advertisment
Hi App Lock

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.

skysecurityfail

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:

  • Gained access to the Play Store Developer Console of Sky, presumably through gaining access to the associated Google Account
  • Obtained access to, or managed to otherwise generate or reproduce, the private RSA keys used to sign the Sky Android app packages

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:

  • Use two-factor authentication on the account.
  • Enable a password or PIN lock on your phones which contain the authenticator app. If you enter a backup phone number, consider the security risks of an attacker compromising your telephone provider via social engineering, or compromising your login to issue a new SIM on your account (to allow them to obtain a one-time login token).
  • Use a very, very, very, very, very secure password for your Developer account, and do not use this password anywhere else. Do not use this Google account for anything else. Log into it only from your own computer, only over WPA-2 (or better) encrypted WiFi, which you control. If you can type this password in under a minute, it’s not secure enough. It should also be random. Random is not your partner’s name followed by the year they were born in. Unless their name is “r$kGmn9d4Fl9&*sEm.Xs2Fl0_3fGjdk” and they were born in year “hJfMn?32VwmndkD2lsk34Rojks83″

Take immense care of your private code signing key as well:

  • It is called private for a reason. Users who install your applications are trusting you to keep this key safe. Do that, and do so with your life. You should plan on being dead for many years before anyone can gain access to this. Many years would likely be a number greater than the life of the universe. Or at least the expiry date on the certificate.
  • Do not decide to “just backup the key to Dropbox for safekeeping” (or indeed any other cloud or remote storage system).
  • Don’t give anyone else access to the key. If you work in a team, can you perhaps operate a system whereby only one person signs the final updates? If it’s really necessary, then share the key, and ensure the other person takes equal levels of precautions.
  • Attackers will always attack the weakest point in your system, and will password-reset your Dropbox account if it gets them access to the shared folder where you stored your private key (and password to decrypt the key in the corresponding readme file, which you knew to never do, but did anyway), or snoop on your emails if you ever attach the key.
  • Protect your key with a very strong and random password (remember the lecture before about what random means?) – do not use this password anywhere else. Do not store this password somewhere an attacker can gain access to. Do not store it with or near your key.
  • Store your private key on an encrypted USB flash drive, and disconnect the drive from your computer when not in use. Then put this drive in a safe when not in use. Store a second copy of the key in a safe deposit box in your bank. This will obviously be heavily encrypted, using a long, secure, random key.

Finally though, what lessons should we all learn (and perhaps Google start to ponder)?

  • There is currently no way to revoke a compromised application signing key. While arguably this is because anyone can sign an app using their own key, and install it on Android (thus meaning that revoking a key is of limited use), this isn’t the case as Google pushes forward with trying to force automated updates upon unsuspecting users. Automated updates are a huge security risk until there is a rapid and effective key revocation system available to developers.
  • There is no way for developers to recover from a compromised signing key. Perhaps Google ought to review the signing system, such that developers create a CA key, which is then used to cross-sign other keys (such as their private signing key), such that if an application key is compromised, they can generate a new one, and sign it with their CA key. (this relies upon the developer understanding this, and realising he must guard the CA key with both his and his family’s lives, and guard the application signing key “simply” with his own life)
  • The Sky apps in question had fairly generous permissions access on the devices they were installed upon. Perhaps developers should stop making their apps attractive targets, and stop bestowing themselves with such wide-reaching permissions on our devices. There is no reason for the majority of apps to make use of any permissions whatsoever (perhaps asides from being able to access the SD card, a permission I argue should be sandboxed to an app-specific area anyway)

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.

sky_apps_playstore_hacked

sky_apps_playstore_hacked

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 »

SecDroid for Android Security

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.

PDroid

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.

ncf4

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.

aeGis

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:

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.

If you want to check out what could be one of the best new security apps, visit the original thread for more information or you can view the source at Decad3nce’s Github.

Advertisement

XDA TV: Most Recent Video

Buy/Sell on Swappa

  • Nexus 5 (Unlocked) buy | sell
  • Galaxy Note 3 (T-Mobile) buy | sell
  • HTC One M7 (Verizon) buy | sell
  • Galaxy S 5 (Unlocked) buy | sell
  • Nexus 7 2013 buy | sell
  • Swappa is the official marketplace of XDA